[mythtv] A prelude to transcoding MPEG2->MPEG2

James L. Paul james at mauibay.net
Sat Dec 6 02:32:56 EST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 05 December 2003 19:17, Geoffrey Hausheer wrote:
> I have started looking at enhancing the transcoder to do
> commercial-clipping on MPEG2 streams without reencoding them to MPEG4.

This is somethign I'm interested in, as I currently do it by hand (with some 
minor shell scripting to automate somewhat.)

> 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.

Whan I edit by hand with avidemux2, I _very_ rarely find a black interval at 
commercial break that does not contain a GOP. When I do, it's usually only a 
frame or two away from a black frame. This is with output from my freestyle 
cards, so of course other streams may vary. This means I am usually able to 
cut on a GOP and have it look clean. This is just an observation.

> 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.

Me either. Another reason (other than using the available tools) that I stick 
to cutting on GOPs.

> The simple truth seems to be that MPEG2 is a pain in the ass to deal with

No doubt. :) It's not intended as an editing format, unfortunately.

> :)
>
> 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.

Another observation. I've spent considerable time trying to get GOPchop to 
generate useable streams and have not yet succeeded. I haven't found a 
multiplexer that can recognize any segments after the first cut. A little 
over a month ago avidemux2 was patched to recognize PVR250 streams and I've 
been using it since with good results. It's even capable of somewhat messy 
automation via commandline.

> 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.

Yah. Hurts, doesn't it? ;) The thing is we're not really farther behind than 
any other projects on this subject either, AFAIK.

> 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?

As I said, I got it to work on a PVR250 (Freestyle) PS, but the results 
weren't feedable to other tools like mplex or tcmplex, so it was moot. In 
fact, even mplayer lost audio at the first cut. This was even after trying 
the gopfixup util intended to fix the broken time indexes caused by GOPchop. 
I'm not sure how useful it would be to use that code wholesale.

I'm not sure how avidemux and avidemux2 are implemented, but they have the 
ability to output m2v and mp2 between cutpoints in a passthrough kind of 
mode. I'm able to join the segments together and feed it to other tools ok, 
but I usually leave them seperate and feed them to dvdauthor as chapters in a 
single title.

I'm not suggesting any particular course of action here, just trying to 
provide some data points about what one more person out here is doing.
It seems that you are in a thinking stage. :)

> .Geoff
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/0YYoT8BYaKRUpkQRAghIAJ0aZliQYXSr3kFkfB7x/66koHAEsgCgiokG
BETJM4zkp4PZELThP95RwdE=
=2MHb
-----END PGP SIGNATURE-----




More information about the mythtv-dev mailing list