Last modified: 2014-11-14 09:21:05 UTC
Needs to be fixed upstream first and then applied to the server configuration. Test case: https://commons.wikimedia.org/wiki/File:VP9test.webm
Error is just 1. Has the issue with cgroups on the video scalars been fixed yet? Sounds like that issue (in which case not upstream)
(In reply to comment #1) > Error is just 1. Has the issue with cgroups on the video scalars been fixed > yet? Sounds like that issue (in which case not upstream) err, nevermind. I'm not sure why its not giving a proper error message, but I think the cgroup issue has been fixed. Probably some separate bug. The thumbnailing part gives a proper error: Error creating thumbnail: '/usr/bin/avconv' -threads 1 -ss 1 -y -i 'http://ms-fe.pmtpa.wmnet:80/v1/AUTH_43651b15-ed7a-40b6-b745-47666abf8dfe/wikipedia-commons-local-public.e1/e/e1/VP9test.webm?temp_url_sig=d5cfbffc0b57006e00038960b14b14610734d5a7&temp_url_expires=1378747307' -ss 3 -s 512x288 -f mjpeg -an -vframes 1 '/tmp/transform_90574ebe6d7e-1.jpg' 2>&1 wgMaxShellMemory: 409600 avconv version 0.8.6-4:0.8.6-0ubuntu0.12.04.2~wmf1, Copyright (c) 2000-2013 the Libav developers built on Aug 19 2013 10:31:19 with gcc 4.6.3 [matroska,webm @ 0x12a28c0] Unknown/unsupported CodecID V_VP9. [matroska,webm @ 0x12a28c0] max_analyze_duration reached [matroska,webm @ 0x12a28c0] Estimating duration from bitrate, this may be inaccurate Input #0, matroska,webm, from 'http://ms-fe.pmtpa.wmnet:80/v1/AUTH_43651b15-ed7a-40b6-b745-47666abf8dfe/wikipedia-commons-local-public.e1/e/e1/VP9test.webm?temp_url_sig=d5cfbffc0b57006e00038960b14b14610734d5a7&temp_url_expires=1378747307': Duration: 00:00:09.92, start: 0.000000, bitrate: N/A Stream #0.0(eng): Video: [0][0][0][0] / 0x0000, 512x288, PAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 1k tbc (default) [buffer @ 0x12a23e0] Invalid pixel format string '-1' Error opening filters!
Brief note: Firefox supports VP9 Many thanks to Jan Gerber who made vp9 work in Firefox 28! https://bugzilla.mozilla.org/show_bug.cgi?id=833023
(In reply to comment #1) > Error is just 1. Has the issue with cgroups on the video scalars been fixed > yet? Sounds like that issue (in which case not upstream) Issue with error reporting not giving useful information https://gerrit.wikimedia.org/r/#/c/108000/ (In this case, the info would just be "codec not supported", which we already know, but good to fix the issue anyhow) ----------- In order to fix this bug, a newer version of libav (compiled with a new enough version of libvpx) needs to be deployed to the servers (putting this bug in ops territory. Something very similar has to be done for opus). I wonder if I should file an RT ticket (?)
> > In order to fix this bug, a newer version of libav (compiled with a new > enough > version of libvpx) needs to be deployed to the servers What I meant to say was a newer version of ffmpeg2theora, compiled against a version of libav and libvpx that's new enough to support VP9. (googling suggests support landed about a year ago...)
(In reply to comment #5) > > > > In order to fix this bug, a newer version of libav (compiled with a new > > enough > > version of libvpx) needs to be deployed to the servers > > What I meant to say was a newer version of ffmpeg2theora, compiled against a > version of libav and libvpx that's new enough to support VP9. (googling > suggests support landed about a year ago...) Further googling suggests we would need at least libvpx 1.3 (Which is what is in trusty as package libvpx1)
Filed the following as RT #6891: Subject: upgrade libav to version 10 making sure to compile against libvpx > 1.3.0 and libopus so we have VP9 video support Download (untitled) text/html 1.5k VP9 is supposed to be the new big thing in open video formats war. Firefox (alpha versions) and chrome already have support built in, and its rumoured that various mobile phones will have hardware decoding support eventually. Its supposed to be quite a bit better format than current webm with VP8. Given we want to promote free formats, it would be great if we could be an early adopter. First step would be to recompile libav to support the format so people could upload the file (and then we convert to VP8 or theora for people who don't support the format) So basically to do this we need to recompile libav (aka avconv aka the libavcodec-extra package) with the options --enable-libvpx and --enable-libopus. The version of libvpx has to be at least version 1.3.0 for this to work. libav has to be quite new as well, at least 10_alpha1, which I believe is > than any ubuntu package (but is debian experimental). Other then that, I imagine it would be compiled with whatever options were used last time. I don't know what those options were, but I imagine --enable-libtheora --enable-libspeex --enable-libschroedinger would make sense (Although of those three, libspeex might be the only one really needed. The other two won't hurt though) There are already 2 existing files on commons using these formats you can test with: *[[File:VP9test.webm]] (VP9 with vorbis audio. It should be noted many VP9 files will actually have opus audio tracks) *[[File:Sound_of_the_bells_of_Sveta_Nedelya_in_Sofia_2012_PD.ogg]] (Opus audio file)
libav / avconv currently does not create valid Opus in WebM files. FFmpeg works but libav needs to be fixed before it can be used to create WebM VP9/Opus files.
(In reply to Jan Gerber from comment #8) Why would we need to create WebM Opus right now? (I guess this is another bug which addresses that TMH supports transcoding into WebM Opus) Currently it seems ok to be 'read only'. I.e. let the users upload those files and create the thumbnail + the 'old' ogv and WebM transcodes.
(In reply to Marco from comment #9) > (In reply to Jan Gerber from comment #8) > Why would we need to create WebM Opus right now? (I guess this is another > bug which addresses that TMH supports transcoding into WebM Opus) > > Currently it seems ok to be 'read only'. I.e. let the users upload those > files and create the thumbnail + the 'old' ogv and WebM transcodes. For decoding vp9/opus files an updated version of avconv should be ok, just wanted to make sure its never used to created vp9/opus webm files before its fixed and produces valid files.
Do we want to do encoding to vp9 ? There should be a very very small percentage of browsers / devices that only support webm vp8 and not vp9, as vp9 gets more "out there". I would suggest only encoding vp9, and deprecating vp8 over time. On the low end, Ogg will be less CPU intensive to decode in JavaScript so will be a better target for that use case. Hopefully JavaScript decodes will use codecs designed for that. Progress continues on orbx-js, they claim it will be open source and on github 'by summer' https://brendaneich.com/2013/12/orbx-js-and-related-news/
(In reply to Michael Dale from comment #11) > Do we want to do encoding to vp9 ? Probably (if not immediayely, at some point probably not that far away). Well reading is a more immediate concern, if we need to update software, might as well do it to a program that can write the files too.
(In reply to Michael Dale from comment #11) > There should be a very very small percentage of browsers / devices that only > support webm vp8 and not vp9, as vp9 gets more "out there". It seems right now up to 40 % only support vp8 (c.f. bug 61805 ) (In reply to Bawolff (Brian Wolff) from comment #12) I have created a separate bug 61805 nonetheless.
From the RT ticket: "libav has a different ABI. That means that backporting it is not enough; we'd need to rebuild all reverse dependencies that use it as well. In any case, let's wait for the final release, plus a few more weeks for it to stabilize. We can be early adopters, but not _that_ early :) (alphas)." That's from Faidon (WMF Opsen/Debian Developer).
(In reply to Greg Grossmeier from comment #14) I guess you are right. Not even YouTube supports VP9.
Changing severity because now more than 50% of all browsers support VP9 ( http://caniuse.com/#search=webm ) and more than 80 % of all "WebM-devices" can play VP9. Also youtube offers high quality WebM only in vp9. (c.f. https://commons.wikimedia.org/wiki/File:NASA_-_Earth_from_Orbit_2013.webm )
Still it's a request for adding new functionality (support for VP9), hence a feature request.
My reasoning was that people will start to upload VP9 files, which then work fine on the client side but fail on the server side. (Missing thumbs and transcodes) In fact I stopped uploading content from YouTube last year and several (hundred?) highly valuable videos are still waiting in my bookmarks to be transferred. Another batch consisting of videos uploaded by other users are waiting to get their 360p VP8 version replaced by a HD VP9 one. So it seems more like a bug than a feature request to me. Also, what is the current state of the RT? Will it be easier to support VP9 after the switch to Ubuntu 14.04?
(In reply to Marco from comment #18) > Also, what is the current state of the RT? According to http://libav.org/ Libav 10.1 was released on May 10, 2014 (that's more or less all being said in the RT ticket). > Will it be easier to support VP9 after the switch to Ubuntu 14.04? http://packages.ubuntu.com/search?keywords=libav&searchon=names&suite=trusty§ion=all shows that Ubuntu 14.04 still ships libav 9.x so we'd have to do manual work for Wikimedia servers / custom deployment.
(In reply to Andre Klapper from comment #19) > (In reply to Marco from comment #18) > > Also, what is the current state of the RT? > > According to http://libav.org/ Libav 10.1 was released on May 10, 2014 > (that's more or less all being said in the RT ticket). > > > Will it be easier to support VP9 after the switch to Ubuntu 14.04? > > http://packages.ubuntu.com/ > search?keywords=libav&searchon=names&suite=trusty§ion=all shows that > Ubuntu 14.04 still ships libav 9.x so we'd have to do manual work for > Wikimedia servers / custom deployment. We may be able to use gstreamer. I think (havent checked) that the version in 14.04 supports VP9. It would be really nice if the video scalers got updated....
For reference, the number of VP9 files on commons is growing. There are currently 37 such files on commons (+15 old versions of files and 5 deleted files), which is quite a lot considering they don't work at all. In particular, youtube has started encoding some files that way, so its likely we will see a lot more via transfers from youtube.
I think the priority of this ticket should be increased. One additional argument: this would allow to make smaller ZIM files for offline usage.
(In reply to Bawolff (Brian Wolff) from comment #21) > In > particular, youtube has started encoding some files that way, so its likely > we will see a lot more via transfers from youtube. For a start, this makes this a bug, not a feature request: because we accept files we can't deal with (and users reasonably expect them to work).
(In reply to Bawolff (Brian Wolff) from comment #21) > ... so its likely > we will see a lot more via transfers from youtube. Actually, I stopped transferring videos from youtube due to the missing support in TMH and youtube2mediawiki. Nonetheless, I am considering to upload a whole bunch of CC videos from youtube as well as replacing previously uploaded small resolution webms from youtube by higher quality VP9 ones as soon as either TMH or youtube2mediawiki supports VP9. https://github.com/bit/youtube2mediawiki/issues/22
(In reply to Bawolff (Brian Wolff) from comment #21) > For reference, the number of VP9 files on commons is growing. There are > currently 37 such files on commons (+15 old versions of files and 5 deleted ... Add me to the list of users pointing out that we are actually skipping VP9 uploads and either not bothering or uploading inferior videos. At the moment I'm transcoding a YouTube mp4 file to VP8 even though the VP9 version is available to download, entire due to it seeming a bit pointless to upload a VP9 which will not display on-wiki (meaning most potential reusers will not even look at it). Unfortunately this example of a 21 minutes long Gay Pride video taken in Stockholm will keep my laptop busy for about 10 hours, which is a massive incentive to give up on video uploads.
Might I suggest making a custom 'libav10' package which installs libav 10.5 with a '10' suffix on the executables ('avconv10' etc)? Assuming the libraries are properly versioned this should let us install it side-by-side with the distro packages without breaking random other packages that might depend on version 9.
Or if the libs are too expansive, just a custom install in /opt/libav10 :P
Building libav 10.5 on 12.04 seems pretty easy; it includes a vp9 decoder but relies on libvpx for vp8/vp9 output and the 12.04 libvpx only does vp8. That should be enough for importing vp9 videos and locally producing vp8 transcodes though, with full vp9 output support waiting on future upgrades. It looks like the default libav build links in its own libraries statically, so they shouldn't interfere with other stuff that links to the system libav. I'll try and wrap it into a .deb package later if nobody beats me to it.
Oh question -- are the YouTube VP9 videos using Vorbis or Opus for audio tracks? There's no libopus on 12.04 so we'd have to build that too.
(In reply to Brion Vibber from comment #29) > Oh question -- are the YouTube VP9 videos using Vorbis or Opus for audio > tracks? There's no libopus on 12.04 so we'd have to build that too. Even if they arent (Fae's example didnt, but i dont know if that's the norm), could we please have opus too? there are more than a couple videos which are vp8+opus which are currently broken.
afaic youtube does not yet offer opus audio streams and wants you to use the vorbis audio stream which comes separately from the VP9 video stream. Though, it obviously doesn't hurt to have opus support as well. :)
I just ran some stats: *377 ogg videos with opus audio tracks *94 webm videos with opus audio *1 ogg audio opus file (Possibly lack of opus audio is due to ogg/opus audio usually having extension .opus, which we don't allow) I would consider opus support (bug 51313) more critical than VP9 (both are important though)
opus seems to backport cleanly from trusty per instructions at <https://wikitech.wikimedia.org/wiki/Backport_packages>; here's a source package made that way: https://github.com/brion/operations-debs-opus Once that's built and installed, making a mostly-statically-linked 'avconv10' that includes opus & vpx seems easy: PREFIX=/usr sudo apt-get build-dep libav || exit 1 wget -c https://libav.org/releases/libav-10.5.tar.gz && tar zxvf libav-10.5.tar.gz || exit 1 (cd libav-10.5 && ./configure --prefix=/opt/libav10 --disable-avplay --disable-avprobe --disable-avserver --enable-runtime-cpudetect --enable-libopus --enable-libvorbis --enable-libvpx && make -j4) || exit 1 sudo cp libav-10.5/avconv $PREFIX/bin/avconv10 ffmpeg2theora would similarly need to be rebuilt to support vp9 input; it seems easier to build it against a statically-linked ffmpeg than to hook it up to libav when building manually. However I'm a bit uncertain how to package either of these. I don't really want to backport the full avconv package because it adds dependencies and cruft that we don't care about. But that might be easier than manually poking deb package stuff, which hurts my brain. Thoughts?
(Note that libvpx doesn't need to be updated for this case because avconv/ffmpeg includes its own vp9 decoder. It'll only need a newer libvpx to encode VP9 output.)
Ok this seems to work, builds with debuild: https://github.com/brion/operations-debs-avconv10 Package installs just the 'avconv' executable as 'avconv10', statically linked to the libav libraries. Requires the opus backport.
