[FFmpeg-devel] [PATCH]Add RoQ regression tests - stddev improved

[Michael Niedermayer]

On Sat, Nov 01, 2008 at 12:26:18PM -0700, Mike Melanson wrote:
> Vitor Sessak wrote:
> > Mike Melanson wrote:
> >> Vitor Sessak wrote:
> >>> Mike Melanson wrote:
> >>>> Carl Eugen Hoyos wrote:
> >>>>> Hi!
> >>>>>
> >>>>> Vitor Sessak <vitor1001 <at> gmail.com> writes:
> >>>>>
> >>>>>>>> The patch increases the time of "make test" by about 30%. If you 
> >>>>>>>> tell me a
> >>>>>>>> reasonable amount, I'll change the test accordingly and apply.
> >>>>>>> 1-2%
> >>>>>>>
> >>>>>>> but it should be at least 2-3 frames
> >>>>>> Any news on this? Carl, if you are out of time, I don't mind sending 
> >>>>>> a new patch using the -vframes option...
> >>>>> I'm happy if you solve it: vframes has to be 15 at least, because (I 
> >>>>> think, did
> >>>>> not RTFS) decoder searches 15 frames for audio and fails if they are not
> >>>> Yes, 15 frames. Until such time I get arround to making the demuxer 
> >>>> smarter.
> >>> Do you think the following patch fix it?
> >> No. It will require a little more substantial rework. The scan approach 
> >> is completely wrong. The demuxer should just start splitting apart the 
> >> chunks and sending them to the streams, initializing the streams along 
> >> the way if not already done. My mistake was in believing that all the 
> >> streams had to be init'd when the file was first opened.
> > 
> > Are you sure it is not required? What if someone does
> > 
> > $ ffmpeg -i file.roq out.avi
> > 
> > The AVI muxer needs to know if there is an audio stream or not to write 
> > the header. If the RoQ demuxer only "finds" the audio stream at the 
> > tenth frame, how will FFmpeg do to write correctly the AVI header?
> 
> Don't know, but the MPEG demuxer somehow gets away with this method.

yes, streams can be initialized late, thats because the m in ffmpeg stands
for "magic" :)

seriously, ffmpeg just buffers frames a little if AVFMTCTX_NOHEADER is set.
So if one can create all streams at the begin that is prefered but if the
information isnt available libavformat will happily do the buffering magic
for the demuxer, duplicating that is not a good idea.

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/ffmpeg-devel/attachments/20081101/48be4b4d/attachment.pgp>