Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

/videos/create wih download_url "works" but leads to Error loading media: media could not be played


Hi,

I'm using the JW Platform /videos/create call to add a video with the download_url option to retrieve the video. The video is coming from a dropbox temporary URL, which is valid for the whole period that this test occurs. The URL is publically accessible.

Some observations (providing as much info as I can to help out):

1. JW Platform call appears to work, as the video "appears" to get downloaded, and encoded, complete with the thumbnail being produced.
2. The encoding time is in line with the expected 1minute = 1minute of video.
3. The SAME video uploaded "directly" via main content portal works.
4. The video downloaded manually from the temporary url from dropbox, and then uploaded works (i.e. there doesn't appear to be any issues with the dropbox download steps)
5. The media-type of the video by JW Platform picks up the correct mp4.
6. Dropbox is correctly reporting the media type as "video/mp4" in this instance (which may be helping JW Platform to correctly identify as .mp4 file)
7. The player, in the normal portal when viewing the list of uploaded videos, and trying to preview the video via dashboard.jwplayer.com is where the player cannot play the file (i.e. it's the standard player)
8. It behaves this way in IE11 and Edge, whilst the manually uploaded version plays just fine in either browser.
9. The player from dashboard.jwplayer.com is making several requests that appears to lead to the "media cannot be played message":
https://content.jwplatform.com/manifests/RBQ7uSk7.m3u8?sig=c8053d3847c79650249c3794909bd93c&exp=1486015882 => 404 Error with x-cache: "Error from cloudfront"
https://content.jwplatform.com/videos/RBQ7uSk7.mp4?sig=3eb3ea9269bf4fdfc936f06361f412d3&exp=1486015880 => 404 Error with x-cache: "Error from cloudfront"
https://content.jwplatform.com/videos/RBQ7uSk7.mp4?sig=3eb3ea9269bf4fdfc936f06361f412d3&exp=1486015880 => 404 Error with x-cache: "Error from cloudfront"
https://content.jwplatform.com/videos/RBQ7uSk7.mp4?sig=3eb3ea9269bf4fdfc936f06361f412d3&exp=1486015880 => 404 Error with x-cache: "Error from cloudfront"

the last item is attempted several times... and there is another header that suggests the server is "openresty"

10. I can see the thumbnail image OK.
11. All the thumbnail links on the "Sources" tab on playform.jwplayer.com seem to work
12. All the video direct links under the uploaded video "Sources" *DO NOT WORK*

Looking from the outside, it appears that when I do /videos/create using download_url, that the converted/transcoded videos are not being propagated to cloud front correctly?

It looks like all the steps for creating the new video have succeeded, except this last one item.

Also: this is reproducible. I get consistent results with my uploaded video (which is HQ, 70.9MB in size for 1min:44 seconds)

Any help/diagnostics on this problem would be very helpful.

Sincerely,
Nathan
Application Architect

7 Community Answers

Donni

JW Player Support Agent  
0 rated :

Hi Nathan,

I’m able to see the direct video links work in your JW Dashboard – can you double check that?

n...

User  
0 rated :

Hi Donni,

Thanks for the reply.

The previous links now work, so...

I ran the test again, and uploaded a new video, and as soon as the vide claims to be "ready", the links produce the exact same behaviour where the video cannot be played, even though it appears to be "Ready".

N.B. I'm on a different network today also, and I can reproduce this from both locations. Please also note, that I am forcing proxy/caching bypass with the F12 option in the browser...so these are direct responses (there is no proxy between me and the internet from my current network although there was a proxy yesterday, but I can bypass that also as I am in the infrastructure group :D )

Is there some sort of "delay" propagation of the videos to the content servers once they are converted?

The new content requests that are failing (404) right now are:
https://content.jwplatform.com/manifests/c6CNreq9.m3u8?sig=ce3d49db895cf31474bd1e1c4b9538e3&exp=1486089019
https://content.jwplatform.com/videos/c6CNreq9.mp4?sig=3d2b80bf5dad372f88d281606cdc42bb&exp=1486089019 (x3)

each has the error in cloudfront message for server "openresty" again.

Sincerely,
Nathan

n...

User  
0 rated :

Hi Donni,

Some additional info... with the (now) working videos...

The failed requests now seem to be getting redirect requests from cloud front.
https://content.jwplatform.com/thumbs/RBQ7uSk7-320.jpg?1486085779145 (301) => https://assets-jpcust.jwpsrv.com/thumbs/RBQ7uSk7-320.jpg?1486085779145


https://content.jwplatform.com/thumbs/RBQ7uSk7.jpg
(301) => https://assets-jpcust.jwpsrv.com/thumbs/RBQ7uSk7.jpg
https://content.jwplatform.com/videos/RBQ7uSk7.mp4?sig=69cbef429bec91de6156352cffc5e797&exp=1486089383 (302)=>

n...

User  
0 rated :

Hi Donni,

Some additional info... with the (now) working videos... (Sorry, previous was partial)

The failed requests now seem to be getting redirect requests from cloud front.
https://content.jwplatform.com/thumbs/RBQ7uSk7-320.jpg?1486085779145 (301) => https://assets-jpcust.jwpsrv.com/thumbs/RBQ7uSk7-320.jpg?1486085779145
https://content.jwplatform.com/thumbs/RBQ7uSk7.jpg (301) => https://assets-jpcust.jwpsrv.com/thumbs/RBQ7uSk7.jpg
https://content.jwplatform.com/videos/RBQ7uSk7.mp4?sig=69cbef429bec91de6156352cffc5e797&exp=1486089383 (302) => https://videos-f.jwpsrv.com/content/conversions/FIp7Z2ym/videos/RBQ7uSk7-27986207.mp4?token=0_5893e5a1_0x157fa184ae49e30ddf7cfca55446757813ae7729

The last one is a 302 redirect...

so perhaps now the issue is more in line with...the final video location is on a different server, and gets updated perhaps...and this reflects the "ready" status, but there is a propagation delay with the redirection rules?

N.B. It's been about 10 minutes since that recent test upload, and it is still failing.

Hope this extra info helps shed some light on the issue.

Sincerely,
Nathan

Donni

JW Player Support Agent  
0 rated :

Hi Nathan,

It can take a few minutes for videos to propagate throughout our CDN. I’m not seeing any errors in your account, which most likely is because enough time has passed since the initial upload for the video to propagate correctly. Can you help me understand what you are trying to do?

n...

User  
0 rated :

Hi Donni,

Sorry for the delay in responding.

It takes much longer than a few minutes...it can take many hours before it becomes visible on the CDN.

What I'm trying to do? I am trying to automate a video upload via the "download_url" path. Which appears to work, and the video shows up in the portal stating it is "Ready" to be played, only it definitely is not ready because the URL from the CDN side comes back with an error. This is a problem because if content is uploaded, and/or re-uploaded, then there is no way of knowing if it is truly ready. This issue would create a broken video on our site, which in this case, totally unacceptable.

I think that there is an issue in that your API reports that the video is ready (and the image thumbnail is ready, so transcoding has completed), but it is not ready AS CDN reports unavailable errors. I can think of a couple of technical reasons for this (one of which seems to be consistent with S3/AWS caching and that there is probably a fairly some simple technical solution s that can be done to fix the problem such that "ready" means exactly that.

The first path would be, as part of your infrastructure/upload process, *not check for any reason* the video as being ready against the *final CDN URL* until AFTER the item was sent to S3. If there is a pre-check in there like does this URL not exist before creating the final URL, then it may be invoking the TTL and thus the final video continues to report the URL as invalid until the TTL has passed. This isn't necessarily an easy thing to do and possibly error prone because of AWS caching of the final video on the CDN (I presume you are using AWS here given reference to fast transfer of files via S3). If you "touch" the final URL before the CDN can successfully retrieve the content from the S3 bucket, then you may be introducing the caching TTL into the mix, and that is possibly why I'm seeing huge delay before I can actually access the video.

The second path would be to force a cache refresh after your transcoding servers have uploaded the video to S3 in preparation of being distributed through to the CDN parts of AWS. One problem I have seen here is that if you refer to the final URL too early, then you invoke the cache TTL on S3/CDN (I myself have experienced this). One solution would be to not refer to the final URL against AWS within the transcoding process, or portal checking process, but add on some query string component (e.g. ?ts=<timestamp>) that will be fairly unique. This will cause the AWS cache to not cache against the FINAL url until you are sure that the data is actually up on S3, and that the AWS cache isn't referring to the final URL, and invoking the TTL for the video. N.B. AWS/S3 has an option on the CDN app that requires a check box to allow for querystrings in the URL. This allows you to effectively access the same resource but via a different URL, and what this does is allows you to bring in a new copy to the cache by changing the query string on the end to a new constant (i.e. using the time here is not wise...but an incrementing counter). I have used this technique in the past.

N.B. My video is part of a playlist (which is included via tags), so the video being added to the playlist would need to have a unique URL with a unique query string to be able to by-pass this problem. I haven't checked yet, but I suspect I cannot change the URL to the video In the playlist as the JWPlatform probably refers the final upload URL also.

N.B.2. I cannot use the querystring trick to force a refresh for the base/final URL, because the caching is for the whole URL, per URL and my cache copy is different to the final URL cache copy!

A third option is apparently, you can programmatically invalidate the AWS CDN cache directly. This would fit directly after the video was uploaded to the S3 bucket from the transcoding servers. That way, the very first access to the final URL will retrieve the video from the S3 bucket (which may be useful to warm the cache for end use).

In summary, this issue does not appear to be a simple Upload to CDN delay. **It also only appears to affect the download_url API**, but the upload through the portal seems to work straight away. Due to the delays involved I suspect it is in line with the TTL settings on the CDN you are using. Given these are effectively static videos, a large TTL would be expected. The time it take before it begins to work is sometimes many hours (far longer than a simple copy time).

If you could please talk to someone technical on this issue, I would be most happy to provide a suitable test case for the technical person to help resolve this issue.

I myself am a solution architect, and would love to help get this issue fixed for my client (and in the process help JWPlayer become a more robust solution)

Sincerely,
Nathan Bolstad

Donni

JW Player Support Agent  
0 rated :

Hi Nathan,

Sorry for the delay in response. I want to be able to escalate the issue but I’ll need some additional reproduction steps. Log in to your JW Dashboard and click the SUBMIT A CASE button and reference #99960 so we can discuss this further and see if anything has changed on your end since this post.

Warm Regards,
Donni

This question has received the maximum number of answers.