[MPlayer-dev-eng] [PATCH] set is_streamed correctly in lavf URLContext

[Michael Niedermayer]

On Wed, Dec 19, 2007 at 02:52:32PM +0100, Reimar Döffinger wrote:
> Hello,
> On Wed, Dec 19, 2007 at 02:05:07PM +0100, Michael Niedermayer wrote:
> [...]
> > > > If sizeof(ByteIOContext) can change between lavf minor version, then
> > > > it shouldn't be part of public API.
> > > > Maybe the definition of ByteIOContext should be moved to a private
> > > > header and only the declaration should be kept in public header ?
> > > 
> > > Maybe ...
> > 
> > After thinking about this again and after reimars comments, i think yes we
> > should remove it, we can always add it back with a
> > 
> > #ifndef INTERNAL
> > uint8_t array[INT_MAX];
> > #endif
> > in it to make misuse harder
> 
> Given the reason for all this and that there seems no other way to set
> is_streamed that seems a bit stupid...

IIRC is_streamed can be set from within the open() function of the URLProtocol
which needs a dependance of the position of is_streamed in URLContext.
Or if URL* isnt used then it can be set directly in ByteIOContext, which needs
a dependance on the position of is_streamed in ByteIOContext. But in no case
is a dependance on sizeof(ByteIOContext) needed. Theres no reason why the
position of is_streamed should change, except during major version bumps but
new fields surely could be added to these structs.


> 
> > Mplayers lavc/lavf wrapers certainly serve as examples for other projects.
> > And if they are filled with ugly hacks which break lavcs ABI/API then this
> > will negatively affect more than just mplayer.
> 
> Well, I am trying to fix it (at least from time to time), 

;)


> but the reason
> for most of those ugly hacks is that there is no proper way to do it.

If there is no proper way, then one should be added. Or the problem should
at least be documented (on our bugtracker) and with a FIXME in the wraper
in mplayer.


> Once there is a proper way and we switched to it I will consider writing
> the code in such a way that it works across revisions, but I don't see a
> point in bothering with such details while there are glaring problems.

The reason why i complain is the addition of new hacks ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20071219/5ea9696b/attachment.pgp>