Rework TV Graphbuilding CC/Post Process (4 Viewers)
- Thread starter Sebastiii
- Start date
- November 11, 2007
- 17
- 11
- Home Country
-
Canada
I talked with CCExtractor guy today he said CCExtractor only supports EIA-608 and it can dump EIA-708 information which I can see that it's there but it does not export it to anything yet and we need a windows guy to build a filter. He is more than happy to assist with CC stuff to someone who can do the heavy lifting with the windows part (DirectShow Filter) (xVFFx and I are willing to donate $500.00 for this work) to anyone who can do this.
Thanks for looking into this as we have several deaf people who really like to see this solution.
FiR3Ma5t3r
Thanks for looking into this as we have several deaf people who really like to see this solution.
FiR3Ma5t3r
- November 11, 2007
- 17
- 11
- Home Country
-
Canada
Copy and Paste from somewhere:
To support EIA-708, you would need to write your own EIA-708-to-bitmap decoder filter. Decoding EIA-708 is harder than decoding EIA-608 but your biggest problem would be feeding the video renderer a bitmap with an alpha channel. It is much easier to extract the EIA-708 data out of the graph and decode it to colorkeyed bitmaps to feed the VMR through the IVMRAlphaBitmap[9] interface (however, this way you can not have semi-transparencies). If you don't want the captions to be scaled with the video, you will need to write a custom allocator/presenter or a mixer filter that dynamically changes the media type's rectangle.
Most ATSC streams also carried an EIA-608 substream alongside the preferred EIA-708 one for backward compatibility. The EIA-608 data is simply packaged differently but, if you write a simple repackaging filter, you can feed it to the stock Line21Decoder.
Hope this helps
FiR3Ma5t3r
To support EIA-708, you would need to write your own EIA-708-to-bitmap decoder filter. Decoding EIA-708 is harder than decoding EIA-608 but your biggest problem would be feeding the video renderer a bitmap with an alpha channel. It is much easier to extract the EIA-708 data out of the graph and decode it to colorkeyed bitmaps to feed the VMR through the IVMRAlphaBitmap[9] interface (however, this way you can not have semi-transparencies). If you don't want the captions to be scaled with the video, you will need to write a custom allocator/presenter or a mixer filter that dynamically changes the media type's rectangle.
Most ATSC streams also carried an EIA-608 substream alongside the preferred EIA-708 one for backward compatibility. The EIA-608 data is simply packaged differently but, if you write a simple repackaging filter, you can feed it to the stock Line21Decoder.
Hope this helps
FiR3Ma5t3r
- November 11, 2007
- 17
- 11
- Home Country
-
Canada
Hi,
It's needed to work on filter, i manage to accept connection from h264 stream on Core CC Parser, but like i was supposed, it was not enough.
I think it's needed to implement the h264 analyse stream but it's out of my competence.
If anyone is interested, i have VS2010 compatible source for CoreCCParser
Thanks
Hi,
I have tested your 60 kb size cccp.ax and I managed to accept connection from H264 stream to your cccp.ax file so I assume you have edited cccp.ax?
Original cccp.ax is at 108kb and I was not able to pin it to h264 stream for a long time.
I think there is something you can do if I show you the EIA-708 code I got from someone yesterday?
Let me know
FiR3Ma5t3r
- Thread starter
- Moderator
- #45
Yes i have patch the code to accept h264 connection but after that no CC available, i think we need to add parser H264 into CCCP but i'm not a c++ guy too
Yep show the code it can be usefull
Yep show the code it can be usefull
- November 11, 2007
- 17
- 11
- Home Country
-
Canada
Yes i have patch the code to accept h264 connection but after that no CC available, i think we need to add parser H264 into CCCP but i'm not a c++ guy too
Yep show the code it can be usefull
I was told Mythtv has eia-708 Closed Caption working and that's where CCExtractor guy got his initial code from.
Here's the code
MythTV: cc708decoder.cpp Source File
--------------------------------------------------------------------------------------------------------------------------------------
Message from Zodiak:
I just wrote a very long PM to some tester, that I thought might be beneficial for the whole community...
Closed captioning is a data stream normally encoded in the analogue NTSC video signal (the notorious line 21). Again, it is part of the analogue picture, just not in the part of the screen, that's normally visible. Every field (half frame) carries 2 bytes of data. Although it may seem simple, the internal stucture of the resulting stream is quite complex. It may contain multiple channels of various kinds of data. It's not a trivial task even to extract CC text for a primary CC1, let alone take into account all the visual effects (e.g., color, text placement or special charcters). This is all part of a standard, that is publically available for a fee. Most modern tv sets just use a specialized microchip that can detect such data in the NTSC signal and use it to [optionaly] render CC, that is then mixed by the video hardware with actual picture.
In the digital video world it's a bit different. Although line 21 is just another video scanline, you cannot use standard MPEG2 encoding because it is lossy and will destroy the fine structure the tv needs to extract the 2 bytes from the analogue waveform. That's why the 2 bytes per field have to be carried via different means. In fact they are still carried in the video MPEG stream, although not in the video bits themselves but in so called user_data, that most video decoders usually ignore.
What cccp does is that it detects presence of such user_data in the video stream and extracts the byte pairs that are then fed to the Line 21 Decoder filter. The latter one analyzes the 2-byte stream and renders visual representation of the currently selected CC channel, which in turn is mixed with the actual picture (decoded in parallel by you favourite MPEG decoder) by either Overlay Mixer or VMR9. The resulting mixed video picture is then displayed on the monitor. This is how it normally works on computer.
Note that even if the videocard has a tvout it's still little different from what you can see on the monitor-- the CCs you see (pardon the pun) are part of the _visible_ tv picture, conveyed to the tv set via NTCS signal. The latter usually contains no data in the line 21.
What makes NS2K card unique is that it's smart enough to detect user_data in the MPEG video strem it renders, so it takes the 2 CC bytes and injects them into the line 21 of the NTSC signal it generates for the tv. The tv is then capable of using it as discussed above.
Now, what is "Convert to A53"? The thing is that there are several ways to encode CC in the user_data and the NS2K is capable of handling only one such format, particuarly the one specified in the ATSC A53 standard. Even if there is user_data carrying valid CC in the stream but in different format, the NS2K cannot interpret it and thus ignores it, leaving the line 21 empty. That's exactly why you cannot see CC on most channels if you feed the stream straight to the NS2K filter in the graph. If you inclide the cccp, however, and enable the abovementioned option, the cccp will convert all CC formats it's aware of (to be honest, there is only one so far ) to the A53, which makes NS2K feel good again.
Of course if you don't use Line 21 decoder and any video mixer in such graph, you will not see the CC's on the computer. There's nothing there that can render and display them-- all CC rendering and mixing is done in the TV set (NOT in the NS2K).
Last edited by zodiak on Thu Nov 11, 2004 1:45 pm, edited 1 time in total.
