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

[burek]

[03:58:37 CET] <inventednight> hi all!
[10:31:55 CET] <durandal_1707> thilo: how long takes spi to send money?
[11:09:41 CET] <darkapex> durandal_1707: thx for the patch ill check with valgrind tonight. if you have any samples on which you know its failing to encode, share em pls!
[11:13:25 CET] <thilo> durandal_1707: I heard during the weekend you're still waiting for GSoC money like others. Usually it does not take this long, I'll check
[11:15:34 CET] <durandal_1707> darkapex: it fails with any sample with not 0000 number of samples at end, it works with lynne sample because it is cut
[11:16:07 CET] <darkapex> ah i see
[11:18:03 CET] <cone-036> ffmpeg 03Paul B Mahol 07master:efee86fafa9c: avfilter/vf_xfade: add circleopen & circleclose transition
[11:21:50 CET] <durandal_1707> darkapex: what case your first mlpenc patch fixes?
[11:22:08 CET] <durandal_1707> commit log seems illogical for me
[11:25:32 CET] <darkapex> yeah with the previous change number_sbits(-1) returned 1
[11:25:57 CET] <darkapex> which caused lossless failures for some files iirc
[11:26:36 CET] <darkapex> after this commit it returns 2. that is the only case for which output of number_sbits is changed
[11:27:22 CET] <darkapex> i will try to find the sample for which it was causing lossless errors on `number < 0` but not on `number < -1` 
[11:30:47 CET] <durandal_1707> darkapex: not needed, i see now
[11:31:04 CET] <darkapex> cool!
[11:31:22 CET] <darkapex> https://samples.ffmpeg.org/flac/When%20I%20Grow%20Up.flac this was the sample in any case
[11:32:12 CET] <darkapex> i think it had blocks with only 0s and -1s lol
[11:32:39 CET] <durandal_1707> :)
[11:37:44 CET] <cone-036> ffmpeg 03Jai Luthra 07master:c1c3916cec9c: mlpenc: fix lossless check error in number_sbits
[11:37:45 CET] <cone-036> ffmpeg 03Jai Luthra 07master:990990ed5d72: mlpenc: fix huff offset calculation
[11:37:46 CET] <cone-036> ffmpeg 03Jai Luthra 07master:ddeb58d58c77: mlpenc: prevent negative lsb_bits lshift
[11:37:47 CET] <cone-036> ffmpeg 03Jai Luthra 07master:bc0ed176024b: mlpenc: improve lpc filtering
[11:37:48 CET] <cone-036> ffmpeg 03Jai Luthra 07master:ad2638473486: mlpenc: clean up
[11:37:49 CET] <cone-036> ffmpeg 03Jai Luthra 07master:d6cef144e217: mlpenc: fix some -fsanitize=integer errors
[11:37:50 CET] <cone-036> ffmpeg 03Jai Luthra 07master:49cfbedb9d5a: mlp: check huff_lsbs only when codebook is used
[11:37:51 CET] <cone-036> ffmpeg 03Paul B Mahol 07master:c35382aaf471: avcodec/mlpenc: fix small memory leak
[11:44:44 CET] <darkapex> thanks durandal_1707 !
[18:31:04 CET] <cone-669> ffmpeg 03Paul B Mahol 07master:fcc0424c9337: avfilter/vf_ssim: improve precision
[18:32:55 CET] <durandal_1707> both fate and fatebeta are dead
[18:33:25 CET] <durandal_1707> bad infrastructure is killing this project
[19:29:03 CET] <durandal_1707> heh, nobody gives a shit, lets work on something else
[20:04:09 CET] <durandal_1707> michaelni: is fate gonna be fixed soon?
[20:05:33 CET] <michaelni> durandal_1707, fatebeta fixed
[20:06:21 CET] <durandal_1707> if this is similar hw issue like described in blog post?
[20:08:24 CET] <durandal_1707> BtbN: you uploaded testsrc or testsrc2 video?
[20:08:33 CET] <michaelni> i hope the server doesnt have such issues ;)
[20:09:21 CET] <BtbN> durandal_1707, testsrc
[20:11:30 CET] <durandal_1707> BtbN: who was listed as copyright owner?
[20:12:26 CET] <BtbN> durandal_1707, https://i.imgur.com/tMCoOaJ.png
[20:18:09 CET] <Polochon_street> Hi! I remember writing this https://github.com/Polochon-street/bliss/blob/master/src/decode.c#L226-L335 some time ago, which basically takes an audio input, converts it to s16le if it's not already the case, and then puts it into an uint8_t array
[20:18:26 CET] <Polochon_street> I'm wondering, how difficult would that be to make that thread multi-threaded, these days?
[20:18:52 CET] <Polochon_street> just asking for some pointers/links, because I have no clue where to start with, maybe my code is completely outdated and there are simpler way to do this?
[20:30:28 CET] <taliho> durandal_1707: fate seems to get stuck on some of the tags
[20:30:51 CET] <taliho> i.e... <tr class="slotfail" id="armv7l-panda-gcc4_6-armv4">
[20:31:55 CET] <taliho> maybe those results are being fetched from somewhere with a slow response?
[20:32:23 CET] <durandal_1707> i have no powers around fate in any way
[20:40:49 CET] <cone-669> ffmpeg 03Paul B Mahol 07master:a15618d2c3a2: avformat/sccdec: use av_sscanf() instead
[20:46:42 CET] <durandal_1707> taliho: arent those michael hw slots?
[20:48:35 CET] <taliho> i've got no idea
[22:50:04 CET] <Polochon_street> hm, the ability to use more threads for decoding/encoding in ffmpeg is dependent on the codec, right?
[22:52:27 CET] <BBB> yes
[22:52:39 CET] <BBB> most intra codecs support it generically (frame threading)
[22:52:56 CET] <BBB> and some inter codecs support it customly (vp8, vp9, h264, hevc, a couple of others)
[22:53:27 CET] <BBB> and then some codecs support slice (or tile) threading also, e.g. mpeg, h264, vp8/9? (iirc) and agin a couple of others
[22:53:31 CET] <Polochon_street> alright, because directly setting codec_context->thread_count to something higher than one works for, f.ex., flac, but not for mp3
[22:54:10 CET] <BBB> ah, audio is different
[22:54:15 CET] <Polochon_street> but I'm getting super confused at all these terms, came accross https://github.com/FFmpeg/FFmpeg/blob/master/doc/multithreading.txt
[22:54:30 CET] <BBB> or video, check AV_CODEC_CAP_FRAME_THREADS and AV_CODEC_CAP_SLICE_THREADS in AVCodec.capabilities
[22:54:37 CET] <Polochon_street> I'm only doing audio
[22:54:40 CET] <BBB> ../libavcodec/flacdec.c:    .capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS,
[22:55:10 CET] <Polochon_street> but this is inherent to the decoding process itself, right? If I'm processing stuff frame by frame, it should be transparent to me?
[22:55:24 CET] <BBB> yes
[22:55:37 CET] <BBB> api usage is no different
[22:55:50 CET] <Polochon_street> thanks a lot, that makes everything much simpler :D
[22:56:05 CET] <BBB> the likely explanation for audio is that overlapping stuff makes it hard to do frame-mt for compressed audio codecs
[22:56:41 CET] <BBB> I think Lynne knows more about that than me
[22:57:19 CET] <Polochon_street> BBB: that's what occured to me as well, it doesn't seem to work for ogg as well
[22:57:34 CET] <BBB> I'd expect it to only work for lossless audio codecs TBH, yes
[22:57:45 CET] <Polochon_street> that's still a huge improvement for me :D
[22:58:20 CET] <Polochon_street> (is there some helpers to get the current number of the computer's thread on ffmpeg, or should directly use pthread for that?)
[22:58:53 CET] <BBB> if you set thread_count to 0 or -1, and thread_type to frame, it should set it automatically
[22:59:23 CET] <BBB> -threads auto
[22:59:24 CET] <Lynne> Polochon_street: yes, for decoding the lapping makes it difficult to do threading, though in theory you could just wait until you have the previous frame and in the meantime decode whatever you can
[23:00:04 CET] <Lynne> won't work well with opus though, since opus has intra/inter frames where seeking is kinda pushing what desync is tolerable
[23:00:15 CET] <Polochon_street> okay
[23:00:20 CET] <Polochon_street> thanks for the detailed explanation
[23:00:34 CET] <Lynne> for encoding you can thread as much as you want though, in fact I did a quick opus encoder hack to do that
[23:01:16 CET] <Lynne> really no one has tried threading lossy audio decoders since they're not very slow, like both mp3 and opus are 500x realtime on a modern machine
[23:01:30 CET] <Polochon_street> oh, that's why as well
[23:01:48 CET] <Lynne> ac3 is I think even faster, 700x realtime
[23:02:17 CET] <Polochon_street> I always thought ac3 was crappy ^^'
[23:03:02 CET] <Lynne> its okay, the native encoder is good, but you still need at least 160kbps for stereo to sound acceptable
[23:03:34 CET] <Polochon_street> do you consider 128kbps for mp3 acceptable?
[23:07:07 CET] <Lynne> depends on the lame settings and content, its anywhere from okay (for simple things like piano) to not great (wall of sound)
[23:09:03 CET] <Polochon_street> oops(), setting `codec_context->thread_count = 0;` and `codec_context->thread_type = FF_THREAD_FRAME;` changes the number of samples
[23:10:15 CET] <Lynne> if its a lossless codec you'll definitely need to flush the decoder
[23:10:27 CET] <Polochon_street> it's flac, yep
[23:12:30 CET] <Polochon_street> is it something I should do at the end of the iteration, or regularly?
[23:13:18 CET] <nevcairiel> At the end of the file
[23:14:15 CET] <Lynne> it kind of happens naturally if you always expect a single packet to produce multiple frames
[23:14:26 CET] <Polochon_street> https://github.com/Polochon-street/bliss/blob/466f8571f8ec1ef815fe8241942bf8fa06d26a49/src/decode.c#L351-L358 isn't what I'm doing here?
[23:15:15 CET] <Lynne> no, you need to give the decoder a NULL packet and read out all the frames
[23:15:45 CET] <Lynne> in a loop, since with threading there won't be just 1 packet left but N, one for each thread usually
[23:16:06 CET] <Polochon_street> oh, so almost the same thing, except with a NULL packet?
[23:18:43 CET] <Lynne> well no, completely different since you need to call avcodec_receive_frame multiple times after you give a null packet
[23:19:23 CET] <Polochon_street> ah, so I send a NULL packet once, and then avcoded_receive_frame as long as it outputs something
[23:19:36 CET] <Polochon_street> sorry, I'm a bit slow but just restarted working on that :D
[00:00:00 CET] --- Wed Feb  5 2020