Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

A prelude to transcoding MPEG2->MPEG2

 

 

First page Previous page 1 2 Next page Last page  View All MythTV dev RSS feed   Index | Next | Previous | View Threaded


ou401cru02 at sneakemail

Dec 5, 2003, 10:17 PM

Post #1 of 28 (17303 views)
Permalink
A prelude to transcoding MPEG2->MPEG2

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?

.Geoff


ke-aa at frisurf

Dec 5, 2003, 10:29 PM

Post #2 of 28 (17023 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

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


james at mauibay

Dec 6, 2003, 12:32 AM

Post #3 of 28 (17095 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

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


jim at jtan

Dec 6, 2003, 12:40 AM

Post #4 of 28 (16974 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

Yeah, seems like MPEG really just wasn't designed for cutting.
What we really need is a way to say "here's a frame, decode it to use
as a reference but don't display it". Could you pull some trickery
like giving a bogus PTS to make that happen?

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

Yeah, audio sync could be a pain. Are you even guaranteed that the
cut for both audio and video will occur in the same PES?

> Considering the complexiity of keeping an MPEG2 stream compliant, I think
> the easier approach will be the GOPchop approach.

GOPchop still has issues with audio sometimes, I've heard. It doesn't
really handle audio -- it apparently just keeps all non-video data
along for the ride while doing his chopping and hopes that it works.

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

I think that there was useful info at http://www.mpucoder.com/dvd/
(like "MPEG Quick Reference" and "PES headers"), but apparently it's
no longer freely accessible, so you'll have to make something like a
$5 donation to get it. I remember mirroring it once, but I don't
think I still have it.

In case you haven't seen it already, there might also be some info
in this thread:
http://www.linuxtv.org/mailinglists/vdr/2003/04-2003/msg00523.html

-jim


ou401cru02 at sneakemail

Dec 6, 2003, 7:31 AM

Post #5 of 28 (17001 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

On Sat, 06 Dec 2003 06:29:29 +0100, "Kenneth Aafl°y" said:
> 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..)..

Sure sounds easy doesn't it? Unfortunately, this is non trivial. As
others have mentioned, just chopping to real i-frames is much more
difficult than it sounds. Reencdoing will make it harder, becasue you
need to generate a valid GOP that looks exactly like the other GOPs,
otherwise you risk compatibility issues. I think I'll start with
chopping down to the nearest I-frame, and if that actually works, then
perhaps we'll try adding a encoder into the mix.

Don't expect anything soon though. This is not a trivial task (which is
why it hasn't been done already)

.Geoff


ou401cru02 at sneakemail

Dec 6, 2003, 7:39 AM

Post #6 of 28 (17003 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

On Fri, 5 Dec 2003 21:32:56 -1000, " James L. Paul" said:
> > 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.
>
Thanks, I'll look into it (I think I did before, and thought it would be
challenging to use, but that was before and this is now)

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

Thanks for the info. I really didn't want to demux/remux the audio, but
it seems like this may be needed to get it right. Yuck.

One thing i just realized is that DVD-Lab (for Windows) has the ability
to set chapters on a per-frame basis. I wonder how they do that. Of
course it is probably not releant, since it could just be some tricks in
the headers, but still, it implies that the DVD spec requires that a
player can decode several-frames without displaying them, and pick up at
an arbitrary b/p/i frame. Or maybe it doesn't really work, I can't say
i've actually used that feature.

.Geoff


doug at ties

Dec 6, 2003, 7:49 AM

Post #7 of 28 (17002 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

On 12/06/03 00:17:14, Geoffrey Hausheer wrote:
> 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.

Each GOP should be self-contained, iirc. Just continue re-encoding
after the cut until you get to a whole, untouched GOP.

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

One would hope that the audio packets would line up on GOP boundaries.
If not, or if you're reencoding video, you're gonna end up reencoding
audio as well -- either MPEG2 layer 3 (there are a few encoders to
choose from for this one :-) or AC3.

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

