Closed Captions ???

[Delphin]

I know how to do the standard menu selectable "Open Captions" that DVD's support (text fonts converted to graphics when authored and later overlaid by the DVD player based on a DVD menu).

I have also seen a number of commercial DVD's which support "Closed Captions" (captions which are digitally encoded into the video near the blanking interval and decoded by the television receiver).

I know that we are talking about TWO different sets of captions because some disks support BOTH and you can turn on both sets at the same time (which looks really strange as the one set and other set compete for space at the bottom of the screen).

My question is HOW ARE THE "CLOSED" CAPTIONS authored into the DVD???

Again, I understand the standard "OPEN" captions, but the encoded "CLOSED" captions have me stumped because they are normally encoded as a set of off-screen on-off (white-black) digital 'bits' in the last scan lines in the ‘blanking interval’ near the sync pulse in the video and I don't think this area gets encoded in a standard 720x480 D1 MPEG2 stream (unless they arbitrarily move the caption line to the last line of the encode and have the player move it back or something like that).

Does anyone definitely know how 'closed captioning' works in DVD's??? :confused: :confused: :confused:

[mpucoder]

The closed captions themselves reside as user data within the video elementary stream. Authoring programs import one or two files containing the preformatted CC data. In the case of Scenarist the files are call .scc files, and there are tools for extracting and creating .scc files at McPoodle's (http://www.geocities.com/mcpoodle43/SCC_TOOLS/DOCS/SCC_TOOLS.HTML) site.

[LocalH]

Correct, very few digital formats encode the non-visible lines, including line 21. The players generally take the metadata that mpucoder mentioned, and generate line 21 captions on the fly. This is also the way most, if not all, professional digital formats handle CC (especially broadcast formats such as DVCPRO, and distribution formats such as the encrypted MPEG-2 that distributors such as WB and Sony use, whether it be a standard satellite feed or the new "Pathfire" system where content is downloaded to a server and can be played back as needed by the station).

[Delphin]

The closed captions themselves reside as user data within the video elementary stream. Authoring programs import one or two files containing the preformatted CC data. In the case of Scenarist the files are call .scc files, and there are tools for extracting and creating .scc files at McPoodle's (http://www.geocities.com/mcpoodle43/SCC_TOOLS/DOCS/SCC_TOOLS.HTML) site.

Correct, very few digital formats encode the non-visible lines, including line 21. The players generally take the metadata that mpucoder mentioned, and generate line 21 captions on the fly.

Thanks! This was just the information I was looking for.

I had seen some references to this Mcpoodle in relation to Closed Captions but did not have the address of the web page.

The fact that it is encode into the stream a 'user data' bits makes perfect sense there I just could not find any references to this in the actual MPEG2 stream specs.

I am using the freeware DVDAUTHOR program, which seems to be a fairly capable but VERY POORLY DOCUMENTED piece of software. The SPUMUX program supplied with dvdauthor only seems to handle the bitmapped type of subs as far a I can tell, and CC subtitles are not mentioned at all.


I am a bit surprised that a simpler 'one click' solution doesn't exist for translating CC content to the standard DVD menu-selecable 'open captions', because, given the direct digital encoding of these into the 'user data' you mention, because I would think that extracting this digital data would be a more reliable and robust method of recreating subtitles than the 'OCR' approach of 'subrip' (at least where the CC subs are available and in the language of interest).

Still, with Mcpoodle's tools, it looks like CC data can be processed even by DVDAUTHOR (by muxing it into the MPEG2 stream manually with Mcpoodle's tools then editing the VTS header with IFOedit to reflect the presence of CC subs in the title set).

Have to give that a try.

Thanks again! :thanks:

[mpucoder]

Not to toot my own horn, but if you used MuxMan (also free) you would not have to correct the ifo's later as it detects CC.

CC isn't very popular, so not so many programs exist for handling it. It exists only in NTSC disks, so PAL programmers have little exposure to it. Translating CC to DVD subpictures requires 2 processes. First the CC data has to be converted into something more closely resembling a subtitle script, as CC is a jumble of 7-bit ASCII codes, with numerous escape sequences. Then, since subtitles in DVD are really subpictures, that script can be turned into a series of images and some form of instructions for the muliplexor as to where to insert each picture. Some authoring programs can take the text script and create the images themselves.

[Delphin]

Not to toot my own horn, but if you used MuxMan (also free) you would not have to correct the ifo's later as it detects CC.


Yes I have found several tools to manipulate, text based sub formats, and some of the DVDAUTHOR GUI's can translate these into the proper graphic fromat and add these to DVD layouts.

As far as your MuxMan development goes, thanks for undertaking this as I would love to see an alternative to DVDauthor and MPLEX as these streams just barely create compliant DVD's and don't yet offer 100% access to the features provided by the format.

I visited your site some time ago but, frankly, was turned off a little by all the 'members only' stuff and the 'cripple-ware' nature of the free version.

For features like CC muxing, I was not aware that this would work in the free version, and was so turned off by the whole 'cripple-ware' thing that I was not inclined to bother trying to figure out what WOULD and what WOULD NOT work.

I have had some experiences in the past where I paid for the 'full' version of software only to discover that it was still buggy 'beta-ware' and overall less useful than other software that was completely 'open-source' and free.

I don't mind paying for fully functional shareware, but [after my past experences] not at such an early stage of development.

I know you are not asking for a huge amount of money (far from it), but my past experiences still cause me to have to take a 'wait and see' approach.

Sorry.

I would love to participate in the early development of your software if you change your site policy, but respect your right to run things as you see fit.