UTCTiming not supported

[randeeppr]

Hi,

I am getting this when I play dash encrypted live streams. Video stutters a lot. Any idea?

Playhead is outside of the seekable range: seekable [71.39000010490417, 71.39000010490417] attempted 71.243267 Adjusting...
Playhead is outside of the seekable range: seekable [72.39000010490417, 72.39000010490417] attempted 72.22295 Adjusting...
Playhead is outside of the seekable range: seekable [73.39000010490417, 73.39000010490417] attempted 73.243267 Adjusting...
Playhead has been moved outside of the seekable range: seekable [73.41100001335144, 73.41100001335144] attempted 73.39 Adjusting...
Playhead is outside of the seekable range: seekable [74.39000010490417, 74.39000010490417] attempted 74.223633 Adjusting...
Playhead is outside of the seekable range: seekable [75.39000010490417, 75.39000010490417] attempted 75.263584 Adjusting...
Playhead is outside of the seekable range: seekable [76.39100003242493, 76.39100003242493] attempted 76.202633 Adjusting...
Playhead is outside of the seekable range: seekable [77.39000010490417, 77.39000010490417] attempted 77.244267 Adjusting...
Playhead is outside of the seekable range: seekable [78.39000010490417, 78.39000010490417] attempted 78.202633 Adjusting...
Playhead is outside of the seekable range: seekable [79.39000010490417, 79.39000010490417] attempted 79.263584 Adjusting...
Playhead is outside of the seekable range: seekable [80.39000010490417, 80.39000010490417] attempted 80.22295 Adjusting...
Playhead is outside of the seekable range: seekable [81.39000010490417, 81.39000010490417] attempted 81.243267 Adjusting...
Playhead has been moved outside of the seekable range: seekable [81.42799997329712, 81.42799997329712] attempted 81.39 Adjusting...
Playhead is outside of the seekable range: seekable [82.39000010490417, 82.39000010490417] attempted 82.179681 Adjusting...
Playhead is outside of the seekable range: seekable [83.39000010490417, 83.39000010490417] attempted 83.243267 Adjusting...
Playhead is outside of the seekable range: seekable [84.39000010490417, 84.39000010490417] attempted 84.22295 Adjusting...
Playhead is outside of the seekable range: seekable [85.39000010490417, 85.39000010490417] attempted 85.263584 Adjusting...
Playhead is outside of the seekable range: seekable [86.39000010490417, 86.39000010490417] attempted 86.182316 Adjusting...

Regards,
Randeep

[joeyparrish]

Sounds like a duplicate of #185, which was fixed in v1.6.0. What version of Shaka Player are you using?

[randeeppr]

I was using 1.5.0.

I'll check with 1.6.0 tomorrow and update here.

Is it required that we need to use https for streams and license servers in
1.6.0?

And I was getting Allow-origin hearder errors even though I had given * for
it on 1.6.0. So I switched back to1.5.0.

Regards,
Randeep

On Thu, Dec 3, 2015 at 12:47 AM, Joey Parrish notifications@github.com
wrote:

Sounds like a duplicate of #185
#185, which was fixed in
v1.6.0. What version of Shaka Player are you using?

—
Reply to this email directly or view it on GitHub
#241 (comment)
.

