Log in

View Full Version : Mainconcept Reference - Slowly gets out of sync


CorpX
15th May 2009, 23:48
I'm trying to convert a huge (22gb) mpeg2 file into h264 so I can burn it onto an AVCHD. I first used TMPGENC to do this and the conversion went well. I converted the audio track separately into AC3 and muxed them together (using tsmuxer) with no problems.

I thought I'd give Reference a shot and in small trials, found that the quality of the encode was better using the 720p preset in Reference. When I mux the tracks again (Reference also doesnt support AC3), I notice sync issues. It's barely noticeable at first, but they get worse progressively. By the end, it's almost a 7 second delay (3hr 46min file).

Any ideas?


I thought drop Frames might be the issue, so I re-encoded it using 59.940DF instead of 59.940 and it still has the sync issues.

Dark Shikari
16th May 2009, 00:37
7 seconds sounds like a case of floating point rounding; remember, the framerate is not 59.94 but actually 60000/1001.

Also, why not use x264 for this? It'll give much better results than the Reference, which is a rather limited frontend for the Mainconcept library.

Ghitulescu
20th May 2009, 12:09
7 seconds sounds like a case of floating point rounding; remember, the framerate is not 59.94 but actually 60000/1001.

Also, why not use x264 for this? It'll give much better results than the Reference, which is a rather limited frontend for the Mainconcept library.

I'm not sure about MainConcept being the cause of this delay. I think it's the muxer. Why, simply, because the h.264 video file does not have a fps in it, it gets one after muxing.

But maybe I'm wrong. I used MCR only once, on about 90min long material, no synch errors at all. And I notice even 40ms delay.

Trahald
20th May 2009, 13:18
I'm not sure about MainConcept being the cause of this delay. I think it's the muxer. Why, simply, because the h.264 video file does not have a fps in it, it gets one after muxing.

But maybe I'm wrong. I used MCR only once, on about 90min long material, no synch errors at all. And I notice even 40ms delay.

While FPS is optional in h264, Most encoders put FPS into the streams, especially if they are putting in time codes like the OP's stream.

Any 720p files ive produced with x264 sync up fine after a tsmuxer mux but i havent used Main Concept in a long time and probably never for a full length stream. check the frame count, maybe the encoder is adding frames. also i dont know if tsmuxer uses hrd info when muxing or calculates on its own, because hrd timing (VFR) can make a stream run longer or shorter than its given FPS depending on how cpb removal delay is calculated. same can go for timie codes. if the encoder supports DF/NDF then it is using time codes. And perhaps tsmuxer is honoring that (unlikely) and either is interpreting them wrong or they are wrong. it can be a few things

Ghitulescu
27th May 2009, 16:10
While FPS is optional in h264, Most encoders put FPS into the streams, especially if they are putting in time codes like the OP's stream.

Any 720p files ive produced with x264 sync up fine after a tsmuxer mux but i havent used Main Concept in a long time and probably never for a full length stream. check the frame count, maybe the encoder is adding frames. also i dont know if tsmuxer uses hrd info when muxing or calculates on its own, because hrd timing (VFR) can make a stream run longer or shorter than its given FPS depending on how cpb removal delay is calculated. same can go for timie codes. if the encoder supports DF/NDF then it is using time codes. And perhaps tsmuxer is honoring that (unlikely) and either is interpreting them wrong or they are wrong. it can be a few things

My material was PAL, I mean HDTV 50i, no problems at all with NDF/DF that plague NTSC material (along with pedestal=black level and TC/IVTC).