[FFmpeg-devel,FFmpeg-cvslog] lavfi: make filter_frame non-recursive.

On Sun, Dec 18, 2016 at 10:49:36AM +0100, Nicolas George wrote:
> ffmpeg | branch: master | Nicolas George <george@nsup.org> | Sun Jan  3 15:44:42 2016 +0100| [02aa0701ae0dc2def8db640c9e3c06dc1b5de70c] | committer: Nicolas George
> 
> lavfi: make filter_frame non-recursive.
> 
> A lot of changes happen at the same time:
> 
> - Add a framequeue fifo to AVFilterLink.
> 
> - split AVFilterLink.status into status_in and status_out: requires
>   changes to the few filters and programs that use it directly
>   (f_interleave, split, filtfmts).
> 
> - Add a field ready to AVFilterContext, marking when the filter is ready
>   and its activation priority.
> 
> - Add flags to mark blocked links.
> 
> - Change ff_filter_frame() to enqueue the frame.
> 
> - Change all filtering functions to update the ready field and the
>   blocked flags.
> 
> - Update ff_filter_graph_run_once() to use the ready field.
> 
> - buffersrc: always push the frame immediately.
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=02aa0701ae0dc2def8db640c9e3c06dc1b5de70c
> ---

i dont know if this is a bug or just somethig that by sheer bad luck
becomes vissible after this but
./ffmpeg -i cvid/dday.mov -vframes 30  -vcodec huffyuv -y -acodec pcm_s16le out3b.avi ; md5sum out3b.avi
gives different outputs from time to time
needs threads on the encoder side, huffyuv, vframes (audio codec irrelevant)

difference in output files looks like this:
valgrind shows nothing (but difference occurs under valgrind)
should be here:
http://samples.ffmpeg.org/V-codecs/CVID/grayscale/dday.mov




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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin

Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit :
> i dont know if this is a bug or just somethig that by sheer bad luck
> becomes vissible after this but
> ./ffmpeg -i cvid/dday.mov -vframes 30  -vcodec huffyuv -y -acodec pcm_s16le out3b.avi ; md5sum out3b.avi
> gives different outputs from time to time
> needs threads on the encoder side, huffyuv, vframes (audio codec irrelevant)
> 
> difference in output files looks like this:
> valgrind shows nothing (but difference occurs under valgrind)
> should be here:
> http://samples.ffmpeg.org/V-codecs/CVID/grayscale/dday.mov

I know there are a few glitches that came through. I have started
working on fixing the worst one, it requires making buffersink aware of
EOF one step earlier.

As for this one and the one you posted a few minutes ago: -vframes with
audio frames too is highly dependant on details of the filters
scheduling, and can change slightly under perfectly normal
circumstances, starting with threading.

I will keep your mails near at hand and look if they show something
worrying. Thanks for testing.

Regards,

On Mon, Dec 19, 2016 at 11:56:27PM +0100, Nicolas George wrote:
> Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > i dont know if this is a bug or just somethig that by sheer bad luck
> > becomes vissible after this but
> > ./ffmpeg -i cvid/dday.mov -vframes 30  -vcodec huffyuv -y -acodec pcm_s16le out3b.avi ; md5sum out3b.avi
> > gives different outputs from time to time
> > needs threads on the encoder side, huffyuv, vframes (audio codec irrelevant)
> > 
> > difference in output files looks like this:
> > valgrind shows nothing (but difference occurs under valgrind)
> > should be here:
> > http://samples.ffmpeg.org/V-codecs/CVID/grayscale/dday.mov
> 
> I know there are a few glitches that came through. I have started
> working on fixing the worst one, it requires making buffersink aware of
> EOF one step earlier.
> 

> As for this one and the one you posted a few minutes ago: -vframes with
> audio frames too is highly dependant on details of the filters
> scheduling, and can change slightly under perfectly normal
> circumstances, starting with threading.

heres another similar issue
./ffmpeg -i ~/tickets/860/jpeg2000.mov -vframes 3  -vcodec huffyuv -y test.avi

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket860/jpeg2000.mov

[...]

On Tue, Dec 20, 2016 at 12:33:41AM +0100, Michael Niedermayer wrote:
> On Mon, Dec 19, 2016 at 11:56:27PM +0100, Nicolas George wrote:
> > Le nonidi 29 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > > i dont know if this is a bug or just somethig that by sheer bad luck
> > > becomes vissible after this but
> > > ./ffmpeg -i cvid/dday.mov -vframes 30  -vcodec huffyuv -y -acodec pcm_s16le out3b.avi ; md5sum out3b.avi
> > > gives different outputs from time to time
> > > needs threads on the encoder side, huffyuv, vframes (audio codec irrelevant)
> > > 
> > > difference in output files looks like this:
> > > valgrind shows nothing (but difference occurs under valgrind)
> > > should be here:
> > > http://samples.ffmpeg.org/V-codecs/CVID/grayscale/dday.mov
> > 
> > I know there are a few glitches that came through. I have started
> > working on fixing the worst one, it requires making buffersink aware of
> > EOF one step earlier.
> > 
> 
> > As for this one and the one you posted a few minutes ago: -vframes with
> > audio frames too is highly dependant on details of the filters
> > scheduling, and can change slightly under perfectly normal
> > circumstances, starting with threading.
> 
> heres another similar issue
> ./ffmpeg -i ~/tickets/860/jpeg2000.mov -vframes 3  -vcodec huffyuv -y test.avi
> 
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket860/jpeg2000.mov

(to clarify, the output of this one changes here between runs)

can some bitexact flag be used to eliminate these (admitably) rare
cases ?


[...]

Le decadi 30 frimaire, an CCXXV, Michael Niedermayer a écrit :
> > ./ffmpeg -i ~/tickets/860/jpeg2000.mov -vframes 3  -vcodec huffyuv -y test.avi

> can some bitexact flag be used to eliminate these (admitably) rare
> cases ?

The obvious answer would be: use -t instead of -vframes, it is already
bit-exact.

To make -vrames bit-exact, it would require ordering the frames in the
various streams by timestamp, like you did to make -shortest work. I do
not think it is worth it: -t is good.

Regards,