From: Pavel T. <pa...@si...> - 2008-11-01 04:45:58
|
Hi! I have the following problem with playing H.264 (MPEG4) video from DVB-T stream: When the channel is tuned, the video is played perfectly, without any problems. However, about 30 - 60 seconds later, the video starts to skip. At first, it stops momentarily and then skips the missing frames for about every 2 - 3 seconds, so it is very annoying (it still plays smoothly between the skips, every skip takes about 200 ms). The skip intervals decrease by the time, and of course also the difference between picture contents before and after the skip. After about a minute, it skips very often with very short skips, so it looks as a low framerate (about 10 fps). This is the final state, it continues to play this way until the channel is re-tuned, which resumes smooth playing for the next 30 - 60 seconds and then it repeats the whole process. The sound is played continuously, no skips, and it keeps approximately in sync with the video. This is not a CPU performance problem - CPU load doesn't hit 1.00 and it is a dualcore machine, so there is a big reserve in the CPU power. Using kaffeine as a frontend. Formerly used xine-lib-1.1.15 and ffmpeg svn from the beginning of September, now tried with current hg snapshot of xine-lib and svn snapshot of ffmpeg. Still the same. I've been also playing extensively with various xine engine settings (quality of postprocessing, deinterlacer type, codecs priority etc.), and it didn't influence anything, the problem appears always in the same manner. There isn't any debug/error output from xine-lib/ffmpeg. Any help, what to fix ? With regards, Pavel Troller |
From: Christophe T. <hf...@fr...> - 2008-11-01 13:00:57
|
Le Saturday 01 November 2008 05:22:55 Pavel Troller, vous avez écrit : > Hi! > I have the following problem with playing H.264 (MPEG4) video from DVB-T > stream: > When the channel is tuned, the video is played perfectly, without any > problems. However, about 30 - 60 seconds later, the video starts to skip. > At first, it stops momentarily and then skips the missing frames for about > every 2 - 3 seconds, so it is very annoying (it still plays smoothly > between the skips, every skip takes about 200 ms). The skip intervals > decrease by the time, and of course also the difference between picture > contents before and after the skip. After about a minute, it skips very > often with very short skips, so it looks as a low framerate (about 10 fps). > This is the final state, it continues to play this way until the channel is > re-tuned, which resumes smooth playing for the next 30 - 60 seconds and > then it repeats the whole process. > The sound is played continuously, no skips, and it keeps approximately > in sync with the video. > This is not a CPU performance problem - CPU load doesn't hit 1.00 and it > is a dualcore machine, so there is a big reserve in the CPU power. > Using kaffeine as a frontend. Formerly used xine-lib-1.1.15 and ffmpeg > svn from the beginning of September, now tried with current hg snapshot of > xine-lib and svn snapshot of ffmpeg. Still the same. I've been also playing > extensively with various xine engine settings (quality of postprocessing, > deinterlacer type, codecs priority etc.), and it didn't influence anything, > the problem appears always in the same manner. > There isn't any debug/error output from xine-lib/ffmpeg. > Any help, what to fix ? > With regards, Pavel Troller Could you provide a sample? -- Christophe Thommeret |
From: Pavel T. <pa...@si...> - 2008-11-01 17:36:00
|
> Le Saturday 01 November 2008 05:22:55 Pavel Troller, vous avez écrit : > > Hi! > > I have the following problem with playing H.264 (MPEG4) video from DVB-T > > stream: > > When the channel is tuned, the video is played perfectly, without any > > problems. However, about 30 - 60 seconds later, the video starts to skip. > > At first, it stops momentarily and then skips the missing frames for about > > every 2 - 3 seconds, so it is very annoying (it still plays smoothly > > between the skips, every skip takes about 200 ms). The skip intervals > > decrease by the time, and of course also the difference between picture > > contents before and after the skip. After about a minute, it skips very > > often with very short skips, so it looks as a low framerate (about 10 fps). > > This is the final state, it continues to play this way until the channel is > > re-tuned, which resumes smooth playing for the next 30 - 60 seconds and > > then it repeats the whole process. > > The sound is played continuously, no skips, and it keeps approximately > > in sync with the video. > > This is not a CPU performance problem - CPU load doesn't hit 1.00 and it > > is a dualcore machine, so there is a big reserve in the CPU power. > > Using kaffeine as a frontend. Formerly used xine-lib-1.1.15 and ffmpeg > > svn from the beginning of September, now tried with current hg snapshot of > > xine-lib and svn snapshot of ffmpeg. Still the same. I've been also playing > > extensively with various xine engine settings (quality of postprocessing, > > deinterlacer type, codecs priority etc.), and it didn't influence anything, > > the problem appears always in the same manner. > > There isn't any debug/error output from xine-lib/ffmpeg. > > Any help, what to fix ? > > With regards, Pavel Troller > > Could you provide a sample? > > I'm afraid not. I've recorded about 5 minutes of the HD stream, which played poorly from the air, but I've found that the recording plays smoothly all the time, with no problems at all! So I'm not able to reproduce the problem from a file, just direct playing from the DVB-T device is causing troubles, captured file is good and can be played without problems. With regards, Pavel Troller |
From: Pavel T. <pa...@si...> - 2008-11-02 13:29:28
|
> > Le Saturday 01 November 2008 05:22:55 Pavel Troller, vous avez écrit : > > > Hi! > > > I have the following problem with playing H.264 (MPEG4) video from DVB-T > > > stream: > > > When the channel is tuned, the video is played perfectly, without any > > > problems. However, about 30 - 60 seconds later, the video starts to skip. > > > At first, it stops momentarily and then skips the missing frames for about > > > every 2 - 3 seconds, so it is very annoying (it still plays smoothly > > > between the skips, every skip takes about 200 ms). The skip intervals > > > decrease by the time, and of course also the difference between picture > > > contents before and after the skip. After about a minute, it skips very > > > often with very short skips, so it looks as a low framerate (about 10 fps). > > > This is the final state, it continues to play this way until the channel is > > > re-tuned, which resumes smooth playing for the next 30 - 60 seconds and > > > then it repeats the whole process. > > > The sound is played continuously, no skips, and it keeps approximately > > > in sync with the video. > > > This is not a CPU performance problem - CPU load doesn't hit 1.00 and it > > > is a dualcore machine, so there is a big reserve in the CPU power. > > > Using kaffeine as a frontend. Formerly used xine-lib-1.1.15 and ffmpeg > > > svn from the beginning of September, now tried with current hg snapshot of > > > xine-lib and svn snapshot of ffmpeg. Still the same. I've been also playing > > > extensively with various xine engine settings (quality of postprocessing, > > > deinterlacer type, codecs priority etc.), and it didn't influence anything, > > > the problem appears always in the same manner. > > > There isn't any debug/error output from xine-lib/ffmpeg. > > > Any help, what to fix ? > > > With regards, Pavel Troller > > > > Could you provide a sample? > > > > > I'm afraid not. I've recorded about 5 minutes of the HD stream, which played > poorly from the air, but I've found that the recording plays smoothly all the > time, with no problems at all! So I'm not able to reproduce the problem from > a file, just direct playing from the DVB-T device is causing troubles, captured > file is good and can be played without problems. > Hi! I've found that I can play HD streams forever with no skipping - it's just enough to activate the time shift feature for a second or two, and it plays the stream, buffered by the time shift file, perfectly. It's the definitive evidence that this problem is not caused by lack of CPU power - in this mode, the system is loaded more than when just playing from the DVB device, because it has to write the time shift file and play it back simultaneously. The only thing I have to remember, is to erase the time shift file manually (I didn't find an option in kaffeine to erase it automatically). I've tried to change number of video buffers and frames in the xine engine settings, and it doesn't influence anything, the problem appears in approximately the same time for 500 buffers as well as for 4000. WIth regards, Pavel Troller |
From: Christophe T. <hf...@fr...> - 2008-11-02 17:58:51
Attachments:
kaffeine-live_ringbuffer.diff
|
Le Sunday 02 November 2008 14:29:20 Pavel Troller, vous avez écrit : > > > Le Saturday 01 November 2008 05:22:55 Pavel Troller, vous avez écrit : > > > > Hi! > > > > I have the following problem with playing H.264 (MPEG4) video from > > > > DVB-T stream: > > > > When the channel is tuned, the video is played perfectly, without > > > > any problems. However, about 30 - 60 seconds later, the video starts > > > > to skip. At first, it stops momentarily and then skips the missing > > > > frames for about every 2 - 3 seconds, so it is very annoying (it > > > > still plays smoothly between the skips, every skip takes about 200 > > > > ms). The skip intervals decrease by the time, and of course also the > > > > difference between picture contents before and after the skip. After > > > > about a minute, it skips very often with very short skips, so it > > > > looks as a low framerate (about 10 fps). This is the final state, it > > > > continues to play this way until the channel is re-tuned, which > > > > resumes smooth playing for the next 30 - 60 seconds and then it > > > > repeats the whole process. > > > > The sound is played continuously, no skips, and it keeps > > > > approximately in sync with the video. > > > > This is not a CPU performance problem - CPU load doesn't hit 1.00 > > > > and it is a dualcore machine, so there is a big reserve in the CPU > > > > power. Using kaffeine as a frontend. Formerly used xine-lib-1.1.15 > > > > and ffmpeg svn from the beginning of September, now tried with > > > > current hg snapshot of xine-lib and svn snapshot of ffmpeg. Still the > > > > same. I've been also playing extensively with various xine engine > > > > settings (quality of postprocessing, deinterlacer type, codecs > > > > priority etc.), and it didn't influence anything, the problem appears > > > > always in the same manner. > > > > There isn't any debug/error output from xine-lib/ffmpeg. > > > > Any help, what to fix ? > > > > With regards, Pavel Troller > > > > > > Could you provide a sample? > > > > I'm afraid not. I've recorded about 5 minutes of the HD stream, which > > played poorly from the air, but I've found that the recording plays > > smoothly all the time, with no problems at all! So I'm not able to > > reproduce the problem from a file, just direct playing from the DVB-T > > device is causing troubles, captured file is good and can be played > > without problems. > > Hi! > I've found that I can play HD streams forever with no skipping - it's > just enough to activate the time shift feature for a second or two, and it > plays the stream, buffered by the time shift file, perfectly. It's the > definitive evidence that this problem is not caused by lack of CPU power - > in this mode, the system is loaded more than when just playing from the DVB > device, because it has to write the time shift file and play it back > simultaneously. The only thing I have to remember, is to erase the time > shift file manually (I didn't find an option in kaffeine to erase it > automatically). > I've tried to change number of video buffers and frames in the xine > engine settings, and it doesn't influence anything, the problem appears in > approximately the same time for 500 buffers as well as for 4000. > WIth regards, Pavel Troller Hm, interesting. So it could be a ringbuffer issue. Could you please try the following: - Apply the joined patch to current kaffeine svn and make install - Start kaffeine from a term, play live HD and look at the output for "WDIST = XXX" msg. - If you see this message (could repeat a lot), edit dvbout.cpp and change the value of WDISTSIZE in: #define WDISTSIZE 100 Increase the value until you stop seeing the msg. Lemme know if it fixes your problem. P.S. the ringbuffer size is: 188*64*WDISTSIZE bytes -- Christophe Thommeret |
From: Pavel T. <pa...@si...> - 2008-11-02 19:59:34
|
> > Hi! > > I've found that I can play HD streams forever with no skipping - it's > > just enough to activate the time shift feature for a second or two, and it > > plays the stream, buffered by the time shift file, perfectly. It's the > > definitive evidence that this problem is not caused by lack of CPU power - > > in this mode, the system is loaded more than when just playing from the DVB > > device, because it has to write the time shift file and play it back > > simultaneously. The only thing I have to remember, is to erase the time > > shift file manually (I didn't find an option in kaffeine to erase it > > automatically). > > I've tried to change number of video buffers and frames in the xine > > engine settings, and it doesn't influence anything, the problem appears in > > approximately the same time for 500 buffers as well as for 4000. > > WIth regards, Pavel Troller > > Hm, interesting. > So it could be a ringbuffer issue. > > Could you please try the following: > > - Apply the joined patch to current kaffeine svn and make install > - Start kaffeine from a term, play live HD and look at the output for "WDIST = > XXX" msg. > - If you see this message (could repeat a lot), edit dvbout.cpp and change the > value of WDISTSIZE in: #define WDISTSIZE 100 > Increase the value until you stop seeing the msg. > > Lemme know if it fixes your problem. > > P.S. > the ringbuffer size is: 188*64*WDISTSIZE bytes > Hi Christopher! Many thanks for your help! I tested your patch. I'm afraid that the problem is somewhere else, it didn't help. I even decreased WBUFSIZE to 50 and it behaved again as usual. I've modified your patch to print WDIST everytime it goes around (commented out your "else") and it showed that the values are very small: most of the time 1, sometimes 2 - 5, maximum I've ever seen was 19. There is no visible change in the pattern, when the video starts to skip. However, during my experiments, I'v noticed the following warning to be printed, exactly once per one "video session": kaffeine: KXineWidget: xine event: dropped frames kaffeine: WARNING: KXineWidget: Skipped frames: 67 - discarded frames: 33 It was interesting that the message appeared shortly after the video became to skip, but never appeared again during the same session. The numbers were different every time, but their sum was always 100. When the timeshift mode was activated immediately after startup, preventing the skips to appear, this message didn't appear (and playback was smooth for at least 10 minutes). With regards, Pavel Troller |
From: Christophe T. <hf...@fr...> - 2008-11-04 14:38:01
|
Le Sunday 02 November 2008 20:59:24 Pavel Troller, vous avez écrit : > > > Hi! > > > I've found that I can play HD streams forever with no skipping - it's > > > just enough to activate the time shift feature for a second or two, and > > > it plays the stream, buffered by the time shift file, perfectly. It's > > > the definitive evidence that this problem is not caused by lack of CPU > > > power - in this mode, the system is loaded more than when just playing > > > from the DVB device, because it has to write the time shift file and > > > play it back simultaneously. The only thing I have to remember, is to > > > erase the time shift file manually (I didn't find an option in kaffeine > > > to erase it automatically). > > > I've tried to change number of video buffers and frames in the xine > > > engine settings, and it doesn't influence anything, the problem appears > > > in approximately the same time for 500 buffers as well as for 4000. > > > WIth regards, Pavel Troller > > > > Hm, interesting. > > So it could be a ringbuffer issue. > > > > Could you please try the following: > > > > - Apply the joined patch to current kaffeine svn and make install > > - Start kaffeine from a term, play live HD and look at the output for > > "WDIST = XXX" msg. > > - If you see this message (could repeat a lot), edit dvbout.cpp and > > change the value of WDISTSIZE in: #define WDISTSIZE 100 > > Increase the value until you stop seeing the msg. > > > > Lemme know if it fixes your problem. > > > > P.S. > > the ringbuffer size is: 188*64*WDISTSIZE bytes > > Hi Christopher! > > Many thanks for your help! I tested your patch. I'm afraid that the > problem is somewhere else, it didn't help. > I even decreased WBUFSIZE to 50 and it behaved again as usual. I've > modified your patch to print WDIST everytime it goes around (commented out > your "else") and it showed that the values are very small: most of the time > 1, sometimes 2 - 5, maximum I've ever seen was 19. There is no visible > change in the pattern, when the video starts to skip. > However, during my experiments, I'v noticed the following warning to be > printed, exactly once per one "video session": > > kaffeine: KXineWidget: xine event: dropped frames > kaffeine: WARNING: KXineWidget: Skipped frames: 67 - discarded frames: 33 > > It was interesting that the message appeared shortly after the video > became to skip, but never appeared again during the same session. The > numbers were different every time, but their sum was always 100. When the > timeshift mode was activated immediately after startup, preventing the > skips to appear, this message didn't appear (and playback was smooth for at > least 10 minutes). > > With regards, Pavel Troller Hm, strange. A last try: edit kaffeine/src/player-parts/xine-part/kxinewidget.cpp in function KXineWidget::setDvb replace m_trackURL = pipeName; with m_trackURL = "fifo://"+pipeName; Zapping will be slower however. -- Christophe Thommeret |
From: Pavel T. <pa...@si...> - 2008-11-05 06:42:43
|
> > > > > > Hm, interesting. > > > So it could be a ringbuffer issue. > > > > > > Could you please try the following: > > > > > > - Apply the joined patch to current kaffeine svn and make install > > > - Start kaffeine from a term, play live HD and look at the output for > > > "WDIST = XXX" msg. > > > - If you see this message (could repeat a lot), edit dvbout.cpp and > > > change the value of WDISTSIZE in: #define WDISTSIZE 100 > > > Increase the value until you stop seeing the msg. > > > > > > Lemme know if it fixes your problem. > > > > > > P.S. > > > the ringbuffer size is: 188*64*WDISTSIZE bytes > > > > Hi Christopher! > > > > Many thanks for your help! I tested your patch. I'm afraid that the > > problem is somewhere else, it didn't help. > > I even decreased WBUFSIZE to 50 and it behaved again as usual. I've > > modified your patch to print WDIST everytime it goes around (commented out > > your "else") and it showed that the values are very small: most of the time > > 1, sometimes 2 - 5, maximum I've ever seen was 19. There is no visible > > change in the pattern, when the video starts to skip. > > However, during my experiments, I'v noticed the following warning to be > > printed, exactly once per one "video session": > > > > kaffeine: KXineWidget: xine event: dropped frames > > kaffeine: WARNING: KXineWidget: Skipped frames: 67 - discarded frames: 33 > > > > It was interesting that the message appeared shortly after the video > > became to skip, but never appeared again during the same session. The > > numbers were different every time, but their sum was always 100. When the > > timeshift mode was activated immediately after startup, preventing the > > skips to appear, this message didn't appear (and playback was smooth for at > > least 10 minutes). > > > > With regards, Pavel Troller > > Hm, strange. > > A last try: > > edit kaffeine/src/player-parts/xine-part/kxinewidget.cpp > in function KXineWidget::setDvb replace > m_trackURL = pipeName; > with > m_trackURL = "fifo://"+pipeName; > > Zapping will be slower however. > Hi Christopher! Yes, there is a big difference visible now. The video plays smoothly for about the time it was playing without the patch, then it fully stops and rebuffering occurs (the percentage indicated is sometimes going from about 10%, sometimes from 50%, but maybe it is because it buffers quickly and the initial value is not shown). When the buffering is finished, it plays smoothly again for approximately the same period (it depends on the actual bitrate, it occurs more frequently, when there are big changes on the screeen), and then the cycle repeats. So it looks like that the player is getting the stream data slower than necessary, so the buffer gets empty and it's necessary to refill it. Maybe the card is not able to supply the data quickly enough ? It's the internal PCI card, not an USB one, and I even tried to fiddle with PCI latency timer for it, but it didn't show any difference. Also the captured streams seem to be complete, which would not be possible in such a case. Or I have another idea, it looks to me as if the player would play the stream a bit faster than it's actually transmitted, so it consumes the data sooner and the buffer underruns. It's also necessary to say, that we have two DVB-T HD test broadcasts here in the Czech Republic, and just one of them is doing this, the second one is played well all the time, but it may be because of the higher bitrate of the first one. I will cancel this patch again, because it didn't repair the problem fully, it causes slowdown of the channel zapping and generally it will not be included in the kaffeine sources I think. With regards, Pavel Troller |