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

[burek]

[00:01:10 CET] <cone-833> ffmpeg 03Carl Eugen Hoyos 07master:e7fe5e511aae: lavf/dashdec: Fix several memleaks.
[00:01:44 CET] <durandal_1707> memory leaks, it is
[00:03:03 CET] <cone-833> ffmpeg 03Steven Liu 07master:1b323c3f9c89: avformat/dashdec: use the current DASHContext for the rep_dest
[00:53:47 CET] <cone-833> ffmpeg 03Gyan Doshi 07master:84556ef05963: lavu/timecode: clarify error msg for timecode_rate
[00:53:48 CET] <cone-833> ffmpeg 03Jun Zhao 07master:2c6b0315d9cd: lavc/libkvazaar: switch to ff_alloc_packet2.
[00:53:49 CET] <cone-833> ffmpeg 03Jun Zhao 07master:dd435c957aa4: lavc/libx265: switch to ff_alloc_packet2
[03:35:56 CET] <SortaCore> okay, it seems to be throwing a null access error when I try to flush h264_qsv
[03:38:24 CET] <SortaCore> avcodec_send_packet, pass a null packet to flush, then after use avcodec_receive_frame to get the ending frames
[03:38:30 CET] <SortaCore> but avcodec_receive_frame is crashing
[03:44:34 CET] <SortaCore> av_assert0(!frame->buf[0]); accesses the null frame
[03:55:28 CET] <SortaCore> it's inside decode_receive_frame_internal, any suggestions folks
[07:26:36 CET] <marsrover> wow, this stuff with wm4 recently has sure turned him into a pms'ing little tart
[14:11:16 CET] <kierank> michaelni: do you have a list of h264 ER TODO anywhere?
[14:13:17 CET] <michaelni> kierank, no, why do you ask ?
[14:16:45 CET] <michaelni> actually maybe i did had a list, but iam not sure where
[14:26:15 CET] <michaelni> there are some "todo/fixme" comments in the code (grep -i fixme libavcodec/error_resilience.c) though
[14:27:59 CET] <kierank> Thinking of stuff for J_Darnley to do
[15:12:38 CET] <michaelni> ill think about it and will post a mail with ideas to ffmpeg-devel
[15:16:54 CET] <kierank> but overall the ER is much better than hardware decoders
[15:20:26 CET] <nevcairiel> I agree, its pretty good
[15:22:47 CET] <kierank> we should maybe do a side by side comparison
[15:59:27 CET] <gnafu> kierank, michaelni: Does ER="error resilience" or something like that?
[15:59:31 CET] <kierank> yes
[15:59:45 CET] <gnafu> Aah, okay.  I wasn'
[16:00:04 CET] <gnafu> t familiar, so it took me a moment to figure out why a software decoder would be better than a hardware decoder.
[16:00:18 CET] <gnafu> (I mean, I can imagine other reasons.)
[16:01:12 CET] <gnafu> But normally, I would expect a hardware decoder to either decode correctly or incorrectly, making it either as good as a software decoder or a non-option.  Error correction I can understand being "good enough" in a hardware solution where a software solution could do it better.
[16:18:06 CET] <BtbN> holy shit configure on cygwin takes over 10 minutes now
[16:19:07 CET] <jamrial> what windows version?
[16:19:11 CET] <BtbN> 10
[16:20:24 CET] <jamrial> falls creator build? because for me it went from about one or two to thirteen minutes after i upgraded to that build
[16:21:05 CET] <jamrial> and fate runs slower with four jobs
[16:21:10 CET] <BtbN> yes, latest update
[16:21:36 CET] <BtbN> Maybe they updated internals and cygwin now fails to use the non-public fork API
[16:21:56 CET] <jamrial> i'm using msys2, but yes, microsoft changed something
[16:22:14 CET] <jamrial> configure spawns bash a billion times for the last several minutes, when it's figuring out module dependencies
[16:23:24 CET] <jamrial> i keep procrastinating installing WSL
[16:26:26 CET] <JEEB> there's even a command line for it now :)
[16:27:39 CET] <JEEB> https://msdn.microsoft.com/en-us/commandline/wsl/install-on-server
[16:30:22 CET] <BtbN> atomnuker, michaelni comments on this wording? https://github.com/BtbN/FFmpeg/commit/8e895ad403d56cc0d237d338d43850b4a44cda80.patch
[16:31:56 CET] <sfan5> you misspelt wrapping
[16:31:57 CET] <BtbN> jamrial, https://github.com/BtbN/FFmpeg/commits/master updated the latest patchset for the FrameData cuvid preparation that was sent to ffmpeg-devel
[16:32:52 CET] <BtbN> where? oO
[16:33:22 CET] <BtbN> Oh, in the commit message. Well, technically that wasn't me :P
[16:34:18 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/0169232e25c56efc36775d60b8dd8ddfd01d561a.patch
[16:34:32 CET] <atomnuker> BtbN: "FFmpeg libs will never check..." -> "FFmpeg libs should not check..."
[16:34:56 CET] <BtbN> That sounds so pessimistic
[16:35:18 CET] <atomnuker> BtbN: will never sounds weird in the context of an API user
[16:35:46 CET] <BtbN> It's meant for ffmpeg devs, to tell them they don't need to care about the field in that way
[16:35:55 CET] <BtbN> Or check for the user having done modifications
[16:36:26 CET] <atomnuker> okay, then put "For project devs:" just before it
[16:36:33 CET] <atomnuker> *above it
[16:37:32 CET] <jamrial> have we ever written a function/field doxy stating a line is "for devs"?
[16:38:05 CET] <jamrial> BtbN: thanks for adapting the set!
[16:38:20 CET] <BtbN> jamrial, I'm a bit unsure about the https://github.com/BtbN/FFmpeg/commit/8c4b1d8a65e0e40e71dfb4e80f47d80fb21b815e.patch
[16:38:44 CET] <BtbN> The wrapping in draw_horiz_band is unneccesary in ffmpeg now, as there is no need to unwrap the opaque_ref
[16:39:01 CET] <BtbN> But it creates quite a diff to libav in various decoders to not merge that part
[16:39:53 CET] <jamrial> shouldn't we at least make private_ref NULL before calling draw_horizontal_band, since it's passing the frame to the user?
[16:40:12 CET] <BtbN> It's not changing frame ownership, and the user is not supposed to care about that field in any way
[16:40:36 CET] <jamrial> alright
[16:40:44 CET] <nevcairiel> private_ref really shouldnt have that wrapping shit though
[16:40:57 CET] <nevcairiel> which is still in the patch above
[16:41:00 CET] <jamrial> in any case, libav is not taking any measures with draw_horizontal_band afaik
[16:41:12 CET] <jamrial> that was something wm4 wrote for the ffmpeg version of the set
[16:41:14 CET] <BtbN> oh right, wm4 added that
[16:41:22 CET] <BtbN> yeah, that should be good then
[16:41:44 CET] <BtbN> nevcairiel, what about wrapped decoders and stuff like that? Where you potentially chain them?
[16:41:55 CET] <nevcairiel> thats not something that exists
[16:41:59 CET] <BtbN> yet
[16:42:01 CET] <nevcairiel> so stop caring for a case that doesnt exist
[16:42:20 CET] <nevcairiel> and even if one were to wrap, just do it with public API, and there is nothing to worry about
[16:42:32 CET] <BtbN> public API?
[16:43:41 CET] <nevcairiel> its a giant rabbit hole to start designing stuff for theoretical cases that one might envision at some point in the future. If a need for a change arises, just do it then. Its internal/private api, no api/abi rules that would block any changes
[16:45:32 CET] <nevcairiel> otherwise the same arguments for the wrapping can probably even be applied to the internal field, the entire point of that was to get rid of that weird mechanic
[16:52:48 CET] <BtbN> nevcairiel, so in that case, if ff_attach_decode_data finds it being already present, should it free it and create a new one, do nothing and return, or throw an error?
[16:53:03 CET] <nevcairiel> free it, probably
[16:53:48 CET] <nevcairiel> it likely should never happen, but in case it was forgotten to be free'ed somewhere, best to just clean up and continue with your live
[16:54:12 CET] <BtbN> Could probably add an assert1 or something in front of the free
[16:57:33 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/9f1cfd88af88a7d7d5c56a368a46639dfdfdef75#diff-ea4f4194be6309231a5b01e350c272cdR1577 something like this
[16:58:54 CET] <jamrial> that assert would make the unref after it superfluous
[16:59:09 CET] <BtbN> not on assert level 0
[16:59:24 CET] <jamrial> fair enough
[17:00:28 CET] <BtbN> no idea if we care about memleaks that are not supposed to be there
[17:00:35 CET] <jamrial> empty FrameDecodeData struct?
[17:00:48 CET] <jamrial> how does malloc behave with that?
[17:01:04 CET] <BtbN> Well, the only thing that was originally in there is gone
[17:01:37 CET] <BtbN> No idea, I did not test-compile the individual commit
[17:01:39 CET] <BtbN> But iirc it's valid
[17:07:35 CET] <jamrial> BtbN: thanks a lot
[17:08:29 CET] <jamrial> after this comes the libav cuvid hwaccel using this framework. i think you suggested to call it nvdec instead since we already have one called cuvid?
[17:08:59 CET] <jamrial> or maybe it can replace the existing one
[17:10:34 CET] <jamrial> wm4 called it "cuvid_hwaccel" in his tree to avoid the name collision, which is ugly :p
[17:33:32 CET] <michaelni> BtbN, doxy text LGTM
[17:55:06 CET] <MercadesBendz> hey guys im not sure who to turn to cause iv had no luck so far but https://pastebin.com/tjNagBUt is my issue and i need some help so i can finaly move fowrad in building this program (vegastrike)
[18:05:08 CET] <J_Darnley> kierank, Gramner, jamrial, Martin Vignali (if you're here): https://blog.cloudflare.com/on-the-dangers-of-intels-frequency-scaling/
[18:06:35 CET] <atomnuker> I do simd too!
[18:06:51 CET] <J_Darnley> oh, sorry about that
[18:07:21 CET] <Gramner> the budget xeons suck badly at avx-512. not only do they not have the p5 alu enabled, the frequency drop is crazy on some low-end models
[18:07:42 CET] <nevcairiel> define crazy
[18:07:48 CET] <Gramner> it's like 50% freq. drop on some model iirc
[18:08:13 CET] <nevcairiel> my 7900 has the p5 port, and it also loses about a ghz, although thats more in the area of 20-25%
[18:08:14 CET] <J_Darnley> In the linked case: 1 core running avx512 will drop 2.1 to 1.8
[18:08:45 CET] <jamrial> 50%? and here i thoguht my haswell dropping about 100mhz in multithreaded loads was bad
[18:09:34 CET] <nevcairiel> obviously a manually overclocked 7900 is quite a different beast then some stock xeons
[18:09:56 CET] <kierank> Gramner: how do you define budget xeon?
[18:10:55 CET] <Gramner> silver/bronze
[18:11:51 CET] <kierank> wow ok
[18:12:23 CET] <Gramner> the avx offset is different for every model as well, have fun trying to optimize that
[18:14:13 CET] <J_Darnley> Damn that's a painful drop --> https://en.wikichip.org/wiki/intel/xeon_silver/4116#Frequencies
[18:14:37 CET] <Gramner> 3GHz -> 1.8GHz :D
[18:15:08 CET] <kierank> :( we use 4114 currnetly
[18:15:38 CET] <Gramner> we're going to need more die shrinks
[18:17:31 CET] <kierank> gold is bad too https://en.wikichip.org/wiki/intel/xeon_gold/5120
[18:17:45 CET] <Gramner> the 8180 (top-of-the-line model) in comparison goes 3.8GHz -> 3.5GHz (single core)
[18:18:13 CET] <Gramner> 3.2 > 2.3 with 28 cores active though
[18:18:52 CET] <nevcairiel> if you can make use of all t hat, thats still a whole lot of flops tho
[18:19:51 CET] <BtbN> jamrial, yes, I'd like to go for a full rename and call the new native hwaccel nvdec
[18:19:56 CET] <Gramner> yeah, if you can just crunch tons of numbers while utilizing zmm regs constantly it's amazing
[18:20:11 CET] <BtbN> Because I kind of planned to rename the original cuvid for a while, and to avoid confusion
[18:20:54 CET] <Gramner> but it really really really needs to be more fine grained thermal throttling instead of a huge instant binary penalty
[18:21:10 CET] <nevcairiel> its not only that
[18:21:15 CET] <nevcairiel> the power consumption goes through the roof
[18:22:03 CET] <nevcairiel> my 7900 would just basically lock up when the clock was too high, instantly
[18:22:21 CET] <nevcairiel> presumably because it needs more power then it wants to deliver
[18:23:25 CET] <Gramner> I'm curious to see how much the reduced transistor capacitance of 10nm will help
[18:44:22 CET] <kierank> Gramner: how much avx512 can you run before it downclocks
[18:44:47 CET] <Gramner> one instruction
[18:45:11 CET] <J_Darnley> Wow it is just one
[18:45:58 CET] <Gramner> try adding a random vpxor zmm0, zmm0 somewhere and watch overall perf drop like a stone
[18:46:30 CET] <Gramner> vpxord*
[18:59:26 CET] <tmm1> anyone know if there's something like h264bitstream/h264analyze for hevc (to view all the NALU in a hevc bitstream)
[19:00:23 CET] <JEEB> I thought the patch set contained HEVC and MPEG-2 Video versions?
[19:05:14 CET] <tmm1> which patch set?
[19:05:26 CET] <kierank> Gramner: do you think any of the v210 and similar functions could benefit from the new blend stuff?
[19:06:08 CET] <jamrial> tmm1: use the trace_headers bsf
[19:07:08 CET] <jamrial> or if you want something with a gui, maybe hevcesbrowser
[19:07:08 CET] <Gramner> i'd guess just packing or unpackning v210 by itself is probably bottlenecked by memory bandwidth in decent simd implementations
[19:07:52 CET] <kierank> hmm true, they are all very fast now
[19:07:59 CET] <kierank> so fast as to be negligible for us
[19:08:15 CET] <kierank> well not negligible but 5-10x faster
[19:10:55 CET] <kierank> Gramner: does anything come to mind in h264dec then?
[19:13:19 CET] <Gramner> I'm a bit doubtful that H.264 decoding can be sped up overall by AVX-512 in it's current state
[19:15:09 CET] <kierank> bit of a damp squib
[19:16:23 CET] <Gramner> from x264 btw: plane_copy_deinterleave_v210_avx2: 2821, plane_copy_deinterleave_v210_avx512: 1789
[19:16:48 CET] <Gramner> but avx-512 is disabled in 10-bit mode because I haven't gotten around to writing enough asm for it
[19:18:51 CET] <kierank> is that avx512 zmm or just blend?
[19:18:57 CET] <Gramner> zmm
[19:19:17 CET] <tmm1> jamrial: thank you
[19:20:44 CET] <Gramner> it doesn't even use any opmasks though. just shifts and 2-table permutes
[19:21:40 CET] <Gramner> and the latter is slow on skl-x anyway with 16-bit values
[19:29:32 CET] <jamrial> BtbN: want ot push the set, or should i apply them as part of the merge for the corresponding commits?
[19:29:49 CET] <BtbN> jamrial, I can just push it if it's ok in that state now?
[19:30:05 CET] <BtbN> Want to run fate on it right now
[19:30:46 CET] <jamrial> i ran fate with only patches 1 and 2 to make sure having the struct empty was fine, and it passed
[19:31:11 CET] <BtbN> I think it's implementation defined
[19:32:29 CET] <jamrial> malloc(0) is valid, but yeah, seems to be implementation defined
[19:42:35 CET] <BtbN> jamrial, yeah, it passes just fine. So, should I push it?
[19:43:24 CET] <jamrial> yeah
[19:44:51 CET] <jamrial> i'll merge-rename the cuvid stuff after this and push it to github first so you can look at it and test it since i lack the hardware
[19:45:25 CET] <BtbN> It was on the ml already as well
[19:45:45 CET] <BtbN> So you can probably find the adapted patches there. Not sure if they where already renamed
[19:45:57 CET] <BtbN> Cause they need quite some work
[19:46:02 CET] <BtbN> which wm4 already did
[19:46:22 CET] <BtbN> Because libav does not dynload cuda/cuvid, and we do
[19:46:48 CET] <jamrial> oh right, wm4's first set included the cuvid patches as well
[19:47:12 CET] <MercadesBendz> hey i need help compiling a programe vegastrike and it keeps getting stuck on ffmpeg during build
[19:47:23 CET] <jamrial> want to push them yourself, then? i see you and philipl lgtm'd them
[19:47:40 CET] <MercadesBendz> no one has been willing to help me so im hoping this channel would
[19:47:54 CET] <jamrial> although you need to rename them from cuvid_hwaccel to nvdec
[19:48:37 CET] <cone-305> ffmpeg 03Michael Niedermayer 07master:1fa3a9a31de1: avutil/frame: Add private_ref to AVFrame
[19:48:37 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:9f1cfd88af88: decode: add a method for attaching lavc-internal data to frames
[19:48:37 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:7fa64514c8d2: decode: add a mechanism for performing delayed processing on the decoded frames
[19:48:37 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:81c021c6a2d7: decode: add a per-frame private data for hwaccel use
[19:48:59 CET] <BtbN> I need to find them first
[19:49:16 CET] <BtbN> patchwork does not seem to have picked them up
[19:49:36 CET] <BtbN> It's broken anyway somehow
[19:49:57 CET] <BtbN> Can probably grab them from wm4s ffmpeg fork
[19:50:19 CET] <jamrial> BBB: https://patchwork.ffmpeg.org/patch/5394/ https://patchwork.ffmpeg.org/patch/5392/
[19:50:23 CET] <jamrial> err, BtbN
[19:50:26 CET] <jamrial> sorry
[19:51:03 CET] <MercadesBendz> i have a pastebin of the errors here: https://pastebin.com/tjNagBUt
[19:51:35 CET] <BBB> np
[19:52:48 CET] <jamrial> BtbN: but yeah, probably best to grab them from wm4's repo and replace the usage of opaque_ref
[19:52:58 CET] <BtbN> It does not even touch that
[19:53:06 CET] <BtbN> It should just use the new struct
[19:53:51 CET] <jamrial> it does touch it
[19:54:05 CET] <BtbN> oh, indeed. Needs to get the data from somewhere
[19:55:13 CET] <J_Darnley> MercadesBendz: 1-this is the wrong channel 2-what is ambiguous about this message? "src/gfx/vid_file.cpp:271:48: error: too few arguments to function int avcodec_send_frame(AVCodecContext*, const AVFrame*)"
[19:55:48 CET] <MercadesBendz> i dont know y there are too few arguments
[19:55:55 CET] <MercadesBendz> and where the missing ones are
[19:56:01 CET] <MercadesBendz> or what they are
[19:56:07 CET] <MercadesBendz> or how to find them
[19:56:28 CET] <jamrial> that means that whatever you're trying to compile is broken, and you should report it to them
[19:56:30 CET] <J_Darnley> Whyare there too few?  Because you aren't giving any arguments: "pFrameRGB         = avcodec_send_frame();"
[19:56:52 CET] <MercadesBendz> i have asked the #ffmpeg channel and no one is talking to me
[19:57:17 CET] <jamrial> no, it's not ffmpeg. it's whatever you're trying to compile that uses ffmpeg
[19:57:43 CET] <MercadesBendz> i was hoping that it might have something to do with ffmpeg
[19:57:59 CET] <MercadesBendz> cause im running out of places to ask
[19:58:10 CET] <MercadesBendz> no one ever answs me
[19:58:30 CET] <MercadesBendz> its like im invisable
[19:58:58 CET] <BtbN> jamrial, I'm a bit worried about wm4 stating that "this is actually completely broken" in a mail, but never followed up to it
[20:00:24 CET] <BtbN> Oh, I see the fix
[20:00:36 CET] <BtbN> avctx->codec->priv_class instead of avctx->av_class
[20:00:40 CET] <jamrial> MercadesBendz: whatever that src/gfx/vid_file.cpp file belongs to is misusing ffmpeg, which is why it fails to compile
[20:00:55 CET] <jamrial> there's not much you can do other than report the problem to whoever wrote that file
[20:01:19 CET] <MercadesBendz> man
[20:01:39 CET] <MercadesBendz> color me puzzled then cause it installs in fedora just fine
[20:02:00 CET] <MercadesBendz> idk y im having such issues with antergos
[20:02:50 CET] <MercadesBendz> i mean the guy gave me a list of patches for vegastrike but this error isnt one of them
[20:03:53 CET] <jamrial> antergos seems to be a distro that ships the latest version of everything, whereas fedora ships old stuff, so perhaps this file compiles fine with old packages but shits itself with new ones, as the above error shows
[20:04:00 CET] <MercadesBendz> ok well thanks anyways its an answ that i didnt have b4
[20:04:15 CET] <MercadesBendz> good point
[20:04:25 CET] <MercadesBendz> i didnt think abt that 
[20:04:56 CET] <MercadesBendz> but aur has it and it wont work even then
[20:05:45 CET] <MercadesBendz> perhaps if i created a vm of fedora and installed it on that?
[20:07:06 CET] <J_Darnley> Jesus christ.  The AUR PKG build tries to get a 3 year old versin of the source
[20:07:26 CET] <J_Darnley> If I remember my SVN command correctly
[20:07:45 CET] <MercadesBendz> that old? wow well i dk that
[20:08:28 CET] <MercadesBendz> i had to pretty much creat my own packebuild file just to get this far
[20:08:34 CET] <J_Darnley> There have been a rather meagre 250 commits since then.
[20:09:35 CET] <MercadesBendz> i wonder y cause its not like vegastrike is a ghost game in popularity... as far as ik anyhow
[20:10:17 CET] <J_Darnley> If it is finished I guess it doesn't take much maintainance to keep up with library changes.
[20:11:04 CET] <MercadesBendz> well from everything iv found the new ffmpeg has really messed alot of things up
[20:12:15 CET] <MercadesBendz> okay then i guess ill take my problem to the vegastrike forum, but in the mean time i hope it will work on a fedora vm
[20:12:41 CET] <J_Darnley> This piece of code probably never worked. "avcodec_send_frame()"
[20:12:42 CET] <MercadesBendz> its better then nothing i guess
[20:13:15 CET] <MercadesBendz> well i had to change it from avcodec_alloc_frame() i blv
[20:13:55 CET] <MercadesBendz> at least that was what the compiler suggested cause it said avcodec_alloc_frame didnt exist
[20:14:07 CET] <JEEB> how the hell did that compile
[20:14:10 CET] <JEEB> lol
[20:14:20 CET] <BtbN> h264_cuvid_hwaccel_hwaccel_deps="cuda cuvid_hwaccel" yeah... no
[20:15:12 CET] <MercadesBendz> also had to change avcodec_open to avcodec_open2
[20:15:43 CET] <MercadesBendz> but with the errors im getting now i dont know enuf abt doing this to figure out
[20:16:06 CET] <JEEB> also I recommend using "site:www.ffmpeg.org/doxygen/trunk/ THING" as the latest documentation is there
[20:16:12 CET] <JEEB> like for example https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[20:16:15 CET] <JEEB> :P
[20:16:20 CET] <MercadesBendz> me?
[20:16:23 CET] <J_Darnley> My suggestion is to use the newest version available of the vegastrike code
[20:16:34 CET] <MercadesBendz> that is the newest version
[20:17:03 CET] <MercadesBendz> i downloaded the code off of the link that the vegastrike site gave me
[20:17:07 CET] <JEEB> yea games usually die after they are "done" so unless you want to work to make it work with non-ancient APIs (yes, those are pretty darn ancient by now)
[20:17:24 CET] <JEEB> you might just want to link your game to some special FFmpeg libraries in its own prefix :P
[20:17:26 CET] <MercadesBendz> wow bummer
[20:17:39 CET] <MercadesBendz> oh cool idea
[20:17:40 CET] <MercadesBendz> how
[20:17:53 CET] Action: J_Darnley goes to grab the source
[20:18:12 CET] <JEEB> --prefix=/some/other/prefix in FFmpeg's configure and then use PKG_CONFIG_PATH=/your/prefix/lib/pkgconfig to make the other build system find that custom FFmpeg
[20:18:33 CET] <JEEB> because if you are not a developer you don't really care about porting the game's media stuff :P
[20:18:44 CET] <MercadesBendz> svn co --ignore-externals https://vegastrike.svn.sourceforge.net/svnroot/vegastrike/trunk/vegastrike vegastrike is where i got the code
[20:18:58 CET] <JEEB> although porting it to the new APIs would be nice, of course.
[20:19:06 CET] <MercadesBendz> ffmpeg's configure?
[20:19:12 CET] <MercadesBendz> i installed using pacman
[20:19:14 CET] <JEEB> ok, if you don't know what that is just stop there
[20:19:40 CET] <JEEB> better to ask someone else to build it against older FFmpeg within the package, or have that person update the API usage
[20:19:53 CET] <MercadesBendz> my include folder has something called ffmpeg2.8
[20:20:54 CET] <MercadesBendz> would --with-ffmpeg=system work? in the game configure?
[20:21:08 CET] <MercadesBendz> cause i had to do that with boost
[20:24:35 CET] <MercadesBendz> okay well i appreciate all u guys's help with this
[20:25:36 CET] <MercadesBendz> my ideas didnt work (not surprised) so ill just try to install this on a fedora vm until i can sort this out on the vegastrike forums
[20:26:39 CET] <MercadesBendz> cause i cant use fedora on my computer system installed cause my wireless card is unsupported and i cant fix it there which is y im using antergos now
[20:27:42 CET] <MercadesBendz> im sry abt this off topic issue but no one lse anywhere was willing to help
[20:28:54 CET] <JEEB> MercadesBendz: you shouldn't have left that channel and just asked your question
[20:29:00 CET] <JEEB> metaquestions generally do not get answered
[20:29:11 CET] <MercadesBendz> i didnt
[20:29:15 CET] <MercadesBendz> leave that is
[20:29:27 CET] <JEEB> -!- MercadesBendz [~dcarr at 2601:880:c100:1ded::ee90] has left #ffmpeg
[20:29:32 CET] <MercadesBendz> i mean i did now
[20:30:10 CET] <JEEB> you were there from 20:43 and left around 21:06
[20:30:12 CET] <MercadesBendz> but thats because im giving up the ghost here and instead will persue the issue on the vegastrike forums
[20:30:28 CET] <JEEB> and your only line was "is anyone home?"
[20:30:38 CET] <MercadesBendz> um
[20:30:43 CET] <JEEB> nobody on IRC is nice enough to say "yes, just ask your question"
[20:30:49 CET] <JEEB> you will instead get ignored, for better or worse
[20:30:58 CET] <MercadesBendz> well when i first joined i asked my question directly
[20:31:14 CET] <JEEB> yes, I scrolled up in my backlog and you noted some things
[20:31:34 CET] <MercadesBendz> then no one answered i had lunch and came back
[20:31:37 CET] <JEEB> anyways, #ffmpeg does offer help but you just have to have patience
[20:31:48 CET] <JEEB> but yea, better poke the game's community if it's still alive
[20:31:49 CET] <JEEB> :)
[20:32:15 CET] <MercadesBendz> yeah well i talked to a maintaner by chance yesterday i think
[20:32:25 CET] <MercadesBendz> but i cant find him anymore
[20:32:43 CET] <MercadesBendz> or at least i think he was a maintainer
[20:33:26 CET] Action: J_Darnley gives up
[20:33:27 CET] <MercadesBendz> but anyhow i have been completly ignored in most channels i join for help so i was getting really fusterated
[20:33:30 CET] <J_Darnley> stupid boost shit
[20:33:45 CET] <JEEB> J_Darnley: now try something using depot_tools
[20:33:50 CET] <MercadesBendz> yep  thats y i had to use 
[20:33:58 CET] <MercadesBendz> --with-boost=system
[20:34:08 CET] <MercadesBendz> in the ./configure line
[20:34:11 CET] <JEEB> ("your clang binary doesn't find random system libraries that GOOG decided not to distro" called)
[20:35:40 CET] <MercadesBendz> i would offer you my packagebuild file but it uses other files that i cant give unless i upload them
[20:36:32 CET] <MercadesBendz> its almost become a vendeta but i have to put it on hold until i get some answs from the vegastrike community
[20:38:01 CET] <BtbN> jamrial, a quick review for stupid mistakes is welcome. Doing a test build, fate, and some manual tests with that hwaccel now: https://github.com/BtbN/FFmpeg/commits/master
[20:40:09 CET] <MercadesBendz> well gb folks and thx again for all ur help
[20:44:42 CET] <jamrial> BtbN: you're using opaque_ref
[20:44:53 CET] <BtbN> Yeah, just pushed a fix for that
[20:45:07 CET] <jamrial> ah ok, let me fetch it
[20:53:44 CET] <BtbN> jamrial, it compiles and does not crash. But it also does not seem to be doing stuff
[20:54:21 CET] <jamrial> as in, hwacell stuff?
[20:54:25 CET] <BtbN> yeah
[20:54:36 CET] <BtbN> Not sure how to convince ffmpeg.c on how to use it
[20:55:30 CET] <jamrial> -hwaccel nvdec maybe? i'm not sure this set actually bothered to get ffmpeg.c working with it or just made sure it worked for lavc users
[20:55:38 CET] <BtbN> It seems to need more
[20:56:20 CET] <jamrial> nevcairiel: quick, update lavfilters to use this :p
[20:56:31 CET] <nevcairiel> its totally not worth it =p
[20:56:33 CET] <nevcairiel> i have d3d11
[20:56:35 CET] <BtbN> it is definitely intended for ffmpeg.c to use it, as it has changes
[20:57:01 CET] <BtbN> But as it does not have a single line of log output, it's impossible to tell what it's actually doing
[20:57:58 CET] <nevcairiel> thats normal
[20:58:03 CET] <nevcairiel> you can usually tell if it outputs nv12
[20:58:20 CET] <BtbN> I'll just add a line of verbose log output
[20:58:33 CET] <BtbN> Ok, it's not going anything
[20:59:15 CET] <jamrial> in my non nvidia rig using -hwaccel nvdec just outputs https://pastebin.com/raw/gx5iK1ZH then decodes using sofware
[21:00:13 CET] <jamrial> but with -hwaccel cuvid it shits out https://pastebin.com/raw/X0AA1Dx4 repeatedly and doesn't decode anything
[21:02:54 CET] <BtbN> Yeah, hwaccel cuvid is special
[21:02:59 CET] <BtbN> nvdec is a native generic one
[21:06:00 CET] <jamrial> BtbN: there's 10190e80b9 in wm4's tree
[21:06:15 CET] <jamrial> but goes after the hevc hwaccel and probably is unrelated to ffmpeg cli
[21:07:41 CET] <BtbN> Yeah, looks unrelated
[21:07:58 CET] <BtbN> ffmpeg.c does not even seem to try using it
[21:17:52 CET] <BtbN> This makes no sense
[21:18:07 CET] <nevcairiel> dumb question, but you did re-configure right
[21:18:36 CET] <BtbN> Yes, I have debug-prints inside of CONFIG_H264_NVDEC_HWACCEL in h264_slice.c, and it does add the CUDA pix_fmt
[21:18:43 CET] <BtbN> And then in ffmpeg.c get_format, there is no CUDA format
[21:19:21 CET] <BtbN> ah wait, it is there. But it finds cuvid instead of nvdec
[21:19:28 CET] <BtbN> weird, I did apply the commit to prevent that
[21:21:21 CET] <jamrial> BtbN: that commit looks different in wm4's tree
[21:21:43 CET] <BtbN> Which one is wm4s tree?
[21:21:48 CET] <jamrial> https://github.com/mpv-player/ffmpeg-mpv/commit/61072065593e308d0616dc8109419d93fd9d6636
[21:21:55 CET] <jamrial> and yours https://github.com/BtbN/FFmpeg/commit/bad5203f53393ba04fd182ca89534582e223e00a
[21:22:00 CET] <jamrial> you're missing one chunk
[21:22:13 CET] <jamrial> is that intended?
[21:22:23 CET] <jamrial> in decode.c
[21:22:54 CET] <BtbN> No, I just applied the patch from the ml there
[21:24:04 CET] <BtbN> avcodec_get_hw_frames_parameters does not exist at all in my tree
[21:24:09 CET] <jamrial> yeah, just noticed that
[21:24:43 CET] <jamrial> BtbN: https://github.com/mpv-player/ffmpeg-mpv/commit/649eef0b4a605d994100ce5734ce385d7344e48a
[21:25:09 CET] <BtbN> That should not be required for it to work
[21:25:23 CET] <BtbN> It's just new API for mpv I guess
[21:25:29 CET] <jamrial> commited in october to libav
[21:25:59 CET] <BtbN> It will be merged eventually then
[21:26:07 CET] <BtbN> It's not the problem I have right now though
[21:32:23 CET] <BtbN> Guess ffmpeg.c just cannot handle the multiple hwaccels yet
[21:33:28 CET] <BtbN> And it can't, because it's internal API
[21:33:29 CET] <BtbN> great
[21:36:39 CET] <jamrial> does it work with avconv? the code it's not different there, aside from cuda needing the sdk
[21:37:29 CET] <BtbN> jamrial, libav does not have two hwaccels with the same pix_fmt
[21:37:34 CET] <BtbN> so the problem does not exist there
[21:37:46 CET] <BtbN> Since they do not have the original cuvid we have
[21:37:52 CET] <jamrial> ah, that's true
[21:38:16 CET] <BtbN> wm4 did a patch to account for that in ff_get_buffer
[21:38:23 CET] <BtbN> ff_get_format
[21:38:25 CET] <BtbN> not buffer
[21:39:06 CET] <JEEB> hrr, I will need to poke x264 more to get colorspace information updates rolling properly
[21:39:57 CET] <JEEB> because I have noticed that ffmpeg.c initializes the encoder before it has the proper colorspace information (or it just doesn't copy it) - and then x264's reconfig doesn't yet support updating the colorspace information
[21:40:14 CET] <JEEB> so even if the AVFrame has the needed stuff that doesn't help :/
[21:41:53 CET] <BtbN> jamrial, yeah, just disabling cuvid fixes the whole situation
[21:44:23 CET] <jamrial> is the existing cuvid worth keeping after adding this? we could just replace it, maybe making cuvid an alias of nvdec if possible to avoid dropping the name
[21:44:38 CET] <BtbN> It is
[21:45:13 CET] <jamrial> the hwaccel? i'm not saying to remove the decoder. unless they have to go together
[21:45:14 CET] <BtbN> it supports hw deinterlacing(only way to access the nvidia hw deinterlacer for the cuda chain), scaling, and like 5 more codecs
[21:45:32 CET] <BtbN> The fake hwaccel is needed for ffmpeg.c still
[21:45:49 CET] <jamrial> i think jkqxz was writing a set to remove the fake hwaccels
[21:49:21 CET] <jamrial> BtbN: if this is a ffmpeg.c only issue, is it possible to skip the relevant changes from the patch until the fake hwaccels can be removed?
[21:49:40 CET] <BtbN> It seems fairly easy to just fix ffmpeg.c
[21:50:34 CET] <jamrial> ah, your comment about internal api made me think it wasn't
[21:50:45 CET] <BtbN> The auto-mode won't work
[21:50:53 CET] <BtbN> But if the user explicitly requests nvdec, it can
[21:51:28 CET] <nevcairiel> auto-mode should probably just prefer one, preferably nvdec
[21:51:56 CET] <BtbN> That's just a matter of ordering the list
[21:51:59 CET] <nevcairiel> but even if it doesnt work its probably fine
[21:52:05 CET] <nevcairiel> auto doesnt work, that is
[21:52:11 CET] <nevcairiel> not sure people really use auto
[21:52:16 CET] <BtbN> auto just prefers the one that comes first, and then gives up
[21:52:17 CET] <nevcairiel> and the platform hwaccels probably win that anyway
[21:52:29 CET] <BtbN> So just by putting nvdev in front of cuvid there makes it win in auto mode, which is desireable
[22:07:03 CET] <BtbN> nevcairiel, jamrial https://github.com/BtbN/FFmpeg/commit/f57a5e68ab346c930a0f9e446785176c2c2850f5 this seems to do the trick
[22:14:50 CET] <BtbN> correction 8234aa4cf8407f86daa3854b82f9ba1a06541543
[22:15:55 CET] <jamrial> can't test it, so if it works for you then it should be good
[22:17:56 CET] <BtbN> Yeah, it works great now
[22:18:12 CET] <BtbN> What should I do? Just push the merges, and the ffmpeg.c patch to the ml?
[22:25:09 CET] <BtbN> libav also has hevc_nvdec
[22:25:36 CET] <jamrial> hevc_cuvid you mean? and yeah, that's a few commits ahead of this point
[22:26:33 CET] <jamrial> and just push this set as is sans the ffmpeg.c patch. sent that one to the ml
[22:26:54 CET] <jamrial> or if you prefer i can apply them as part of the merges
[22:27:12 CET] <BtbN> It's not all merges, but the other patches needed for it have been on the ml forever by wm4
[22:27:29 CET] <BtbN> It's pretty much one merge and a bunch of preparation to make it possible
[22:27:35 CET] <jamrial> yeah
[22:27:54 CET] <BtbN> Gonna test stuff on cygwin to be sure, and then will just push
[22:28:27 CET] <jamrial> alright
[22:31:11 CET] <BBB> if you have a double for loop, why not place the closing braces on the same line? it saves a line
[22:31:18 CET] <BBB> for (..) {
[22:31:21 CET] <BBB>     for (..) {
[22:31:23 CET] <BBB>         ..
[22:31:26 CET] <BBB> }   }
[22:31:34 CET] <BBB> doesnt that look pretty?
[22:32:21 CET] <cone-305> ffmpeg 03Aurelien Jacobs 07master:a337b36b8bd6: aptx: implement the aptX bluetooth codec
[22:32:22 CET] <cone-305> ffmpeg 03Aurelien Jacobs 07master:018eef1a1bb6: aptx: add raw muxer and demuxer for aptX
[22:32:23 CET] <cone-305> ffmpeg 03Rostislav Pehlivanov 07master:eb7a01d69268: Changelog: list the new aptX features
[22:33:40 CET] <BtbN> I don't like it
[22:34:59 CET] <atomnuker> TD-Linux: not a bad little codec
[22:35:22 CET] <BtbN> configure on my Desktop is not nearly as dirt slow as on my work laptop
[22:35:50 CET] <BtbN> but that's crappy cheap Laptop SSD and 2GHz dual core vs. Samsung Pro NVMe SSD and an octa core
[22:40:23 CET] <BtbN> Yeah, works fine
[22:40:37 CET] <BtbN> Just noticed that sw decoding h264 on this CPU is way faster than hw decoding
[22:40:47 CET] <BtbN> 600 fps on cuvid, vs. 2500 fps on CPU
[22:40:53 CET] <atomnuker> what resolution?
[22:40:56 CET] <BtbN> 1080p
[22:41:14 CET] <atomnuker> wow
[22:41:27 CET] <atomnuker> does perf show hotspots/copies or something?
[22:41:35 CET] <BtbN> This is Windows
[22:41:36 CET] <BtbN> no perf
[22:41:41 CET] <atomnuker> ah, yeah, forgot
[22:41:51 CET] <atomnuker> bitrate?
[22:42:09 CET] <BtbN> ~10Mbps
[22:45:27 CET] <atomnuker> frame threading maybe
[22:45:36 CET] <SortaCore> heyo, QSV seems to be checking if it can use mfxHandleType D3D9 before it checks for D3D11
[22:45:56 CET] <atomnuker> decoding 4k h264 at 25mbps is around 4x faster on my 4 core cpu than with vaapi
[22:46:10 CET] <atomnuker> its around 1/2 the speed of vaapi with 1 thread though
[22:46:17 CET] <TD-Linux> atomnuker, more curious how it compares to sbc
[22:46:39 CET] <BtbN> atomnuker, this is a Ryzen 8 core with 16 threads as well
[22:46:54 CET] <BtbN> so something has to be putting those threads to use, cause it's sitting at 100% when doing that
[22:47:04 CET] <TD-Linux> well also intel's decoder is probably faster
[22:48:02 CET] <BtbN> jamrial, yeah, works just fine
[22:54:06 CET] <jamrial> BtbN: as philipl always says, ship it :p
[22:54:44 CET] <BtbN> hm, it won't let me. The big nvdec patch has a trailing whitespace _somewhere_
[22:55:21 CET] <BtbN> git show with its colors doesn't show anything obvious, hm
[22:58:48 CET] <jamrial> weird, there doesn't seem to be one
[22:59:13 CET] <BtbN> Oh... I messed up the changelog when rebasing the set
[23:00:15 CET] <cone-305> ffmpeg 03wm4 07master:5593049466bc: avcodec/cuvid: rename cuvid.c to cuviddec.c
[23:00:16 CET] <cone-305> ffmpeg 03wm4 07master:ae5046e492cd: avcodec: allow multiple hwaccels for the same codec/pixfmt
[23:00:17 CET] <cone-305> ffmpeg 03wm4 07master:0aecc08e5fd1: avcodec/decode: add missing \n to log message
[23:00:18 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:0e0062438995: h264dec: add a NVDEC hwaccel
[23:00:52 CET] <BtbN> finally... that took a while
[23:03:06 CET] <jamrial> it took more than time, but yeah, it's finally over
[23:04:57 CET] <alevinsn> is wm4 still active in FFmpeg development?  wm4's libav work is being merged in (by jamrial), but that's from the summer.
[23:05:10 CET] <BtbN> Isn't it an ffmpeg fork?
[23:05:31 CET] <jamrial> he means the patches that were commited to libav first
[23:06:02 CET] <jamrial> alevinsn: currently no, he's not
[23:07:18 CET] <BtbN> just noticed the merge is kinda incomplete
[23:07:34 CET] <BtbN> the hevc part is missing, and was in the same commit in libav
[23:22:24 CET] <BtbN> nevermind, it's actually not the same commit. Just nearly the same commit message
[23:36:45 CET] <BtbN> great, the hevc decoder just plain crashes on me
[23:38:31 CET] <BtbN> https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/cuvid_hevc.c;h=5de9bca4836c1fb18e483a1ccaef67093b0ab244;hb=HEAD#l265 sps is just null here
[23:39:02 CET] <jamrial> maybe that's what libav commit 00fd914d49 fixes?
[23:39:37 CET] <jamrial> it's right before the hevc cuvid one
[23:40:11 CET] <BtbN> yeah, looks about right
[23:40:49 CET] <jamrial> i'll merge it in a moment
[23:41:11 CET] <kierank> michaelni: thank you
[23:42:10 CET] <BtbN> it's a clean cherry-pick, but a proper merge is probably better
[23:44:16 CET] <BtbN> works just fine with that commit in front
[23:45:49 CET] <BtbN> https://github.com/BtbN/FFmpeg/commits/master has the nvdec hevc patch. Feel free to push/merge along, it works with the other patch before
[23:46:12 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:de77671438c2: decode: avoid leaks on failure in ff_get_buffer()
[23:46:13 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:359a8a3e2d11: decode: add a method for attaching lavc-internal data to frames
[23:46:14 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:badf0951f54c: decode: add a mechanism for performing delayed processing on the decoded frames
[23:46:15 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:704311b2946d: decode: add a per-frame private data for hwaccel use
[23:46:16 CET] <cone-305> ffmpeg 03Anton Khirnov 07master:b9129ec4668c: h264dec: add a CUVID hwaccel
[23:46:17 CET] <cone-305> ffmpeg 03James Almer 07master:ae644cee1f42: Merge commit 'b9129ec4668c511e0a79e25c6f25d748cee172c9'
[23:46:19 CET] <jamrial> thanks
[23:48:40 CET] <kierank> michaelni: also, should sliced threads be added to that list?
[23:49:12 CET] <BBB> slice threading for ER?
[23:49:32 CET] <kierank> iirc ER is non optimal or broken somehow for h264 sliced threads
[23:53:03 CET] <nevcairiel> i thought that was fixed
[23:53:08 CET] <nevcairiel> but maybe i remember wrong
[00:00:00 CET] --- Sat Nov 11 2017