[Bug 19784] timestampOffset with multiplexed Media Segments

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19784

Steven Robertson <strobe@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |strobe@google.com

--- Comment #1 from Steven Robertson <strobe@google.com> ---
My US$0.02:

- I think you're being too optimistic about current-generation media pipelines
;)

Output framerates are almost always fixed once by the platform, either at app
start (on some devices) or long before it, and never (in my experience)
renegotiated based on observed video framerate on-the-fly. The most you can
hope for, then, is a jitter buffer to smooth frame timing. Frankly, though,
even proper double-buffering is something to celebrate on most CE devices.

In other words, I think that the extra control you're requesting wouldn't
result in user-visible improvements to quality outside of a lab. That's not to
say we shouldn't consider how we can improve things in the future. But we
should be careful about how far we're willing to hold back the huge QoE win of
adaptive, app-controled fetching, and seamless splicing, in order to add
features that won't have any user-visible benefit today.

- All of your timestampOffset problems go away if you use unmuxed media. 

That shouldn't immediately shut down the discussion, but it is worth noting
that the existence of this current limitation in API expressiveness is entirely
due to the decision to use muxed content.

(On a personal note: the number of problems that we've seen at scale related
specifically to interleaving/multiplexing has made me a passionate advocate for
using unmuxed formats, and we don't even do splicing from multiple content
sources on the client (yet). This isn't the place to go into details, but not
only do you get more control over your content when it's unmultiplexed, you
instantly slay an entire family of eldritch corner cases that will otherwise
haunt your waking hours.)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 30 October 2012 17:22:55 UTC