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.

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(a)wikimedia.org> wrote: _______________________________________________ Multimedia mailing list Multimedia(a)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" &lt;bvibber(a)wikimedia.org <javascript:_e(%7B%7D,'cvml','bvibber@wikimedia.org');>> wrote: > On Fri, May 27, 2016 at 12:06 PM, Pine W &lt;wiki.pine(a)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_i… > * > https://brionv.com/misc/ogv.js/demo/#file=Tears_of_Steel_in_4k_-_Official_B… > * > 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" &lt;bvibber(a)wikimedia.org >> <javascript:_e(%7B%7D,'cvml','bvibber@wikimedia.org');>> wrote: >> >>> On Tue, May 24, 2016 at 10:21 AM, Pine W &lt;wiki.pine(a)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-performan… >>> & 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(a)lists.wikimedia.org >>> <javascript:_e(%7B%7D,'cvml','Multimedia@lists.wikimedia.org');> >>> https://lists.wikimedia.org/mailman/listinfo/multimedia >>> >>> >> _______________________________________________ >> Multimedia mailing list >> Multimedia(a)lists.wikimedia.org >> <javascript:_e(%7B%7D,'cvml','Multimedia@lists.wikimedia.org');> >> https://lists.wikimedia.org/mailman/listinfo/multimedia >> >> > > _______________________________________________ > Multimedia mailing list > Multimedia(a)lists.wikimedia.org > <javascript:_e(%7B%7D,'cvml','Multimedia@lists.wikimedia.org');> > https://lists.wikimedia.org/mailman/listinfo/multimedia > >