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

[Reimar Döffinger]

On Wed, Sep 23, 2009 at 05:36:01AM +0300, Uoti Urpala wrote:
> On Tue, 2009-09-01 at 16:51 +0200, reimar wrote:
> > Hack demux_demuxers so that demux_demuxers_fill_buffer is actually called.
> 
> > Modified: trunk/libmpdemux/demux_demuxers.c
> > ==============================================================================
> > --- trunk/libmpdemux/demux_demuxers.c	Tue Sep  1 14:12:45 2009	(r29609)
> > +++ trunk/libmpdemux/demux_demuxers.c	Tue Sep  1 16:51:49 2009	(r29610)
> > @@ -54,6 +54,9 @@ demuxer_t*  new_demuxers_demuxer(demuxer
> >    ret->video = vd->video;
> >    ret->audio = ad->audio;
> >    ret->sub = sd->sub;
> > +  if (vd) vd->video->demuxer = ret;
> 
> Unfortunately this breaks all the demuxer-specific code in video.c which
> now sees the file type as "demux_demuxers type".
> 
> What was your motivation for this change? To enable r29611? If so then
> rather than changing video.c that subtitle problem is probably better
> fixed otherwise. I think 29611 is not a correct fix anyway - it only
> ensures there's one demuxed packet, but sometimes more than one would be
> needed.

The subtitle code pulls in more by itself as long as there is one.
But the principle motivation is that demux_demuxer_fill buffer should be
consistently called, not that sometimes it is called (well, it probably
was never called previously, but that was more an accident than
intentional), sometimes the subdemuxers directly.
And while the subtitles are the only case where it is actually
necessary, the demuxers are supposed to make sure data is adequately
interleaved, which is only possible if the reads go through
demux_demuxers.
Apart from that I am not at all convinced that all the demuxer-specific
code in video.c should be there and not at least partially in the
demuxers.
A large part of it I think could be removed by just making the demuxers
set sh->format correctly and introducing a needs_parsing variable (for
what I can tell find_video_codec does not really find the video codec,
it finds how if at all the stream needs to be parsed into packets).
Particularly the 3 ES demuxer variants look quite idiotic to me, here
the demuxer format seems to have been misused to identify the codec -
for which we have sh->format after all.