H264 audio sync

[dcoffset]

I've noticed this on several projects previously where H264 video files appear to introduce a small offset on the corresponding audio file of 1-2 frames compared to a more reliable codec eg. ProRes.

On a recent project, time was of the essence and so I grudgingly accepted an H264 to reconform (with timecode burned in the frame). Before using the H264 file, I convert it using Shutterencoder to MXF (Avid DNX HD codec, OP-atom format) and then import it into PT. The strange thing is the video was in sync and I could verify this with the timecode, but the audio had been pushed back by a frame compared to the ProRes audio reference and the OMF (admittedly different edits so could be an issue caused elsewhere).

So I decided to try this myself, and I made a test video file in Premiere (same NLE as the project). I insert academy leader with tone and timecode... I export MXF and everything lines up on import. However, with H264 the video is in the right place but this time the audio is early by ~520 samples (huh?!?!?).

Anyone else observed this? Is H264 audio sync altered on encoding or is it an issue with the conversion back to MXF or via direct audio import into Pro Tools? Either way, it basically means H264 cannot be trusted as a reference for audio sync.

ps. I knew H264 couldn't be trusted beforehand just wanted to confirm this, and I know 520 samples is not much altho' I've seen up to 1-2 frames diff... I'm hoping I missed something here :/
pps. On my test, H264 export setting in Premiere were High Quality 720p on a 23.976fps sequence (Avid DNX).

[Wizzoboy]

H264, due to the nature of Long GOP codecs, is not a good codec to work with in PT. Sync can be haphazard when stopping and starting playback, especially if you are trying to spot fx etc. I've found that DNxHD 36 is reliable every time.

[JFreak]

520 samples is over 10ms, it is a lot. Monitoring voiceover would be impossible while it does not yet lose lip sync (one frame at 48k = 1920 samples)

[dcoffset]

Originally Posted by Wizzoboy

H264, due to the nature of Long GOP codecs, is not a good codec to work with in PT. Sync can be haphazard when stopping and starting playback, especially if you are trying to spot fx etc. I've found that DNxHD 36 is reliable every time.

I'm not working with an H264 file, as I state in my original msg the file has been converted to DNxHD 36 prior to import in the session. I only tested importing an H264 to see if there was any difference if the file was converted externally or via Pro Tools (audio import).

My observation is that when an H264 is decoded (or even perhaps encoded) it introduces an audio offset, and therefore there is no way of using it for sync reference when importing in Pro Tools. I understand GOP codecs cannot be used for sync from a visual standpoint, but I did expect the audio would be correct...

[its2loud]

Originally Posted by dcoffset

I'm not working with an H264 file, as I state in my original msg the file has been converted to DNxHD 36 prior to import in the session. I only tested importing an H264 to see if there was any difference if the file was converted externally or via Pro Tools (audio import).

My observation is that when an H264 is decoded (or even perhaps encoded) it introduces an audio offset, and therefore there is no way of using it for sync reference when importing in Pro Tools. I understand GOP codecs cannot be used for sync from a visual standpoint, but I did expect the audio would be correct...

I do recall seeing this anomaly a few years back. The work around was to ask the provider of the video reference to place an accurate 2 pop in the audio reference. This way you can always accurately move it back where it needs to be.

[dcoffset]

Originally Posted by its2loud

I do recall seeing this anomaly a few years back. The work around was to ask the provider of the video reference to place an accurate 2 pop in the audio reference. This way you can always accurately move it back where it needs to be.

Yes that's what I thought as a workaround, although I tried that in my Premiere test and the 2Pop ended in the right place but started early (I assume this is a bug as the pop should be 1 frame long)