[mythtv] [PATCH] more pcHDTV channel-change improvements

[Jason Hoos]

On Wednesday 22 October 2003 08:17 pm, Doug Larrick wrote:
> The following patch again improves channel-change behavior for the
> pcHDTV card.  It does two things:
> 1. Delays output until a GOP frame is encountered, both when starting
> and at channel change, under the assumption the player will do a better
> job with less distracting video artifacts and potential crashes if it
> has an I frame to start with.
>...

Not sure if I'm the only one seeing this, but... this patch seems to have
broken something for me. :(

In particular, I can't seem to receive my local ABC affiliate (WLS, Chicago
area).  Not sure if any other channels are affected since I haven't had a
chance to check yet (there's only one other station I can pick up with my
current antenna).  Reverting to the previous version of hdtvrecorder.cpp
fixed the problem for the moment, so given that and some debugging I did, I
suspect that the GOP stuff has something to do with it.

What's happening is this - when I go into LiveTV, the backend tunes to the
station, thinks for a while, then eventually prints a message to the effect
of "No data from capture card for 25 seconds, game over man".  I've looked
into the problem a little bit with some printf-debugging on
hdtvreceiver.cpp, and it appears that the code is never finding the GOP
frames from this station.  I put printf's in the FindKeyframes method inside
the "// picture_start" and "// group_of_pictures" if statements;  when it
runs I get lots of "picture_start" messages, but no "group of pictures"
messages.  

In addition, I dumped one of the successfully recorded streams via an 'od'
command to look for the sequence bytes that the code was looking for.  I
found many occurrences of the '00 00 01 00' sequence, but few or none of the
'00 00 01 b8' sequence.  I was able to find the '00 00 01 b8' sequence in a
stream from the other station (WGN), but I don't remember if I actually
tried recording from that station with the latest version (I gave up and
went to bed at some point :) ).  

I hope to dig into this deeper tonight, but if anyone has any suggestions of
what to look for I'd appreciate it.  Is there another sequence of bytes that
the code could told to look for?  Or can anyone point me at a good reference
for what the MPEG video inside of an ATSC stream should look like so I can
pick one apart and see what's missing or why the GOP frames aren't being
found?  (I do know about the TS format docs at www.atsc.org, but I didn't
see anything there about how the video itself should be formatted...)

I could also make a clip from this station available if someone else wants
to pick it apart...

Jason