Page MenuHomePhabricator

[iOS app] Some media (esp. video) files do not work
Open, MediumPublic

Description

Video files in particular, do not play.

For video files, a thumbnail is shown but tapping it does nothing. See [[Blowing a raspberry]].

For audio files, with mp3 support most embedded audio files now play, more could be done to improve the UX, but basic audio playback works. Additionally prononciation guides or other audio links embedded in templates still do not play. See linked task/discussion in comments below.

The gray box also has too much padding, so that it covers some of the surrounding text/article content. See for example [[When Johnny Comes Marching Home]].

Details

Reference
bz66722

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:18 AM
bzimport set Reference to bz66722.
bzimport added a subscriber: Unknown Object (MLST).
Ragesoss created this task.Jun 17 2014, 2:38 PM
brion added a comment.Jun 17 2014, 9:23 PM

We should probably do a short-term workaround that turns the <audio> or <video> elements into links which offer to open the files in VLC (or offers to go install the VLC app via iTunes).

A proper fix for this will probably come later this year (depending on when we have a chance to prioritize it)... requires manually writing a basic video player around the ogg/vorbis/theora libraries. (I have some basic proof of concept code for iOS and more mature code for web/JavaScript/Flash which I can adapt.)

brion added a comment.Jun 23 2014, 9:27 PM

Ok, as a quick fix I've restored the code that hides the "Cannot play audio file" on audio bits, will see about making both audio and video able to open in VLC later.

brion added a subscriber: brion.Jan 18 2015, 5:47 PM
Deskana triaged this task as Medium priority.Mar 23 2015, 9:32 PM
brion added a comment.Mar 28 2016, 9:53 PM

Summary update:

  • iOS doesn't include support for Ogg or WebM media, so native display doesn't work
  • I have a library available which provides a suitable player widget, using the standard open-source decoder libraries for both Ogg and WebM
    • cleaning that up so it's easy to pull into the Wikipedia app is task T91689

So roughly what needs to happen:

  • clean up the OGVKit framework packaging (T91689)
  • add code to the media view mode in Wikipedia app to:
    • fetch transcode/deriv file data
    • launch an OGVKit player with suitably-selected video or audio transcode for audio/* or video/* files in place of the image
  • make sure the in-article view makes sense
    • make sure videos have a play icon?
    • make sure audio makes sense?
    • might have to handle direct links to .ogg files for pronunication etc?
This comment was removed by Josve05a.
yangand added a subscriber: yangand.Jul 5 2017, 5:42 PM

PoC of using brion's OGVKit in wikipedia iOS

https://www.youtube.com/watch?v=rTb9peS9X6c

I didn't try to run it on real device. I tried to use brion's ogv.js but cannot run it in simulator due to misunderstanding how webkit webvideo works.
PoC reads meta from api.php for 'File:<name>.ogv' files and pass url for the file with lowest bandwith to OGVKit.

JMinor added a comment.Jul 5 2017, 5:54 PM

Thanks @yangand !! Is there a pull request or branch we could peek at?

I'll put this on our roadmap for revisiting after our next version, since this seems like good progress to consider.

@JMinor https://github.com/wikimedia/wikipedia-ios/pull/1595 added but please don't merge it to develop, it should be tested on iPad and need additional actions to develop like 'close' buttons, different video quality selection, errors processing, it supports .ogv files only (I just parse html images for .ogv files only).

JMinor added a comment.Jul 5 2017, 6:54 PM

Thanks for the PR. Don't worry, it definitely won't get merged as is, have a PR just helps us to potentially give you high level feedback and understand the POC for planning.

brion added a comment.Jul 5 2017, 6:57 PM

Note if y'all are interested in moving forward on this, I can finish up the CocoaPods packaging on OGVKit. :)

brion added a comment.Jan 9 2018, 9:40 PM

Audio should work now (using MP3 transcodes). Video still a work in progress.

JMinor added a comment.Jan 9 2018, 9:54 PM

Yes, we tested yesterday and everything "just works". Huge!

We noticed that pronunciation examples haven't been transcoded? Are they handled differently than other audio?

I filed a task to look into it, but not sure where to take that.

brion added a comment.Jan 9 2018, 9:58 PM

I think a lot of pronunciation samples are linked directly to the source file -- eg [[Media:Ja-Godzilla.oga]] instead of inline players [[File:Ja-Godzilla.oga]]. That bypasses the multi-format support in the <audio> element, and if the source format isn't natively supported, no dice. We can either do a 'smart link handler' in the app -- eg see a ".ogg" or ".oga" link and transform it into the derivative .mp3 link -- or we can devise a new way for users to embed tiny players that are more reliable.

I'd wager the former is easier. :)

brion added a comment.Jan 9 2018, 10:03 PM

for reference that's T183471 -- added note.

JMinor renamed this task from [iOS app] Media files do not work to [iOS app] Some media (esp. video) files do not work.Mar 13 2018, 5:45 PM
JMinor updated the task description. (Show Details)
JMinor removed a subscriber: wikibugs-l-list.

Adding OTRS ticket

https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=11291821

When will we be able to play video media in the Wikipedia app? Thanks! Steve

Hi all.

For now, one quick workaround might be to intercept the click and spawn a WKWebView to the desktop pinned version of the Commons URL like https://commons.wikimedia.org/w/index.php?title=File:Jupiter-HubbleSpaceTelescope-Animation-20190823.webm&mobileaction=toggle_view_desktop where playback works. For a more mobile-friendly skin but still desktop try https://commons.wikimedia.org/w/index.php?title=File:Jupiter-HubbleSpaceTelescope-Animation-20190823.webm&mobileaction=toggle_view_desktop&useskin=Minerva . The URL formats have been relatively stable, but you probably should check with Web in case any changes are anticipated in the future. TimedMediaHandler (TMH) will be getting updates that allow more seamless mdot WebKit compatible playback from a ResourceLoader-based JS context - point being eventually you may not need extra URL parameters in the future.