In the past, we've had a mixture of fixed bitrates and quality-based settings for producing video transcodes.
Each has its advantages: fixed bitrates are more predictable for watching while streaming, while fixed quality settings allow for reducing the bitrate on low-complexity scenes to save bandwidth (and increasing it on high-complexity scenes to keep quality up!)
Since "download and watch it later" is less of a thing on today's internet than "stream it right now!", I'd been leaning for a while towards moving more things to fixed bitrates. However, I'm starting to come down on the side of a fixed quality setting with a variable bitrate...
Overall variable rate encoding should lead to lower bandwidth usage for most parts of most files, while still maintaining high quality on scenes that need it.
The downside is that a high-complexity scene encoded at a higher bitrate might cause buffering to run out during playback that had been working ok on earlier scenes at a lower bitrate.
Once we support adaptive streaming (using MPEG-DASH, or something like it) the system should be able to provide a detailed enough manifest[1] to show which segments of the file are low-bandwidth and which are high-bandwidth, so if there's a bandwidth limitation that stops us from viewing one particular segment at the current resolution, we can bump down and then bump resolution back up again when the bandwidth usage goes down.
If there's no strong objection, I'm going to tinker with the quality settings for WebM and Ogg Theora video transcodes to try to find quality settings I'm happy with that result in reasonable bandwidth averages.
[1] An MPEG-DASH manifest (.mpd) specifies a target bitrate on each resolution representation, but the actual segments can be different sizes. When they're specified as byte ranges of a source file, the exact segment size is conveniently available!
-- brion
Hi Brion,
In addition to automated bitrate adjustments, can there be a way for users to manually adjust their bitrates or quality settings on the fly without changing resolutions or file formats?
Not meaning to be ungrateful, but I think that improving HD video playback in IE and Safari should take precedence as a priority. I tried watching one of Victor's HD WEBM fundraising videos on a 4K display in Safari, and my user experience went from amazing to awful as soon as playback started in low-def OGV.
Thanks,
Pine On May 24, 2016 09:44, "Brion Vibber" bvibber@wikimedia.org wrote:
In the past, we've had a mixture of fixed bitrates and quality-based settings for producing video transcodes.
Each has its advantages: fixed bitrates are more predictable for watching while streaming, while fixed quality settings allow for reducing the bitrate on low-complexity scenes to save bandwidth (and increasing it on high-complexity scenes to keep quality up!)
Since "download and watch it later" is less of a thing on today's internet than "stream it right now!", I'd been leaning for a while towards moving more things to fixed bitrates. However, I'm starting to come down on the side of a fixed quality setting with a variable bitrate...
Overall variable rate encoding should lead to lower bandwidth usage for most parts of most files, while still maintaining high quality on scenes that need it.
The downside is that a high-complexity scene encoded at a higher bitrate might cause buffering to run out during playback that had been working ok on earlier scenes at a lower bitrate.
Once we support adaptive streaming (using MPEG-DASH, or something like it) the system should be able to provide a detailed enough manifest[1] to show which segments of the file are low-bandwidth and which are high-bandwidth, so if there's a bandwidth limitation that stops us from viewing one particular segment at the current resolution, we can bump down and then bump resolution back up again when the bandwidth usage goes down.
If there's no strong objection, I'm going to tinker with the quality settings for WebM and Ogg Theora video transcodes to try to find quality settings I'm happy with that result in reasonable bandwidth averages.
[1] An MPEG-DASH manifest (.mpd) specifies a target bitrate on each resolution representation, but the actual segments can be different sizes. When they're specified as byte ranges of a source file, the exact segment size is conveniently available!
-- brion
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On Tue, May 24, 2016 at 10:21 AM, Pine W wiki.pine@gmail.com wrote:
In addition to automated bitrate adjustments, can there be a way for users to manually adjust their bitrates or quality settings on the fly without changing resolutions or file formats?
Probably not; if I understand you correctly you would like to be able, as an end-user watching a video, to switch from "480p Ogg Theora at 2 Mbps" to "480p Ogg Theora at 3 Mbps" etc? That would require pre-generating, and storing, some arbitrarily large number of copies of the file at different bitrates/quality settings for very little expected benefit.
It makes a lot more sense to me to encode at a bitrate/quality setting that results in reasonable quality for each resolution; then if you need to change bitrates due to network limitations, you bump up or down a notch on the resolution list. This also avoids extra blocky artifacts from having a too-low-bitrate at a high resolution, etc.
Not meaning to be ungrateful, but I think that improving HD video playback in IE and Safari should take precedence as a priority. I tried watching one of Victor's HD WEBM fundraising videos on a 4K display in Safari, and my user experience went from amazing to awful as soon as playback started in low-def OGV.
There are several questions kind of stuck together there, let me tease them apart and answer them each:
* The source file's format is not related to resolution or quality of the source -- we have beautiful 1080p HD videos with high bitrate OGV sources, and 240p quarter-SD videos with crappy, artifact-laden low-bitrate WebM VP9 sources.
* Visual quality is not determined by format alone, but by a combination of format, bitrate, quality settings, and the particular input data. When rendered at the same resolution at *appropriate* bitrates/quality settings, WebM and OGV will look about the same... OGV will tend to degrade a bit more in high-motion scenes, but if the base quality is good that's usually a modest effect.
* WebM is not currently used for the ogv.js fallback player in Safari/IE/Edge because it's several times slower to decode than OGV at the same resolution, and still a lot buggier (though you'll be happy to hear I've fixed several major bugs recently!) If we switched to using WebM for ogv.js, you *would not* get HD because it's too slow to decode HD WebM in ogv.js.
* OGV transcodes are currently only made up to 480p (standard def); we do not currently produce 720p or 1080p high-def transcodes in OGV. This means in Safari you won't get high-def playback even if your computer could handle it (and if it's a current-ish Mac or a recent model iPad, it can probably handle OGV at 720p or 1080p at a modest 24fps or 30fps).
* Bitrate & quality settings -- many of our OGV transcodes at 480p and 360p are still older versions from when a too-low bitrate was used, leading to *very* poor appearance. You can determine this by going to the File: page on Commons and checking the transcode list at the bottom; if it says something around 1 Mbits for 480p or 500 kbits for 360p, it's an old file and not representative of current settings. It should say around 2 Mbits for 480p, 1 Mbit for 360p, 500 kbits for 240p.
* Sometimes the automatic resolution downgrade for slow computers in the ogv.js/TimedMediaHandler integration picks a super-low 160p resolution version when it should not have, which looks pretty bad.
So -- what am I doing to improve it, you ask? :)
Here's what: the general disk space / bandwidth savings from using variable bitrate encodings make it less scary-sounding to enable 720p (and _maybe_ 1080p) HD OGV transcodes, which will enable high-def playback in Safari and Edge. (And maybe IE 11 on a fast machine, but IE is less than half the speed of Edge or Safari at decoding.) These will still be bigger than the WebM versions because Theora needs a higher data rate than VP8 to maintain quality, but the WebMs and the other OGVs will be smaller than they used to be at fixed bitrates, so it's less of a burden.
I know you really want HD WebM in Safari, but that's not possible until *huge* performance gains can be realized in the decoder... or Apple gives in and adds WebM support to their operating system. Don't hold your breath on waiting for Apple; their ways are mysterious.
Don't hold your breath on huge performance gains either; I'm investigating avenues for improvement (see https://brionv.com/log/2016/05/19/peeking-into-vp8-video-decoding-performanc... & https://brionv.com/log/2016/05/20/vp8-parallelization-continued/ for details) but overlapping macroblocks on CPU threads will probably give less than a 50% improvement, and I have literally no idea what kind of performance to expect from pushing more work to the GPU (and it sounds like a LOT of work, could take months/years of poking at it).
-- brion
Hi Brion,
I think that 1080p HD OGV transcodes would be a big improvement for both Safari and Edge. I'd love to see that happen, preferably before 2Q 2016-2017.
Pine On May 24, 2016 11:09, "Brion Vibber" bvibber@wikimedia.org wrote:
On Tue, May 24, 2016 at 10:21 AM, Pine W wiki.pine@gmail.com wrote:
In addition to automated bitrate adjustments, can there be a way for users to manually adjust their bitrates or quality settings on the fly without changing resolutions or file formats?
Probably not; if I understand you correctly you would like to be able, as an end-user watching a video, to switch from "480p Ogg Theora at 2 Mbps" to "480p Ogg Theora at 3 Mbps" etc? That would require pre-generating, and storing, some arbitrarily large number of copies of the file at different bitrates/quality settings for very little expected benefit.
It makes a lot more sense to me to encode at a bitrate/quality setting that results in reasonable quality for each resolution; then if you need to change bitrates due to network limitations, you bump up or down a notch on the resolution list. This also avoids extra blocky artifacts from having a too-low-bitrate at a high resolution, etc.
Not meaning to be ungrateful, but I think that improving HD video playback in IE and Safari should take precedence as a priority. I tried watching one of Victor's HD WEBM fundraising videos on a 4K display in Safari, and my user experience went from amazing to awful as soon as playback started in low-def OGV.
There are several questions kind of stuck together there, let me tease them apart and answer them each:
- The source file's format is not related to resolution or quality of the
source -- we have beautiful 1080p HD videos with high bitrate OGV sources, and 240p quarter-SD videos with crappy, artifact-laden low-bitrate WebM VP9 sources.
- Visual quality is not determined by format alone, but by a combination
of format, bitrate, quality settings, and the particular input data. When rendered at the same resolution at *appropriate* bitrates/quality settings, WebM and OGV will look about the same... OGV will tend to degrade a bit more in high-motion scenes, but if the base quality is good that's usually a modest effect.
- WebM is not currently used for the ogv.js fallback player in
Safari/IE/Edge because it's several times slower to decode than OGV at the same resolution, and still a lot buggier (though you'll be happy to hear I've fixed several major bugs recently!) If we switched to using WebM for ogv.js, you *would not* get HD because it's too slow to decode HD WebM in ogv.js.
- OGV transcodes are currently only made up to 480p (standard def); we do
not currently produce 720p or 1080p high-def transcodes in OGV. This means in Safari you won't get high-def playback even if your computer could handle it (and if it's a current-ish Mac or a recent model iPad, it can probably handle OGV at 720p or 1080p at a modest 24fps or 30fps).
- Bitrate & quality settings -- many of our OGV transcodes at 480p and
360p are still older versions from when a too-low bitrate was used, leading to *very* poor appearance. You can determine this by going to the File: page on Commons and checking the transcode list at the bottom; if it says something around 1 Mbits for 480p or 500 kbits for 360p, it's an old file and not representative of current settings. It should say around 2 Mbits for 480p, 1 Mbit for 360p, 500 kbits for 240p.
- Sometimes the automatic resolution downgrade for slow computers in the
ogv.js/TimedMediaHandler integration picks a super-low 160p resolution version when it should not have, which looks pretty bad.
So -- what am I doing to improve it, you ask? :)
Here's what: the general disk space / bandwidth savings from using variable bitrate encodings make it less scary-sounding to enable 720p (and _maybe_ 1080p) HD OGV transcodes, which will enable high-def playback in Safari and Edge. (And maybe IE 11 on a fast machine, but IE is less than half the speed of Edge or Safari at decoding.) These will still be bigger than the WebM versions because Theora needs a higher data rate than VP8 to maintain quality, but the WebMs and the other OGVs will be smaller than they used to be at fixed bitrates, so it's less of a burden.
I know you really want HD WebM in Safari, but that's not possible until *huge* performance gains can be realized in the decoder... or Apple gives in and adds WebM support to their operating system. Don't hold your breath on waiting for Apple; their ways are mysterious.
Don't hold your breath on huge performance gains either; I'm investigating avenues for improvement (see https://brionv.com/log/2016/05/19/peeking-into-vp8-video-decoding-performanc... & https://brionv.com/log/2016/05/20/vp8-parallelization-continued/ for details) but overlapping macroblocks on CPU threads will probably give less than a 50% improvement, and I have literally no idea what kind of performance to expect from pushing more work to the GPU (and it sounds like a LOT of work, could take months/years of poking at it).
-- brion
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On Fri, May 27, 2016 at 12:06 PM, Pine W wiki.pine@gmail.com wrote:
Hi Brion,
I think that 1080p HD OGV transcodes would be a big improvement for both Safari and Edge. I'd love to see that happen, preferably before 2Q 2016-2017.
You'll enjoy these samples of some VBR-encoded files over the full resolution range:
* https://brionv.com/misc/ogv.js/demo/#file=RED_4K_Video_of_Colorful_Liquid_in... * https://brionv.com/misc/ogv.js/demo/#file=Tears_of_Steel_in_4k_-_Official_Bl... * https://brionv.com/misc/ogv.js/demo/#file=Art_and_Feminism_Wikipedia_Edit-a-...
(Click into 'search media' for more -- stay in the "VBR transcode tests" mode in the media selector panel or you'll go back to the existing Commons transcodes.) Crank it back down to 720p or below in the resolution selector if 1080p is too slow. You can actually crank some of these up to 1440p or even 2160p, though they get rather slow and large. ;) 1440p is the limit I can run smoothly on my MacBook Pro in Safari.
720p and 1080p OGVs look pretty decent and aren't as huge overall using VBR, though the bitrates can skew upwards in high-complexity scenes which will benefit from adaptive switching later on... If there are no big surprises I'll go ahead and enable 720p and 1080p Ogg transcodes live some time in the next couple weeks.
I'm also putting together an updated maintenance script to re-run transcodes in bulk, as the current ones are pretty ..... very broken and don't actually work.
Some preliminary notes on things that need work for adaptive streaming with OGV: https://brionv.com/log/2016/05/26/thoughts-on-ogg-adaptive-streaming/
-- brion
Pine On May 24, 2016 11:09, "Brion Vibber" bvibber@wikimedia.org wrote:
On Tue, May 24, 2016 at 10:21 AM, Pine W wiki.pine@gmail.com wrote:
In addition to automated bitrate adjustments, can there be a way for users to manually adjust their bitrates or quality settings on the fly without changing resolutions or file formats?
Probably not; if I understand you correctly you would like to be able, as an end-user watching a video, to switch from "480p Ogg Theora at 2 Mbps" to "480p Ogg Theora at 3 Mbps" etc? That would require pre-generating, and storing, some arbitrarily large number of copies of the file at different bitrates/quality settings for very little expected benefit.
It makes a lot more sense to me to encode at a bitrate/quality setting that results in reasonable quality for each resolution; then if you need to change bitrates due to network limitations, you bump up or down a notch on the resolution list. This also avoids extra blocky artifacts from having a too-low-bitrate at a high resolution, etc.
Not meaning to be ungrateful, but I think that improving HD video playback in IE and Safari should take precedence as a priority. I tried watching one of Victor's HD WEBM fundraising videos on a 4K display in Safari, and my user experience went from amazing to awful as soon as playback started in low-def OGV.
There are several questions kind of stuck together there, let me tease them apart and answer them each:
- The source file's format is not related to resolution or quality of the
source -- we have beautiful 1080p HD videos with high bitrate OGV sources, and 240p quarter-SD videos with crappy, artifact-laden low-bitrate WebM VP9 sources.
- Visual quality is not determined by format alone, but by a combination
of format, bitrate, quality settings, and the particular input data. When rendered at the same resolution at *appropriate* bitrates/quality settings, WebM and OGV will look about the same... OGV will tend to degrade a bit more in high-motion scenes, but if the base quality is good that's usually a modest effect.
- WebM is not currently used for the ogv.js fallback player in
Safari/IE/Edge because it's several times slower to decode than OGV at the same resolution, and still a lot buggier (though you'll be happy to hear I've fixed several major bugs recently!) If we switched to using WebM for ogv.js, you *would not* get HD because it's too slow to decode HD WebM in ogv.js.
- OGV transcodes are currently only made up to 480p (standard def); we do
not currently produce 720p or 1080p high-def transcodes in OGV. This means in Safari you won't get high-def playback even if your computer could handle it (and if it's a current-ish Mac or a recent model iPad, it can probably handle OGV at 720p or 1080p at a modest 24fps or 30fps).
- Bitrate & quality settings -- many of our OGV transcodes at 480p and
360p are still older versions from when a too-low bitrate was used, leading to *very* poor appearance. You can determine this by going to the File: page on Commons and checking the transcode list at the bottom; if it says something around 1 Mbits for 480p or 500 kbits for 360p, it's an old file and not representative of current settings. It should say around 2 Mbits for 480p, 1 Mbit for 360p, 500 kbits for 240p.
- Sometimes the automatic resolution downgrade for slow computers in the
ogv.js/TimedMediaHandler integration picks a super-low 160p resolution version when it should not have, which looks pretty bad.
So -- what am I doing to improve it, you ask? :)
Here's what: the general disk space / bandwidth savings from using variable bitrate encodings make it less scary-sounding to enable 720p (and _maybe_ 1080p) HD OGV transcodes, which will enable high-def playback in Safari and Edge. (And maybe IE 11 on a fast machine, but IE is less than half the speed of Edge or Safari at decoding.) These will still be bigger than the WebM versions because Theora needs a higher data rate than VP8 to maintain quality, but the WebMs and the other OGVs will be smaller than they used to be at fixed bitrates, so it's less of a burden.
I know you really want HD WebM in Safari, but that's not possible until *huge* performance gains can be realized in the decoder... or Apple gives in and adds WebM support to their operating system. Don't hold your breath on waiting for Apple; their ways are mysterious.
Don't hold your breath on huge performance gains either; I'm investigating avenues for improvement (see https://brionv.com/log/2016/05/19/peeking-into-vp8-video-decoding-performanc... & https://brionv.com/log/2016/05/20/vp8-parallelization-continued/ for details) but overlapping macroblocks on CPU threads will probably give less than a 50% improvement, and I have literally no idea what kind of performance to expect from pushing more work to the GPU (and it sounds like a LOT of work, could take months/years of poking at it).
-- brion
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
Thanks for working on this!
4K in WebM and OGV would be highly desirable in some scerarios, such as playing videos on large displays or with projectors at Wikimania or in large classrooms. My personal sense of priorities is that 1080p for Edge and Safari should come first, and after that should come 4K for the most widely used browsers.
If it's possible to improve the maximum display sizes of OGV files from 480p to 4K in one step in a way that is compatible with many browsers, that is icing on the cake.
Pine On May 29, 2016 01:16, "Brion Vibber" bvibber@wikimedia.org wrote:
On Fri, May 27, 2016 at 12:06 PM, Pine W wiki.pine@gmail.com wrote:
Hi Brion,
I think that 1080p HD OGV transcodes would be a big improvement for both Safari and Edge. I'd love to see that happen, preferably before 2Q 2016-2017.
You'll enjoy these samples of some VBR-encoded files over the full resolution range:
https://brionv.com/misc/ogv.js/demo/#file=RED_4K_Video_of_Colorful_Liquid_in...
https://brionv.com/misc/ogv.js/demo/#file=Tears_of_Steel_in_4k_-_Official_Bl...
https://brionv.com/misc/ogv.js/demo/#file=Art_and_Feminism_Wikipedia_Edit-a-...
(Click into 'search media' for more -- stay in the "VBR transcode tests" mode in the media selector panel or you'll go back to the existing Commons transcodes.) Crank it back down to 720p or below in the resolution selector if 1080p is too slow. You can actually crank some of these up to 1440p or even 2160p, though they get rather slow and large. ;) 1440p is the limit I can run smoothly on my MacBook Pro in Safari.
720p and 1080p OGVs look pretty decent and aren't as huge overall using VBR, though the bitrates can skew upwards in high-complexity scenes which will benefit from adaptive switching later on... If there are no big surprises I'll go ahead and enable 720p and 1080p Ogg transcodes live some time in the next couple weeks.
I'm also putting together an updated maintenance script to re-run transcodes in bulk, as the current ones are pretty ..... very broken and don't actually work.
Some preliminary notes on things that need work for adaptive streaming with OGV: https://brionv.com/log/2016/05/26/thoughts-on-ogg-adaptive-streaming/
-- brion
Pine On May 24, 2016 11:09, "Brion Vibber" bvibber@wikimedia.org wrote:
On Tue, May 24, 2016 at 10:21 AM, Pine W wiki.pine@gmail.com wrote:
In addition to automated bitrate adjustments, can there be a way for users to manually adjust their bitrates or quality settings on the fly without changing resolutions or file formats?
Probably not; if I understand you correctly you would like to be able, as an end-user watching a video, to switch from "480p Ogg Theora at 2 Mbps" to "480p Ogg Theora at 3 Mbps" etc? That would require pre-generating, and storing, some arbitrarily large number of copies of the file at different bitrates/quality settings for very little expected benefit.
It makes a lot more sense to me to encode at a bitrate/quality setting that results in reasonable quality for each resolution; then if you need to change bitrates due to network limitations, you bump up or down a notch on the resolution list. This also avoids extra blocky artifacts from having a too-low-bitrate at a high resolution, etc.
Not meaning to be ungrateful, but I think that improving HD video playback in IE and Safari should take precedence as a priority. I tried watching one of Victor's HD WEBM fundraising videos on a 4K display in Safari, and my user experience went from amazing to awful as soon as playback started in low-def OGV.
There are several questions kind of stuck together there, let me tease them apart and answer them each:
- The source file's format is not related to resolution or quality of
the source -- we have beautiful 1080p HD videos with high bitrate OGV sources, and 240p quarter-SD videos with crappy, artifact-laden low-bitrate WebM VP9 sources.
- Visual quality is not determined by format alone, but by a combination
of format, bitrate, quality settings, and the particular input data. When rendered at the same resolution at *appropriate* bitrates/quality settings, WebM and OGV will look about the same... OGV will tend to degrade a bit more in high-motion scenes, but if the base quality is good that's usually a modest effect.
- WebM is not currently used for the ogv.js fallback player in
Safari/IE/Edge because it's several times slower to decode than OGV at the same resolution, and still a lot buggier (though you'll be happy to hear I've fixed several major bugs recently!) If we switched to using WebM for ogv.js, you *would not* get HD because it's too slow to decode HD WebM in ogv.js.
- OGV transcodes are currently only made up to 480p (standard def); we
do not currently produce 720p or 1080p high-def transcodes in OGV. This means in Safari you won't get high-def playback even if your computer could handle it (and if it's a current-ish Mac or a recent model iPad, it can probably handle OGV at 720p or 1080p at a modest 24fps or 30fps).
- Bitrate & quality settings -- many of our OGV transcodes at 480p and
360p are still older versions from when a too-low bitrate was used, leading to *very* poor appearance. You can determine this by going to the File: page on Commons and checking the transcode list at the bottom; if it says something around 1 Mbits for 480p or 500 kbits for 360p, it's an old file and not representative of current settings. It should say around 2 Mbits for 480p, 1 Mbit for 360p, 500 kbits for 240p.
- Sometimes the automatic resolution downgrade for slow computers in the
ogv.js/TimedMediaHandler integration picks a super-low 160p resolution version when it should not have, which looks pretty bad.
So -- what am I doing to improve it, you ask? :)
Here's what: the general disk space / bandwidth savings from using variable bitrate encodings make it less scary-sounding to enable 720p (and _maybe_ 1080p) HD OGV transcodes, which will enable high-def playback in Safari and Edge. (And maybe IE 11 on a fast machine, but IE is less than half the speed of Edge or Safari at decoding.) These will still be bigger than the WebM versions because Theora needs a higher data rate than VP8 to maintain quality, but the WebMs and the other OGVs will be smaller than they used to be at fixed bitrates, so it's less of a burden.
I know you really want HD WebM in Safari, but that's not possible until *huge* performance gains can be realized in the decoder... or Apple gives in and adds WebM support to their operating system. Don't hold your breath on waiting for Apple; their ways are mysterious.
Don't hold your breath on huge performance gains either; I'm investigating avenues for improvement (see https://brionv.com/log/2016/05/19/peeking-into-vp8-video-decoding-performanc... & https://brionv.com/log/2016/05/20/vp8-parallelization-continued/ for details) but overlapping macroblocks on CPU threads will probably give less than a 50% improvement, and I have literally no idea what kind of performance to expect from pushing more work to the GPU (and it sounds like a LOT of work, could take months/years of poking at it).
-- brion
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 Sunday, May 29, 2016, Pine W wiki.pine@gmail.com wrote:
Thanks for working on this!
4K in WebM and OGV would be highly desirable in some scerarios, such as playing videos on large displays or with projectors at Wikimania or in large classrooms. My personal sense of priorities is that 1080p for Edge and Safari should come first, and after that should come 4K for the most widely used browsers.
If it's possible to improve the maximum display sizes of OGV files from 480p to 4K in one step in a way that is compatible with many browsers, that is icing on the cake.
I can add 720p, 1080p, and 1440p OGV in the short term. Won't bother producing the 2160p size in OGV probably as I can't get smooth playback at that resolution and there's no sense eating the disk space.
Since we have fairly few 2160p source files, I'll probably just bump up the WebM transcodes to 2160p as well for now.
-- brion
Pine On May 29, 2016 01:16, "Brion Vibber" <bvibber@wikimedia.org javascript:_e(%7B%7D,'cvml','bvibber@wikimedia.org');> wrote:
On Fri, May 27, 2016 at 12:06 PM, Pine W <wiki.pine@gmail.com javascript:_e(%7B%7D,'cvml','wiki.pine@gmail.com');> wrote:
Hi Brion,
I think that 1080p HD OGV transcodes would be a big improvement for both Safari and Edge. I'd love to see that happen, preferably before 2Q 2016-2017.
You'll enjoy these samples of some VBR-encoded files over the full resolution range:
https://brionv.com/misc/ogv.js/demo/#file=RED_4K_Video_of_Colorful_Liquid_in...
https://brionv.com/misc/ogv.js/demo/#file=Tears_of_Steel_in_4k_-_Official_Bl...
https://brionv.com/misc/ogv.js/demo/#file=Art_and_Feminism_Wikipedia_Edit-a-...
(Click into 'search media' for more -- stay in the "VBR transcode tests" mode in the media selector panel or you'll go back to the existing Commons transcodes.) Crank it back down to 720p or below in the resolution selector if 1080p is too slow. You can actually crank some of these up to 1440p or even 2160p, though they get rather slow and large. ;) 1440p is the limit I can run smoothly on my MacBook Pro in Safari.
720p and 1080p OGVs look pretty decent and aren't as huge overall using VBR, though the bitrates can skew upwards in high-complexity scenes which will benefit from adaptive switching later on... If there are no big surprises I'll go ahead and enable 720p and 1080p Ogg transcodes live some time in the next couple weeks.
I'm also putting together an updated maintenance script to re-run transcodes in bulk, as the current ones are pretty ..... very broken and don't actually work.
Some preliminary notes on things that need work for adaptive streaming with OGV: https://brionv.com/log/2016/05/26/thoughts-on-ogg-adaptive-streaming/
-- brion
Pine On May 24, 2016 11:09, "Brion Vibber" <bvibber@wikimedia.org javascript:_e(%7B%7D,'cvml','bvibber@wikimedia.org');> wrote:
On Tue, May 24, 2016 at 10:21 AM, Pine W <wiki.pine@gmail.com javascript:_e(%7B%7D,'cvml','wiki.pine@gmail.com');> wrote:
In addition to automated bitrate adjustments, can there be a way for users to manually adjust their bitrates or quality settings on the fly without changing resolutions or file formats?
Probably not; if I understand you correctly you would like to be able, as an end-user watching a video, to switch from "480p Ogg Theora at 2 Mbps" to "480p Ogg Theora at 3 Mbps" etc? That would require pre-generating, and storing, some arbitrarily large number of copies of the file at different bitrates/quality settings for very little expected benefit.
It makes a lot more sense to me to encode at a bitrate/quality setting that results in reasonable quality for each resolution; then if you need to change bitrates due to network limitations, you bump up or down a notch on the resolution list. This also avoids extra blocky artifacts from having a too-low-bitrate at a high resolution, etc.
Not meaning to be ungrateful, but I think that improving HD video playback in IE and Safari should take precedence as a priority. I tried watching one of Victor's HD WEBM fundraising videos on a 4K display in Safari, and my user experience went from amazing to awful as soon as playback started in low-def OGV.
There are several questions kind of stuck together there, let me tease them apart and answer them each:
- The source file's format is not related to resolution or quality of
the source -- we have beautiful 1080p HD videos with high bitrate OGV sources, and 240p quarter-SD videos with crappy, artifact-laden low-bitrate WebM VP9 sources.
- Visual quality is not determined by format alone, but by a
combination of format, bitrate, quality settings, and the particular input data. When rendered at the same resolution at *appropriate* bitrates/quality settings, WebM and OGV will look about the same... OGV will tend to degrade a bit more in high-motion scenes, but if the base quality is good that's usually a modest effect.
- WebM is not currently used for the ogv.js fallback player in
Safari/IE/Edge because it's several times slower to decode than OGV at the same resolution, and still a lot buggier (though you'll be happy to hear I've fixed several major bugs recently!) If we switched to using WebM for ogv.js, you *would not* get HD because it's too slow to decode HD WebM in ogv.js.
- OGV transcodes are currently only made up to 480p (standard def); we
do not currently produce 720p or 1080p high-def transcodes in OGV. This means in Safari you won't get high-def playback even if your computer could handle it (and if it's a current-ish Mac or a recent model iPad, it can probably handle OGV at 720p or 1080p at a modest 24fps or 30fps).
- Bitrate & quality settings -- many of our OGV transcodes at 480p and
360p are still older versions from when a too-low bitrate was used, leading to *very* poor appearance. You can determine this by going to the File: page on Commons and checking the transcode list at the bottom; if it says something around 1 Mbits for 480p or 500 kbits for 360p, it's an old file and not representative of current settings. It should say around 2 Mbits for 480p, 1 Mbit for 360p, 500 kbits for 240p.
- Sometimes the automatic resolution downgrade for slow computers in
the ogv.js/TimedMediaHandler integration picks a super-low 160p resolution version when it should not have, which looks pretty bad.
So -- what am I doing to improve it, you ask? :)
Here's what: the general disk space / bandwidth savings from using variable bitrate encodings make it less scary-sounding to enable 720p (and _maybe_ 1080p) HD OGV transcodes, which will enable high-def playback in Safari and Edge. (And maybe IE 11 on a fast machine, but IE is less than half the speed of Edge or Safari at decoding.) These will still be bigger than the WebM versions because Theora needs a higher data rate than VP8 to maintain quality, but the WebMs and the other OGVs will be smaller than they used to be at fixed bitrates, so it's less of a burden.
I know you really want HD WebM in Safari, but that's not possible until *huge* performance gains can be realized in the decoder... or Apple gives in and adds WebM support to their operating system. Don't hold your breath on waiting for Apple; their ways are mysterious.
Don't hold your breath on huge performance gains either; I'm investigating avenues for improvement (see https://brionv.com/log/2016/05/19/peeking-into-vp8-video-decoding-performanc... & https://brionv.com/log/2016/05/20/vp8-parallelization-continued/ for details) but overlapping macroblocks on CPU threads will probably give less than a 50% improvement, and I have literally no idea what kind of performance to expect from pushing more work to the GPU (and it sounds like a LOT of work, could take months/years of poking at it).
-- brion
Multimedia mailing list Multimedia@lists.wikimedia.org javascript:_e(%7B%7D,'cvml','Multimedia@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org javascript:_e(%7B%7D,'cvml','Multimedia@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org javascript:_e(%7B%7D,'cvml','Multimedia@lists.wikimedia.org'); https://lists.wikimedia.org/mailman/listinfo/multimedia
Great. Thank you, Brion.
Pine On May 30, 2016 14:01, "Brion Vibber" bvibber@wikimedia.org wrote:
On Sunday, May 29, 2016, Pine W wiki.pine@gmail.com wrote:
Thanks for working on this!
4K in WebM and OGV would be highly desirable in some scerarios, such as playing videos on large displays or with projectors at Wikimania or in large classrooms. My personal sense of priorities is that 1080p for Edge and Safari should come first, and after that should come 4K for the most widely used browsers.
If it's possible to improve the maximum display sizes of OGV files from 480p to 4K in one step in a way that is compatible with many browsers, that is icing on the cake.
I can add 720p, 1080p, and 1440p OGV in the short term. Won't bother producing the 2160p size in OGV probably as I can't get smooth playback at that resolution and there's no sense eating the disk space.
Since we have fairly few 2160p source files, I'll probably just bump up the WebM transcodes to 2160p as well for now.
-- brion
Pine On May 29, 2016 01:16, "Brion Vibber" bvibber@wikimedia.org wrote:
On Fri, May 27, 2016 at 12:06 PM, Pine W wiki.pine@gmail.com wrote:
Hi Brion,
I think that 1080p HD OGV transcodes would be a big improvement for both Safari and Edge. I'd love to see that happen, preferably before 2Q 2016-2017.
You'll enjoy these samples of some VBR-encoded files over the full resolution range:
https://brionv.com/misc/ogv.js/demo/#file=RED_4K_Video_of_Colorful_Liquid_in...
https://brionv.com/misc/ogv.js/demo/#file=Tears_of_Steel_in_4k_-_Official_Bl...
https://brionv.com/misc/ogv.js/demo/#file=Art_and_Feminism_Wikipedia_Edit-a-...
(Click into 'search media' for more -- stay in the "VBR transcode tests" mode in the media selector panel or you'll go back to the existing Commons transcodes.) Crank it back down to 720p or below in the resolution selector if 1080p is too slow. You can actually crank some of these up to 1440p or even 2160p, though they get rather slow and large. ;) 1440p is the limit I can run smoothly on my MacBook Pro in Safari.
720p and 1080p OGVs look pretty decent and aren't as huge overall using VBR, though the bitrates can skew upwards in high-complexity scenes which will benefit from adaptive switching later on... If there are no big surprises I'll go ahead and enable 720p and 1080p Ogg transcodes live some time in the next couple weeks.
I'm also putting together an updated maintenance script to re-run transcodes in bulk, as the current ones are pretty ..... very broken and don't actually work.
Some preliminary notes on things that need work for adaptive streaming with OGV: https://brionv.com/log/2016/05/26/thoughts-on-ogg-adaptive-streaming/
-- brion
Pine On May 24, 2016 11:09, "Brion Vibber" bvibber@wikimedia.org wrote:
On Tue, May 24, 2016 at 10:21 AM, Pine W wiki.pine@gmail.com wrote:
In addition to automated bitrate adjustments, can there be a way for users to manually adjust their bitrates or quality settings on the fly without changing resolutions or file formats?
Probably not; if I understand you correctly you would like to be able, as an end-user watching a video, to switch from "480p Ogg Theora at 2 Mbps" to "480p Ogg Theora at 3 Mbps" etc? That would require pre-generating, and storing, some arbitrarily large number of copies of the file at different bitrates/quality settings for very little expected benefit.
It makes a lot more sense to me to encode at a bitrate/quality setting that results in reasonable quality for each resolution; then if you need to change bitrates due to network limitations, you bump up or down a notch on the resolution list. This also avoids extra blocky artifacts from having a too-low-bitrate at a high resolution, etc.
Not meaning to be ungrateful, but I think that improving HD video playback in IE and Safari should take precedence as a priority. I tried watching one of Victor's HD WEBM fundraising videos on a 4K display in Safari, and my user experience went from amazing to awful as soon as playback started in low-def OGV.
There are several questions kind of stuck together there, let me tease them apart and answer them each:
- The source file's format is not related to resolution or quality of
the source -- we have beautiful 1080p HD videos with high bitrate OGV sources, and 240p quarter-SD videos with crappy, artifact-laden low-bitrate WebM VP9 sources.
- Visual quality is not determined by format alone, but by a
combination of format, bitrate, quality settings, and the particular input data. When rendered at the same resolution at *appropriate* bitrates/quality settings, WebM and OGV will look about the same... OGV will tend to degrade a bit more in high-motion scenes, but if the base quality is good that's usually a modest effect.
- WebM is not currently used for the ogv.js fallback player in
Safari/IE/Edge because it's several times slower to decode than OGV at the same resolution, and still a lot buggier (though you'll be happy to hear I've fixed several major bugs recently!) If we switched to using WebM for ogv.js, you *would not* get HD because it's too slow to decode HD WebM in ogv.js.
- OGV transcodes are currently only made up to 480p (standard def); we
do not currently produce 720p or 1080p high-def transcodes in OGV. This means in Safari you won't get high-def playback even if your computer could handle it (and if it's a current-ish Mac or a recent model iPad, it can probably handle OGV at 720p or 1080p at a modest 24fps or 30fps).
- Bitrate & quality settings -- many of our OGV transcodes at 480p and
360p are still older versions from when a too-low bitrate was used, leading to *very* poor appearance. You can determine this by going to the File: page on Commons and checking the transcode list at the bottom; if it says something around 1 Mbits for 480p or 500 kbits for 360p, it's an old file and not representative of current settings. It should say around 2 Mbits for 480p, 1 Mbit for 360p, 500 kbits for 240p.
- Sometimes the automatic resolution downgrade for slow computers in
the ogv.js/TimedMediaHandler integration picks a super-low 160p resolution version when it should not have, which looks pretty bad.
So -- what am I doing to improve it, you ask? :)
Here's what: the general disk space / bandwidth savings from using variable bitrate encodings make it less scary-sounding to enable 720p (and _maybe_ 1080p) HD OGV transcodes, which will enable high-def playback in Safari and Edge. (And maybe IE 11 on a fast machine, but IE is less than half the speed of Edge or Safari at decoding.) These will still be bigger than the WebM versions because Theora needs a higher data rate than VP8 to maintain quality, but the WebMs and the other OGVs will be smaller than they used to be at fixed bitrates, so it's less of a burden.
I know you really want HD WebM in Safari, but that's not possible until *huge* performance gains can be realized in the decoder... or Apple gives in and adds WebM support to their operating system. Don't hold your breath on waiting for Apple; their ways are mysterious.
Don't hold your breath on huge performance gains either; I'm investigating avenues for improvement (see https://brionv.com/log/2016/05/19/peeking-into-vp8-video-decoding-performanc... & https://brionv.com/log/2016/05/20/vp8-parallelization-continued/ for details) but overlapping macroblocks on CPU threads will probably give less than a 50% improvement, and I have literally no idea what kind of performance to expect from pushing more work to the GPU (and it sounds like a LOT of work, could take months/years of poking at it).
-- brion
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
multimedia@lists.wikimedia.org