[mythtv-commits] Ticket #1926: H.264 keyframe detection fixes
MythTV
mythtv at cvs.mythtv.org
Mon Jul 3 09:20:38 UTC 2006
#1926: H.264 keyframe detection fixes
-----------------------------------------+----------------------------------
Reporter: mark_kendall at btinternet.com | Owner: stuarta
Type: patch | Status: new
Priority: minor | Milestone: 0.20
Component: mythtv | Version: head
Severity: medium | Resolution:
-----------------------------------------+----------------------------------
Comment (by mark_kendall at btinternet.com):
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
--
Ticket URL: <http://cvs.mythtv.org/trac/ticket/1926>
MythTV <http://www.mythtv.org/>
MythTV
More information about the mythtv-commits
mailing list