The VideoLAN Forums

Hi, (MOD: I hope this is the correct forum, please move if it belongs in the Beta section)

I'm using a Decklink capture card for input, encoding with h264. I'm outputting an RTP multicast stream.
I'm running 64bit Linux and built 1.2.0-git Twoflower (revision a2e0062) with Decklink 8.6.0 (Have to use the vlc 1.2.x for Decklink support)

The machine is an Intel i7 930 @ 2.80GHz (8 cores) 3Gb Ram

I'm capturing 1080i/50 from the Decklink SDI (Both audio and video), outputting 3000 bitrate at 960x540/25fps via this commadline.


All seems to work well for some time even though I get a constant stream of this warning message After several minutes (10-20) vlc continues to run but stops encoding/streaming for a while (again a random number of minutes) and then resumes without any intervention.
During encoding, load average is up around 1.00 but cpu usage is only around 30% overall.
It appears that encoding stops during the pauses (although all threads still appear to be running) and cpu usage drops to next to nothing.

I have a couple of pastebin logs here to show what is happening.
The first is starting vlc and the stream beginning normally here:
http://pastebin.com/MyhYpkxh

The second is during the period with no output and shows it recovering here:
http://pastebin.com/ETsusYzT

Please let me know if any further info would be helpful.

Thank you

You should probably increase caching.

Thanks Rémi,

I did try to increase the caching (added caching=3000) but every attempt I made was met with

[0x6f6398] main stream out warning: option caching is unknown

Could you please suggest the syntax I should use?

Edit: Ok I added :sout-mux-caching=3000 which it didn't complain about.
But it still eventually starts doing this

Ok so even with the cache settings above the problem persists.

One observation I've made is that this consistently happens when the number in the brackets on the mux warning goes above 2.3 Million.
Does this number refer to memory usage and if so would this indicate a lack of ram?

sout-mux-caching maybe. But it's only a work around. Someone should debug the problem and improve the clock/caching code.

I'd be more than willing to work with someone to debug this.
Should I open a ticket or is there already work happening in this area?

Nobody is working on this.

Ok well I've been experimenting with different values for --sout-mux-caching and it seems the setting this to 15000 seems to solve the problem.
It's been running for the past few hours with no issues so far. I still get the "late buffer for mux input [1938487]" warning but the number seems to sit around that value and is pretty stable.

Thanks for your help with this Rémi.

I appreciate everything you guys do.

Regards

mrgoblin

Seems I spoke too soon....
The --sout-mux-caching doesn't seem to have any effect at all.

Seems that some random alignment of the planets was responsible for the timing being aligned in such a way that the mux buffer stayed in sync.
After I rebooted the machine I was back to the original behaviour no matter what sout-mux-caching setting I used....
Back to the drawing board I guess.. sigh........

I did spot this in the output though I'm not sure how much help it is.

I was having the same problem while capturing from Firewire/DV camera. Adding the --dv-caching=5000 option fixed the warning for me.

Encoding from http/h264/ac3/TS to http/h264/mp3/TS, I have a similar problem (using 2.0.3 on Windows 7, also with the newest nightly, for example vlc-2.1.0-git-20121003-1150-win64). It will just stop doing anything at some point. It still shows as playing (pause button), in codec information it still shows the codec on the source end, but in statistics everything shows "0" and it is not connected to the source anymore.

Log bit when it stops working: Full log:
http://pastebin.com/YzEedVtF


This could also be related: https://trac.videolan.org/vlc/ticket/4774

After playing around with tvheadend streams, I was experiencing this myself, i found its due to x264 encode, add the following to your transcode
I found the cpu on my i3 550 dropped from ~200% to ~30%, and those warns/errors didn't appear again

Hi, could anyone fix the issue and successfully stream a video ?
i have increased the network and mux caching, but the video still gets freezed and after a long gap goes to the next image and gets freezed again.
I urgently need to fix the issue and get the video streaming. Any kind of assistance is appreciated.

If you need a fix urgently, you can either fix it yourself or contract someone.

Asking on the forum is not going to get the issue solved quickly in any case.