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

[burek]

[00:16:27 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:d39fae08866e: avfilter/avf_showspectrum: fix scaling in zoom mode
[02:27:31 CEST] <tmm1> jkqxz: the cbs patchset (https://github.com/fhvwy/FFmpeg/commits/cbs) no longer builds with master after 300ef253141fbebf9b201de676db1bb9e4298c40
[02:47:16 CEST] <tmm1> (the i'm also trying to make sense of this intermittent crash with that patchset, if anyone has an idea of what it could be: http://0x0.st/sYRW.txt
[05:11:12 CEST] <cone-398> ffmpeg 03Pavel Koshevoy 07master:03123e4053d6: lavfi/atempo: fix tempo range limit inconsistency
[12:03:54 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:3e687be4faa6: avfilter/avf_showspectrum: add green color map
[14:18:39 CEST] <nevcairiel> BBB: i thought about your question re: hwaccel with dav1d, and ultimately it would just need to expose the same sort of information and hooks that we make the avcodec decoders give to the hwaccel, except in this case in public  API, I guess
[14:20:37 CEST] <nevcairiel> plus of course being able to handle opaque frames with a caller-specified free callback
[14:21:32 CEST] <BBB> thats what I was hoping for, yes
[14:21:46 CEST] <BBB> I think most of the information you want is in levels.h
[14:21:50 CEST] <BBB> and is not changing much
[14:22:01 CEST] <BBB> you may need parts of internal.h Dav1dContext, but not that much I expect
[14:22:07 CEST] <nevcairiel> what we really need we wont know until the hw people define us an  API
[14:22:26 CEST] <nevcairiel> but generally speaking, everything from sequence and frame headers in raw uninterpreted form
[14:23:44 CEST] <BBB> yes, thats in levels.h
[14:23:50 CEST] <BBB> Im considering opening it up entirely already
[14:23:52 CEST] <BBB> since its there anyway
[14:23:57 CEST] <BBB> might just as well show it, right?
[14:26:31 CEST] <nevcairiel> and of course a variety of hooks in the decoding process, namely in avcodec terms: get_format, called whenever the frame format changes (size, bitdepth, chroma) - preferably only when it changes, and not too often, get_buffer to provide custom-allocated frames, and a decode hook that gets passed the entire frame data (including uncompressed headers, and all that), and circumvents actual software decoding
[14:27:02 CEST] <BBB> of course
[14:28:45 CEST] <nevcairiel> it'll probably be a bit more time until some of the hardware APIs even get support for this, but if you're open to putting this in, we could possibly make this work
[14:35:45 CEST] <atomnuker> pointless as by then <i>someone</i> will have ported dav1d to lavc
[14:36:38 CEST] <durandal_1707> but that is pointless as everybody are switching to rust
[14:39:14 CEST] <gnafu> But switching to Rust is pointless because everyone is actually switching to quantum computers.
[14:40:52 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:fe447c0609cd: avfilter/avf_showspectrum: add zoom mode to showspectrumpic
[14:41:48 CEST] <TD-Linux> yeah I don't see anything wrong with exposing AV1FrameHeader and AV1SequenceHeader. there is no reason for them to break ABI
[14:41:58 CEST] <TD-Linux> exposing Av1Block would be weird though
[14:42:48 CEST] <BBB> nevcairiel: absolutely open to it, yes
[14:42:58 CEST] <BBB> Im not sure you need Av1Block
[14:43:03 CEST] <BBB> since the block coding would happen in hw
[14:43:07 CEST] <BBB> they dont need access to sw internals
[14:43:13 CEST] <BBB> I think?
[14:44:25 CEST] <TD-Linux> I think that's correct
[14:44:34 CEST] <TD-Linux> but more importantly exposing Av1Block would hinder future optimizations
[15:24:36 CEST] <cone-210> ffmpeg 03Paul B Mahol 07master:50a2347b1949: avfilter/avf_showspectrum: increase padding size for low sample rates
[16:15:10 CEST] <atomnuker> bofh_: ping
[16:47:56 CEST] <January> Re-based a patchset which extracted timecodes from pic_timing in h264, trying to add support for extracting up to 3 timecodes per pic_timing SEI. Having issue with threading (-threads 1 works). https://0x0.st/sYFX.log (without -threads 1). https://github.com/januaryjp/FFmpeg/commit/b2f45ae089ea4c5e03a701d6c5f4c2e1f4f87d68
[16:48:03 CEST] <January> Unsure how I'd make it thread-safe
[16:56:00 CEST] <kierank> January: it's weird because captions should be thread safe
[16:57:55 CEST] <kierank> January: also try tsan
[17:28:31 CEST] <durandal_1707> what happened to new lavfi api?
[17:39:40 CEST] <atomnuker> you haven't proposed one?
[18:29:58 CEST] <kierank> January:  memcpy(tcside->data, &tc, sizeof(uint32_t));
[18:29:59 CEST] <kierank> looks dubious
[18:30:28 CEST] <kierank> tc is int64
[18:31:59 CEST] <January> unsure why the original patch used int64, guess could make tc uint32 but i removed the memcpy anyway
[18:32:49 CEST] <kierank> does it help
[18:35:07 CEST] <January> no
[18:38:27 CEST] <kierank> I think side data is totally broken
[18:38:35 CEST] <kierank> michaelni: how is side data guaranteed to be accurate?
[18:45:45 CEST] <durandal_1707> michaelni is busy, do not disturb him
[18:47:34 CEST] <BBB> wut
[18:48:12 CEST] <kierank> January has discovered side data is not frame accurate
[18:48:16 CEST] <kierank> with frame threads
[19:08:28 CEST] <lotharkript_> sorry to ask again, but commit http://git.videolan.org/?p=ffmpeg.git;h=ddef3d902f0e4cbd6be6b3e5df7ec158ce51488b  enabled passing through of rotation side data from input to output using stream side data. This is an issue when using HW filter to rotate, because we have no way of clearing this side data after rotation. Is there a way to clear stream side data for output, from command line ?
[19:11:53 CEST] <durandal_1707> lotharkript_: sidedata filter?
[19:12:21 CEST] <lotharkript_> do we have one for stream side data?
[19:12:28 CEST] <lotharkript_> it is not in the avframe
[19:13:34 CEST] <lotharkript_> mp4 muxer get it from av_stream_get_side_data
[19:14:15 CEST] <lotharkript_> if you want to use HW filter, you have to add the option -noautorotate in the cmd line (so, the software rotation is not inserted)
[19:14:28 CEST] <lotharkript_> but that will copy the stream_side data to the output.
[19:17:58 CEST] <durandal_1707> lotharkript_: no way AFAIK, send patch to fix it, adding function to remove stream side data and update ffmpeg utility
[19:18:50 CEST] <lotharkript_> i can add the function to remove side data, but the filter should be the one to remove the side data or at least update it.
[19:19:03 CEST] <lotharkript_> the problem is that filter does not have access to avstrem, no?
[19:20:05 CEST] <durandal_1707> no, filters deals with frames only
[19:20:29 CEST] <lotharkript_> exactly, so how do you specify you do want to add/remove/update avstream side data?
[19:20:53 CEST] <lotharkript_> i'm ok to do the code, just want to talk about the correct way first
[19:20:54 CEST] <durandal_1707> so you would not deal with filters, but with ffpeg -remove_this_stream)side_data 
[19:21:26 CEST] <lotharkript_> ok.. So, you suggest to add options in the command line to update stream_side_data?
[19:21:52 CEST] <durandal_1707> something like that, if you have better idea - i'm all ears
[19:26:20 CEST] <kierank> durandal_1707: can you fix side data frame accuracy
[19:26:28 CEST] <lotharkript_> This is what we though as well, but before coding it, wanted to check with you all
[19:44:22 CEST] <tmm1> it seems that get_bits() and UPDATE_CACHE don't do bounds checking even when checked mode is enabled?
[19:45:15 CEST] <nevcairiel> we require all compressed input to be padded, in any case
[19:47:50 CEST] <tmm1> ah, i dont think the cbs userdata patches have padding
[19:58:13 CEST] <tmm1> how much padding is used?
[19:58:43 CEST] <JEEB> AV_INPUT_BUFFER_PADDING_SIZE I think?
[19:58:49 CEST] <jamrial> yes
[20:04:28 CEST] <durandal_1707> kierank: i think one would need to reorder captions anyway?
[20:04:41 CEST] <kierank> exactly
[20:04:45 CEST] <kierank> it's broken with threads
[20:04:54 CEST] <kierank> might have worked by chance before
[20:07:32 CEST] <durandal_1707> lotharkript_: what about sharing all samples that do not decode with latest ffmpeg?
[20:08:22 CEST] <lotharkript_> durandal_1707: which samples are you talking about?
[20:10:15 CEST] <durandal_1707> lotharkript_: any sample :)
[20:11:09 CEST] <lotharkript_> most are user data, so under GDPR, i cannot share them.
[20:14:37 CEST] <durandal_1707> lotharkript_: can you share info about which container and codec is in?
[20:15:25 CEST] <lotharkript_> if i found some, i think i can let you know.
[20:17:04 CEST] <lotharkript_> one thing you may want to ask michael is the coverage result from oss-fuzz. There are a LOT of codecs where the coverage is under 25%
[20:23:05 CEST] <tmm1> thanks. looks like ASAN agrees there's a heap overread, so the padding is definitely missing
[20:23:46 CEST] <JEEB> coolio
[20:24:00 CEST] <JEEB> just means when it gets allocated it needs some padding love
[20:24:36 CEST] <tmm1> might be tricky to do since i think its just creating a GBC off the original stream
[20:24:59 CEST] <JEEB> yea, probably :)
[20:25:02 CEST] <tmm1> http://0x0.st/sgsr.txt
[20:25:07 CEST] <JEEB> so there might have to be memcpy somewhere
[20:25:17 CEST] <tmm1> yea, ugh.
[20:25:25 CEST] <JEEB> inorite
[20:25:31 CEST] <tmm1> man asan output is nice though, first time i've used it successfully
[20:25:54 CEST] <JEEB> yea I need to get to that, since valgrind can be just impossible to use due to the speed overhead
[20:28:35 CEST] <tmm1> yay that was easier fix than expected
[20:28:42 CEST] <tmm1> -        current->user_data_ref = av_buffer_alloc(k);
[20:28:42 CEST] <tmm1> +        current->user_data_ref = av_buffer_alloc(k + AV_INPUT_BUFFER_PADDING_SIZE);
[20:29:12 CEST] <JEEB> yup
[20:33:22 CEST] <jamrial> tmm1: memset that padding to 0 as well
[20:35:14 CEST] <tmm1> ah good idea, will change to av_buffer_allocz
[20:40:53 CEST] <jamrial> just do memset(current->user_data_ref->data + k, 0, AV_INPUT_BUFFER_PADDING_SIZE); instead
[20:41:27 CEST] <jamrial> no point zeroing the whole buffer if you're going to immediately write to it afterwards, just to zero the padding
[21:32:57 CEST] <tmm1> true, but its only a few bytes. h264 side calls allocz always already too
[21:33:13 CEST] <tmm1> also doesn't the kernel zero pages in the background or something, i thought calloc was optimized in certain cases
[21:34:10 CEST] <tmm1> i guess anything the kernel does would be for safety across process boundaries, within the process the malloc impl would still need to zero any time a block was reused
[00:00:00 CEST] --- Sat Oct  6 2018