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

[burek]

[00:21:41 CET] <cone-383> ffmpeg 03Paul B Mahol 07master:24424a6516f8: avcodec/simple_idct_template: fix integer overflow
[04:38:10 CET] <kierank> jdarnley: how hard do you think it is for me to write 32-bit coeff 10-bit idct support over christmas
[04:38:14 CET] <kierank> and 12-bit idct
[04:38:25 CET] <kierank> asm
[04:52:25 CET] <kierank> also why does 8-bit have dc only hack but not 10-bit
[09:50:36 CET] <cone-300> ffmpeg 03Carl Eugen Hoyos 07master:193143486e8a: lavc/pnmdec: Fix 16bit decoding.
[12:15:29 CET] <jdarnley> kierank: C and ASM?  Or just ASM?
[12:15:41 CET] <durandal_1707> ???
[12:15:53 CET] <jdarnley>  <@kierank> jdarnley: how hard do you think it is for me to write 32-bit coeff 10-bit idct support over christmas
[12:16:01 CET] <jdarnley> at [Sat 14 04:38]
[12:16:57 CET] <durandal_1707> why?
[12:17:23 CET] <jdarnley> IIRC it is some weird studio format he's been working on for the past few years
[12:17:49 CET] <jdarnley> Was it part of MPEG-4?
[12:17:54 CET] <jdarnley> I don't recall
[12:29:13 CET] <kurosu> yes, studio profile uses that
[12:29:32 CET] <kurosu> dunno why it needs more precision than say prores or dnxhd, though
[12:32:52 CET] <Lynne> jdarnley: if you're going to write it please write it into libavutil/tx
[12:33:11 CET] <durandal_1707> i can not figure out what LUT curve braw uses
[12:34:00 CET] <durandal_1707> Lynne: should i use avutil/tx for 2d idct?
[12:39:03 CET] <Lynne> the API is capable for it, so if you write a new transform you should put it there
[12:39:38 CET] <Lynne> right now its just ffts, though I could write a float/int dct using an fft too
[12:40:03 CET] <Lynne> but its like 4x the price if you use an fft to do a dct
[12:41:04 CET] <BradleyS> durandal_1707: there are three dynamic range settings on my cam
[12:41:15 CET] <BradleyS> film, extended video, and video
[12:41:46 CET] <BradleyS> blackmagic provides luts in cam and in davinci resolve for film and extended video
[12:42:15 CET] <BradleyS> film is the widest dynamic range / least compressed
[12:42:25 CET] <BradleyS> extended video is wider than video
[12:42:49 CET] <BradleyS> video is basically normal / standard not needing a lut
[12:43:12 CET] <BradleyS> if you want i can shoot all three and provide samples for comparison
[12:44:02 CET] <BradleyS> not sure whether their lut files are available or if they're embedded in resolve / protected in some way
[12:45:44 CET] <durandal_1707> BradleyS: have you uploaded standard already?
[12:45:59 CET] <BradleyS> don't think so, pretty sure they are all film
[12:46:16 CET] <BradleyS> i can set exposure with gray card and shoot some targets in all modes for you
[12:46:50 CET] <BradleyS> and prores versions for comparison
[12:47:03 CET] <Lynne> are the luts not in the disasm/
[12:48:09 CET] <BradleyS> i don't think their player app has the luts, only camera and resolve applies them on playback (can enable/disable)
[12:50:45 CET] <durandal_1707> BradleyS: feel free to do it for standard mode, with prores as reference
[12:51:05 CET] <BradleyS> okay, will try to get that done today
[12:51:20 CET] <BradleyS> UTC-5 here so just getting going
[12:56:35 CET] <durandal_1707> player have sidcar files, but even without them their output is much brighter
[12:56:46 CET] <durandal_1707> *sidecar
[13:02:51 CET] <BradleyS> ah
[14:35:03 CET] Action: BradleyS summons the paul
[14:44:16 CET] <BradleyS> wb
[14:44:23 CET] <BradleyS> same link: https://www.dropbox.com/sh/8s7bb7hkylewbtm/AAB8BuW23OyyqE9qtRqzQvlEa?dl=0
[14:44:31 CET] <BradleyS> last 6 files
[14:44:41 CET] <BradleyS> BRAW-DR-* and ProRes-DR-*
[14:45:11 CET] <BradleyS> Film (Widest) > Extended Video (Wide) > Video (Standard)
[14:59:29 CET] <kierank> jdarnley: ASM for 32-bit coeff input
[14:59:37 CET] <kierank> Have been reading the code
[14:59:41 CET] <kierank> It's possible
[14:59:55 CET] <kierank> But there are some tricks that make it hard
[15:03:04 CET] <jdarnley> It is probably possible over christmas
[15:03:41 CET] <jdarnley> Depends on how much free time you have given the current project.
[15:04:20 CET] <jdarnley> As for the dc only hack in the the 8-bit...
[15:04:29 CET] <jdarnley> I would assume it was there for speed reasons
[15:05:44 CET] <jdarnley> IIRC it is slightly different to the normal coeffs so maybe it was also to match some other decoder
[15:06:53 CET] <jdarnley> Didn't we make a blog post about it?  I went looking and I found no answer.
[15:19:43 CET] <yuzo555> Hi, cloud anyone confirm is this ( https://trac.ffmpeg.org/ticket/5578 ) a bug and when will it be fixed?
[15:20:46 CET] <jdarnley> When you submit a patch for it.
[16:04:30 CET] <durandal_1707> michaelni: please write bayer 16bit to rgb 16 bit conversion
[16:05:00 CET] <cehoyos> What conversion do we currently have?
[16:05:29 CET] <durandal_1707> only to > 8bit
[16:05:49 CET] <durandal_1707> so it kills other 8bits of 16
[16:05:59 CET] <cehoyos> from bayer to 8bit rgb? That sounds correct, no?
[16:06:10 CET] <cehoyos> I thought it is actually 4bit bayer, no?
[16:06:17 CET] <cehoyos> What we currently have
[16:06:24 CET] <durandal_1707> 16 bit bayer to 16bit rgb
[16:06:37 CET] <cehoyos> But our "16 bit bayer" is actually 4bit, no?
[16:06:39 CET] <durandal_1707> 4bit bayer is nonsense
[16:07:08 CET] <durandal_1707> bayer 16 bit is 16 bit RGGB pattern
[16:08:24 CET] <cehoyos> Indeed;-)
[16:10:57 CET] <cone-290> ffmpeg 03Carl Eugen Hoyos 07master:8b5ef2dcffe5: lavu/pixfmt: Cosmetics, remove wrong end-of-comment markers.
[16:38:13 CET] <durandal_1707> BradleyS: what about taking picture of gray ramp, from pure black to pure white?
[16:39:29 CET] <BradleyS> i don't have a standard chart for that but could try to find something
[16:40:13 CET] <BradleyS> there are gray ramped swatches on the target but obviously that only gives you 6-8 levels
[16:40:35 CET] <BradleyS> i will see if i can find something printed with a gradient here
[16:41:22 CET] <durandal_1707> BradleyS: picture monitor/tv screen?
[16:42:37 CET] <BradleyS> probably
[17:18:55 CET] <cehoyos> michaelni: A regression was reported: https://trac.ffmpeg.org/ticket/8430
[17:54:14 CET] <MarioMey> Hello, people.
[17:54:34 CET] <MarioMey> I'm having some issues with ffmpeg by compiling Blender... 
[17:55:33 CET] <MarioMey> Last time I compiled it was with Debian 9. Now, I'm on 10 (Buster) and I'm having some messages when compiling.
[17:56:06 CET] <MarioMey> The same compiler suggests me some changes... but there're ones that has no suggestion and no-idea how to fix it.
[17:56:31 CET] <MarioMey> I think it's about ffmpeg version... can I downgrade it?
[18:03:23 CET] <MarioMey> This just one of the error mesages with suggestion:
[18:03:26 CET] <MarioMey> /home/mario/src/blender-git/blender/source/blender/blenkernel/intern/writeffmpeg.c:639:15: error: CODEC_FLAG_GLOBAL_HEADER undeclared (first use in this function); did you mean AV_CODEC_FLAG_GLOBAL_HEADER?
[18:03:26 CET] <MarioMey>    c->flags |= CODEC_FLAG_GLOBAL_HEADER;
[18:03:26 CET] <MarioMey>                ^~~~~~~~~~~~~~~~~~~~~~~~
[18:03:26 CET] <MarioMey>                AV_CODEC_FLAG_GLOBAL_HEADER
[18:09:33 CET] <cehoyos> Apart from "wrong channel": Don't you agree that the message looks rather helpful?
[18:11:26 CET] <cehoyos> (AV_CODEC_FLAG_GLOBAL_HEADER was added more than four years ago)
[18:14:40 CET] <BradleyS> durandal_1707: same link, BRAW|Prores-DR-Grad-*
[18:14:44 CET] <BradleyS> out of focus to avoid moire
[18:16:45 CET] <BradleyS> see also in directory, BRAW-DR-Grad-WhiteClipping.jpg
[18:17:02 CET] <BradleyS> photo of cam display with zebra guide showing white clipping area for standard curve
[18:18:05 CET] <BradleyS> unfortunately my calibrated (today) 99% sRGB coverage S-IPS display has poor definition in the blacks, so the it's somewhat flat on the left side of the gradient
[18:18:10 CET] <BradleyS> but should help
[18:19:43 CET] <durandal_1707> thanks
[18:19:55 CET] <BradleyS> any time
[21:59:07 CET] <MarioMey> cehoyos: Sorry if this is no the channel. Tell me where to ask this... meanwhile, this is not the only error. There're others with no suggestions, like:
[21:59:10 CET] <MarioMey> /home/mario/src/blender-git/blender/source/blender/blenkernel/intern/writeffmpeg.c:576:3: error: AVCodecContext {aka struct AVCodecContext} has no member named me_method
[21:59:10 CET] <MarioMey>   c->me_method = ME_EPZS;
[21:59:11 CET] <MarioMey>    ^~
[21:59:24 CET] <MarioMey> Or:
[21:59:25 CET] <MarioMey> /home/mario/src/blender-git/blender/source/blender/blenkernel/intern/writeffmpeg.c:576:17: error: ME_EPZS undeclared (first use in this function)
[21:59:26 CET] <MarioMey>   c->me_method = ME_EPZS;
[21:59:26 CET] <MarioMey>                  ^~~~~~~
[22:00:00 CET] <JEEB> seems to only be utilized for libx264 so it seems to now only appear as an AVOption
[22:00:05 CET] <JEEB> instead of an AVCodecContext global option
[22:01:11 CET] <MarioMey> I'm concern with this issue... because I really need to compile Blender.
[22:01:39 CET] <MarioMey> There's a way to compile the stuff that Blender needs... for example, ffmpeg.
[22:02:33 CET] <MarioMey> But I'm confused...
[22:04:01 CET] <JEEB> the deprecation for that stuff was done between october 2014 and july 2015, and finally removed completely in March, 2017
[22:04:12 CET] <MarioMey> It's possible to compile ffmpeg and get the "include" path appart from the one from O.S.?
[22:04:41 CET] <JEEB> when you `make install` the .pc files for the libraries contain the installed prefix's directories
[22:05:32 CET] <JEEB> for example `PKG_CONFIG_PATH=/home/jeeb/encoding_prefix/lib/pkgconfig/ pkg-config --libs libavcodec`
[22:05:50 CET] <JEEB> should give you the flags for that libavcodec installed under ~/encoding_prefix :P
[22:06:19 CET] <JEEB> (This is not specific to FFmpeg, all pkg-config utilizing things can and should do this)
[22:06:33 CET] <MarioMey> Sorry, man... I'll continue in another moment... I have a terrible pain in my back as a dagger and I don't know why... I can't write any more. I'll save what you are saying.
[22:07:00 CET] <MarioMey> :-$
[22:41:03 CET] <mkver> michaelni: Are you sure it is the "Stop reallocating" patchset that fixes your testcase and not the "Copy one NAL unit at a time"? (https://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/251732.html)
[22:46:22 CET] <michaelni> mkver, the refered patch fixed a timeout caused by repeated packet growing. it was faster after that patch, i admit i did not fully test after each patch, so maybe another one made a (substantial diference too) i just quickly tested that the refered one made it from (iam too lazy to wait) to quick
[22:47:01 CET] <mkver> Oh, a timeout. Then it indeed must have been that patch.
[22:47:01 CET] <michaelni> that is unless i made a mistake and mixed something up ...
[22:51:19 CET] <mkver> Do you have some numbers for me to add to the commit message (your timeout fixes always contain these nice numbers)? It doesn't matter if you are comparing the fixed version with git master or the preceding patch.
[00:00:00 CET] --- Sun Dec 15 2019