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.