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

[burek]

[03:02:45 CEST] <atomnuker> rcombs: ping
[03:45:58 CEST] <rcombs> atomnuker: pushed on my gh fork; I forget if there's anything left to be done
[07:17:19 CEST] <Ahti333>  michaelni could you take a quick look at https://github.com/ahti/FFmpeg/commit/8b5f83021caf14c230727eeeff387c970b85bedd and let me know wether this is an appropriate way to resolve https://trac.ffmpeg.org/ticket/6558 ?
[09:19:31 CEST] <nevcairiel> seems fine to me Ahti333, you should sent it to the mailing list
[10:57:29 CEST] <michaelni> Ahti333, id say post the patch to the ML
[11:25:52 CEST] <JEEB> did lavu have a function to produce a timestamp from int64_t+timebase?
[11:26:13 CEST] <JEEB> (or from a double since we have the int64_t+timebase => double thing at least)
[11:26:54 CEST] <JEEB> as in, speaking of the timestamp string that a lot of subtitle formats use ("00:00:00.000")
[11:29:51 CEST] <nevcairiel> you can always use rescale for that
[11:31:15 CEST] <nevcairiel> oh you want a string timestamp?
[11:33:31 CEST] <nevcairiel> apparently we dont, at least srtenc does it manually
[11:38:13 CEST] <JEEB> yea, I checked there :)
[11:38:26 CEST] <JEEB> ffprobe also used its own thing
[11:38:37 CEST] <JEEB> so ok, no such thing yet
[12:13:48 CEST] <cone-542> ffmpeg 03Paul B Mahol 07master:5d07275529f6: avfilter/af_headphone: increase max ir length
[12:24:40 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:7333799de5fc: avcodec/pngdec: Clean up on av_frame_ref() failure
[12:24:41 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:bfb7744aaffa: avcodec/svq3: Fix overflow in svq3_add_idct_c()
[12:24:42 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:b9f0979e16c0: avcodec/ffv1dec: Fix integer overflow in read_quant_table()
[12:24:43 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:743354358b31: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*()
[12:24:44 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:c7ad616ddaaa: avcodec/takdec: Fix integer overflows in decode_subframe()
[12:24:45 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:dc5240a4d797: avcodec/proresdec2: Check bits in DECODE_CODEWORD(), fixes invalid shift
[12:24:46 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:27505de3b9fe: avcodec/takdec: Fix integer overflow in decode_lpc()
[12:24:47 CEST] <cone-542> ffmpeg 03Michael Niedermayer 07release/3.1:38c1df15c6a3: Update for 3.1.11
[17:16:06 CEST] <LongWork> Could anyone clarify a few things around SDR / HDR / HDR10 for me ? 
[17:16:38 CEST] <LongWork> I have a device which has two settings for colorspaces and color management. And the more i read about those on various articles , the more i get confused
[17:17:48 CEST] <LongWork> seems like i have a setting calles EOTF which has the following options SDR / HDR / HDR10
[17:18:25 CEST] <LongWork> i suppose that 10 bits videos should use the HDR10, but then i have no idea on how to know from an AVFrame if it's SDR or HDR 
[17:38:11 CEST] <LongWork> it's kind of fuzzy for me what can be deduced for TRC / colorspace and colorprimaries
[17:50:23 CEST] <iive> my guess, not based on any knowladge or facts, is that these are 8/9/10 bits
[17:52:02 CEST] <LongWork> from what i have read it can be more complicated :)
[17:55:59 CEST] <wm4> iive: no
[17:56:24 CEST] <wm4> HDR usually requires 10 bit or so to avoid banding, that's all
[17:56:43 CEST] <wm4> LongWork: generally, you need to export the correct colorspace
[17:57:10 CEST] <wm4> AVCOL_SPC_BT2020_NCL would usually be HDR
[17:57:19 CEST] <wm4> you might also have to export a bunch of other metadata
[17:58:00 CEST] <wm4> potentially parts of AV_FRAME_DATA_MASTERING_DISPLAY_METADATA and AV_FRAME_DATA_CONTENT_LIGHT_LEVEL
[17:58:06 CEST] <LongWork> is HDR necessary 10 bits ? 
[17:58:22 CEST] <wm4> I suppose in theory it could be applied to 8 bits...
[17:58:42 CEST] <wm4> possible, but doesn't make too much sense I guess
[17:58:53 CEST] <wm4> on the other hand, 10 bit does not necessarily mean the file uses HDR
[17:59:02 CEST] <iive> LongWork: is the device capture (camera) or playback (monitor) ?
[17:59:08 CEST] <LongWork> because i have two settings available on the hardware, one is called EOTF which can be SDR / HDR or HDR10, the other one relates to colorspace
[17:59:41 CEST] <LongWork> and i'm trying to determine how to adjust those two settings from ffmpeg TRC / colorspace and Primaries
[17:59:51 CEST] <wm4> iive: he is working with a decoder
[18:00:57 CEST] <wm4> LongWork: right, I think that corresponds to AVColorTransferCharacteristic
[18:01:33 CEST] <wm4> yeah, I think Bt.2020 colorspace does not mean yet that it's HDR
[18:01:47 CEST] <wm4> but if the transfer function is Bt.2020, it is HDR
[18:01:50 CEST] <wm4> probably
[18:02:38 CEST] <wm4> and apparently there are different bitstream values depending on bitness: AVCOL_TRC_BT2020_10 and AVCOL_TRC_BT2020_12
[18:02:40 CEST] <wm4> for whatever reason
[18:03:46 CEST] <wm4> I might be talking non-sense, I'm not all that familiar with those
[18:04:01 CEST] <LongWork> that's at least some light on all this mess :)
[18:04:33 CEST] <wm4> digging a bit deeper BT2020 TRC is still not HDR, but AVCOL_TRC_SMPTEST2084 is
[18:04:59 CEST] <wm4> I'd just make sure that your hw decoder wrapper returns the same parameters as sw decoding
[18:05:49 CEST] <LongWork> yeah it seems to be the case, i have the same enums as ffmpeg for TRC 
[18:10:11 CEST] <wm4> oh right, they just stole that without respecting copyright
[18:10:40 CEST] <wm4> then what is that stuff you talked about?
[18:12:37 CEST] <LongWork> wm4 : well i need to set the colorspace info to the display system trhru drm 
[18:12:50 CEST] <LongWork> that is possible with setting DRM plane properties
[18:13:09 CEST] <LongWork> there are two properties there to adjust color stuff
[18:13:22 CEST] <LongWork> one is called EOTF and can be SDR/ HDR / HDR10
[18:13:29 CEST] <wm4> oh
[18:13:52 CEST] <wm4> so that's completely different from what I thought you're talking about, oops
[18:14:08 CEST] <LongWork> second is called COLOR_SPACE and can be one of the following values : https://github.com/torvalds/linux/blob/master/include/uapi/linux/videodev2.h#L183-L238
[18:14:32 CEST] <LongWork> so the question is basically, how do i match the TRC & colorspace info i'm getting to those settings 
[18:15:10 CEST] <wm4> I have not the slightest clue
[18:15:27 CEST] <wm4> maybe you could ask hanna, if you explain the choices which DRM offers well enough
[18:15:45 CEST] <hanna> context?
[18:16:26 CEST] <hanna> LongWork: `HDR10` might refer to the HDR10 Media Profile
[18:16:39 CEST] <hanna> Which is a metadata thing only
[18:16:45 CEST] <hanna> and shouldn't be confused with the bit depth...
[18:17:13 CEST] <hanna> BT.2020 also has nothing to do with HDR. HDR itself is a meaningless term, also
[18:17:21 CEST] <LongWork> hmmm 
[18:17:23 CEST] <hanna> The only underlying question is which TRC you use: PQ or HLG; and with how many bits
[18:18:22 CEST] <hanna> `SDR`, `HDR` and `HDR10` are completely meaningless descriptions of EOTFs
[18:18:27 CEST] <JEEB> yea
[18:18:34 CEST] <LongWork> well all i have in input is the amount of bits in the video 8 /10, and the usual info from ffmpeg TRC / primaries / colorspace
[18:18:50 CEST] <hanna> I can only vaguely guess that they're supposed to map to either `BT.1886` or `SRGB` for `SDR`, and HDR / HDR10 probably both map to PQ but the latter also takes mastering metadata into account?
[18:19:01 CEST] <hanna> but who knows
[18:19:05 CEST] <LongWork> then the "settings" available thru drm on the hardware are that EOTF and thte colorspace properties
[18:19:15 CEST] <JEEB> HDR says nothing, HDR10 usually is BT.2020 + SMPTE ST.2084 with the mastering metadata (and 10bit HEVC)
[18:19:32 CEST] <JEEB> since HDR10 is what UHD BD uses :P
[18:19:43 CEST] <JEEB> HDR10+ is the dynamic metadata bullshit
[18:20:28 CEST] <hanna> also lol are those enums supposed to describe both the primaries and the transfer?
[18:20:46 CEST] <hanna> `EOTF` is normally just the transfer
[18:21:00 CEST] <JEEB> yea
[18:21:03 CEST] <LongWork> yeah that's what i was given 
[18:21:13 CEST] <hanna> so BT.2020 would be irrelevant
[18:21:21 CEST] <JEEB> which API are we talking about?
[18:21:24 CEST] <hanna> (BT.2020 only concerns the colorspace, not the EOTF)
[18:21:29 CEST] <JEEB> I just know what "HDR10" means
[18:21:41 CEST] <LongWork> available values for EOTF are :
[18:21:42 CEST] <LongWork> * TRADITIONAL_GAMMA_SDR = 0,
[18:21:42 CEST] <LongWork>   * TRADITIONAL_GAMMA_HDR,
[18:21:42 CEST] <LongWork>   * SMPTE_ST2084,/* HDR10*/ 
[18:21:47 CEST] <hanna> (although BT.2020 *does* specify an OETF, the BT.2020 OETF, which is a counter-part to BT.1886 i.e. `SDR`)
[18:21:57 CEST] <hanna> traditional gamma HDR
[18:22:08 CEST] <hanna> oh so it's BT.1886 but allows values above 1.0?
[18:22:12 CEST] <hanna> what a confusing thing to call HDR
[18:22:25 CEST] <hanna> although traditional gamma is also ambiguous as fuck
[18:22:31 CEST] <hanna> is it PPC? BT.1886? sRGB?
[18:22:59 CEST] <LongWork> all that crap is chinese for me :) 
[18:23:33 CEST] <LongWork> i was just hoping to get an idea on what the matrix would be between TRC & EOTF
[18:23:56 CEST] <LongWork> then i suppose that colorspace stuff should more or less match 
[18:24:29 CEST] <wm4> where are the docs for that?
[18:24:34 CEST] <wm4> or is that kernel-style NO DOCS
[18:25:01 CEST] <LongWork> the latter :) it's not even in kernel yet, just landed as a patch for testing in the mail 
[18:25:54 CEST] <hanna> context?
[18:25:57 CEST] <hanna> I still have no clue wtf this is about
[18:26:17 CEST] <hanna> oh V4L2
[18:26:26 CEST] <LongWork> not quite 
[18:26:27 CEST] <hanna> What is V4L2 anyway? just for capture cards and shit?
[18:26:35 CEST] <wm4> no I think this is DRM
[18:26:38 CEST] <hanna> hmm
[18:27:08 CEST] <wm4> LongWork works on the rockchip decoder wrapper, whose support lib conveniently steals ffmpeg's code for this, so no problem
[18:27:23 CEST] <wm4> LongWork: so, link to patch?
[18:27:23 CEST] <LongWork> yeah i have the media info fine 
[18:27:32 CEST] <LongWork> sure 
[18:27:35 CEST] <wm4> MediaInfo?
[18:27:52 CEST] <LongWork> https://patchwork.ffmpeg.org/patch/5250/
[18:27:58 CEST] <LongWork> this is the patch
[18:28:15 CEST] <BtbN> patchwork still broken/down :(
[18:28:24 CEST] <LongWork> but that's not where the issue is, with that patch i get the media information as ffmpeg
[18:28:40 CEST] <wm4> LongWork: I mean the DRM one
[18:29:10 CEST] <LongWork> from that AVFrame info in which i get TRC / colorspace & primaries i need to pass that info to the display system so that gamma is handled properly by the display 
[18:29:58 CEST] <LongWork> I use DRM for dispalying, and the only way to set color information is to define two properties in the DRM plane i'm sending to display 
[18:30:17 CEST] <LongWork> one of these props is EOTF as mentioned above with 3 available values 
[18:30:41 CEST] <LongWork> the other one is COLOR_SPACE which can be set to the values of the V4L2 enums above
[18:31:17 CEST] <LongWork> so I wanted to know how to select the right EOTF / COLOR_SPACE values from ffmpeg TRC / colorspace / primaries
[18:31:43 CEST] <LongWork> from what i got ffmpeg TRC should match EOTF, and ffmpeg colorspace  should match COLOR_SPACE
[18:32:28 CEST] <LongWork> now the question is that ffmpeg TRC has like https://github.com/FFmpeg/FFmpeg/blob/ec1573f879b1974050c68fdcb69b654e500efdfa/libavutil/pixfmt.h#L455-L477 a couple values which i need to turn into 3 possible settings 
[18:32:55 CEST] <LongWork> the COLOR_SPACE one should be matching more what ffmpeg has in it's colorspace info 
[18:33:04 CEST] <wm4> LongWork: the ffmpeg ones are pretty much those from the codec bitstream
[18:33:52 CEST] <LongWork> i suppose AVCOL_TRC_SMPTE2084 should patch their  * SMPTE_ST2084,/* HDR10*/
[18:34:16 CEST] <LongWork> but i'm not sure about the other two "TRADITIONAL_GAMMA_SDR" and "TRADITIONAL_GAMMA_HDR"
[18:35:06 CEST] <LongWork> so was wondering if someone could shed some light on what could be matching any of those, should there be any sense in that :)
[18:35:50 CEST] <wm4> not sure why you're asking that - the author of the kernel API should know (and in a sane world, the kernel API would document this properly)
[18:35:59 CEST] <wm4> or, well, DRM API
[18:36:26 CEST] <LongWork> DRM is sorrowfully not very well documented
[18:36:42 CEST] <LongWork> and even worse there is no standard for these property as they are not part of legacy API 
[18:37:09 CEST] <hanna> TRADITIONAL_GAMMA_* could mean literally anything, and I don't think ffmpeg implies any explicit clipping semantics on either of those
[18:38:58 CEST] <LongWork> yeah was afraid of that :)
[18:39:13 CEST] <LongWork> ok i'll get back to them for some further clarification then 
[18:39:28 CEST] <hanna> keep in mind that DRM probably has different goals here, or something
[18:39:47 CEST] <hanna> Actually DRM doesn't concern itself with compositing at all, right?
[18:39:55 CEST] <hanna> It assumes it gets a single image from whatever's feeding it?
[18:39:56 CEST] <wm4> actually it does
[18:40:02 CEST] <hanna> hmm
[18:40:04 CEST] <wm4> it gives you access to the hardware compositor
[18:40:13 CEST] <hanna> What does hardware compositor mean?
[18:40:27 CEST] <wm4> it means the GPU magically composites multiple layer
[18:40:30 CEST] <jkqxz> It represents the scanout planes and nothing else.  If compositing is supported there then it's exposed, otherwise not.
[18:40:31 CEST] <hanna> ah
[18:40:42 CEST] <hanna> Isn't the scanout plane shit for stereo vision and whatnot
[18:40:45 CEST] <hanna> or maybe I'm confused
[18:40:55 CEST] <wm4> think of it as hardware overlays
[18:41:20 CEST] <LongWork> most of the tiem on embedded, the compsiting device is not the GPU, they have some video processing unit that will do that job.
[18:41:21 CEST] <jkqxz> There is usually a cursor overlay at least.
[18:41:38 CEST] <LongWork> so they have a primary plane, a few overlays and a cursor plane
[18:41:53 CEST] <hanna> in any case, TRADITIONAL_GAMMA_SDR probably means to whatever we were doing before, TRADITIONAL_GAMMA_HDR probably maps to whatever we were doing before but allow out-of-range values which will get signalled to the display in god knows what manner, and HDR10 probably means signal to the display that the content is to be interpreted as PQ, with attached metadata
[18:42:03 CEST] <hanna> maybe it translates TRADITIONAL_GAMMA_HDR to PQ internally
[18:42:11 CEST] <LongWork> you will draw to these planes with GPU but the end cmpositing of such planes is done by another hardware than GPU 
[18:42:12 CEST] <hanna> because I don't believe display connections have a standard for HDR that isn't PQ?
[18:42:34 CEST] <hanna> unless this is the xvYCC shit or something
[18:42:48 CEST] <hanna> scRGB I mean
[18:42:56 CEST] <jkqxz> LongWork:  Where do you pass this information to the DRM modesetting API?  Is it a plane or CRTC property somehow?
[18:43:08 CEST] <hanna> I mean technically scRGB is meant for wide gamut and not HDR but I don't even know what the difference between the two is even more (both are just out-of-range values...)
[18:43:27 CEST] <hanna> ah Large positive numbers allow high dynamic range images to be represented, though the range is inferior to that of some other high dynamic range formats such as OpenEXR.[1]
[18:43:31 CEST] <LongWork> jkqxz: you need the Atomic API and set the properties on the drmPlane
[18:43:34 CEST] <hanna> seems like out-of-range = negative values, not just positive
[18:43:42 CEST] <hanna> maybe we need support for negative value tone-mapping in mpv
[18:44:03 CEST] Action: hanna hides somewhere wm4 can't find him
[18:44:26 CEST] <LongWork> jkqxz: FYI (still WIP, don't bother about the mess) https://github.com/LongChair/mpv/commit/11f531265b0043446ed5a7cd19863a7afc0b1242
[18:44:34 CEST] <hanna> seems like HDMI can do xvYCC 4:4:4
[18:44:48 CEST] <LongWork> jkqxz: would be done in the same way as those : https://github.com/LongChair/mpv/commit/11f531265b0043446ed5a7cd19863a7afc0b1242#diff-6f3c3fbfdebb6303132abee62d9545b5R189
[18:44:54 CEST] <hanna> but god knows what the display hardware will actually do with this
[18:45:04 CEST] <hanna> it's all fucked
[18:45:21 CEST] <LongWork> yeah on those devices, what the call VOP (scaler, compositor), can also handle the colorspace conversion
[18:47:08 CEST] <LongWork> jkqxz: the bad thing about that is that there are a few legacy properties that are in DRM standards (the ones in the code). but there is no standard for colorspace stuff, so basically each vendor would have it's own props... which is rather bad
[18:47:16 CEST] <jkqxz> Hehe, KMS atomic <3.  (Clearest API evar.)
[18:47:52 CEST] <LongWork> yeah ... but on such devices, there is no performance without drm .. :/
[18:47:57 CEST] <jkqxz> I don't see any properties for this on Rockchip (<http://sprunge.us/RajG>).  This needs some exciting new kernel?
[18:48:49 CEST] <LongWork> nope the ones in the code i linked are DRM standard, they are there :)
[18:49:17 CEST] <jkqxz> The colourspace ones, I mean.#
[18:49:44 CEST] <LongWork> oh yeah colorspace ones are not in kernel yet :)
[18:50:16 CEST] <LongWork> i get some uncooked patches from RK usually :p
[18:50:31 CEST] <LongWork> then do the guinea pig and then they are pushed :p
[18:50:49 CEST] <LongWork> jkqxz: btw did you test the latest ffmpeg decoder patch ? 
[18:50:51 CEST] <jkqxz> (I looked at this before on Rockchip to test kmsgrab stuff, all of the nonstandard plane formats are fun too.)
[18:51:03 CEST] <LongWork> yeah the NV12_10 
[18:51:04 CEST] <jkqxz> Just looking at it.  I think it's good now.
[18:51:39 CEST] <LongWork> they did that for ddr bandwidth .. but that's not enought for 4K at 60 obviously, i wish they went the AFBC way 
[18:51:54 CEST] <LongWork> although would have probably been more difficult to use from ffmpeg
[18:52:13 CEST] <wm4> AFBC?
[18:52:28 CEST] <LongWork> Arm Frame Buffer Compression
[18:52:55 CEST] <LongWork> it's some sort of framebuffer compression that allows to divide the bw by 2/3
[18:53:11 CEST] <LongWork> most ARM chips like GPU or VPU can decode encode that 
[18:53:28 CEST] <LongWork> and allows to minimize the memory transfer bandwidth, especially with video stuff
[18:53:52 CEST] <LongWork> https://developer.arm.com/technologies/graphics-technologies/arm-frame-buffer-compression
[18:54:23 CEST] <LongWork> the problem is that i don't think ABFC code is public
[18:56:00 CEST] <atomnuker> intel has a similar thing, turned on by default nowadays
[19:05:22 CEST] <jkqxz> LongWork:  Two minor things:  DRM_FORMAT_* should be a uint32_t (around rkmpp_get_frameformat());  ret is sometimes pointlessly initialised to MPP_NOK in functions returning AVERROR - they all get overwritten, but if you don't initialise it then the compiler will check that for you :)
[20:01:16 CEST] <kurosu_> all GPU vendors have equivalent stuff for compressing their buffers
[20:01:37 CEST] <kurosu_> often a mix of delta (from a neighbor), palette and old school techniques
[20:02:05 CEST] <kurosu_> though not sure how they achieve lossless, fixed rate, and not too large risk of expansion
[20:02:57 CEST] <kurosu_> famous s3tc
[20:17:41 CEST] <iive> s3tc is lossy
[20:18:48 CEST] <iive> it is basically half by half image and smaller deltas.
[20:19:45 CEST] <LongChair> jkqxz: mind replying to these in ML so that i can keep track of that ? :)
[21:09:17 CEST] <llogan> i need to set an alias for ffmpeg as "gg,[rh" due to my occassional, but odd, one-key-to-the-right typos
[21:38:59 CEST] <cone-694> ffmpeg 03Paul B Mahol 07n3.1.11:HEAD: avfilter/af_headphone: increase max ir length
[21:52:51 CEST] <jkqxz> LongChair:  <http://sprunge.us/LLBJ>
[21:53:02 CEST] <jkqxz> Mostly cosmetic.  I can just squash that in if you're happy with it?
[21:53:13 CEST] <jkqxz> Does anyone else want to comment on Rockchip decoder?  wm4?
[21:53:40 CEST] <wm4> I've looked at it much earlier and have nothing more to say
[21:55:24 CEST] <jkqxz> I don't think anyone else is interested, so if LongChair is happy with that then I'll just push it.
[21:55:46 CEST] <wm4> no objection here
[22:13:59 CEST] <hanna> 20:02 <@kurosu_> though not sure how they achieve lossless, fixed rate, and not too large risk of expansion <- the answer is simple: they don't
[22:14:08 CEST] <hanna> I've yet to see a lossless texture compression mode
[22:14:44 CEST] <cone-694> ffmpeg 03Thomas Mundt 07master:d491d6a0cd01: avfilter/interlace: rename two variables for consistency
[22:28:35 CEST] <jamrial> wm4: patch deprecating copy_side_data and suggesting to use copy_props on the ml
[22:29:13 CEST] <wm4> sounds fine
[22:44:45 CEST] <jamrial> for that matter, was sizeof(AVPacketSideData) meant to be part of the ABI?
[22:44:53 CEST] <jamrial> i ask because sizeof(AVFrameSideData) is not
[22:47:43 CEST] <wm4> that's unknown
[22:48:01 CEST] <wm4> since it's not explicitly documented as such, you probably have to assume that it's part of the ABI
[22:48:39 CEST] <wm4> actually, the packet side data is an array of structs
[22:48:45 CEST] <wm4> so it's definitely part of the ABI
[22:48:50 CEST] <wm4> I hate this inconsistent crap
[22:49:01 CEST] <jamrial> right
[22:49:14 CEST] <wm4> I wonder if ubitux will go through with making a reusable side data list thing
[22:50:28 CEST] <ubitux> didn't start, maybe tomorrow
[22:51:05 CEST] <jamrial> my intention was making packet side data refcounted, much like BBB did for frame side data, but guess that's not an option
[22:51:45 CEST] <wm4> at least not without some major deprecation dances
[22:51:46 CEST] <jamrial> can't add an AVBufferRef pointer to AVPacketSideData, and i have to assume downstream users implemented their own code handling side data, which would break badly
[22:52:25 CEST] <atomnuker> jamrial: we're bumping api versions soon, couldn't we change it (or do we have to wait 2 years)?
[22:53:08 CEST] <jamrial> i don't know. can we simply say "ok, this is not part of the abi anymore" after a bump?
[22:53:45 CEST] <wm4> no idea
[22:54:17 CEST] <wm4> I'd nuke it from orbit, and replace it with ubitux shiny yet-to-exist thing, and some painfully messy compat code
[22:54:19 CEST] <atomnuker> if anyone was using sizeof(AVPacketSideData) they'd have to recompile because abi isn't preserved so nothing would break in theory
[22:54:57 CEST] <ubitux> wm4: is that side data thing really rocket science?
[22:55:11 CEST] <wm4> not really
[22:55:26 CEST] <jamrial> atomnuker: it's more about existing code assuming it's part of the abi, manually handling side data instead of using the helpers and potentially breaking if we suddenly make it ref counted
[22:55:49 CEST] <nevcairiel> jamrial: technically you probably could, but the unfortunate part is that we cant really enforce that or even notify users if they are using it wrong, so its easy to cause subtle bugs
[22:56:00 CEST] <wm4> atomnuker: that's a bit naive... things could happen like API users accidentally copying a AVBufferRef* field without handling it properly etc.
[22:58:39 CEST] <wm4> what's the state of sizeof(AVPacket)
[22:58:52 CEST] <wm4> as long that is part of the ABI, nothing can happen
[22:59:13 CEST] <wm4> (tbh I'd just abolish ABI and rule that ABI only needs to be kept for minor releases)
[23:03:33 CEST] <rcombs> add a `char _padding[1024 * 1024 * 1024]` to the end of the struct, and subtract that from sizeof() when malloc()ing it
[23:03:40 CEST] <rcombs> that oughtta stop people from putting it on the stack
[23:04:34 CEST] <wm4> nice one, but UB
[23:04:41 CEST] <wm4> (probably)
[23:05:00 CEST] <nevcairiel> people came up with all sorts of ideas to try to get compilers to yell at you when you try
[23:05:05 CEST] <nevcairiel> but there is no clean way
[23:05:23 CEST] <rcombs> alternately move it to a private header and add getters and setters
[23:06:29 CEST] <nevcairiel> we're trying to go away from getters and setters again
[23:06:31 CEST] <nevcairiel> noone likes those
[23:07:59 CEST] <jamrial> what nobody likes is getters and setters for fields from structs in an installed header :p
[23:08:45 CEST] <wm4> setters and getters are annoying, but reasonable for opaque structs
[23:09:05 CEST] <wm4> what I don't like are setters and getters _and_ public or half-public fields _and_ AVOption crap all at once
[23:09:19 CEST] <JEEB> yup
[23:09:33 CEST] <rcombs> oh yeah that's dumb as hell
[23:27:42 CEST] <durandal_1707> wm4: so how filters should set its options?
[00:00:00 CEST] --- Tue Sep 26 2017