Yes, this is a PITA. Even the dead-tree documentation in this field is
expensive :-( I've learned what little I know mostly by reading source
code.

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

There's actually a good amount of info on MPEG-TS available in the ATSC
(HDTV) standards freely available from www.atsc.org (in PDF). Quick
management summary:

MPEG-TS (transport stream) multiplexes individual MPEG-ES (elementary
stream) streams (video and audio) from one or more programs, and breaks
them into 188-byte packets for ease of transmission. Each packet has a
PID (program identifier) that shows what stream it belongs to, as well
as (optionally) other info to help in classifying the packets without
decoding their contents. The stream also includes table-of-contents
information (PAT, program association table--always at PID 0, and PMT,
program map table--one for each program). It can also contain other
non-video data in a semi-standard table format; this is used in HDTV
for PSIP (program and system information protocol)--guide data etc.

Both HDTV and (I believe) DVB store their recordings on disk in MPEG-TS
in order to avoid having to translate the video into MPEG2-PS at record
time, which in principle is trivial but we don't quite have code to do.
It's probably worthwhile to insert code into transcode to do so, and
then commercial editing would just work.

-Doug


ou401cru02 at sneakemail

Dec 6, 2003, 8:38 AM

Post #8 of 28 (16999 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

On Sat, 6 Dec 2003 02:40:26 -0500, "Jim Paris jim-at-jtan.com
|mythtv/1.0-Allow|" <elxwhpgqut0t [at] sneakemail> said:
> Yeah, seems like MPEG really just wasn't designed for cutting.
> What we really need is a way to say "here's a frame, decode it to use
> as a reference but don't display it". Could you pull some trickery
> like giving a bogus PTS to make that happen?
>

Hard to say, as I still don't really understand how the PTS works.

> Yeah, audio sync could be a pain. Are you even guaranteed that the
> cut for both audio and video will occur in the same PES?

I dunno. This is why I'm now considering demuxing/remuxing the audio.
When I make DVDs using DVD-Lab
(for Windows), I always need to demux the audio. I'm not sure why, but
i think it makes adding chapters easier (you can make sure the PES
starts at a chapter boundary perhaps?)

>
> > Considering the complexiity of keeping an MPEG2 stream compliant, I think
> > the easier approach will be the GOPchop approach.
>
> GOPchop still has issues with audio sometimes, I've heard. It doesn't
> really handle audio -- it apparently just keeps all non-video data
> along for the ride while doing his chopping and hopes that it works.
>

Good to know. Sounds like I should steer clear of GOPchop from what you
and James are saying.

> > 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.
>
> I think that there was useful info at http://www.mpucoder.com/dvd/
> (like "MPEG Quick Reference" and "PES headers"), but apparently it's
> no longer freely accessible, so you'll have to make something like a
> $5 donation to get it. I remember mirroring it once, but I don't
> think I still have it.
>
> In case you haven't seen it already, there might also be some info
> in this thread:
> http://www.linuxtv.org/mailinglists/vdr/2003/04-2003/msg00523.html
>
Thanks for the links. I sent them my $5. We'll see what we get (lloks
like a good site tho). I also found:
http://ookami.videoxone.de/programmers.html
which has some good info, though it is in DOC and RAR-compressed.

.Geoff


jim at jtan

Dec 6, 2003, 9:26 AM

Post #9 of 28 (16995 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

> One thing i just realized is that DVD-Lab (for Windows) has the ability
> to set chapters on a per-frame basis. I wonder how they do that. Of
> course it is probably not releant, since it could just be some tricks in
> the headers, but still, it implies that the DVD spec requires that a
> player can decode several-frames without displaying them, and pick up at
> an arbitrary b/p/i frame. Or maybe it doesn't really work, I can't say
> i've actually used that feature.

Aah, interesting. If it does work, you might be able to mark the
cut-section as a chapter and then use the DVD's scripting to
automatically skip over the chapter on playback. The cut section
would still be in the MPEG stream and take up space, but maybe you
don't care if you're only trying to archive shows..

-jim


ou401cru02 at sneakemail

Dec 7, 2003, 12:28 PM

Post #10 of 28 (17014 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

Well, I've done some more investigating, and I am beginning to formulate
a plan for removing chunks from mpeg2 streams.

From my analysis, the way to go appears to be to demux the stream on the
fly, clip out GOP chunks, rewrite the GOP header, and remux.

I found a very good spec of the MPEG2-PS stream on one of the sites
mentioned earlier, and implemented a crude mpeg parser (which can find
interesting frames, and decode the data inside).

There are nasty things that need to be dealt with though.
A GOP is not necessarily self contained (and usually not). A common GOP
sequence is:
a b c d e f g h i j k l m n o p q r s
I B B P B B P B B I B B P B B P B B I ...

(a-i would be within a single GOP).
However, to decode, h and i, both g and j frames are needed, so this gets
stored as:
a d b c g e f j h i m k l p n o s q r ...
I P B B P B B I B B P B B P B B I B B

as you can see frames are all out of order, and a given GOP can contain
frames from the previous GOP. This will make accurate (frame-exact)
clipping more challenging.

