[Ffmpeg-devel] vhook contaminating video stream bugwhen-deinterlace is used on flv streams

Scott Manley scott
Sat Mar 31 03:13:53 CEST 2007


Michael Niedermayer wrote:
> Hi
>
> On Fri, Mar 30, 2007 at 03:56:07PM -0800, Scott Manley wrote:
>   
>> V?ctor Paesa wrote:
>>     
>>> Hi,
>>>
>>> Please avoid top-posting, it makes hard to follow the history.
>>>
>>>  
>>>       
>>>> Sure -
>>>>
>>>> $ ffmpeg -i originals/junior.flv -deinterlace -vcodec mpeg4 -f mov
>>>> -acodec copy -vhook "/usr/lib64/vhook/drawtext.so -c #ffffff -f
>>>> resources/VAGRoundedStd-Bold.otf -t crazytext" junior-watermarked.mov
>>>> FFmpeg version SVN-r8548, Copyright (c) 2000-2007 Fabrice Bellard, et al.
>>>>  configuration: --cc=gcc4 --prefix=/usr --libdir=/usr/lib64
>>>> --mandir=/usr/share/man --incdir=/usr/include/ffmpeg
>>>> --extra-cflags=-fPIC --enable-libmp3lame --enable-libogg
>>>> --enable-libvorbis --enable-libfaad --enable-libgsm --enable-liba52
>>>> --enable-liba52bin --enable-libdts --enable-pp --enable-shared
>>>> --enable-gpl --disable-strip --enable-pthreads
>>>>  libavutil version: 49.4.0
>>>>  libavcodec version: 51.40.2
>>>>  libavformat version: 51.11.0
>>>>  built on Mar 30 2007 14:10:15, gcc: 4.1.0 20060515 (Red Hat 4.1.0-18)
>>>>
>>>> Seems stream 0 codec frame rate differs from container frame rate:
>>>> 1000.00 (1000/1) -> 24.00 (24/1)
>>>> Input #0, flv, from 'originals/junior.flv':
>>>>  Duration: 00:04:41.6, start: 0.000000, bitrate: 128 kb/s
>>>>  Stream #0.0: Video: flv, yuv420p, 400x222, 24.00 fps(r)
>>>>  Stream #0.1: Audio: mp3, 44100 Hz, mono, 128 kb/s
>>>> Output #0, mov, to 'junior-watermarked.mov':
>>>>  Stream #0.0: Video: mpeg4, yuv420p, 400x222, q=2-31, 200 kb/s, 24.00
>>>> fps(c)
>>>>  Stream #0.1: Audio: mp3, 44100 Hz, mono, 128 kb/s
>>>> Stream mapping:
>>>>  Stream #0.0 -> #0.0
>>>>  Stream #0.1 -> #0.1
>>>> Press [q] to stop encoding
>>>> [flv @ 0x2a95c30e70]run overflow at 15x13 i:0me=61.7 bitrate= 342.5kbits/s
>>>> [flv @ 0x2a95c30e70]Error at MB: 353
>>>> [flv @ 0x2a95c30e70]concealing 59 DC, 59 AC, 59 MV errors
>>>> [flv @ 0x2a95c30e70]slice end not reached but screenspace end (23 left
>>>> 6F0160, score= -2424)
>>>> [flv @ 0x2a95c30e70]concealing 350 DC, 350 AC, 350 MV errors
>>>> frame= 6759 fps=334 q=15.7 Lsize=   11578kB time=281.6 bitrate=
>>>> 336.8kbits/s
>>>> video:7015kB audio:4394kB global headers:0kB muxing overhead 1.480154%
>>>>    
>>>>         
>>> There are errors, and the original reported total bitrate of 128kb/s
>>> should be larger that the reported audio bitrate of 128kb/s, hence
>>> your input file is corrupted (or not properly recognized by ffmpeg).
>>>
>>> So it is not a good test bed for the kind of bug you report.
>>> Try to reproduce it with a non corrupted input file.
>>>
>>> Notice anyway, that if you watermark then you are adding detail to your
>>> original movie, and hence you need to specify for your output a higher
>>> video bitrate that your input has, to keep the same quality.
>>>  
>>>       
>> ok so I don't have a way to produce this file so getting a fixed version 
>> may not be possible, but I can address the brokenness by only encoding 
>> the first 10 seconds, and at a higher bitrate to address your concern 
>> regarding a lack of bits on the output encoding - the corruption still 
>> happens despite these changes.
>>     
>
> what happens if you reencode this to a lossless format like ffv1/huffyuv
> and then in a second pass do the deint vhook stuff?
>
>   
It all works fine, no motion smearing, so it's purely confined to 
decoding flv sources, but I've got plenty of other flv files which don't 
exhibit this issue.

actually with some embarrasment I must report that my original assertion 
that -deinterlace made a difference is completely bogus, I think my use 
of -deinterlace in some of my test command lines was merely stopping 
ffmpeg from copying the flv data instead. So ignore that as having 
anything to do with it.

I don't know if anyone's actually tried and reporoduced the output, but 
it appears to me that pixels from the output buffer are having motion 
vectors applied to them and so any motion smears the watermark across 
the action.






More information about the ffmpeg-devel mailing list