Mercurial > mplayer.hg
changeset 16387:8f347723d3b3
Fixes suggested by Diego
author | gpoirier |
---|---|
date | Sun, 04 Sep 2005 16:57:51 +0000 |
parents | 9e1ba1ac3c7d |
children | 9bce6b40def2 |
files | DOCS/xml/en/encoding-guide.xml |
diffstat | 1 files changed, 9 insertions(+), 9 deletions(-) [+] |
line wrap: on
line diff
--- a/DOCS/xml/en/encoding-guide.xml Sun Sep 04 16:08:18 2005 +0000 +++ b/DOCS/xml/en/encoding-guide.xml Sun Sep 04 16:57:51 2005 +0000 @@ -1296,7 +1296,7 @@ broken sync. However, in some cases they can cause unnecessary skipping and duplication of frames, and possibly slight A/V desync, when used with proper input -(off course, A/V sync issues apply only if you process or copy the +(of course, A/V sync issues apply only if you process or copy the audio track while transcoding the video, which is strongly encouraged). Therefore, you may have to switch to basic A/V sync with the <option>-mc 0</option> option, or put this in your @@ -1371,7 +1371,7 @@ Though it may work in ideal cases, using <option>-nosound</option> is likely to hide some problems in your encoding command line setting. In other words, having a soundtrack during your encode assures you that, - provided you don't get messages such as + provided you do not see messages such as <quote>Too many audio packets in the buffer</quote>, you will be able to get proper sync. </para> @@ -1381,23 +1381,23 @@ You can for example copy the orignal soundtrack during the encode with <option>-oac copy</option> or convert it to a "light" 4 kHz mono WAV PCM with <option>-oac pcm -channels 1 -srate 4000</option>. - otherwise, in some cases, it will generate a video file that won't sync + Otherwise, in some cases, it will generate a video file that will not sync with the audio. - Such cases are when the number of video frames in the source file do + Such cases are when the number of video frames in the source file does not match up to the total length of audio frames or whenever there are discontinuities/splices where there are missing or extra audio frames. The correct way to handle this kind of problem is to insert silence or cut audio at these points. However <application>MPlayer</application> cannot do that, so if you - demux the AC3 and encode it with a separate app (or dump it to PCM with + demux the AC3 audio and encode it with a separate app (or dump it to PCM with <application>MPlayer</application>), the splices will be left incorrect and the only way to correct them is to drop/dup video frames at the splice. - As long as <application>MEncoder</application> sees the audio when it's - encoding the video, it can do this dropping/duping (which is usually ok + As long as <application>MEncoder</application> sees the audio when it is + encoding the video, it can do this dropping/duping (which is usually OK since it takes place at full black/scenechange, but if - <application>MEncoder</application> can't see the audio, it will just - process all frames as-is and they won't fit the final audio stream when + <application>MEncoder</application> cannot see the audio, it will just + process all frames as-is and they will not fit the final audio stream when you for example merge your audio and video track into a Matroska file. </para>