Long GOP - DVD player comparison .

[drcl]

Will your DVD player play GOP of 132 for mpeg2 video?
I chose 132 because im fairly sure its the maximum for the GOP layer in the mpeg2 spec.

Mine is an LG 5063, and it does, I would assume all the 5000s and the 6000s do also.

[neuron2]

Originally posted by drcl
im fairly sure its the maximum for the GOP layer in the mpeg2 spec Where does it say that in the spec?

[drcl]

Oops, your right again; I think the GOP length restriction only applies to MPEG-1 sequences, but im sure I read it somewhere in an Mencoder guide(it said it applied to mpeg1/2/4).

So its an arbritrary number for MPEG-2 but it would still be interesting to see which players are capable.

[drcl]

Here's a link for one of the guides, i couldnt find the original but it looks almost the same.

http://www.lab.inf.uc3m.es/cgi-bin/man2html?fibmap_mplayer+1

search for "compliance"

[neuron2]

Actually, the maximum frames between keyframes is not the same thing as GOP length (GOPs can have multiple I frames).

[callmeace]

Is more than one I-Frame per GOP, compliant for DVD Mpeg-2 specifications?

[hank315]

Is more than one I-Frame per GOP, compliant for DVD Mpeg-2 specifications?AFAIK yes.

MPEG2 compliant max. GOP length: PAL 15, NTSC 18 (frame based), PAL 30, NTSC 36 (field based).
A lot of HW players can handle larger GOPS, most software players can handle movies with just one large GOP.
Advice: don't do it that way, just stick to the specs...

[Mug Funky]

long gops kinda suck for mpeg-2. i can't remember the technical reasons, but basically errors accumulate over time, and after about 50 frames, colours will start drifting toward greens and magentas (you'll be able to see this quite easily...).

long GOPs is more of an mpeg-4 thing, IMHO.

[callmeace]

I am confused whether an Iframe is the same as a Keyframe - I mean a different name for the same thing.

I know a Keyframe is what you can seek to.
I believe an Iframe is a frame that is encoded just from the source frame and not using information from frames before or after it (like P and B frames can do), so are only these Iframes seekable?

A lot of people seem to use the two terms, Iframe & Keyframe interchangibly, and so I dont know if they are the same. If any expert can tell me I appreciate it!

[neuron2]

You have to state what you mean by "seekable". For example, if you mean randomly decode a given *frame number*, not even I frames are seekable without preprocessing the file to generate an index. Once you have an index, any frame is seekable; you may have to decode some pictures before it, however, to get the reference frames that you need.

You can jump into a stream at an I frame and start decoding forward from there. In that sense, yes, an I frame is a key frame.

[callmeace]

Thanks for the info, I appreciate it.

I guess I didn't really know technically what I meant by seekable. You know that a lot of Video players have a progress bar which shows the position of playing?, and you can usually click on the bar and it goes (roughly) to the relative place in the movie where you clicked. I have noticed in a lot of movies when trying to fine-drag to a frame thst it will usually only go a few frames rather than individual frame-by-frame, so I had guessed that the frames it goes to (what I think of as seekable) are the keyframes. It seemed to fit also that these would be IFrames rather than a derived frame like a Pframe or Bframe.

As you can probably tell this is my guessing, and I was wondering whether this is Iframes and 'seekable keyframes' as Players use them (both same thing?), and if this is different under another interpretation like some technical definition? :scared:

Thanks for any further knowledge that might come my way!

[marcellus]

Originally posted by Mug Funky
long gops kinda suck for mpeg-2. i can't remember the technical reasons, but basically errors accumulate over time, and after about 50 frames, colours will start drifting toward greens and magentas (you'll be able to see this quite easily...).

long GOPs is more of an mpeg-4 thing, IMHO.
I wouldn't be so sure. I use ffdshow to encode live from my tv tuner card (making SVCD's -480x576 PAL). At 800-1000 kbps I obtain decent quality with a long GOP setting (500) - and of course with a custom matrix and some preprocessing, as much as my CPU can do in real time without dropping frames. With a GOP of 15 I couldn't obtain quality at such bitrate, I tried many times. I have over 50 SVCD's recorded that way that play fine on my standalone, only seeking is slow.

Is true that a year ago the colour drifting (like you said) in some blocks was noticeable, especially in static portions of the image, but since then libavcodec evolved a lot and that effect is not present anymore. IMO libavcodec makes mpeg2 behave as if it was mpeg4.

[video]

Originally posted by Mug Funky
long gops kinda suck for mpeg-2. i can't remember the technical reasons, but basically errors accumulate over time, and after about 50 frames, colours will start drifting toward greens and magentas (you'll be able to see this quite easily...).

long GOPs is more of an mpeg-4 thing, IMHO.

quite suprised on this. I felt that gop is nothing else, but an administrative unit. Gops is fixed on dvds to ease/make possible navigation of the video, i mean -50x -10x -5x -1x 1x 5x 10x 50x playbacks. or if you are decoding streaming mpeg2 a GOP is a sync point from which you can hook in, if you have lost somewhere - coz od stream error. gop header tells you resolution, AR, FPS, progressivenex etc...

What you are describing is rather related with I-frame distance, isn't it?

[mpucoder]

Yes, he was talking about I frame distance. Although a gop starts with an I frame, it is not limited to one I frame, there can be more.

Any header will get a decoder back into bit/byte sync. The gop doesn't contain resolution or ar or anything really useful to a decoder. The information in a gop is designed for editing and multiplexing, all it contains is a time code, and the closed and broken bits.

[Mug Funky]

ah, yes. i'm treating I-frame distance and GOP size as the same thing (usually they are, but i guess they can be different).

the green/pink problem i've only seen in TMPGenc, because that's the only encoder at the time that would let me do such long GOPs.

a short I-frame distance is also beneficial for error-correction. unless you incur extra overhead (like with concealment motion-vectors, which are almost never used), a glitch will most likely stay with you for the whole GOP. in practice, usually a given part of the frame can be replaced by an intra-coded block quite quickly, but sometimes this may not be the case.

[mpucoder]

Actually the spec states that "every macroblock is required to be refreshed before it is coded 132 times as predictive macroblocks. Macroblocks in B-pictures (and skipped macroblocks in P-pictures) are excluded from the counting as they do not lead to the accumulation of mismatch errors" Annex A of ISO 13818-2. So, regardless of I-frame distance, the errors should be limited to 132 P-pictures. I'm not sure if all, or even any, encoders track the number of times each macroblock is predictively coded before an intra macroblock is used.
Also the encoder can limit the accumulation of errors caused by quantization if it looks at the currently decoded coefficients, and not the YUV data, to determine the new coefficient values.

[dragongodz]

i'm treating I-frame distance and GOP size as the same thing (usually they are, but i guess they can be different).
you will find most encoders do 1 I frame per GOP for the simple fact they are based on doing output such as vcd/svcd/dvd where there is a short limit on the length a GOP can be. since you can select to use larger GOPS such a feature would be useful true but again consider that 99.9% of the time the GOP length will be small it is hardly a feature that most people/companies will spend time implamenting unless they see some need or great demand.

So, regardless of I-frame distance, the errors should be limited to 132 P-pictures. I'm not sure if all, or even any, encoders track the number of times each macroblock is predictively coded before an intra macroblock is used.
i doubt the majority do keep track. same reason as above. :)