Message ID | 20161219224740.GC27739@nb4 |
---|---|
State | Not Applicable |
Headers | show |
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,
--- A 2016-12-19 23:36:43.297001535 +0100 +++ B 2016-12-19 23:36:47.605001627 +0100 @@ -50,9 +50,7 @@ 0, 16, 16, 1, 54316, 0xdca6a02a 1, 18728, 18728, 1024, 2048, 0xf24df16c 0, 17, 17, 1, 55204, 0xa93a73e6 -1, 19752, 19752, 1024, 2048, 0x27c11d5c 0, 18, 18, 1, 54872, 0x8b01d9b0 -1, 20776, 20776, 1024, 2048, 0x77e00ab9 0, 19, 19, 1, 54544, 0x752b168f 0, 20, 20, 1, 58916, 0x1596d7cf 0, 21, 21, 1, 53868, 0x0f286854