From: Sylvain \Skarsnik\ C. <sco...@gm...> - 2004-11-29 12:47:46
|
Hi, I already repport this bug in the bugtracker on SF : http://sourceforge.net/tracker/index.php?func=detail&aid=1065125&group_id=9655&atid=109655 I am sorry to insist, but I think there is a big trouble with the cache because this file have a big frame rate per second, the video seen don't move and speed up to stay sync with the audio again and again. I don't try with the latest CVS release, and I don't know if I am the only one with this prob. I have lot of this file so I must use mplayer and not a good Gui based on xine lib to play them. Thanks to look at this prob if you have time. -- Sylvain "Skarsnik" Colinet Victory was near but the power of the ring couldn't be undone |
From: Michael R. <mr...@us...> - 2004-11-29 17:38:43
|
Hi, > Hi, I already repport this bug in the bugtracker on SF : > http://sourceforge.net/tracker/index.php?func=detail&aid=1065125&group_id=9 >655&atid=109655 I am sorry to insist, but I think there is a big trouble > with the > cache because this file have a big frame rate per second, the video > seen don't move and speed up to stay sync with the audio again and > again. > I don't try with the latest CVS release, and I don't know if I am the > only one with this prob. > > I have lot of this file so I must use mplayer and not a good Gui based > on xine lib to play them. I downloaded the file and tested it here. Unfortunately, my PII 400 seems to be too slow to judge on the smoothness of the playback, but it looked sufficiently good. Some speed variations could be seen, though, but I would rather blame X11 or the kernel for that. 120fps is quite a job, most displays don't have such a rate, so X11 will get into trouble. The kernel might also schedule the video out thread too late for some frames which will result in discarded frames. I think these two effects explain the speed variations I saw here. It would be interesting to have someone with a faster computer try the file. Btw, do you use a 2.6 kernel? Michael -- Linux is much like an Indian tent: no Gates, no Windows and Apache inside |
From: xi <xi...@en...> - 2004-11-29 19:53:01
Attachments:
log.txt
|
Michael Roitzsch wrote: > Hi, > > >>Hi, I already repport this bug in the bugtracker on SF : >>http://sourceforge.net/tracker/index.php?func=detail&aid=1065125&group_id=9 >>655&atid=109655 I am sorry to insist, but I think there is a big trouble >>with the >>cache because this file have a big frame rate per second, the video >>seen don't move and speed up to stay sync with the audio again and >>again. >>I don't try with the latest CVS release, and I don't know if I am the >>only one with this prob. >> >>I have lot of this file so I must use mplayer and not a good Gui based >>on xine lib to play them. > > > I downloaded the file and tested it here. Unfortunately, my PII 400 seems to > be too slow to judge on the smoothness of the playback, but it looked > sufficiently good. Some speed variations could be seen, though, but I would > rather blame X11 or the kernel for that. 120fps is quite a job, most displays > don't have such a rate, so X11 will get into trouble. The kernel might also > schedule the video out thread too late for some frames which will result in > discarded frames. I think these two effects explain the speed variations I > saw here. > > It would be interesting to have someone with a faster computer try the file. > > Btw, do you use a 2.6 kernel? > > Michael > Hi, Tested here, I got the same problem : frames are dropped and playback is really jerky. I use a 2.4.19 kernel, graphic cards is matrox G400 @ 72Hz using Xv, and I use a dual 2800+ athlon system. There is no problem with mplayer to play this file. I have included xine's verbose output playing the whole file. Regards, Xavier -- E-mail: ctr...@fr... xi...@ch... Please no longer use xi...@en..., this e-mail will be removed soon. Homepage: http://xizard.free.fr http://www.chez.com/xizard/ |
From: James S. <jr...@ja...> - 2004-11-30 01:19:14
|
On Mon, 29 Nov 2004, Michael Roitzsch wrote: > Hi, > > > Hi, I already repport this bug in the bugtracker on SF : > > http://sourceforge.net/tracker/index.php?func=detail&aid=1065125&group_id=9 > >655&atid=109655 I am sorry to insist, but I think there is a big trouble > > with the > > cache because this file have a big frame rate per second, the video > > seen don't move and speed up to stay sync with the audio again and > > again. > > I don't try with the latest CVS release, and I don't know if I am the > > only one with this prob. > > > > I have lot of this file so I must use mplayer and not a good Gui based > > on xine lib to play them. > > I downloaded the file and tested it here. Unfortunately, my PII 400 seems to > be too slow to judge on the smoothness of the playback, but it looked > sufficiently good. What happens if you try to play it at 1/4 speed? Your CPU might be able to cope then. > Some speed variations could be seen, though, but I would > rather blame X11 or the kernel for that. 120fps is quite a job, most displays > don't have such a rate, so X11 will get into trouble. The kernel might also > schedule the video out thread too late for some frames which will result in > discarded frames. I think these two effects explain the speed variations I > saw here. > > It would be interesting to have someone with a faster computer try the file. I have a Pentium4 2.6 GHz with Hyperthreading, running kernel 2.6.8.1-12mdksmp. When I play this file with --verbose=255, I get zero frames skipped or discarded. What does happen is that the picture moves for short busts, then remains static for a short while before moving again. Each time the picture moves, 'video jump' is printed to the console. Perhaps the problem here is in the decoding? I suspect that this clip has 4 out of 5 frames encoded as skipped (giving 24 actual frames per second instead of 120), but xine decodes this incorrectly and tries to play the frames too quickly. Such an encoding would be useful for NTSC material which has a mix of 24 fps and 30 fps (or 24 fps with edits that break the 3:2 cadence), since it would allow both frame rates. Also, mplayer (which plays this clip smoothly) thinks that there are 119.880 frames per second (since the metadata says that the clip came from a DVD, this seems more likely than 120 (NTSC DVDs use 29.97 fps, not 30)). James |
From: Sylvain \Skarsnik\ C. <sco...@gm...> - 2004-11-29 18:18:28
|
On Mon, 29 Nov 2004 18:38:19 +0100, Michael Roitzsch <mr...@us...> wrote: > Hi, > > > > > Hi, I already repport this bug in the bugtracker on SF : > > http://sourceforge.net/tracker/index.php?func=detail&aid=1065125&group_id=9 > >655&atid=109655 I am sorry to insist, but I think there is a big trouble > > with the > > cache because this file have a big frame rate per second, the video > > seen don't move and speed up to stay sync with the audio again and > > again. > > I don't try with the latest CVS release, and I don't know if I am the > > only one with this prob. > > > > I have lot of this file so I must use mplayer and not a good Gui based > > on xine lib to play them. > > I downloaded the file and tested it here. Unfortunately, my PII 400 seems to > be too slow to judge on the smoothness of the playback, but it looked > sufficiently good. Some speed variations could be seen, though, but I would > rather blame X11 or the kernel for that. 120fps is quite a job, most displays > don't have such a rate, so X11 will get into trouble. The kernel might also > schedule the video out thread too late for some frames which will result in > discarded frames. I think these two effects explain the speed variations I > saw here. > > It would be interesting to have someone with a faster computer try the file. > > Btw, do you use a 2.6 kernel? > > Michael > I don't think my dual 1900 athlon have prob :) Yes I use a 2.6 kernel skarsnik@gobbla:~$ uname -a Linux gobbla 2.6.8-1-k7-smp #1 SMP Mon Nov 22 11:35:36 UTC 2004 i686 GNU/Linux I try with xv video output and xshm but the troub is still here But if it's a kernel or x11 prob why mplayer can play without prob, I know mplayer don't use threads but I don't see any framedrop or other tricks. -- Sylvain "Skarsnik" Colinet Victory was near but the power of the ring couldn't be undone |
From: Sylvain \Skarsnik\ C. <sco...@gm...> - 2004-11-29 20:34:44
|
On Mon, 29 Nov 2004 19:18:20 +0100, Sylvain Skarsnik Colinet <sco...@gm...> wrote: > On Mon, 29 Nov 2004 18:38:19 +0100, Michael Roitzsch > > > <mr...@us...> wrote: > > Hi, > > > > > > > > > Hi, I already repport this bug in the bugtracker on SF : > > > http://sourceforge.net/tracker/index.php?func=detail&aid=1065125&group_id=9 > > >655&atid=109655 I am sorry to insist, but I think there is a big trouble > > > with the > > > cache because this file have a big frame rate per second, the video > > > seen don't move and speed up to stay sync with the audio again and > > > again. > > > I don't try with the latest CVS release, and I don't know if I am the > > > only one with this prob. > > > > > > I have lot of this file so I must use mplayer and not a good Gui based > > > on xine lib to play them. > > > > I downloaded the file and tested it here. Unfortunately, my PII 400 seems to > > be too slow to judge on the smoothness of the playback, but it looked > > sufficiently good. Some speed variations could be seen, though, but I would > > rather blame X11 or the kernel for that. 120fps is quite a job, most displays > > don't have such a rate, so X11 will get into trouble. The kernel might also > > schedule the video out thread too late for some frames which will result in > > discarded frames. I think these two effects explain the speed variations I > > saw here. > > > > It would be interesting to have someone with a faster computer try the file. > > > > Btw, do you use a 2.6 kernel? > > > > Michael > > > > I don't think my dual 1900 athlon have prob :) > Yes I use a 2.6 kernel > skarsnik@gobbla:~$ uname -a > Linux gobbla 2.6.8-1-k7-smp #1 SMP Mon Nov 22 11:35:36 UTC 2004 i686 GNU/Linux > > I try with xv video output and xshm but the troub is still here > > But if it's a kernel or x11 prob why mplayer can play without prob, I > know mplayer don't use threads but I don't see any framedrop or other > tricks. > You can also find the BUGREPORT file on bugtraker -- Sylvain "Skarsnik" Colinet Victory was near but the power of the ring couldn't be undone |
From: Michael R. <mr...@us...> - 2004-11-29 20:50:02
|
Hi, > You can also find the BUGREPORT file on bugtraker I know, I read it. It only shows that frames are dropped. Michael -- "C combines all the power of assembly language with all the ease of use of assembly language" - trad |
From: Michael R. <mr...@us...> - 2004-11-29 20:52:27
|
Hi, > Tested here, I got the same problem : frames are dropped and playback is > really jerky. > > I use a 2.4.19 kernel, graphic cards is matrox G400 @ 72Hz using Xv, and > I use a dual 2800+ athlon system. A 2.4.19 kernel with 100Hz scheduling will undoubtedly fail to play that, because the files frame rate is 120Hz. The scheduling has no chance to be in time. > There is no problem with mplayer to play this file. This is because mplayer does not use any multithreading, so it does not suffer from scheduling problems. > I have included xine's verbose output playing the whole file. It confirms that lots of frames are dropped because the scheduler does not make it in time. Michael -- die_if_kernel("Whee... Hello Mr. Penguin", current->tss.kregs); 2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c |
From: Sylvain \Skarsnik\ C. <sco...@gm...> - 2004-11-29 21:31:16
|
On Mon, 29 Nov 2004 21:51:52 +0100, Michael Roitzsch <mr...@us...> wrote: > Hi, > > > Tested here, I got the same problem : frames are dropped and playback is > > really jerky. > > > > I use a 2.4.19 kernel, graphic cards is matrox G400 @ 72Hz using Xv, and > > I use a dual 2800+ athlon system. > > A 2.4.19 kernel with 100Hz scheduling will undoubtedly fail to play that, > because the files frame rate is 120Hz. The scheduling has no chance to be in > time. > > > There is no problem with mplayer to play this file. > > This is because mplayer does not use any multithreading, so it does not suffer > from scheduling problems. > > > I have included xine's verbose output playing the whole file. > > It confirms that lots of frames are dropped because the scheduler does not > make it in time. > > Michael > How to handle this prob ? let xine play only for example 1/2 of the amount of frame, Change something in the kernel ? -- Sylvain "Skarsnik" Colinet Victory was near but the power of the ring couldn't be undone |
From: Michael R. <mr...@us...> - 2004-11-30 16:25:37
|
Hi James, > > I downloaded the file and tested it here. Unfortunately, my PII 400 seems > > to be too slow to judge on the smoothness of the playback, but it looked > > sufficiently good. > > What happens if you try to play it at 1/4 speed? Your CPU might be able to > cope then. Nice idea. This made the problem show up clearly. > Each time the picture moves, 'video jump' is printed to the console. > Perhaps the problem here is in the decoding? > > I suspect that this clip has 4 out of 5 frames encoded as skipped (giving > 24 actual frames per second instead of 120), but xine decodes this > incorrectly and tries to play the frames too quickly. Metronom receives very strange PTS values. The frames claim to have a duration of 750, but they actually arrive with PTS intervals around 7000. This difference accumulates and will lead to these jumps once it arrives at a critical value. > Such an encoding would be useful for NTSC material which has a mix of 24 > fps and 30 fps (or 24 fps with edits that break the 3:2 cadence), since it > would allow both frame rates. I would guess then, from my and your analysis, that the video stream claims to be 120fps and so the frames get tagges with a 750 duration, but it actually emits frames at a much larger interval, confusing metronom (which will average between the claimed and the actual duration, but the difference will still accumulate beyond all bounds). This seems to be a problem in the decoder (ffmpeg in this case), maybe the xine wrapper around ffmpeg does not handle S-frames correctly? > Also, mplayer (which plays this clip smoothly) thinks that there are > 119.880 frames per second (since the metadata says that the clip came from > a DVD, this seems more likely than 120 (NTSC DVDs use 29.97 fps, not 30)). Again, we receive the framerate from ffmpeg. It would appear that a ffmpeg expert should have a look at this. Michael -- If a packet hits a pocket on a socket on a port, And the bus is interrupted as a very last resort, And the address of the memory makes your floppy disk abort, Then the socket packet pocket has an error to report! |
From: Sylvain \Skarsnik\ C. <sco...@gm...> - 2004-12-01 22:35:46
|
On Tue, 30 Nov 2004 17:25:18 +0100, Michael Roitzsch <mr...@us...> wrote: > Hi James, > > > > I downloaded the file and tested it here. Unfortunately, my PII 400 seems > > > to be too slow to judge on the smoothness of the playback, but it looked > > > sufficiently good. > > > > What happens if you try to play it at 1/4 speed? Your CPU might be able to > > cope then. > > Nice idea. This made the problem show up clearly. > > > Each time the picture moves, 'video jump' is printed to the console. > > Perhaps the problem here is in the decoding? > > > > I suspect that this clip has 4 out of 5 frames encoded as skipped (giving > > 24 actual frames per second instead of 120), but xine decodes this > > incorrectly and tries to play the frames too quickly. > > Metronom receives very strange PTS values. The frames claim to have a duration > of 750, but they actually arrive with PTS intervals around 7000. This > difference accumulates and will lead to these jumps once it arrives at a > critical value. > > > Such an encoding would be useful for NTSC material which has a mix of 24 > > fps and 30 fps (or 24 fps with edits that break the 3:2 cadence), since it > > would allow both frame rates. > > I would guess then, from my and your analysis, that the video stream claims to > be 120fps and so the frames get tagges with a 750 duration, but it actually > emits frames at a much larger interval, confusing metronom (which will > average between the claimed and the actual duration, but the difference will > still accumulate beyond all bounds). > > This seems to be a problem in the decoder (ffmpeg in this case), maybe the > xine wrapper around ffmpeg does not handle S-frames correctly? > > > Also, mplayer (which plays this clip smoothly) thinks that there are > > 119.880 frames per second (since the metadata says that the clip came from > > a DVD, this seems more likely than 120 (NTSC DVDs use 29.97 fps, not 30)). > > Again, we receive the framerate from ffmpeg. It would appear that a ffmpeg > expert should have a look at this. > Yes it's a ffmpeg prob, and I can't encode this file with transcode because of that, I just try with -x mplayer with transcode and the prob doesn't appear, so ffmpeg is the prob :) -- Sylvain "Skarsnik" Colinet Victory was near but the power of the ring couldn't be undone |
From: Miguel F. <mfr...@gm...> - 2004-12-08 21:41:06
|
On Tue, 30 Nov 2004 17:25:18 +0100, Michael Roitzsch <mr...@us...> wrote: > > Such an encoding would be useful for NTSC material which has a mix of 24 > > fps and 30 fps (or 24 fps with edits that break the 3:2 cadence), since it > > would allow both frame rates. > > I would guess then, from my and your analysis, that the video stream claims to > be 120fps and so the frames get tagges with a 750 duration, but it actually > emits frames at a much larger interval, confusing metronom (which will > average between the claimed and the actual duration, but the difference will > still accumulate beyond all bounds). agreed. that's my observation too. > Again, we receive the framerate from ffmpeg. It would appear that a ffmpeg > expert should have a look at this. not really, we currently use frame rate from demuxer. i don't know if/when does ffmpeg knows it better than demux. i've tried using the frame rate from ffmpeg (25 fps) which definitely improved things but still caused video jumps from time to time. so i'm about to commit a workaround that is to use the VIDEO_PTS_MODE for these 120fps streams. i never seen any other (proclamed) 120fps before, so i guess the chance this will break something else is pretty small... miguel |
From: Michael R. <mr...@us...> - 2004-12-09 12:04:41
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Miguel, > not really, we currently use frame rate from demuxer. i don't know > if/when does ffmpeg knows it better than demux. i've tried using the > frame rate from ffmpeg (25 fps) which definitely improved things but > still caused video jumps from time to time. > > so i'm about to commit a workaround that is to use the VIDEO_PTS_MODE > for these 120fps streams. i never seen any other (proclamed) 120fps > before, so i guess the chance this will break something else is pretty > small... Nice solution. AFAIK, some MPEG-4 part 2 codecs (like Xvid) can change the= =20 framerate inside the video stream. Maybe some multiplexers don't support th= is=20 and report something wrong in the container format. ffmpeg should know the= =20 correct per-frame framerate then. Michael =2D --=20 WARNING: REALITY.SYS has been corrupted. Reboot universe? (y/n/a)=20 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFBuD8/jhx3hMVnyYsRAmQZAJ9yr7ZmFyz+woM2NNPASXQL8assvACeNBsM xAtFxqC/+12aPo3EjDiQX8E=3D =3DSm0z =2D----END PGP SIGNATURE----- |
From: James S. <jr...@ja...> - 2004-12-12 18:19:48
|
On Wed, 8 Dec 2004, Miguel Freitas wrote: > so i'm about to commit a workaround that is to use the VIDEO_PTS_MODE > for these 120fps streams. i never seen any other (proclamed) 120fps > before, so i guess the chance this will break something else is pretty > small... The 'Bottle Fairy' clip is still not played correctly with xine. The motion appears to be jerky, compared to mplayer. When I enable logging in metronom.c, I see a pattern like this: got_video_frame pts = 2442189, duration = 0 computed frame_duration = 6756 got_video_frame pts = 2442940, duration = 0 computed frame_duration = 751 got_video_frame pts = 2449697, duration = 0 computed frame_duration = 6757 got_video_frame pts = 2450448, duration = 0 computed frame_duration = 751 Instead of each frame lasting for 1/24 of a second, we get one frame for about 1/13 of a second and one for 1/120 of a second. This uneven framerate can be observed when the clip is played at 1/4 speed. James |
From: Miguel F. <mfr...@gm...> - 2004-12-13 12:15:31
|
On Sun, 12 Dec 2004 18:19:42 +0000 (GMT), James Slorach <jr...@ja...> wrote: > The 'Bottle Fairy' clip is still not played correctly with xine. The > motion appears to be jerky, compared to mplayer. > > When I enable logging in metronom.c, I see a pattern like this: > > got_video_frame pts = 2442189, duration = 0 > computed frame_duration = 6756 > got_video_frame pts = 2442940, duration = 0 > computed frame_duration = 751 > got_video_frame pts = 2449697, duration = 0 > computed frame_duration = 6757 > got_video_frame pts = 2450448, duration = 0 > computed frame_duration = 751 > > Instead of each frame lasting for 1/24 of a second, we get one frame for > about 1/13 of a second and one for 1/120 of a second. This uneven > framerate can be observed when the clip is played at 1/4 speed. James, unfortunately this is what the frame pts have told us to do. the file is indeed pretty strange. usually xine uses a metronom mode where such differences are smoothed but it require the *real* frame rate to be known. if you can figure where does mplayer receives the information about 24 fps (as ffmpeg says 25fps) we can try to improve this. miguel |