I use vdr-xine and I get stuttering and video freeze on mainly on one
channel, the local NBC. Happens on others but not as much. video/audio
goes into a stutter and you need to change channels to fix it. Even just
reentering the same channel works. Other times the video will totally
freeze with no audio and only a restarting vdr fixes it. Can't tell on
that if it's a problem with xine or vdr. Kind of looks like a vdr
problem as cpu usage drops for vdr while a xine crash which peaves me
with a black screen with a prompt line in the upper left and a xorg "X"
mouse pointer in the middle causes no change in vdr cpu and it continues
to record shows, etc. Still needs a restart since my script restart vdr,
xorg and xine at the same time.
On 1/21/2011 11:54 AM, Rob Davis wrote:
(Un?)fortunately, this issue doesn't occur in xineliboutput, as the
source is actually HD Mpeg2 720p with AC3, but the issue I have is only
with XBMC and vnsiserver. I am wondering if there's a clock set wrong on
their ATSC muxer or something like that which xine and every set top box
out there ignores, but XBMC looks at.
On 21/01/11 12:34, Timothy D. Lenz wrote:
There was a patch posted a day or two in the in the xine list that had
to do with pts. From freenode #xine:
[11:43] <rnissl> in case of a video freeze, I assume you had a clock
error
[11:44] <rnissl> hotwings suffers them too for h264
[11:54] <hotwings> btw, you fixed the pts error rnissl. but when it
occurs the video glitches/freezes briefly. however other players go
smooth right through it (like coreavc+mpc in windows). i think thats due
to bugs in the frame stuff though and not how the pts error is handled
right?
[11:54] <rnissl> yes, acutally, the pts error is just a pts wrap and
shouldn't be handled like that.
[11:55] <rnissl> my plans are to release a patch this week which makes
the handling configureable
[11:56] <rnissl> although I think that this kind of handling is not
necessary or wrong, there may be situations where removing the code
causes other trouble
[11:57] <rnissl> so a config option should suit both interests
On 1/21/2011 8:58 AM, Rob Davis wrote:
Using VDR 1.7.16 and the vnsi plugin, xbmc seems to be struggling to
play
one particular channel. Unfortunetly, it's the channel I'm doing a
temporary admin contract for, so I kind of need to see it. vdr-sxfe
plays
it OK, but I get too much video stuttering on it, and all other channels
play ok on xbmc/vdr.
Working at the station, if the problem is there, I have a hope of
getting
it fixed. Their sister station using the same equipment but on a
different frequency and antenna (transmitter) is fine.
I get the same symptoms using both OTA (8vsb) and via Comcast QAM256, so
am fairly sure the problem is specific to something at the station.
The code from demuxer.c (in vnsi plugin) that's being triggered is this:
else if(checkTimestamp)
{
int d = dts + m_epochDTS - m_LastDTS;
if (d< 0 || d> 90000) {
if (d< -PTS_MASK || d> -PTS_MASK + 180000)
{
m_badDTS++;
if (m_badDTS< 5)
{
dsyslog("VNSI-Error: DTS discontinuity. DTS = %10lu, last =
%10lu", dts, m_LastDTS);
}
}
else
{
/* DTS wrapped, increase upper bits */
m_epochDTS += PTS_MASK + 1;
m_badDTS = 0;
}
}
I get my logs filled with the VNSI-Error, DTS discontinuity. The audio
stutters. It appears to be AC-3 Stereo, but may be labelled 5.1? I have
audio passthrough to my amp. On another laptop with analog output it
seems to stutter in a different way..
I'm fairly happy putting some kind of checking in VDR or VNSI and
recompiling if it'll help. I have two ATSC tuners, it happens to both
tuners.
Thanks
Rob
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
