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 ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
