From: SourceForge.net <no...@so...> - 2004-12-31 16:31:04
|
Bugs item #1093821, was opened at 2004-12-31 17:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1093821&group_id=9655 Category: a/v sync problem Group: current cvs version Status: Open Resolution: None Priority: 5 Submitted By: Frantisek Dvorak (valtri) Assigned to: Nobody/Anonymous (nobody) Summary: Bad A/V sync and vanishing sound on slow HW Initial Comment: Hello team, Thanks to all for great work, xine 1.0 is really nice gift for all. :-) I want mention one bug, which I found during Christmas. A/V sync goes away on slow HW and sound stops after several seconds. A/V sync is reset to normal state and sound is back always after seek. There is probably some race condition, because effect isn't occurred or isn't so big if xine must make additional software scaling. X server ran with priority -19. With different priority even additional SW scaling doesn't help. It doesn't work with increased HZ value in kernel from 100 to 1000 too. Bug is occured only with some decoders (it shows no skipped frames, only dropped): ISO MPEG-4 (XviD, DivX5) and M$ MPEG-4 v3. DVDs and MPEG streams are OK (and it shows mainly skipped frames). I tried xine with OSS and ALSA, with XShm (Xv can't work on given hardware). Increasing number of video buffers increases the time before silence. Changing audio.synchronization.av_sync_method, audio.synchronization.force_rate and audio_synchronization.resample_mode have no effect. Attached is generated BUG-REPORT file. Thank you and happy new year, :-) Frantisek PS: The Pentium MMX 200 MHz isn't so bad. I used it for playing movies, with 1-2 seconds per frame, two or three years ago... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1093821&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-03-23 20:58:39
|
Bugs item #1093821, was opened at 2004-12-31 17:31 Message generated for change (Comment added) made by mroi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1093821&group_id=9655 Category: a/v sync problem Group: current cvs version Status: Open Resolution: None Priority: 5 Submitted By: Frantisek Dvorak (valtri) Assigned to: Nobody/Anonymous (nobody) Summary: Bad A/V sync and vanishing sound on slow HW Initial Comment: Hello team, Thanks to all for great work, xine 1.0 is really nice gift for all. :-) I want mention one bug, which I found during Christmas. A/V sync goes away on slow HW and sound stops after several seconds. A/V sync is reset to normal state and sound is back always after seek. There is probably some race condition, because effect isn't occurred or isn't so big if xine must make additional software scaling. X server ran with priority -19. With different priority even additional SW scaling doesn't help. It doesn't work with increased HZ value in kernel from 100 to 1000 too. Bug is occured only with some decoders (it shows no skipped frames, only dropped): ISO MPEG-4 (XviD, DivX5) and M$ MPEG-4 v3. DVDs and MPEG streams are OK (and it shows mainly skipped frames). I tried xine with OSS and ALSA, with XShm (Xv can't work on given hardware). Increasing number of video buffers increases the time before silence. Changing audio.synchronization.av_sync_method, audio.synchronization.force_rate and audio_synchronization.resample_mode have no effect. Attached is generated BUG-REPORT file. Thank you and happy new year, :-) Frantisek PS: The Pentium MMX 200 MHz isn't so bad. I used it for playing movies, with 1-2 seconds per frame, two or three years ago... ---------------------------------------------------------------------- >Comment By: Michael Roitzsch (mroi) Date: 2005-03-23 21:58 Message: Logged In: YES user_id=552060 It's a known problem that a lot of decoders simply ignore the skipping hints from metronom and do not skip. As the decoder gets further behind the real time, xine has currently no other response than throwing data away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1093821&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-04-19 06:15:31
|
Bugs item #1093821, was opened at 2004-12-31 17:31 Message generated for change (Comment added) made by valtri You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1093821&group_id=9655 Category: a/v sync problem Group: current cvs version Status: Open Resolution: None Priority: 5 Submitted By: Frantisek Dvorak (valtri) Assigned to: Nobody/Anonymous (nobody) Summary: Bad A/V sync and vanishing sound on slow HW Initial Comment: Hello team, Thanks to all for great work, xine 1.0 is really nice gift for all. :-) I want mention one bug, which I found during Christmas. A/V sync goes away on slow HW and sound stops after several seconds. A/V sync is reset to normal state and sound is back always after seek. There is probably some race condition, because effect isn't occurred or isn't so big if xine must make additional software scaling. X server ran with priority -19. With different priority even additional SW scaling doesn't help. It doesn't work with increased HZ value in kernel from 100 to 1000 too. Bug is occured only with some decoders (it shows no skipped frames, only dropped): ISO MPEG-4 (XviD, DivX5) and M$ MPEG-4 v3. DVDs and MPEG streams are OK (and it shows mainly skipped frames). I tried xine with OSS and ALSA, with XShm (Xv can't work on given hardware). Increasing number of video buffers increases the time before silence. Changing audio.synchronization.av_sync_method, audio.synchronization.force_rate and audio_synchronization.resample_mode have no effect. Attached is generated BUG-REPORT file. Thank you and happy new year, :-) Frantisek PS: The Pentium MMX 200 MHz isn't so bad. I used it for playing movies, with 1-2 seconds per frame, two or three years ago... ---------------------------------------------------------------------- >Comment By: Frantisek Dvorak (valtri) Date: 2005-04-19 08:15 Message: Logged In: YES user_id=543511 Understand I right, mentioned decoders can be improved? I though it was their principle limitation. This bug has other nasty issue - just enabling CPU intensive postprocessing get xine out of sync for this decoders. ---------------------------------------------------------------------- Comment By: Michael Roitzsch (mroi) Date: 2005-03-23 21:58 Message: Logged In: YES user_id=552060 It's a known problem that a lot of decoders simply ignore the skipping hints from metronom and do not skip. As the decoder gets further behind the real time, xine has currently no other response than throwing data away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1093821&group_id=9655 |
From: SourceForge.net <no...@so...> - 2005-04-19 13:23:47
|
Bugs item #1093821, was opened at 2004-12-31 17:31 Message generated for change (Comment added) made by mroi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1093821&group_id=9655 Category: a/v sync problem Group: current cvs version Status: Open Resolution: None Priority: 5 Submitted By: Frantisek Dvorak (valtri) Assigned to: Nobody/Anonymous (nobody) Summary: Bad A/V sync and vanishing sound on slow HW Initial Comment: Hello team, Thanks to all for great work, xine 1.0 is really nice gift for all. :-) I want mention one bug, which I found during Christmas. A/V sync goes away on slow HW and sound stops after several seconds. A/V sync is reset to normal state and sound is back always after seek. There is probably some race condition, because effect isn't occurred or isn't so big if xine must make additional software scaling. X server ran with priority -19. With different priority even additional SW scaling doesn't help. It doesn't work with increased HZ value in kernel from 100 to 1000 too. Bug is occured only with some decoders (it shows no skipped frames, only dropped): ISO MPEG-4 (XviD, DivX5) and M$ MPEG-4 v3. DVDs and MPEG streams are OK (and it shows mainly skipped frames). I tried xine with OSS and ALSA, with XShm (Xv can't work on given hardware). Increasing number of video buffers increases the time before silence. Changing audio.synchronization.av_sync_method, audio.synchronization.force_rate and audio_synchronization.resample_mode have no effect. Attached is generated BUG-REPORT file. Thank you and happy new year, :-) Frantisek PS: The Pentium MMX 200 MHz isn't so bad. I used it for playing movies, with 1-2 seconds per frame, two or three years ago... ---------------------------------------------------------------------- >Comment By: Michael Roitzsch (mroi) Date: 2005-04-19 15:23 Message: Logged In: YES user_id=552060 If the xine wrapper code around these decoders is able to skip individual frames, the decoders could be improved by actually handling the metronom skipping hint. This will make them stay in sync with audio, no matter if the reason for the drift is slow hardware or heavy postprocessing. Michael ---------------------------------------------------------------------- Comment By: Frantisek Dvorak (valtri) Date: 2005-04-19 08:15 Message: Logged In: YES user_id=543511 Understand I right, mentioned decoders can be improved? I though it was their principle limitation. This bug has other nasty issue - just enabling CPU intensive postprocessing get xine out of sync for this decoders. ---------------------------------------------------------------------- Comment By: Michael Roitzsch (mroi) Date: 2005-03-23 21:58 Message: Logged In: YES user_id=552060 It's a known problem that a lot of decoders simply ignore the skipping hints from metronom and do not skip. As the decoder gets further behind the real time, xine has currently no other response than throwing data away. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109655&aid=1093821&group_id=9655 |