Hi all,
I've figured out the TS timing issue (issue #221). I have one quick fix, and there is another possible fix. I'm not sure which is actually better.
So... the problem: The channels that are broken only set the TS payload start bit for each MPEG sequence header (~ every 12 frames). The channels that work set the TS payload start bit for each MPEG picture header. On the broken channels, the sending of the picture slices for the first picture causes DTVRecorder::FindKeyframes() to stop searching for more start codes, so it never finds the rest of the pictures in the group.
Fix 1:
Comment out "_scanning_pes_header_for_gop = false;" in the 'video slice' section at the bottom of FindKeyframes(). Or just remove the variable _scanning_pes_header_for_gop entirely. See the patch below.
My concern with this fix: I'm not sure how likely it is that we'll find a spurious picture header during picture data. It doesn't seem to happen in my (limited) testing, and the spec seems to make it unlikely, but I'm not sure if it is impossible.
Fix 2:
The GOP timecode information contains a count of the number of frames we should have seen. Once you've found the group start code, you can pull out the time code information with:
int time_code = ((int)buffer[i+2] << 17) | ((int)buffer[i+3] << 9) |
((int)buffer[i+4] << 1) | ((buffer[i+5] & 0x80) >> 7);
if (!(time_code & 0x1000)) {
VERBOSE(VB_RECORD, QString("Bad marker bit in GOP header time code"));
}
bool drop_frame_flag = (time_code & 0x01000000);
int time_code_hours = (time_code >> 19) & 0x1F;
int time_code_mins = (time_code >> 13) & 0x3F;
int time_code_secs = (time_code >> 6) & 0x3F;
int time_code_pics = time_code & 0x3F;
Together with the number of frames per second, you can then calculate the number of frames past since the last GOP header. You can get the fps from the sequence header with:
int fps_code = (buffer[i+5] & 0xF0) >> 4;
/* need to look up actual fps from fps_code */With these together, we could stop counting the number of frames actually seen, and simply insert a Keyframe every seq or gop header, with the appropriate number of frames in it.
My concern with this fix: It changes the semantics of the position map. It is no longer the number of frames we've detected, it is the number of frames the stream has told us have passed. I think playback uses # frames displayed for its current location - that is closer to the old semantics.
Thoughts? Comments? I think fix 1 is probably the way to go - following the KISS principle.
Will :-}
Patch:
This patch implements the first fix above. Note: This patch is untested. I have tested commenting out the line that sets _scanning_pes_header_for_gop to false, but this patch removes that variable entirely.
remove_scanning_bool.diff
Description: Binary data
-- Dr William Uther National ICT Australia Phone: +61 2 9385 6357 Computer Science and Engineering Email: [EMAIL PROTECTED] University of New South Wales Web: http://www.cse.unsw.edu.au/~willu/ Sydney, Australia_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
