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" <bvib...@wikimedia.org> wrote: > On Tue, May 24, 2016 at 10:21 AM, Pine W <wiki.p...@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-performance/ > & 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
