[14:52:06] [[Tech]]; DasSvenson; /* Fehler [e9012b466b1436590a45e549 ]Wikimedia\Rdbms\DBQueryError */ new section; https://meta.wikimedia.org/w/index.php?diff=27331255&oldid=27318230&rcid=32251578 [14:54:53] [[Tech]]; JJMC89; /* Fehler [e9012b466b1436590a45e549 ]Wikimedia\Rdbms\DBQueryError */; https://meta.wikimedia.org/w/index.php?diff=27331303&oldid=27331255&rcid=32251628 [15:10:58] [[Tech]]; DasSvenson; /* Fehler [e9012b466b1436590a45e549 ]Wikimedia\Rdbms\DBQueryError */ Reply; https://meta.wikimedia.org/w/index.php?diff=27331541&oldid=27331303&rcid=32251880 [15:25:15] Question: Is there any way to force timed media handler to use the "source" video instead of a transcode (Context: its for a screencast, and the transcodes do horrible things to text on the screen) [15:25:48] [[Tech]]; AKlapper (WMF); [none]; https://meta.wikimedia.org/w/index.php?diff=27332064&oldid=27331541&rcid=32252490 [15:25:51] I was thinking maybe if the file was low enough resolution it might work... but even if the video was sub-720p, it still chose the 360p transcode over the source file [15:59:54] bawolff, are you asking about from within the player or for all users via the file syntax? [16:00:09] via file syntax [16:00:48] Basically I'm worried that users won't realize they can change it, and want a way to set the default source via file syntax [16:01:30] I'm not aware of an option for that [16:01:58] it would have to prefer using the source file instead of requiring it, as there is no free video format with 100% compatibility [16:02:41] Who doesn't support webm at this point? [16:03:51] but regardless, that doesn't really matter to me, i just want something where the average user upon clicking play is actually greeted with a video that is not super blurry [16:04:02] * bawolff probably out of luck [16:04:05] older iOS devices only support H.264/HEVC [16:04:23] So far, the best idea seems to be [[File:Some thumb.png|link=Media:foo]] [16:05:43] https://caniuse.com/?search=webm hmm, 5% of users still have no webm. That's kind of sad. Its 2024 alrady [16:08:49] bvibber is definitely the person to talk to about this [16:11:41] * bvibber perks up [16:12:19] bawolff: no, timedmediahandler prefers not to play the source video if it can, as it's less likely to be suitably encoded for live playback [16:12:51] If you want full context, its for gsoc project. my gsoc student is wondering how to make the video on https://www.mediawiki.org/wiki/User:JayanthVikash/GSoC/InlineComments-Draft#Video_demo not be blurry [16:12:53] is there a specific need for picking the source file? [16:13:22] bvibber: basically its a screencast, and the transcode transcoding settings seem to make text be blurry, which is unideal [16:13:27] in my firefox i get 720p when i load it [16:13:32] is 720p bad? [16:13:53] it'll pick a size close to the window size [16:14:04] 720p is ok, when we were testing it out though, it seemed not as sharp as we would like [16:14:15] 480p is really bad [16:14:37] screencasts on video should generally be recorded with large font sizes on purpose to survive small video sizes [16:14:55] that looks like a 1080p screen just recorded with normal fonts [16:15:09] i'd recommend retooling the video with in-browser usage in mind [16:15:20] small windows, picture-in-picture, phone screens are all small [16:15:59] you can't assume people will have a 13" or larger screen showing high-resolution video [16:16:39] FWIW, an older version of the video was somewhat smaller resolution - (The 2nd entry in the file history at https://www.mediawiki.org/wiki/File:InlineComments_extension_updated_video.webm ) [16:16:47] but i agree, larger fonts make sense here [16:17:30] When it was an 846x693 resoultion video TMH picked the 480p transcode, which looked really bad [16:17:52] yeah it'll never scale up, so having a weird intermediate size means you get the next size down [16:17:58] what standard is 846 by 693 [16:18:19] I think it was just cropped from part of a desktop [16:18:20] in any case it's not the pixel size that's at issue so much as the font size [16:18:39] if you'd have trouble reading it in 480p on a phone screen, then redo the video :) [16:19:03] think about the user's environment [16:19:10] playback on different devices and circumstances [16:19:30] I think 480p original source would be fine. 480p TMH transcode is not [16:19:49] why? [16:20:03] the font size matters [16:20:08] and that wouldn't change [16:20:28] 480p original and 480p transcode of 480p original should be very very similar [16:20:39] font size would help a lot here, but i think a major issue here are artifacts introduced by the transcode process [16:21:07] i disagree, the font size is the exact specific problem [16:21:39] although i didn't actually try a 480p original, but for example the 846x693 source video is significantly better than the 720p transcode of the larger video, despite being smaller resolution [16:22:12] so that's probably because it's not scaled down? [16:22:29] yes [16:22:30] you seem to have an issue with the scaling, is my understanding [16:22:48] I mean, i think its the same as PNG vs JPEG scaling [16:22:49] which is why the scaling of the font size is the issue [16:22:53] ...? [16:23:10] i don't understand [16:23:30] Where we use different settings when scaling pngs then jpegs, because which algorithm looks best depends on the contents of the file [16:23:42] ...? [16:23:58] Like we sharpen pngs but we don't sharpen jpegs [16:24:07] that's not happening here at all [16:24:16] you're essentially comparing a large JPEG against a smaller JPEG derived from it [16:24:22] and saying "the small JPEG has harder to read text" [16:25:28] it is true that the smaller JPEG has harder to read text, but this is because the text has been scaled down too small [16:25:39] if the text were larger, you wouldn't have this problem. [16:30:05] The compression artifacts in the transcoded video are pretty severe, I think even at a larger font size they would be very noticable [16:30:27] But regardless, i agree that font should be bigger [16:30:40] well my recommendation is to start with a video that you know is legible at 480p on a small screen [16:30:52] and if that still looks bad to you, we'll talk about adjusting parameters ;) [16:31:57] Even if parameters could be better for this particular case, it probably wouldn't make sense to adjust parameters, as I don't think screencasts are your average video content [16:32:17] screencasts are honestly nasty edge cases for video ;) but they're relevant to us i suspect [16:32:30] if i had more time to dedicate to revamping the video support i'd put some time into doing this better :( [16:33:14] and thanks for reminding me about the thing where it scales down but not up and can end up with a much bigger drop-down than you like [16:33:23] i may be able to convince it to better handle odd sizes [16:33:44] eg by putting a not-scaled-up version in the 1080p slot that's really 893p or whatever ;) [16:34:00] i'll make a note to add that to my tech debt list [16:39:15] Hmm, you might be right about it being mostly down to font size. I looked at some other screencasts with bigger fonts, and they look much better even after transcoding [16:41:24] yay [16:41:51] the visual business of the smaller font sizes is extra hard on the compression, so the smaller sizes _and_ the extra hgih-frequency data compound to lower visual quality yeah :D [16:42:28] Ohh, so its using up its byte budget [16:42:30] video encoding is more aggressive about dropping quality to maintain bitrate than stills [16:42:33] exactly :D [16:42:42] ok, that makes a lot of things make sense to me [16:42:48] \o/ yay [16:45:20] I think i was getting confused, because for example, the 360p transcode (of https://www.mediawiki.org/wiki/File:InlineComments_extension_updated_video.webm ) really did look horrible beyond just small fonts. Like even UI elements were severely blurred, and i was thinking that that couldn't just be font size, but the 360p transcode of an older version with bigger fonts ( [16:45:26] https://www.mediawiki.org/wiki/File:MediaWiki_InlineComments_extension_demo.webm ) looks reasonably normal [16:45:40] so byte budget makes a lot of sense for what i was seeing [16:46:59] *nod* [16:47:04] ty :) [17:21:23] Ah, it seems like part of the problem here is my co-mentor had the video defaulting to 240p for unknown reasons, which was a very bad user experience for him :S [18:00:40] hmm, looks like it tries to default to 666px but that's not one of the choices [18:00:49] but only on chrome (?) [18:22:04] oh its because i am zoomed in on firefox [18:22:07] Filed as https://phabricator.wikimedia.org/T373137