Randeep
Mob: +919447831699[kerala]
Mob: +919880050349[B'lore]
http://twitter.com/Randeeppr
http://in.linkedin.com/in/randeeppr

[image: --]
Randeep Raman
[image: http://]about.me/Randeeppr
http://about.me/Randeeppr

[joeyparrish]

The CORS situation for 1.6 hasn't changed, and we have never placed any restrictions on http vs https at the library level. Browsers may or may not restrict these things, and URI scheme definitely affects a browser's CORS checks.

CORS-wise, you want Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: scheme://my.origin.tld. To use the existing clock-sync mechanism, you also have to allow access to the Date header with Access-Control-Expose-Headers: Date. (This clock-sync mechanism will not be used in Shaka 2.)

[joeyparrish]

@randeeppr Were you able to get CORS working with v1.6?

[randeeppr]

@joeyparrish

No Joey. Can you check if there anything wrong with my http headers?

XMLHttpRequest cannot load http://live.domain.com/dash/russiatoday/audio1/Header.m4s. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://vod.domain.com' is therefore not allowed access.

curl -I http://live.domain.com/dash/russiatoday/audio1/Header.m4s
HTTP/1.1 200 OK
Content-Length: 0
Server: Halo Origin Server
Content-Type: video/mp4
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Content-Type, Access-Control-Allow-origin, Range, Date, Accept
Access-Control-Expose-Headers: Access-Control-Allow-Origin, Content-Length, Content-Type, Date, Range, Server, Transfer-Encoding
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Cache-Control: max-age=10
Date: Sat, 12 Dec 2015 08:21:47 GMT
Connection: keep-alive

Regards,
Randeep

[joeyparrish]

@randeeppr

I was about to post my own results, until I realized that your URL is a fake one. :-)

Can you please try this and report back?

curl -I http://live.domain.com/dash/russiatoday/audio1/Header.m4s?123456

I am curious if the cache-buster is causing your CORS issues.

[randeeppr]

@joeyparrish
:)
Here is the result.

[root@localhost ~]# curl -I http://live.domain.com/dash/russiatoday/audio1/Header.m4s?123456
HTTP/1.1 200 OK
Content-Length: 0
Server: Halo Origin Server
Content-Type: video/mp4
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, Content-Type, Access-Control-Allow-origin, Range, Date, Accept
Access-Control-Expose-Headers: Access-Control-Allow-Origin, Content-Length, Content-Type, Date, Range, Server, Transfer-Encoding
Access-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONS
Cache-Control: max-age=10
Date: Mon, 14 Dec 2015 03:32:19 GMT
Connection: keep-alive

Regards,
Randeep

[joeyparrish]

Well, then it's not related to cache-busting. I don't see any obvious problem with the Access-Control headers here.

Are you using cookies and/or the withCredentials flag in the request? If you were sending cross-origin credentials, you would need Access-Control-Allow-Credentials: true.

I can't think of any other reason for CORS to fail. If you can send me the real manifest URL privately, I could help you debug. Otherwise, I'm stumped.

[randeeppr]

Joey,

Can you please send me your email id?

Regards,
Randeep

On Mon, Dec 14, 2015 at 9:47 PM, Joey Parrish notifications@github.com
wrote:

Well, then it's not related to cache-busting. I don't see any obvious
problem with the Access-Control headers here.

Are you using cookies and/or the withCredentials flag in the request? If
you were sending cross-origin credentials, you would need
Access-Control-Allow-Credentials: true.

I can't think of any other reason for CORS to fail. If you can send me the
real manifest URL privately, I could help you debug. Otherwise, I'm stumped.

—
Reply to this email directly or view it on GitHub
#241 (comment)
.

Randeep
Mob: +919447831699[kerala]
Mob: +919880050349[B'lore]
http://twitter.com/Randeeppr
http://in.linkedin.com/in/randeeppr

[image: --]
Randeep Raman
[image: http://]about.me/Randeeppr
http://about.me/Randeeppr

[joeyparrish]

joeyparrish@google.com

[joeyparrish]

Here's what I'm getting:

XMLHttpRequest cannot load http://domain.com/path/to/video1/138697.m4s. No 'Access-Control-Allow-Origin' header is present on the requested resource ... The response had HTTP status code 404.

The 404 is the key. There is no CORS problem, it just appears so since your 404 responses don't have the CORS headers on them.

It appears that clock sync is the root of the problem. We don't support the UTCTiming element you're using in your manifest, but instead use the Date header from the manifest request. Your server's Date is ahead of my workstation's date by 104 seconds, and ahead of the UTCTiming element by 127 seconds.

So the player is requesting segments that are not yet available, which results in a 404 error.