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

[burek]

[00:10:48 CET] <jamrial> mmh, archlinux had to rebuild their mpv package for ffmpeg 3.2 even though it shouldn't have been necessary
[00:10:54 CET] <jamrial> did we break abi again without realizing it?
[00:15:25 CET] <jamrial> looks like every other package worked fine without having to recompile
[00:16:54 CET] <philipl> mpv will throw an error if any version component changed.
[00:17:19 CET] <philipl> wm4 decided not to risk anything.
[00:18:35 CET] <jamrial> ah, i see
[00:24:39 CET] <cone-078> ffmpeg 03Michael Niedermayer 07master:a6330119a099: avcodec/msrle:  Check side data size before use
[01:03:31 CET] <cone-078> ffmpeg 03Michael Niedermayer 07master:7d196f2a5a48: avcodec/qtrle:  Check side data size before use
[01:03:32 CET] <cone-078> ffmpeg 03Michael Niedermayer 07master:16793504dfba: avcodec/qpeg:  Check side data size before use
[02:13:38 CET] <cone-078> ffmpeg 03Michael Niedermayer 07master:161ccdaa06d1: avcodec/msvideo1: Check side data size before use
[02:13:39 CET] <cone-078> ffmpeg 03Michael Niedermayer 07master:0f64b6cd2241: avcodec/rscc: Check side data size before use
[02:13:40 CET] <cone-078> ffmpeg 03Michael Niedermayer 07master:5f0bc0215a0f: avcodec/rawdec: Check side data size before use
[04:56:45 CET] <cone-078> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:894e7ef9b425: configure: add '-uninstalled' to uninstalled .pc files
[14:46:20 CET] <cone-965> ffmpeg 03Sasi Inguva 07master:5e965582d512: lavf/mov.c: Use the correct timescale when seeking for audio.
[20:32:59 CET] <atomnuker> BBB: ycgco support would be nice for vf_colorspace
[20:33:12 CET] <BBB> I oked the patch right?
[20:33:20 CET] <atomnuker> would there be any rounding errors going through XYZ first?
[20:33:23 CET] <BBB> I usually leave them out for a bit before pushing
[20:33:40 CET] <BBB> theres always rounding errors, but theres no statistical bias
[20:33:53 CET] <BBB> (i.e. the error is equally much up as it is down)
[20:34:06 CET] <atomnuker> btw, why xyz as the intermediate format rather than rgb?
[20:34:48 CET] <BBB> rgb is not device-independent
[20:35:02 CET] <atomnuker> device independent?
[20:35:11 CET] <BBB> i.e. a particular value for rgb when colorspace is sRGB is not the same as that same value for rgb in bt2020
[20:35:21 CET] <BBB> or DCI-P3, or whatnot
[20:36:40 CET] <BBB> if you have 8-bits-per-component values, with a range of 0-255, then youd hope that a particular tri-component value pair r, g, b has a fixed meaning in terms of color perception
[20:36:43 CET] <BBB> but thats not the case
[20:36:53 CET] <BBB> its basically set for a particular generation of devices
[20:37:15 CET] <ubitux> btw, speaking of xyz, apparently some people use lut3d to do arbitrary colorspace convert
[20:37:17 CET] <BBB> and so bt601 rgb values have a different meaning from srgb or bt2020 or dci-p3 or [etc]
[20:37:30 CET] <ubitux> there are many 3d lut out there for colorspace convert
[20:41:42 CET] <BBB> assuming your input range is small (e.g. 8bpc tricomponent means the lut is only pow(2,8*3)=16MB?), thats doable
[20:42:38 CET] <BBB> but as your input grows (e.g. assume 10bit input or 12bit input), the table gets excessively big (pow(2,12*3)=64giga-items of 12 bits each=96 or 128GB memory depending on how you store them)
[20:42:46 CET] <BBB> that may be a little much
[20:43:31 CET] <BBB> you could reasonably use vf_colorspace to fill the lut :)
[20:43:41 CET] <BBB> but thats up to users I guess
[20:43:44 CET] <ubitux> 3d lut do not define all the points
[20:43:47 CET] <cone-953> ffmpeg 03Mark Thompson 07master:4df6605da7e3: vc1: Return stream format information from parser
[20:43:48 CET] <cone-953> ffmpeg 03Mark Thompson 07master:0c559f7893e6: hevc: Return stream format information from parser
[20:43:49 CET] <cone-953> ffmpeg 03Mark Thompson 07master:309fe16a126c: mpegvideo: Return correct coded frame sizes from parser
[20:43:50 CET] <cone-953> ffmpeg 03Mark Thompson 07master:1f26a231bb06: qsv: Merge libav implementation
[20:43:51 CET] <cone-953> ffmpeg 03Mark Thompson 07master:4e7a7a96cfc8: qsvdec: Avoid probing with qsv decoders
[20:43:52 CET] <cone-953> ffmpeg 03Kyle Schwarz 07master:5d542936680e: avcodec/qsv: remove MFX_EXTBUFF_CODING_OPTION3
[20:44:08 CET] <ubitux> there is N-points data interpolation on a 3d space
[20:44:34 CET] <ubitux> most popular one is tetrahedral
[20:46:02 CET] <BBB> I guess Im not totally familiar with how lut3d works
[20:46:15 CET] <BBB> but in general it makes sense yes
[20:46:52 CET] <ubitux> it's generally pretty useful to register a complex color transformation as a 3d lut to re-do it fast
[20:47:39 CET] <BBB> atomnuker: also, related to rounding error, the intermediates are quite a bit bigger than the source/dest bitdepth, so any rounding error in intermediates is at much higher resolution than is relevant for the final values, so the impact should be negligibly small _on average_
[20:47:56 CET] <BBB> ubitux: I agree
[20:47:59 CET] <ubitux> ffmpeg can btw use a 3d lut saved as a video stream if your transform evolves over time </advert>
[20:48:05 CET] <atomnuker> yeah, makes sense
[20:48:21 CET] <atomnuker> I can't wait to test encoding some rgbs to ycgco dirac
[20:48:31 CET] <atomnuker> (and decoding too, because that hasn't been tested)
[20:48:37 CET] <BBB> (Im stressing the on average, because Im sure you can make some crazy test cases where it does impact the end result)
[20:48:45 CET] <BBB> decoding would be cool yes
[20:48:52 CET] <BBB> isnt there one ycgco clip in the h264 fate test set?
[20:49:11 CET] <atomnuker> though considering chroma coefficients are going to be less for ycgco compression will be worse considering dirac's horrible quantization
[20:49:34 CET] <BBB> is this just for testing?
[20:49:42 CET] <BBB> or do you really want to do something significant with it?
[20:50:10 CET] <BBB> my impression has always been that ycgco is like a cheap yuv if your target format is rgb but youd like to split color from luma somewhat for encoding purposes
[20:50:30 CET] <BBB> since the conversion between rgb and ycgco is simpler (2 butterflies) than rgb-yuv (complete 3x3 matrix)
[20:50:47 CET] <BBB> I guess the inverse is a little bit more complex but still very simple
[20:52:04 CET] <ubitux> BBB: you can try btw; something like ffmpeg -f lavfi -i haldclutsrc=8 -vf colorspace=ycgco -frames:v 1 clut.png; then compare ffmpeg -i in -vf colorspace=ycgco ... to ffmpeg -i in -i clut.png -lavfi '[0][1] haldclut' ... 
[20:52:13 CET] <ubitux> s/to/with/
[20:52:21 CET] <ubitux> and see what sort of precision you loose
[20:57:15 CET] <jkqxz> relaxed:  Have you ever investigated making your static builds with vaapi support?  (I'm wondering about <https://trac.ffmpeg.org/ticket/5920>: does static-built libva work at all?)
[20:58:15 CET] <jkqxz> (I followed the same steps as in that bug and observe than libva segfaults in initialisation.)
[21:07:17 CET] <drv> I believe reall-fully-static Linux binaries can't use libdl at all (I'm surprised it even links)
[21:11:03 CET] <atomnuker> BBB: testing only, there hasn't been a way to generate ycgco up until now despite some codecs supporting it
[21:11:47 CET] <atomnuker> well, an easy way without having to dump raw rgb and converting it yourself
[21:12:42 CET] <TD-Linux> BBB, it also loses less to precision if you're converting from an RGB source (like screen capture) and limited to 8 bits
[21:13:08 CET] <TD-Linux> the downside of course being the worse decorrelation, so it only makes sense if you're running at a high enough bitrate
[21:13:20 CET] <jkqxz> drv:  It makes sense that it doesn't work, but a nice explanation as to why would be helpful for that bug.
[21:15:55 CET] <cone-953> ffmpeg 03Vittorio Giovara 07master:5a123f1424fe: vf_colorspace: Add support for iec61966-2.4 (xvYCC) transfer
[21:17:44 CET] <TD-Linux> actually according to this it decorrelates better: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Malvar_Sullivan_YCoCg-R_JVT-I014r3-2.pdf
[21:20:40 CET] <BBB> michaelni: if you prefer to have me apply the patches, Ill probably do it tomorrow& the only reason I Dont apply immediately is to give others a chance to chime in also (just in case youre wondering why Im lazy and letting you do patchmonkey work)
[23:21:06 CET] <cone-953> ffmpeg 03Michael Niedermayer 07master:e167610794db: avcodec/rscc: Fix constant
[23:21:07 CET] <cone-953> ffmpeg 03Michael Niedermayer 07master:979bca513424: avcodec/tscc:  Check side data size before use
[23:21:08 CET] <cone-953> ffmpeg 03Michael Niedermayer 07master:140f48b90fbe: avcodec/smc:  Check side data size before use
[00:00:00 CET] --- Tue Nov  1 2016