Unfortunately MPEG2 is not designed for random access (there is no way to
tell how big a given GOP with it's frames will be), so searching for
headers is sort of slow.

For now, I plan to rewrite the gop headers with correct timecodes and
frame numbers, and to strip out any 'B' frames following the initial I
frame. In theory, the MPEG2 spec allows for setting a 'broken' flag to
indicate to the decoder to ignore B frames that refer to the previous
GOP, but it seems that these flags are not always well supported, and
discaring the bogus B frames will work better. It will also mean
rewriting the frame numbers inside the frames, but that isn't too
challenging.

Things can be further complicated by the sequence headers which can
contain different quantization matrices for a given set of GOPs, so I may
need to build new sequence headers too (so far the MPEG2 streams I've
seen have a 1:! correspondance between GOP and SEQ headers, but this
isn't gauranteed).

It does not appear that libavcodec/libavformat gives me sufficient
control to do this sort of thing (it may well be able to, but the
documentation is horrendous, and I haven't figured out how yet). Since
for this type of transcoding, there is no need to decode the actual
frames, I don't need av* for that.

So what does this all mean to the end user? I think I can do commercial
clipping tothe GOP boundaries without too much difficulty. It will
initially only work for PVR streams (MPEG-PS). I will have to write my
own MPEG parsing code (this isn't really too difficult, but could
probably be replaced with some other parser in the future).

This will all suck, because it requires a completely different code-path
to deal with the MPEG2-MPEG2 case in the transcoder. All the
fast-forward code will need to be duplicated into my mpeg parser.

So far, I think I can actually implement all of the above in a reasobably
straight-forward manner. I haven't looked into processing the audio yet,
and that may make things more challenging, as I expect I'll need to
reencode the audio to keep the sync.

I will try to implement the above. I'll probably start with implementing
a standalone prototype which takes the cutpoints on the command line. If
that all works, we'll see how to best merge it with myth.

.Geoff


jim at jtan

Dec 7, 2003, 2:05 PM

Post #11 of 28 (16995 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

> From my analysis, the way to go appears to be to demux the stream on the
> fly, clip out GOP chunks, rewrite the GOP header, and remux.

Do you need to demux the entire stream, or just in the vicinity of the
cut?

> I found a very good spec of the MPEG2-PS stream on one of the sites
> mentioned earlier

Out of curiosity, which site?

> Unfortunately MPEG2 is not designed for random access (there is no way to
> tell how big a given GOP with it's frames will be), so searching for
> headers is sort of slow.

Are the GOPs easily findable in a stream of data, and can you use the
timestamps to determine which they are? If so, you could do a
binary-type search where you just seek to an arbitrary file position,
find the nearest GOP, and see where you ended up.

> This will all suck, because it requires a completely different code-path
> to deal with the MPEG2-MPEG2 case in the transcoder.
..
> I'll probably start with implementing a standalone prototype which
> takes the cutpoints on the command line. If that all works, we'll
> see how to best merge it with myth.

If it really shares little or no code with Myth, I'd recommend just
leaving it as a separate command-line utility, and just putting a
small stub in Myth to spawn it, with the reasoning being that there
are so many projects that want to do good MPEG2 cutting, and this
could be useful for all of them.

-jim


warlord at MIT

Dec 8, 2003, 8:08 AM

Post #12 of 28 (16978 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

"Geoffrey Hausheer" <ou401cru02 [at] sneakemail> writes:

> Sure sounds easy doesn't it? Unfortunately, this is non trivial. As
> others have mentioned, just chopping to real i-frames is much more
> difficult than it sounds. Reencdoing will make it harder, becasue you
> need to generate a valid GOP that looks exactly like the other GOPs,
> otherwise you risk compatibility issues. I think I'll start with
> chopping down to the nearest I-frame, and if that actually works, then
> perhaps we'll try adding a encoder into the mix.
>
> Don't expect anything soon though. This is not a trivial task (which is
> why it hasn't been done already)

Personally, I'm willing to live with chopping to the nearest GOP.
Usually I'm cutting out 60-300 seconds of crap; I'm willing to live
with 0.5-1 second of leftover in the result. Also, cutting to the
nearest GOP should make it easier to write to a video DVD, no?

> .Geoff

-derek

--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord [at] MIT PGP key available


developstuff at qwest

Dec 8, 2003, 2:22 PM

Post #13 of 28 (16953 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

Jim Paris wrote:
> GOPchop still has issues with audio sometimes, I've heard. It doesn't
> really handle audio -- it apparently just keeps all non-video data
> along for the ride while doing his chopping and hopes that it works.


James L. Paul wrote:
> 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.


This is quite odd because I've been using GOPchop for a while now to archive interview segments from talk shows and cut commercials out of The Kids In The Hall, The Simpsons, and South Park. I've never witnessed a missing audio or sync problem using my PVR-250's streams. It gives a warning about the missing header of course, and it has the unavoidable MPEG-2 problems of the first and last GOP of each clip. But those two problems are handled by the "Ignore Errors" and "Drop Orphaned Frames" options respectively. The latter option is not a solution to the latter problem, just a preference for the user to choose the lesser of two evils. I'm quite happy with cutting on GOPs because I'm archiving stuff for myself, not doing production work, so I can tolerate the less-than-0.5-second of a commercial on the occasion when there is no black frame (in my experience: ~30%) or when there's reverb in the audio along with a black frame.

--
Craig Rindy


ou401cru02 at sneakemail

Dec 8, 2003, 3:47 PM

Post #14 of 28 (16988 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

On Mon, 08 Dec 2003 14:22:20 -0700, "Craig Rindy
developstuff-at-qwest.net |mythtv/1.0-Allow|"
<bl5dhotpoq0t [at] sneakemail> said:
> Jim Paris wrote:
> > GOPchop still has issues with audio sometimes, I've heard. It doesn't
> > really handle audio -- it apparently just keeps all non-video data
> > along for the ride while doing his chopping and hopes that it works.
>
>
> James L. Paul wrote:
> > 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.
>
>
> This is quite odd because I've been using GOPchop for a while now to
> archive interview segments from talk shows and cut commercials out of The
> Kids In The Hall, The Simpsons, and South Park. I've never witnessed a
> missing audio or sync problem using my PVR-250's streams. It gives a
> warning about the missing header of course, and it has the unavoidable
> MPEG-2 problems of the first and last GOP of each clip. But those two
> problems are handled by the "Ignore Errors" and "Drop Orphaned Frames"
> options respectively.
Making compliant streams should not be difficult (at least for MPEG2-PS).
I'll post my commercial-cutting prototype when it is actually funtional
(probably a couple more days). I ran into a snag where my documentation
on stream encapsulation (PES headers) didn't match the actual headers I
was seeing in the stream. I found a decent reference implementation in
ogle that has helped me get it right.

I'm still having trouble determining how to sync the audio. The audio
frames do not appear to specify the number of samples in the header, so i
know of no way to determine the audio length without decoding the audio,
which kinda sucks. All the info needed for frame-rate control on the
video side exists in the header, so there is no need to decode the video
to do the chopping.

Also, I'd really like to get my hands on a MPEG2-TS stream from one of
the HDTV/DVB guys so I can work on making that work too, so if anyone
wants to snip ~5 minutes from such a beast and find a way to get it to
me, that'd help (MPEG2-TS won't be supported otherwise)

> The latter option is not a solution to the latter
> problem, just a preference for the user to choose the lesser of two
> evils. I'm quite happy with cutting on GOPs because I'm archiving stuff
> for myself, not doing production work, so I can tolerate the
> less-than-0.5-second of a commercial on the occasion when there is no
> black frame (in my experience: ~30%) or when there's reverb in the audio
> along with a black frame.

If using myth to play the streams, it won't be an option, because we can
add 'micro-jumps' to get frame-exact.

Note that I have yet to see a PVR250 stream which is DVD compliant. DVD
requires either an AC3 or PCM stream to be present, and I'm not aware of
any way to get such a thing from the PVR250. I've yet to find an AC3
encoder which is really compliant (the one that comes with ffmpeg is not
compatible with my DVD player, and I've had to use commercial encoders in
Windows to get compliant streams). Anyhow, that isn't really relevant as
it has nothing to do with the issue at hand, I just thought I'd mention
it.

.Geoff


warlord at MIT

Dec 8, 2003, 4:17 PM

Post #15 of 28 (16960 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

"Geoffrey Hausheer" <ou401cru02 [at] sneakemail> writes:

> Note that I have yet to see a PVR250 stream which is DVD compliant. DVD
> requires either an AC3 or PCM stream to be present, and I'm not aware of
> any way to get such a thing from the PVR250. I've yet to find an AC3
> encoder which is really compliant (the one that comes with ffmpeg is not
> compatible with my DVD player, and I've had to use commercial encoders in
> Windows to get compliant streams). Anyhow, that isn't really relevant as
> it has nothing to do with the issue at hand, I just thought I'd mention
> it.

Not quite true.. A DVD can also use MP2 audio, which the PVR will do.
I was able to make a video DVD without any audio transcoding, and
it works just fine in my set-top DVD player.

> .Geoff

-derek

--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord [at] MIT PGP key available


james at mauibay

Dec 8, 2003, 4:26 PM

Post #16 of 28 (16986 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

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

On Monday 08 December 2003 11:22, Craig Rindy wrote:
> Jim Paris wrote:
> > GOPchop still has issues with audio sometimes, I've heard. It doesn't
> > really handle audio -- it apparently just keeps all non-video data
> > along for the ride while doing his chopping and hopes that it works.
>
> James L. Paul wrote:
> > 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.
>
> This is quite odd because I've been using GOPchop for a while now to
> archive interview segments from talk shows and cut commercials out of The
> Kids In The Hall, The Simpsons, and South Park. I've never witnessed a
> missing audio or sync problem using my PVR-250's streams. It gives a
> warning about the missing header of course, and it has the unavoidable
> MPEG-2 problems of the first and last GOP of each clip. But those two
> problems are handled by the "Ignore Errors" and "Drop Orphaned Frames"
> options respectively. The latter option is not a solution to the latter
> problem, just a preference for the user to choose the lesser of two evils.
> I'm quite happy with cutting on GOPs because I'm archiving stuff for
> myself, not doing production work, so I can tolerate the
> less-than-0.5-second of a commercial on the occasion when there is no black
> frame (in my experience: ~30%) or when there's reverb in the audio along
> with a black frame.

Can you point me to the source for the version of GOPchop you are using?

> --
> Craig Rindy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/1QiMT8BYaKRUpkQRAi0+AJ9kwMqj/0eV6YpWeLN9lukTAxPMaACeJAD2
kbV1X2Ngcq1yLsIwYjigAQM=
=hadB
-----END PGP SIGNATURE-----


doug at ties

Dec 8, 2003, 4:28 PM

Post #17 of 28 (16971 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

On 12/08/03 17:47:53, Geoffrey Hausheer wrote:

> Also, I'd really like to get my hands on a MPEG2-TS stream from one
> of the HDTV/DVB guys so I can work on making that work too, so if
> anyone wants to snip ~5 minutes from such a beast and find a way to
> get it to me, that'd help (MPEG2-TS won't be supported otherwise)

I happen to have 38 seconds of MPEG-TS (80 MB!) lying around, and
you're welcome to it, though please be kind as it's a (slow-uplink)
cable modem. http::/jekyl.ddts.net/enterprise.mpg . If you truly need
5 minutes, I'll have to defer to somebody with a bigger pipe.

-Doug


james at mauibay

Dec 8, 2003, 4:36 PM

Post #18 of 28 (17003 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

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

On Monday 08 December 2003 12:47, Geoffrey Hausheer wrote:
> On Mon, 08 Dec 2003 14:22:20 -0700, "Craig Rindy
> developstuff-at-qwest.net |mythtv/1.0-Allow|"
>
> <bl5dhotpoq0t [at] sneakemail> said:
> > Jim Paris wrote:
> > > GOPchop still has issues with audio sometimes, I've heard. It doesn't
> > > really handle audio -- it apparently just keeps all non-video data
> > > along for the ride while doing his chopping and hopes that it works.
> >
> > James L. Paul wrote:
> > > 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.
> >
> > This is quite odd because I've been using GOPchop for a while now to
> > archive interview segments from talk shows and cut commercials out of The
> > Kids In The Hall, The Simpsons, and South Park. I've never witnessed a
> > missing audio or sync problem using my PVR-250's streams. It gives a
> > warning about the missing header of course, and it has the unavoidable
> > MPEG-2 problems of the first and last GOP of each clip. But those two
> > problems are handled by the "Ignore Errors" and "Drop Orphaned Frames"
> > options respectively.
>
> Making compliant streams should not be difficult (at least for MPEG2-PS).
> I'll post my commercial-cutting prototype when it is actually funtional
> (probably a couple more days). I ran into a snag where my documentation
> on stream encapsulation (PES headers) didn't match the actual headers I
> was seeing in the stream. I found a decent reference implementation in
> ogle that has helped me get it right.
>
> I'm still having trouble determining how to sync the audio. The audio
> frames do not appear to specify the number of samples in the header, so i
> know of no way to determine the audio length without decoding the audio,
> which kinda sucks. All the info needed for frame-rate control on the
> video side exists in the header, so there is no need to decode the video
> to do the chopping.
>
> Also, I'd really like to get my hands on a MPEG2-TS stream from one of
> the HDTV/DVB guys so I can work on making that work too, so if anyone
> wants to snip ~5 minutes from such a beast and find a way to get it to
> me, that'd help (MPEG2-TS won't be supported otherwise)
>
> > The latter option is not a solution to the latter
> > problem, just a preference for the user to choose the lesser of two
> > evils. I'm quite happy with cutting on GOPs because I'm archiving stuff
> > for myself, not doing production work, so I can tolerate the
> > less-than-0.5-second of a commercial on the occasion when there is no
> > black frame (in my experience: ~30%) or when there's reverb in the audio
> > along with a black frame.
>
> If using myth to play the streams, it won't be an option, because we can
> add 'micro-jumps' to get frame-exact.
>
> Note that I have yet to see a PVR250 stream which is DVD compliant. DVD
> requires either an AC3 or PCM stream to be present, and I'm not aware of
> any way to get such a thing from the PVR250. I've yet to find an AC3
> encoder which is really compliant (the one that comes with ffmpeg is not
> compatible with my DVD player, and I've had to use commercial encoders in
> Windows to get compliant streams). Anyhow, that isn't really relevant as
> it has nothing to do with the issue at hand, I just thought I'd mention
> it.

It's not true that only AC3 and PCM are DVD-Video compliant. The common mp2
audio that we have is also well supported. There are the compliant types of
audio streams for DVD-Video:

* Dolby Digital (AC-3): 1 to 5.1 channels
* MPEG-2 audio: 1 to 5.1 or 7.1 channels
* PCM: 1 to 8 channels.

Assuming I use a compliant video resolution and bitrate, and compliant audio
frequency and rate, I believe the output of the PVR250 is acceptably
DVD-Video compliant. :) My practical results with a variety of standalone
players reflects this as well, so far. :)

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

