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

[burek]

[01:07:14 CET] <kierank> log of ffmpeg-meeting
[01:07:16 CET] <kierank> https://usercontent.irccloud-cdn.com/file/CAXlwwJD/irccloud-export-5955-2019-11-10-19-19-29.zip
[02:36:58 CET] <Lynne> jamrial: you don't even try to understand, I really regret giving you votes
[02:38:47 CET] <jamrial> Lynne: i try to understand what your obsession with michael is, but can't
[02:40:07 CET] <jamrial> he, according to you, ignores you or your reviews, and that's reason to spend months demanding an apology?
[06:42:03 CET] <linjie> thanks for sharing the meeting logs
[06:47:32 CET] <kurosu> Lynne: maybe I'm not either, but from my distant view, you're past arguing your points, and what I recently read are maybe counterproductive
[06:48:32 CET] <kurosu> is it about security patches being too low quality/hasted towards commit? Or rather what you feel (and may well be) disregard of your opinions?
[06:50:11 CET] <kurosu> The former is I think shared by a number of persons and I'm not privvy to any discussion about it, but that is a valid discussion to be had at some point with some TC
[06:51:14 CET] <kurosu> the issue(s) may have been lingering for months and it may have been gnawing at your... resistance/fortitude/whatever
[06:56:29 CET] <kurosu> anyway, I'm neither on the CC nor the TC nor among the voters, so...
[06:56:55 CET] <kurosu> Maybe I'm best being ignored :o
[09:20:36 CET] <kierank> kurosu: most people in Tokyo still
[14:38:58 CET] <mkver> jamrial: There is an easy solution for this coverity issue: Simply adapt the documentation of av_bsf_send_packet to match its actual implementation. It already allows empty packets (i.e. those where pkt->data and pkt->side_data_elems vanish) to indicate flushing. We simply jump to the checked call to av_bsf_send_packet().
[14:43:27 CET] <jamrial> mkver: sounds good. i forgot empty packets also worked as flush packets
[14:43:32 CET] <jamrial> want to send a patch for that?
[14:45:01 CET] <mkver> Already working on that.
[14:45:10 CET] <jamrial> thanks
[15:07:06 CET] <mkver> jamrial: Patches sent.
[16:03:57 CET] <cone-096> ffmpeg 03Andreas Rheinhardt 07master:41b05b849f21: avcodec/avcodec: Adapt the doc of av_bsf_send_packet to match its actual implementation.
[16:03:58 CET] <cone-096> ffmpeg 03Andreas Rheinhardt 07master:f01f9f179389: avformat/av1dec: Redo flushing of bsf
[16:05:21 CET] <rcombs> so do we need to find all the jumps on 32-byte boundaries in x86 code and nop them away
[16:08:57 CET] <kurosu> and a patched build of (n|y)asm
[16:38:55 CET] <cone-096> ffmpeg 03James Almer 07master:73ee53f31741: avcodec/encode: add missing assert to avcodec_receive_packet()
[17:29:08 CET] <Gramner> not really, adding pointless padding hurts performance of on non-broken cpus
[17:37:04 CET] <kurosu> that and I need my 0day to steal the data off msac *whistles*
[17:41:29 CET] <Gramner> I thought intel already fixed it in microcode?
[17:42:06 CET] <bencoh> them releasing a fix doesn't mean it's widely used yet :)
[17:43:51 CET] <Gramner> and adding a workaround in a different piece of software will magically make it so?
[17:50:10 CET] <lotharkript_> i noticed that the wrapper for Dav1d does not behave the same as libaom. For Dav1d, it will output all the layers, while aom will not.
[17:50:25 CET] <lotharkript_> Should we not have an option to disable all the layer on Dav1d?
[17:50:34 CET] <JEEB> "layer"?
[17:51:41 CET] <lotharkript_> output all spatial layers of a scalable AV1 bitstream is by default set to true for Dav1d
[17:51:47 CET] <JEEB> ah
[17:51:52 CET] <lotharkript_> while aom is false
[17:52:30 CET] <JEEB> if there's an option for that in dav1d the wrapper could quite well have an option for that
[17:52:38 CET] <nevcairiel> feel free to submit an option, but outputting all information by default is what it should be
[17:52:43 CET] <JEEB> yea
[17:53:40 CET] <lotharkript_> are we sure this is what you want to have all the spatial layer outputted? ffmpeg cannot deal with it after that.
[17:53:50 CET] <JEEB> hmm
[17:53:56 CET] <lotharkript_> you will get multiple frame with the same timestamp
[17:54:03 CET] <lotharkript_> and different resolution
[17:55:08 CET] <JEEB> I think the main thing is that the full res thing should be output from dav1d. but in that case I wouldn't disagree that only pushing out the full version makes sense
[17:55:16 CET] <kurosu> that reminds me of the (HE|AV)IF discussion
[17:56:01 CET] <nevcairiel> i dont even understand the purpose of such bitstream features, wouldnt you want seperate bitstreams to cut down on bandwidth
[17:56:34 CET] <kurosu> you splice/peel away some of the bitstream that is only for the lowres thing
[17:56:35 CET] <JEEB> with HEVC it seems like paytv sends the base thing out as unencrypted and then crypts the additional layers
[17:56:49 CET] <lotharkript_> if you look at dav1d source code, https://code.videolan.org/videolan/dav1d/blob/master/src/lib.c#L70  it seems to me that outputting all the layers is a temporary solution
[17:56:53 CET] <JEEB> that's one of the few use cases that kind of... makes sense
[17:56:58 CET] <kurosu> but you need it as well as the rest of the bitstream to do the full res one
[17:57:19 CET] <kurosu> some "HDR" solutions do work that way
[17:57:33 CET] <JEEB> was it the panasonic thing?
[17:57:51 CET] <kurosu> (also, hello V-Nova)
[17:58:01 CET] <kurosu> no, some of the Dolby profiles
[17:58:07 CET] <JEEB> right
[17:58:14 CET] <JEEB> I only mostly have seen profiles 5 and 8.x
[17:58:20 CET] <kurosu> or maybe Panasonic too, but I don't know about them
[17:58:22 CET] <JEEB> 5 being normal HEVC without SVC
[17:59:53 CET] <JEEB> lotharkript_: anyways it just sounds like the wrapper was not tested a lot if it does that with scalable stuff. in theory I'd say it might make sense to output the highest thing based on what you feed the decoder (or having an option for the thing you want out)
[17:59:56 CET] <kurosu> nevcairiel: (also correcting my earlier answer) you splice/peel away some of the bitstream that is only for the hires part (ie only keep that of the lowres part)
[18:00:23 CET] <kurosu> there is a lowres option in ffmpeg
[18:00:32 CET] <kurosu> so it may make sense to (ab)use it then
[18:00:36 CET] <lotharkript_> if you disable it, dav1d will output the highest layer (at least from dav1d command line)
[18:00:55 CET] <lotharkript_> I will send an patch to add an option for it
[18:01:00 CET] <JEEB> yea, that makes sense to test and make the default.
[18:01:05 CET] <kurosu> (dunno if the lowres option is deprecated)
[18:01:27 CET] <JEEB> kurosu: the current discussion is regarding "output_all_layers" boolean
[18:01:29 CET] <JEEB> :)
[18:01:38 CET] <JEEB> so you get N AVFrames of same PTS with differing sizes
[18:01:47 CET] <JEEB> which is kind of *handwave*
[18:01:59 CET] <kurosu> ok, I'd thought dav1d allowed you to select the layer
[18:02:10 CET] <JEEB> https://code.videolan.org/videolan/dav1d/blob/master/src/lib.c#L70
[18:02:16 CET] <JEEB> in a way this is called "letting the user select" xD
[18:02:28 CET] <JEEB> (output all and then(ry)
[18:02:38 CET] <lotharkript_> there is an option in Dav1d to select the layer as well.
[18:03:11 CET] <kurosu> "all" btw? what do profile mandate? Up to, say, 3 ?
[18:10:50 CET] <kurosu> ok, operating point, coded on 5 bits
[18:12:45 CET] <kurosu> and spatial_layers_cnt_minus_1 o 2 bits
[18:15:01 CET] <kurosu> no constrain on spatial_layer_ref_id, so you could require up to 4 resampling
[18:15:20 CET] <kurosu> for outputting a particular layer
[18:15:57 CET] <jamrial> a new option that maps to Dav1dSettings's operating_point should be fine
[18:17:20 CET] <jamrial> and all_layers should probably be set to 0 regardless of what dav1d sets it to. lavc shouldn't output all layers
[18:18:26 CET] <JEEB> yea
[18:19:40 CET] <lotharkript_> send patch for it
[18:20:03 CET] <lotharkript_> i mean, i sent a patch for it
[18:20:39 CET] <kurosu> ah ah, otherwise I'd have added ASAP :D
[18:25:25 CET] <kurosu> if the demuxer could get access to operating_points_cnt_minus_1, it could create as many video streams as there are operating points
[18:26:05 CET] <kurosu> but then I don't really know what use it would be, as you likely want to have only the stream that has the resolution and framerate targeted
[18:32:05 CET] <Dmitri_Ovch> Hi! I sent the patch (https://patchwork.ffmpeg.org/patch/16270/) proposed by Sitan Liu. This is a very small but useful patch that corrects the profile level option on AMF HEVC. Earlier, I also sent a patch, allowing the user to select the engine for AMF initialisation (https://patchwork.ffmpeg.org/patch/16015/). Could you review these patches?
[18:42:10 CET] <durandal_1707> how one does cross correlation of long 1D signals?
[18:59:15 CET] <kurosu> durandal_1707: iirc, for very long signals, you use FFT but I'm not sure how much of a speedup it actually is - at least that may give you keywords for your google search
[18:59:27 CET] <kurosu> someone more into signal processing will have further hints
[19:02:22 CET] <durandal_1707> kurosu: but what about one very long signal, and another shorter signal?
[19:02:29 CET] <jamrial> BBB: can you look at the spatial layer dav1d patch and discussion on the ml?
[19:03:41 CET] <BBB> let me look
[19:06:46 CET] <BBB> hm...
[19:07:03 CET] <BBB> I wish we had test samples that were meaningful so we could figure out what makes sense
[19:07:08 CET] <BBB> it's a little bit abstract right now
[19:07:18 CET] <BBB> I think I agree that by default, outputing all layers is silly
[19:07:34 CET] <BBB> I also agree having a way to debug streams by having all layers is nice
[19:07:53 CET] <BBB> I'd also like an option to output invisible streams, for example
[19:07:56 CET] <BBB> also for debugging
[19:11:42 CET] <BBB> for vp9... the problem is, nobody ever used svc
[19:11:48 CET] <BBB> so I never knew how it was supposed to work
[19:11:59 CET] <BBB> again, having reasonable test streams would be extremely valuable
[19:47:03 CET] <kurosu> It would be nice to have a negociation/configuration phase between codec and (API) user (also for threads, when eg dav1d allows setting the number of threads for eg loop filters, beside tiles and frames)
[19:47:12 CET] <kurosu> Here, how does th
[19:48:14 CET] <kurosu> An app/player gets to know and select which substream it might want, let alone have a user select it like it's possible for subs or audio
[19:49:42 CET] <JEEB> don't AVOptions update just fine during the life time of an AVCodecContext instance?
[19:50:00 CET] <JEEB> and it being mostly the case that things don't actually utilize them during their runtime
[19:51:07 CET] <kurosu> durandal_1707: don't really know, it depends on how many samples the shortest one has. It's like the factorization of multiplies in some dct algos. Mathematically right, practically often less useful. In your case it may simpler to just do a scalar product, and then ask money for faster algos afterwards :D
[21:00:02 CET] <taliho> :jamrial is there a missing dav1d_data_unref(data) if res == AVERROR(EINVAL) on libdav1d.c:222 ?
[21:02:08 CET] <taliho> also strangely I have an av_assert0 failure in libdav1d.c:237 because p->allocator_data is NULL
[21:04:17 CET] <taliho> on a file that plays fine in vlc
[21:07:37 CET] <lotharkript> BBB: is there an option in dav1d to return invisible frame?
[21:10:46 CET] <BBB> not yet
[21:10:49 CET] <BBB> but I will likely add it
[23:48:11 CET] <jamrial> taliho: on failure it's unreferenced in libdav1d_close() or libdav1d_flush()
[23:48:37 CET] <jamrial> also, can you upload the sample that fails on assert?
[00:00:00 CET] --- Fri Nov 15 2019