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

[burek]

[00:00:00 CET] --- Sat Mar 23 2019
[00:45:13 CET] <Matti-> i found a amazing program that scans mp3 files and tell which mp3 encoder was used.   if this could happen with mp3,  is it possible to have a program that does for AAC, and tells which AAC encoder used
[00:45:29 CET] <Matti-> oops wrong channel
[01:00:08 CET] <cone-219> ffmpeg 03James Almer 07n4.1.2:HEAD: Merge commit '0676de935b1e81bc5b5698fef3e7d48ff2ea77ff'
[05:56:11 CET] <cone-682> ffmpeg 03Jun Zhao 07master:305025c8aede: lavfi/sidedata: add missed frame side data type
[05:56:11 CET] <cone-682> ffmpeg 03Jun Zhao 07master:fba42b33b7f2: lavf/flvdec: fix typo in log message
[08:04:26 CET] <cone-682> ffmpeg 03Steven Liu 07master:2cb29a5d8de0: avformat/avformat.h: update the comment from deprecated to new API
[08:04:27 CET] <cone-682> ffmpeg 03hwrenx 07master:bf05f621d583: lavc/libdavs2: add davs2_flush
[08:04:28 CET] <cone-682> ffmpeg 03hwrenx 07master:5252d594a155: lavc/libdavs2: fix frame dumping error description
[12:55:24 CET] <BtbN> I feel like I have forgotten one or two nvidia related patches, but I can't find them on the ML anymore.
[13:04:27 CET] <JEEB> was npp or cuda the thing we were trying to get rid of?
[13:05:53 CET] <JEEB> since I see a cuda crop filter being posted on the ML
[13:07:33 CET] <jkqxz> CUDA crop?  Isn't that redundant, since you already have the cropping information on hardware frames?
[13:08:07 CET] <jkqxz> Hmm.  Apparently I never merged the generic crop filter.
[13:15:34 CET] <jkqxz> That CUDA version seems wildly complicated.  Why does it even copy?  Aren't the CUDA data references just pointers anyway?
[13:16:03 CET] <jkqxz> (Or meant to look like them, at least.)
[13:16:19 CET] <nevcairiel> they are, and it really confused me when i saw it the first time, when I thought "why is someone doing pointer arithmetic on these opaque hardware pointers"
[13:16:55 CET] <BtbN> Those opaque hardware pointers can be casted to actual pointers and they just work most of the time as well.
[13:17:57 CET] <BtbN> Can you even do full crop, like top and left side, with just pointer arith?
[13:17:58 CET] <nevcairiel> that then leaves the question, why bother with cropping if you can just increment pointers
[13:18:08 CET] <nevcairiel> sure
[13:18:08 CET] <BtbN> well, top obviously, but left side
[13:18:24 CET] <nevcairiel> well in software you can
[13:18:45 CET] <BtbN> I'm pretty sure that would mess up the strict alignment requirements CUDA has on the pointers.
[13:18:51 CET] <nevcairiel> in software the o nly problem that comes up is that the reslulting pointers are no longer aligned
[13:18:54 CET] <BtbN> So you could only crop in multiple of 256 or even 512
[13:19:09 CET] <nevcairiel> if hardware has similar annoyances, then you cant
[13:19:22 CET] <BtbN> Alignment requirements on CUDA frames are super strict
[13:19:48 CET] <BtbN> 256 byte aligned minimum, depending on GPU gen
[13:19:56 CET] <jkqxz> Do NVENC or any other things support the AVFrame cropping fields?
[13:20:27 CET] <BtbN> no
[13:20:31 CET] <jkqxz> Let me just send the generic one again.  It's from a year ago, but sitll works nicely for VAAPI at least.
[13:20:49 CET] <jkqxz> Could scale_cuda support it easily?
[13:20:50 CET] <BtbN> I don't remember nvenc having cropping parameters either. nvdec has
[13:21:23 CET] <BtbN> Adding support for it to scale_cuda would require pretty much the same kind of code that filter adds.
[13:21:27 CET] <nevcairiel> in a perfect world you would want to get rid of cropping parameters w hen transcoding
[13:21:41 CET] <nevcairiel> because many players dont support top/left either
[13:22:02 CET] <BtbN> I'm not aware of nvenc supporting cropping parameters either, as in, speciying an input rect
[13:22:49 CET] <BtbN> It defines a NVENC_RECT type, but then proceeds to never use it
[13:28:22 CET] <nevcairiel> in related topics, do they 16-series cards have the full turing video engine? I would assume so, right?
[13:28:47 CET] <BtbN> I'd assume the same, but in lack of any Turing card, can't test it.
[13:29:55 CET] <nevcairiel> well i have a 20 series, but that doesnt really allow me to extrapolate to the 16 series that I might want to plug into a media system
[13:31:19 CET] <BtbN> If they were to release a 16 series card with 8GB RAM like a 1670, I'd probably get it.
[13:33:17 CET] <nevcairiel> i dont think the 16-series is going to go upwards in performance, because it would seriously infringe on the 2060 then
[13:46:35 CET] <BtbN> Will need to get a 2070 or 2080 then at some point
[13:46:44 CET] <BtbN> My 1060 is already limiting me in some games
[18:52:11 CET] <durandal_1707> BBB: now what about qpel? lets use (A+B+1)>>1 for 1/2pel and (6A+2B+1)>>3 for 1/4pel and (2A+6B+4)>>3 for 3/4pel, how to make 16 combinations from those?
[18:52:55 CET] <durandal_1707> 0,0 is copy
[19:02:49 CET] <kierank> See how h264 does it
[19:08:16 CET] <durandal_1707> h264 is mess
[19:28:16 CET] <iive> i thought that all MC already do that. I even remember that RV40 turned out to use the wrong interpolation function for one of the cases e.g. [3,3]/4
[19:33:03 CET] <BBB> wait, wait
[19:33:15 CET] <BBB> the reason that h264 is the way it is, is because halfpel is special-cased
[19:33:23 CET] <BBB> the idea in h264 is that qpel positions are derived from hpel
[19:33:26 CET] <BBB> this is hell for decoders
[19:33:47 CET] <BBB> but for encoders, it is supposedly better
[19:34:02 CET] <BBB> that's why h264 is the way it is (in terms of dsp function pointer table design)
[19:34:09 CET] <BBB> for a more generic system, you don't need that
[19:34:24 CET] <BBB> just use a subpel position function argument x/y
[19:34:31 CET] <BBB> and use that as multiplier for A
[19:34:57 CET] <BBB> if mx is in range of [0..3], then the B coefficient is simply mx
[19:35:39 CET] <BBB> so out=A+(((B-A)*mx+4)>>3)
[19:35:40 CET] <BBB> IIRC
[19:35:48 CET] <BBB> it's just standard bilinear
[19:35:59 CET] <BBB> and then store that in temp, do the same for my vertical
[19:36:00 CET] <BBB> etc.
[19:36:05 CET] <BBB> durandal_1707: ^^
[19:55:47 CET] <durandal_1707> BBB: what about my? i have 16 combinations, 4Xx4Y
[19:57:25 CET] <BBB> but you don't need 16 functions
[19:57:30 CET] <BBB> just pass mx/my as function arguments
[19:57:36 CET] <BBB> and do the function I just gave you per direction
[19:57:39 CET] <BBB> it's simple bilinear
[19:57:43 CET] <BBB> there's nothing complex about it
[19:58:26 CET] <BBB> durandal_1707: if I'm not making sense, let me know, I can explain in some more detail if that helps
[19:59:29 CET] <iive> some of the 16 combinations are repeats.
[19:59:32 CET] <durandal_1707> so first 2 bits are x part of coded motion vector and rest is 2 bits for y part, that gives 0-15 values
[20:00:25 CET] <durandal_1707> first 4 cases are pure horizontal?
[20:04:15 CET] <durandal_1707> BBB: i do not understand how to do vertical - for which cases it is done?
[20:05:10 CET] <BBB> so you have a motion vector right?
[20:05:15 CET] <BBB> and the lowest 2 bits are fractional
[20:05:22 CET] <BBB> that is, they are the subpixel position
[20:05:29 CET] <BBB> of each (x, y) component
[20:05:31 CET] <BBB> yes?
[20:05:35 CET] <BBB> does that make sense so far?
[20:06:06 CET] <BBB> let's call this set of 2x 2 bits "mx" and "my"
[20:06:17 CET] <BBB> mx is the x mv subpixel component
[20:06:24 CET] <BBB> my is the y mv subpixel component
[20:06:26 CET] <BBB> ok?
[20:06:31 CET] <durandal_1707> ok
[20:06:46 CET] <BBB> ok, let's start with horizontal
[20:06:52 CET] <BBB> you said, for mx=0, the function is A
[20:07:02 CET] <BBB> for mx=1, it's (A*6+B*2+4)>>3
[20:07:10 CET] <BBB> for mx=2, it's (A+B+1)>>1
[20:07:27 CET] <BBB> for mx=3, it's (A*2+B*6+4)>>3
[20:07:28 CET] <BBB> ok?
[20:07:34 CET] <durandal_1707> yes
[20:08:02 CET] <BBB> I'm gonna rewrite that as (mx*B+(4-mx)*a+2)>>2
[20:08:18 CET] <BBB> which can also be written as A+(((B-A)*mx+2)>>2)
[20:08:28 CET] <BBB> this is the standard bilinear equation
[20:08:41 CET] <BBB> where A is src[x], and B is src[x+1]
[20:08:44 CET] <BBB> that's the horizontal part
[20:08:48 CET] <BBB> store it, do the same vertically
[20:08:49 CET] <BBB> and done
[20:09:26 CET] <BBB> it's just that vertically, you do A=src[x] and B=src[x+stride]
[20:09:41 CET] <BBB> so do the hor loop wx(h+1)
[20:09:45 CET] <BBB> and the verloop wxh times
[20:11:11 CET] <durandal_1707> other cases from 8 to 15 are just repeat of those?
[20:11:26 CET] <durandal_1707> 4-7 are vertical?
[20:30:21 CET] <BBB> whatdo you mean 8 to 15
[20:30:26 CET] <BBB> you have4 mx positions and 4 my
[20:30:34 CET] <BBB> so in h264 these are unrolles to unique functions
[20:30:39 CET] <BBB> but for bilin you don't need that
[20:30:48 CET] <BBB> so it's not 4x4 functions; it's just 1 function handling 2x4 mx/my pairs
[20:34:19 CET] <durandal_1707> i need to map somehow those bits to something, so which of them are which ....
[20:36:07 CET] <BBB> I can see that we have some sort of a mismatch of information here
[20:36:29 CET] <BBB> I don't see what you don't understand and you can't see why I can't understand you :-p
[20:36:35 CET] <BBB> but I don't know what you mean, sorry
[20:36:48 CET] <BBB> can you show some code and tell me what is unclear?
[20:42:18 CET] <durandal_1707> BBB: https://pastebin.com/Axn1TKLz
[20:42:49 CET] <BBB> hehe
[20:42:51 CET] <BBB> mx=mode&3
[20:42:54 CET] <BBB> my=mode>>2
[20:42:57 CET] <BBB> and then do what I did above
[20:43:05 CET] <BBB> don't write it out using switches, that's terrible :)
[20:43:08 CET] <BBB> it'll be way too long
[20:49:17 CET] <durandal_1707> for which mx/my i pick vertical and v+h?
[20:55:56 CET] <BBB> if mx != 0, there is horizontal subsampling
[20:56:04 CET] <BBB> if my != 0, there is vertical subpixeling
[20:56:07 CET] <BBB> not subsampling, sorry
[23:42:43 CET] <cone-134> ffmpeg 03Carl Eugen Hoyos 07master:5fceac1cdb82: lavd/v4l2: Fix the type of the probe function.
[00:00:00 CET] --- Sun Mar 24 2019