iD8DBQE/1QsLT8BYaKRUpkQRAhoOAKCGZWIF6kBSMochBbQYvcYA3Ur4XgCglAOT
sFg0Qztt47b4lILL/K7VKKs=
=ekvv
-----END PGP SIGNATURE-----


james at mauibay

Dec 8, 2003, 4:40 PM

Post #19 of 28 (16967 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

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

On Monday 08 December 2003 13:17, Derek Atkins wrote:
> "Geoffrey Hausheer" <ou401cru02 [at] sneakemail> writes:
> > Note that I have yet to see a PVR250 stream which is DVD compliant. DVD
> > requires either an AC3 or PCM stream to be present, and I'm not aware of
> > any way to get such a thing from the PVR250. I've yet to find an AC3
> > encoder which is really compliant (the one that comes with ffmpeg is not
> > compatible with my DVD player, and I've had to use commercial encoders in
> > Windows to get compliant streams). Anyhow, that isn't really relevant as
> > it has nothing to do with the issue at hand, I just thought I'd mention
> > it.
>
> Not quite true.. A DVD can also use MP2 audio, which the PVR will do.
> I was able to make a video DVD without any audio transcoding, and
> it works just fine in my set-top DVD player.

I just posted to this effect as well. Here's some specifics on DVD support for
MPEG audio, from the excellent dvddemystified.com website:

