I don't mean to sound like I'm nagging, but could anybody (Arpi?) tell me if there are any plans for looking at the DVD encoding audio sync bug, as reported by myself and christopher j bottaro? That's the only thing that's stopping me from encoding my DVDs right now, as everything else I do with 0_90 CVS works flawlessly and awesomely. My first bugreport is available here: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report1/ ..and my second is at: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report2/ I'd really appreciate it if somebody could tell me what's going on. Thanks, Corey I would say that mplayer rules, but we all know that already. ;)
Corey Hickey wrote:
..and my second is at: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync
Oops, sorry, that should be: ftp://ftp.mplayerhq/hu/MPlayer/incoming/mencoder_dvd_audio_sync The one below is correct.
Thanks again, Corey
On Mon, Feb 10, 2003 at 06:34:56PM -0800, Corey Hickey wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html] I don't mean to sound like I'm nagging, but could anybody (Arpi?) tell me if there are any plans for looking at the DVD encoding audio sync bug, as reported by myself and christopher j bottaro? That's the only thing that's stopping me from encoding my DVDs right now, as everything else I do with 0_90 CVS works flawlessly and awesomely.
My first bugreport is available here: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report1/
..and my second is at: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report2/
I'd really appreciate it if somebody could tell me what's going on.
IMO this is a really serious bug that should be addressed before 0.90 final! The main purpose of mencoder is probably ripping dvds, and if it can't do that properly, it's quite broken... :( I'll try to do some testing soon, but right now I don't have a working box with dvd drive. So if someone else could check into this it would be very good! Rich
D Richard Felker III wrote:
I'll try to do some testing soon, but right now I don't have a working box with dvd drive. So if someone else could check into this it would be very good!
Rich
Excellent! I thought Christopher and I were alone on this. If there's anything I can do to facilitate this, I'd be more than happy to assist. Does the problem require a DVD drive, or just vob file(s)? I have a significant portion of one here: http://bugfood.casa-z.org/mpbug/report2/ ...and can provide several more if you need them (don't have a WHOLE lot of upstream, though). Heck, if you want a shell account on my machine, I can give you one too. :) Just mail me off the list if that would be helpful. -Corey
Hi,
ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report2/
I'd really appreciate it if somebody could tell me what's going on.
IMO this is a really serious bug that should be addressed before 0.90 final! The main purpose of mencoder is probably ripping dvds, and if it can't do that properly, it's quite broken... :(
heh is this the same problem as with mplayer before, that constant 200-300ms (sometimes random, change per chapter) delay? i thought the demuxer fix solved it for both mplayer and mencoder... A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu "However, many people beg for its inclusion in Debian. Why?" - Gabucino "Because having new software in Debian is good." - Josselin Mouette "Because having good software in Debian is new." - Gabucino
Arpi wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html] Hi,
ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report2/
I'd really appreciate it if somebody could tell me what's going on.
IMO this is a really serious bug that should be addressed before 0.90 final! The main purpose of mencoder is probably ripping dvds, and if it can't do that properly, it's quite broken... :(
heh is this the same problem as with mplayer before, that constant 200-300ms (sometimes random, change per chapter) delay? i thought the demuxer fix solved it for both mplayer and mencoder...
No, the problem is that when mencoding, a typical output status line looks like this: Pos:5662.8s 135773f (81%) 5fps Trem: 91min 750mb A-V:0.073 [811:93]]] Where A-V is constantly near a certain value somewhere between 0.000 and 0.100 (but that value is always between +- 0.030 and +- 0.080). Within a single movie, the A-V drifts around by about 0.015 (which isn't a problem) but is always consistantly near that certain value. For instance, as I watch the above movie get encoded, it is always between 0.065 and 0.075, which is definitely perceptible. Playing the encoded movie with -delay 0.070 looks just fine. Different movies have different values about which the A-V centers. Some are 0.030, some are 0.080, etc. Sorry, I have a hard time explaining this. Christopher might be able to describe the problem better. Also, take a look here: http://www.mplayerhq.hu/pipermail/mplayer-users/2003-February/029156.html Thanks again, Corey
this is hard for me to explain, but lemmie try. i wrote a perl script that examines mencoder's output and counts consective frames who's abs(A-V) value is greater than 0.03. so consider the following mencoder output: Pos:5662.8s 135773f (81%) 5fps Trem: 91min 750mb A-V:0.023 [811:93]]] Pos:5662.8s 135774f (81%) 5fps Trem: 91min 750mb A-V:0.013 [811:93]]] Pos:5662.8s 135775f (81%) 5fps Trem: 91min 750mb A-V:0.033 [811:93]]] Pos:5662.8s 135776f (81%) 5fps Trem: 91min 750mb A-V:0.043 [811:93]]] Pos:5662.8s 135777f (81%) 5fps Trem: 91min 750mb A-V:0.043 [811:93]]] Pos:5662.8s 135778f (81%) 5fps Trem: 91min 750mb A-V:0.013 [811:93]]] the perl script would spit out something like: frames 135775-135777, count 3, avg (0.033+0.043+0.043)/3 where the avg would the value of that expression. well, i've noticed some weirdness. if i use a recent version of mencoder, then pretty much the whole thing would be outta sync...like frames 100-end_frame, and when playing the divx, the audio would be noticibly off. if i use the dec 10, 2002 snapshot of mencoder, i still get lots and lots of chunks of frames that are off (by pretty high avgs also, like > 0.05), but the resulting divx would playback fine........ i honesty don't know if this means anything significant, its just something i've noticed. another weird thing i've noticed is that if i use mplayer -dvd 1 (dec 10th snapshot) to play certain dvds, the audio would be waaaay off. but if i encode the same dvd to divx using mencoder, the audio isn't off at all in the resulting divx... thanks for looking into this, i think mplayer/mencoder is great, i just wish i could upgrade from the dec 10th snapshot...=) -- christopher P.S. here is some output from my script. note that the divx that was created from this plays back with no AV sync problems...despite all the "AV desync" messages my script spits out... first pass mencoder -oac mp3lame -lameopts abr:br=96 -ovc frameno -o frameno.avi -ofps 23.976 -dvd 1 -aid 128 0% done, 0 mins remaining AV desync detected: range 11-38, count 27, avg 0.0540740740740741 0% done, 0 mins remaining AV desync detected: range 56-61, count 5, avg 0.0384 5% done, 12 mins remaining AV desync detected: range 85-9155, count 9070, avg 0.0483592061742018 6% done, 11 mins remaining AV desync detected: range 9158-10872, count 1714, avg 0.0480793465577597 11% done, 11 mins remaining AV desync detected: range 10876-18885, count 8009, avg 0.0478329379448131 13% done, 11 mins remaining AV desync detected: range 18899-21515, count 2616, avg 0.047663226299695 17% done, 10 mins remaining AV desync detected: range 21529-26598, count 5069, avg 0.0475241665022688 21% done, 9 mins remaining AV desync detected: range 26600-32936, count 6336, avg 0.0472250631313132 27% done, 9 mins remaining AV desync detected: range 32939-42492, count 9553, avg 0.0467689730974575 30% done, 8 mins remaining AV desync detected: range 42509-47392, count 4883, avg 0.0631484742985865 34% done, 8 mins remaining AV desync detected: range 47403-53501, count 6098, avg 0.0632100688750407 72% done, 3 mins remaining AV desync detected: range 111107-111110, count 3, avg 0.032 75% done, 3 mins remaining AV desync detected: range 114361-114374, count 13, avg 0.0418461538461538 100% done, 0 mins remaining AV desync detected: range 155903-155908, count 6, avg 0.04 100% done, 0 mins remaining this pass recommended a vbitrate of 801 On Tuesday 11 February 2003 01:58 am, Corey Hickey wrote:
No, the problem is that when mencoding, a typical output status line looks like this: Pos:5662.8s 135773f (81%) 5fps Trem: 91min 750mb A-V:0.073 [811:93]]]
Where A-V is constantly near a certain value somewhere between 0.000 and 0.100 (but that value is always between +- 0.030 and +- 0.080). Within a single movie, the A-V drifts around by about 0.015 (which isn't a problem) but is always consistantly near that certain value. For instance, as I watch the above movie get encoded, it is always between 0.065 and 0.075, which is definitely perceptible. Playing the encoded movie with -delay 0.070 looks just fine.
Different movies have different values about which the A-V centers. Some are 0.030, some are 0.080, etc.
Sorry, I have a hard time explaining this. Christopher might be able to describe the problem better. Also, take a look here: http://www.mplayerhq.hu/pipermail/mplayer-users/2003-February/029156.html
Thanks again, Corey
_______________________________________________ RTFM!!! http://www.MPlayerHQ.hu/DOCS Search: http://www.MPlayerHQ.hu/cgi-bin/htsearch http://mplayerhq.hu/mailman/listinfo/mplayer-users
On 03.02.11 Arpi pressed the following keys:
is this the same problem as with mplayer before, that constant 200-300ms (sometimes random, change per chapter) delay? i thought the demuxer fix solved it for both mplayer and mencoder...
Nom this is really a problem with DVD mastering. Audio and Video almost never start at the same time, the difference is what was reported by our vstrip test some months before. It is totally independent from the 200-300ms delay you've already handled. I mean, back when mplayer didn't solve this huge (~250ms) delay properly, mencoder showed only this <80ms difference which I handled with ogmmerge when muxing OGM. ogmmerge can quite preciselly cut/pad with silence AC3, Vorbis, PCM and MP3 sound. This difference AFAIR is rougly difference between PTS of first audio and video frame. Robert -- Bastard Operator From 149.156.96.35
Robert R. Wal wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html] On 03.02.11 Arpi pressed the following keys:
is this the same problem as with mplayer before, that constant 200-300ms (sometimes random, change per chapter) delay? i thought the demuxer fix solved it for both mplayer and mencoder...
Nom this is really a problem with DVD mastering. Audio and Video almost never start at the same time, the difference is what was reported by our vstrip test some months before.
It is totally independent from the 200-300ms delay you've already handled. I mean, back when mplayer didn't solve this huge (~250ms) delay properly, mencoder showed only this <80ms difference which I handled with ogmmerge when muxing OGM. ogmmerge can quite preciselly cut/pad with silence AC3, Vorbis, PCM and MP3 sound.
This difference AFAIR is rougly difference between PTS of first audio and video frame.
Robert
So, if I understand you correctly, mencoder and mplayer handle this in two different ways: Mplayer synchonizes audio and video based on the timestamps within each stream. At any given point, the positions within each stream may differ relative to the start of the stream. Mencoder muxes audio and video from the beginning of each stream. Each stream's position relative to its beginning is always the same. Am I on track here? Does this mean that mencoder ought to pad/trim the audio slightly so that the muxing starts off with audio and video in sync? -Corey
Hi,
So, if I understand you correctly, mencoder and mplayer handle this in two different ways: no
Mplayer synchonizes audio and video based on the timestamps within each stream. At any given point, the positions within each stream may differ relative to the start of the stream. yes
Mencoder muxes audio and video from the beginning of each stream. Each stream's position relative to its beginning is always the same. no!
the same a-v sync method is used in both. mplayer: AV_delay=(a_pts-delay-audio_delay)-v_pts; if(drop_frame_cnt>50+drop_message*250 && AV_delay>0.5){ ++drop_message; mp_msg(MSGT_AVSYNC,MSGL_ERR,MSGTR_SystemTooSlow); } x=AV_delay*0.1f; if(x<-max_pts_correction) x=-max_pts_correction; else if(x> max_pts_correction) x= max_pts_correction; if(default_max_pts_correction>=0) max_pts_correction=default_max_pts_correction; else max_pts_correction=sh_video->frametime*0.10; // +-10% of time if(!frame_time_remaining){ sh_audio->delay+=x; c_total+=x;} //correction mencoder: AV_delay=(a_pts-v_pts); AV_delay-=mux_a->timer-(mux_v->timer-(v_timer_corr+v_pts_corr)); // compensate input video timer by av: x=AV_delay*0.1f; if(x<-max_pts_correction) x=-max_pts_correction; else if(x> max_pts_correction) x= max_pts_correction; if(default_max_pts_correction>=0) max_pts_correction=default_max_pts_correction; else max_pts_correction=sh_video->frametime*0.10; // +-10% of time // sh_video->timer-=x; c_total+=x; v_pts_corr+=x; the difference is that mplayer compensates A-V by teh audio card's buffering delay, while mencoder doe sthe compensation of muxer's delay (preload). i can imagine that the <100ms delay comes from the audio codecs, probably from libmp3lame's buffering, especialy in VBR modes. there are ~38 audio frames for 1 sec, it means ~26ms/frame, so if it buffers up a few frames it may cause some delay. try encoding using -oac pcm, or -oac copy and check if the delay still exists. maybe i have to hack it a bit to compensate codec's (encoder) delay. also, it's possible that video encoder delays 1 frame, if using B frames. try -ovc rawrgb, if it solves a-v issue then it's the problem. A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu "However, many people beg for its inclusion in Debian. Why?" - Gabucino "Because having new software in Debian is good." - Josselin Mouette "Because having good software in Debian is new." - Gabucino
Hi! In that case would -mc 5 cure the desync with mencoder somewhat ? bye Denes On 2003. február 12. 21:27, Arpi wrote:
the difference is that mplayer compensates A-V by teh audio card's buffering delay, while mencoder doe sthe compensation of muxer's delay (preload).
i can imagine that the <100ms delay comes from the audio codecs, probably from libmp3lame's buffering, especialy in VBR modes. there are ~38 audio frames for 1 sec, it means ~26ms/frame, so if it buffers up a few frames it may cause some delay.
try encoding using -oac pcm, or -oac copy and check if the delay still exists. maybe i have to hack it a bit to compensate codec's (encoder) delay.
also, it's possible that video encoder delays 1 frame, if using B frames. try -ovc rawrgb, if it solves a-v issue then it's the problem.
A'rpi / Astral & ESP-team
Hi,
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html] Hi!
In that case would -mc 5 cure the desync with mencoder somewhat ?
no. why should it? mencoder just doens't know about the codec delaying the data.
bye Denes
On 2003. február 12. 21:27, Arpi wrote:
the difference is that mplayer compensates A-V by teh audio card's buffering delay, while mencoder doe sthe compensation of muxer's delay (preload).
i can imagine that the <100ms delay comes from the audio codecs, probably from libmp3lame's buffering, especialy in VBR modes. there are ~38 audio frames for 1 sec, it means ~26ms/frame, so if it buffers up a few frames it may cause some delay.
try encoding using -oac pcm, or -oac copy and check if the delay still exists. maybe i have to hack it a bit to compensate codec's (encoder) delay.
also, it's possible that video encoder delays 1 frame, if using B frames. try -ovc rawrgb, if it solves a-v issue then it's the problem.
A'rpi / Astral & ESP-team
_______________________________________________ RTFM!!! http://www.MPlayerHQ.hu/DOCS Search: http://www.MPlayerHQ.hu/cgi-bin/htsearch http://mplayerhq.hu/mailman/listinfo/mplayer-users
A'rpi / Astral & ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu "However, many people beg for its inclusion in Debian. Why?" - Gabucino "Because having new software in Debian is good." - Josselin Mouette "Because having good software in Debian is new." - Gabucino
Arpi wrote:
try encoding using -oac pcm, or -oac copy and check if the delay still exists. maybe i have to hack it a bit to compensate codec's (encoder) delay.
also, it's possible that video encoder delays 1 frame, if using B frames. try -ovc rawrgb, if it solves a-v issue then it's the problem.
A'rpi / Astral & ESP-team
Ok, here's a few tests. I just watched the A-V meter for each test and observed where it seemed to average. The values I give are imprecise, but the differences between tests are noticable. -oac mp3lame -ovc lavc 0.78 -oac copy -ovc lavc 0.56 -oac pcm -ovc lavc 0.40 I tried -ovc rawrgb for each of the three audio codecs, but couldn't see any difference. All tests were done on "fastandfurious.vob" ftp://ftp.mplayerhq/hu/MPlayer/incoming/mencoder_dvd_audio_sync http://bugfood.casa-z.org/mpbug/report2/ ...with a simple line like this: mencoder fastandfurious.vob -ovc lavc -lavcopts vcodec=mpeg4 -oac pcm -ofps 23.976 Also, I noticed that when I remove -ofps, the A-V values are very small. I don't know if that helps you any. Thanks, Corey
my bug report is in: ftp://ftp.mplayerhq.hu/MPlayer/incoming/kingpin_test.tar.bz2 it includes a sample divx that demonstrates the problem, a verbose log of mencoder's output which made the divx, and a text file describing the problem. i guess what you really need is a stream dump of like the first chapter of the dvd that causes the problem? isn't that going to be a huge file? would it be acceptable for me to upload it to the ftp server? i'm not too saavy with digital media terminology, but a stream dump is just like having the vob file, right? -- christopher On Monday 10 February 2003 08:34 pm, Corey Hickey wrote:
[Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html] I don't mean to sound like I'm nagging, but could anybody (Arpi?) tell me if there are any plans for looking at the DVD encoding audio sync bug, as reported by myself and christopher j bottaro? That's the only thing that's stopping me from encoding my DVDs right now, as everything else I do with 0_90 CVS works flawlessly and awesomely.
My first bugreport is available here: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report1/
..and my second is at: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report2/
I'd really appreciate it if somebody could tell me what's going on.
Thanks, Corey
I would say that mplayer rules, but we all know that already. ;)
_______________________________________________ RTFM!!! http://www.MPlayerHQ.hu/DOCS Search: http://www.MPlayerHQ.hu/cgi-bin/htsearch http://mplayerhq.hu/mailman/listinfo/mplayer-users
On Mon, Feb 10, 2003 at 18:34 -0800, Corey Hickey wrote:
I don't mean to sound like I'm nagging, but could anybody (Arpi?) tell me if there are any plans for looking at the DVD encoding audio sync bug, as reported by myself and christopher j bottaro? That's the only thing that's stopping me from encoding my DVDs right now, as everything else I do with 0_90 CVS works flawlessly and awesomely.
My first bugreport is available here: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report1/
..and my second is at: ftp://ftp.mplayerhq/hu/MPlayer/incoming/avsync http://bugfood.casa-z.org/mpbug/report2/
I'd really appreciate it if somebody could tell me what's going on. ...
Hi, Is there any chance that disabling the new telecine detection and a/v delay fix would fix the a/v sync for mencoder ? mencoder seemed to be producing files that were in sync for me with ntsc dvds and `-ofps 23.976` before the telecine detection and a/v delay fix. Maybe a mencoder command line switch would be possible unless a better fix is found? I've tried playing a couple dvds and mplayer rc4 now plays ntsc dvds flawlessly without the delay and all the choppiness is gone. This is great! Thank you to Arpi and the developers. But i'm sorry to hear about the a/v sync trouble with mencoder now. I haven't tried recent mencoder builds but files I made dvd -> mpeg4 with older mencoder didn't seem to have any a/v sync problems and they looked very smooth to me. Michael
participants (7)
-
Arpi -
Balatoni Denes -
christopher j bottaro -
Corey Hickey -
D Richard Felker III -
Michael Waters -
Robert R. Wal