[foms] Proposal: adaptive streaming using open codecs

James Courtier-Dutton James at superbug.co.uk
Sat Oct 23 02:27:40 PDT 2010


 Hi,

I don't know if any of you remember me. I attended some FOMS meetings
some time ago now.

First point:
Download protocols. Let the client choose.
I have not read any of the current spec on adaptive streaming.
I like the idea. The particular problem I am looking at is mythtv.
One has a central box holding all the source media.
One then has set top boxes that play the stream.
If the STBs are connected by Ethernet cables, there is probably not much
reason to do adaptive streaming.
The use case that I think would benefit is streaming via Wireless LAN to
a laptop. I.e A medium that will encounter packet loss and delays.
Streaming to mobile phone is also a valid use case.
When watching TV, there seems to be a priority of what is more annoying
to loose.
Even if the video is jerky or pauses, as long as the audio continues,
the show is still understandable.
I would therefore think it beneficial to separate out the audio and the
video into chunks. Audio as one chunk and Video as another chunk. (or
multiple chunks of audio/video if at different qualities)
So, the player would grab the audio chunk first, and then depending on
how long it took to download the audio chunk, decide on which quality of
video chunk to download.
Radio provides its own unique problems with data transmission, because
past data rates do not have much bearing on what is available now. Radio
tends to have more packet loss clumped together in time due to an
interference event, and then other periods of less packet loss.
I have a lot of experience with satellite data transmissions having
worked on a number of projects in that area. One being "Galileo" (the
European GPS or sat nav project.). Another being delivering encrypted
multicast with conditional access and "fast kick" features over
satellite without the need of a smart card.

Radio networks tend to be lossy networks, whereas wired
Ethernet/broadband connection a much less lossy.

To this end, using TCP, even for downloading chunks, is probably not the
best protocol to use over Radio LANs.
So, I think there should be a choice that the adaptive streaming client
makes as to which download protocol it wishes to use.
e.g.
1) TCP (Advantage is that is uses less bandwidth in low loss networks)
2) A protocol suited for download over lossy networks. These normally
involve some form of FEC (Forward error correction). Uses more bandwidth
due to the FEC but delivers data more quickly on lossy networks.


Next point:
Sync from one chunk to the next.
For video this is simple. The high quality chunk has X frames. The low
quality chunk also has X frames. Both chunks can be decoded without
referring to any other chunks.
One can simply switch between the two video chunks.
For Audio it is more difficult. Although the high quality chunk will
output X samples, and the low quality chunk can be made to have the same
amount of X samples, there may well not be a smooth transition between
chunks of different quality and a glitch will most likely be audible.
Some work will need to be done to hide the glitches. It may even require
a new audio codec type.

Kind Regards

James






More information about the foms mailing list