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

burek burek021 at gmail.com
Wed Jan 10 03:05:03 EET 2018


[00:20:34 CET] <atomnuker> BBB: I think I implemented ycocg support, could you check - https://0x0.st/sZUq.diff
[00:20:57 CET] <durandal_1707> why?
[00:23:44 CET] <nevcairiel> atomnuker: YCoCg is currently a colorspace value, not a pixfmt, do we really need one for it?
[00:24:31 CET] <atomnuker> I'd like one for it, dirac supports it and I'd like to find out if its more efficient than 10bit rgb
[00:24:49 CET] <nevcairiel> why cant you use it with pix_fmt_yuv + colorspace ycocg?
[00:25:00 CET] <nevcairiel> thats how h264 and hevc decoders expose it, for example
[00:25:18 CET] <BBB> we dont do rgb that way either
[00:25:23 CET] <BBB> I dont know what the correct way is, though
[00:25:48 CET] <nevcairiel> ycocg is conceptually basically the same as YCbCr, just a different transfer to rgb
[00:26:15 CET] <nevcairiel> practically duplicating every single yuv value for ycocg seems wasteful
[00:27:52 CET] <nevcairiel> ycocg can even be subsampled
[00:29:13 CET] <atomnuker> apparently not according to the itu document
[00:29:26 CET] <atomnuker> but nvm the patch
[00:29:44 CET] <nevcairiel> well i have a h264 ycocg file in 4:2:0, so at least something made it at some point =p
[00:29:52 CET] <atomnuker> can I have it?
[00:30:43 CET] <nevcairiel> https://files.1f0.de/samples/bunny_420_YCgCo.mkv and https://files.1f0.de/samples/bunny_444_YCgCo.mkv
[00:31:30 CET] <nevcairiel> (also, apparently a lot of people disagree between YCgCo or YCoCg)
[00:32:57 CET] <atomnuker> is there some document that explains what the difference is between a transfer function, a colorspace and the primaries?
[00:33:35 CET] <atomnuker> I thought the pixel format implied the colorspace
[00:35:18 CET] <wm4> WTF
[00:35:23 CET] <wm4> don't add more idiotic pixfmts
[00:35:33 CET] <nevcairiel> the "colorspace" as we call it represents the matrix coefficients, ie, the actual math used to derive YCbCr (or YCgCo) from RGB, the other two describe the RGB itself
[00:35:33 CET] <wm4> also this breaks ycgco support in mpv
[00:36:08 CET] <wm4> I'll NACK such a patch till death
[00:36:59 CET] <rcombs> yeah pls don't do the J thing again
[00:37:18 CET] <wm4> yeah, this is pretty much an extension of the J approach
[00:38:55 CET] <atomnuker> well I didn't know
[00:40:14 CET] <atomnuker> nevcairiel: I get it, but I thought there was just one rgb format
[00:40:16 CET] <wm4> also how does that add support to vf_colorspace, other than simply allowing the format?
[00:40:47 CET] <atomnuker> not a clue, that's why I asked, I got some image resembling ycocg
[00:40:56 CET] <nevcairiel> atomnuker: the 0-255 rgb can also include different range of colors
[00:41:00 CET] <wm4> I'd very much argue we should remove the GBRP formats too and just use the colorspace enum
[00:41:24 CET] <nevcairiel> personally i'm fine with making exceptions for RGB since its the "natural" format of images
[00:41:41 CET] <atomnuker> what pixel format would non-gbrp planar rgb images use then?
[00:42:05 CET] <nevcairiel> and its quite different then YUV, with every channel being equal instead of one  dominant luminance channel and two color channel
[00:42:51 CET] <atomnuker> I didn't even know mpv supports ycgco until I tried it with a test sample
[00:44:49 CET] <rcombs> I'm ambivalent about RGB vs BGR
[00:46:11 CET] <rcombs> don't we use pixfmt to indicate chroma-plane-swapping, though?
[00:46:18 CET] <rcombs> like, NV12 vs NV21
[00:46:41 CET] <wm4> atomnuker: we also have some fully packed yuv formats
[00:46:49 CET] <wm4> so I'd argue memory structure != colorspace
[00:47:23 CET] <wm4> rcombs: yeah
[00:47:34 CET] <rcombs> yeah, colorspace is about how the values, however they're laid out (or subsampled) map to RGB (or XYZ, if you prefer)
[00:47:35 CET] <wm4> memory structure, component order, occasionally colorspace
[00:48:12 CET] <rcombs> it _is_ confusing how colorspace overlaps with matrix, transfer characteristics, and primaries, though
[00:48:52 CET] <rcombs> I'm not entirely sure what the difference is
[00:49:02 CET] <rcombs> or what it implies if the colorspace value and the primaries value don't match
[00:50:20 CET] <TD-Linux> colorspace generally can imply any of the other parameters
[00:50:28 CET] <wm4> it implies your file is fucking broken
[00:50:39 CET] <TD-Linux> (as an english word, not in ffmpeg itself)
[00:50:41 CET] <wm4> not much you can do
[00:50:50 CET] <wm4> except guessing common encoder bugs, maybe
[00:51:01 CET] <rcombs> so why are they coded separately anyway
[00:51:38 CET] <TD-Linux> they are logically distinct things and it's totally mathematically legit to code them separately.
[00:52:24 CET] <TD-Linux> but there are standards that specify certain combinations of all the parameters and if they deviate from those it's more often an encoder side mistake than intentional
[00:52:58 CET] <rcombs> I just don't like when standards allow for inconsistent files and then don't define what to do when you encounter one
[00:53:26 CET] <rcombs> since you know somebody's gonna make a file like that at some point (probably due to a bug) and then different decoders will handle it differently because it's not defined
[00:53:35 CET] <TD-Linux> I mean, they do, you're supposed to follow what the file says. but yeah.
[00:53:46 CET] <TD-Linux> worse is the ability to set any of the fields to "unknown"
[00:54:02 CET] <rcombs> how do you follow what the file says if it e.g. says bt601 for colorspace and bt709 for primaries
[00:54:49 CET] <TD-Linux> oh, actually I'm not aware of a file format that allows that.
[00:54:53 CET] <TD-Linux> but I'm sure there is one.
[00:55:03 CET] <rcombs> pretty sure h264 and hevc
[00:56:05 CET] <rcombs> yes
[00:56:42 CET] <rcombs> both of those code color primaries, transfer characteristics, and colorspace separately
[00:56:56 CET] <rcombs> with "colorspace" coming from a value internally referred to as "matrix_coefficients"
[00:57:09 CET] <TD-Linux> in this case "colorspace" probably actually means "color matrix"
[00:57:13 CET] <rcombs> (I'm not sure how those relate to primaries)
[00:57:27 CET] <TD-Linux> primaries are what R, G, and B actually are in XYZ space
[00:57:53 CET] <rcombs> so coefficients map YUV to RGB, and primaries map RGB to XYZ?
[00:57:57 CET] <TD-Linux> yes
[00:59:47 CET] <TD-Linux> traditionally you didn't care or correct primaries, it was just whatever your display has (and many displays deviate a lot from the "standard" primaries, but it looks ok)
[01:00:01 CET] <TD-Linux> same for transfer function
[01:00:36 CET] <rcombs> yeah but now HDR came around and now I have to care
[01:00:57 CET] <TD-Linux> also rec2020 introduced radically different primaries that are only possible to faithfully reproduce on a $40,000 laser projector, so now you have to correct those too
[01:01:53 CET] <rcombs> I guess they call it a "recommendation" for a reason
[01:02:48 CET] <TD-Linux> well, you can convert to rec709 primaries and use tone mapping to clamp out-of-range colors
[01:04:10 CET] <TD-Linux> I suspect the most common "nonstandard" arrangement will be HDR + 709 primaries. youtube allows it for example
[01:24:45 CET] <lrusak> wm4: -1 isn't a valid pts, should I check for that instead?
[01:29:18 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:374a2d22504d: avcodec/jpeglsdec: Check ilv for being a supported value
[01:29:19 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:7373064247fd: avcodec/jpeglsdec: Check for end of bitstream in ls_decode_line()
[01:29:20 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:fcfa854abdfb: avcodec/aacdec_fixed: Fix integer overflow in predict()
[01:29:21 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:8bd2ba44a108: avcodec/aacdec_fixed: Fix integer overflow in apply_dependent_coupling_fixed()
[01:29:22 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:0bd6717c0fd3: avcodec/xan: Improve overlapping check
[01:29:23 CET] <cone-515> ffmpeg 03Luca Barbato 07release/3.2:d6ecc61db8ea: avformat: Free the internal codec context at the end
[01:29:24 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:8b8502a66f00: avcodec/exr: fix undefined shift in pxr24_uncompress()
[01:29:25 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:d7c29005a40f: avcodec/xan: Check for bitstream end in xan_huffman_decode()
[01:29:26 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:7a8b61357c5a: avcodec/h264idct_template: Fix integer overflows in ff_h264_idct8_add()
[01:29:27 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:4d9f669a9f79: avutil/softfloat: Add FLOAT_MIN
[01:29:28 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:4e87ab803ad5: avcodec/aacsbr_fixed: Fix division by zero in sbr_gain_calc()
[01:29:29 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:473004689106: avcodec/sbrdsp_fixed: Fix integer overflow in shift in sbr_hf_g_filt_c()
[01:29:30 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:d857f1035bfe: avcodec/cngdec: Fix integer clipping
[01:29:31 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:5f58877bd929: avcodec/snowdec: Fix integer overflow in header parsing
[01:29:32 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:314d78992c1a: avcodec/mdct_*: Fix integer overflow in addition in RESCALE()
[01:29:33 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:1fc3ebbcd913: avcodec/aacdec_fixed: Fix undefined shift
[01:29:34 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:4654cc8cee07: avcodec/aacpsdsp_template: Fix integer overflows in ps_decorrelate_c()
[01:29:35 CET] <wm4> lrusak: do you mean v4l timestamp? I don't know about its conventions
[01:29:35 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:b51f515c5c83: avcodec/x86/mpegvideodsp: Fix signedness bug in need_emu
[01:29:36 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:cbc839681b16: avcodec/h264dec: Fix potential array overread
[01:29:37 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:e69edb7aef67: avcodec/vc2enc: Clear coef_buf on allocation
[01:29:38 CET] <cone-515> ffmpeg 03Fredrik Hubinette 07release/3.2:7d1404674023: avformat/mov: Check size of STSC allocation
[01:29:39 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:3e3e42dbc4b7: avcodec/snowdec: Check intra block dc differences.
[01:29:40 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:b24b316e3045: avcodec/snowdec: Check for remaining bitstream in decode_blocks()
[01:29:41 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:5fdc67956164: avcodec/wmv2dec: Check end of bitstream in parse_mb_skip() and ff_wmv2_decode_mb()
[01:29:42 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:37a14a3d83a3: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD137iL0()
[01:29:43 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:d6ff6dc56bf3: avcodec/zmbv: Check that the buffer is large enough for mvec
[01:29:44 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:81bf24a82749: avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output()
[01:29:45 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:c09c0ce374e5: avcodec/hevcdsp_template: Fix invalid shift in put_hevc_epel_bi_w_v()
[01:29:46 CET] <cone-515> ffmpeg 03Jacob Trimble 07release/3.2:a03d488ae2e4: avformat/mov: Propagate errors in mov_switch_root.
[01:29:47 CET] <cone-515> ffmpeg 03Dale Curtis 07release/3.2:380515e5b958: Use ff_thread_once for fixed, float table init.
[01:29:48 CET] <cone-515> ffmpeg 03Dale Curtis 07release/3.2:13763f719260: Fix undefined shift on assumed 8-bit input.
[01:29:49 CET] <cone-515> ffmpeg 03Dale Curtis 07release/3.2:02d11e616af3: Close ogg stream upon error when using AV_EF_EXPLODE.
[01:29:50 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:b48a36e77395: avcodec/mpeg4videodec: Check also for negative versions in the validity check
[01:29:51 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:42b9df5a98c7: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_FIDELITYi*
[01:29:52 CET] <wm4> I guess negative video PTS don't really happen
[01:29:52 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:857c5fa97641: avcodec/kgv1dec: Check that there is enough input for maximum RLE compression
[01:29:53 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:5ee4c376d0d9: avcodec/mlpdsp: Fix signed integer overflow, 2nd try
[01:29:54 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:e8a3b17dd470: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_epel_bi_w_h()
[01:29:55 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:50dd0e43af84: avcodec/j2kenc: Fix out of array access in encode_cblk()
[01:29:56 CET] <cone-515> ffmpeg 03Dale Curtis 07release/3.2:fc3e4c9ab300: avformat/utils: Prevent undefined shift with wrap_bits > 64.
[01:29:57 CET] <cone-515> ffmpeg 03Dale Curtis 07release/3.2:e1a854da2d54: avcodec/vorbis: 1 << 31 > int32_t::max(), so use 1u << 31 instead.
[01:29:58 CET] <cone-515> ffmpeg 03Dale Curtis 07release/3.2:32d16571924e: Don't manipulate duration when it's AV_NOPTS_VALUE.
[01:29:59 CET] <cone-515> ffmpeg 03Dale Curtis 07release/3.2:91c7cc9726d2: avcodec/vorbis: Fix another 1 << 31 > int32_t::max() with 1u.
[01:30:00 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:17b3485a6762: avcodec/dirac_dwt: Fix integer overflows in COMPOSE_DAUB97*
[01:30:01 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:49efdb1e77dd: avcodec/diracdsp: Fix integer overflow in PUT_SIGNED_RECT_CLAMPED()
[01:30:02 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:969485aacec3: avcodec/amrwbdec: Fix division by 0 in voice_factor()
[01:30:03 CET] <cone-515> ffmpeg 03Jun Zhao 07release/3.2:1a6f38b31b23: avfilter/formats: fix wrong function name in error message
[01:30:04 CET] <cone-515> ffmpeg 03Kelly Ledford 07release/3.2:235a55700b45: libavfilter/af_dcshift.c: Fixed repeated spelling error
[01:30:05 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:ce2804775527: avcodec/hevcdsp_template: Fix undefined shift in put_hevc_qpel_bi_w_hv()
[01:30:06 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:34cad2f0e2bd: avcodec/hevc_sei: Fix integer overflows in decode_nal_sei_message()
[01:30:07 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:9ad735588c9e: tests/audiomatch: Add missing return code at the end of main()
[01:30:08 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:8bd6bf821431: avcodec/hevc_cabac: Fix integer overflow in ff_hevc_cu_qp_delta_abs()
[01:30:09 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:2c60731777f6: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0() and COMPOSE_DD137iL0()
[01:30:10 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:954c2b07b6fe: avcodec/hevcdsp_template.c: Fix undefined shift in FUNC(dequant)
[01:30:11 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:4be2a19822da: avcodec/flacdec: avoid undefined shift
[01:30:12 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:34a9bef0c90e: avcodec/hevcdsp_template: Fix Invalid shifts in put_hevc_qpel_bi_w_h() and put_hevc_qpel_bi_w_w()
[01:30:13 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:ab0e4b5b51fc: avcodec/flacdec: Fix overflow in multiplication in decode_subframe_fixed()
[01:30:14 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:439f3564fa54: avcodec/exr: Check buf_size more completely
[01:30:15 CET] <cone-515> ffmpeg 03Luca Barbato 07release/3.2:6d654eb036ce: x264: Support version 153
[01:30:16 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:c4ead1ab27f4: avcodec/dnxhddec: Check dc vlc
[01:30:17 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:3f86cc068084: avcodec/h264_slice: Do not attempt to render into frames already output
[01:30:18 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:d89941aa89c9: avcodec/jpeg2000dsp: Fix integer overflows in ict_int()
[01:30:19 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:c28752f03a9e: avcodec/opus_parser: Check payload_len in parse_opus_ts_header()
[01:30:20 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:a9fb75893bc7: avcodec/diracdec: Fix integer overflow with quant
[01:30:21 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:1ab3e34cb44c: avcodec/dirac_dwt: Fix overflows in COMPOSE_HAARiH0/COMPOSE_HAARiL0
[01:30:22 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:adfefc9c9aaf: avcodec/h264addpx_template: Fixes integer overflows
[01:30:58 CET] <lrusak> or should I just check if (v4l2_pts < 0) return AV_NOPTS_VALUE;
[01:31:29 CET] <wm4> what problem are you trying to solve?
[01:32:18 CET] <lrusak> if a valid pts isn't returned
[01:33:09 CET] <lrusak> and in regards to the other time_base issue, v4l2 has the flag V4L2_BUF_FLAG_TIMESTAMP_COPY	which I think would be good to use
[01:34:13 CET] <wm4> are you trying to use the decoder and it sometimes returns broken PTS or what is the problem?
[01:35:06 CET] <lrusak> well, the issue really was the time_base problem, when it wasn't set I would get an invalid pts. So I just wanted to add a check.
[01:38:48 CET] <wm4> I mean you could check for an unset pkt_timebase, and make the v4l decoder refuse init if unset
[01:40:29 CET] <lrusak> can I ask, why would the timebase ever change?
[01:41:36 CET] <wm4> it doesn't at runtime
[01:42:02 CET] <wm4> it's just that different container formats use different timebases
[01:42:36 CET] <lrusak> hmm ok
[01:43:10 CET] <lrusak> so based on the container I should set the pkt_timebase?
[01:43:32 CET] <lrusak> pkg_timebase should be set by the application correct?
[01:44:42 CET] <wm4> yes
[01:47:28 CET] <lrusak> ok, will do
[01:48:38 CET] <cone-515> ffmpeg 03Kyle Swanson 07master:42a5fe340fb3: doc/filters: correct typo in psnr filter docs
[03:28:03 CET] <cone-515> ffmpeg 03Michael Niedermayer 07release/3.2:4fb4a642c63f: Update for 3.2.10
[05:07:40 CET] <atomnuker> what's the bloody deal with aurelien?
[05:09:40 CET] <wm4> is there a problem
[05:10:38 CET] <atomnuker> yes, he's admitting aptx and aptx hd are very similar in bitstream but refuses to accept one's just a profile and wants to define a new codec id for it
[05:10:58 CET] <atomnuker> because "its more obvious to users"
[05:12:01 CET] <atomnuker> sure it is but if we used "its more obvious to users" we'd have a separate api for each decoder "because its more obvious"
[05:12:42 CET] <atomnuker> using a profile here makes things more generic yet still allows users to discern between both flavors of a codec
[05:13:29 CET] <atomnuker> he did the same with sbc as well, just made 3 separate codec ids for each profile
[05:17:15 CET] <wm4> ask him nicely?
[05:28:54 CET] <atomnuker> did, explained to him what to do to make it work, then why its better if we use profiles
[07:49:33 CET] <fff> sup guys
[08:18:29 CET] <durandal_1707> atomnuker: admit that your idea is bad
[10:24:15 CET] <durandal_1707> the filters doc on web page havent been updated for more than 24h
[12:29:30 CET] <cone-270> ffmpeg 03Paul B Mahol 07master:7add1ca2b5af: avfilter/af_aiir: add cascaded biquads support
[12:29:31 CET] <cone-270> ffmpeg 03Paul B Mahol 07master:d9a3074b93ac: avfilter/af_aiir: add slice threading support
[13:09:14 CET] <cone-270> ffmpeg 03Paul B Mahol 07master:21c99f4b40de: avfilter/af_aiir: make default processing to serially cascaded
[14:09:49 CET] Action: jdarnley is back on vc2enc
[14:24:47 CET] <jdarnley> Dammit people!  Why couldn't you leave --disable-ffserver in as a compatability option?
[15:04:39 CET] <cone-270> ffmpeg 03James Almer 07master:ded409b7c9c2: avresample: remove deprecated attribute from the AVAudioResampleContext struct
[16:22:25 CET] <kierank> jdarnley: is fragment suppprt in mainline
[16:22:36 CET] <jdarnley> Not yet
[16:23:24 CET] <jdarnley> That is one of the things I plan to put in
[16:23:39 CET] <jdarnley> I will also try for const quant again
[16:53:23 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vNqll
[16:53:23 CET] <KGB> 13FFV1/06master 14dee437f 15Jérôme Martinez: White space for forcing carriage return in a paragraph
[17:55:33 CET] <cone-270> ffmpeg 03Paul B Mahol 07master:e9edd61965da: avfilter/af_aiir: refactor code so it uses IIRChannel struct
[18:03:26 CET] <cone-270> ffmpeg 03Paul B Mahol 07master:d38a223943d1: doc/filters: update aiir filter documentation
[18:17:03 CET] <KGB> [13FFV1] 15michaelni closed pull request #97: change definitions from use of luminance to use of luma (06master...06ab/luma-in-definitions) 02https://git.io/vNfiM
[18:59:16 CET] <KGB> [13FFV1] 15michaelni closed pull request #90: Use Golomb Rice wording when applicable (06master...06VLC) 02https://git.io/vNvVZ
[19:16:56 CET] <durandal_170> why is everything so silent here?
[19:23:09 CET] <j-b> durandal_170: because january?
[19:23:29 CET] <durandal_170> whats in january?
[19:30:39 CET] <DHE> vacation because it's cold
[19:30:55 CET] <durandal_170> lies
[20:07:50 CET] <kierank> who wants to be backup mentor
[20:08:01 CET] <durandal_170> kierank: encoder?
[20:08:09 CET] <kierank> no, add features that are missing
[20:08:13 CET] <kierank> to decoder
[20:08:15 CET] <kierank> and make fast
[20:08:42 CET] <durandal_170> but but but encoder
[20:09:49 CET] <kierank> gsoc encoders are few and far between
[20:10:58 CET] <durandal_170> whois using radare for reing?
[20:13:58 CET] <durandal_170> filtering ideas for gsoc?
[20:15:23 CET] <kierank> durandal_170: you don't want to backup mentor?
[20:16:09 CET] <atomnuker> kierank: yeah, put me on as backup mentor
[20:18:23 CET] <durandal_170> kierank: for encoder? sure
[20:18:42 CET] <kierank> dunno if student can finish decoder and write encoder
[20:19:10 CET] <durandal_170> gsoc 2019 then
[20:19:11 CET] <atomnuker> it didn't work for the jpeg2k and dirac stuff many years ago
[20:19:43 CET] <atomnuker> but those were done from scratch
[20:25:05 CET] <thresh> going to reboot videolan server which is hosting ffmpeg git right now, due to meltdown.
[20:26:58 CET] <BBB> ty for letting us know
[20:27:39 CET] <thresh> the machine is up, things should be back to normal
[20:31:56 CET] <thresh> you're welcome BBB 
[20:31:58 CET] <thresh> cheers
[20:32:41 CET] <philipl> BtbN: http://ieeexplore.ieee.org/document/6803847/ A cuda deinterlacing paper. Paywalled however.
[20:32:56 CET] <durandal_170> buy it!
[20:34:01 CET] <philipl> And expense it? :-P
[21:48:02 CET] <jkqxz> atomnuker:  Could we make a project for GSoC from OpenCL/Vulkan for GPU something filtering something?  Probably easier with OpenCL because it's already there, but Vulkan might attract more interest now and could be more useful in the long run.
[21:49:15 CET] <atomnuker> nah, I'll finish it, I'm not that far off, I have the hwcontext done and went as far as hooking up glslang to the configure system and writing a half-finished chromaticaberration filter
[21:49:27 CET] <atomnuker> what would be interesting would be motion compensation filter
[21:49:41 CET] <atomnuker> because many people are complaining that the minterpolate filter is extermely slow
[21:50:04 CET] <jkqxz> There are a lot of different things it could have a use for.  For filtering: scaling (many algorithms and ways to do it), deinterlacing, colourspace conversion, probably quite a few other things.  For codecs, ffv1 stands out as something which gets a lot of use but is not implemented in hardware anywhere.
[21:50:05 CET] <atomnuker> having one on the gpu would be awesome as we could use it for encoders too
[21:50:46 CET] <atomnuker> wow, ffv1 on the gpu
[21:51:24 CET] <nevcairiel> I doubt that would be particularly useful
[21:51:35 CET] <nevcairiel> gpu shaders are bad at that kind of thing
[21:52:29 CET] <jkqxz> I had a bit of a think about it for ffv1, if there are plenty of slices then it does work pretty plausibly.  Dunno if the result would actually be useful, though.
[21:52:47 CET] <atomnuker> with many slices you lose compression
[21:55:27 CET] <jkqxz> Do you know how much that actually matters for large streams?
[21:56:09 CET] <nevcairiel> dont you like need hundreds if not thousands of slices for gpus to be actually good
[21:57:54 CET] <jkqxz> Perhaps.  I have not actually written anything to test this idea.
[21:58:50 CET] <jkqxz> The filtering stuff is definitely a lot more obviously tractable.
[22:21:05 CET] <durandal_1707> i think cineform  task to be hard for students, bunch of code to grasp...
[22:21:34 CET] <kierank> the cineform code is hard to understand, yes
[22:21:44 CET] <kierank> their one
[22:21:45 CET] <kierank> ours is ok
[22:22:16 CET] <durandal_1707> yes
[22:22:52 CET] <durandal_1707> michaelni: who is responsible for doc html cronjob?
[22:23:03 CET] <durandal_1707> on ffmpeg.org site
[22:23:25 CET] <atomnuker> llogan and him afaik
[23:12:00 CET] <durandal_1707> how transforming sound to text works?
[00:00:00 CET] --- Wed Jan 10 2018


More information about the Ffmpeg-devel-irc mailing list