Well, in the last few weeks, after finally getting MPEG2-PS streams out of my series 2 TiVo, I’ve been actively using gopchop again. It had stagnated, but it seems that people with hardware MPEG2 encoders continue to use it. I should have realized sooner that they are gopchop’s audience. It’s traditionally been a rather fragile bit of code for software-generated MPEG2-PS streams, but pretty stable for the more regular hardware-encoder streams. Between my recent increase in its use, and two large patch bundles I was sent, I’m trying to pick up development again.
One thing that has been particularly frustrating when dealing with MPEG2 video has been dealing with the rendering of the pictures. MPEG2 stores its pictures “out of order”. And by “order” I mean display order. They’re in order for decoding, but not for display. libmpeg2 handles all this for me, except for the part where I need to stop on a specific picture. For an accurate GOP splitting UI, I need to display the last picture of a GOP. Depending on the stream, libmpeg2 may not have rendered the last picture, since it’s waiting for more B or P frames before it knows the decoding is done. (For example, B frames depend on frames in the future, so you can’t render them until you see further down the stream, etc.)
My plan to deal with this is to force-feed libmpeg2 with End-Of-Stream packets, and not render stuff until I’m on the picture I want. For example, to display the initial B or P frames from a GOP, I may need to process the entire prior GOP first. For some types of streams, this may end up being very CPU expensive, since they may have hundreds of pictures in each GOP. But, this is why MPEG2 editing is hard. :)
© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Well, you shouldn’t have to put in an end of sequence or an end of GOP header at all. You should just have to send the next picture header. I’m not sure how libmpeg2 works, but MPEG, in general, only saves two pictures behind — which are the last two anchor frames. But, one of those should be displayed, so only one hasn’t been.
Depending on your software encode, I’m guessing the first picture of your next GOP would be an anchor frame. So, when seeing that, the MPEG decoder should pop out the undisplayed anchor frame for presentation.
Hope that works, e-mail if you have questions.
Comment by Ted Gould — April 28, 2005 @ 12:41 pm
Yes, this is possible, also, and is just as “correct”. With gop chop you may not be continuing on to the next GOP, so it’s just as wasteful, unfortunately. There are also unusual streams that have LONG chains of B/P frames. :)
Comment by kees — April 28, 2005 @ 4:52 pm
It, ofcourse, depends on your MPEG stream. There are MPEG streams that do not contain sequence or GOP headers, nor I frames. None of those are required in an MPEG 2 stream.
The idea of a GOP is really more an MPEG 1 structure, that is supported in MPEG 2. But, for the most part, they aren’t used as much in MPEG 2.
Comment by Ted Gould — April 29, 2005 @ 10:17 am