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

burek burek at teamnet.rs
Wed Sep 18 03:05:05 EEST 2019


[00:30:53 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:ef50cf7b32b9: avcodec/hevcdec: Fix memleak of a53_caption
[03:44:01 CEST] <tmm1> jkqxz: wdyt of http://ffmpeg.org/pipermail/ffmpeg-devel/2019-September/249905.html; would it be better to remove the unions altogether?
[15:02:05 CEST] <cone-101> ffmpeg 03Andreas Rheinhardt 07master:34bd293b014e: avformat/mov: Fix memleak
[15:02:05 CEST] <cone-101> ffmpeg 03Andreas Rheinhardt 07master:2b1fcba8ddcb: fftools/ffmpeg_opt: Fix signed integer overflow
[15:02:05 CEST] <cone-101> ffmpeg 03Michael Niedermayer 07master:093d1f42507e: avformat/mov: Check for EOF in mov_read_meta()
[15:02:05 CEST] <cone-101> ffmpeg 03Michael Niedermayer 07master:65589ad55349: tools/target_dec_fuzzer: Adjust threshold for binkvideo
[15:19:22 CEST] <nevcairiel> You would think people trying to report such static analyzer problems actually knew a bit of C
[15:24:15 CEST] <BtbN> "Wow, what is the point? norm = norm?" -_-
[15:25:26 CEST] <nevcairiel> that one for example
[15:25:32 CEST] <nevcairiel> read the entire line :p
[15:26:54 CEST] <BtbN> Yes, not a single one of those which I looked at are in any way a problem.
[15:27:09 CEST] <BtbN> "This else is not possible)) I suppose. All variants are already checked."
[15:27:17 CEST] <BtbN> You don't say, which is why it return a BUG
[15:27:17 CEST] <nevcairiel> some things have a bit of redundant code in  it, but often in the name of clarity
[15:31:00 CEST] <mkver> And somehow it thinks that stuff initialized through AV_WL/AV_WB macros are not really initialized.
[15:31:35 CEST] <BtbN> It's probably some pimped up linter, and not even a static analysis.
[15:35:44 CEST] <nevcairiel> pvs-studio keeps popping up every couple years, I wouldn't be surprised if some people are sponsored by the creators of such tools to go analyze open-source code and make sure to mention their tools name
[15:36:12 CEST] <BtbN> Well, it's pretty bad publicity they get from this.
[15:36:20 CEST] <BtbN> Really not a single thing it finds is correct.
[15:42:34 CEST] <mkver> I wouldn't go so far.
[15:43:34 CEST] <mkver> These array overrun errors in cbs_h2645 are genuine.
[15:46:28 CEST] <nevcairiel> i dont see any mention of cbs in that pvs ticket
[15:55:27 CEST] <mkver> Lines 651-2231 in the list of tasks are about cbs.
[15:55:49 CEST] <mkver> You ignored the attached file, didn't you?
[15:57:35 CEST] <BtbN> There is _even more_ oO
[15:58:06 CEST] <BtbN> I'd say ignoring this entire report is safe. Anything serious will be catched by coverity already.
[15:58:18 CEST] <BtbN> And people ignore that all the time as well.
[16:00:38 CEST] <nevcairiel> obviously i'm not going to read some large random report some random person attaches in a random ticket :p
[16:00:57 CEST] <nevcairiel> which probably even needs their tool to read properly
[16:01:44 CEST] <nevcairiel> mostly because its just unproductive to find the one good hit in the noise of nonsense
[20:44:36 CEST] <Lynne> pushed a finally working version of the vulkan patchset here - https://github.com/cyanreg/FFmpeg/tree/vulkan
[20:45:39 CEST] <Lynne> could do asynchronous filtering for most filter but won't need an api change, just a few hundred lines of tedious management code
[20:45:43 CEST] <Lynne> durandal_1707: happy now?
[20:46:10 CEST] <durandal_1707> Lynne: what i need to install vulkan?
[20:46:39 CEST] <durandal_1707> and does this framework works with multiple vulkan filters in single graph?
[21:08:59 CEST] <Lynne> durandal_1707: on debian just install glslang-dev, should pull in the rest of the vulkan headers
[21:09:39 CEST] <Lynne> ./ffmpeg_g -init_hw_device "vulkan=vk:0,debug=1" -init_hw_device "vaapi=vp:/dev/dri/renderD128" -hwaccel vaapi -hwaccel_output_format vaapi -i sample.mkv -hwaccel vaapi -hwaccel_output_format vaapi -i sample2.mkv -filter_hw_device vk -filter_complex "[0:0] hwmap,format=vulkan [s1] ; [1:0] hwmap,format=vulkan [s2] ; [s2] avgblur_vulkan=sizeX=9:sizeY=9 [s2] ; [s1] chromaber_vulkan=dist_x=9:dist_y=9 [s1] ;
[21:09:41 CEST] <Lynne> [s1] [s2] overlay_vulkan=x=320:y=90 [d1] ; [d1] scale_vulkan=w=640:h=-1 [d1] ; [d1] avgblur_vulkan=sizeX=5:sizeY=5 [d1] ; [d1] hwdownload,format=nv12 [d1]" -map "[d1]" -c:v rawvideo -y test.nut
[21:10:20 CEST] <Lynne> you can chain as many filters as you want and even overlay like the example I pasted
[21:11:20 CEST] <Lynne> you need libdrm to map from vaapi though in addition to libva-dev
[21:39:50 CEST] <philipl> Lynne: nice.
[21:40:15 CEST] <philipl> are you eventually going to implement mapping back to vaapi/drm/cuda?
[22:02:15 CEST] <Lynne> philipl: there is mapping from vulkan to vaapi/drm already, it works
[22:05:12 CEST] <Lynne> want to do the cuda mapping? should be just a matter of moving everything under "if (!dst_int || !dst_int->cuda_fc_ref) {" in a new function and calling it to export to cuda, then do the memcpy
[22:24:00 CEST] <cone-659> ffmpeg 03Paul B Mahol 07master:251284e44aa5: avfilter/vf_v360: add mercator projection
[22:31:38 CEST] <JEEB> wow
[22:31:49 CEST] <JEEB> the "old" subtitle decoding mode is the default still
[22:31:49 CEST] <JEEB> TIL
[22:50:06 CEST] <philipl> Lynne: Theoretically, I'd like it, but it will take a while to get to it.
[22:50:21 CEST] <philipl> If you're happy to wait, then sure. Certainly wouldn't block merging what you have.
[22:54:40 CEST] <Lynne> k, I'll try to do it tonight
[23:02:32 CEST] <Lynne> are there semaphores I need to signal in a cuda frame?
[23:07:50 CEST] <philipl> So, you'd need an additional semaphore to deal with the case that a frame has been passed on for mapping to cuda but now something wants to reuse the frame for new content. I'm not sure that would ever happen though. As the frame would presumably not be available until read.
[23:08:59 CEST] <philipl> Another case would be if the frame producer might not have finished writing the frame when you map it. Then you'd want a semaphore for cuda to wait on before doing the memcpy
[23:09:16 CEST] <philipl> Again, that might not actually happen.
[23:24:29 CEST] <Lynne> cu->cuCtxPushCurrent(cuda_dev->cuda_ctx) segfaults... in libvulkan according to gdb
[00:00:00 CEST] --- Wed Sep 18 2019


More information about the Ffmpeg-devel-irc mailing list