MPEG audio is multi-channel digital audio, using lossy compression from
original PCM format with sample rate of 48 kHz at 16 or 20 bits. Both MPEG-1
and MPEG-2 formats are supported. The variable bit rate is 32 kbps to 912
kbps, with 384 being the normal average rate. MPEG-1 is limited to 384 kbps.
Channel combinations are (front/surround): 1/0, 2/0, 2/1, 2/2, 3/0, 3/1, 3/2,
and 5/2. The LFE channel is optional with all combinations. The 7.1 channel
format adds left-center and right-center channels, but is rare for home use.
MPEG-2 surround channels are in an extension stream matrixed onto the MPEG-1
stereo channels, which makes MPEG-2 audio backwards compatible with MPEG-1
hardware (an MPEG-1 system will only see the two stereo channels.) MPEG Layer
3 (MP3) and MPEG-2 AAC (also known as NBC or unmatrix) are not supported by
the DVD-Video standard. MPEG audio is not used much on DVDs, although some
inexpensive DVD recording software programs use MPEG audio, even on NTSC
discs, which goes against the DVD standard and is not supported by all NTSC
players.

> > .Geoff
>
> -derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/1QvjT8BYaKRUpkQRAlN2AJ926Xk/BxMo82F/ubSIiW70AHuBtwCffHVc
d+TM4wfZ9BhhRriALuEG/UQ=
=0cK1
-----END PGP SIGNATURE-----


