[Ffmpeg-devel-irc] ffmpeg-devel.log.20170627

[burek]

[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=96e27d93ede2d905721edc68252ce5313cfef949;hb=HEAD#l953
[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