[00:00:20 CET] <cone-203> ffmpeg 03James Almer 07release/4.1:abf36b76de63: avcodec/av1_parser: don't abort parsing the first frame if extradata parsing fails [00:00:21 CET] <cone-203> ffmpeg 03James Almer 07release/4.1:6972b353b4e0: avcodec/cbs_av1: fix range of values for Mastering Display Color Volume Metadata OBUs [03:04:05 CET] <giggybyte> gotcha, thanks for the information. i'll take a look at the other suggestions, then [10:15:39 CET] <thardin> grmbl google [10:17:50 CET] <thardin> maybe I can give them the hackerspace's address [10:19:15 CET] <nevcairiel> durandal_1707: i found an issue with your cached bitstream reader, specifically get_bits_le just doesn't work, i have a UtVideo file thats broken due to that, disabling cached reader makes it work. Any thoughts? [10:21:16 CET] <nevcairiel> (here is a sample file that is affected: https://files.1f0.de/samples/ut-test-t2-umrg.mkv) [10:25:20 CET] <nevcairiel> As I understand the code, the problem is that get_bits_le in the old code also refills using AV_RL, but the new reader always refills with AV_RB, so it has the bytes in a different order. [10:29:42 CET] <durandal_1707> nevcairiel: on it [10:32:49 CET] <kurosu> is there a place where it works? (not being sarcastic, just wondering if it is a specific condition) [10:32:53 CET] <kurosu> though if durandal_1707 is on it [10:33:25 CET] <nevcairiel> get_bits_le is extremely rarely used in our code [10:33:32 CET] <nevcairiel> only in like 2-3 obscure formats, and utvideo [10:34:03 CET] <nevcairiel> and I dont think it can work right now [10:34:59 CET] <kurosu> might be a refill problem that is cpu-dependent rather than codec-dependent (ie _le should invoke the _le refill?) [10:35:04 CET] <kurosu> can't try atm [10:35:33 CET] <nevcairiel> i dont know if its expected that you can mix get_bits and get_bits_le on the same reader [10:35:36 CET] <nevcairiel> in the old one you can [10:35:50 CET] <nevcairiel> in the new one, that might be very problematic if you j ust change the refill [10:36:04 CET] <nevcairiel> unless you keep track of which method you filled with and then purge and re-fill again if it changes [10:36:08 CET] <durandal_1707> no code does combination [10:36:21 CET] <durandal_1707> and should not do it anyway [14:02:15 CET] <cone-892> ffmpeg 03Jun Zhao 07master:e9c9514ce37c: avformat/avformat.h: Update the comment for AVInputFormat.flags [15:38:45 CET] <nevcairiel> man why do we not have a multithreaded software scaler, this is really holding up my flow here [15:45:44 CET] <atomnuker> but we do, just slice the frame yourself and run Nx swscale instances in separate threads [15:46:00 CET] <nevcairiel> last i tried, that didnt work for shit [15:46:15 CET] <nevcairiel> admittedly its been a while ago [15:46:20 CET] <atomnuker> you tried that!?! [15:46:44 CET] <atomnuker> without caring about potential blocking artifacts? [15:47:48 CET] <BBB> atomnuker doing a pirouette [15:48:30 CET] <nevcairiel> back then it just resulted in a lot of nonsense [15:48:46 CET] <nevcairiel> but maybe it was improved since then, i faintly remember reading something about it [15:48:51 CET] <nevcairiel> but apparently its still crap then? [15:50:55 CET] <rcombs> atomnuker: I mean if you frame-threaded it'd be fine [15:51:33 CET] <nevcairiel> I might be ok with a slight delay in this use-case, but its harder to implement as well [15:51:51 CET] <nevcairiel> i should probably favor hardware scaling, since its hardware encoding anyway [15:52:07 CET] <nevcairiel> only that i need to write a d3d11 scaler then, and i was lazy about that [15:52:32 CET] <JEEB> libplacebo or so? [15:52:43 CET] <JEEB> then use shaderc to compile to HLSL [15:52:45 CET] <JEEB> :V [15:52:52 CET] <nevcairiel> i'm fine with the fixed function d3d11 scaling [15:52:55 CET] <JEEB> :) [15:52:56 CET] <nevcairiel> can also hook up deint then [15:53:15 CET] <atomnuker> write vulkan import export for d3d11 [16:17:13 CET] <atomnuker> I'm impressed, a 53mb total vp9 beats a 140mb h264+aac for a 640x360 video [16:17:26 CET] <atomnuker> on youtube [16:18:21 CET] <atomnuker> oh wow there's an av1 version as well, nevermind, I'll watch that [17:09:20 CET] <rcombs> nevcairiel: what are you encoding with anyway [17:09:42 CET] <rcombs> (just curious about hardware pipelines on windows, since they're historically pretty awkward) [17:09:54 CET] <nevcairiel> d3d11 -> nvenc pipeline works pretty well [17:10:26 CET] <nevcairiel> but its really the only full hardware pipeline i care to support, qsv d3d11 support is broken [17:10:28 CET] <rcombs> can't use scale_cuda? [17:10:44 CET] <nevcairiel> cuda filters are nonfree at this time [17:10:50 CET] <gnafu> atomnuker: I was watching a video the other day that looked really rough in AV1, so I checked out other versions. It was even worse in VP9, but nearly unwatchable in H.264. [17:11:09 CET] <gnafu> Didn't look good in any version, though. [17:11:11 CET] <rcombs> wait, the filters are nonfree but the encoder isn't? [17:11:23 CET] <nevcairiel> yes, because of the cuda compiler [17:12:18 CET] <rcombs> huh [17:13:32 CET] <nevcairiel> right now i'm trying to figure out if supporting qsv is generally worth it, the ffmpeg encoder seems to be in a somewhat questionable state [17:15:28 CET] <rcombs> I dunno your use case but generally intel's stuff is stupidly fast [17:16:23 CET] <nevcairiel> Yeah that part is fine [17:16:57 CET] <nevcairiel> but the ffmpeg implementation is so bad, it has no runtime feature probing at all, the sdk you build with determines hardware support, which is just stupid [17:19:18 CET] <nevcairiel> i should probably round up a few older intel systems and see if i can figure out some way to make it work on them [17:19:52 CET] <nevcairiel> after i finished tweaking the nvenc stuff i guess [17:22:19 CET] <nevcairiel> maybe also figure out how the amd stuff works, although i dont think i have any hardware for that, so meh [19:21:12 CET] <lotharkript> durandal_1707: I was told you may know this answer: Should the output of a filtercomplex vs vf behave the same when using fps filter and vsync? [19:29:06 CET] <BtbN> It's just different cli syntax, the create instances of the exact same filters. [19:29:10 CET] <BtbN> *they [19:34:49 CET] <lotharkript> BtbN: we found a difference between -filtercomplex fps=fps=60 -vsync 1 and -vf fps=fps=60 -vsync 1. Looking at the code, it seems there is a path being executed with filtercomplex, but not with vf: see https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L1080 [19:35:07 CET] <BtbN> vsync is a horrible hack iirc, and it wouldn't surprise me [19:35:41 CET] <lotharkript> because the filter does not change the AVframe duration, the hack is using it for vsync [19:35:58 CET] <lotharkript> so, should the FPS filter update the AVFrame.duration field? [19:40:51 CET] <BtbN> Only the timestamps really matter anyway [21:16:46 CET] <cone-867> ffmpeg 03Carl Eugen Hoyos 07master:1e34014010db: lavc/bmp: Avoid a heap buffer overwrite for 1bpp input. [22:07:57 CET] <lotharkript> BtbN: I agreed that TimeStamp should matter , but looking at this code: https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c#L1080 they are using the AVFrame Duration, which is incorrect when we use FPS filter [00:00:00 CET] --- Wed Mar 27 2019