I've been experimenting with writing some transcode scripts for H264 video sources (not attempting lossless cuts, just re-encode from specified start point to end point). Something I'm noticing is that MythTV seems to interpret time and frame in H264 videos differently than other programs (ffmpeg, handbrake, or vlc). For example, a frame late in an H264 video will be displayed with a time stamp in edit mode that is several seconds away from where that frame is reported by vlc. Handbrake appears to be closer to vlc (though it doesn't list current frame number, so it is difficult to determine if they align perfectly without more experimentation). Earlier frames are much closer across all tools. Is this expected?
I am using 0.27. Has anything changed in this regard in the newer releases?
Discrepancy in how software calculates H264 frames
Moderator: Forum Moderators
Re: Discrepancy in how software calculates H264 frames
I do not believe anything has changed in recent releases that would affect the behavior you see. I don't know why there is a difference.
Re: Discrepancy in how software calculates H264 frames
Did you rebuild the seek table (mythcommflag --rebuild)? If you have changed the video you need to do that. Also depending on the format of H264 you are using, rebuild may not work correctly, it may delete the seek table.
-
- Senior
- Posts: 265
- Joined: Sun Jun 15, 2014 1:08 am
Re: Discrepancy in how software calculates H264 frames
Broadcast transport streams typically have time offset between audio & video packets.
Video packet are sent early, so their PTS values are higher (later) at any point in the file stream.
AFAIK This eases support of out-of-order video frame packets (B-frames) decoding & video post-processing (GOP size dependent 100-500ms) with the minimal audio buffering.
DVB Broadcast mpeg-TS uses special B-frame sequences & not I-frames to minimise the peak bitrates which are a problem with the modulation scheme.
After emails with author of lossless-cut & MKVToolNix many years back (>5!).. concluded this:
MKVToolNix (mkvmerge/lossless-cut) uses the earliest PTS as time-zero (start). This will be an audio packet in a broadcast TS. MythTV seektable data must be time offset to use with most external tools.
http://lists.mythtv.org/pipermail/mytht ... 42494.html
http://lists.mythtv.org/pipermail/mytht ... 49285.html
MythTV is a little unique in that it uses first video packet as time-zero (start).
If you play broadcast TS in VLC you will notice that audio starts with blank video for 100-500ms because the matching video packets (with right PTS) are missing.
MediaInfo has a method to resolve the A-V packet PTS offset.
Guess should be possible to extract this info from ffprobe.
Video packet are sent early, so their PTS values are higher (later) at any point in the file stream.
AFAIK This eases support of out-of-order video frame packets (B-frames) decoding & video post-processing (GOP size dependent 100-500ms) with the minimal audio buffering.
DVB Broadcast mpeg-TS uses special B-frame sequences & not I-frames to minimise the peak bitrates which are a problem with the modulation scheme.
After emails with author of lossless-cut & MKVToolNix many years back (>5!).. concluded this:
MKVToolNix (mkvmerge/lossless-cut) uses the earliest PTS as time-zero (start). This will be an audio packet in a broadcast TS. MythTV seektable data must be time offset to use with most external tools.
http://lists.mythtv.org/pipermail/mytht ... 42494.html
http://lists.mythtv.org/pipermail/mytht ... 49285.html
MythTV is a little unique in that it uses first video packet as time-zero (start).
If you play broadcast TS in VLC you will notice that audio starts with blank video for 100-500ms because the matching video packets (with right PTS) are missing.
MediaInfo has a method to resolve the A-V packet PTS offset.
Guess should be possible to extract this info from ffprobe.