another FAQ that all devs know the answer to but is not in the DOCS. hopefully its formatted correctly... pls check it before apply :) -compn
On Tue, Nov 22, 2005 at 10:23:02PM -0500, compn wrote:
another FAQ that all devs know the answer to but is not in the DOCS.
hopefully its formatted correctly... pls check it before apply :)
--- DOCS/xml/en/faq.xml 20 Oct 2005 23:07:55 -0000 1.98 +++ DOCS/xml/en/faq.xml 23 Nov 2005 00:38:42 -0000 @@ -708,6 +708,13 @@ </itemizedlist> </para></answer> </qandaentry> +<qandaentry> +<question><para> +How can I get rid of a/v desync while seeking through .rm stream? +</para></question> +<answer><para> +<option>-mc 10</option> can help. +</para></answer> </qandadiv>
The <qandaentry> tag is never closed. It's also not forbidden to insert empty lines between FAQ entries ;) Applied, thanks. Diego
On Tue, Nov 22, 2005 at 10:23:02PM -0500, compn wrote:
another FAQ that all devs know the answer to but is not in the DOCS.
hopefully its formatted correctly... pls check it before apply :) -compn
Index: DOCS/xml/en/faq.xml =================================================================== RCS file: /cvsroot/mplayer/main/DOCS/xml/en/faq.xml,v retrieving revision 1.98 diff -u -r1.98 faq.xml --- DOCS/xml/en/faq.xml 20 Oct 2005 23:07:55 -0000 1.98 +++ DOCS/xml/en/faq.xml 23 Nov 2005 00:38:42 -0000 @@ -708,6 +708,13 @@ </itemizedlist> </para></answer> </qandaentry> +<qandaentry> +<question><para> +How can I get rid of a/v desync while seeking through .rm stream? +</para></question> +<answer><para> +<option>-mc 10</option> can help. +</para></answer> </qandadiv>
<qandadiv id="faq-dvd">
I do not suggest such big value. All the real files I have with desync can be fixed with -mc .1 and using .1 has an advantage over bigger values. The fact is that after a seek while playing a real file with the option -mc n, audio and video are out of sync and it takes about 2*n+4 sec to regain the sync. So if n is 10, it takes more than 20 seconds to resync. If n is .1, it takes only few seconds. If you use also the option -autosync 10 togheter with -mc n then the time necessary to resync is about n+1. The value of the argument of -autosync does not seem to play a relevant role. Any values seems good. If n is .1 it is also not necessary to use -autosync. I think the suggestion shuld be to use the lower possible value of n that keep the sync, starting with .1 and increasing it if a low value isn't good enough. Giacomo
On Wednesday 23 November 2005 17:16, Giacomo Comes wrote:
I do not suggest such big value. All the real files I have with desync can be fixed with -mc .1 and using .1 has an advantage over bigger values.
All the real files I have start with about 20 - 30 seconds of desync. -mc 10 nearly completely halts video until audio catches up. With -mc 0.1, it'd take ages for this to happen.
On Wed, Nov 23, 2005 at 05:47:17PM +0200, Jan Knutar wrote:
On Wednesday 23 November 2005 17:16, Giacomo Comes wrote:
I do not suggest such big value. All the real files I have with desync can be fixed with -mc .1 and using .1 has an advantage over bigger values.
All the real files I have start with about 20 - 30 seconds of desync. -mc 10 nearly completely halts video until audio catches up. With -mc 0.1, it'd take ages for this to happen.
Does it make any difference if you add -autosync? Giacomo
On Wed, Nov 23, 2005 at 11:16:52AM -0400, Giacomo Comes wrote:
On Tue, Nov 22, 2005 at 10:23:02PM -0500, compn wrote:
+<question><para> +How can I get rid of a/v desync while seeking through .rm stream? +</para></question> +<answer><para> +<option>-mc 10</option> can help.
I do not suggest such big value. All the real files I have with desync can be fixed with -mc .1 and using .1 has an advantage over bigger values. The fact is that after a seek while playing a real file with the option -mc n, audio and video are out of sync and it takes about 2*n+4 sec to regain the sync. So if n is 10, it takes more than 20 seconds to resync. If n is .1, it takes only few seconds. If you use also the option -autosync 10 togheter with -mc n then the time necessary to resync is about n+1. The value of the argument of -autosync does not seem to play a relevant role. Any values seems good. If n is .1 it is also not necessary to use -autosync.
-mc 10 works satisfactorily with all the broken samples I have. Could you provide one of your samples for comparison? Diego
On Thu, Nov 24, 2005 at 12:16:19AM +0100, Diego Biurrun wrote:
On Wed, Nov 23, 2005 at 11:16:52AM -0400, Giacomo Comes wrote:
On Tue, Nov 22, 2005 at 10:23:02PM -0500, compn wrote:
+<question><para> +How can I get rid of a/v desync while seeking through .rm stream? +</para></question> +<answer><para> +<option>-mc 10</option> can help.
I do not suggest such big value. All the real files I have with desync can be fixed with -mc .1 and using .1 has an advantage over bigger values. The fact is that after a seek while playing a real file with the option -mc n, audio and video are out of sync and it takes about 2*n+4 sec to regain the sync. So if n is 10, it takes more than 20 seconds to resync. If n is .1, it takes only few seconds. If you use also the option -autosync 10 togheter with -mc n then the time necessary to resync is about n+1. The value of the argument of -autosync does not seem to play a relevant role. Any values seems good. If n is .1 it is also not necessary to use -autosync.
-mc 10 works satisfactorily with all the broken samples I have. Could you provide one of your samples for comparison?
I have hundreds of real file like that. Unfortunately the web site that was providing them has changed format, moving from Real to Windows Media Player. So there are no more examples downloadable from the net. I put one short examples in http://encode2mpeg.sf.net/real/ Giacomo
On Mon, Dec 05, 2005 at 04:36:38PM -0400, Giacomo Comes wrote:
On Thu, Nov 24, 2005 at 12:16:19AM +0100, Diego Biurrun wrote:
-mc 10 works satisfactorily with all the broken samples I have. Could you provide one of your samples for comparison?
I have hundreds of real file like that. Unfortunately the web site that was providing them has changed format, moving from Real to Windows Media Player. So there are no more examples downloadable from the net.
I put one short examples in http://encode2mpeg.sf.net/real/
I don't get A/V desync with that file... Diego
On Wed, Dec 07, 2005 at 01:44:47AM +0100, Diego Biurrun wrote:
On Mon, Dec 05, 2005 at 04:36:38PM -0400, Giacomo Comes wrote:
On Thu, Nov 24, 2005 at 12:16:19AM +0100, Diego Biurrun wrote:
-mc 10 works satisfactorily with all the broken samples I have. Could you provide one of your samples for comparison?
I have hundreds of real file like that. Unfortunately the web site that was providing them has changed format, moving from Real to Windows Media Player. So there are no more examples downloadable from the net.
I put one short examples in http://encode2mpeg.sf.net/real/
I don't get A/V desync with that file...
You are right, that particular file does not show desync if you simply play it, but it will show it if you do one seek (and don't use -mc), however it is just an example of the fact that it makes a big difference during seek if you give -mc 10 (~24 seconds to resync) and -mc .1 (few seconds) I can provide bigger files that will show also the desync during playback if you are intrested. Giacomo
On Wed, Dec 07, 2005 at 11:18:44AM -0400, Giacomo Comes wrote:
On Wed, Dec 07, 2005 at 01:44:47AM +0100, Diego Biurrun wrote:
On Mon, Dec 05, 2005 at 04:36:38PM -0400, Giacomo Comes wrote:
On Thu, Nov 24, 2005 at 12:16:19AM +0100, Diego Biurrun wrote:
-mc 10 works satisfactorily with all the broken samples I have. Could you provide one of your samples for comparison?
I have hundreds of real file like that. Unfortunately the web site that was providing them has changed format, moving from Real to Windows Media Player. So there are no more examples downloadable from the net.
I put one short examples in http://encode2mpeg.sf.net/real/
I don't get A/V desync with that file...
You are right, that particular file does not show desync if you simply play it, but it will show it if you do one seek (and don't use -mc), however it is just an example of the fact that it makes a big difference during seek if you give -mc 10 (~24 seconds to resync) and -mc .1 (few seconds) I can provide bigger files that will show also the desync during playback if you are intrested.
Yes, please. Diego
On Wed, Dec 07, 2005 at 05:01:03PM +0100, Diego Biurrun wrote:
On Wed, Dec 07, 2005 at 11:18:44AM -0400, Giacomo Comes wrote:
On Wed, Dec 07, 2005 at 01:44:47AM +0100, Diego Biurrun wrote:
On Mon, Dec 05, 2005 at 04:36:38PM -0400, Giacomo Comes wrote:
On Thu, Nov 24, 2005 at 12:16:19AM +0100, Diego Biurrun wrote:
-mc 10 works satisfactorily with all the broken samples I have. Could you provide one of your samples for comparison?
I have hundreds of real file like that. Unfortunately the web site that was providing them has changed format, moving from Real to Windows Media Player. So there are no more examples downloadable from the net.
I put one short examples in http://encode2mpeg.sf.net/real/
I don't get A/V desync with that file...
You are right, that particular file does not show desync if you simply play it, but it will show it if you do one seek (and don't use -mc), however it is just an example of the fact that it makes a big difference during seek if you give -mc 10 (~24 seconds to resync) and -mc .1 (few seconds) I can provide bigger files that will show also the desync during playback if you are intrested.
Yes, please.
I did put another real file. This one will show an increasing desync during playback. This is only half of the complete file, but it's playable. Tell me when you finish to take it and I will put the second part. Giacomo
On Wed, Dec 07, 2005 at 11:18:44AM -0400, Giacomo Comes wrote:
On Wed, Dec 07, 2005 at 01:44:47AM +0100, Diego Biurrun wrote:
I don't get A/V desync with that file...
You are right, that particular file does not show desync if you simply play it, but it will show it if you do one seek (and don't use -mc), however it is just an example of the fact that it makes a big difference during seek if you give -mc 10 (~24 seconds to resync) and -mc .1 (few seconds) I can provide bigger files that will show also the desync during playback if you are intrested.
Got your sample, you are right. FAQ entry fixed. Diego
participants (4)
-
compn -
Diego Biurrun -
Giacomo Comes -
Jan Knutar