[mythtv-commits] Ticket #11435: recordedseek as recorded differs from mythcommflag
MythTV
noreply at mythtv.org
Sun Mar 31 20:36:49 UTC 2013
#11435: recordedseek as recorded differs from mythcommflag
----------------------------------+------------------------------
Reporter: blm-ubunet@… | Owner: stichnot
Type: Bug Report - General | Status: closed
Priority: minor | Milestone: unknown
Component: MythTV - Recording | Version: 0.26-fixes
Severity: low | Resolution: Works for me
Keywords: H264 recordedseek | Ticket locked: 0
----------------------------------+------------------------------
Comment (by blm-ubunet@…):
After attempting to study this:
http://www.itu.int/rec/T-REC-H.264-201201-I/en
and reference H264 decoder:
http://iphome.hhi.de/suehring/tml/
I went thru' H264Parser line by line trying to align to spec & reference
decoder when I got lost..
I think the premise that the recording starts on keyframe is wrong, that
first GOP is not decode-able without SPS/PPS.
Had to make changes to dtvrecorder.cpp to sync to SPS. A small change to
mpeg2 code was required because of common code (with H264).
H264Parser signals (outputs) I-frame or sliced refresh AVC.
I can not test H264 I-frame or mpeg2 video recording.
Tested with H264-AVC OTA broadcast & playback using VDPAU & OpenGL.
As the H264Parser is reused by avformatdecoder, I checked that HD-PVR &
HDHR samples play okay. My HD-PVR samples include 11159 (60p) & 50p..
Playback seeking is very good & cutlist editor faultless.
I don't think recording sync to SPS is the perfect solution but it is
better than sync to keyframe/AU.
My coding style is naive/simple & there are a few unused variables.
A git diff to master is possble in a week or so but for now diff files
only..
Thanks for your help..
ps: ignore the previous comment about "au_contains_keyframe_message" being
wrong..
--
Ticket URL: <http://code.mythtv.org/trac/ticket/11435#comment:14>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center
More information about the mythtv-commits
mailing list