Page 1 of 1

audio out of sync but only when played via media steamer

Posted: Sat Jun 13, 2009 5:48 am
by RickMenHome
I have just rendered a mpeg2 movie and have found that the audio is out of sych but only when I play the file via my WD USB my media streamer onto my HDTV. I have no Out of Synch (OOS) issue when I play the rendered file in either VS2 or with Windows Media Player, but when I copy the file to an external hard drive and plug and play the file via the WD media steamer onto my HDTV I get an OOS issue.

The properties of the rendered file are:

MPEG2-Video, UFF
24 bits, 1920x1080 16:9
25 fps
data rate = 28,000
audio type = MPEG2 audio layer 2 files
48000Hz 16 bit stereo
384kbps

I have a few other rendered files, with the exact same properties, that I have done exactly the same workflow and have not noticed an OOS issue with those files when played on my HDTV via the WD media streamer (although those files do not have as much 'talking' bits as the troublesome file).

The troublesome file has about a dozen clips in a row of people talking. It appears that as the file progressing the OOS issue becomes more obivous. If I pause the file then resume playing the audio appears to line up again but then slowly start to drift apart the longer the file is played.

Any suggestions?

Posted: Sat Jun 13, 2009 8:06 am
by Clevo
Something you can try... when editing try using sound tracks in .wav format.

When you edit both video and sound tracks with both sources in a compressed format (mpg, mp3,wmv etc) when rendering to a new file type you increase the likelyhood of OOS issues as the video progresses.

Posted: Sat Jun 13, 2009 11:56 am
by mitchell65
Clevo wrote:when editing try using sound tracks in .wav format
I'm learning a lot from this Forum about audio files. Everyone seems to favour .wav files. Are they normally uncompressed so making them better for editing?

Posted: Sat Jun 13, 2009 1:23 pm
by skier-hughes
WAV is compressed, but much less than mp3.
mp3 is really like mpeg2 video, a format made for listening/watching rather than editing.

OP, Try outputing you final video with lpcm audio or better ac3, rather than the mpeg2.

Posted: Sun Jun 14, 2009 12:30 am
by RickMenHome
Thanks Clevo. Just before I tried your suggestion I searched the forum for other OOS related issues and came across various senior members' suggestions of turning off the 'smart render' option, anyway, I did do just that and no more OOS issue with the file. Just 1 further question, whats 'smart render' and OOS got to do with each other?

Thanks to all who assisted with this issue.

BTW, I did notice when I re-rendered with 'smart render' turned off that my file size increased my 10% (3.9B => 4.2G) and it took approx 50% longer to render (20 mins to 30 mins) the file.

Posted: Sun Jun 14, 2009 12:56 am
by Ken Berry
When you render an existing video file into another video file (even of the same format), you lose quality -- particularly when it is an mpeg video (mpeg-1, 2 or 4). This is because mpeg is by its nature a 'lossy' format, so each time you render it, it loses a generation of quality. This is cumulative and soon starts to show up with pixelation/blockiness and other quality artifacts.

SmartRender provides a partial way around this quality loss. When rendering a video of one format into the same format (from mpeg-2 to another mpeg-2, for instance, as you are doing), and using the same settings as the original, SmartRender only renders those parts of the video which have actually been edited e.g. where you have inserted a title, or a transition or a filter... The remainder, including its original quality, remains unchanged and is not re-rendered.

Using SmartRender thus means that less time is taken for the overall render as VS skips those parts that don't need re-rendering. I am surprised, though, that in your case there was so little difference in the times. Normally, when re-rendering a HDV project on my Quad 6600, it still takes over twice as long to render the project without SmartRender enabled as it does with it enabled...

I am unable to answer the question of why your final file was actually larger than the original. I would have thought that with some quality loss, the end file would have been a bit smaller. Hopefully someone else with a better technical grasp of the situation can provide an explanation.

Personally, with my own HDV videos, I *never* use SmartRender -- and have, in a variety of other threads, advised other users to do the same with their own high def video, whether AVCHD or HDV. (Few seem to take my advice, I have to admit! :cry: ) I obviously want to maintain the same high quality properties as the original, which I do. But I had noticed that using SmartRender, one or two other minor artifacts were occasionally introduced, including the occasional blip around a transition (as is suffered by AVCHD users both with and without SmartRender enabled). I never suffered any OOS problem. But not using SmartRender fixed those other minor problems. So now I just go away and do something else while the full -- and thus longer -- re-render takes place. I don't mind the extra time as I have learned to be very patient when editing video!

OOS problems were virtually always associated with SmartRender in VS versions 10 and earlier. Not everyone experienced them, and we have no idea what exact combination of computer architecture and software -- and user workflow -- might have caused the problem. Turning off SmartRender in those cases just about always solved the problem.

OOS has been almost non-existent since VS11 and 12 appeared on the scene. But the operative word is 'almost' -- as you have learned through personal experience. We are still unable to provide an explanation as to why it still occurs but only for a small handful of users, and not the great majority. But at least you now know a work-around...

Moreover, your high def settings are such high quality that one generation of quality loss in your case (caused by not using SmartRender) will just not be detectable by the human eye.

Posted: Sun Jun 14, 2009 5:06 am
by RickMenHome
Thanks Ken, That's informative, as always.