User Tools

Site Tools


streaming_factors

Performance of live on-line streams may vary. This article expains some of the reasons.

All live online streams get transcoded into a memory buffer, rather than into a transcoded file. That's because a live stream is continuous, rather than the known fixed length of an on-line file, and if transcoded into a file could run out of disk space, so a rotating buffer is used instead. This is triggered by setting the “live” parameter in a plug-in or when setting up the live on-line stream in Serviio.

Depending on the stream (use ffmpeg to get its components http://wiki.serviio.org/doku.php?id=add_live_feeds ) the stream may simply be remuxed into mpeg-ts or the audio and videos also transcoded (see the profile serviio is using for your tv to see what the rules are http://www.serviio.org/index.php?option=com_content&view=article&id=16) (serviio uses first valid rule from local rules, then online rules if present or profile 1 online rules if not http://www.serviio.org/index.php?option=com_content&view=article&id=24). See the debug log for the ffmpeg command actually used(http://wiki.serviio.org/doku.php?id=detail_logging).

Transcoding is cpu intensive. Load will vary with the codecs and bitrate of the stream. Dual core cpus will max out, and HD videos impose ~4xtimes the load of SD. If your CPU cannot hack it in real time (there is no buffering to even out highs and lows) the video playback of the transcoded stream will be choppy. (See the console transcoding parameter for the number of cpus to be used, and the windows task manager performance tab for the cpu utilization by core)

Its also possible that the stream itself being ~4x the data is having problems making it thru the internet regardless of your connection speed to your isp. I use the Network tab on the windows task manager, and display bytes in and out per second. It shows how smooth or choppy the input data flow is, and will also show the effect of any transcoding. When my rules were transcoding h264.flv to mpeg2video my output was 4x the input. Since my TV can play H264.flv natively I changed my samsung c-d profile to only remux online h.264.flv to mpeg-ts. viewtopic.php?f=10&t=6057&start=10#p43806

Even when the dataflow seems sufficient, I have seen the video freeze for a few seconds and then start playing again. I don't know if this is due to the source providing frozen frames (many of them are just ad-hoc capture card setups subject to their own delays in sending their streams to the streaming server service provider), or if errors introduced over the internet (lost packets, misordered packets etc) are the cause.

You also need to ensure that you have other network traffic paused (p2p) and that your wireless connection is not flaky due to signal interference or low data rate (shown in task manager) or use a wired connection.

All told there are many factors, so you need to pick a stream and check out which of these are contributing to the choppy results. The best results will be from a quality stream provider streaming from a nearby site to minimize network delays. That's why isp provided ppv streams work well, where those coming from ad-hoc setup via overloaded servers across the oceans may not.

I've written this on the fly, based on my experience to date. It would be nice if others more knowledgeable would post their comment/corrections in http://forum.serviio.org/viewtopic.php?f=41&t=6059 . I still have lots of questions on how this all works so it would be nice to hear others explain it too.

streaming_factors.txt · Last modified: 2012/05/04 13:48 by jhb50