Discrepancy in how software calculates H264 frames

Have a MythTV related problem? Ask for help from other MythTV users here.

Moderator: Forum Moderators

Post Reply
mr_tea
Junior
Posts: 21
Joined: Tue Apr 11, 2017 2:47 am
United States of America

Discrepancy in how software calculates H264 frames

Post by mr_tea »

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?
User avatar
pgbennett
Developer
Posts: 503
Joined: Mon Apr 27, 2015 5:41 pm
United States of America

Re: Discrepancy in how software calculates H264 frames

Post by pgbennett »

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.
User avatar
pgbennett
Developer
Posts: 503
Joined: Mon Apr 27, 2015 5:41 pm
United States of America

Re: Discrepancy in how software calculates H264 frames

Post by pgbennett »

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.
blm-ubunet
Senior
Posts: 265
Joined: Sun Jun 15, 2014 1:08 am
Cambodia

Re: Discrepancy in how software calculates H264 frames

Post by blm-ubunet »

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.
Post Reply