H.264 keyframe detection fixes

[mark_kendall@…]

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.

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

[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

[anonymous]

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

[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

[Stuart Auchterlonie]

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

[mark_kendall@…]

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

[Stuart Auchterlonie]

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