[mythtv] Ticket #11899: Garbled CCs on some stations

faginbagin mythtv at hbuus.com
Tue Oct 15 05:05:42 UTC 2013


On 10/12/2013 5:19 PM, MythTV wrote:
> #11899: Garbled CCs on some stations
> -----------------------------------+----------------------------
>   Reporter:  faginbagin <mythtv@…>  |          Owner:  stichnot
>       Type:  Bug Report - General   |         Status:  accepted
>   Priority:  minor                  |      Milestone:  unknown
> Component:  MythTV - Captions      |        Version:  0.27-fixes
>   Severity:  medium                 |     Resolution:
>   Keywords:                         |  Ticket locked:  0
> -----------------------------------+----------------------------
> 
> Comment (by stichnot):
> 
>   A few observations so far.
> 
>   1. Mostly (but not entirely), the garbling is because roughly half the
>   characters aren't being displayed.
> 
>   2. xine shows almost exactly the same garbled captions as MythTV.
> 
>   3. As noted, ccextractor (version 0.65 in my case) produces very clean
>   captions.
> 
>   4. If you combine the captions from fields 0 and 1 by setting field=0 at
>   the beginning of CC608Decoder::FormatCCField(), most (but not all) of the
>   caption characters are correctly displayed.
> 
>   Especially in light of the xine behavior, I suspect an upstream ffmpeg
>   problem, though it's also possible that it's a problem in our
>   avformatdecoder.cpp.

Thanks for looking at this. Some questions:

Where is the "upstream" version of ffmpeg used by xine and mythtv? When I look at:
https://github.com/FFmpeg/FFmpeg/blob/release/1.2/libavcodec/mpeg12.c
http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=libavcodec/mpeg12.c;hb=refs/heads/release/1.2
these versions of mpeg12.c don't have any reference to the data members tmp_atsc_cc_len or tmp_scte_cc_len, which leads me to believe I'm not looking at the right upstream repositories, at least when it comes to CC support in ffmpeg. I found this commit:
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=33d699a4e73d5281b2cfcd0fa355c0d80241dd23
which seems to match the one referenced in this mythtv commit:
https://github.com/MythTV/mythtv/commit/9c728cb8f19100e9976196709b8258480e72d30b
This leads me to believe videolan is the source of mythtv's ffmpeg code, but videolan must do something different when it comes to CC processing.

I've skimmed at the mpeg12.c code and wondered about the way it copies CC data from the source video stream into temp buffers that are later copied to other buffers by mpegvideo.c and then handled by avformatdecoder.cpp. I suspect the mpeg12.c code may be stripping out needed info from the control bytes. I haven't looked "super" close, but maybe its time to do so. It would help to know where that code came from.

Thanks,
Helen


More information about the mythtv-dev mailing list