I've gone ahead and self-merged a couple small tweaks to TimedMediaHandler's .ogv handling, which can go out with the next release if there's no rush to deploy them earlier:
*Enabled 720p and 1080p .ogv output*, using existing variable bitrate configuration: https://gerrit.wikimedia.org/r/291921
This will enable new generation of high-definition .ogv transcodes for files whose sources are high-definition. The files will be smaller than they would be at constant bitrate, running somewhere from 'about the size of existing webm' to 'up to 40% larger than webm' depending on which configuration the webms were generated against. :)
*Disabled forcing of audio output to max 44.1 kHz* for .ogv output due to bugs in the resampling leading to a/v sync mismatch on long videos: https://gerrit.wikimedia.org/r/289900
Once existing .ogv transcodes are redone, this will fix a/v sync drift on the .ogv versions of longer videos with 48kHz audio, such as https://commons.wikimedia.org/wiki/File:Knowledge_for_Everyone_(no_subtitles...
In the next week I'm going to try to finish up a couple more things:
*Update ogv.js to 1.1.2 release* (just released alpha.7, probalby final):
I've made major improvements to ogv.js on slower machines, with better audio/video sync maintenance and more effective use of multiple CPU cores. This should improve performance on old 32-bit iOS devices as well as older Windows machines running IE.
*Maintenance script to re-run video transcodes in bulk:*
I'm replacing several half-working maintenance scripts in TimedMediaHandler with a new one that actually works. Once I've added a 'throttle' mode I'll commit it, and we can bulk re-run transcodes in production to update things to current configurations.
*Re-tuning .webm and low-res .ogv transcodes for VBR:*
Transcode settings other than the HD .ogvs are currently specifying constant bitrates, which are higher than they need to be for a lot of material in order to provide enough headroom for high-complexity scenes. A cleaner variable bitrate configuration will save space on most material, while using more bits only when needed. (That will free up more space for the HD .ogv transcodes.)
...And then try to finish up more of the video.js front-end with TheDJ and anybody else who's interested. We're so close! And that'll get us video on mobile as well... :D
-- brion
:)
Pine On Jun 21, 2016 09:22, "Brion Vibber" bvibber@wikimedia.org wrote:
I've gone ahead and self-merged a couple small tweaks to TimedMediaHandler's .ogv handling, which can go out with the next release if there's no rush to deploy them earlier:
*Enabled 720p and 1080p .ogv output*, using existing variable bitrate configuration: https://gerrit.wikimedia.org/r/291921
This will enable new generation of high-definition .ogv transcodes for files whose sources are high-definition. The files will be smaller than they would be at constant bitrate, running somewhere from 'about the size of existing webm' to 'up to 40% larger than webm' depending on which configuration the webms were generated against. :)
*Disabled forcing of audio output to max 44.1 kHz* for .ogv output due to bugs in the resampling leading to a/v sync mismatch on long videos: https://gerrit.wikimedia.org/r/289900
Once existing .ogv transcodes are redone, this will fix a/v sync drift on the .ogv versions of longer videos with 48kHz audio, such as https://commons.wikimedia.org/wiki/File:Knowledge_for_Everyone_(no_subtitles...
In the next week I'm going to try to finish up a couple more things:
*Update ogv.js to 1.1.2 release* (just released alpha.7, probalby final):
I've made major improvements to ogv.js on slower machines, with better audio/video sync maintenance and more effective use of multiple CPU cores. This should improve performance on old 32-bit iOS devices as well as older Windows machines running IE.
*Maintenance script to re-run video transcodes in bulk:*
I'm replacing several half-working maintenance scripts in TimedMediaHandler with a new one that actually works. Once I've added a 'throttle' mode I'll commit it, and we can bulk re-run transcodes in production to update things to current configurations.
*Re-tuning .webm and low-res .ogv transcodes for VBR:*
Transcode settings other than the HD .ogvs are currently specifying constant bitrates, which are higher than they need to be for a lot of material in order to provide enough headroom for high-complexity scenes. A cleaner variable bitrate configuration will save space on most material, while using more bits only when needed. (That will free up more space for the HD .ogv transcodes.)
...And then try to finish up more of the video.js front-end with TheDJ and anybody else who's interested. We're so close! And that'll get us video on mobile as well... :D
-- brion
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
multimedia@lists.wikimedia.org