[Ffmpeg-devel] closed captioning bug?

Michael Niedermayer michaelni
Fri Apr 21 20:43:07 CEST 2006


Hi

On Fri, Apr 21, 2006 at 01:26:09PM -0400, Cyrus A wrote:
> Closed captioning bug report:
> 
> kernel - 2.6.15-1.2054_FC5
> processor - AMD 64 X2 3800
> ffmpeg version - cvs from April 21, 2006
> bttv: Winfast 2000 Deluxe (seems to be in perfect working order)
> 
> It seems there is a but with closed captioning when using ffmpeg on 
> x86_64 architecture. The captioning I recorded (using ntsc-cc and 
> zvbi-ntsc-cc)  is garbled... it's just as if every other letter or 
> sometimes groups of letters are removed. Here is an example where I 
> started ntsc-cc with tvtime, then turned on ffmpeg:
> 
> HUNDREDS OF DEMONSTRATORS CAME
> OUT TO DENOUNCE CHINA'S
> COMMUNIST GOVERNMENT AND THE BAN
> OF FALUN GONG UNIT.
> >WELL THE WOMA W SCREENED            <------------ ffmpeg turned on
> AT PSIDENT HU THE WTE
> HOEYESTERY  DUEN COT
> IS AERNO BUT T CORC AN
> RLIER CNN POR, SHE H NOT
> BE CHAED WITH TEANG
> FOREIGN OFFICIAL
> IS WASNFORTIE GOT FROM
> E HER ATTNEY.
> 
> The funny thing is, I tried several combinations of programs that use 
> /dev/vbi0 in some way and *sometimes* the caps work well. Ffmpeg seems 
> to be the weak link that "breaks" the captions. Here is my evidence:
> 
> zvbi-ntsc-cc by itself:  CAPTIONS OK
> tvtime with ntsc-cc : CAPTIONS OK
> tvtime with zvbi-ntsc-cc: CAPTIONS OK
> tvtime with ffmpeg with ntsc-cc: CAPTIONS OK
> ffmpeg with zvbi-ntsc-cc: CAPTIONS GARBLED
> ffmpeg with ntsc-cc: CAPTIONS VERY GARBLED
> 
> NOTE: zvbi seems to perform better than ntsc-cc when each is run alone 
> with ffmpeg
> 
> Here is my ffmpeg command:
> 
> [cyrus at localhost ~]$ /home/cyrus/ffmpeg/ffmpeg -ad /dev/audio -vd 
> /dev/video0 -s 320x256 -y -r ntsc /home/cyrus/test.mpg
> FFmpeg version CVS, Copyright (c) 2000-2004 Fabrice Bellard
>  configuration:  --enable-mp3lame --cpu=x86_64
>  libavutil version: 49.0.0
>  libavcodec version: 51.9.0
>  libavformat version: 50.4.0
>  built on Apr 21 2006 12:28:44, gcc: 4.1.0 20060304 (Red Hat 4.1.0-3)
> Input #0, video4linux, from '':
>  Duration: N/A, bitrate: N/A
>  Stream #0.0, 29.97 fps(r): Video: rawvideo, yuv420p, 320x256, 29461 kb/s
> Input #1, audio_device, from '':
>  Duration: N/A, bitrate: N/A
>  Stream #1.0: Audio: pcm_s16le, 44100 Hz, mono, 705 kb/s
> Output #0, mpeg, to '/home/cyrus/test.mpg':
>  Stream #0.0, 29.97 fps(c): Video: mpeg1video, yuv420p, 320x256, 
> q=2-31, 200 kb/s
>  Stream #0.1: Audio: mp2, 44100 Hz, mono, 64 kb/s
> Stream mapping:
>  Stream #0.0 -> #0.0
>  Stream #1.0 -> #0.1
> Press [q] to stop encoding
> [mpeg1video @ 0x8d0590]warning, clipping 1 dct coefficients to -255..255
> frame= 1488 q=12.7 Lsize=    1894kB time=49.5 bitrate= 313.4kbits/s
> video:304kB audio:387kB global headers:0kB muxing overhead 174.221079%
> 
> NOTE: It doesn't seem to matter which encoding scheme I'm using. mpeg1, 
> mpeg4, mp2, mp3... they all show the same behavior.
> 
> Any help would be greatly appreciated.

ok, ive not the faintest idea whats wrong but does chaning the
resolution / encoding to /dev/null using -vcodec copy help?

btw, are there any distortions in the video vissible?
maybe the diskaccess for encoding is causing some buffers of the
capture hw to overrun in that case hdparm / pci settings
might have some effect

[...]

-- 
Michael

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is





More information about the ffmpeg-devel mailing list