james at mauibay

Dec 8, 2003, 5:37 PM

Post #20 of 28 (16976 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

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

On Monday 08 December 2003 13:40, James L. Paul wrote:
> On Monday 08 December 2003 13:17, Derek Atkins wrote:
> > "Geoffrey Hausheer" <ou401cru02 [at] sneakemail> writes:
> > > Note that I have yet to see a PVR250 stream which is DVD compliant.
> > > DVD requires either an AC3 or PCM stream to be present, and I'm not
> > > aware of any way to get such a thing from the PVR250. I've yet to find
> > > an AC3 encoder which is really compliant (the one that comes with
> > > ffmpeg is not compatible with my DVD player, and I've had to use
> > > commercial encoders in Windows to get compliant streams). Anyhow, that
> > > isn't really relevant as it has nothing to do with the issue at hand, I
> > > just thought I'd mention it.
> >
> > Not quite true.. A DVD can also use MP2 audio, which the PVR will do.
> > I was able to make a video DVD without any audio transcoding, and
> > it works just fine in my set-top DVD player.
>
> I just posted to this effect as well. Here's some specifics on DVD support
> for MPEG audio, from the excellent dvddemystified.com website:
>
> MPEG audio is multi-channel digital audio, using lossy compression from
> original PCM format with sample rate of 48 kHz at 16 or 20 bits. Both
> MPEG-1 and MPEG-2 formats are supported. The variable bit rate is 32 kbps
> to 912 kbps, with 384 being the normal average rate. MPEG-1 is limited to
> 384 kbps. Channel combinations are (front/surround): 1/0, 2/0, 2/1, 2/2,
> 3/0, 3/1, 3/2, and 5/2. The LFE channel is optional with all combinations.
> The 7.1 channel format adds left-center and right-center channels, but is
> rare for home use. MPEG-2 surround channels are in an extension stream
> matrixed onto the MPEG-1 stereo channels, which makes MPEG-2 audio
> backwards compatible with MPEG-1 hardware (an MPEG-1 system will only see
> the two stereo channels.) MPEG Layer 3 (MP3) and MPEG-2 AAC (also known as
> NBC or unmatrix) are not supported by the DVD-Video standard. MPEG audio is
> not used much on DVDs, although some inexpensive DVD recording software
> programs use MPEG audio, even on NTSC discs, which goes against the DVD
> standard and is not supported by all NTSC players.

