Now that the web vid spec MPEG DASH has been published and interoperability testing is well underway, vendors are starting to put their cards on the table with serious deployments. One of the first to build DASH into products is Thomson Video Networks, which is now supporting it in its ViBE VS7000 multi-screen video platform, …
I stopped reading at "Content Protection"
Seriously, haven't they learned from the past? As soon as you remove DRM your sales will sky rocket. Just look at iTunes where the first DRM-free song quickly overtook a big chunk of their DRM titles. Anybody still designing DRM into their systems shows he has no idea about reality. As Wau Holland, founder of the Chaos Computer Club once put it, "Es gibt keinen Kopierschutz, nur einen Kapierschutz". (There is no copy protection, only protection from understanding)
Other than that, there always has been something called "scalable codecs" which tried to do the same as MPEG-DASH does. Essentially you have multiple streams, one basic streams, and others allowing you to have higher resolutions or more details. It's technology from the 1990s.
Re: I stopped reading at "Adaptive Streaming"
...because we all just know that what that really means is that content delivery systems will not be upgraded to meet demand, quality will go down to meet capacity.
For examples, see DAB radio, cable/sat TV, ISP bandwidth throttling/caps on "unlimited" services. All are trying to squeeze more content down fixed capacity for a bigger ROI making a mockery of the "digital clarity" we were promised from these so-called "services of the future".
Streaming of high bandwidth content is pointless until the carriers are ready and prepared to offer end-to-end transit capacity to meet the needs and expectations of the customers.
I'm surprised nobody has written a streaming client which utilises multiple connections to get around speed throttling which is often applied at the ISP level.
For example using such a download manager like Internet Download Manager which defaults to 8 simultaneous connections I can download large files much quicker than using a single thread due to artificial slowness introduced at my ISP.
A http based streaming system which uses a multi threaded buffering mechanism would be able to play quite high quality video over what's normally a slow single threaded connection.
This has nothing to do with MEPG DASH but it would speed things up for a lot of people regardless of which type of video they are playing.
Re: Multiple connections
Multiple connections will only help if the ISP is throttling at the IP level, which seems unlikely. Web servers may throttle connections like that, ISP's usually won't. It won't help if the throttling is at the basic (probably ATM) level, since all connections will be considered together as a single flow over one virtual circuit.
Re: Multiple connections
Is this kind of throttling business as usual in the UK?
It is mostly about content protection - the antithesis of HTML5 and the web which seeks to expose data and make it usable everywhere. Any DRM will have to involve binary blobs and inaccessible data because it is almost guaranteed that the system will be broken and the "standard" will need to be changed.
The idea appears to be to allow a stream but not a download, desperately trying to shove the digital genie back in the bottle and revert to pure analogue broadcast with no VCR. If you use download rather than streaming, the user merely waits a bit and then picks everything up at local network or media speeds.
Having said that, there are occasions when high demand might make degrading quality useful. Streaming the FA cup final might be one of them - you don't want to hit a "pause" as the ball heads towards goal. However, for that application we have a wonderful broadcast medium called "telly" which works quite well. Degrading quality is for when you haven't built the network you should have.
I stopped reading at "Content Protection"
I had very similar thoughts on reading this. At first I was thinking, what's wrong with adapting the Transport Stream protocol, but that's not exactly scalable to differing pipes or screen sizes. At best it'll let you tune transmission for poor quality connection. My next thought was to use something like the "progressive" modes in JPEG, PNG, or (IIRC) DIrac (or similar trick as used in FLAC audio, separating the stream into a lossy part and a set of deltas). This would be much easier if the encoding system was based on wavelets (again, I think Dirac does this), but an FFT-based system can work too. The problem there, though, is how to do flow control so that the sender can stop sending the high-detail part of the stream. Then it struck me... why not use UDP for the fine level of detail and use TCP for the base image? You'd still have to do dynamic tuning on the encoder side (and a bit of buffering and stitching together at the decoder end), but at least the congestion part could be mostly handled by the network itself.
I also don't like the way that DRM is being baked into HTML5, but it's also hardly surprising. Sad, though.
Re: I stopped reading at "Content Protection"
Actually there's a type of digital filter developed a long time ago (it was the basis for Musicam and PAL+, I can't remimber the name) which allows you to split a signal into 2 parts with a matched pair of low- and high-pass filters. You can subsample both, and transmit them independently. So you could set up one low resolution stream as well as a high resolution one.
You could in fact start with an UHDTV image, and scale it down several times until you end up with 256x144 or something. That would be your basic stream, the more additional streams you take into account the more resolution you will get. The great thing about is that you will also be able to scale the processor power needed. That's particularly useful for mobile devices.
Re: I stopped reading at "Content Protection"
See perfect-reconstruction filter banks, and the relationship of wavelets to such.
I don't understand why they want to use HTTP (Everyone seems to want to use it these days even for stuff that would be better with a new protocol).
Why waste time and effort developing a new protocol when one already exists which is common, popular, extensible, and effective enough? Someone else will just come along and patent your idea while you're still fiddling with the bits for your new protocol.
It isn't efficient. UDP was designed for applications where lossiness isn't an issue, whereas TCP adds processing overheads in sequence numbers and bandwidth for acknowledgements and latency when packets are lost, with TCP windows.
As long as your data/application can survive data loss then UDP should be fine.
However, http allows you to cross proxies and firewalls to get into corporates whereas new ports would never be allowed.
I think realplayer fouled things up for everyone by being such a pig of a protocol/implementation. Many mobile phones required realplayer to have fixed source & destination ports which made NAT mostly impractical, even when the desktop version of the protocol had moved on and allowed dynamic source ports.
HTTP is not so much an application as a transport these days, with data being held in proprietary apps on each end.
HTTP is not so much an application as a transport these days.....
Errr http has ALWAYS been a transport method, the clue is in the name.
Hypertext Transfer Protocol
Granted, SIP (which is roughly based on HTTP) would be better, but as pointed out, easier to shove http through firewalls and proxies.
Re: HTTP is not so much an application as a transport these days.....
So which of those Ts stands for "transport", then? Oh, wait... that would be *neither*.
The part of HTTP that everyone forgets about in the context of streaming media is the H. Text and binaries don't benefit from a lossy transport mechanism, since the client needs the original data intact. Streaming media easily can, but isn't being given the chance.
As for being easy to shove through proxies, I can only hope this DASH nonsense actually obeys the HTTP standards, instead of trying to get away with a vague resemblance and happening to use port 80.
What is OTT? Over The ???
Also, to answer one question, the reason to do everything with HTTP is that many corporate firewalls block nearly all protocols except HTTP. This is for "security", even though everyone knows that there are programs that wrap other protocols up into HTTP messages.
I guess eventually firewalls will start examining HTTP packets in more detail, and then be able to block based on the nature of those packets. Then another level of wrapping will be needed. And so it goes....
"Over-The-Top Content (OTT) means Broadband Delivery of Video and Audio without the Internet Service Provider being involved in the control or distribution of the content itself." http://en.wikipedia.org/wiki/Over-the-top_content
and phone companies don't like OTT because people tend to use that instead of their services.
Scalable Video Codec
Having to pre-encode the same video at different bitrates is stupid. The codec should automatically degrade the stream as needed to save bandwidth without needing lower resolution encoded files. This technology has been around for over a decade.
A better solution is to use a Scalable Video Codec that can choose on the fly to throw away data to allow the stream to degrade as needed. This technology has been around for years in both JPEG2000 as well as in the newer specs of H.264 that include SVC and some proprietary protocols such as V2D by IP Video Systems.
When I see a streaming video product that requires that I store the same video files at different bandwidths I walk away.
Re: Scalable Video Codec
Why is this stupid? Just because there are ways around it doesn't mean that the simpler solution of pre-encoding isn't better. Throwing away data on a higher bitrate to achieve a lower bitrate will always give lower quality than having it directly encoded for the best possible quality at the low bitrate.
Does this "waste" storage? Sure, but storage is cheap. Does it waste CPU time encoding multiple times? Sure, but that's an up front one time cost, whereas scalable codecs require more CPU on the client end - undesirable when you have mobile clients on minimal power budgets.
Re: Scalable Video Codec
Right now you encode several different files for several different rates. This sounds like it might be encoding once into one file, and bits can be thrown away according to knowledge of the connection quality through some intelligent connection protocol. (But this is not absolutely clear, because the author has focused more on business aspects than technical aspects). This would be at least an expected technical advance, if not now, in
the near future.
You must be walking away from a lot of products then, Almost all of them, in fact.
Practically every streaming project I have worked on in the past two years involves transcoding into a variety of formats and resolutions. The only exception is when we are doing on the fly transcoding, but that is so proc intensive we only use that in special circumstances.
Hopefully that will change in the future. In fact, if we could only have a single format, I'd be happy to deal with the bitrates.
Alas, the world we live in is not (nor ever will be) perfect, and you do what you need to do.
Glad to hear we may begin to get some consensus on an HLS standard and a DRM package to go along with it. Sorely missing at the moment.
Re: @Mad Hacker
> You must be walking away from a lot of products then, Almost all of them, in fact.
I guess it must depend on whether he is using the product for internal use (optimal tech possible) or for
external use (people use old technology, ie6, jpegs not jpeg2000, etc. and you have to serve up something
that will be understood by an ordinary punter's computer).
the answer to all quality and storage space is xvid streaming, it is better picture quality then any other encoder and the smallest file size, and the fastest to encode
Since (because of their very nature) DRM is ILLEGAL (in most country) to start with, DASH IS DOA. DRM does not work, ENCOURAGE PIRACY, add to the cost of what ever it is infecting and does NOT the PUBLIC INTEREST in any way
Simply TYPING various WORDS in ALL CAPS does not make your message MORE IMPACTFUL. It DOES make people think YOU are being a JERK.
On to the meat of your argument: There are a lot of practices (e.g, marijuana sales and use, prostitution, gambling) that are illegal in some jurisdictions; this does not make them any less valid or profitable in other jurisdictions. Indeed, that doesn't make them any less profitable in the jurisdictions where they are illegal. So even if your premise is correct, your conclusion does not follow.
Thank you. Have a nice day.
Whoopy Fucking Dooooooooooooo
Wake me up when they start pressing LP's/Vinyl for the masses again.
Last time I heard about MPEG-DASH here it was because Apple (plus Cisco and the Fraunhofer Institute) had facilitated it's approval.
Microsoft Media "Player"
Just about every time I have tried* to use that pos it refused to play (unknown format).
Adding a folder of, er, media also seems to be beyond it's ability. There must be a way but as I have only been using PCs since 1988 it must be my stupidity.
*On a locked down work PC, at home I only use Linux
- Comment Renewable energy 'simply WON'T WORK': Top Google engineers
- Nexus 7 fandroids tell of salty taste after sucking on Google's Lollipop
- Useless 'computer engineer' Barbie FIRED in three-way fsck row
- Game Theory Dragon Age Inquisition: Our chief weapons are...
- 'How a censorious and moralistic blogger ruined my evening'