[MPlayer-cvslog] r29610 - trunk/libmpdemux/demux_demuxers.c

[Uoti Urpala]

On Wed, 2009-09-23 at 13:18 +0200, Reimar Döffinger wrote:
> On Wed, Sep 23, 2009 at 12:32:44PM +0300, Uoti Urpala wrote:
> > n Wed, 2009-09-23 at 09:56 +0200, Reimar Döffinger wrote:
> > > The subtitle code pulls in more by itself as long as there is one.
> > 
> > By what mechanism? The code is pretty much designed with the goal it
> > should not trigger reads from the demuxer. The only way it could pull
> > more without being buggy in normal use would be if it'd somehow trigger
> > the added code in demux_demuxers again (via other streams?) but I don't
> > see how that'd happen either.
> 
> Ah, that you mean. I fear it does assume not more than one subtitle
> packet per video packet on average.

It wouldn't take anything that extreme to show broken behavior. If audio
and video come from the same file then audio buffering may also buffer
video frames ahead, and only one subtitle from that duration would be
handled. Further audio fills could already trigger new subtitle reading
before buffered video runs out but that's not something to count on.


> > What "adequate interleaving"? I don't see any reason why it would be
> > generally _desirable_ for reading one stream to imply buffered packets
> > appearing in another, so this would rather be something to avoid (when
> > there's no cost to doing so), not something to make sure of.
> 
> Well, maybe, though I am not 100% sure you couldn't fiddle with mov edit
> lists to get a similar issue for audio streams as for subtitle streams.

I don't see how you could get anything similar for audio. Subtitle
reading relies on the side effects of reading other streams. Audio
doesn't.


> > The
> > subtitles are a special case because trying to read the next packet
> > naively could trigger unlimited buffering of other streams. Since the
> > subtitle code already has to be aware of such problems I think it would
> > be logical to make it aware of this detail too, and unconditionally call
> > ds_get_next_pts() if appropriate. The decision to do that could be based
> > on a flag set in the demuxer/demux_stream object (probably better than
> > hardcoding a check against specific demuxer types there).
> 
> Yep, basically what I meant by "indicate non-interleaved streams".
> Do you still object to sh_common addition? I'd rather add that
> interleaved flag there instead of on an as-needed-basis that increases
> the mess.

Why sh? That's for codec-level stuff and this demuxing property doesn't
belong there. I think a demux_stream field would be better.