[mythtv] [PATCH] better GOP detection for HDTV
Jason Hoos
jhoos at thwack.net
Thu Dec 18 11:36:15 EST 2003
Doug -
Received this off-list, looks like it might help. I modified your tsdump.C
program to look for the sequence headers he mentions (which I determined was
00 00 01 b3 with the help of Google -
http://andrew.csie.ncyu.edu.tw/zip/mpeg.htm), and the headers do exist in
the stream from that station. And they seem to occur at regular 30-picture
intervals.
When I get a chance I'll try modifying the GOP code to look for these as
well and see what happens, but I probably won't get to it until Saturday...
Jason
> -----Original Message-----
> From: WATLINGTON John FTRD/DIH/BOS [mailto:john.watlington at ftrd.us]
> Sent: Thursday, December 18, 2003 9:49 AM
> To: jhoos at thwack.net
> Cc: Development of mythtv
> Subject: Re: [mythtv] [PATCH] better GOP detection for HDTV
>
>
>
> I tried to post a reply to your question yesterday, but my reply was
> moderated out of existance.
>
> The MPEG2 video spec specifically states that GOP headers are
> optional. The point at which a bitstream should be cut is the
> sequence header (which tends to come right before a GOP header,
> if there is one.)
>
> John
>
> From Section 6.1.1.7 of the MPEG Video Specification:
>
> "Group of picture header is an optional header that can be used
> immediately before a coded I-frame to indicate to the decoder if the
> first consecutive B-pictures immediately following the coded I-frame
> can be reconstructed properly in the case of a random access. In
> effect, if the preceding reference frame is not available, those
> B-pictures, if any, cannot be reconstructed properly unless they only
> use backward prediction or intra coding. This is more
> precisely defined
> in the clause describing closed_gop and broken_link. A group
> of picture
> header also contains a time code information that is not used by the
> decoding process.
>
> In the coded bitstream, the first coded frame following a group of
> pictures header shall be a coded
> I-frame."
>
> On Thursday, December 18, 2003, at 01:09 AM, Jason Hoos wrote:
>
> > On Wed, Dec 17, 2003 at 09:08:59AM -0500, Doug Larrick wrote:
> >> If you have a recording from that station, try running
> tsdump, found
> >> here: <http://jekyl.ddts.net/tsdump.C> on the recording --
> it should
> >> closely mimic how hdtvrecorder is looking at the stream.
> >
> > I haven't had a chance to try the actual patch yet, but I
> did run the
> > tsdump.C program on a stream that I recorded from that station, and
> > it didn't find any GOPs. :( (It did find them just fine on another
> > station.)
> >
> > If you want to look at it, here is the output from a tsdump
> of a 10-15
> > second clip from that station:
> >
> > http://home.comcast.net/~jchoos/test_tsdump.gz
> >
> > And here is the clip itself:
> >
> > http://home.comcast.net/~jchoos/test.nuv (~16 MB)
> >
> > I'm all for finding a better way to deal with this station
> than using
> > the "treat the I-frame like the GOP marker" method, but I'm
> not sure if
> > there is one. Any ideas?
> >
> > Jason
> >
> >
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
More information about the mythtv-dev
mailing list