The VideoLAN Forums

Hi,

I work in network support for an ISP that is nearly ready to begin marketing a DSL broadband, IP multicast "digital cable" tv product to our DSL subscribers (and hopefully attract new ones too). We are currently running trials using a TV set-top box solution that we will eventually sell to our customers.

However, because I support the multicast network for this stuff, some of my colleagues and I started looking months ago for an application that would allow us to join multicast streams from our PCs and found your the VLC media player to work very well. However, our encoder/streamer vendor has recently released new software for their devices which our head-end has upgraded to, and now VLC viewer does not work as it did previously. One of my colleagues wrote a script to capture live streams and save them as MPEG2 files, and has saved them on his webserver at http://www.scripty.com/work/mpeg/ . Both files can be loaded into VLC, but the file labelled "channel-after.mpg" won't display video, only the audio stream. The other file, labelled "channel-before.mpg", is a capture of a live multicast stream that is fully viewable by VLC.

I have looked through the various threads on this forum, and tried all the recommended fixes to the problem. My colleagues and I all run Win2K, and are using the newest version of VLC. I'm running current DirectX, current video drivers, etc. I've also tried the various recommended settings under Advanced Options for the video output as mentioned in other threads. So, I don't believe this is a problem with my PC. Because there are at least 6 confirmed cases of myself and my colleagues who've experienced this problem on different PCs, so we're confident that its not a hardware problem as far as our PCs are concerned. I'm guessing its a codec issue. We have found the the following mpeg2 player can play both files without any problems: http://www.elecard.com/products/mpeg2player.shtml

So, my challenge/question is.... what do we need to do to VLC to allow us to view our multicast streams as we used to as per the "channel-before.mpg" example? Our head-end people tell us that there might have been some resolution changes with the stream, but I suspect something else changed with the codec as well.

Looking forward to your responses!

Just tried watching a stream again, and seeing the following debug messages in the Message Log. Can anyone let me know what's wrong here?:

main warning: audio drift is too big (122337), dropping buffer
main warning: dts != current_pts (81037)
main warning: late picture skipped (1007699)
main warning: audio drift is too big (121541), dropping buffer
main debug: decoded 3/135 pictures
main warning: dts != current_pts (34793)
main warning: late picture skipped (1101084)
ts debug: pid[16] unknown
main warning: dts != current_pts (13015)
main warning: late picture skipped (1089951)
ts debug: pid[20] unknown
main warning: late picture skipped (1117801)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1069731)
main warning: late picture skipped (1098207)
main warning: late picture skipped (1072212)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1145358)
main warning: late picture skipped (1067240)
main warning: late picture skipped (1112545)
main warning: resampling stopped after 22124235 usec (drift: 39959)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1080627)
main warning: late picture skipped (1121859)
main warning: late picture skipped (1105125)
ts warning: discontinuity received 0xa instead of 0x4
ts warning: discontinuity received 0xe instead of 0xd
mpeg_audio debug: emulated startcode (no startcode on following frame)
main warning: buffer is 87549 in advance, triggering downsampling
main warning: output date isn't PTS date, requesting resampling (61191)
main warning: resampling stopped after 915360 usec (drift: 25846)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1122706)
main warning: late picture skipped (1063811)
main warning: late picture skipped (1122335)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1062998)
main warning: late picture skipped (1125722)
main warning: late picture skipped (1086640)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1104161)
main warning: late picture skipped (1065954)
main warning: late picture skipped (1104621)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1066493)
main warning: late picture skipped (1127268)
main warning: late picture skipped (1068084)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1130895)
main warning: late picture skipped (1072569)
main warning: late picture skipped (1098220)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1063552)
main warning: late picture skipped (1144785)
main warning: late picture skipped (1107648)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1106185)
main warning: late picture skipped (1067987)
main warning: late picture skipped (1128724)
main debug: decoded 3/135 pictures
main warning: late picture skipped (1066212)
main warning: late picture skipped (1061536)