Ack.. replying to myself. I just re-read the last sentence above. I took this
to mean that MP3 audio is not supported on DVDs, although it reads as if MPEG
audio in general is not supported on NTSC discs. (Which would contradict all
the info earlier in the paragraph.) It's my understanding that MP2 audio is
supported with the parameters above, although it's admittedly rarely used.
Perhaps somebody here can confirm/clarify this. I'll do more researching when
I get a chance.

FWIW, I have never had one of my DVDs with MP2 audio fail to play in any of
the dozens of standalone players I've tried that can play burned discs. :) So
this is little more than curiosity on my part.

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

iD8DBQE/1RlTT8BYaKRUpkQRAsHFAJ4rOVo9C2WItmR4bQXX0ZDbqxGvKgCdHuzc
wkXZpJd/HNG8X95kgJ0dH1Q=
=ZTgl
-----END PGP SIGNATURE-----


warlord at MIT

Dec 8, 2003, 5:59 PM

Post #21 of 28 (16966 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

" James L. Paul" <james [at] mauibay> writes:

> Can you point me to the source for the version of GOPchop you are using?

http://outflux.net/unix/software/GOPchop/

-derek

--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord [at] MIT PGP key available


james at mauibay

Dec 8, 2003, 6:23 PM

Post #22 of 28 (16997 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

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

On Monday 08 December 2003 14:59, Derek Atkins wrote:
> " James L. Paul" <james [at] mauibay> writes:
> > Can you point me to the source for the version of GOPchop you are using?
>
> http://outflux.net/unix/software/GOPchop/

Thanks. I have major problems with that version 0.91 that is on that site. In
fact, sometimes I can't even get it to index a file output by my Freestyle
card. I don't have the indexing problems with 0.92pre3, but I do have broken
audio after the first cutpoint. I don't have time now to dig back into this
further but I'll check again when if I get a chance.

I also found that gop_fixup, which was written specifically to fix the broken
timestamps left by GOPchop, didn't seem to have any impact on my results.
Perhaps GOPchop has different results depending on the capture resolution? I
don't see why that would be so, but assuming we are both using the same
version I don't know why my results would be so different from yours.

Anyway, I consider you to be more fortunate that I, since I haven't gotten it
to work. ;) However, avidemux2 has been doing a great job and seems much more
feature-rich so I haven't been hurting lately. :)

> -derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/1SQNT8BYaKRUpkQRAjHgAKCOG4dCkckjz0vbpWjrONPG+nFnsgCfbhCv
8ukHjq6p45/6x/NHzCmj2/Y=
=sMTR
-----END PGP SIGNATURE-----


ou401cru02 at sneakemail

Dec 8, 2003, 8:41 PM

Post #23 of 28 (16987 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

