Unable to play a live TS stream

Since upgrading from 2.1.5 to 2.2.0 on Windows 7, I can’t decode a live TS stream without getting a constant flow of these messages: ts warning: discontinuity received 0x3 instead of 0x2 (pid=33)

I’ve attached the VLC log. I’ve installed 2.1.5 in a separate directory and can decode the same stream with zero TS warnings.

I've tried the latest 64 bit development build and it shows the same issue as 2.2.0

added Severity::normal Type::bug Version::master git + 1 deleted label

changed milestone to %Bugs paradize

VLC log (debug level) decoding 6 Megabit TS video/audio stream

Added attachment:

• ts.log

Original author: stephane st-hilaire

Sample, please.

assigned to @funman and unassigned @MigrationBot

added Component::Demuxers: TS label and removed 1 deleted label

I've attached a TS recording and a Wireshark PCAP capture at http://streams.videolan.org/upload/ Hopefully you have received them. I assume that's what you meant by "sample". If otherwise please specify. Thanks

Original author: stephane st-hilaire

Just in case I put the files on filedropper too:

http://www.filedropper.com/ts6mbit http://www.filedropper.com/tsoverudponport1234--2015-03-13t103925

Original author: stephane st-hilaire

I can’t decode a live TS stream without getting a constant flow of these messages: in my case flow of errors #12872 (closed)

Can't reproduce.

RAW TS from pcap works Other sample works too

to me it looks like receiver is losing UDP packets and/or is not fast enough to process it

http://streams.videolan.org/issues/14145/

Try disabling video track, or better, pass --no-video from start

When disabling the video track I can still see non stop TS discontinuity messages (and my CPU is only at 6%). With the video track enabled, I am still only at 28% CPU. I've never seen something like this with any of the previous versions of VLC.

FYI, VLC is running on a Intel i3 @ 3.20Ghz with 4 Gigs of ram. Windows 7 pro 64 bit + service pack 1 is the exact OS.

Btw, I keep getting "environment not found" accessing this site, either trying to login via OpenID, adding a comment to a ticket... just about anything. It is a bit frustrating. I seem to only be able to update tickets from my home laptop for some reason... this will introduce some delays in my responses.

Original author: stephane st-hilaire

One more thing, the encoder producing the TS stream and the PC running VLC are directly connected to the same switch, there are no reasons to lose any TS packets (which is consistent with 2.1.5 not loosing anything). Thanks

Original author: stephane st-hilaire

Le 19/03/2015 13:03, Ilkka Ollakka a écrit :> On Thu, Mar 19, 2015 at 12:47:48PM +0100, Francois Cartegnie wrote:

Le 19/03/2015 07:59, Ilkka Ollakka a écrit :

This patch is really just a shot in the dark, I don't know if those calls should/can be used and if that approach is anyway sane, or if it actually compiles properly. Anyone with any win32 experience, feel free to give comments.

Was there any earlier changes to that shrunk that receive buffer on all windows platforms ? https://trac.videolan.org/vlc/ticket/14145

There was a change that removed setting buffers at all, and default buffer handling seems to be non-working in anything below windows 8.

For windows 8 and newer, we shouldn't touch it, as like Remi said it's really OS area to fiddle those automaticly.

Most likely same issue than in #14200 (closed), please try nightly build of 3.0 if it fixes the issue for you?

Tried the 3.0 build from today the 23rd. Must be something wrong with it, I couldn't decode anything at all. You will find attached the log when I tried to tune in to the UDP stream. I will try another daily 3.0 build in a couple of days.

Original author: stephane st-hilaire

Log of 3.0 daily build not decoding TS over UDP at all.

Added attachment:

• VLC_3.0.txt

Original author: stephane st-hilaire

Ok, so the 3.0 builds (32 and 64 bit) from the 25th are working fine. The issue seems fixed as far as I know. Thanks a lot. I guess this will show up in a official 2.2.1 release in the near future?

Regards

Original author: stephane st-hilaire

added Status::fixed label

changed milestone to %3.0.0

closed

Milestone renamed

changed milestone to %3.0 FF

Milestone renamed