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

Michael Niedermayer michaelni
Sat Mar 31 02:39:10 CEST 2007


Hi

On Fri, Mar 30, 2007 at 05:13:53PM -0800, Scott Manley wrote:
> 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.

maybe someone should try valgrind

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

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070331/2bf36ce9/attachment.pgp>



More information about the ffmpeg-devel mailing list