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

[burek]

[01:58:16 CET] <cone-430> ffmpeg 03Michael Niedermayer 07master:038d291b70bf: avcodec/qpeg: Optimize long runs in qpeg_decode_intra() not spanning a full row
[09:12:13 CET] <durandal_1707> atomnuker: i'm very dissapointed
[12:22:03 CET] <cone-914> ffmpeg 03Peter Ross 07master:2659a0fe3632: avcodec/vp3data: use more compact data type
[13:45:44 CET] <atomnuker> durandal_1707: don't be, I bet you get no mold over there to waste half a day cleaning only for it to grow back in a week
[13:46:46 CET] <durandal_1707> atomnuker: where you live? it is dangerous?
[13:53:38 CET] <kierank> atomnuker: same in the office, cleaned it a month ago and it's coming back
[14:41:03 CET] <atomnuker> durandal_1707: not even in a basement, on the 3rd floor
[14:47:56 CET] <Compn> touchpad is the best
[14:48:10 CET] <Compn> i need a new touchpad mouse 
[15:39:40 CET] <durandal_1707> Compn: mplayer is dead, hooraay
[15:44:08 CET] <BBB> is it? is it?
[15:45:04 CET] <durandal_1707> why you typed same thing twice?
[15:45:10 CET] <BBB> excitement
[15:51:59 CET] <durandal_1707> if human neurons were stored in RAM how much would it take?
[15:55:27 CET] <thardin> you could build a little fort out of RAM stick and put a brain inside it
[15:55:32 CET] <thardin> sticks
[16:23:12 CET] <atomnuker> durandal_1707: welp, its kinda difficult to define
[16:23:30 CET] <atomnuker> what stores neuron state such that if "resumed" it'll execute the exact same operations
[16:24:20 CET] <atomnuker> there's an internal state within the neuron itself which accumulates and upon an adapted treshold fires whatever's connected to the axon, be it a single other neuron/no neurons at all/multiple neurons
[16:24:47 CET] <atomnuker> but the really messed up thing is how the individual connections to each neuron are stored
[16:25:17 CET] <atomnuker> e.g. the weight of each connection to the neuron from other neurons
[16:25:45 CET] <atomnuker> and its the distance the charge has to travel to reach the center
[16:26:45 CET] <atomnuker> so if you wanted to store an ideal copy, you'd need the positions of pretty huge amount of atoms inside the brain, plus their states
[16:29:21 CET] <thardin> there's evidence that there's quantum effects at play too, so that may not necessarily be enough
[16:29:28 CET] <atomnuker> indeed
[16:29:51 CET] <thardin> it might not actually be computable, despite what transhumanists would have you believe
[16:29:59 CET] <BradleyS> what if most of the brain's atoms are inert gases
[16:30:32 CET] <atomnuker> thardin: that way no, but I really don't think its necessary to emulate the electrochemistry of neurons perfectly
[16:30:57 CET] <thardin> perhaps not. depends on what you want to do
[16:31:24 CET] <thardin> openworm has a simulation of c. elegans "brain", which may or may not be accurate
[16:31:44 CET] <atomnuker> that's the thing if accurate == accurate in the real world
[16:32:12 CET] <atomnuker> but what if you need accurate == good enough to function and survive within its new environment
[16:32:47 CET] <atomnuker> sure, it'll deviate from real world behavior but it'll work and function exactly as before on a macroscale
[16:36:58 CET] <durandal_1707> atomnuker: what about commenting patch?
[16:38:33 CET] <atomnuker> I didn't see anything code-wise that looked wrong but I still need to test it
[17:40:20 CET] <atomnuker> jamrial: can libdav1d now render to user-given frames?
[17:43:29 CET] <durandal_1707> due to lack of comments and force i will apply anlmdn asap!
[17:43:51 CET] <jamrial> atomnuker: i think so, but afaik we can't use get_buffer2() with it
[17:44:11 CET] <jamrial> we can't ensure the constrains will be met
[17:44:39 CET] <BBB> atomnuker: dav1d's constraints are that the buffer needs to be superblock aligned
[17:44:46 CET] <BBB> atomnuker: and ffmpeg doesn't guarantee that, sadly
[17:45:08 CET] <BBB> we can fix the decoder to not need that, I did that for ffvp9, but I'd rather fix it on the ffmpeg side
[17:46:52 CET] <durandal_1707> why is that really needed?
[17:48:20 CET] <kierank> durandal_1707: https://www.youtube.com/watch?v=4JWgmv92fQk
[17:49:53 CET] <atomnuker> BBB: IIRC users ask lavc for alignment value
[17:50:21 CET] <BBB> durandal_1707: the alignment to superblocks?
[17:50:40 CET] <BBB> because blocks can be up to 128x128, and can extend the visible frame up to (I believe) 63 pixels
[17:50:55 CET] <atomnuker> yep, users call avcodec_align_dimensions2() to get the stride/w/h aligns
[17:50:57 CET] <BBB> so if you have a buffer of width X, you can write up to [x+62]
[17:51:02 CET] <atomnuker> with a configured avctx
[17:51:21 CET] <BBB> and libavcodec only guarantees alignment (and thus edge extension) of up to 31 (or maybe it's 15 now on some systems)
[17:51:36 CET] <BBB> alignment of 16/32 of course, and thus extended width of up to 15/31
[17:51:47 CET] <BBB> wihch means dav1d can overwrite the next line's start
[17:51:49 CET] <BBB> which we don't want
[17:52:14 CET] <BBB> so, avcodec's get_buffer constraints are not compatible with dav1d's get_buffer requirements
[17:53:02 CET] <BBB> at the ottom of the frame, it's worse
[17:53:06 CET] <BBB> since we don't align height at all
[17:53:10 CET] <BBB> but we have the same requirements
[17:53:21 CET] <durandal_1707> there is some code that does it
[17:53:22 CET] <BBB> so we can overwrite up to 63 lines, all of which basically overwrite the top of the chroma plane
[17:53:31 CET] <BBB> so same conclusion
[17:53:41 CET] <atomnuker> BBB: where is it documented that get_buffer only supports alignment of 31 max?
[17:53:51 CET] <BBB> it's not documented, it's how it's implemented
[17:53:56 CET] <atomnuker> where?
[17:54:15 CET] <BBB> utils.c?
[17:54:23 CET] <atomnuker> its the users that do the alignment in case of DR
[17:54:31 CET] <BBB> I understand that
[17:54:34 CET] <atomnuker> so?
[17:54:37 CET] <durandal_1707> cant you use coded_width/height?
[17:54:42 CET] <BBB> but if even the default implementation doesn't work
[17:54:52 CET] <BBB> then how can I expect a user's custom implementation to work?
[17:55:32 CET] <BBB> I'm sure you could use coded_* or some other solution
[17:55:36 CET] <BBB> but that's not how it works right now
[17:55:44 CET] <BBB> ffvp9 does double buffering on edges
[17:55:56 CET] <BBB> and dav1d simply set wider cosntraints that are incompatible with ffmpeg's default implementation
[17:55:57 CET] <BBB> so no DR
[17:56:08 CET] <BBB> if you want to fix it, go for it, I have other things I'd rather do
[17:56:18 CET] <durandal_1707> swscale
[17:56:25 CET] <atomnuker> my point was it'll work for users without any changes
[17:56:39 CET] <BBB> atomnuker: I tested it with ffvp9 and it did not
[17:56:40 CET] <BBB> sorry
[17:56:44 CET] <BBB> it did not work
[17:56:56 CET] <BBB> I had to imlpement double buffering to get it to work
[17:56:56 CET] <atomnuker> eh? but ffvp9 dr works
[17:57:01 CET] <atomnuker> ah
[17:57:03 CET] <BBB> yes, b/c I added double buffering
[17:57:09 CET] <BBB> I'm not adding double buffering to dav1d
[17:57:22 CET] <BBB> I instead changed the get_buffer constraints
[17:57:25 CET] <atomnuker> surely it would have been simpler to just change the alignment requirements in utils.c
[17:57:38 CET] <BBB> that's an API break
[17:57:46 CET] <BBB> given that it means all users have to implement a new get_buffer callback
[17:57:49 CET] <BBB> imagine that pain
[17:57:52 CET] <BBB> I'd rather not
[17:57:59 CET] <BBB> I udnerstand your point
[17:58:06 CET] <BBB> but I don't think it's practical, it will cause huge pains
[17:58:34 CET] <atomnuker> so get_buffer is documented to require no more than width + max 16(or was it 31) pixels of alignment?
[17:58:52 CET] <BBB> I don'tknow how it's documented; but that's how it's implemented in the default implementation
[17:59:01 CET] <BBB> and so I assume most custom implementations do that too
[17:59:04 CET] <atomnuker> I'm just not sure where the API break would be
[17:59:32 CET] <BBB> https://ffmpeg.org/doxygen/3.2/structAVCodecContext.html#a7c93198032a3a728b13cb7d7e637d295
[17:59:38 CET] <BBB> avcodec_align_dimensions2() should be used to find the required width and height, as they normally need to be rounded up to the next multiple of 16.
[18:00:08 CET] <BBB> https://ffmpeg.org/doxygen/3.2/libavcodec_2utils_8c_source.html#l00260
[18:00:17 CET] <BBB> I don't want to change all that
[18:00:35 CET] <BBB> the API break is that some implementations that used to work, no longer work
[18:00:38 CET] <BBB> and they fail silently
[18:00:46 CET] <BBB> that is, they return memory, and then it crashes
[18:01:11 CET] <BBB> now, these may be implementations that don't call avcodec_align_dimensions2 as they should
[18:01:16 CET] <BBB> but they used to work and now they don't
[18:02:59 CET] <atomnuker> they're using the API incorrectly and its their fault
[18:04:31 CET] <atomnuker> and "as they normally need to be rounded up to the next multiple of 16." just implies some standard h264 alignment, not a max or min limit
[18:10:46 CET] <BBB> I get it
[18:10:48 CET] <BBB> I really do
[18:10:53 CET] <BBB> but I'm not going to be the one changing it
[18:10:54 CET] <BBB> sorry
[18:11:06 CET] <BBB> you wanna fix it? go for it
[18:11:07 CET] <BBB> I'm not doing it
[18:11:23 CET] <BBB> from my perspective, there is no bug in dav1d
[18:11:29 CET] <durandal_1707> OK you _NOT_ doing it
[18:11:33 CET] <BBB> and I don't care enough to fix this particular bug in ffmpeg
[18:11:39 CET] <atomnuker> I didn't say there is, and its not a bug here either
[18:11:55 CET] <BBB> there is. you need to increase the 16 to 128 in that function
[18:11:59 CET] <BBB> that is a bug
[18:12:01 CET] <atomnuker> all one (someone) needs to do is add a case for AV1 in the dimensions fn
[18:12:14 CET] <BBB> right now, DR with that implementation of get_dimensions won't work
[18:12:19 CET] <BBB> that is a bug
[18:12:23 CET] <atomnuker> BBB: some codecs already require aligns of 64 of both width and height
[18:12:27 CET] <atomnuker> SVQ
[18:12:40 CET] <atomnuker> it will
[18:12:51 CET] <atomnuker> as long as an av1 entry is added to indicate 128 aligns
[18:13:36 CET] <BBB> I've been saying that all along
[18:13:38 CET] <BBB> it needs a change
[18:13:43 CET] <BBB> and I'm not making that change
[18:13:46 CET] <BBB> not worth it for me
[18:13:50 CET] <atomnuker> no, you're not
[18:13:51 CET] <BBB> you wanna make that change? go for it
[18:13:54 CET] <BBB> I'm not making it
[18:13:54 CET] <durandal_1707> LOL
[18:14:04 CET] <BBB> "needs change" == "current version doesn't work"
[18:14:12 CET] <durandal_1707> i'm not making it either
[19:12:55 CET] <durandal_1707> atomnuker: have you removed mold?
[19:49:14 CET] <durandal_1707> atomnuker: i can no longer wait, will apply it
[19:56:44 CET] <atomnuker> yeah allright, patch applied, going to test it now
[20:14:13 CET] <atomnuker> durandal_1707: gave it a go, sounds very good
[20:14:24 CET] <atomnuker> the n option doesn't seem to do much though
[20:14:36 CET] <atomnuker> the filter seems to always consume 2 cores
[20:15:09 CET] <atomnuker> and code-wise remove the brackets around 1-line statements in compute_distance_ssd() and filter_channel()
[20:20:11 CET] <durandal_1707> atomnuker: i removed n option and do it automatically internally depending on number of samples in input
[20:21:12 CET] <durandal_1707> atomnuker: i only do not like how it process very high frequencies, like loud breathing - it distort it too much
[22:05:37 CET] <durandal_1707> cone-149 is not showing commits
[00:00:00 CET] --- Wed Jan  9 2019