Video Streaming Need To Know: Part 1- Encoding, Bit Rates and Errors

Consumer networking vendors are constantly pitching us to stream video wirelessly around our homes. In Part 1 of this tutorial, Tim Higgins looks at what it takes to mess up networked video.
16 answers Last reply
More about video streaming know part encoding rates errors
  1. Too bad you didn't tried something more professionnal like Darwin Streaming server as the VOD source (but vlc or qt7 as the player)... With them, h264 works like a charm. (but you have to encode files properly and moreover hint and structure streams properly to have the best performances, mp4box is a good place to start).
  2. Hello,

    the MPEG 4 toolset (for both part 2 and part 10) does have tools(features) to increase error resilience/robustness/concealment in situations like this where the BER (bit error rates) is 'higher' than the normally experienced (like a safe playback from disk).

    For example such tools would be found in the Extended Profile in MPEG-4 part 10 (aka H.264).

    Using Encoders and Decoders compliant to such profiles and level in a situation like the one tested in this article (with high BERs) would have probably made a *big* difference.

    best regards,
    andrea
  3. Quote:
    Hello,

    the MPEG 4 toolset (for both part 2 and part 10) does have tools(features) to increase error resilience/robustness/concealment in situations like this where the BER (bit error rates) is 'higher' than the normally experienced (like a safe playback from disk)....

    Do you know if consumer applications like Apple's Quicktime offer access to these encoding options?
  4. Hello.

    QuickTime (Player I assume) when it comes to what gets presented to the user as tweakable options is, to say the least, quite poor.
    But this is a bit of a disgression since native Apple QuickTime decoders for MPEG-4 10 do not support Error Resilience tools (not clear for part 2 even if error resilience is part of the Simple Profile).

    I am not sure that encoders like XVID and X264 support/allow error resilience tools (but it would be great if they did!). If they did movie clip native playability by QuickTime would be broken (MPEG4 part 10), but either VLC or ffmpeg/ffplay might come to the rescue.

    Error resilience tools availability within MPEG4 seem to be part only of the professional/pricey univers (with tie-in encoders/decoders) but as you have discovered with your very useful article already in the Wireless world, where higher BERs are the norm, (I really think) all of the normal users would benefit greatly if such support was provided by XVID and the like.

    It seems so far that there is better chances to just use MPEG-4 part 2, I'll dig a little bit deeper to see if anything in the open source domain supports error resilience. If that was the case than with tools like MPEG4IP or MP4BOX it would be possible to generate .mp4 files which can be fed to streaming servers like Darwin (DSS). Also going to check if Apple MPEG4 part 2 decoder is 'fully' Simple Profile compliant and cope with error resilience tools.

    best regards
    andrea
  5. I doubt that there are many encoders out there that engage the extra error concealment features that are present in most compression protocols, if for no other reason than all forms of Forward Error Correction cost bits. The other reason being that I suspect that most decoders ignore redundant slices and and probably can't cope with partitioned data (I know that is true of the decoders I've written).

    I admit I'm surprised by how well your Mpeg4-2 (DivX) held up under error conditions - generally I would have expected it to fare rather worse than Mpeg-2 given that a missing packet will normally break the rest of the frame rather than just the remainder of the macroblock line. Depending on encoding tools employed H.264 will often be even worse.

    On the UDP vs TCP 'debate'. In the case where you have a small network and are only trying to get one stream to one place then TCP is your friend (for its flow control features as well as error correction). You need UDP if you are trying to broadcast (multicast) a stream or if latency is an issue as it would be if this was a video-phone link.
  6. Your results regarding TCP vs. UDP are just what one would expect: the UDP stream degrades but keeps going, while the TCP stream pauses and/or skips but maintains quality.

    (It would be interesting to know if the pause/skip behavior is a policy decision made by the player, and under what circumstances. Another common player behavior is for the audio to continue while the video pauses or skips.)

    But there's more to the TCP vs. UDP situation than your tests reveal. Your test highlights what happens to the video steams themselves when there's a certain degree of packet loss, but what happens to the other traffic on the network that might be occurring at the same time?

    I was involved in some testing about 10 years ago at Intel, where we wondered about the impact of streaming media on the performance of a corporate LAN. We found that for equivalent bit rates, a TCP stream was much more disruptive of other traffic than was a UDP stream. The easiest way to observe this behavior is to copy some very large files from one node to another while your stream is running, and see what the file transfer throughput rate is. I don't recall the exact results, but I do remember that with UDP there was almost no impact (for 1 stream) while with TCP there was a very significant impact. YMMV of course.

    I understand that you are mainly interested in the problem of RF interference, but unless all you do on your WLAN is stream video, you should take into account what happens to your other traffic.
  7. Quote:
    Your results regarding TCP vs. UDP are just what one would expect: the UDP stream degrades but keeps going, while the TCP stream pauses and/or skips but maintains quality.

    (It would be interesting to know if the pause/skip behavior is a policy decision made by the player, and under what circumstances. Another common player behavior is for the audio to continue while the video pauses or skips.)

    But there's more to the TCP vs. UDP situation than your tests reveal. Your test highlights what happens to the video steams themselves when there's a certain degree of packet loss, but what happens to the other traffic on the network that might be occurring at the same time?

    I was involved in some testing about 10 years ago at Intel, where we wondered about the impact of streaming media on the performance of a corporate LAN. We found that for equivalent bit rates, a TCP stream was much more disruptive of other traffic than was a UDP stream. The easiest way to observe this behavior is to copy some very large files from one node to another while your stream is running, and see what the file transfer throughput rate is. I don't recall the exact results, but I do remember that with UDP there was almost no impact (for 1 stream) while with TCP there was a very significant impact. YMMV of course.

    I understand that you are mainly interested in the problem of RF interference, but unless all you do on your WLAN is stream video, you should take into account what happens to your other traffic.


    Did you have a hub? Switches help allot for that.......

    @ all - Good article. I my self stream files to my laptop with just a skip now and then. TCP/IP for life :)

    Anyone use 802.11 A? hows the range? 5Ghz should be less packed?
  8. I noticed you used a WAN Network Emulator.
    That is a nice tool, *BUT* it doesn't really duplicate the
    actual situations that can be encountered under actual
    "field use" conditions.

    These conditions can vary wildly depending on:
    1. number of other signal sources in the immediate area (such signal sources include, but are not limited to: other AP, other electronic devices and even atmospherics)
    2. local contruction (metal based infrastructure, metalized film glass and other highly absorbant or reflective media)
    3. signal strength of your AP
    4. antenna effeciency
    5 anything else you can think of

    That emulator cannot possibly begin to simulate much more than the very basic environment.

    as an aside, I am a licensed Radio Technician with some "in the field experience" and I have seen some of the above conditions manifest with extreme regularity. Video streaming over such noisy spectra as this are simply NOT POSSIBLE.

    one last point: wireless is inherently HALF DUPLEX, which lends additional problems to dealing with "video over wireless".
  9. might be a bit off topic, but it's definitely the same ballpark.

    I recorded a video stream for my wife. Unfortunately the asf file will not allow me to scroll through the saved file in any media player. I have attempted to reencode the file, but have yet to have any luck. Could any of you tell my why when I play back the asf file there is no time stamp, and why can I not fast forward, or scroll to points I would like to see?

    Thanks in advance.
  10. Quote:
    I understand that you are mainly interested in the problem of RF interference, but unless all you do on your WLAN is stream video, you should take into account what happens to your other traffic.

    That's a good point. I'll be looking into it in Part 2 when I run the actual wireless tests.
  11. Quote:
    Did you have a hub? Switches help allot for that.......

    A switch isn't going to help once traffic hits the WLAN since all traffic will share the same bandwidth

    Quote:
    Anyone use 802.11 A? hows the range? 5Ghz should be less packed?

    802.11A's range problems were fixed long ago.
    http://www.tomsnetworking.com/2003/04/16/second/

    The main problem is that the networking industry refuses to consistently support dual-band products, especially on the client side other than PCI adapters.
  12. Quote:
    I noticed you used a WAN Network Emulator.
    That is a nice tool, *BUT* it doesn't really duplicate the
    actual situations that can be encountered under actual
    "field use" conditions.

    Point taken and acknowledged in the article. Part 1 was focused on exploring the sensitivity of wireless streaming to data error rate. This was done in an Ethernet environment which allowed the controlled experiments without the complication of wireless effects.

    Part 2 will look at wireless streaming itself.
  13. I'd be interested in performance evaluations of multiple solutions to push video to your TV across an 802.11g wLAN. There seems to be a vast difference in the ability of my laptop to stream video from the office PC compared to the set top box we have streaming the same file from the same machine over the same net to the same TV. Box and laptop are w/in 5 feet of each other so range shouldn't be an issue. No hiccups on the laptop while I get regular hiccups on the set top box. Hardware issue? Firmware issue? Software issue? All of the above?

    Anyway, I didn't want to get a blanket "wireless video works great" assessment made w/o looking into a fair amount of all the viable solutions out there since some may work a heck of a lot better than others.

    Thanks for the great work you guys do at THG and for a decade of support for the hardware geek in us all.
  14. Dave said:
    Quote:
    Wireless is not ready for prime-time, man. Too slow, too prone to interference/hacking, and insecure.

    My solution: I have a dual-CPU 200MHz SCSI rack that runs Vmware Server(!), has 768MB Ram, and ~40GB of SCSI striped LVM. Vmware guest is Win2kpro with (21) ISO's as drives E-Z, along with Audio and Video shares.

    Using standard Win network shares, I can allow clients to play mp3/ogg on their computer over the net, and video play over the share is spotless. Haven't tried .vob, but standard mp3/avi/wmv works fine.

    Of course, due to low CPU speed, this is not recommended for more than a handful of simultaneous users; but it's certainly workable without needing to resort to wireless.
  15. I probably have some unique experience on this particular topic since we are providing live TV over WLAN to mobile platforms. To make things worse, we are doing it using multicast which provides no error correction. We did lots of testing with packet loss as well as delay/latency. Yes, video is very sensitive to packet loss. We ultimately chose Windows Media 9 and determined that you'll start seeing interruptions when packet loss approaches ~3%. At about 6% it's pretty much unwatchable. However, there are other factors that play into this. In the case of WM9, Windows Media Player will not start displaying video until it receives a key frame. So if there is an interruption in the video due to packet loss, and the key frame interval is high, you could be waiting a long time for the video to return. We had to set our KFI to 1s (the minimum) to help mediate this. Fragmented packets (large packet sizes) may also have an adverse effect.

    Some solutions (Real, for one) also provide a unicast "backchannel" that allows the player to request lost packets even with multicast streams.
  16. Might a new neighborhood just be the most expedient solution? Not moving your home, but switching to the 5.4Ghz band with 802.11A? I recall some old d-link .11A gear that claimed a proprietary 2x mode.
    Maybe I'm getting totally off topic, and if so I apologize... but what other devices compete for the slice of spectrum that .11A uses?
    And with all the development being done in the crowded lower band, could any of these advanced transmission systems be adopted for the neglected 5.4Ghz band?
    If the end goal is getting reliable high-bandwidth data wirelessly, could the higher band be the less congested route?
Ask a new question

Read More

Article Discussion Video Streaming Networking Encoding