[00:18:09 CET] <atomnuker> jkqxz: nope, "hwmap,detile_vulkan,hwdownload,format=bgr0" still makes the drm->vulkan mapping but the frame I get in the filter isn't a vulkan frame despite having in->format=vulkan [00:18:31 CET] <atomnuker> putting ,format=vulkan after it doesn't change anything [00:34:34 CET] <atomnuker> the fuck? [00:34:58 CET] <atomnuker> something's using buf[0] and overwriting where I put my avvkframe struct [00:55:45 CET] <jkqxz> atomnuker: What do you mean by looking inside buf[0]? That need not be the original buffer instance, it can be anything which holds the reference transitively. [00:57:27 CET] <atomnuker> I need to store some per-frame context so I put it in buf[0] thinking there'll not be any issues and once a buf's refcount reaches 0 it'll call my callback and get freed [00:58:27 CET] <atomnuker> thing is, in the map_to function buf[0] is NULL, so it gets set to a reference to my context, and that bufferref gets overwritten by some other when it gets to the second filter [00:58:39 CET] <jkqxz> What do you put in the data pointers? [00:58:46 CET] <atomnuker> nothing [00:58:52 CET] <jkqxz> Oh. [00:59:07 CET] <jkqxz> Your frame information, the VkImage and stuff, must be in the data pointers. [00:59:14 CET] <jkqxz> Look at every other hardware frame format. [00:59:23 CET] <atomnuker> huh, ok [00:59:59 CET] <atomnuker> I thought it was okay for them to be in the buf[0] parts because obviously a hwframe can't have a bufferref [01:01:05 CET] <jkqxz> The reference is only for the refcounting, what is actually in it need not be the original buffer as long as it holds a reference to the original buffer and its frames context (and transitively device). [01:01:55 CET] <jkqxz> E.g. the mapping functions put an HWMapDescriptor as the reference on the mapped frame, which contains a reference to the source frame. [01:03:33 CET] <atomnuker> ah, now it makes sense, thanks [01:39:41 CET] <atomnuker> jkqxz: so during normal frame creation (like in get_buffer) buf[0] is set to a reference to a hwcontext priv struct, which is normally set to data[0], but what happens when mapping from another frame type? [01:39:41 CET] <atomnuker> data[0] gets directly set to the frame type and buf[0] doesn't get set to anything is what hwcontext_vaapi does [01:39:42 CET] <atomnuker> what's meant to free data[0]? [01:39:42 CET] <atomnuker> line 1146, dst->data[0] = (uint8_t*)drm_desc; [01:39:42 CET] <atomnuker> well, actually I'm interested in the other case, "dst->data[3] = (uint8_t*)(uintptr_t)surface_id;" for drm->vaapi, but that doesn't allocate any memory for the data planes [01:39:42 CET] <atomnuker> obviously you can't make a reference to the data because like you said buf[0] is used for chaining mappings [01:46:29 CET] <atomnuker> I guess I'll make the unmapping function free that struct, maybe that's how it was made to be done [02:35:57 CET] <jamrial> wm4: i'll apply the mlp_parser patch that honors the PARSER_FLAG_COMPLETE_FRAMES flag, plus a patch to make the matroska demuxer not set it for mlp/theora, so that sample from the other day doesn't complain [02:37:25 CET] <jamrial> just a heads up since you didn't reply to my last email about it in that thread [03:12:52 CET] <cone-612> ffmpeg 03James Almer 07master:63b5d04e331c: avformat/matroskadec: force full frame parsing of MLP/TrueHD streams [03:12:53 CET] <cone-612> ffmpeg 03James Almer 07master:55ebf707d0ab: avcodec/mlp_parser: don't try to combine frames when full frames are provided [03:12:54 CET] <cone-612> ffmpeg 03James Almer 07master:ede6e7494f61: avcodec/mlp_parser: reindent after last commit [04:33:57 CET] <cone-612> ffmpeg 03James Almer 07master:0cc3d830d159: avcodec/Makefile: add missing opus.c dependency to opus encoder [04:43:39 CET] <wm4> jamrial: sure, don't know if other containers are affected though [05:29:07 CET] <cone-612> ffmpeg 03Gyan Doshi 07master:b99e77b9f7b9: avformat/mpegenc - fix typo in VBV warning [05:29:08 CET] <cone-612> ffmpeg 03Dale Curtis 07master:42323c3e3a60: avcodec/mpegaudio_parser: Skip APE tags when parsing mp3 packets. [09:00:00 CET] <dragmore88> hi, i tried this q on the main channel, but as this is a more deeper topic for devs, ill try here : hi. Anyone know if ffprobe or ffmpeg supports detecting/setting the EAC3 parameter : convsnroffst ? (its to enable the ability to downfilter eac3 to ac3 compliant systems) [11:42:53 CET] <thardin> former boss of MPEG lamenting the rise of open standards: http://blog.chiariglione.org/a-crisis-the-causes-and-a-solution/ [11:45:20 CET] <j-b> good job team [11:51:06 CET] <atomnuker> michaelni: could you finally remove the FCC countdown warning from ffmpeg.org? [11:58:18 CET] <RiCON> atomnuker: https://0x0.st/sNNf.txt [11:59:44 CET] <atomnuker> send it to the ml? if there just ping the patch [12:00:40 CET] <RiCON> ffmpeg-devel too? [12:01:25 CET] <atomnuker> yes [12:06:31 CET] <RiCON> sent [12:25:11 CET] <jdarnley> Curses. I've got a segfault what disappears in GDB [12:25:16 CET] <jdarnley> *that [12:29:44 CET] <atomnuker> valgrind it [12:41:19 CET] <kierank> or asan if it's thread related [13:33:00 CET] <durandal_1707> j-b: disfunctional team [13:43:49 CET] <wm4> Nablet Developer has a weird clock [13:45:06 CET] <wm4> (what kind of author name is that anyway, not that I'm someone to talk) [13:49:54 CET] <atomnuker> I wish instead of pushing for their library they'd submit a properly written demuxer [13:50:39 CET] <wm4> it's not a demuxer though [13:50:44 CET] <wm4> it's on the stream layer [13:51:10 CET] <wm4> I guess it's a byte transport protocol and it's for serving a normal container over it [13:52:56 CET] <atomnuker> meh, its not like they can do much for realtime streaming, it has to be udp and it has to be one-way only [13:53:25 CET] <kierank> huh, it's two way [13:53:35 CET] <kierank> they have just abstracted it as a "protocol" [13:53:56 CET] <atomnuker> well surely they don't have the time to ask the sender to resend a packet [13:54:06 CET] <kierank> they add buffering [13:54:09 CET] <kierank> in the receiver for that [13:54:40 CET] <atomnuker> do they do error correction? [13:54:48 CET] <kierank> no [13:54:59 CET] <kierank> just retransmit on some insane protocol they wrote [13:55:18 CET] <atomnuker> wtf, this is stupid [13:57:19 CET] <durandal_1707> atomnuker: 1 month passed and still no atrac9 decoder, you are very slow typing coder [13:58:33 CET] <atomnuker> on the other hand I have a fully working vulkan filtering infrastructure capable of importing dmabufs and a filter template to write whatever filter I wanna have [13:58:53 CET] <durandal_1707> but that is for gsoc [13:59:38 CET] <atomnuker> no, its up to the gsoc student to use what I've written to try to write MV search on the gpu, though I just know I'll have to do it myself [14:00:29 CET] <atomnuker> I'll post the vulkan patchset to the ML soon, then I'll get atrac9 finished [14:23:02 CET] <durandal_1707> iive: hi! why are you back? [14:23:37 CET] <iive> durandal_1707, what? [14:24:06 CET] <durandal_1707> i thought you left [14:25:15 CET] <iive> have you gone insane? [14:26:27 CET] <iive> or you are just trolling me. I don't find it funny. [15:33:58 CET] <jdarnley> atomnuker: in a 2-level wavelet transform without deinterleave the first dwt for the whole image would output "0 1 2 3" samples in a row... [15:34:18 CET] <jdarnley> but the second level should only touch the 0 and 2 samples [15:34:22 CET] <jdarnley> Is that right? [15:39:26 CET] <jdarnley> oh well all that code is wrong, that stride should increase as the SubBand gets smaller [16:17:01 CET] <cone-612> ffmpeg 03James Almer 07master:222d7055e2dd: avcodec/hevc_parser: use ff_hevc_decode_extradata() to parse extradata [17:25:18 CET] <cone-612> ffmpeg 03James Almer 07master:782e066e3e3d: avcodec/mediacodecdec: use ff_hevc_ps_uninit() [17:28:40 CET] <SortaCore> does NVENC still require screen plugged in and turned on? [20:41:40 CET] <SortaCore> hmm also does NVENC support crf [20:44:59 CET] <BtbN> no [20:45:07 CET] <BtbN> crf is an x264 thing [20:46:37 CET] <RiCON> (libvpx too) [20:46:55 CET] <SortaCore> qsv has ICQ with same range [20:48:14 CET] <BtbN> The meaning of crf varies greatly depending on which implementation adapted the name [20:48:26 CET] <BtbN> you can't pass the same number into the same implementation, and get the same result [20:50:26 CET] <SortaCore> hm, nvenc has adaptive quality thing [20:57:51 CET] <SortaCore> I see one place where the guy is recommending turn on adaptive quant, set constq mode as cq 1, and vbr it [20:58:06 CET] <SortaCore> and NVENC also has -qp and -cq parameters [21:04:35 CET] <BtbN> -cq is weird, and -qp has a whole different scale and meaning [21:12:25 CET] <SortaCore> interestin [21:13:09 CET] <SortaCore> tell me more [21:29:36 CET] <BBB> its difficult to explain if you dont understand some fundamentals about video compression [21:29:51 CET] <BBB> compression generally improves if not all frames use the same quantizer [21:29:58 CET] <BBB> but for testing, using the same quantizer can help greatly [21:30:02 CET] <BBB> -qp uses the same quantizer [21:30:08 CET] <BBB> -crf targets an average quantizer [21:30:28 CET] <BBB> so -crf will have a better overall quality, but -qp uses the same quantizer in the literal sense [21:30:37 CET] <BBB> -crf is for end users, -qp for developers, Id say [21:30:49 CET] <atomnuker> libvpx takes liberties with what it does with constant quantizers [21:46:32 CET] <SortaCore> yea, I know diff between crf and cq [21:46:40 CET] <SortaCore> -qp <int> E..V.... Constant quantization parameter rate control method (from -1 to 51) (default -1) [21:46:41 CET] <SortaCore> -cq <float> E..V.... Set target quality level (0 to 51, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 51) (default 0) [21:46:51 CET] <SortaCore> just wondering what the difference between these is [21:46:53 CET] <BtbN> cq for nvenc never did anything for me. [21:47:04 CET] <BtbN> nvidia added it and sent a patch, and I never managed to make it do things [21:47:40 CET] <SortaCore> why does it say rate control "method" [21:57:35 CET] <mateo`> jamrial: thx for the mediacodec patch, and sorry for my lack of review/reply, i totally missed the patch on the ml [21:58:15 CET] <jamrial> mateo`: no prob [21:58:30 CET] <jamrial> and it was patch 4 in a set, so easy to miss [22:00:44 CET] <JEEB> yea, that was a nice one [22:18:51 CET] <kierank> michaelni: i appreciate you've been posting it for years but your mosad quotes are unnecessary [22:31:11 CET] <durandal_1707> kierank: also they are full of typos [22:34:42 CET] <SortaCore> that's just his way to avoid copyright strikes [22:48:47 CET] <cone-612> ffmpeg 03Michael Niedermayer 07master:4a75a75c62ef: avcodec/hevc_ps: Check log2_sao_offset_scale_* [22:48:48 CET] <cone-612> ffmpeg 03Michael Niedermayer 07master:2ff9f178519b: avcodec/indeo5: Do not leave frame_type set to an invalid value [22:48:49 CET] <cone-612> ffmpeg 03Michael Niedermayer 07master:fe1e6c06d034: avcodec/dirac_dwt: Fix several integer overflows [00:00:00 CET] --- Wed Jan 31 2018