transcoding mpeg2 -> mpeg2 (was: RE: [mythtv] DVB, (new) recording profiles, and transcoding)

Geoffrey Hausheer ou401cru02 at sneakemail.com
Fri Oct 3 10:52:16 EDT 2003


On Fri, 03 Oct 2003 12:19:36 +0200, "Torsten Schenkel
torsten.schenkel-at-web.de |mythtv/1.0-Allow|"
<j19fhm6efm0t at sneakemail.com> said:
> Hi, just as I tried out transcoding a question arised and was answered
> by the list immediately:
> 
> > >  As
> > > for honouring the cutlist and keeping the mpeg2 stream (like we already
> > > do for mpeg4), you need to be able to reencode key frames in mpeg2 format
> > > (because you need to mark a key frame after the 'cut').  I'm not aware of
> > > any legally free tools to do this, but someone had mentioned bbmpeg as an
> > > option (I've not looked into it).
> 
> though not in the manner I hoped for. 
> 
> So it isn't possible at the moment to transcode mpeg2 to mpeg2 to cut
> commercials? Would be nice because I have H/W mpeg2 decoding but low cpu
> power.

Yep, your statement is correct.  Also, i looked into tihs, and don't see
a good solution.  Edward's solution woul be the easiest (clip to key
frames).  It would require basically no work to get right, but it
sacrifices the per-frame precision we have today.  the second option
would be to do what Isaac originally proposed, and I decided against when
this first came up for mpeg4.  That would be to clip to key-frames, and
then store 'micro-jumps' in the table that would allow myth to skip the
unwanted frames during playback as if there was a really short
commercial.  The upside to this is that we don't need to do any
re-encoding.  the downside is that playing mpeg2 streams on any other
player (buring to DVD or whatever) would leave you with ~1 second of
commercials at each cutpoint.  the third option is to implement an mpeg2
encoder.  Myth already ships with one in the form of libavcodec, but it'd
need to be hooked up.  This option allows exact commercial cuts, and
wouldn't require much more CPU time (you're only reencoding a small
number of frames), but it MAY end up creating incompatible mpeg2 streams
(which won't play in anything besides myth), since you don't end up with
key frames at even intervals, and again this may break saving to DVD or
other such things.  the fourth option i this so called 'bbmpeg' but from
my research it appears to be basically inactive, and it doesn't appear to
do exactly what I need it to.

So the simplest solution from a coding perspective is option '2' above
('1' is actually simpler, but basically just a subset of '2' anyway).  If
we go that way, it'd be easiest to change the mpeg4 transcoding to use
the same method as well (this will leave all currently transcoded mpeg4s
as obsolete, but the code to handle the weird key-frame distribution
isn't too bad, so there's no reason to make them unsupported)

>From an implementation perspective, '3' may actaully be easier, since it
'only' requires hooking up the mpeg2 encoder, which should work a lot
like the mpeg4 encoder does, and the transcoder would not need many
changes.  But we'd have to look into the MPEG2 container spec and see if
it is legal to have unevenly spaced key-frames, and if not decide whether
we want to break the mpeg2 containers, and have the myth-mpeg2s be
incompatible with other players.

Anyhow, that's how things stand today.  I am open for other options and
opinions.

.Geoff


More information about the mythtv-dev mailing list