Re: A problem with H.264 video (DVB-T)

Pavel Troller <[email protected]>
Newsgroups gmane.comp.video.xine.user
Message-ID <[email protected]>
> > >
> > > 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


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.