forked from youtube/cobalt
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Support live streams (ie big timestamps), replace float with double (y…
…outube#1910) b/309222250 Live video streams with epoch timestamps was not possible to play. Huge timestamps values was truncated because use of data type float with limited resolution. Change-Id: I7bed973b56e58bea5cd4740ce1778f32dfe617e2 **BACKGROUND** It is problem to play some live video streams in Cobalt with a javascript player. It turned out to be related to timestamp values. Normally at play of a video the timestamp starts at zero and grow. For live streams they don't. As such a video is continuously created. Then the timestamp can be the current clock, i.e. UTC time. In seconds these values will be quite big and in microseconds huge. Cobalt cannot handle these huge values and therefor cannot play such video streams. **DEVELOPMENT** I started to investigate the call path for the Seek function. The Seek value that comes to a starboard integration is not the same as higher up in function call path. I found out that the function ConvertSecondsToTimestamp will disturb the value. It uses a float type for micro seconds. The float type is only 24 bits. I rewrite it. In javascript "mediaElement.currentTime = 0.0;" will create a call to currentTimeAttributeSetter in v8c_html_media_element.cc (file created during build) and that calls set_current_time in the HTMLMediaElement class. Call flow for seek: In javascript assign currentTime a value. currentTimeAttributeSetter // v8c_html_media_element.cc at build time HTMLMediaElement::set_current_time() HTMLMediaElement::Seek() WebMediaPlayerImpl::Seek() WebMediaPlayerImpl::OnPipelineSeek() WebMediaPlayerImpl::Seek() SbPlayerPipeline::Seek() SbPlayerBridge::PrepareForSeek() SbPlayerBridge::Seek() SbPlayerPrivate::Seek() PlayerWorker::Seek() PlayerWorker::DoSeek() PlayerWorkerHandler::Seek() // third_party/starboard integration I discover that timestamp is saved in different data types. In some places as seconds in a float. The floating-point data type "float" doesn't have enough resolution to handle timestamps. For example date of today will be approx. 1,695,316,864. A float mantissa is only 24 bits. In javascript all numbers are 64 bit float (52 bits mantissa, 11 bits exponent, one sign bit), max 9007199254740991 and min -9007199254740991. Let look at a today time in microseconds: 1,695,392,081,110,344 and compare with 9,007,199,254,740,991. It will fit. In C/C++ data type "double" is 64 bit floating-point. Fortunately, I didn't have to change the glue file between javascript and C++ (v8c_html_media_element.cc). It is already for double. One problem was that the called function in cobalt had a float argument. I ended up with changing float to double in a lot of places. While convert from floating-point value to an integer value (e.g. double to int64_t). The value needs to be rounded, not truncated. This is done in function ConvertSecondsToTimestamp. It might be nicer to use the TimeDelta::FromDouble function. However this function will truncate the value and it is a unittest for it. I don't see the use of such function. Well, I didn't change it. It would have effects a lot. **TEST** I have built (debug/devel/gold linux-x64x11) and run unittest (devel). Got 3 failed unittest, nplb about ipv6. I assume this is not caused by me. Executed Cobalt (devel and debug) in Ubuntu before and after change. With a html page running a javascript DASH player. Unfortunately, I have not found any open test streams on internet with huge timestamps. I have used streams from two different sources (with huge timestamps) to validate this change. **RESULT** Now it is possible to play live streams that have timestamps as current time expressed in epoch.
- Loading branch information
1 parent
85e1b18
commit ee2f99f
Showing
8 changed files
with
78 additions
and
89 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.