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)

jgerber wrote:

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.

jgerber wrote:

(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.

mdale wrote:

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&section=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&section=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.

Someone uploaded this really nice video at https://commons.wikimedia.org/wiki/File:Snowdonia_by_drone.webm . Transcoding failed:

'/usr/bin/ffmpeg2theora' '/tmp/localcopy_5177375e9e5f-1.webm' -V '160' -F '15' -a '-1' -H '44100' -c '2' --no-upscaling --keyint '128' --buf-delay '256' --width '284' --height '160' --aspect '284:160' -o '/tmp/transcode_160p.ogvc2b8c2cc034d-1.ogv'

Exitcode: 0
Memory: 4194304

[matroska,webm @ 0x21ca4c0] Unknown/unsupported CodecID V_VP9.
[matroska,webm @ 0x21ca4c0] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska,webm, from '/tmp/localcopy_5177375e9e5f-1.webm':
  Duration: 00:01:15.43, start: 0.000000, bitrate: N/A
    Stream #0.0(eng): Video: [0][0][0][0] / 0x0000, 1280x720, PAR 1:1 DAR 16:9, 30 tbr, 1k tbn, 1k tbc (default)
  Pixel Aspect Ratio: 1.00/1   Frame Aspect Ratio: 1.77/1
[swscaler @ 0x2787f00] Unknown format is not supported as input pixel format
  Resize: 1280x720 => 284x160
  Resample Framerate: 30.000 => 15.000
No video or audio stream found.

What's the status of this? Why hasn't this been resolved after 1,5 years?

with ffmpeg2theora 0.29 from debian and an updated ffmpeg the video stream is recognized but I'm getting a segfault:

filippo@filippo-test-trusty:~$ ffmpeg2theora Snowdonia_by_drone.webm -V '160' -F '15' -a '-1' -H '44100' -c '2' --no-upscaling --keyint '128' --buf-delay '256' --width '284' --height '160' --aspect '284:160' -o Snowdonia_by_drone.ogv
Input #0, matroska,webm, from 'Snowdonia_by_drone.webm':
  Metadata:
    encoder         : google
  Duration: 00:01:15.43, start: 0.000000, bitrate: 1241 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1280x720, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
  Pixel Aspect Ratio: 1.00/1   Frame Aspect Ratio: 1.77/1
  Resize: 1280x720 => 284x160
  Resample Framerate: 30.000 => 15.000
[swscaler @ 0x24aaf40] Warning: data is not aligned! This can lead to a speedloss
  0:01:15.59 audio: 0kbps video: 159kbps, time elapsed: 00:00:19            
  0:01:15.43 audio: 0kbps video: 159kbps, time elapsed: 00:00:19           Segmentation fault
filippo@filippo-test-trusty:~$

The same segfault happens on when converting Snowdonia_by_drone.webm in Debian unstable, so this isn't limited to the backport, but an upstream bug

@fgiunchedi Would you mind hitting the ffmpeg command once again with another video like

• or https://commons.wikimedia.org/wiki/File:Snowdonia_by_drone.webm (updated)

So we know it wasn't the specific WebM file which is broken.

@McZusatz looks like only NASA_-_Earth_from_Orbit_2013.webm is able to get fully transcoded, if you'd like to test it yourself as well get a labs instance with trusty and install ffmpeg and ffmpeg2theora (the right versions should be pulled in already)

$ for i in *.webm ; do 
> ffmpeg2theora $i -V '160' -F '15' -a '-1' -H '44100' -c '2' --no-upscaling --keyint '128' --buf-delay '256' --width '284' --height '160' --aspect '284:160' -o ${i/webm/ogv} ; done
Input #0, matroska,webm, from 'NASA_-_Earth_from_Orbit_2013.webm':
  Metadata:
    encoder         : Lavf55.34.100
  Duration: 00:03:48.09, start: 0.000000, bitrate: 1195 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1280x720, SAR 1:1 DAR 16:9, 1k fps, 29.97 tbr, 1k tbn, 1k tbc (default)
    Stream #0:1(eng): Audio: vorbis, 44100 Hz, stereo, fltp (default)
  Pixel Aspect Ratio: 1.00/1   Frame Aspect Ratio: 1.77/1
  Resize: 1280x720 => 284x160
  Resample Framerate: 1000.000 => 15.000
[swscaler @ 0x218d320] Warning: data is not aligned! This can lead to a speedloss
  0:03:48.20 audio: 43kbps video: 147kbps, time elapsed: 00:01:04            
  0:03:48.08 audio: 43kbps video: 147kbps, time elapsed: 00:01:04           
Input #0, matroska,webm, from 'Snowdonia_by_drone.webm':
  Metadata:
    encoder         : google
  Duration: 00:01:15.43, start: 0.000000, bitrate: 2701 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 1920x1080, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 1k tbn, 1k tbc (default)
  Pixel Aspect Ratio: 1.00/1   Frame Aspect Ratio: 1.77/1
  Resize: 1920x1080 => 284x160
  Resample Framerate: 30.000 => 15.000
[swscaler @ 0x122e260] Warning: data is not aligned! This can lead to a speedloss
  0:01:15.59 audio: 0kbps video: 159kbps, time elapsed: 00:00:52            
  0:01:15.43 audio: 0kbps video: 159kbps, time elapsed: 00:00:52           Segmentation fault
Input #0, matroska,webm, from 'VP9test.webm':
  Metadata:
    encoder         : vpxenc v1.2.0-3650-gee1fe2f
  Duration: 00:00:09.92, start: 0.000000, bitrate: 144 kb/s
    Stream #0:0(eng): Video: vp9 (Profile 0), yuv420p(tv), 512x288, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 1k tbn, 1k tbc (default)
    Side data:
      stereo3d: 2D
  Pixel Aspect Ratio: 1.00/1   Frame Aspect Ratio: 1.77/1
  Resize: 512x288 => 284x160
  Resample Framerate: 25.000 => 15.000
[swscaler @ 0x1e674e0] Warning: data is not aligned! This can lead to a speedloss
  0:00:10.00 audio: 0kbps video: 163kbps, time elapsed: 00:00:01            
  0:00:09.92 audio: 0kbps video: 163kbps, time elapsed: 00:00:01           Segmentation fault

When will vp9 most likely be switched on in Wikimedia since this https://gerrit.wikimedia.org/r/#/c/230078/ patch was merged and switched to ffmpeg instead.

Not until it works.

Ok I've got a provisional patch for ffmpeg2theora master, which gets a local build of ffmpeg2theora working in MediaWiki-Vagrant for me. https://bugs.launchpad.net/ffmpeg2theora/+bug/1483861

Change 238781 had a related patch set uploaded (by Brion VIBBER):
Use ffmpeg for video thumbs & transcoding

https://gerrit.wikimedia.org/r/238781

Change 238781 merged by Brion VIBBER:
Use ffmpeg for video thumbs & transcoding

https://gerrit.wikimedia.org/r/238781

Since some patches have been merged how can I find out where a vp9 video is to test.

Doesent timedmediahandler need to enable it since it is disabled by default.

No, nothing needs to be enabled on the MediaWiki/TMH end to *decode* VP9 videos -- it simply needs to be present in the avconv or ffmpeg & ffmpeg2theora builds present on the servers.

Oh ok but to watch videos. you have to set

$wgEnabledTranscodeSet

It shows this error now

for webm

'/usr/bin/avconv' -y -i '/tmp/localcopy_bffa71b3af37-1.webm' -threads 2 -skip_threshold 0 -bufsize 6000k -rc_init_occupancy 4000 -qmin '19' -qmax '19' -vcodec libvpx -f webm -s 1920x1080 -aq '3' -acodec libvorbis /tmp/transcode_1080p.webm7fba8fe6f578-1.webm

Exitcode: 1
Memory: 4194304

avconv version 0.8.17-4:0.8.17-0ubuntu0.12.04.1, Copyright (c) 2000-2014 the Libav developers

built on Mar 16 2015 13:26:50 with gcc 4.6.3

[matroska,webm @ 0x14b07a0] Unknown entry 0x56AA
[matroska,webm @ 0x14b07a0] Unknown entry 0x56BB
[matroska,webm @ 0x14b07a0] Unknown/unsupported CodecID V_VP9.
[matroska,webm @ 0x14b07a0] Unknown/unsupported CodecID A_OPUS.
[matroska,webm @ 0x14b07a0] max_analyze_duration reached
[matroska,webm @ 0x14b07a0] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska,webm, from '/tmp/localcopy_bffa71b3af37-1.webm':

Duration: 00:35:52.91, start: 0.000000, bitrate: N/A
  Stream #0.0: Video: [0][0][0][0] / 0x0000, 1920x1080, PAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
  Stream #0.1: Audio: [0][0][0][0] / 0x0000, 48000 Hz, 2 channels (default)

[buffer @ 0x15c7420] Invalid pixel format string '-1'
Error opening filters!

for ogv

'/usr/bin/ffmpeg2theora' '/tmp/localcopy_4486f3427d33-1.webm' -V '160' -F '15' -a '-1' -H '44100' -c '2' --no-upscaling --optimize --keyint '128' --buf-delay '256' --width '284' --height '160' --aspect '284:160' -o '/tmp/transcode_160p.ogv5856feb00ed2-1.ogv'

Exitcode: 0
Memory: 4194304

[matroska,webm @ 0x19dd4c0] Unknown entry 0x56AA
[matroska,webm @ 0x19dd4c0] Unknown entry 0x56BB
[matroska,webm @ 0x19dd4c0] Unknown/unsupported CodecID V_VP9.
[matroska,webm @ 0x19dd4c0] Unknown/unsupported CodecID A_OPUS.
[matroska,webm @ 0x19dd4c0] max_analyze_duration reached
[matroska,webm @ 0x19dd4c0] Estimating duration from bitrate, this may be inaccurate
Input #0, matroska,webm, from '/tmp/localcopy_4486f3427d33-1.webm':

Duration: 00:35:52.91, start: 0.000000, bitrate: N/A
  Stream #0.0: Video: [0][0][0][0] / 0x0000, 1920x1080, PAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
  Stream #0.1: Audio: [0][0][0][0] / 0x0000, 48000 Hz, 2 channels (default)
Pixel Aspect Ratio: 1.00/1   Frame Aspect Ratio: 1.77/1

[swscaler @ 0x1a25780] Unknown format is not supported as input pixel format

Resize: 1920x1080 => 284x160
Resample Framerate: 29.970 => 15.000

No video or audio stream found.

when trying to convert to different transcodes

please see https://commons.wikimedia.org/wiki/File:Wikimania_2014_-_Technology_VI_-_Views_-_FastCCI.webm

@Paladox where are you testing this?

The production thm servers are not updated, you might test it in beta in an hour or so.

Ok ok I was testing on commons.wikimedia.org.

Ok these should now be working on Commons. @Paladox can you confirm the one you were testing is working now?

@brion seems to be transcoding now. only format not shown is vp9. Should be enabled in timedmediahandler now.

Can 4k be switched on at Wikimedia since vp9 is now supported.