Live TV hitting the end of the File

[Lao Pan]

This is a problem that NPVR has always had, but seems to be a bit worse now.

When watching Live TV - either MPEG2 or H264 - when there are large blocks of Colour and Text (End of Shows, Adverts etc.) Sound stutters as playback bangs into the end of the file, which can be seen if you bring up the playback position bar. (-1 to 0 seconds on the left hand time)
If you go back in the file 30 seconds then forward 1 minute - i.e. to the end of the file - there is always a 4 to 3 second buffer left and it plays perfectly, as does recorded TV.
This is with the PDVD13 Video and Lav Audio Codecs with a 125ms audio delay to get lip sync.

Is there anyway to increase the Live TV buffer by a second or possibly two seconds to try and smooth out playback?

[Elmo Putney]

I seem to be having the same issue - though I hadn't noticed the timeline, I'll check that tonight. Is this a fairly recent issue for you i.e. in the last 6 months or so?

[Lao Pan]

Is this a fairly recent issue for you i.e. in the last 6 months or so?

I've had this problem ever since NPVR came out (Not on GBPVR, obviously a different way of doing live TV)

But It has definitely got much worser in the last 6 months - I think it may be due to the improvements :eek: to compression of the Transport Streams / Bit Budgeting so that more Channels / Junk can be broadcast on each Mux.

Obviously on large solid blocks of colour they can use large numbers of B frames with very few P or I Frames and maybe the Splitter / Codec etc. is trying to get frames that are not yet in the buffer.

[johnsonx42]

When you first watch live tv in npvr, the decoder is being fed all the frames as they arrive via shared-memory, it's not reading from the disk file at all. It's only after you pause or skip that the decoder is fed from the file instead. There must be some means though to prevent the decoder from running up against the end of the buffer. Especially with H.264, B-frames can reference multiple other frames in the past and the future (they can with MPEG-2 also, but it's much more limited). I'm guessing many (all?) of the decoders we use for live tv are designed on the assumption that they are decoding frames from a locally stored file or a streaming buffer that fills faster than the frames are to be decoded. This just-in-time delivery of frames at the same speed they're to be decoded probably wasn't in the plan.

[Lao Pan]

Would it be possible to have a configurable live TV memory buffer, in either milliseconds, megabytes or frames - so that it could be increased in small steps until the problem goes away. I'm sure I have seen it mentioned in one of the other TV software forums in the past. I know my TV's built in tuner takes 3 or 4 seconds longer than NPVR to open channels from the epg - presumably it is taking this time to buffer the stream.

[sub]

Initially Live TV starts out in shared memory mode, which basically delivers the transport stream packets for decoding immediately as they delivered by the device. It'll only ever deliver complete packets etc, so shouldn't be possible to broken or partial packets leading to corrupt video etc.

I have seen a machine using HDMI that where the audio renderer played too fast, which would lead to stuttering etc on live tv. This might be related to what you're seeing. ie, even if you skipped back 10 seconds (equivalent of buffering 10 seconds before playback), then left live tv running, it'd eventually catch up to live and start stuttering Found lots of discussion about this on the net, but mostly related to how to work around it on Linux, and didn't find anything conclusive on fixing this scenario in Windows.

[Elmo Putney]

Some observations now that I've been paying attention:

from post 1 "(-1 to 0 seconds on the left hand time)"

mine does this all the time but does not seem to correlate to the stuttering - red herring?

The issue definatley seems to manifest itself when there are color wipes in the broadcast - e.g. big fade to black for ads, or other single colour dominant scenes.

-not sure if that stacks up with Subs explanation or not (I'm not worthy)

Some channels seem worse than others, e.g. I've had 5+1 running for 2-3 hours tonight with no issues - ctrl+o used to bring up details of stream in GBPVR is there an NPVR equiv?

[sub]

ctrl+o used to bring up details of stream in GBPVR is there an NPVR equiv?

Not currently, but the next release adds this.

[Lao Pan]

I have seen a machine using HDMI that where the audio renderer played too fast, which would lead to stuttering etc on live tv. This might be related to what you're seeing. ie, even if you skipped back 10 seconds (equivalent of buffering 10 seconds before playback), then left live tv running, it'd eventually catch up to live and start stuttering

The HTPC does use HDMI for Video and the onboard Realtek DTS encoder over Toslink to the surround amp. I do have to set a delay on audio of about 125 ms, but I think that is fairly constant, over hours lip sync will stay OK - I'll have to try on delayed playback to see if it gets closer to the end over time.

from post 1 "(-1 to 0 seconds on the left hand time)"

mine does this all the time but does not seem to correlate to the stuttering - red herring?

Possibly, but I was pointing out that live TV is always very close to the end of the buffer where as if you pause then catch up to the end of the file (try and jump forwards past the current time) there is always at least 3 - 4 seconds of buffer - I presume when you do this you are still using the Recorded File off the hard drive.

The issue definitely seems to manifest itself when there are color wipes in the broadcast - e.g. big fade to black for ads, or other single colour dominant scenes.

Some channels seem worse than others, e.g. I've had 5+1 running for 2-3 hours tonight with no issues

Yep large blocks of colour or black - end credits or Adverts seem to be the worst culprits - especially if there is Text involved - possibly de-interlacing comes in to the equation?
Also I have been wondering if the inconsistent stream rate from Microsoft's TS Reader may be part of the problem? I know LAV Video decoder finds it a problem.

It's possible that Channel 5+1 may be using older encoding technology that's why there is less of a problem - although there has always been slight glitches with NPVR - it seems to be much worse now, and the size of recorded files is now much smaller than before, both on H264 DVB-T2 and MPEG2 DVB-T.

[Elmo Putney]

Just resurrecting this - I realized this morning that I have not had this happen to me recently, wondering if it just because it's summer and I'm watching less or if the issue maybe related to the transmission has gone away - anyone else noticed? - I'll keep an eye on it now.