[FFmpeg-devel] [PATCH 4/4] lavfi: make filter_frame non-recursive.

[Nicolas George]

Le duodi 2 brumaire, an CCXXV, Michael Niedermayer a écrit :
> breaks (no video window opens)
> ./ffplay bgc.sub.dub.ogm
> google points to: http://samples.mplayerhq.hu/ogg/bgc.sub.dub.ogm

Works for me here.

ffplay version N-81631-gb453521 Copyright (c) 2003-2016 the FFmpeg developers
  built with gcc 6.1.1 (Debian 6.1.1-11) 20160802
  configuration: --enable-shared --disable-static --enable-gpl --enable-libx264 --enable-libopus --enable-libass --enable-libfreetype --enable-opengl --assert-level=2
  libavutil      55. 29.100 / 55. 33.100
  libavcodec     57. 55.101 / 57. 63.103
  libavformat    57. 48.103 / 57. 53.100
  libavdevice    57.  0.102 / 57.  0.103
  libavfilter     6. 61.100 /  6. 64.100
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  2.100
  libpostproc    54.  0.100 / 54.  0.100
[ogg @ 0x2af08c000920] Headers mismatch for stream 1: expected 3 received 2.
[ogg @ 0x2af08c000920] Headers mismatch for stream 2: expected 3 received 2.
Input #0, ogg, from '/home/cigaes/tmp/samples/bgc.sub.dub.ogm':
  Duration: 00:01:00.01, start: 0.000000, bitrate: 1620 kb/s
    Stream #0:0(Bubblegum Crash 1: Illegal Army): Video: mpeg4 (DX50 / 0x30355844), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 23.98 fps, 23.98 tbr, 23.98 tbn, 30k tbc
    Stream #0:1(English): Audio: vorbis, 48000 Hz, stereo, fltp, 4294967 kb/s
    Stream #0:2(Japanese): Audio: vorbis, 48000 Hz, stereo, fltp, 4294967 kb/s
    Stream #0:3(English): Subtitle: text
  19.90 A-V:  0.083 fd=  45 aq=  765KB vq= 5744KB sq=    0B f=158/158   

> i also have a file that with
> -af apad -shortest out.nut results in
> [output stream 0:1 @ 0x2b374c0] 100 buffers queued in output stream 0:1, something may be wrong.
> [output stream 0:1 @ 0x2b374c0] 1000 buffers queued in output stream 0:1, something may be wrong.
> [output stream 0:1 @ 0x2b374c0] 10000 buffers queued in output stream 0:1, something may be wrong.
> [output stream 0:1 @ 0x2b374c0] 100000 buffers queued in output stream 0:1, something may be wrong.
> [output stream 0:1 @ 0x2b374c0] 1000000 buffers queued in output stream 0:1, something may be wrong.
> Killed
> 
> while working before,  i cant share that file though

Can you share what makes it special, though, so I can try and reproduce the
issue? The issue should be triggered by the order and timing of the frames,
not their contents.

(This is one of the cases where Stefano's text demuxer would come handy.)

> also several files seem to improve in accuracy in their stream
> durations with vframes
> for example
> ./ffmpeg -i bbb-360p24.i420.lossless.drc.ogg.fixed.ogg+bbb-24fps.flac.via-ffmpeg.ogg -vframes 7 -f framecrc -
> has a audio frame after the patch but is missing that before
> (google has hits for the filename, i can upload it though if needed)
> 
> maybe something should be added to the fate tests as this seems not to
> be covered, the file is too big though
> 
> the output for bgc.sub.dub.ogm with  -vframes 3 -f framecrc -
> is also significnatly different

I have always said that using -vframes with several streams is not
supported. Its exact result depends on undocumented and unguaranteed
properties of the scheduling, both inside libavfilter and ffmpeg.c, or even
caused by input or users. We could enhance that, the change would take place
in ffmpeg.c:need_output().

I am glad you say this change improves the accuracy. A better scheduling is
one of the purposes. But even if it did worsen it in some cases, I think it
would be acceptable, as long as it is only a bit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161023/a95ed1e1/attachment.sig>