Video doesn't play in browser when uploaded from the app.

[rezzap]

Describe the bug

When I create a new video block from the app and then try to view this post in a web browser on desktop (Firefox), I only get the audio. The video portion doesn't play.

I've tested this on Personal and Premium plan sites, private or public and receive the same issue.

To Reproduce
Steps to reproduce the behavior:

1. Go to My Sites > Blog Posts > Add New post.
2. Click on the + symbol to add a new video block.
3. Select the option to upload from media library or from device.
4. Upload a video and then publish your post.
5. View the post on mobile, in the in-app browser or the actual browser (iOS Safari), the video works.
6. View the post on a desktop computer in a browser (Firefox and Chrome were tested in incognito), only the audio plays.

When I checked the path to the video itself, I get a forbidden error message. I can share links to testing sites if needed.

Expected behavior
I would expect that the video displays in a browser on desktop if it's working in the mobile browser.

Screenshots

Smartphone (please complete the following information):

• Device: iPhone X
• OS: 14.4
• Version Post created in WP app iOS 16.9

Additional context
The issue is specific to the browser so I'm not sure if it's app related, but given it only happens with posts created from the app I figured it would be a good place to start.

Reported in a chat: 28469174-hc
Follow up ticket: 3832447-zd-woothemes

[hypest]

Couldn't replicate on my side.

Device: iPhone 6s, iOS v14.3 (also tested on iOS v14.4.1)
App: WPiOS v16.9 from Testflight (not published to App Store at the time of writing.
Site plan: Premium on WPCOM
Desktop browsers: Firefox v86.0.1, Safari v14.0.3, Chrome v89.0.4389.90
Desktop OS: macos v11.2.1 Big Sur

[antonis]

I wasn't able to replicate this either.
Device: iPhone SE 2020, iOS 14.2
App Version: 16.9
Site plan: premium
Test post: https://antonistest.wordpress.com/2021/03/19/video-test/

I will update my device to 14.4 and try this again.

[hypest]

The issue is specific to the browser so I'm not sure if it's app related, but given it only happens with posts created from the app I figured it would be a good place to start.

👋 @rezzap , any specifics on which browser the user tried and on which OS? Thanks!

[antonis]

Tested again on iOS 14.4.1 and wasn't able to reproduce the issue.

[rezzap]

@hypest I don't know for sure which browser the user tried, but I replicated this on my end using Firefox 86.1 (64 bits), Chrome (89.0.4389.90). I'm now able to get the video to play in Safari though, but not the other browsers.

I'm on OS 10.15.7.

To confirm, the video works fine on the mobile web browser, it just doesn't play in a desktop browser on my MacBook when I create the block from the app.

[hypest]

Aha, good to know you can replicate @rezzap ! Is that on a site of your own that you can share details (example failing post) here perhaps? Thanks!

[rezzap]

I'll send you the details privately @hypest, since these are for private posts. Thanks!

[hypest]

Thanks for the info @rezzap . I noticed the posts in the private site of yours and yeah, can confirm that the mobile-app uploaded vide/post is only playing audio, while the Calypso uploaded one plays video+audio normally.

Thing is, looks like the Calypso one is not HEVC but H.264, so I wonder if there's some auto-transcoding that takes place in one flow but not the other. 👋 @roundhill , I think I kinda recall you mentioning at some point that there is indeed transcoding happening automatically. Can you confirm whether transcoding is happening when HEVC is uploaded via Calypso, and maybe not happening when the same HEVC video is uploaded via the mobile apps? Thanks!

[roundhill]

The auto-transcode is taking place for mobile video uploads, but I think y'all are inserting the original video and not the transcoded one(s). On the web we use the video shortcode to insert the VideoPress player into a post, which will load the transcoded videos that work across most browsers.

For example, @antonis' video details are at this endpoint: https://public-api.wordpress.com/rest/v1.1/videos/sIahVDOw

Happy to walk y'all through the transcoding process, I think it could be beneficial to get VideoPress working better on mobile.

[hypest]

I've added the "[Pri] High" as this is related to HEVC files on iOS which the users will probably use often.

[antonis]

I did a couple more tests today:

• As mentioned above the upload from mobile Safari works as expected.
• The Take a Video option seems to work since we are using Kanvas that defaults to h264.
• What does not work is selecting an HEVC video from the device (2nd video in this test post)

[hypest]

Headsup that I believe wordpress-mobile/WordPress-iOS#16548 will address this issue.

[roundhill]

It may be better to do a bit of API back-and-forth when uploading to a site using VideoPress, so that you can insert the h264 transcoded video into the block instead of the original file:

• After uploading, you'll get a media id, you could then hit /sites/{site-url}/media/{media-id}.
• In that media response there should be a videopress_guid property if the site is using VideoPress.
• You can take that videopress_guid and use it for this endpoint: https://public-api.wordpress.com/rest/v1/videos/{guid} (Ex: https://public-api.wordpress.com/rest/v1/videos/bPak0vYH)
• That endpoint gives you the current transcode status and the Urls to the transcoded videos. It probably makes the most sense to insert the hd version into the block.

[hypest]

Thanks for the analytical instructions @roundhill!

Do you think the same would be needed for Atomic sites? There's a similar ticket on Android and I do see while testing that uploading to Atomic ends up in broken posts on the frontend (example from a test site of mine).

That endpoint gives you the current transcode status and the Urls to the transcoded videos. It probably makes the most sense to insert the hd version into the block.

About that step in particular, looks like the URLs for the transcoded files are not available until the transcoding is finished for each individual variant. What's the recommended flow in that case? Should we poll to see when the transcoding is finished (say, for the hd variant) or is it safe to construct the URL locally based on the original URL and append something like _hd to form the one we want?

[SiobhyB]

Noting that this is still an issue and I think the [Pri] High label remains valid, as the experience is fundamentally broken for users.

[SiobhyB]

Fixed in Automattic/jetpack#35637.

[hypest]

Fixed in Automattic/jetpack#35637

This.is.great! 💚