Marc,
The performance of all the platforms are converging these days, due to
substantial improvements on the server side. All the major servers will
aggressively use available bandwidth to push bits faster than the connection
speed, to increase the amount of time there is to resend lost packets, and
to deal with periods of reduced connection speeds. RealMedia and Windows
Media can also switch between different data rates during transmission as
bandwidth needs change.
At this point, broadband users watching a stream at a lower data rate
than their connection speed generally have a good experience, with very few
artifacts due to lost data. Modem users have a hard time. And office users
with shared connectivity can have highly variable connection speeds, which
can occasionally cause buffering. But dropped packets themselves are mainly
a problem for modem users, since they don't have enough surplus bandwidth
for aggressive buffering, and on a bad connection can just lose a lot of
packets.
None of the formats will dynamically reduce resolution due to CPU
limitations. MPEG-4's scalable profiles (not widely implemented yet) and
Windows Media 9 (still in pre-release) can have different resolutions at
different data rates within the same file, though. Only MPEG-4 and (in a
limited way) QT with SV3.1 B-frames use the enhancement layer concept.
RealMedia and Windows Media both just have multiple copies of the data in
the file at different data rates. This arguably provides better SNR,
although forthcoming enhancements of the Fine Grain Scalability MPEG-4
profiles should substantially close this gap.
QuickTime's biggest competitive limitation for streaming is its lack of
robust mechanisms to deal with varying connection speeds.
Ben Waggoner <http://www.benwaggoner.com>
Compressed Video Consulting, Training, and Encoding
My Book: http://www.benwaggoner.com/books.htm
Cleaner Tutorial: http://www.saferseas.com/navseries/adclean.html
Compression Books: http://www.benwaggoner.com/bookshelf.htm
on 11/23/02 4:58, Marc Jdckle at email@hidden wrote:
> You do write about error resilience but your book's focus is "mostly" on how
> to achieve good compression with different technologies (great book btw).
> You write very little about how the quality of MPEG-4/RealVideo/WMV streams
> behave when packets are lost during transmission. You don't really compare
> those technologies in this field (Did I say that I love pictures?;-) or run
> scientific tests.
>
> There is a lot of information about the MPEG-4 error resilience tools (on
> the web, in publications etc.) but what about Real Video or Windows Media?
> There is so litte information about those two.
> So I was wondering if anyone has conducted some tests on how they actually
> behave in lossy networks. What happens to a Windows Media Video if packets
> are lost for example? Is the complete picture influenced or only parts of
> it?
>
> In your book you also mention the high CPU requirements of current RealVideo
> codecs but you write little about how a real video stream reacts to such
> environments. You mention frame dropping but can the RealVideo decoder also
> adjust the resolution to such an environment (I'm not talking about dynamic
> adoption to bandwidth here which you do cover in your book)? Does Real offer
> something like MPEG-4's base layer/enhancement layer system? Or can I just
> assume that if it's not in the book it doesn't support it? :-)
>
> Oh, seems like I got carried away. Originally I only wanted to know about
> how those technologies behave in real-world environments and not only
> theoretically.
>
> As I said, I don't think people talked a lot about those topics on this list
> (probably because this isn't a Real or MS list - I know that - and probably
> because you can put those topics in a couple of sentences as far as QT is
> concerned exactly like you just did. The whole thing wasn't meant as
> critisism)
_______________________________________________
quicktime-talk mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/quicktime-talk
Do not post admin requests to the list. They will be ignored.
