An MPEG-2 PS format/layout question regarding GOP headers...

[jdiner]

I am hoping one of the MPEG-2 encoder wizards here might be able to answer a short and hopefully easy question on the structure of a GOP within an MPEG-2 PS file.

I am working over adding CC data to the MPEG-2/VOB files extracted and processed by TyTool. I have gotten it working with only a few problems but I have run into a TIVO source-specific issue with the super-long GOP sizes. (Often have GOPs containing 60+ picture headers in a single GOP.

The CC data structure that is part of MPEG-2 is size limited and only allows for a size of 31 frames/GOP with 1 CC byte-pair entry per frame. (A simple structure but odd that it is size limited in that way when so much of the MPEG-2 format is remarkably flexible.)

Anyway one of the main goals is to re-encode as little as possible to maintain the visual quality of the material. So I do not want to manually break the GOPs up by turning a P-frame into an I-frame via re-encoding and all that is needed for that if at all possible.

I found a reference on the web that indicated that it is "legal" to follow a GOP header with a P-frame as it can be considered an "entry point". But my MPEG-2 docs say nothing about CC at all and nothing about legal locations for a GOP structure. I have been gearing up to test the theory but thought before I got to invested I would ask those much more familiar with the construction of an MPEG-2 Elementart Stream than I am.

Anyway if any of you have any ideas then please post your answers.

Many Thanks,
--jdiner

[video]

line21 CC is an NTSC specific issue - and afaik it resides in a private stream within the DVD PS/digital broadcast TS - and normally playable only with TVsets supporting closed captions. The best way i feel to extract CC as srt with vsrip - edit srt a lot (spelling issues, fullcaps letters, etc,) and author as a legal dvd subtitle..

Regarding GOPs a GOP should allwys start with an I picture.

[ac-chan123]

@jdiner:
here are some links for MPEG and DVB:
-http://www.chiariglione.org/mpeg/ the page of the man how has established the MPEG
-http://www.itscj.ipsj.or.jp/sc29/ this is the page of the MPEG and JPEG Group
-http://www.broadcastpapers.com/
-http://www.etsi.org/home2.htm all the european telcom standards for free after a registration with your email addy.
-http://www.bjpace.com.cn/data/tec/ DVB docs

for USA TV standards see http://www.atsc.org/ .

[jdiner]

Originally posted by video
Regarding GOPs a GOP should allwys start with an I picture.
Good enough. I was looking to see if there were any other options, seems like there are not. Ah well. Just means it has to be dealt with in a more standard manor.

Thanks,
--jdiner

[jdiner]

BTW, I have CC working. There are just a few tivo related options with the generation of the MPEG-2 video ES data itself that I was looking to fill in the gaps in my knowledge a bit.

To try to be a bit more clear, given a PM I received here is a bit more on what I really meant. Sorry to have perhaps been a bit unclear.

----------------------------

As for the Closed Caption (CC) portion. It isn't in the MPEG-2 ISO 13818 docs that I have or have ever seen. I have guesses as to why that is so but no actual facts.

The CC header is implemented as user data (00 00 01 B2) directly following a GOP header structure with a 4-byte flag after it (43 43 01 F8). Then you get 1 packed flag-byte with 4 entries in it. One of them is 4 bits which constitute the number of picture structures in the GOP. This is followed by 6 bytes for each frame/picture that contain the Field1 and Field2 CC data.

For a standard DVD this is fine as with a max of 31 that covers the 15 and 18 that are the standard GOP length. However for what I have to deal with that standard for GOP length is completely ignored.

Most of my testing has shown that hardware and software players will support the mismatch well enough, a few don't work properly. I.e. a GOP of 60 frames with 31 in the CC structure works, but often doesn't provide "enough" space for the remaining required CC byte-pairs to be added and used.

So I am looking for alternatives if there are any. If not, well then it will be dealt with in the more standard way.

The last 2 ideas I could come up with was 1- to add "more" GOP headers, and 2- to re-encode at various P-frames to make I-frames out of them shortening the GOPs to 15/18 or less everytime. But as mentioned one of the goals is to re-encode as little as possible given the lossy nature of that encoding.

Thanks,
--jdiner

[jdiner]

Originally posted by ac-chan123
@jdiner:
here are some links for MPEG and DVB:
-http://www.chiariglione.org/mpeg/ the page of the man how has established the MPEG
-http://www.itscj.ipsj.or.jp/sc29/ this is the page of the MPEG and JPEG Group
-http://www.broadcastpapers.com/
-http://www.etsi.org/home2.htm all the european telcom standards for free after a registration with your email addy.
-http://www.bjpace.com.cn/data/tec/ DVB docs

for USA TV standards see http://www.atsc.org/ .
I have seen a number of those but a couple are new to me. Thanks for the info.

--jdiner

[mpucoder]

Have you tried adding another user_data header with the additional CC data?

[ac-chan123]

I have nothing found about CC(close caption) in DVB only Subtitles.
ETSI EN 300 743 V1.2.1 (2002-10)

[jdiner]

Originally posted by mpucoder
Have you tried adding another user_data header with the additional CC data?
Ah the man himself. It was your break down of the CC header that I have been using.

I have tried many combinations of locations and placement. I put it after the I-Frame and it worked in only 1 of 7 players. That one, a really cheap Mintek 1500, seems to "find" it in any location.

The rest of the players require it to be located immediately after, i.e. as an extension to, the GOP header itself.

I had not however thought about putting several of them in at that one location. I am testing that idea now. I will post the results in a few minutes.

--jdiner

[jdiner]

No joy. Both the hardware and software DVD players have the same result. When the second header is encountered it is replacing the first and they play the second header only. It is not appended just replaced.

But it was worth trying out.

--jdiner

[mpucoder]

Maybe it would work if the user_data was inserted after the previous data had been used up, ie 31 frames later. Just an idea - I have no clue either.

[jdiner]

Originally posted by mpucoder
Maybe it would work if the user_data was inserted after the previous data had been used up, ie 31 frames later. Just an idea - I have no clue either.
Tried that. I was hoping it would work.

On the players that expect it in the real location nothing comes from the second header. In the player that would look anywhere for it, it almost seems to work. There were unexpected gaps in the playback of the CC stream.

Anyway, I appriciate the ideas and the help. I was hoping something would pan out but it has not appeared to, so I will just have to go back to the drawing board.

If anyone has any further ideas please do not hesitate to bring them up.

--jdiner