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

burek burek021 at gmail.com
Fri Jul 21 03:05:04 EEST 2017


[01:22:47 CEST] <SolarAquarion> what can go wrong if i disable the building of avdevice.so
[01:23:56 CEST] <JEEB> don't spam
[01:25:15 CEST] <SolarAquarion> sorry
[05:34:15 CEST] <cone-591> ffmpeg 03James Almer 07master:3cd616a0c958: avdevice: make ff_reverse available on shared builds
[07:00:30 CEST] <cone-591> ffmpeg 03James Almer 07master:0a813ca091c8: fate: add libavdevice/reverse.c to fate-source
[07:32:45 CEST] <rcombs> in which I try to suggest a change to the matroska documentation: https://gist.githubusercontent.com/rcombs/0f42e186081b114a55676e4dc3106ebf/raw/2ec4ec93725503bd3fd22c442fafac60d538cfea/gistfile1.txt
[09:25:30 CEST] <cone-591> ffmpeg 03Rostislav Pehlivanov 07master:3aca16e857a1: opus_rc: fix CDF encoding of zeroes
[12:14:25 CEST] <J_Darnley> I don't understand any of this shit.  Why does using threads cause this?  Why does a race when writing cause zeros?  As far as I can tell it shouldn't even be writing to the same location.
[12:34:59 CEST] <kierank> J_Darnley: have you tried disabling threads for golomb encoding
[12:35:18 CEST] <J_Darnley> no
[12:35:41 CEST] <J_Darnley> I expected the problem to be in my threaded slice-based transform
[12:35:52 CEST] <J_Darnley> If I disable threads for that one part it is all fine
[12:37:56 CEST] <J_Darnley> I will try that though
[12:41:24 CEST] <J_Darnley> Nah.  That didn't change anything
[13:54:59 CEST] <iive> J_Darnley: race when writing causing zeroes, this sounds more like cache coherenci bug.
[13:55:38 CEST] <iive> J_Darnley: could you fill the write buffer with something else than zeroes, before you start.
[13:56:03 CEST] <iive> and maybe use movntq and memofy fence
[14:05:31 CEST] <J_Darnley> Well I don't *know* it is zeros, just the common corruption is black and green (chroma 0) after decoding
[14:05:44 CEST] <J_Darnley> I might try writing something there
[17:12:07 CEST] <ZeroWalker> doesn't ffmpeg have some kind of automatic audio buffer thing to push samples until it reaches the frame size to then encode it. i suck at circular buffers
[17:28:30 CEST] <atomnuker> ZeroWalker: libswresample can do that for you
[17:30:14 CEST] <ZeroWalker> it can? thing is the input is variable in sample size (as it's capture). I am trying to use libswresample for format conversion atm, but not sure how to use it for "frame size filling"
[17:41:44 CEST] <kierank> ZeroWalker: av_fifo
[17:42:05 CEST] <kierank> using swresample is using a hammer to crack an egg
[18:00:38 CEST] <nevcairiel> audio fifos are trivial, and yeah we have avutil/audio_fifo.h
[18:12:47 CEST] <ZeroWalker> will give it a look:)
[18:32:04 CEST] <paras_2052> durandal_1707: Hi, There was an issue in the FITS decoder with RGB48 and RGBA64 images which i have fixed now. i am sending the updated patch on ML in a few minutes. Please wait before applying the patch.
[18:32:39 CEST] <durandal_1707> paras_2052: ok
[19:09:13 CEST] <leif> Can anyone tell me what the version tags in the git repo are for? I ask because there seems to be differences from the 3.3.2 download on the website and the n3.3.2 tag in the git repo.
[19:14:29 CEST] <leif> Ah, never mind. I am apparently just bad at typing. (n3.3.2 != n3.2.2 ...)
[19:17:06 CEST] <atomnuker> holy shit float dwt asm
[19:17:31 CEST] <atomnuker> ...its a shufps fest
[19:39:39 CEST] <durandal_1707> im getting sick
[19:41:27 CEST] <kierank> sick of what
[19:43:39 CEST] <durandal_1707> of certain entity on devel ml
[19:45:30 CEST] <kierank> ffmpeg needs to move to "everything is a filter" api
[19:47:42 CEST] <kierank> in modern multimedia the distinction between container and codec is dead
[19:49:01 CEST] <durandal_1707> kierank: where?
[20:43:12 CEST] <BBB> uhm
[20:43:15 CEST] <BBB> michaelni: so uh
[20:43:28 CEST] <BBB> michaelni: I fear one of us is going to have to dig into this patch from wtc@ in tsan warning about a data race in libavcodec/h264_direct.c
[20:44:03 CEST] <BBB> michaelni: unless we can encourage Gramner to look at it
[20:44:12 CEST] <BBB> michaelni: so& should we toss a coin or so?
[21:32:17 CEST] <ZeroWalker> hmm, if i want to convert from one audio format to another, how do you work out the buffer data thing, as it's an array (for non planar). And i guess float is non planar?
[21:33:40 CEST] <iive> why not?
[21:35:42 CEST] <Blubberbub> Doesn't planar mean: channels are separate data blocks and non-planar the channel samples are "interleaved"? From my (very basic) understanding one could have float-planar data: AV_SAMPLE_FMT_FLTP
[21:35:59 CEST] <BBB> Blubberbub: thats correct
[21:36:06 CEST] <BBB> ZeroWalker: just use swresample
[21:36:27 CEST] <BBB> ZeroWalker: theres example code for swresample all over the place (in the tree, on stackoverflow, etc.)
[21:38:13 CEST] <iive> Blubberbub: both should support floats
[21:40:09 CEST] <Blubberbub> from my "reading ffmpeg code for a few days"-exercise i feel like the signed-formats are the ones that need the most conversion and are the hardest to work with
[21:41:01 CEST] <J_Darnley> ?  Signed audio makes the most sense
[21:41:14 CEST] <Blubberbub> ah unsigned
[21:41:19 CEST] <Blubberbub> i wanted to say unsigned
[21:41:39 CEST] <Blubberbub> the formats that don't have silence = 0
[21:42:05 CEST] <J_Darnley> Some might say that silence is any constant value :)
[21:44:12 CEST] <Blubberbub> hmm.... never thought about that
[21:44:30 CEST] <Blubberbub> just took me a while to understand that :D
[21:45:59 CEST] <Blubberbub> mixing to signals by addition does not work that easy with unsigned pcm in comparison to signed pcm, right?
[21:49:34 CEST] <BBB> you have to subtract a base, yes
[21:49:54 CEST] <BBB> if you think of it as averaging, it makes more sense
[21:50:14 CEST] <BBB> I guess it does not, actually
[21:50:15 CEST] <BBB> anyway
[22:17:27 CEST] <ZeroWalker> that's what i confused, i get the error "Output Changed". Basically i try to use swr_convert_frame, so the input has all the format stuff set and has been filled. The output has been set as well (but it has no buffer as from my understanding it will be allocated on the spot if needed).
[00:00:00 CEST] --- Fri Jul 21 2017


More information about the Ffmpeg-devel-irc mailing list