Hi all,
Observations on the upload and playback of https://commons.wikimedia.org/wiki/File:Wikipedia_5_million_articles_milesto... :
1. I'm impressed by how much the video compressed, down to 1.97 Mbps on WebM 1080P.
2. I had multiple problems when uploading this file in WebM/VP9 format. Firefox crashed every time I tried to use the upload wizard with chunked uploads enabled. IE was successful after I changed my chunked upload setting to 1 simultaneous upload.
3. The upload progress bar was very inaccurate on Firefox. On IE, the bar seemed to indicate the upload progress of the 5MB chunks rather than the progress of the whole video.
4. The automated transcoding process to multiple formats on Commons is nice, although there was a notable decrease in audio quality on the OGV file that I downloaded.
5. On playback of the video in ENWP by clicking the thumbnail which results in the video popup window, I think it would be good to make the option to fullscreen the video more obvious to the viewer inside of the popup window.
Thanks!
Pine
On Thu, 29 Oct 2015 21:14:34 +0100, Pine W wiki.pine@gmail.com wrote:
- The upload progress bar was very inaccurate on Firefox. On IE, the
bar seemed to indicate the upload progress of the 5MB chunks rather than the progress of the whole video.
We're fixing this! https://gerrit.wikimedia.org/r/248923
I just tried playing the video on Android. Good news, bad news:
The video plays as expected in the Wikipedia app.
The video has major problems playing in Firefox for Android and the default Android browser for mobile web.
Can someone else please test those latter two configurations? If problems are confirmed, how long will a fix take, keeping in mind how close we are (4,998,070 articles) to the 5M milestone?
Pine
We don't yet have fully "on purpose" multimedia support on mobile -- eg if it works at all, that's awesome. :) But it's probably sub-ideal in a number of ways. (On iOS in particular we have *no* playback except in the desktop mode due to Safari's lack of native WebM or Ogg support; the ogv.js JavaScript playback has only been integrated on the desktop mode so far, as we need to clean up TimedMediaHandler's JS-side code to run cleanly on mobile... and not suck on desktop.)
Questions: * Are you viewing the File: page in a browser directly, or some page that includes the file on it? (If the latter, which page?) * Are you pressing the 'play' button on an image thumbnail, or clicking the "download original file" link, or something else? * What device are you using? * What Android version are you running on?
General issues: * There's no manual resolution selection override in the user interface, so you might be getting a high resolution file that's too slow to decode. * In Firefox in particular you may not be getting the benefit of hardware acceleration for WebM video decoding. * The 'Android default browser' may or may not exist on any given device (many newer devices just have Chrome, so I can't test it locally on my Nexus 5 or 5x).
There may or may not be any 'fixes' we can make in a short term. Note there are *no* WMF resources assigned to video at present, so things get fixed only as someone interested in the topic gets to them.
-- brion
On Thu, Oct 29, 2015 at 7:16 PM, Pine W wiki.pine@gmail.com wrote:
I just tried playing the video on Android. Good news, bad news:
The video plays as expected in the Wikipedia app.
The video has major problems playing in Firefox for Android and the default Android browser for mobile web.
Can someone else please test those latter two configurations? If problems are confirmed, how long will a fix take, keeping in mind how close we are (4,998,070 articles) to the 5M milestone?
Pine
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
I'm guessing this is on https://commons.m.wikimedia.org/wiki/File:Wikipedia_5_million_articles_miles... ...
... in which case the problem is that inline/thumbnail usages of videos by default use a 'popup transform' that -- until currently desktop-only JavaScript is loaded -- is just a thumbnail image plus a link to the original file. (The code for the proper player is hidden away where it can be loaded into a popup window by the JS.)
This is pretty awful on mobile at present, as the thumbnail does nothing when you click on it, while there's a 'play media' link that sends you to the highest-resolution file you could possibly download. This means you're trying to play a full HD 1920x1080 video from the original VP9 source, which while a great format can be somewhat CPU-intensive.
I have some planned refactoring that should improve this by including a stripped-down player inline for the mobile/non-JS cases, but beware it wouldn't get deployed until sometime mid to late next week even if we hurry it. (We do not deploy on Fridays or weekends!)
-- brion
On Thu, Oct 29, 2015 at 7:39 PM, Brion Vibber bvibber@wikimedia.org wrote:
We don't yet have fully "on purpose" multimedia support on mobile -- eg if it works at all, that's awesome. :) But it's probably sub-ideal in a number of ways. (On iOS in particular we have *no* playback except in the desktop mode due to Safari's lack of native WebM or Ogg support; the ogv.js JavaScript playback has only been integrated on the desktop mode so far, as we need to clean up TimedMediaHandler's JS-side code to run cleanly on mobile... and not suck on desktop.)
Questions:
- Are you viewing the File: page in a browser directly, or some page that
includes the file on it? (If the latter, which page?)
- Are you pressing the 'play' button on an image thumbnail, or clicking
the "download original file" link, or something else?
- What device are you using?
- What Android version are you running on?
General issues:
- There's no manual resolution selection override in the user interface,
so you might be getting a high resolution file that's too slow to decode.
- In Firefox in particular you may not be getting the benefit of hardware
acceleration for WebM video decoding.
- The 'Android default browser' may or may not exist on any given device
(many newer devices just have Chrome, so I can't test it locally on my Nexus 5 or 5x).
There may or may not be any 'fixes' we can make in a short term. Note there are *no* WMF resources assigned to video at present, so things get fixed only as someone interested in the topic gets to them.
-- brion
On Thu, Oct 29, 2015 at 7:16 PM, Pine W wiki.pine@gmail.com wrote:
I just tried playing the video on Android. Good news, bad news:
The video plays as expected in the Wikipedia app.
The video has major problems playing in Firefox for Android and the default Android browser for mobile web.
Can someone else please test those latter two configurations? If problems are confirmed, how long will a fix take, keeping in mind how close we are (4,998,070 articles) to the 5M milestone?
Pine
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On Thu, Oct 29, 2015 at 8:10 PM, Brion Vibber bvibber@wikimedia.org wrote:
I'm guessing this is on https://commons.m.wikimedia.org/wiki/File:Wikipedia_5_million_articles_miles... ...
whhops copy-paste error :D https://en.m.wikipedia.org/wiki/Wikipedia:Five_million_articles
-- brion
... in which case the problem is that inline/thumbnail usages of videos by default use a 'popup transform' that -- until currently desktop-only JavaScript is loaded -- is just a thumbnail image plus a link to the original file. (The code for the proper player is hidden away where it can be loaded into a popup window by the JS.)
This is pretty awful on mobile at present, as the thumbnail does nothing when you click on it, while there's a 'play media' link that sends you to the highest-resolution file you could possibly download. This means you're trying to play a full HD 1920x1080 video from the original VP9 source, which while a great format can be somewhat CPU-intensive.
I have some planned refactoring that should improve this by including a stripped-down player inline for the mobile/non-JS cases, but beware it wouldn't get deployed until sometime mid to late next week even if we hurry it. (We do not deploy on Fridays or weekends!)
-- brion
On Thu, Oct 29, 2015 at 7:39 PM, Brion Vibber bvibber@wikimedia.org wrote:
We don't yet have fully "on purpose" multimedia support on mobile -- eg if it works at all, that's awesome. :) But it's probably sub-ideal in a number of ways. (On iOS in particular we have *no* playback except in the desktop mode due to Safari's lack of native WebM or Ogg support; the ogv.js JavaScript playback has only been integrated on the desktop mode so far, as we need to clean up TimedMediaHandler's JS-side code to run cleanly on mobile... and not suck on desktop.)
Questions:
- Are you viewing the File: page in a browser directly, or some page that
includes the file on it? (If the latter, which page?)
- Are you pressing the 'play' button on an image thumbnail, or clicking
the "download original file" link, or something else?
- What device are you using?
- What Android version are you running on?
General issues:
- There's no manual resolution selection override in the user interface,
so you might be getting a high resolution file that's too slow to decode.
- In Firefox in particular you may not be getting the benefit of hardware
acceleration for WebM video decoding.
- The 'Android default browser' may or may not exist on any given device
(many newer devices just have Chrome, so I can't test it locally on my Nexus 5 or 5x).
There may or may not be any 'fixes' we can make in a short term. Note there are *no* WMF resources assigned to video at present, so things get fixed only as someone interested in the topic gets to them.
-- brion
On Thu, Oct 29, 2015 at 7:16 PM, Pine W wiki.pine@gmail.com wrote:
I just tried playing the video on Android. Good news, bad news:
The video plays as expected in the Wikipedia app.
The video has major problems playing in Firefox for Android and the default Android browser for mobile web.
Can someone else please test those latter two configurations? If problems are confirmed, how long will a fix take, keeping in mind how close we are (4,998,070 articles) to the 5M milestone?
Pine
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Ok. In the meantime, is there a way to make the text that I just added to the video caption, "(If you want to view this video on an Android device, you might need to install the Wikipedia app from the Google Play store https://play.google.com and then use the app to view the video.)", appear only when the page is being viewed on Android?
Pine
On Thu, Oct 29, 2015 at 8:11 PM, Brion Vibber bvibber@wikimedia.org wrote:
On Thu, Oct 29, 2015 at 8:10 PM, Brion Vibber bvibber@wikimedia.org wrote:
I'm guessing this is on https://commons.m.wikimedia.org/wiki/File:Wikipedia_5_million_articles_miles... ...
whhops copy-paste error :D https://en.m.wikipedia.org/wiki/Wikipedia:Five_million_articles
-- brion
... in which case the problem is that inline/thumbnail usages of videos by default use a 'popup transform' that -- until currently desktop-only JavaScript is loaded -- is just a thumbnail image plus a link to the original file. (The code for the proper player is hidden away where it can be loaded into a popup window by the JS.)
This is pretty awful on mobile at present, as the thumbnail does nothing when you click on it, while there's a 'play media' link that sends you to the highest-resolution file you could possibly download. This means you're trying to play a full HD 1920x1080 video from the original VP9 source, which while a great format can be somewhat CPU-intensive.
I have some planned refactoring that should improve this by including a stripped-down player inline for the mobile/non-JS cases, but beware it wouldn't get deployed until sometime mid to late next week even if we hurry it. (We do not deploy on Fridays or weekends!)
-- brion
On Thu, Oct 29, 2015 at 7:39 PM, Brion Vibber bvibber@wikimedia.org wrote:
We don't yet have fully "on purpose" multimedia support on mobile -- eg if it works at all, that's awesome. :) But it's probably sub-ideal in a number of ways. (On iOS in particular we have *no* playback except in the desktop mode due to Safari's lack of native WebM or Ogg support; the ogv.js JavaScript playback has only been integrated on the desktop mode so far, as we need to clean up TimedMediaHandler's JS-side code to run cleanly on mobile... and not suck on desktop.)
Questions:
- Are you viewing the File: page in a browser directly, or some page
that includes the file on it? (If the latter, which page?)
- Are you pressing the 'play' button on an image thumbnail, or clicking
the "download original file" link, or something else?
- What device are you using?
- What Android version are you running on?
General issues:
- There's no manual resolution selection override in the user interface,
so you might be getting a high resolution file that's too slow to decode.
- In Firefox in particular you may not be getting the benefit of
hardware acceleration for WebM video decoding.
- The 'Android default browser' may or may not exist on any given device
(many newer devices just have Chrome, so I can't test it locally on my Nexus 5 or 5x).
There may or may not be any 'fixes' we can make in a short term. Note there are *no* WMF resources assigned to video at present, so things get fixed only as someone interested in the topic gets to them.
-- brion
On Thu, Oct 29, 2015 at 7:16 PM, Pine W wiki.pine@gmail.com wrote:
I just tried playing the video on Android. Good news, bad news:
The video plays as expected in the Wikipedia app.
The video has major problems playing in Firefox for Android and the default Android browser for mobile web.
Can someone else please test those latter two configurations? If problems are confirmed, how long will a fix take, keeping in mind how close we are (4,998,070 articles) to the 5M milestone?
Pine
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Hi, I tried the video on Android 5.1 Lollipop (Samsung Galaxy S6) and it was choppy and unreliable.
At this point in time, you might consider going with VP8 for the highest compatibility. VP9 is still kind of bleeding edge.
As for the content:
* I think it's a great effort but editorially, I'd start right with the Wikipedia-specific content without the (admittedly great) visual night sky. The first minute of the video isn't really about Wikipedia.
* At 1:55 when I see "263 registered course instructions" I'm underwhelmed. As someone who's active in the Wiki edu space, I said to myself, "I thought there'd be more..." For higher impact, I'd say "less is more" and cut off the list at administrators.
Good to see the effort being put into more video.
-Andrew
On Fri, Oct 30, 2015 at 12:20 AM, Pine W wiki.pine@gmail.com wrote:
Ok. In the meantime, is there a way to make the text that I just added to the video caption, "(If you want to view this video on an Android device, you might need to install the Wikipedia app from the Google Play store https://play.google.com and then use the app to view the video.)", appear only when the page is being viewed on Android?
Pine
On Thu, Oct 29, 2015 at 8:11 PM, Brion Vibber bvibber@wikimedia.org wrote:
On Thu, Oct 29, 2015 at 8:10 PM, Brion Vibber bvibber@wikimedia.org wrote:
I'm guessing this is on https://commons.m.wikimedia.org/wiki/File:Wikipedia_5_million_articles_miles... ...
whhops copy-paste error :D https://en.m.wikipedia.org/wiki/Wikipedia:Five_million_articles
-- brion
... in which case the problem is that inline/thumbnail usages of videos by default use a 'popup transform' that -- until currently desktop-only JavaScript is loaded -- is just a thumbnail image plus a link to the original file. (The code for the proper player is hidden away where it can be loaded into a popup window by the JS.)
This is pretty awful on mobile at present, as the thumbnail does nothing when you click on it, while there's a 'play media' link that sends you to the highest-resolution file you could possibly download. This means you're trying to play a full HD 1920x1080 video from the original VP9 source, which while a great format can be somewhat CPU-intensive.
I have some planned refactoring that should improve this by including a stripped-down player inline for the mobile/non-JS cases, but beware it wouldn't get deployed until sometime mid to late next week even if we hurry it. (We do not deploy on Fridays or weekends!)
-- brion
On Thu, Oct 29, 2015 at 7:39 PM, Brion Vibber bvibber@wikimedia.org wrote:
We don't yet have fully "on purpose" multimedia support on mobile -- eg if it works at all, that's awesome. :) But it's probably sub-ideal in a number of ways. (On iOS in particular we have *no* playback except in the desktop mode due to Safari's lack of native WebM or Ogg support; the ogv.js JavaScript playback has only been integrated on the desktop mode so far, as we need to clean up TimedMediaHandler's JS-side code to run cleanly on mobile... and not suck on desktop.)
Questions:
- Are you viewing the File: page in a browser directly, or some page
that includes the file on it? (If the latter, which page?)
- Are you pressing the 'play' button on an image thumbnail, or clicking
the "download original file" link, or something else?
- What device are you using?
- What Android version are you running on?
General issues:
- There's no manual resolution selection override in the user
interface, so you might be getting a high resolution file that's too slow to decode.
- In Firefox in particular you may not be getting the benefit of
hardware acceleration for WebM video decoding.
- The 'Android default browser' may or may not exist on any given
device (many newer devices just have Chrome, so I can't test it locally on my Nexus 5 or 5x).
There may or may not be any 'fixes' we can make in a short term. Note there are *no* WMF resources assigned to video at present, so things get fixed only as someone interested in the topic gets to them.
-- brion
On Thu, Oct 29, 2015 at 7:16 PM, Pine W wiki.pine@gmail.com wrote:
I just tried playing the video on Android. Good news, bad news:
The video plays as expected in the Wikipedia app.
The video has major problems playing in Firefox for Android and the default Android browser for mobile web.
Can someone else please test those latter two configurations? If problems are confirmed, how long will a fix take, keeping in mind how close we are (4,998,070 articles) to the 5M milestone?
Pine
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
That's a good point about VP8. If I need to re-render the video anyway due to the milestone happening in November, I'll try doing to with VP8.
Content is frozen at this point, aside from necessary tweaks for the November change and maybe some easy updates to the statistics page.
Yes, that's a mediocre number of course instructors, but it's a good point of conversation IMO.
I've heard mixed thoughts about the opening scene. Most people appreciate the aesthetics, although one person told me to expect varied levels of appreciation for poetry. The positive comments have outweighed the critics by about a 5:1 margin, so I'm leaving it as it is. (:
Pine
On Fri, Oct 30, 2015 at 8:12 AM, Andrew Lih andrew.lih@gmail.com wrote:
Hi, I tried the video on Android 5.1 Lollipop (Samsung Galaxy S6) and it was choppy and unreliable.
At this point in time, you might consider going with VP8 for the highest compatibility. VP9 is still kind of bleeding edge.
As for the content:
- I think it's a great effort but editorially, I'd start right with the
Wikipedia-specific content without the (admittedly great) visual night sky. The first minute of the video isn't really about Wikipedia.
- At 1:55 when I see "263 registered course instructions" I'm
underwhelmed. As someone who's active in the Wiki edu space, I said to myself, "I thought there'd be more..." For higher impact, I'd say "less is more" and cut off the list at administrators.
Good to see the effort being put into more video.
-Andrew
On Fri, Oct 30, 2015 at 12:20 AM, Pine W wiki.pine@gmail.com wrote:
Ok. In the meantime, is there a way to make the text that I just added to the video caption, "(If you want to view this video on an Android device, you might need to install the Wikipedia app from the Google Play store https://play.google.com and then use the app to view the video.)", appear only when the page is being viewed on Android?
Pine
On Thu, Oct 29, 2015 at 8:11 PM, Brion Vibber bvibber@wikimedia.org wrote:
On Thu, Oct 29, 2015 at 8:10 PM, Brion Vibber bvibber@wikimedia.org wrote:
I'm guessing this is on https://commons.m.wikimedia.org/wiki/File:Wikipedia_5_million_articles_miles... ...
whhops copy-paste error :D https://en.m.wikipedia.org/wiki/Wikipedia:Five_million_articles
-- brion
... in which case the problem is that inline/thumbnail usages of videos by default use a 'popup transform' that -- until currently desktop-only JavaScript is loaded -- is just a thumbnail image plus a link to the original file. (The code for the proper player is hidden away where it can be loaded into a popup window by the JS.)
This is pretty awful on mobile at present, as the thumbnail does nothing when you click on it, while there's a 'play media' link that sends you to the highest-resolution file you could possibly download. This means you're trying to play a full HD 1920x1080 video from the original VP9 source, which while a great format can be somewhat CPU-intensive.
I have some planned refactoring that should improve this by including a stripped-down player inline for the mobile/non-JS cases, but beware it wouldn't get deployed until sometime mid to late next week even if we hurry it. (We do not deploy on Fridays or weekends!)
-- brion
On Thu, Oct 29, 2015 at 7:39 PM, Brion Vibber bvibber@wikimedia.org wrote:
We don't yet have fully "on purpose" multimedia support on mobile -- eg if it works at all, that's awesome. :) But it's probably sub-ideal in a number of ways. (On iOS in particular we have *no* playback except in the desktop mode due to Safari's lack of native WebM or Ogg support; the ogv.js JavaScript playback has only been integrated on the desktop mode so far, as we need to clean up TimedMediaHandler's JS-side code to run cleanly on mobile... and not suck on desktop.)
Questions:
- Are you viewing the File: page in a browser directly, or some page
that includes the file on it? (If the latter, which page?)
- Are you pressing the 'play' button on an image thumbnail, or
clicking the "download original file" link, or something else?
- What device are you using?
- What Android version are you running on?
General issues:
- There's no manual resolution selection override in the user
interface, so you might be getting a high resolution file that's too slow to decode.
- In Firefox in particular you may not be getting the benefit of
hardware acceleration for WebM video decoding.
- The 'Android default browser' may or may not exist on any given
device (many newer devices just have Chrome, so I can't test it locally on my Nexus 5 or 5x).
There may or may not be any 'fixes' we can make in a short term. Note there are *no* WMF resources assigned to video at present, so things get fixed only as someone interested in the topic gets to them.
-- brion
On Thu, Oct 29, 2015 at 7:16 PM, Pine W wiki.pine@gmail.com wrote:
I just tried playing the video on Android. Good news, bad news:
The video plays as expected in the Wikipedia app.
The video has major problems playing in Firefox for Android and the default Android browser for mobile web.
Can someone else please test those latter two configurations? If problems are confirmed, how long will a fix take, keeping in mind how close we are (4,998,070 articles) to the 5M milestone?
Pine
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On 10/30/15, Andrew Lih andrew.lih@gmail.com wrote:
Hi, I tried the video on Android 5.1 Lollipop (Samsung Galaxy S6) and it was choppy and unreliable.
At this point in time, you might consider going with VP8 for the highest compatibility. VP9 is still kind of bleeding edge.
Are you sure that you viewed the VP9 version? I would expect the TimedMediaHandler js (if it was working properly, usually a big if) to select the VP8 transcoded version for playback, not the original.
On the mobile view, if you click the 'play media' link on a popup transform you get the original source. It's kinda bad. :(
If you get the actual <video> tag then it selects a medium-resolution VP8 source by default which looks a bit nicer. I need to rework all this logic to not be awful. ;)
-- brion
On Fri, Oct 30, 2015 at 3:22 PM, Brian Wolff bawolff@gmail.com wrote:
On 10/30/15, Andrew Lih andrew.lih@gmail.com wrote:
Hi, I tried the video on Android 5.1 Lollipop (Samsung Galaxy S6) and it was choppy and unreliable.
At this point in time, you might consider going with VP8 for the highest compatibility. VP9 is still kind of bleeding edge.
Are you sure that you viewed the VP9 version? I would expect the TimedMediaHandler js (if it was working properly, usually a big if) to select the VP8 transcoded version for playback, not the original.
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On 10/30/15, Brian Wolff bawolff@gmail.com wrote:
On 10/30/15, Andrew Lih andrew.lih@gmail.com wrote:
Hi, I tried the video on Android 5.1 Lollipop (Samsung Galaxy S6) and it was choppy and unreliable.
At this point in time, you might consider going with VP8 for the highest compatibility. VP9 is still kind of bleeding edge.
Are you sure that you viewed the VP9 version? I would expect the TimedMediaHandler js (if it was working properly, usually a big if) to select the VP8 transcoded version for playback, not the original.
err. nevermind. TMH selects the vp9 as the best possible source on my phone for some reason, so it probably does the same for you too.
The chopiness might not even have anything to do with vp9 so much as the high bit-rate of the original source being too much for a phone or something, although hard to know for sure. The VP8 1080p transcode behaves rather chopily on my phone too.
All I can say for sure is that the webm VP8 480p transcode plays nicely on my kind of oldish phone. The VP8 720p is a bit choppy but not too bad.
-- -bawolff
Can we use this situation as evidence that WMF resources should urgently be directed to improving end-users' video viewing experiences on mobile? (:
On Fri, Oct 30, 2015 at 3:36 PM, Brian Wolff bawolff@gmail.com wrote:
On 10/30/15, Brian Wolff bawolff@gmail.com wrote:
On 10/30/15, Andrew Lih andrew.lih@gmail.com wrote:
Hi, I tried the video on Android 5.1 Lollipop (Samsung Galaxy S6) and it was choppy and unreliable.
At this point in time, you might consider going with VP8 for the highest compatibility. VP9 is still kind of bleeding edge.
Are you sure that you viewed the VP9 version? I would expect the TimedMediaHandler js (if it was working properly, usually a big if) to select the VP8 transcoded version for playback, not the original.
err. nevermind. TMH selects the vp9 as the best possible source on my phone for some reason, so it probably does the same for you too.
The chopiness might not even have anything to do with vp9 so much as the high bit-rate of the original source being too much for a phone or something, although hard to know for sure. The VP8 1080p transcode behaves rather chopily on my phone too.
All I can say for sure is that the webm VP8 480p transcode plays nicely on my kind of oldish phone. The VP8 720p is a bit choppy but not too bad.
-- -bawolff
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Update: I have uploaded a new version of the video, this time in OGV. Observations:
*The video now plays with acceptable performance in Firefox and the Wikipedia App on Android mobile *The video doesn't play at all in the default Android browser, nor in Chrome on Android *On desktop, the video doesn't automatically increase the quality of the file download when a user maximizes the window, meaning that a user who clicks the thumbnail on ENWP, gets the popup, then clicks maximize will likely see a file that looks awful when full-screened until and unless they find the button to increase the video quality. *On IE on desktop, the default popup for me is for 360p even though that's smaller than it should be for the size of the popup that I get, so the video quality in the popup is poor. The popup should be for 480p. *I haven't tested iPhone and Mac desktop browsers
Between VP9 and OGV, I'd say that our support for video playback has much room for improvement on both desktop and mobile.
On Fri, Oct 30, 2015 at 3:39 PM, Pine W wiki.pine@gmail.com wrote:
Can we use this situation as evidence that WMF resources should urgently be directed to improving end-users' video viewing experiences on mobile? (:
On Fri, Oct 30, 2015 at 3:36 PM, Brian Wolff bawolff@gmail.com wrote:
On 10/30/15, Brian Wolff bawolff@gmail.com wrote:
On 10/30/15, Andrew Lih andrew.lih@gmail.com wrote:
Hi, I tried the video on Android 5.1 Lollipop (Samsung Galaxy S6) and
it
was choppy and unreliable.
At this point in time, you might consider going with VP8 for the
highest
compatibility. VP9 is still kind of bleeding edge.
Are you sure that you viewed the VP9 version? I would expect the TimedMediaHandler js (if it was working properly, usually a big if) to select the VP8 transcoded version for playback, not the original.
err. nevermind. TMH selects the vp9 as the best possible source on my phone for some reason, so it probably does the same for you too.
The chopiness might not even have anything to do with vp9 so much as the high bit-rate of the original source being too much for a phone or something, although hard to know for sure. The VP8 1080p transcode behaves rather chopily on my phone too.
All I can say for sure is that the webm VP8 480p transcode plays nicely on my kind of oldish phone. The VP8 720p is a bit choppy but not too bad.
-- -bawolff
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On 10/31/15, Pine W wiki.pine@gmail.com wrote:
Update: I have uploaded a new version of the video, this time in OGV. Observations:
*The video now plays with acceptable performance in Firefox and the Wikipedia App on Android mobile *The video doesn't play at all in the default Android browser, nor in Chrome on Android *On desktop, the video doesn't automatically increase the quality of the file download when a user maximizes the window, meaning that a user who clicks the thumbnail on ENWP, gets the popup, then clicks maximize will likely see a file that looks awful when full-screened until and unless they find the button to increase the video quality. *On IE on desktop, the default popup for me is for 360p even though that's smaller than it should be for the size of the popup that I get, so the video quality in the popup is poor. The popup should be for 480p. *I haven't tested iPhone and Mac desktop browsers
Between VP9 and OGV, I'd say that our support for video playback has much room for improvement on both desktop and mobile.
You uploaded an 8.01 Mbp webm video, and are comparing it to a 6.47 Mbps ogg video. The less stuttering you experienced might have nothing to do with the format but with the lower bitrate (Or it could have something to do with the format. Hard to say).
*The video doesn't play at all in the default Android browser, nor in Chrome on Android
How soon after you uploaded did you try. MediaWiki probably just hadn't converted it to webm yet.
-- -bawolff
Still doesn't play on the default Android browser, nor in Chrome on Android.
I agree with Brian, the choppiness is much more likely to have to do with excessive bitrate than the format at hand. For reference, youtube uses a 2Mbps bitrate for the 1080p VP9 videos they serve. I'd recommend trying to compressing the original VP9 video at that bitrate to see if the choppiness goes away.
If that solves the problem, I think it's an indication that we should transcode videos down to a lower bitrate when the original bitrate is too high, even when the format is playable as-is.
As an anecdote, in ye olde times of learning DVD production at university, we were shown statistics about how real dvd players handled bitrate in the wild and it turns out that you had to be extremely conservative about both the average bitrate of your video and the maximum peak bitrate (when using variable bitrate), otherwise playback could be choppy on consumer DVD players. I can't remember the values, but they were very far from the theoretical maximum of the DVD specification. As much as it sucks to see the quality loss due to the extra compression required to abide to very conservative bitrates as the publisher of the video, it's what made the difference between the video being playable at all by people or not. If it's choppy for them, they're definitely not going to watch the whole thing.
On Sun, Nov 1, 2015 at 10:14 PM, Pine W wiki.pine@gmail.com wrote:
Still doesn't play on the default Android browser, nor in Chrome on Android.
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
My understanding is that one of the points of going to VP9 is that it's good at varying its bit rate depending on available throughput. If bitrare really was the problem with the VP9 version, that suggests that VP9 failed at one of the reasons for using it in the first place.
Pine
Another factor that males me think that the format rather than the bit rate is the problem: the VP9 video played just fine in the Wikipedia App on Android, but not in browsers on Android.
Pine On Nov 1, 2015 11:41 PM, "Pine W" wiki.pine@gmail.com wrote:
My understanding is that one of the points of going to VP9 is that it's good at varying its bit rate depending on available throughput. If bitrare really was the problem with the VP9 version, that suggests that VP9 failed at one of the reasons for using it in the first place.
Pine
Re Gilles:
If that solves the problem, I think it's an indication that we should transcode videos down to a lower bitrate when the original bitrate is too high, even when the format is playable as-is.
We actually do, but timed media handler has decided the original is a better source to suggest as default :(
Re Pine:
My understanding is that one of the points of going to VP9 is that it's good at varying its bit rate depending on available throughput. If bitrare really was the problem with the VP9 version, that suggests that VP9 failed at one of the reasons for using it in the first place.
I have never heard that. My understanding is the primary benefit is being optimized for high resolution (HD) video, where there are a lot more pixels, but larger areas of pixels look similar.
In any case, variable bitrate is usually the sort of thing that happens in the encoding step. When you make the video, you set the bitrate. Everyone who views the video is stuck with the bitrate that is set during creation. Variable bit rate allows creators to use more bits for complex parts, and less for simple parts, but its up to the creator. (The analogy would be JPEGs have a quality setting. The person who makes the JPEG can set the quality to whatever, but that's a trade off made by the creator. The viewer can't change that trade off to better meet his/her needs, its already set at that point). [You might be thinking of something along the lines of https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP - but that's not specific to VP9, and alas, we also don't support it :(
Another factor that males me think that the format rather than the bit rate is the problem: the VP9 video played just fine in the Wikipedia App on Android, but not in browsers on Android.
That seems like a leap in logic. Because playing the video in one program worked well, but it didn't in the other, you conclude that the video format is the problem?
More likely the problem is with either the browser implementation of the video tag, or (more likely) the javascript part of TimedMediaHandler is sucky. There's a very realistic chance you were looking at an entirely different video file between the app vs the web (Quite possibly due to TimedMediaHandler making poor choices on which transcode to use)
Brian, regarding your last point: I think I was unclear in my comment about what I meant by format. In I meant that the video format chosen was being handled poorly, rather than that there is an inherent problem with all video in VP9 format. I agree with your last assessment that there is debugging to be done in our (Wikimedia) video playback.
Thanks,
Pine On Nov 2, 2015 2:57 AM, "Brian Wolff" bawolff@gmail.com wrote:
Re Gilles:
If that solves the problem, I think it's an indication that we should transcode videos down to a lower bitrate when the original bitrate is too high, even when the format is playable as-is.
We actually do, but timed media handler has decided the original is a better source to suggest as default :(
Re Pine:
My understanding is that one of the points of going to VP9 is that it's
good at varying its bit rate depending on available throughput. If bitrare really was the problem with the VP9 version, that suggests that VP9 failed at one of the reasons for using it in the first place.
I have never heard that. My understanding is the primary benefit is being optimized for high resolution (HD) video, where there are a lot more pixels, but larger areas of pixels look similar.
In any case, variable bitrate is usually the sort of thing that happens in the encoding step. When you make the video, you set the bitrate. Everyone who views the video is stuck with the bitrate that is set during creation. Variable bit rate allows creators to use more bits for complex parts, and less for simple parts, but its up to the creator. (The analogy would be JPEGs have a quality setting. The person who makes the JPEG can set the quality to whatever, but that's a trade off made by the creator. The viewer can't change that trade off to better meet his/her needs, its already set at that point). [You might be thinking of something along the lines of https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP - but that's not specific to VP9, and alas, we also don't support it :(
Another factor that males me think that the format rather than the bit
rate is the problem: the VP9 video played just fine in the Wikipedia App on Android, but not in browsers on Android.
That seems like a leap in logic. Because playing the video in one program worked well, but it didn't in the other, you conclude that the video format is the problem?
More likely the problem is with either the browser implementation of the video tag, or (more likely) the javascript part of TimedMediaHandler is sucky. There's a very realistic chance you were looking at an entirely different video file between the app vs the web (Quite possibly due to TimedMediaHandler making poor choices on which transcode to use)
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
multimedia@lists.wikimedia.org