[mythtv] A prelude to transcoding MPEG2->MPEG2

Kenneth Aafløy ke-aa at frisurf.no
Sat Dec 6 00:29:29 EST 2003


On Sat, 2003-12-06 at 06:17, Geoffrey Hausheer wrote:
> I have started looking at enhancing the transcoder to do
> commercial-clipping on MPEG2 streams without reencoding them to MPEG4.
> 
> I have finally invested a little time in understanding the MPEG2 format,
> and have a better idea of what is needed.
> I've looked at GOPChop, which is the closest thing I've seen to this
> capability, but it leaves the problem of having to cut to the nearest GOP
> (I-Frame).  When we faced this problem with MPEG4 streams, I decided to
> create a new I-Frame at the cutpoint, and reencdoe to the next I-Frame,
> then do some magic to get the key-frames right.
> 
> With MPEG2 we have the same options: 1) cut to the nearest GOP, and use
> micro-jumps to get to the exact frame, or 2) reencode a new GOP
> consisting of a new I-frame at the exact start-point up-to the next real
> I-Frame.
> 
> As far as I can tell, the MPEG2 format doesn't require GOPs to all be the
> same size, so we could keep valid streams and do (1).  However, it
> requires an MPEG2-encoder (there is one in libavcodec, though quite a bit
> of code will be needed to use it), and it may turn out to be difficult to
> get compatibility with all MPEG2 streams.  Doing (2) would be quite a bit
> easier, but it means that watching the videos outside of myth, (or
> recording to DVD) you could end up seeing ~0.5 seconds unwanted video
> between the commercial cut.
> 
> MPEG2 is further complicated by B-Frames, which means that the end-point
> needs to be cut to the nearest P-Frame or I-Frame, so you could end up
> with a few extra frames after the start of the cut-point in either of the
> above methods.
> 
> There is also the question of how audio and video are muxed together.  My
> understanding is that the 'PES' consists of a series of GOPs and audio
> sections.  So I am not sure how to get frame accuracy without building
> new PES and possibly needing to reencode the audio.
> 
> The simple truth seems to be that MPEG2 is a pain in the ass to deal with
> :)
> 
> This is about as far as I've gotten so far, which isn't anywhere near
> enough to actually implement anything.
> 
> Considering the complexiity of keeping an MPEG2 stream compliant, I think
> the easier approach will be the GOPchop approach.  I was considering just
> importing it wholesale (it is GPL) but it looks like it'll take a fair
> amount of work to extract the GUI parts and make a library from it, so it
> may be easier to just duplicate the GOP modifying functions in myth.  On
> the flip-side, chopping to exact frames would give a much beter overall
> solution, but is likely to be challenging to make work for the PVR250,
> DVB, and HDTV crowds.
> 
> Anyhow, this is all to say that we're no farther along in the goal of
> chopping mpeg2 streams then we were 3 months ago.
> 
> However, if anyone knows where I can find a reasonable spec for the MPEG2
> stream format, I'd be much obliged.  My google searching has turned up
> lots of useful stuff, but not enough for me to really understand how to
> begin (for instance I've been able to find zilch on the actual PES and
> GOP formats.
> 
> Also, everything I've looked at has been MPEG2-PS related.  the 'TS'
> variety seems to be quite a bit more complex, and if DVB uses it (as I
> suppose it does...'TS' being 'Transport Stream'), it will cause much woe,
> so if anyone knows anything about that, it'd be useful too. For instance,
> has anyone tried using GOPchop on a DVB stream?

It's 6:30 in the morning here, so I hope I did not catch the point.

If we where to cut between two keyframes, why not just decode the frames
from the first keyframe and until now, and reencode them to the frame we
want to be at. What to do with the remaining frames would offcourse be
codec independentent (tm), as we can't know what state the codecs want
after such an operation. The most keen solution would be to encode also
the rest of the non-i-frames after the frame we just handleded (won't be
many anyway..)..


Night,
Kenneth



More information about the mythtv-dev mailing list