Significant audio delay on an avi file with blank audio
Hi! I have an avi file which seems to have "blank audio" during its first 14 seconds. However, mplayer plays immediately the audio. The problem can only be reproduced if you do not seek the stream (with -ss or a keyboard shortcut). 1) mplayer blank_audio.avi => the sound starts to play immediately and thus audio and video aren't synchronized, there is no sound during the last 14 seconds of the video file. 2) mplayer -ss 14 blank_audio.avi => sound and video are now synchronized as expected The video file : ftp://upload.mplayerhq.hu/MPlayer/incoming/blank_audio_delay.avi The output log of 1) : ftp://upload.mplayerhq.hu/MPlayer/incoming/blank_audio_delay.txt Cheers, -- Sébastien Mazy
Sébastien Mazy wrote:
Hi!
I have an avi file which seems to have "blank audio" during its first 14 seconds. However, mplayer plays immediately the audio. The problem can only be reproduced if you do not seek the stream (with -ss or a keyboard shortcut).
1) mplayer blank_audio.avi => the sound starts to play immediately and thus audio and video aren't synchronized, there is no sound during the last 14 seconds of the video file.
Have you tested what happens with the -delay option? What happens if you start playing with the -ss option and then try to seek back to before the sound began? Does it get out of sync, play video without audio (and remain in sync), or refuse to seek back that far? -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
Thanks for your answer! On Tue, Aug 5, 2008 at 10:04 PM, The Wanderer <inverseparadox@comcast.net> wrote:
Have you tested what happens with the -delay option?
mplayer -delay -14 blank_audio_delay.avi resulted in: - image lag during a few seconds + "Your system is too SLOW to play this!" message on stdout (which is not the case, my CPU is enough for a low-def divx) - the sound starting immediately, the video starting at 14s (though a negative value for -delay is supposed to delay the sound according to the man)
What happens if you start playing with the -ss option and then try to seek back to before the sound began? Does it get out of sync, play video without audio (and remain in sync), or refuse to seek back that far?
It goes out of sync, just as if I had started playing the file from the beginning. Mplayer skips the blank audio whenever you start playing before the assumed start of the sound at 14 seconds. Mplayer is not consistent with seeking with this video. If you seek before 14s (the approximate start of the non blank audio), the sound will always be 14s too early. If you seek after 14s, it will always be synchronized. It seems one can upload files on ftp://upload.mplayerhq.hu/ but not download them after. If you want to test the video I've uploaded again: http://dl.free.fr/pPpCUreUq That may also be a bug in the video, but VLC and totem (gstreamer backend) play that file fine. Cheers, -- Sébastien Mazy
Sébastien Mazy wrote:
Thanks for your answer!
On Tue, Aug 5, 2008 at 10:04 PM, The Wanderer <inverseparadox@comcast.net> wrote:
Have you tested what happens with the -delay option?
mplayer -delay -14 blank_audio_delay.avi
resulted in: - image lag during a few seconds + "Your system is too SLOW to play this!" message on stdout (which is not the case, my CPU is enough for a low-def divx)
Yeah - the "system too slow" message just means that the A and V values have gotten out of sync by more than a certain minimum, which in this case is roughly what we're asking for.
- the sound starting immediately, the video starting at 14s (though a negative value for -delay is supposed to delay the sound according to the man)
The sign of delay is a little hard to keep track of, and I've seen it be inconsistent between the different methods in the past. Try with a non-negative value as well and see if that changes anything.
What happens if you start playing with the -ss option and then try to seek back to before the sound began? Does it get out of sync, play video without audio (and remain in sync), or refuse to seek back that far?
It goes out of sync, just as if I had started playing the file from the beginning. Mplayer skips the blank audio whenever you start playing before the assumed start of the sound at 14 seconds.
My guess would be that there is, in fact, not "blank audio" in the file for those 14 seconds; my guess would be that there is *no* audio in the file for that period. If you demux the audio (using e.g. mplayer -ao pcm), prepend 14 seconds of silence (this can be created with e.g. sox and prepended with e.g. cat), and remux, does the problem go away?
Mplayer is not consistent with seeking with this video. If you seek before 14s (the approximate start of the non blank audio), the sound will always be 14s too early. If you seek after 14s, it will always be synchronized.
That sounds consistent to me...
It seems one can upload files on ftp://upload.mplayerhq.hu/ but not download them after.
Yes, that's intentional; to download, you need a non-anonymous account there, which the developers have. (I don't, although I used to.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Tue, Aug 5, 2008 at 11:41 PM, The Wanderer <inverseparadox@comcast.net> wrote:
Yeah - the "system too slow" message just means that the A and V values have gotten out of sync by more than a certain minimum, which in this case is roughly what we're asking for.
Thanks for the clarification.
The sign of delay is a little hard to keep track of, and I've seen it be inconsistent between the different methods in the past. Try with a non-negative value as well and see if that changes anything.
A positive value, delays the video as stated in the man page. The sound stills plays immediately.
My guess would be that there is, in fact, not "blank audio" in the file for those 14 seconds; my guess would be that there is *no* audio in the file for that period.
Sorry this "blank audio" vocabulary was confusing. There is no audio during the 14 first seconds of the file indeed. I can confirm that with VLC for example (I can hear my sound card coming out of auto-suspend power mode after 14s of playing, which shows that VLC does not send sound to the sound card before that time).
If you demux the audio (using e.g. mplayer -ao pcm), prepend 14 seconds of silence (this can be created with e.g. sox and prepended with e.g. cat), and remux, does the problem go away?
The demuxed audio doesn't contain any blank sound, which confirms what you said. I'm pretty sure prepending blank sound will solve the problem but it will not be the same video then.
Mplayer is not consistent with seeking with this video. If you seek before 14s (the approximate start of the non blank audio), the sound will always be 14s too early. If you seek after 14s, it will always be synchronized.
That sounds consistent to me...
Let me put an example: 1) you let mplayer play the file without interfering from the begining until 20s 2) you start playing at 20s directly (by seeking with a keyboard shortcut or the -ss option) In both cases you are at the same time of the video (20s), but you do not hear the same sound. 1) is 14 sec earlier than 2). That's not consistent.
It seems one can upload files on ftp://upload.mplayerhq.hu/ but not download them after.
Yes, that's intentional; to download, you need a non-anonymous account there, which the developers have. (I don't, although I used to.)
http://dl.free.fr/pPpCUreUq should be accessible by anyone. Since other players such as VLC/Xine/Totem can handle this file, I think there are two possibilities: - either it is "standard" (provided avi is a standard) to have a sound track in an avi file which starts at any time and mplayer doesn't handle this (-> bug) - or it isn't, a sound track should always start at 0s in an avi file and the other players are to blame for being too tolerant with a non standard avi file (). Cheers, -- Sébastien Mazy
participants (2)
-
Sébastien Mazy -
The Wanderer