Well worth the money in my opinion. The discussion of jitter and lip sync alone are worth more than the book costs. It's very far superior to trying to get an understanding purely from reading the RFCs (like I did intitially!)
But on to my topics. It's late tonight (again I worked late into the night) so I cannot really go into the detail that I want to. But here's a short jab at it.
There's some great work going on with scalable codecs - methods of encoding media where a client can decode only the part that they need. A lower resolution client can tap the stream, basically, and show a low resolution version. These are borderline magical, in my opinion. Great stuff. Only I don't see where they will be deployed in the real world yet except for on PC clients. Cell phones - where it would potentially be the best bet - operate on walled garden networks where the wireless provider is going to control it anyway, likely in a greedy attempt to monetize a controlled video source (yes, I'm being harsh - but cellular video is pretty rigidly controlled in my opinion - open solutions need not apply). Set Top Boxes are mass manufactured to get low cost through economy of scale. The chip sets in them have MPEG2 and H.264 decode and built in MPEG2 Transport Stream decoding. The scalable codec support is not in the chips (yet, at least, to my knowledge). That leaves PCs, mostly. Interesting, but I still think that video streams are for lean-back watching, and I lean forward on my PC. It's where I work, not watch video. I think most people think that way, though my really young friends are certainly busting that model so maybe I'm wrong.
I came to my MPEG-centric, broadcast-centric view of the RTP landscape through my work mostly. I've spent the last 5 years building and deploying a 'narrowcast' IPTV system. It's a hybrid store-and-forward system where the media is streamed onto a private network from a media server in the venue, but media is delivered to the server as files. I map the same solution pattern onto homes. I suspect that in the future media will be delivered to a streaming-capable device - which may or may not be a server - that will in turn stream to edge devices. The link local bandwidth from the media source to the media sink will be large compared to the number of streams and the value of a scalable codec will not be enough to justify the costs. In this scenario the same economics that drive the capability set of today's STB units will still prevail: MPEG transport streams will still carry the day, and the software complexity of RTCP (needed if you split the audio out from the video into separate streams) is exactly what I keep hearing folks say: too complex, too costly, serves no purpose for the given application.
So, Randell is right, for the world he works in. The world I work in seems to resist even using RTP. I argue with vendors who think that just tossing MPEG transport stream frames in UDP packets is enough. I have yet to convince any of them to do a real RTCP implementation. Even before the economy tanked, these vendors have to pay real cash to real programmers to implement real features. The market is asking for a pile of things that those programmers need to implement. RTP/RTCP is not on the list. So I'm right too. As I get older I've lost the passion for the most elegant Engineering solution and found an affinity for the solution that I can sell at a profit. I think the business-side folks never had that conflict to start with.
But I live and work in a microcosm. What do you think?
[ add comment ] ( 1 view ) | [ 0 trackbacks ] | permalink |
( 3 / 215 )
Archives
