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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
|
