Grey screen when fast forwarding a HQ .ts

Hello, I'm using VLC to play (edited) TV recordings in 720p or 1080i. First of all, I've always had some little problems with stuttering .ts files right at the beginning within VLC. The first few seconds are mostly pixelated, but that was not a problem for me.

However, I've just upgraded my VLC to version 2.1.4, and now - additionally to the stuttering at the beginning - the picture is grey for about one second when I fast forward these files. Afterwards, it looks like the picture gets "built" properly again. When looking for a certain point of the video, this gets very annoying and disturbing. I had no issues concerning this in version 2.0.x.

I've tested .mkv, SD .ts files and also .mp4. No issues with these.

I assume it may be simply a single setting I should edit. Probably it's a malfunction of one of the filters used to play back .ts files in VLC. But as I'm not 100% sure of this, I've filled a ticket here.

This is normal in VLC 2.1. We don't seek to I-frames so you'll see incomplete imagery until the next full frame.

Please try a 2.2 nightly build since this behavior was improved for some container formats in the next feature release (not sure about MPEG TS): http://nightlies.videolan.org

Replying to [comment:1 fkuehne]:

This is normal in VLC 2.1. We don't seek to I-frames so you'll see incomplete imagery until the next full frame.

Please try a 2.2 nightly build since this behavior was improved for some container formats in the next feature release (not sure about MPEG TS): http://nightlies.videolan.org

Thanks for your reply. I've tested it with the latest 2.2 build, but unfortunately - at least with MPEG TS - there are no changes.

Please share a file.

assigned to @funman

added Component::Demuxers: TS + 1 deleted label

apart from the stuttering problem,

The artifacts are due to those problems:

• the TS demuxer does not clean its buffer and states when seeking. Sending old packets/frames along with the ones from the seek point.
• timestamps for those blocks not matching the new PCR as well.
• the packetizer is always used and it does not know a discontinuity happened. (see next)
• the TS demuxer does not flag discontinuities.
• The packetizer does not flush its slices on discontinuity (only on corrupt blocks)
• The decoder is not informed of discontinuities. (see next)
• The packetizer does not flag discontinuities.
• The decoder does not seem to wait I Frames after a discontinuity.

assigned to @fcartegnie and unassigned @funman

Too vague.

added Status::needs more info label

closed