Well, I see that there has been a few people look at my post, but no responses indicating that they were up to the challenge of dissecting the udp streams that we captured and working on a fix for VLC yet. I hope one of the developers here will look into this, because I have yet to find another product with as many nice features as VLC. You guys have an excellent product here, and if I had the skills, I'd be working on VLC with you. But I'm just a lowly network guy with no programming skills or experience

In the mean time, I guess I'll have to resort to using the Elecard-Moonlight UDP Stream Player, which works very well in my situation. While I find it lacking on the user-interface, and is very smooth and stable. Unfortunately it doesn't support playlists like VLC does

Looks like you're getting an "interesting" stream from the vendor. The "after" file that you posted also shows many more anomalies in the debug window, blocks of:
ts debug: - pid[308] seen
ts debug: - pid[8190] seen
ts debug: - pid[8191] seen

Where the pids are changing -- this is happening during the play, not during the startup sequence only.

I'd almost guess that they're multiplexing multiple streams on the same multicast address and port, assigning different PIDs so that you are supposed to demux against a specific subset of PIDs.

A lot of timestamp anomalies, that's why you're not seeing anything -- VLC isn't getting enough to declare a successful connection, to do anything with it (messages like decoded 3/135 are a bad sign). Perhaps it's getting messed up because it is expecting to see a finite, related, set of data coming in as a stream, not multiple disparate items shoveled though the same spigot.

By any chance, is the Moonlight decoder the ONLY thing that works, because the head end is now using a custom Moonlight TX solution?

I'm not one of the gurus of the software, just that your debug messages sound like that's what is going on.

Hi Markfm,

Thanks for your comments. Actually, our head-end streaming hardware vendor is TANDBERG, and I'm pretty sure they're not using anything affiliated with Moonlight at all. The Moonlight product is just something I stumbled accross while hunting for another player that works while waiting for VLC to be fixed. Moonlight (http://www.elecard.com) says their products are based on Microsoft ActiveX architecture.

I'm pretty certain that our head-end isn't multiplexing multiple streams on the same port, because I have a complete list of all multicast streams (by TV channel) and their respective UDP multicast IP addresses and individual ports. To watch a channel, I enter them almost identically the same way using the Moonlight UDP Stream player as I did with VLC.

If anything, I think Tandberg is moving more towards Microsoft standards. Down the road, we're told that our head-end Tandberg gear will be upgraded to streaming using Windows Media 9 (perhaps 10?) as opposed to MPEG4. Right now, its just plain old MPEG2.

Ahh, Tandberg Try the VLC IRC -- there are a couple of folks on there, early evening US Eastern time, who I believe work with their units.

I'm curious about the debug messages popping up in that sample you posted.

I tried playing the same channel-after.mpg file in xine/mplayer and both players have no problems with the file. I have opened the mpeg2 file with a patched version of Ethereal and the transport PID stream looks fine.

From a quick inspection of the file, it seems that the problem is that the PCR (program clock reference) values in the stream are not delayed compared to the PTS (presentation timestamps).

That basically means that the stream doesn't allow enough time to VLC to decode the data and consequently VLC drops it. The intended decoding time of data in VLC is based (in accordance to the MPEG TS spec) on the PCR/PTS values and VLC will drop this data if it realizes it won't be able to do the decoding before the specified time.

Most players don't use the PCR values in MPEG TS streams (because they simply synchronise the playback on the playing rate of the audio stream), this is why for instance xine/mplayer/moonlight do play the stream without any problem (although this leads to over problems like potential buffer overrun/underruns in the long term). However, as explained above, VLC is a lot stricter in that respect and won't deal properly with such badly constructed stream.

You should really complain to tanberg about that because I believe such a stream isn't standard compliant.

Ah and by the way, there is a work-around for this problem. Just increase the VLC caching a bit (:udp-caching=1000).

Increasing the UDP buffer to 1000ms (1 sec) did the trick. Thanks for all the help.

Increasing the UDP buffer to 1000ms (1 sec) did the trick. Thanks for all the help.

Yes! Worked for me too! Thanks for the help

Hey 1ordinary-guy, do you by any chance work for Telus?