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

[burek]

[00:30:54 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:47a4528abc97: avformat/utils: Don't initialize in loops
[00:30:55 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:bf79e4426a94: avformat/utils: Fix memleaks II
[00:30:56 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:ada02cf85fff: avformat/utils: Don't create unnecessary references
[00:30:57 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:cdba00ae113c: avformat/utils: Avoid copying packets unnecessarily
[00:30:58 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:5c95af6b7c8e: avformat/utils: Improve parsing packets
[00:30:59 CEST] <cone-144> ffmpeg 03Andreas Rheinhardt 07master:9fdc2c7bc45b: avformat/utils: Remove unnecessary initializations
[14:25:30 CEST] <durandal_1707> ceilf/truncf is not in C90 so FFmpeg cant use it?
[14:29:58 CEST] <durandal_1707> FFmpeg should switch to C99
[14:34:02 CEST] <Lynne> ceilf is assumed to always be available, and truncf is automatically added if it doesn't exist
[15:02:57 CEST] <durandal_1707> here you go: scroll filter
[15:03:34 CEST] <durandal_1707> no more ideas to do
[15:12:28 CEST] <Lynne> finish the decoder you started?
[15:13:04 CEST] <Lynne> also tried arnndn, it sounded worse than anlmdn
[15:19:23 CEST] <durandal_1707> Lynne: anlmdn is much slower and does not work for speech extraction at all, it just try to iron waves
[15:24:14 CEST] <durandal_1707> Lynne: also what model you tried? i extracted std.rnnn -> default model used by rnnoise
[15:41:40 CEST] <Lynne> I tried all, couldn't find the standard ("orig" in the rnnoise-models readme) one
[15:42:20 CEST] <Lynne> it was much faster though, yes
[15:52:22 CEST] <durandal_1707> Lynne: anlmdn is exponentially slower for high sample rates
[16:10:47 CEST] <mkver> michaelni: Valgrind complains about jumps depending on uninitialized values in your recent fitsdec patch cfa19377. See http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=20190927003223
[16:46:25 CEST] <durandal_1707> Lynne: i just checked, arnndn output is almost bit exact with rnnoise output, differences are pretty small
[16:48:48 CEST] <durandal_1707> and yes, if you just listened at removed signal (with original/std model), arnndn is worse in typical scenarios than anlmdn
[17:25:05 CEST] <michaelni> mkver, will fix it, thanks
[17:34:41 CEST] <jamrial> mkver, michaelni: i sent a patch fixing it last night
[17:35:54 CEST] <mkver> Sorry. Should have checked the ML before reporting it.
[17:45:34 CEST] <cone-852> ffmpeg 03James Almer 07master:e3f0ecfc5788: avcodec/fitsdec: fix use of uninitialised values
[17:48:36 CEST] <durandal_1707> is my change to qtrle and muxing fine?
[17:50:59 CEST] <durandal_1707> https://patchwork.ffmpeg.org/patch/15327/
[17:51:11 CEST] <durandal_1707> https://patchwork.ffmpeg.org/patch/15286/
[18:23:08 CEST] <kierank> durandal_1707: yes
[18:50:00 CEST] <cone-852> ffmpeg 03Andreas Rheinhardt 07master:f3333c3c67e8: avcodec/cbs_h2645: Fix potential out-of-bounds array access
[18:50:01 CEST] <cone-852> ffmpeg 03Andreas Rheinhardt 07master:1929dd4eff93: avcodec/cbs_av1: Make overread check more robust
[20:44:08 CEST] <cone-852> ffmpeg 03Paul B Mahol 07master:4a51075f4db1: doc/examples/muxing: fix underflow in duration of encoded streams
[20:54:54 CEST] <durandal_1707> crap, my change is incorrect, this looks like mov strangeness
[21:05:31 CEST] <jkqxz> cehoyos:  The 10-bit RGB + 2-bit alpha format is a standard one for hardware.  E.g. it's in OpenGL as GL_RGB10_A2, Vulkan as VK_FORMAT_A2R10G10B10_*, OpenCL as CL_RGBA + CL_UNORM_INT_101010_2.
[21:06:02 CEST] <jkqxz> It's not a particularly useful intermediate, but it would be good to have it for direct rendering cases.
[21:06:42 CEST] <cone-852> ffmpeg 03Paul B Mahol 07master:f1e17eb44657: avcodec/qtrleenc: fix undefined behaviour
[21:07:53 CEST] <jkqxz> That VAAPI tonemap filter isn't what you want the ffmpeg utility for transcode cases, but it might be useful when rendering to output in a player.
[21:10:12 CEST] <jkqxz> The inclusion of alpha there doesn't make any sense, though.  The format should be 10-bit RGB with two ignored bits, like OpenCL's CL_RGB + CL_UNORM_INT_101010.
[21:12:15 CEST] <jkqxz> I think there is a lot of confusion around alpha in the H.265 stuff they have, too.  I'm not entirely sure because I don't have any hardware to look at, but I don't think the hardware they're talking about supports any alpha channel at all in H.265.
[22:01:08 CEST] <cehoyos> jkqxz: There are hevc samples with alpha
[22:01:33 CEST] <cehoyos> jkqxz: I now that the format is standard on Windows, my point is that it would be a new useless format in FFmpeg
[22:01:38 CEST] <cehoyos> s/now/know
[22:02:16 CEST] <cehoyos> Why is the vaapi tonemap filter not useful? Intel hardware is certainly more common than float formats...
[22:03:15 CEST] <jkqxz> It's standard in hardware, independent of Windows.  E.g. Linux DRM allows all variations: <https://cgit.freedesktop.org/mesa/drm/tree/include/drm/drm_fourcc.h#n137>.
[22:04:54 CEST] <jkqxz> I mean I'm thinking it's not very useful in the FFmpeg utility specifically.  It might be useful to have it in the library for players to use.
[22:05:43 CEST] <cehoyos> I believe I also asked about the video players but no answers...
[22:09:06 CEST] <jkqxz> On hevc+alpha - yes, but it comes as two independently-decodable layers.  You get at most three components in a single-layer stream.
[22:16:11 CEST] <cehoyos> jkqxz: It should come out as one frame from the decoder
[22:16:20 CEST] <cehoyos> And the Intel developers claim it does
[22:20:05 CEST] <cone-852> ffmpeg 03Michael Niedermayer 07master:47b0d0812e77: tools/target_dec_fuzzer: Adjust VP7 threshold
[22:53:40 CEST] <rcombs> jkqxz: hmm, could you elaborate on the VAAPI tonemap filter, and how it differs from e.g. lavfi's?
[22:53:58 CEST] <thardin> https://codecs.multimedia.cx/2019/09/going-to-the-7th-level-for-the-grail/
[23:13:44 CEST] <cehoyos> rcombs: It accepts a sane input format.
[23:14:08 CEST] <rcombs> so does lavfi's OpenCL one, doesn't it
[23:15:36 CEST] <JEEB> I think the only "insane" part of floating point linear RGB is that nobody added the swscale part for it. which, to be completely honest, I'm not really surprised about.
[23:15:47 CEST] <JEEB> it's nice if the opencl one handles the most common cases, though.
[23:15:59 CEST] <JEEB> because IIRC niklas talked rather well with the intel person making it
[23:16:11 CEST] <JEEB> and thus it should technically be in a better state than the lavfi one?
[23:16:56 CEST] <cehoyos> rcombs: No, it does not
[23:21:13 CEST] <philipl> jkqxz: did you have a change to look at my hw transfer changes?
[23:21:51 CEST] <philipl> *chance
[23:25:27 CEST] <rcombs> cehoyos: in that OpenCL isn't well-supported in lavfi, or&?
[23:26:18 CEST] <rcombs> JEEB: I end up concerned about it for perf reasons; seems like combining that math into a single pass would be faster
[23:27:36 CEST] <JEEB> rcombs: could be
[23:29:21 CEST] <cehoyos> Sorry, I misread above question: The hardware-based tonemap filters are more useful than the software filter (is what I was trying to say)
[23:29:48 CEST] <cehoyos> Or: The vaapi filter will be once there is pipeline for what it outputs
[23:34:18 CEST] <rcombs> I've been wanting to extract a bunch of utility functions out of vf_colorspace and into some generic lavfi or lavu APIs
[23:34:56 CEST] <rcombs> like, getting conversion matrices, and applying transforms on individual colors (would be useful to drag drawutils.c out of BT601-land)
[23:36:43 CEST] <JEEB> personally I would look into just pulling in zimg if the primary problem is that it's not part of the source code (although I'm pretty sure people will have issues with the fact that it's C++ and opted for intrinsics)
[23:36:59 CEST] <JEEB> since you have AVX2 and AVX512 SIMD in zimg and the license is WTFPL
[23:38:37 CEST] <rcombs> well, I'm saying that all the conversions should be built into vf_tonemap
[23:38:55 CEST] <rcombs> so you can do 1-pass YUV->YUV
[23:39:54 CEST] <JEEB> I'm not sure how well tone mapping works in YCbCr?
[23:41:01 CEST] <rcombs> poorly, I'd imagine; you'd go to RGB and back
[23:41:14 CEST] <rcombs> per-pixel
[23:41:49 CEST] <rcombs> but that makes it just a few muls and no extra memory bandwidth requirement
[23:42:11 CEST] <JEEB> so yea. the base steps would still be the same. main difference is that you'd just be holding it in a single filter vs having the linear rgb'ification separate
[23:42:16 CEST] <rcombs> right
[23:42:47 CEST] <JEEB> might need actual benchmarks to define it, but if it's worth it I'd say I'm OK with having that in there as long as it handles the content according to the input AVFrame
[23:47:39 CEST] <rcombs> my _guess_ would be that you could do this today in the C filter (just by pulling in the matrix generation from vf_colorspace) and it'd be equivalent to or faster than the current route that uses ASM for the space conversion, because a few extra muls + int<->floats in the filter function are cheaper than round-tripping the floats through memory
[23:48:00 CEST] <rcombs> but I haven't benched
[23:52:02 CEST] <rcombs> hmmm, I wonder what the best way to handle multiple tonemap functions in ASM would be
[23:52:48 CEST] <rcombs> there's the obvious "macro-ize it and duplicate the entire filter routine for each one" option
[23:53:29 CEST] <rcombs> or you could do something along the lines of the C's switch/case, which is _probably_ pretty branch-predictor-friendly; not sure what that kind of thing does to your pipeline, though?
[00:00:00 CEST] --- Mon Sep 30 2019