On Mon, 8 Dec 2003 13:40:19 -1000, " James L. Paul james-at-mauibay.net
|mythtv/1.0-Allow|" <0ambhpgqea0t [at] sneakemail> said:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 08 December 2003 13:17, Derek Atkins wrote:
> > "Geoffrey Hausheer" <ou401cru02 [at] sneakemail> writes:
> > > Note that I have yet to see a PVR250 stream which is DVD compliant. DVD
> > > requires either an AC3 or PCM stream to be present, and I'm not aware of
> > > any way to get such a thing from the PVR250. I've yet to find an AC3
> > > encoder which is really compliant (the one that comes with ffmpeg is not
> > > compatible with my DVD player, and I've had to use commercial encoders in
> > > Windows to get compliant streams). Anyhow, that isn't really relevant as
> > > it has nothing to do with the issue at hand, I just thought I'd mention
> > > it.
> >
> > Not quite true.. A DVD can also use MP2 audio, which the PVR will do.
> > I was able to make a video DVD without any audio transcoding, and
> > it works just fine in my set-top DVD player.
>
> I just posted to this effect as well. Here's some specifics on DVD
> support for
> MPEG audio, from the excellent dvddemystified.com website:
>
> MPEG audio is multi-channel digital audio, using lossy compression from
> original PCM format with sample rate of 48 kHz at 16 or 20 bits. Both
> MPEG-1
> and MPEG-2 formats are supported. The variable bit rate is 32 kbps to 912
> kbps, with 384 being the normal average rate. MPEG-1 is limited to 384
> kbps.
> Channel combinations are (front/surround): 1/0, 2/0, 2/1, 2/2, 3/0, 3/1,
> 3/2,
> and 5/2. The LFE channel is optional with all combinations. The 7.1
> channel
> format adds left-center and right-center channels, but is rare for home
> use.
> MPEG-2 surround channels are in an extension stream matrixed onto the
> MPEG-1
> stereo channels, which makes MPEG-2 audio backwards compatible with
> MPEG-1
> hardware (an MPEG-1 system will only see the two stereo channels.) MPEG
> Layer
> 3 (MP3) and MPEG-2 AAC (also known as NBC or unmatrix) are not supported
> by
> the DVD-Video standard. MPEG audio is not used much on DVDs, although
> some
> inexpensive DVD recording software programs use MPEG audio, even on NTSC
> discs, which goes against the DVD standard and is not supported by all
> NTSC
> players.
>
I looked at this some time ago, and it seems that MP2 must be accompanied
by either AC3 or PCM to gaurantee a compatible disc. (For instance, you
can have an AC3 primary audio, and MP2 alternate-audio, and be
compliant). Note that SVCD only supports MP2 audio, and most players
that support SVCD will also support MP2-only DVDs, (effectively a DVD
with MP2 audio will be idnetical to SVCD at a higher bitrate) however,
this is not gauranteed.

Sorry, I don't have a reference for the above statement. I believe I
originally had documentation to back it up, but I can't find it now.
However, at one time I spent an awful lot of effort making the most
compatible DVDs I could for a video project, and found that the above
matched well with empirical tests. That said, if your player will play
an mp2 encoded DVD, and that is what you need, then that should be good
enough.

.Geoff


ou401cru02 at sneakemail

Dec 8, 2003, 8:42 PM

Post #24 of 28 (16990 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

On Mon, 8 Dec 2003 18:28:18 -0500, "Doug Larrick doug-at-ties.org
|mythtv/1.0-Allow|" <bccihm3msa0t [at] sneakemail> said:
> On 12/08/03 17:47:53, Geoffrey Hausheer wrote:
>
> > Also, I'd really like to get my hands on a MPEG2-TS stream from one
> > of the HDTV/DVB guys so I can work on making that work too, so if
> > anyone wants to snip ~5 minutes from such a beast and find a way to
> > get it to me, that'd help (MPEG2-TS won't be supported otherwise)
>
> I happen to have 38 seconds of MPEG-TS (80 MB!) lying around, and
> you're welcome to it, though please be kind as it's a (slow-uplink)
> cable modem. http::/jekyl.ddts.net/enterprise.mpg . If you truly need
> 5 minutes, I'll have to defer to somebody with a bigger pipe.
>
This should be perfect. I am downloading it now. I won't look at it
until the MPEG-PS stuff actually works, but I'm sure it will be useful.

.Geoff


developstuff at qwest

Dec 9, 2003, 12:58 AM

Post #25 of 28 (16998 views)
Permalink
Re: A prelude to transcoding MPEG2->MPEG2 [In reply to]

James L. Paul wrote:
> On Monday 08 December 2003 14:59, Derek Atkins wrote:
>
>>>" James L. Paul" <james [at] mauibay> writes:
>>>
>>>>Can you point me to the source for the version of GOPchop you are using?
>>>
>>>http://outflux.net/unix/software/GOPchop/
>
>
> Thanks. I have major problems with that version 0.91 that is on that site. In
> fact, sometimes I can't even get it to index a file output by my Freestyle
> card. I don't have the indexing problems with 0.92pre3, but I do have broken
> audio after the first cutpoint. I don't have time now to dig back into this
> further but I'll check again when if I get a chance.
>
> I also found that gop_fixup, which was written specifically to fix the broken
> timestamps left by GOPchop, didn't seem to have any impact on my results.
> Perhaps GOPchop has different results depending on the capture resolution? I
> don't see why that would be so, but assuming we are both using the same
> version I don't know why my results would be so different from yours.
>
> Anyway, I consider you to be more fortunate that I, since I haven't gotten it
> to work. ;) However, avidemux2 has been doing a great job and seems much more
> feature-rich so I haven't been hurting lately. :)
>
>
>>>-derek
>

I am using GOPchop 0.9.1 with one minor modification to avoid an endless loop because I'm using Gentoo's libmpeg2-0.3.2_pre20030625 ebuild and GOPchop 0.9.1 was written against mpeg2dec version 0.3.1. All of my streams are 720x480 with a bitrate of 4 Mbps default or 8 Mbps for high quality.

--
Craig Rindy

First page Previous page 1 2 Next page Last page  View All MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.