[00:23:00 CEST] <durandal_1707> BtbN: use metadata filter to print it [00:24:09 CEST] <BtbN> the hack is working for now [00:24:30 CEST] <BtbN> but yeah, looks like it could also do that [00:51:48 CEST] <atomnuker> iive: updated https://pars.ee/temp/pvq_v2_benchmark.txt [00:53:12 CEST] <iive> Thank You [00:54:18 CEST] <durandal_1707> michaelni: prores_ks cant emulate prores_aw [00:55:31 CEST] <durandal_1707> you are asking bitrate which would give similar numerical results [00:55:50 CEST] <durandal_1707> thats nonsense [00:56:54 CEST] <durandal_1707> there are options to target bitrate per macroblock i think [00:57:00 CEST] <durandal_1707> use that [01:01:16 CEST] <michaelni> to compare quality one can check quality at the same bitrate or bitrate at the same quality or draw a distortion vs bitrate curve and compare these [01:02:01 CEST] <michaelni> you said its better i try to understand what you compared [01:02:11 CEST] <durandal_1707> bare eyes [01:02:48 CEST] <michaelni> did the files use similar bitrate ? [01:03:31 CEST] <durandal_1707> i could try to target it but why? [01:04:32 CEST] <durandal_1707> besides it supports only one pixel format [01:04:50 CEST] <durandal_1707> no point in keeping it [01:04:55 CEST] <michaelni> if a file with twice the size looks better it doesnt tell anything about which encoder is better quality [01:05:34 CEST] <michaelni> thats why i ask about bitrate so much, i would not really mind otherwise [01:06:47 CEST] <michaelni> iam not asking to keep 2 encoders but we should keep the better encoding algorithm, i do not knw which is better i dont remember the implementations exactly [01:07:52 CEST] <durandal_1707> michaelni: its obviously worse quality because it doesnt support higher profiles, besides i need to check which profile was used in fate [01:09:30 CEST] <durandal_1707> also this format is not used for compression [01:09:33 CEST] <nevcairiel> if both encoders lack ratecontrol to actually control the bitrate for a comparison, then with a format like prores the absolute quality should probably still matter [01:09:48 CEST] <michaelni> does either or both of the encoders do proper rate distortion decissions ? RD would beat non RD [01:12:10 CEST] <iive> atomnuker: may I request one more test run, all_float and presearch_rounding, at the same time. [01:12:37 CEST] <iive> you gave me a single number yesterday, it's bug i've made. [01:15:40 CEST] <atomnuker> so ALL_FLOAT_PRESEARCH cpuflag(sse42) && 1 and PRESEARCH_ROUNDING 01? [01:15:59 CEST] <atomnuker> that's already in the text file [01:16:09 CEST] <atomnuker> since presearch rounding is on as it was [01:16:20 CEST] <iive> rounding 00 [01:19:48 CEST] <atomnuker> iive: done [01:20:17 CEST] <iive> thank you [01:22:26 CEST] <iive> atomnuker: one more thing. [01:22:43 CEST] <iive> could you run a start/stop timer without anything between them [01:22:48 CEST] <iive> aka, no code. [01:22:55 CEST] <iive> once is enough. [01:23:04 CEST] <atomnuker> wouldn't it be more useful to run them with an empty function? [01:23:14 CEST] <atomnuker> calls still take time [01:24:15 CEST] <iive> no need [01:25:12 CEST] <iive> stop timer has an instruction fence, and it takes a lot of cycles to finish all codes at it. [01:25:37 CEST] <atomnuker> huh, didn't know that [01:25:39 CEST] <atomnuker> 264 decicycles in pvq_search, 8388340 runs, 268 skips [01:25:54 CEST] <iive> nice. similar to my cpu. [01:37:37 CEST] <kierank> rcombs: you can come visit us in Vauxhall if you want [01:38:17 CEST] <durandal_1707> watch out: they bite [01:38:57 CEST] <kierank> durandal_1707: i don't bite [01:39:29 CEST] <durandal_1707> i wasnt thinking .. [02:02:58 CEST] <jamrial> ubitux: can you test the coff patch on the ml with your freedos box? [02:03:49 CEST] <jamrial> nevcairiel: i have no idea what could be wrong with our code when you mix nasm and msvc, so just force yasm so the slots stop being red [02:07:18 CEST] <jamrial> nevcairiel: one thing worth testing is perhaps reverting 18f09524f7 since there's a ticket in trac complaining it generated unreadable .a files, but aside from that i don't know what could be wrong [03:13:12 CEST] <graphitemaster> when decoding audio with ffmpeg api, is there a way to request it at a different time scale, i.e slow it down or speed it up [03:14:02 CEST] <graphitemaster> right now I'm consuming it at the rate it suggests, which is fine, but our application has a global time scale, doing things this way leads to aliased or clipped audio naturally. [03:17:09 CEST] <Compn> there is an audio filter [03:17:34 CEST] <Compn> which api are you using graphitemaster ? [03:19:05 CEST] <graphitemaster> just av_read_frame and for audio avcodec_decode_audio4 with swr_convert to map it to the format and sample rate our application internally requires pretty much everything as [03:21:15 CEST] <graphitemaster> if there is a filter I can just tack onto the stream which does the magical time scale stuff [03:21:18 CEST] <graphitemaster> that'd be neat [03:21:27 CEST] <graphitemaster> not sure where to find the documentation for that though [03:21:32 CEST] <graphitemaster> or if such a thing exists [03:22:47 CEST] <graphitemaster> problem is I need to control the filter while decoding a stream, it needs to be immediate, I can't just open a stream with a filter, I need to control time scale pretty much at runtime at any time. [03:30:24 CEST] <graphitemaster> so it seems atempo is what I want [03:31:09 CEST] <graphitemaster> ah shucks, atempo is limited to 0.5 to 2 inclusive [03:31:13 CEST] <graphitemaster> that's no good :| [03:34:46 CEST] <graphitemaster> can stack atempo filters :| [03:34:53 CEST] <graphitemaster> but man that feels ugly [03:35:39 CEST] <graphitemaster> like, determining at runtime how many atempo filters I need and their coefficients would be basically impossible in the short amount of time I have anyways [10:02:18 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:4ed7c2bbc3d0: avcodec/utvideodec: add SIMD for restore_rgb_planes [10:28:29 CEST] <thebombzen> what is UT video even used for :O [10:41:39 CEST] <JEEB> thebombzen: it's an open source lossless video thingy that has modules for all.major video frameworks [10:42:04 CEST] <JEEB> thus it got popular for exporting your videos from editors etc [10:42:20 CEST] <thebombzen> Ah. Why not ffv1? isn't that now a standard? [10:42:40 CEST] <JEEB> it's becoming but there are no modules [10:43:06 CEST] <thebombzen> other than libavcodec ones I guess [10:43:09 CEST] <JEEB> also ut video is used to input lossless clips into those frameworks [10:43:33 CEST] <JEEB> basically ut has vfw/dshow/mf/QT [10:43:49 CEST] <thebombzen> hm, according to wikipedia it's also designed to be a more efficient alternative to huffyuv [10:44:01 CEST] <JEEB> so win/mac things can both read/write ut [10:44:04 CEST] <thebombzen> meaning it's probably a lot faster than ffv1 but less good for archiving due to ratio [10:44:31 CEST] <JEEB> yea compression wise ffv1 wins big time [10:45:09 CEST] <thebombzen> I wonder if utvideo is suitable for realtime encoding. Currently I use yuv444p libx264 with -qp 0 [10:45:12 CEST] <thebombzen> and preset superfast [10:57:51 CEST] <rcombs> kierank: poke me on twitter or something? I may have time to drop by today [11:17:25 CEST] <LongChair> jkqxz: hi :) touching base on the drm topic, hoping you had some time to think about it :) [12:07:51 CEST] <durandal_1707> wow foo86 rocks [12:15:40 CEST] <kierank> durandal_1707: LOL [12:15:57 CEST] <durandal_1707> whats funny? [12:16:42 CEST] <kierank> impressive piece of work [12:18:46 CEST] <nevcairiel> wasnt there some talk long ago that dolby might get angry about dolby e decoders [12:18:53 CEST] <kierank> yes they will [12:20:02 CEST] <durandal_1707> just point to vlc people, not us [12:27:24 CEST] <funman> 17:56 <@durandal_1707> only when kierank posts dolby-e decoder [12:27:48 CEST] <funman> too late i guess [12:32:01 CEST] Action: rcombs shrugs [12:32:02 CEST] <rcombs> fuck 'em [12:44:46 CEST] <thebombzen> I was thinking of writing a -vf colorlevelsdetect filter that autodetects the black point and white point to be fed for -vf colorlevels, similar to how -vf cropdetect is used for -vf crop [12:44:55 CEST] <thebombzen> is this something that would get added to libavfilter? [12:46:42 CEST] <thebombzen> or I mean if I write this and submit a patch for it to be added and document it, would there be any reason it's not added [12:51:46 CEST] <durandal_1707> thebombzen: basically you need report max and min value of pixel in video frame? [12:52:02 CEST] <durandal_1707> for example for y component? [12:52:40 CEST] <thebombzen> yea basically, and also scale it to the [0, 1] range because that's what colorlevels takes [12:53:07 CEST] <thebombzen> most likely I'd end up reporting both, but if you want it to end up like cropdetect, which spoon-feeds you the vf crop filter, I'd also have to do the scaling [12:58:15 CEST] <durandal_1707> thebombzen: doesnt cololevels already does that via negative number set for imin and imax? [12:58:35 CEST] <thebombzen> I don't know, does it? [12:59:56 CEST] <thebombzen> I don't actually know what negative input values for imin and imax do, seeing that setting imin to 0 and imax to 1 ends up doing nothing [13:18:25 CEST] <durandal_1707> thebombzen: set input max and min to -1 and watch output [13:23:40 CEST] <thebombzen> durandal_1707: that works, but it changes per-frame and doesn't print the info to stdout [13:24:28 CEST] <thebombzen> which means the filter's parameter change over the course of the input. it sounds like it would be nice for there to be a verbose=yes option or something to print the autodetected filter it's applying [13:24:40 CEST] <durandal_1707> if you need only numbers try signalstats filter [13:24:51 CEST] <thebombzen> hm, one sec, lemme read that [13:25:54 CEST] <durandal_1707> well it will not work for you because its not rgb filter... [13:26:44 CEST] <thebombzen> yea, according to the manpage, signalstats does not output rgb, and colorlevels only does rgb [13:27:35 CEST] <thebombzen> it might make sense to use the Y value if you want to just adjust the value without adjusting the color balance though [13:29:34 CEST] <JEEB> oh wow, dolby-e :D [13:29:38 CEST] <JEEB> foo86 da man [13:35:53 CEST] <funman> they really missed on calling it dolb-e [13:36:22 CEST] <JEEB> :D [13:36:59 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:430d4f2bb52e: avcodec/ffv1enc: Allow less than 2 rows of slices for low vertical resolution [13:37:00 CEST] <cone-209> ffmpeg 03Andreas Håkon 07master:a29c7127297a: avformat: Fix Pro-MPEG non-square matrix [13:37:01 CEST] <cone-209> ffmpeg 03Michael Niedermayer 07master:0f8d3d8a462c: avcodec/ffv1enc: compute the max number of slices and limit by that [13:42:16 CEST] <kierank> is there any way i can remove this political bullshit footers from the mailing list [13:47:32 CEST] <Compn> where ? [13:47:38 CEST] <durandal_1707> kierank: what? [13:48:04 CEST] <J_Darnley> I would guess michaelni's most recent email [13:48:08 CEST] <kierank> not singling out michaelni because there are other people but i don't care about stupid politics [13:48:33 CEST] <Compn> oh, the automated signatures in peoples various mails [13:49:04 CEST] <durandal_1707> oh that one is very old... [13:50:26 CEST] <Compn> if you dont care about politics why are you caring abou... nevermind [14:03:46 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:bbaca6e86799: avcodec/proresenc_kostya: add 4444XQ profile [14:32:58 CEST] <thebombzen> this person links their log on a file upload site that has a shitty html interface that makes you pay or wait 5 seconds or some bs [14:57:22 CEST] <TMM> How is it determined whether enough reviews have taken place on a patch? I've received two reviews with some small fixes which I've processed but it appears that everything went silent again :) [14:57:27 CEST] <TMM> am I supposed to do something? [15:01:26 CEST] <BBB> did you send a new/updated patch? [15:01:35 CEST] <TMM> yes [15:02:06 CEST] <BBB> how long ago? [15:02:34 CEST] <TMM> Sunday [15:02:40 CEST] <durandal_1707> i gonna commit it, its game codecs after all [15:02:45 CEST] <BBB> ok [15:03:37 CEST] <TMM> If there are more fixes needed I'll happily make them :) [15:48:59 CEST] <wm4> " This fixes build failures on older mingw chains (before 2012)." [15:49:00 CEST] <wm4> nevcairiel: why [15:49:19 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:ba2c385006e3: Interplay MVE: Implement MVE SEND_BUFFER operation [15:49:20 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:8f87bfb4b7dd: Interplay MVE: Refactor IP packet format [15:49:21 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:19f6fd199e46: Interplay MVE: Implement frame format 0x06 [15:49:22 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:8f96da060a26: Interplay MVE: Implement frame format 0x10 [15:49:23 CEST] <cone-209> ffmpeg 03Hein-Pieter van Braam 07master:c4cbaec6e3af: Interplay MVE: Changelog entry for changes [15:49:24 CEST] <cone-209> ffmpeg 03Paul B Mahol 07master:feab761b73c3: avcodec/interplayvideo: properly check if there is enough bytes left [15:49:40 CEST] <wm4> also I assume it's fine to push merges without review [15:52:05 CEST] <iive> wm4: sure, but you have to fix them if somebody finds they cause regression. [15:52:44 CEST] <TMM> durandal_1707, Did you add those extra checks? [15:52:49 CEST] <TMM> durandal_1707, to interplayvideo? [15:53:16 CEST] <durandal_1707> yes [15:53:32 CEST] <TMM> durandal_1707, isn't that the exact same check that's on like 1292? [15:55:19 CEST] <durandal_1707> TMM: not exactly same, also it checks after doing pointer stuff [15:55:47 CEST] <durandal_1707> i guess that check is now obsolete [15:56:30 CEST] <TMM> bytestream2_init doesn't actually read anything though, right? [15:56:38 CEST] <TMM> that's why I collapsed all those checks at the end [15:56:59 CEST] <TMM> it'll setup all the pointers and bytestreams but it won't actually read anything until after that check [15:57:21 CEST] <durandal_1707> nope, but o dislike idea of incrrasing pointer and checking for overread later [15:57:42 CEST] <TMM> OK, I'll keep that in mind for next time [15:57:51 CEST] <TMM> the reason I did it like this was to ensure that no codepath could exist without that check [15:57:58 CEST] <durandal_1707> check doesnt take into account 14 bytes [15:58:17 CEST] <durandal_1707> of one of modes [15:59:24 CEST] <TMM> ah yeah, it only checks if the total size of the packet is big enough indeed, but the 14 bytes skipped get forgotten about [15:59:34 CEST] <TMM> that's not so great, thanks [16:03:48 CEST] <TMM> durandal_1707, I'll be wanting to merge more stuff from scummvm back into ffmpeg. If you have any other comments please let me know so I won't repeat the same mistakes for the future [16:05:16 CEST] <durandal_1707> TMM: just check for overreads and overwrites if you can [16:05:36 CEST] <durandal_1707> there is more stuff? [16:05:46 CEST] <TMM> yeah, older cocktel vision codec [16:05:51 CEST] <TMM> some bink features [16:05:53 CEST] <TMM> and sierra robot [16:06:21 CEST] <TMM> and I'm working on truemotion1's 'sprite' feature [16:28:28 CEST] <nevcairiel> wm4: what [16:29:16 CEST] <wm4> nevcairiel: I removed the check for disabling dxva with pre-2012 mingw builds [16:29:18 CEST] <wm4> is that ok? [16:29:34 CEST] <nevcairiel> why would you remove something that already exists [16:30:09 CEST] <wm4> because configure is a labyrinth and I don't need an additional wall to enable idiots (people on ancient mingws)? [16:32:12 CEST] <nevcairiel> adding header checks isnt that crazy, but it was like 3 years ago, who knows if anyone still runs those, however entirely failing builds is never nice when you could just disable shit [16:32:38 CEST] <wm4> well I'm not sure what to do with the check [16:33:32 CEST] <wm4> or how it used to work [16:49:12 CEST] <wm4> nevcairiel: want to test my d3d libav merge before I push it? [16:49:24 CEST] <wm4> also I didn't have a chance to test vp9 (not even compilation) [16:49:46 CEST] <wm4> I could probably steal a dxva header from somewhere for that to test compilation at least? [16:49:56 CEST] <iive> wm4: is that check somehow makes merges harder? [16:50:20 CEST] <wm4> iive: yes because Libav didn't have the check [16:51:39 CEST] <nevcairiel> latest mingw-w64 has vp9 at least [16:51:41 CEST] <nevcairiel> i got them to add it [16:52:17 CEST] <iive> is mingw now a distribution? [16:55:05 CEST] <nevcairiel> wm4: do you have a branch for testing? [16:56:40 CEST] <wm4> give me a second [16:57:58 CEST] <wm4> man I wish github had a "merge upstream" button or so [16:58:10 CEST] <wm4> nevcairiel: master branch https://github.com/wm4/ffmpeg/ [16:58:34 CEST] <nevcairiel> yeah its really annoying, w onder why github never tried to solve that problem [16:58:35 CEST] <iive> i thought they have push request or something similar [17:02:18 CEST] <nevcairiel> wm4: the changelog should probably refer to ffmpeg not avconv [17:03:42 CEST] <wm4> sure [17:03:46 CEST] <wm4> fuck the changelog anyway [17:04:08 CEST] <wm4> is just "ffmpeg" the right way to refer to CLI? [17:04:13 CEST] <nevcairiel> i guess [17:05:03 CEST] <wm4> force-pushed my branch to fix that [17:06:25 CEST] <nevcairiel> the dxva2 code sure is full of warnings [17:06:41 CEST] <wm4> example? most should have gone away [17:07:03 CEST] <wm4> but some will just remain if both dxva and d3d are enabled [17:07:11 CEST] <wm4> due to the messy way to making the code "generic" [17:07:14 CEST] <nevcairiel> plenty of those dxva2_internal.h:107:98: warning: pointer type mismatch in conditional expression [17:07:19 CEST] <wm4> yep, this [17:07:25 CEST] <nevcairiel> some const warnings [17:07:34 CEST] <nevcairiel> ibavcodec/dxva2.c:239:59: warning: passing argument 3 of 'dxva2_validate_output' discards 'const' qualifier from pointer target type [17:07:53 CEST] <wm4> huh [17:08:19 CEST] <wm4> that one is easily fixable, and probably should be [17:08:20 CEST] <nevcairiel> warning: "CONFIG_VP9_D3D11VA2_HWACCEL" is not defined, evaluates to 0 [17:08:23 CEST] <nevcairiel> configure missing something? [17:08:31 CEST] <wm4> that sounds worse [17:08:34 CEST] <nevcairiel> or allcodecs.c or whereever? [17:08:40 CEST] <wm4> shit [17:08:53 CEST] <wm4> yes that is missing [17:09:15 CEST] <nevcairiel> these context shit warnigns sure make it hard to find anything else [17:09:29 CEST] <wm4> indeed [17:09:35 CEST] <wm4> pushed a fixup commit [17:09:43 CEST] <wm4> blindly [17:11:23 CEST] <nevcairiel> meh noone ever fixed the problem that you cant run fate with hwaccel anymore [17:11:32 CEST] <nevcairiel> because it now decodes to nv12 and all hashes fail [17:11:44 CEST] <nevcairiel> previously the lack of filte re-config forced it to yuv420 =p [17:11:49 CEST] <JEEB> :D [17:11:53 CEST] <wm4> lol [17:12:11 CEST] <wm4> would be kind of nice if every fate test forced the output format, maybe [17:17:35 CEST] <nevcairiel> so is hwaccel supposed to crop now? [17:17:56 CEST] <nevcairiel> the test at least still fails [17:18:50 CEST] <wm4> only right/bottom borders [17:19:06 CEST] <wm4> the rest isn't hooked up anywhere, at least not with fate [17:19:50 CEST] <durandal_1707> my asm code made function 5x times faster but original utvideo decoder is still faster, how so? [17:20:35 CEST] <atomnuker> by how much? [17:20:51 CEST] <nevcairiel> maybe there is more things to accelerate [17:26:22 CEST] <wm4> nevcairiel: still testing my branch? [17:27:59 CEST] <nevcairiel> yeah had to reconfigure to test vp9 properly, another minute [17:28:24 CEST] <wm4> so I don't get any warnings for dxva2.c here, which is confusing [17:28:44 CEST] <wm4> I think I got at least the pointer type warnings in Libav [17:29:04 CEST] <nevcairiel> maybe for random reasons d3d11va is off for you? [17:29:51 CEST] <wm4> d3d11va, d3d11va2, dxva2 are all enabled [17:30:12 CEST] <wm4> they also worked when I tested them earlier this day [17:30:50 CEST] <nevcairiel> hrm now the build failed entirely [17:31:02 CEST] <nevcairiel> dxva2_vp9.c(354): error C2027: use of undefined type 'dxva2_picture_context' [17:31:08 CEST] <nevcairiel> let me clean to make sure nothing is wonky [17:31:37 CEST] <nevcairiel> ah no seems like an actual bug [17:31:46 CEST] <nevcairiel> d3d11va was just disabled before [17:32:05 CEST] <wm4> copy&paste error [17:32:21 CEST] <wm4> pushed another fixup for this [17:32:22 CEST] <nevcairiel> AV_CODEC_ID_H264 in there [17:32:26 CEST] <nevcairiel> for vp9 [17:32:28 CEST] <wm4> blerghhdl [17:32:28 CEST] <nevcairiel> :) [17:32:50 CEST] <wm4> ok, pushed another one [17:39:01 CEST] <nevcairiel> does d3d11va output to yuv420p for some reason or is it just not used? [17:39:21 CEST] <nevcairiel> either that or vp9 d3d11va just doesnt work [17:39:38 CEST] <wm4> no, it should output no nv12 [17:39:41 CEST] <wm4> *to [17:42:15 CEST] <nevcairiel> do all the get_format calls need the new d3d11 pix_fmt? [17:42:18 CEST] <nevcairiel> because vp9 didnt get it [17:42:32 CEST] <wm4> they do, and that explains it [17:42:56 CEST] <wm4> I'll add it [17:44:07 CEST] <nevcairiel> works with that added [17:44:10 CEST] <nevcairiel> should be good then [17:44:15 CEST] <wm4> pushed [17:44:54 CEST] <wm4> ok then I'll rebase it to put the fixes into their proper places [17:47:44 CEST] <wm4> pushed to my branch, want to take another look or should I push to the ffmpeg main repo? [17:49:17 CEST] <cone-209> ffmpeg 03James Almer 07master:4d62ee674699: x86inc: don't use read-only data sections on COFF targets [17:53:50 CEST] <wm4> nevcairiel: *prod* [17:55:06 CEST] <nevcairiel> i'll compile it again real quick, but i hope you didnt rebase wrong :) [17:55:33 CEST] <wm4> I hope not... seems like all fixes went into the big commit [18:01:53 CEST] <nevcairiel> wm4: should be good to go [18:06:26 CEST] <wm4> somehow pushing is stuck [18:06:39 CEST] <cone-209> ffmpeg 03wm4 07master:3303511f33dc: lavu: add new D3D11 pixfmt and hwcontext [18:06:40 CEST] <cone-209> ffmpeg 03wm4 07master:865360ba633b: lavc: set avctx->hwaccel before init [18:06:41 CEST] <cone-209> ffmpeg 03wm4 07master:ab28108a3611: dxva: preparations for new hwaccel API [18:06:42 CEST] <cone-209> ffmpeg 03wm4 07master:5659f7404731: dxva: move d3d11 locking/unlocking to functions [18:06:43 CEST] <cone-209> ffmpeg 03wm4 07master:70143a3954e1: dxva: add support for new dxva2 and d3d11 hwaccel APIs [18:06:44 CEST] <cone-209> ffmpeg 03Martin Storsjö 07master:3125a4a8a8fc: d3d11va: Link directly to dxgi.dll and d3d11.dll functions if LoadLibrary is unavailable [18:06:45 CEST] <cone-209> ffmpeg 03wm4 07master:e2afcc33e0bc: dxva: add declarative profile checks [18:06:46 CEST] <cone-209> ffmpeg 03wm4 07master:39f201a0ec79: dxva: fix some warnings [18:06:47 CEST] <cone-209> ffmpeg 03wm4 07master:1509d739a036: hwcontext_d3d11va: fix crash on frames_init failure [18:06:48 CEST] <cone-209> ffmpeg 03wm4 07master:6f5ff3269b12: hwcontext_d3d11va: allocate staging texture lazily [18:06:49 CEST] <cone-209> ffmpeg 03wm4 07master:8d7fdba7b867: dxva: support DXGI_FORMAT_420_OPAQUE decoding [18:06:50 CEST] <cone-209> ffmpeg 03wm4 07master:289d387330d8: hwcontext_d3d11va: add option to enable debug mode [18:06:51 CEST] <cone-209> ffmpeg 03wm4 07master:f0bcedaf37ed: dxva: verbose-log decoder GUID list [18:06:52 CEST] <cone-209> ffmpeg 03Anton Khirnov 07master:d14179e3d49e: hwframe: Allow hwaccel frame allocators to align surface sizes [18:06:55 CEST] <wm4> ah [18:07:55 CEST] <BtbN> Something is weird with the git server for a while. Feels like the push-hooks take forever [18:09:23 CEST] <jamrial> BtbN: yes, it's been like that since the server move [18:29:07 CEST] <durandal_1707> atomnuker: it used lot of cpu, for rgb, but i cannot test old utvideo any more so cant bench it [18:29:38 CEST] <durandal_1707> which is really weird because it worked before [18:30:48 CEST] <durandal_1707> nevcairiel: only obvious thing to simd was thing i did but it didnt improve overall performance a lot [18:31:19 CEST] <nevcairiel> Even pulling is slow from git [18:31:23 CEST] <durandal_1707> and i cannot get perf tools to work at all [18:31:50 CEST] <durandal_1707> dos attack again? [18:33:43 CEST] <jamrial> pulling is fine here [18:34:45 CEST] <durandal_1707> so anyone have perf setup already? [18:35:37 CEST] <ubitux> durandal_1707: what do you need? [18:36:40 CEST] <ubitux> btw, it's nice to have the functions in checkasm for benching [18:37:06 CEST] <durandal_1707> ubitux: get results of utvideo decoding performance for rgb24 format [18:37:20 CEST] <ubitux> can you provide command/sample? [18:37:37 CEST] <durandal_1707> encode with utvideo testsrc2 [18:37:45 CEST] <ubitux> what resolution? [18:37:52 CEST] <durandal_1707> hd1080 [18:41:44 CEST] <ubitux> 98.13% ffmpeg_g ffmpeg_g [.] decode_plane.constprop.6 [18:41:46 CEST] <ubitux> 1.19% ffmpeg_g ffmpeg_g [.] ff_restore_rgb_planes_sse2 [18:43:05 CEST] <ubitux> damnit perf still has this weird offset shift on the instruction time [18:43:37 CEST] <ubitux> http://ubitux.fr/pub/pics/2017-06-27-184312_280x227_scrot.png  the 3 in red are obviously the 3 movdqa [18:44:23 CEST] <ubitux> durandal_1707: anyway, most of the code seems spent on the bitstream reader [18:45:40 CEST] <durandal_1707> yea, need to see if libav bitreader helps here [18:46:09 CEST] <ubitux> s/code/time/ [18:48:32 CEST] <jamrial_> durandal_1707: it might. afaik it helped huffyuv and other lossless decoders [18:49:48 CEST] <ubitux> yeah, it will likely help on x86_64 [18:51:52 CEST] <cone-209> ffmpeg 03James Almer 07master:fa50d9360ba3: x86/vf_blend: add sse and ssse3 extremity functions [18:51:53 CEST] <cone-209> ffmpeg 03James Almer 07master:0daa1cf07318: x86/vf_blend: optimize difference and negation functions [18:54:11 CEST] <jamrial> ubitux: speaking of speed, do you know why the aarch64 stereo interpolate functions are so slow? [18:54:23 CEST] <jamrial> the others you wrote got a decent speed up [18:55:03 CEST] <ubitux> i'm guessing it's hiting the memory bus bottleneck [19:10:02 CEST] <paras_2052> durandal_1707: hi, by metadata you mean the header of the fits image, right ? and i have to export it using the metadata AVDictionary in the AVFrame ? [19:10:37 CEST] <durandal_1707> paras_2052: yes [19:10:56 CEST] <paras_2052> durandal_1707: okay [19:24:19 CEST] <durandal_1707> ugh the avconv is 17% faster in decoding utvideo [19:24:51 CEST] <durandal_1707> 96 vs 116 fps [19:25:22 CEST] <JEEB> wow [19:25:33 CEST] <durandal_1707> atomnuker: have you looked at writing alternative bit reader? [19:26:21 CEST] <atomnuker> it can't be that slow [19:26:27 CEST] <kierank> durandal_1707: LOL [19:26:29 CEST] <kierank> drama [19:26:51 CEST] <durandal_1707> try it [19:27:06 CEST] <atomnuker> kierank: you hypocrite [19:27:32 CEST] <atomnuker> you create the drama by calling it drama in the first place and then you complain about there being drama! [19:27:46 CEST] <kierank> i was referring to previous drama [19:28:53 CEST] <durandal_1707> please no more drama surges [19:29:12 CEST] <kierank> ok [19:30:05 CEST] <atomnuker> durandal_1707: fine, I'll work on that tonight [19:30:31 CEST] <atomnuker> the residual reader for the dirac vlc codes I wrote ought to chew through everything [19:30:57 CEST] <durandal_1707> atomnuker: no need if you dont want :) [19:31:33 CEST] <atomnuker> its not about will its about pride now... 17% [19:32:39 CEST] <wm4> at this rate there will be more a few more forks before we can reunify with Libav [19:33:27 CEST] <atomnuker> >implying its even possible [19:35:29 CEST] <durandal_1707> yuv420p is even worse its 90 vs 120 or 25% [19:35:46 CEST] <durandal_1707> guess my simd helped lot [19:36:41 CEST] <durandal_1707> that or avconv is making numbers up [19:37:51 CEST] <durandal_1707> michaelni: improve bitreader and we can keep both prores encoders and decoders :) [19:38:33 CEST] <jamrial> durandal_1707: shouldn't be hard to just drop the bitstream reader header in our tree, cherry pick the utvideo bitstream reader port commit and see if that's what made it faster [19:39:18 CEST] <jamrial> no pls, just one of each [19:47:20 CEST] <wm4> we should write a new h264 decoder to encourage healthy competition [19:52:52 CEST] <durandal_1707> ffmpegs hevc is much faster than libavs [19:53:07 CEST] <ubitux> we have some missing simd though [19:53:13 CEST] <kierank> vp9 as well [19:53:53 CEST] <JEEB> ubitux: someone should just gcc -S that stuff and do the x264inc dance :D [19:54:28 CEST] <JEEB> HEVC is so far relatively low on my priority list so I haven't gotten to doing that [19:54:40 CEST] <JEEB> esp. since the intrinsics patches do still apply [19:54:48 CEST] <JEEB> which for local usage is "enough" [19:54:50 CEST] <ubitux> it's been years i hear about this "someone" guy that is going to save us all :( [19:54:58 CEST] <JEEB> yes :< [19:55:07 CEST] <JEEB> he is so busy we haven't seen him in years [20:05:03 CEST] <J_Darnley> Okay. I've got an big question regarding avcodec. [20:05:48 CEST] <J_Darnley> Does it already have the ability to encode a slice (part of a frame) without the whole frame being available? [20:06:02 CEST] <atomnuker> nope [20:06:25 CEST] <atomnuker> I thought you knew you had to take the encoder out of lavc [20:06:57 CEST] <durandal_1707> jamrial: stole libav bitstream and got 146 fps prev was 96 [20:07:28 CEST] <jamrial> haha [20:07:37 CEST] <durandal_1707> so its even faster than libav [20:07:54 CEST] <jamrial> yeah, the new bitstream is good with lossless video, at least on x86_64 [20:08:21 CEST] <jamrial> problem was with audio codecs, which was slower in some cases. i think ac3 and aac [20:08:54 CEST] <J_Darnley> atomnuker: I think I will have to [20:09:25 CEST] <J_Darnley> That might be slightly easier than trying to extend avcodec like that. [20:10:38 CEST] <kierank> J_Darnley: don't worry about the avcodec problems for now [20:10:41 CEST] <jamrial> durandal_1707: test x86_32 as well [20:10:54 CEST] <durandal_1707> jamrial: cant [20:11:17 CEST] <kierank> J_Darnley: being able to encode slice by slice (and not doing the transform on the entire image) is a big goal in itself [20:11:31 CEST] <J_Darnley> kierank: well as far as I can tell because sliced threading exists what you want already exists. [20:11:38 CEST] <durandal_1707> kierank: are you gonna use rust-av? [20:11:42 CEST] <kierank> J_Darnley: no, that's not quite [20:11:49 CEST] <kierank> J_Darnley: the transform is still run on the entire frame [20:11:53 CEST] <kierank> and then the slices are encoded iirc [20:12:00 CEST] Action: J_Darnley looks again [20:12:41 CEST] <kierank> J_Darnley: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vc2enc.c;h=96e27d... [20:12:47 CEST] <kierank> yeah the plane is transformed [20:13:04 CEST] <kierank> might also end up being faster doing the transform per-slice because the data is in cache [20:13:10 CEST] <J_Darnley> you are quite right there [20:14:58 CEST] <kierank> there are also various papers on vc-2 [20:16:29 CEST] <kierank> also https://github.com/bbc/vc2-reference [20:16:38 CEST] <kierank> https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwi0q62K0d7UAhUsLsAKHd0XBeIQFgguMAE&url=http%3A%2F%2Fdownloads.bbc.co.uk%2Frd%2Fpubs%2Fwhp%2Fwhp-pdf-files%2FWHP238.pdf&usg=AFQjCNE0PXYhr0xwxgaK5_gRPipsa0Dp2g [20:16:45 CEST] <kierank> http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP238.pdf [20:16:48 CEST] <kierank> http://downloads.bbc.co.uk/rd/pubs/whp/whp-pdf-files/WHP159.pdf [20:16:50 CEST] <kierank> and those [20:17:21 CEST] <kierank> J_Darnley: try implementing haar on a slice, atomnuker will agree it's the simplest [20:17:24 CEST] <kierank> and easiest to get working [20:19:39 CEST] <kierank> J_Darnley: or you can perhaps try it on the decode [20:19:39 CEST] <kierank> https://github.com/atomnuker/ffmpeg_dirac_trimmed [20:19:51 CEST] <kierank> forget about the ffmpeg mainline decoder it has a ton of legacy stuff [20:20:53 CEST] <kierank> atomnuker: decoder is easier, right? [20:20:53 CEST] <tmatth> kierank: did you ever stream vc-2 over RTP or other? [20:20:59 CEST] <kierank> tmatth: no but that's the goal [20:21:20 CEST] <tmatth> kierank: nice, in upipe or some other repo? [20:21:37 CEST] <kierank> dunno tbh, none of the OSS frameworks are designed for super low latency [20:21:44 CEST] <kierank> so we might have to hack something in upipe [20:21:54 CEST] <kierank> by low latency I mean encoding slices before the frame has arrived [20:24:05 CEST] <atomnuker> not sure about the decoder, I think it'll take more work to start from the decoder [20:24:29 CEST] <kierank> atomnuker: are you sure not doing valid decoding slice by slice will be easier? [20:24:33 CEST] <atomnuker> for a starting point just do the transforms first on both the decoder and encoder on a per-slice basis [20:24:45 CEST] <kierank> well for a decoder you know you'll be right [20:25:08 CEST] <atomnuker> then rip both up and modify them to write the actual bitstreams on a per slice basis [20:25:12 CEST] <kierank> atomnuker: i never really understood how to handle the cases with large transforms and small slices but perhaps you may be able to help [20:27:25 CEST] <kierank> ah there are edge extension rules [21:00:11 CEST] <gh0st__> Does anyone have a machine with a cpu that has avx-512 instruction set to test avx-512 assembly code on it? [21:05:39 CEST] <Compn> a few devs have one iirc [21:05:52 CEST] <Compn> there might even be one setup for people to test on... [21:06:11 CEST] <Compn> i asked the intel guy to give us some chips to do tests and dev on hehe [21:06:15 CEST] <Compn> didnt get a reply tho [21:08:15 CEST] <BtbN> Isn't that pretty much limited to Xeon Phi right now? [21:09:01 CEST] <jamrial> no, skl-x is out [21:38:59 CEST] <Gramner> skl-x is released since yesterday, but motherboards in particular seems hard to come by [21:44:20 CEST] <Gramner> skl-x has avx-512{f, cd, bw, dq, vl} extensions, so everything you need for multimedia stuff [21:46:21 CEST] <gh0st__> Cool [22:09:21 CEST] <Compn> user talking about sample wav file with 32 channels [22:09:28 CEST] <Compn> can we up the max_channels limit ? [22:09:44 CEST] <Compn> michaelni ? [22:11:21 CEST] <cone-161> ffmpeg 03Ilia Valiakhmetov 07master:35a5d9715dd8: avcodec/vp9: add 64-bit ipred_dr_32x32_16 avx2 implementation [22:25:07 CEST] <michaelni> Compn, which limit where ? there are alot of MAX_CHANNELS and variants in the codebase [22:27:01 CEST] <Compn> hmm [22:27:48 CEST] <Compn> "Invalid sample rate or channel count!" [22:28:19 CEST] <Compn> weird, https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2011-June/037929.html [22:28:37 CEST] <Compn> michaelni : i've asked for sample, maybe will be uploaded tomorrow [22:28:38 CEST] <nevcairiel> wav files cant really represent 32 channel properly, since its channel layout gives up at that point [22:29:27 CEST] <Compn> yeah i dont think its for playback , with channel layouts [22:29:35 CEST] <Compn> more for production music work [22:29:42 CEST] <Compn> or voice tracks [22:54:31 CEST] <durandal_1707> michaelni: ffmpeg with libav bitreader still beats your patchset, so new bitreader is still to go [22:56:41 CEST] <nevcairiel> the differences in the bitstream readers are extremely dependent on your compiler [23:08:04 CEST] <durandal_1707> nevcairiel: really? try it with your compilers [23:22:54 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:2c874548d663: avcodec/hevcdec: do basic validity check on delta_chroma_weight and offset [23:22:55 CEST] <cone-161> ffmpeg 03Michael Niedermayer 07master:c578c9c229f0: libswresample/swresample: remove obsolete code [00:00:00 CEST] --- Wed Jun 28 2017