Opened 14 years ago

Closed 13 years ago

#1926 closed patch (fixed)

H.264 keyframe detection fixes

Reported by: mark_kendall@… Owned by: Stuart Auchterlonie
Priority: minor Milestone: 0.20
Component: mythtv Version: head
Severity: medium Keywords: h264 hd
Cc: Ticket locked: no

Description

This patch fixes two issues with h.264 frame detection.

Firstly, a state change and hence frame count increment would be triggered for each slice in a picture. Typically this meant the frame count running at 6x the actual frame count. I've tightened it up to ensure state changes are only triggered when needed.

Secondly, the BBC H.264 trial broadcasts do not use IDR slice types - which the keyframe detection relies on. I've re-worked based on the assumption that only an access unit containing an IDR contains a sequence parameter set - this seems to tie up with the standard and works for the streams I have.

I now get accurate position maps for the BBC trials (dvb-s and dvb-t) and in conjunction with ticket:1925 should fully enable these broadcasts in mythtv.

Clearly I can't test this patch extensivley but it does also work for some h.264 transport streams I have from Germany (AnixeHD) and the US (KOAT 7?) passed in via the crcipnetworkrecorder.

Attachments (2)

h264utils.diff (2.2 KB) - added by anonymous 14 years ago.
h264.diff (399 bytes) - added by anonymous 13 years ago.

Download all attachments as: .zip

Change History (10)

Changed 14 years ago by anonymous

Attachment: h264utils.diff added

comment:1 Changed 14 years ago by Stuart Auchterlonie

Keywords: h264 hd added
Milestone: 0.20
Owner: changed from Isaac Richards to Stuart Auchterlonie
Version: head

comment:2 Changed 14 years ago by tim@…

This is working on the live bbc HD streams. however it seems to play for a few frames <1 second and then pause and play for a few more. This patch applied cleanly however 1925 didn't this may be the cause of my problems. Would you like some logs to diagnose?

comment:3 Changed 14 years ago by mark_kendall@…

The pauses are because it is a 20Mbs/s H.264 1080i stream - you will need a top of the range cpu to get full frame rate playback. The ffmpeg h.264 decoder doesn't seem to be the fastest either.

My Athlon XP 3000+ overclocked to 2.4Ghz can only manage around 15 fps.

Mark

comment:4 Changed 13 years ago by anonymous

this patch doesn't seem to apply cleanly anymore it fails at line 114

comment:5 Changed 13 years ago by mark_kendall@…

Sorry for the delay - I've been away for a few weeks.

I'll revisit the patch again in the next few days, though I can't see why it no longer applies cleanly.

While on my travels, I took a more detailed look at the standard (bedtime reading anyone!) and realised the 'error' in my sps assumption however. The definitions clearly state that a sequence parameter set can span one or more video sequences (each video sequence containing one keyframe). Hence it might undercook the number of keyframes. I suspect it will work for the vast majority of streams out there though.

The alternative is also clear from the definitions. An IDR picture (or keyframe) is defined as a picture where all slices are I or SI slices. So we need to keep a track of the slice types and act accordingly. I've coded this up outside of myth and it works on everything I can throw at it and should, in theory, be totally standard compliant. It does require minimal syntax header decoding, however, which will make the patch slightly more invasive - but on the upside it will give a framework for more extensive syntax header decoding which will enable us to do fully compliant access unit detection in the future if needed (per 7.4.1.2.4 in the standard)

Does anyone have any preferences on the approach to take?

Mark

comment:6 Changed 13 years ago by Stuart Auchterlonie

Resolution: fixed
Status: newclosed

(In [10574]) Closes #1926, by applying patch

comment:7 Changed 13 years ago by mark_kendall@…

Resolution: fixed
Status: closedreopened

Small ommission from previous changeset - I only noticed recently when I did my first clean checkout for a while.

Attached patch ensures recording lengths are accurate (h264 test transmissions report 6* framerate otherwise)

Mark

Changed 13 years ago by anonymous

Attachment: h264.diff added

comment:8 Changed 13 years ago by Stuart Auchterlonie

Resolution: fixed
Status: reopenedclosed

(In [11027]) Closes #1926. Fixes keyframe detection for h264 based HD streams.

Note: See TracTickets for help on using tickets.