Extracted CC Problems

[slk001]

I am using VSRip to extract CC from an episodic DVD. The CC's are extracted from each 40min episode separately. The resulting CC's are always in perfect sync from the beginning to the first commercial break (there is no commercial, just a fade to black for a second or two, then back to the program). After the commercial break, the CC's have slipped sync (captions appear up to 2.5 secs before spoken text). The other commercial breaks also "take away" seconds from my perfect sync goal.

What I believe is happening (and either McPoodle or Gabest can hopefully address) is that during a commercial break, closed captions are NOT placed in the USER DATA field of the video stream, so instead of "8080" there is "0000". Since all CC data is "odd-parity" based, a "0000" would be seen as invalid data, and so maybe discarded. If it is discarded, then the timing of the subsequenct captions would slip as I have discribed, since I'm assuming that McPoodle gets his timing from the amount of data and not the original MPEG file (every two bytes is a video frame). I ran the captured **.bin file thru a parity checker that I wrote to see if there were any "even-parity" anomalies. There were none - everything was correctly "odd-parity". This leads me to believe that VSRip is discarding invalid closed caption data. Either that, or something else more sinister is happening! I should note, that the original captions on the DVD are in perfect sync.

What I'm having to do, is cut the CC.TXT files segments between these commercial breaks, and manually adjusting them to the correct timing, then placing them back into the origial CC.TXT file. If discarding is indeed taking place, then would it be possible to replace the invalid captions with a "8080" instead?

[mpucoder]

What is more likely is that there is NO user data during the commercial break. But timing information should not rely on a steady stream of data, but rather on one of the many timecodes present in the NavPack.

[slk001]

Correct. NO user data would be "0000" (probably). Since I use VOBSUB2SCC to convert the .cc.raw to .scc, where do you get the timing info?

Because a MPG file with USER DATA (CC DATA) in the odd fields can be cut and pasted together and still retain proper sync (since they depend only on their position in the MPG file for proper display - they are actually part of the MPG file), using all the data can be used for timing (but you still can't drop/discard any).

[mpucoder]

And that is the basic problem with raw files. I've been looking at McPoodle's site and it looks like every method of converting DVD CC to SCC format depends on raw data. The problem is it is perfectly acceptable to omit the user data whenever there is no CC for the GOP. What is needed is a tool to extract the CC from DVD/mpeg straight to a text format with timecodes, eg scc format. Either that or a program to extract to raw that fills in missing user data based on the number of display fields in the GOP (not trivial, which is why there is no program currently)

[jeanl]

mpucoder, out of curiosity, why do you say that

a program to extract to raw that fills in missing user data based on the number of display fields in the GOP

is not trivial? Do you mean it's not trivial to find out the number of fields in the GOP? (I thought it was not that hard)...
jeanl

[slk001]

mpucoder, out of curiosity, why do you say that

is not trivial? Do you mean it's not trivial to find out the number of fields in the GOP? (I thought it was not that hard)...
jeanl


I have the same question. AFAIK, the length of a GOP is irrelavent, because the USER DATA is stored in the individual FIELDS of the video. I thought that it would be as easy (?) as finding a specific header type, offsetting to the USER DATA position, recording the data to a file, then find the NEXT header and repeat. Repeat this until EOF is encountered.

[mpucoder]

OK, not that difficult, either, but probably twice the current parsing code.
The CC data is stored in a user data header for each GOP, so to account for missing user data one needs to know the number of fields in the GOP.
And nothing in mpeg is at fixed offsets, one needs to parse looking for the start code prefix (00 00 01) and then process according to the code.

[jeanl]

And nothing in mpeg is at fixed offsets, one needs to parse looking for the start code prefix (00 00 01) and then process according to the code.
Yes, that's part of the fun :D :D! That's what DVDSubEdit does to detect CC by the way... (shameless plug!)
jeanl

[McPoodle]

Hi, sorry to come in so late.

I need to work on this problem. What complicates things is that the number of captions in a USER DATA packet is not necessarily equal to the GOP size, but rather to the number of frames displayed. With 3:2 pulldown, this means that a 12-frame GOP translates into a 15-frame USER DATA packet.

When the user data is not there, I need to read the Top Field First and Repeat First Field data to work out how many frames are actually being displayed for the GOP. I've just started incorporating this into my CC_MUX tool, but it looks like SCC2RAW (and General Parser, and VSRip) will need it as well.

Either that, or yes, I'll have to come up with a way to go straight from MPEG to SCC by getting the timecodes from the NavPacks.

--McPoodle

[jeanl]

Getting the time code from the navpack is way easier than trying to figure out how many fields/frames you have per gop. The time code is right there!! You could use the SRC at the top of the navpack, or the start PTS, or even the elapsed time from the first I-frame (but I wouldn't trust that)....
jeanl

[mpucoder]

The most reliable timestamp for the first GOP (remember, there can be more than one GOP per VOBU) is vobu_s_ptm (offset 0x039 of NAV). However, if there is a second GOP you either determine the duration of the previous GOP by parsing and counting flags, or get the timestamp from the GOP itself.

Getting the timestamp from the GOP itself would work for all GOPs, so would require less code if it were the only method of establishing the time.

Here's the trick: Rather than look at the PTS, which needs to be adjusted by the Temporal Sequence Number of the I picture AND the rff flags of any lower numbered pictures, use DTS and add one frame to it.

No matter what you use, you still need to account for the resetting of the clock at vob joints. For this you keep a "base value" for the current vob. When the VobID changes add (vob_v_e_ptm - vob_v_s_ptm) (NAV_PK offsets 0x437 and 0x433 respectively) from the previous vob to the base value.
The initial value of the base value can be used to account for the video delay, so it should be -vobu_s_ptm of the very first vob.

I have a question about scc files and the timecode - does the timecode refer to the first 2 bytes of the CC data, or the last? The reason I ask is that a device I have for inserting CC into analog wants the display time of the caption and computes how far back it needs to start the insertion. (plus I intend to add scc support to MuxMan)

[jeanl]

Thanks for this info mpucoder, I hadn't thought of using the DTS, that's a nice trick.
jeanl

[McPoodle]

First of all, I threw together a fast update to CCExtract for General Parser that adds the ability to detect GOPs without user data, calculate the displayed GOP size, and output that many 8080 pairs.

The file can be downloaded from http://www.geocities.com/mcpoodle43/SCC_TOOLS/CCExtract.bdl, and belongs in the directory C:\Program Files\General Parser\source\MPEG\.

I haven't switched over from raw to SCC output just yet because my tools support six different MPEG caption formats (and all but DVD are frame-based instead of GOP-based), and I need to re-work the logic for all of them.

Second, the timecode in the SCC file does refer to the first byte pair.