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

[burek]

[00:04:28 CEST] <cone-029> ffmpeg 03Gyan Doshi 07master:cdd6a525e492: doc/encoders: list missing options for x265
[00:42:27 CEST] <jamrial> TD-Linux: "matrix_coefficients out of range [AOM_CICP_MC_BT_709..AOM_CICP_MC_ICTCP]"
[00:42:35 CEST] <jamrial> when i try to set it to AOM_CICP_MC_IDENTITY, for rgb
[00:42:49 CEST] <jamrial> am i missing something?
[00:43:00 CEST] <TD-Linux> jamrial, probably not. do you want a file a bug, or should I?
[00:43:28 CEST] <jamrial> feel free to
[00:44:09 CEST] <JEEB> was there anything in avutil or something for buffer queues?
[00:44:41 CEST] <jamrial> just tried to pass AV_PIX_FMT_GBRP (which the encoder wrapper treats as i444), but the resulting file is wrong
[00:45:05 CEST] <jamrial> then tried to set matrix coeff to rgb as well, and got that error
[00:45:20 CEST] <JEEB> ah https://patchwork.ffmpeg.org/patch/8203/
[00:53:40 CEST] <TD-Linux> https://aomedia-review.googlesource.com/c/aom/+/53708
[01:35:20 CEST] <jamrial> TD-Linux: nice, that indeed fixes rgb with the wrapper after a fix i'll apply in a bit
[01:35:42 CEST] <TD-Linux> as you might guess, rgb is rather... untested
[01:35:48 CEST] <jamrial> also, at least two commits changed the bitstream in the last hours. samples i encoded yesterday don't worn anymore :D
[01:36:02 CEST] <TD-Linux> it should work but probably needs at least some quantizer changes in the encoder
[01:36:23 CEST] <TD-Linux> (to compress well... that said if you are using RGB you've already lost that battle)
[01:38:13 CEST] <jamrial> just tried to encode one frame with the above change plus my fix, and the output looks fine now
[01:38:23 CEST] <jamrial> and the output file is i444
[01:38:48 CEST] <TD-Linux> great
[01:39:05 CEST] <jamrial> or not
[01:39:08 CEST] <jamrial> "Stream #0:0: Video: av1 (High) (AV01 / 0x31305641), gbrp(tv, gbr/bt709/iec61966-2-1), 1280x720, 23.98 tbr, 23.98 tbn, 23.98 tbc"
[01:39:35 CEST] <jamrial> guess i misread
[01:40:52 CEST] <TD-Linux> er the "tv" is probably bad :)
[01:41:37 CEST] <TD-Linux> is libaom actually giving you a gbr enum type?
[01:42:56 CEST] <jamrial> looks like it's giving me AOM_IMG_FMT_I444, but the decoder wrapper sets it to gbrp after looking at the matrix coef value
[01:44:30 CEST] <jamrial> and regarding the tv thing
[01:44:32 CEST] <jamrial> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libaomenc.c;h=8ebdcc20e3ef25fb64da47cccaaaba5d1368cc49;hb=HEAD#l273
[01:45:16 CEST] <jamrial> which is the same as the vpx wrapper
[01:45:16 CEST] <TD-Linux> jamrial, could you also make it set full range if you get in a AV_PIX_FMT_GBRP?
[01:45:38 CEST] <TD-Linux> at least I was under the assumption that it always implied full range in ffmpeg
[01:45:51 CEST] <jamrial> let me try
[01:47:30 CEST] <jamrial> TD-Linux: https://bugs.chromium.org/p/aomedia/issues/detail?id=1686 maybe this?
[01:47:54 CEST] <jamrial> i see no difference in what the aom wrapper does compared to the vpx one
[01:48:06 CEST] <jamrial> and the vpx one does full range for gbrp
[01:49:01 CEST] <TD-Linux> jamrial, vp9 doesn't let you signal color range at all when you tell it srgb color space, it just assumes full
[01:49:52 CEST] <TD-Linux> but yeah you could just wait to see what the outcome of that bug is, maybe you won't need to do anything
[01:49:53 CEST] <jamrial> i mean the resulting file is reported as full range with vp9
[01:51:47 CEST] <TD-Linux> jamrial, right because libvpx will report it as such because there's no way to signal anything else in the bitstream.
[01:55:37 CEST] <jamrial> TD-Linux: the frame i'm encoding doesn't set codec range, which for libaom that defaults to 0 (studio range)
[01:56:44 CEST] <jamrial> the suggested fix in the bug i mentioned above tries to make sure it's full range instead, if rgb
[01:56:57 CEST] <jamrial> i can hardcode it in the wrapper, in any case
[01:57:12 CEST] <TD-Linux> jamrial, yeah. I think ffmpeg semantics are that if it's undefined it should be rgb for the rgb formats. I could also change libaom so that if you set matrix coefficients it then sets a default range
[01:58:22 CEST] <TD-Linux> (but then you would have to not call the ctl in that caes)
[02:01:20 CEST] <TD-Linux> oh actually one sec I might be wrong
[02:02:11 CEST] <TD-Linux> yeah as it stands this is a libaom bug, nothing for you to fix yet.
[02:05:34 CEST] <jamrial> also, the suggested fix in 1686 may not be ideal. it's expecting matrix coeff, transform chraracteristics and color primaries all to be set
[02:05:55 CEST] <jamrial> wouldn't it be better to only make sure matrix coeff is rgb, and the other two can be undefined?
[02:07:00 CEST] <TD-Linux> yeah it's kinda funky. I guess it means you *would* need to do the range thing I suggested if you are using RGB-but-not-SRGB-primaries
[04:04:01 CEST] <FishPencil> Is there somewhere I can ask image processing questions? I'm having a little issue implementing a white paper algo: https://i.imgur.com/aqHWV6E.jpg
[04:06:10 CEST] <atomnuker> neural networks?
[04:07:14 CEST] <FishPencil> no
[04:09:01 CEST] <atomnuker> which paper
[04:10:58 CEST] <FishPencil> This is the paper section (nlmeans): https://i.imgur.com/kDnz3cq.png this is my code: https://paste.ubuntu.com/p/pr7hKtd9nJ/
[04:11:17 CEST] <FishPencil> Is it possible that things are different for YUV than they would be for RGB?
[04:11:34 CEST] <FishPencil> I assumed both were 255... but maybe that was wrong
[04:12:17 CEST] <atomnuker> no, for yuv you need to check the color range flag to see whether the range if 0-255 or 16-235
[04:12:55 CEST] <atomnuker> are you writing a filter?
[04:13:02 CEST] <FishPencil> yes
[04:13:46 CEST] <FishPencil> Not specifically for FFmpeg, but down the road yes. I'm just trying to implement the basic algo right now.
[04:15:24 CEST] <FishPencil> I'm hoping there's something glaringly wrong with my code vs the white paper so someone can easily spot it
[04:15:32 CEST] <atomnuker> we have an nlmeans filter you can use as a reference
[04:16:03 CEST] <FishPencil> it uses an integral image optimization that changes quite a lot 
[04:16:25 CEST] <FishPencil> this is a pixel wise implementation without summed area tables
[09:36:46 CEST] <cone-141> ffmpeg 03Martin Vignali 07master:34304677c05b: avfilter/showvolume : add comment for orientation condition
[09:36:46 CEST] <cone-141> ffmpeg 03Martin Vignali 07master:25b22666a3c0: avfilter/showvolume : calculate fade only if fade < 1.
[09:36:46 CEST] <cone-141> ffmpeg 03Martin Vignali 07master:328df2f71234: avfilter/showvolume : indent after prev commit
[09:36:46 CEST] <cone-141> ffmpeg 03Martin Vignali 07master:e8d785035320: doc/avfilter/showvolume : fix doc for orientation param
[09:36:46 CEST] <cone-141> ffmpeg 03Paul B Mahol 07master:0c25caa4708c: avfilter/avf_showvolume: let fade be also exactly 0
[11:22:27 CEST] Action: durandal_1707 porting rust code to C
[18:51:26 CEST] <JEEB> what was the space in the patch where you could add your random comments?
[18:53:16 CEST] <JEEB> oh, so additional --- after the commit message?
[19:03:05 CEST] <wm4> yeah
[19:03:25 CEST] <wm4> that seems to cause git to remove it from the commit message, and the actual patch starts with the actual patch headers
[19:09:23 CEST] <JEEB> alright, new patch sent out
[19:16:07 CEST] <durandal_1707> should i get -X where X!=1 from get_vlc2() ?
[19:18:49 CEST] <atomnuker> depends if your vlc codes decode to incrementing numbers
[19:19:19 CEST] <atomnuker> if they don't you can init the vlc with a table of numbers to output for matching codess
[21:00:39 CEST] <cone-824> ffmpeg 03Martin Storsjö 07master:f33f72847043: arm: swscale: Only compile the rgb2yuv asm if .dn aliases are supported
[21:00:39 CEST] <cone-824> ffmpeg 03Martin Storsjö 07master:6660bc034d21: arm: hevcdsp: Avoid using macro expansion counters
[21:00:39 CEST] <cone-824> ffmpeg 03Martin Storsjö 07master:5f83935de4ef: arm: hevcdsp: Add commas between macro arguments
[00:00:00 CEST] --- Sun Apr  1 2018