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

[burek]

[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