[mythtv] [PATCH] better GOP detection for HDTV

[Jason Hoos]

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