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

[burek]

[00:22:24 CET] <durandal_1707> looks like braw either uses fringe colorspace or its using somesort of internal demosaicing which could explain initial "subsampling"
[03:12:49 CET] <cone-216> ffmpeg 03Andreas Rheinhardt 07master:ff2b75d94cee: avformat/matroskadec: Add a fate test for CodecPrivate compression
[11:44:30 CET] <cone-444> ffmpeg 03Gyan Doshi 07master:1b4f473d181a: avfilter/scale.c: factorize ff_scale_eval_dimensions
[12:09:33 CET] <durandal_1707> Lynne: so how to do 12bit idct of 32 elements, i presume 8x4 ?
[12:09:57 CET] <kurosu> there are simple_idct variants for DV and/or wmv3/vc1 iirc
[12:10:38 CET] <kurosu> 12 bits sounds like 16bits intermediates would loose too many precision
[12:10:47 CET] <kurosu> iirc, that's what happens for DNXHR
[12:11:03 CET] <kurosu> s/many/much
[12:12:03 CET] <kurosu> there's a tool not build by default (test_idct?) in ffmpeg that I think applies some ISO criteria to measure whether your idct has too much drift
[12:12:20 CET] <kurosu> (ISO11381? maybe mpeg1 or mpeg2)
[12:17:49 CET] <durandal_1707> kurosu: i mean output of idct is 12 bit depth
[12:18:21 CET] <durandal_1707> and coefficients are stored as int16_t
[12:20:36 CET] <Lynne> durandal_1707: 8x4 makes more sense than 4x8, and if you follow this order it'll be correct - http://paste.debian.net/1120063/
[12:21:04 CET] <iive> i think kierank implemented high bit depth idct for mpeg4 asp
[12:23:28 CET] <durandal_1707> iive: yes, but i need 32 element idct with 64 already implemented
[12:24:22 CET] <Lynne> durandal_1707: as for the dct, for now you should probably just copy some float one and make it round like in that diasm you posted
[12:24:38 CET] <Lynne> you can integerize it later on, its not hard
[12:36:20 CET] <kurosu> durandal_1707: I know. From experience on templating simple_idct10 and adding 12 bits support (for prores or dnxhr, can't recall), some patterns can cause overflow
[12:37:36 CET] <kurosu> anyway, maybe no overflow for 8x4, and you'll need to look at the variants implemented for DV/...
[12:38:00 CET] <kurosu> grep for ff_simple_idct48_add
[12:38:15 CET] <kurosu> or ff_simple_idct84_add
[12:38:28 CET] <kurosu> ah, WMV2 it was
[13:02:00 CET] <kurosu> also, achievement unlocked: being contacted by scientology because of ffmpeg
[13:02:15 CET] <kurosu> should I still reply because ffmpeg strives to become a better community ?
[13:02:55 CET] <durandal_1707> lol, why?
[13:04:11 CET] <kurosu> dnxhd
[13:04:13 CET] <rcombs> pretty sure scientology and better communities are incompatible
[13:04:34 CET] <kurosu> durandal_1707: just you wait, you're probably next in line if I recall recent history
[13:05:36 CET] <rcombs> hmmm, I think the weirdest software-related contact I've had was from some director of a university CS program who was confused about how version numbers worked
[13:05:49 CET] <rcombs> seemed to think that 1.2 > 1.10
[13:10:41 CET] <cone-444> ffmpeg 03Michael Niedermayer 07master:e3dddf2142e2: tools/target_dec_fuzzer: Also fuzz request_channel_layout
[13:10:51 CET] <durandal_1707> Lynne: in their obfuscated code i see for 32 transform they do idct4 before idct8
[13:12:15 CET] <JEEB> rcombs: to be honest, many people think that it's decimal numbers
[13:12:27 CET] <JEEB> and not NUM.NUM.NUM
[13:12:46 CET] <rcombs> sure, just, one would think someone in an authority position in a CS department would know better
[13:15:05 CET] <kurosu> rcombs: I was kind of ironic there, though the thing I asked myself was: what is the threshold of evilness where you do not reply? Such a large organization/sect must have a hefty amount of commercial contacts and suppliers, so...
[13:29:21 CET] <Lynne> durandal_1707: just swap them then, like https://paste.debian.net/1120082/
[14:48:39 CET] <jdarnley>  3
[15:38:23 CET] <durandal_1707> Lynne: i did use their float idct84 variant but i get greenish output in first 2 rows
[16:22:15 CET] <Lynne> durandal_1707: so you get 2 green lines, then 2 valid lines?
[16:24:07 CET] <durandal_1707> Lynne: i found something else while REing
[16:58:48 CET] <durandal_1707> Lynne: it simply give not valid output for bunch of blocks, i'm now dechipering SIMD for 32 idct
[17:02:41 CET] <Lynne> could be a weirdly scaled dct, yeah
[18:38:59 CET] <cpplearner> Guys, how can I set profile & bitrate when using h264_vaapi? I tried av_opt_set(..., "profile", "baseline", 0), but it fails. 
[18:39:42 CET] <cpplearner> It would be nice if I can look into the complete list of av_opt_set options for h264_vaapi. ='(
[18:41:26 CET] <nevcairiel> it accepts  main/high/constrained_baseline
[18:41:39 CET] <nevcairiel> not plain baseline, which is rarely hardware compatible
[18:42:04 CET] <cpplearner> nevcairiel: Oh, I see. Hmm, how can I see the list of accapeted options for h264_vaapi? I'm a newbie.. ='(
[18:42:18 CET] <cpplearner> Thanks for the info, BTW.
[18:44:10 CET] <nevcairiel> ffmpeg CLI can probable list them, try something like ffmpeg -h h264_vaapi
[18:46:43 CET] <cpplearner> nevcairiel: Thanks!!!!
[18:46:54 CET] <cpplearner> =D
[18:49:56 CET] <durandal_1707> Lynne: which zigzag to use for 32/8x4 ?
[18:58:18 CET] <Lynne> durandal_1707: there's only 2 choices, one starts down, the other starts right, to determine which you can just set the first 3 coefficients and swap the last 2 to see which looks more correct
[19:00:52 CET] <Lynne> the one which starts down is the de-facto standard, so its most likely that one, you can just write the rest of it manually with a sheet of paper
[19:07:30 CET] <durandal_1707> Lynne: but their is 4x8, because it goes, 0, 4, 8, 12...
[19:14:20 CET] <Lynne> for a 8x4 transform?
[19:15:46 CET] <durandal_1707> yes, but similar is for 8x8 one
[19:15:58 CET] <durandal_1707> they use weird idct implementation
[19:23:16 CET] <Lynne> I don't get how they lay out 8x4 in 4x8 or why
[19:40:40 CET] <cpplearner> Hmm, guys. Is there anything I should be careful with, when doing CBR encoding with h264_vaapi? Trying ffmpeg binary works fine, but av_opt_set gives me a cripppled output...
[20:17:49 CET] <cpplearner> Hmm, should I set bitrate with av_opt_set?
[22:24:34 CET] <cone-072> ffmpeg 03Andreas Rheinhardt 07master:9f7b2b37e3c6: fate/matroska: Add a test for propagating flac channel layouts
[00:00:00 CET] --- Mon Dec  9 2019