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

[burek]

[00:06:30 CET] <durandal_1707> nobody knows how rl2 works?
[01:13:47 CET] <durandal_1707> michaelni_: can you explain meaning of each table in RLTable?
[03:41:24 CET] <cone-530> ffmpeg 03Fei Wang 07master:1ea44178f5ff: avcodec/cbs_av1: avoid reading trailing bits when obu type is OBU_TILE_LIST
[07:49:21 CET] <cone-470> ffmpeg 03Jun Zhao 07master:8d823e6005fe: lavf/libsrt: add linger parameter to libsrt
[07:49:21 CET] <cone-470> ffmpeg 03Jun Zhao 07master:952fd0c76874: lavf/libsrt: enable other encryption parameters
[07:49:21 CET] <cone-470> ffmpeg 03macweng 07master:e3c732bb0c9b: configure: add OPENSSL_init_ssl check if pkg-config fail
[07:49:21 CET] <cone-470> ffmpeg 03Jun Zhao 07master:4eae85a82f81: lavf/tls_openssl: support both pre-1.1.0 and post-1.1.0 init
[08:22:37 CET] <cone-470> ffmpeg 03Steven Liu 07master:ed8976333624: avformat/hlsenc: remove duplicate code block
[08:22:38 CET] <cone-470> ffmpeg 03Steven Liu 07master:4110029e562c: avformat/cache: rename the class name fro Cache to cache
[10:39:20 CET] <cehoyos> nevcairiel: That is not entirely correct, at least mentioning FFmpeg and the LGPL are an explicit requirement to comply
[10:40:06 CET] <cehoyos> (And you are not right about "mailing them is ok": They would have to make a legally binding offer to provide sources on request, that made sense before the internet but is irrelevant now)
[10:40:30 CET] <cehoyos> We have founds now and could decide to go after license violators.
[10:40:45 CET] <cehoyos> The question is if we have something to offer to them, this is not 100% clear imo
[10:43:05 CET] <nevcairiel> In any case, if you really wanted to go after license violations, using LGPL violations is still boring and not very fruitful, because all they need to do is add a bunch of text somewhere, spending energy on those non-free cases is far more interesting
[10:46:48 CET] <thardin> if they've baked them together like that then the code that does the baking should fall under the LGPL, right?
[10:47:03 CET] <thardin> probably not a huge issue to just release that
[10:47:17 CET] <thardin> so not very fruitful
[10:47:40 CET] <nevcairiel> baking like that is one command of a linker
[10:47:43 CET] <nevcairiel> not even code
[10:47:50 CET] <nevcairiel> i do that myself with some libraries
[10:48:32 CET] <nevcairiel> build as static libraries, bake into a dll and export all library symbols, done
[11:39:58 CET] <cone-470> ffmpeg 03Gyan Doshi 07master:78676ee8f812: avfilter/scale_eval: remove redundant mathematical constants
[11:55:22 CET] <durandal_1707> i guess i can not use rl table as its uses 16bit elements for codes, while mine have max of 18bit
[13:21:08 CET] <Illya> VLC_TYPE is also 16
[15:50:58 CET] <jamrial> any suggestion about the MPEG-H 3D patch? regarding how it tags audio key frames by changing is_intra_only() in lavf/utils.c
[15:51:36 CET] <jamrial> that function should be more general. it looks for AV_CODEC_PROP_INTRA_ONLY only on video codecs, despite the prop being allowed on audio codecs
[15:52:36 CET] <jamrial> and currently, only a bunch of lossless audio codecs set that prop
[15:53:52 CET] <JEEB> yea
[15:54:00 CET] <JEEB> basically thankfully most audio formats have that prop
[15:54:06 CET] <JEEB> I mean, they are intra-only
[15:54:25 CET] <jamrial> no, most don't set that prop
[15:54:31 CET] <JEEB> yes, I miswrote
[15:54:32 CET] <JEEB> sorry
[15:54:42 CET] <JEEB> I meant, all of them are/should be intra only
[15:55:00 CET] <JEEB> thus setting that flag and changing the code to be general
[15:55:18 CET] <jamrial> so codec_desc.c needs an overhaul :p
[15:55:18 CET] <JEEB> instead of having an if audio | MPEG-H 3D audio
[15:55:57 CET] <JEEB> yea I see for mayn formats the vlaues are set there
[15:56:11 CET] <jamrial> which codecs would not set intra_only? truehd, mpeg-h 3d, and what else?
[15:56:21 CET] <JEEB> aC-4, which we don't atm have
[15:56:26 CET] <JEEB> not sure about game codecs
[15:56:51 CET] <JEEB> but currently I think audio codecs are set generally intra only, no?
[15:57:06 CET] <JEEB> and was truehd really with inter prediction?
[15:57:20 CET] <jamrial> it has sync frames
[15:57:24 CET] <JEEB> ah
[15:58:28 CET] <JEEB> but yea, I feel really awful for not for whatever reason having brought this up a few weeks ago when I first noticed it
[15:59:04 CET] <jamrial> codec_desc.c doesn't set intra_only for the vast majority of audio codecs. i don't know if this is done or assumed elsewhere in the codebase
[15:59:28 CET] <JEEB> wasn't is_intra_only more or less assuming that?
[16:00:07 CET] <JEEB> yea, it would return 1 for audio formats
[16:00:09 CET] <jamrial> ah yeah, for every audio codec. my bad
[16:00:20 CET] <JEEB> not sure how many things utilize that function
[16:00:37 CET] <JEEB> after all the packet should also have that mentioned'
[16:00:59 CET] <jamrial> lavf util demuxing code, av_read_frame()
[16:02:14 CET] <jamrial> so, set intra_only prop for every codec in codec_desc.c sans the aforementioned couple, update is_intra_only(), and hope nothing breaks? :p
[16:02:59 CET] <JEEB> *every audio codec
[16:03:05 CET] <jamrial> yeah
[16:04:17 CET] <mkver> It might also affect the Real audio codecs (cook, sipr, atrac3, ra 288).
[16:05:08 CET] <mkver> At least when mkvmerge muxes them into Matroska, not all of the blocks get a keyframe flag. But this might just be how it is done in Matroska.
[16:05:26 CET] <mkver> Someone with more knowledge about these codecs should be consulted.
[16:05:41 CET] <jamrial> yeah, for truehd mkvmerge sets only the sync frames as key
[16:06:04 CET] <JEEB> but yea, I'd say for now (unless we want to get rid of that function), that would make it more sensible and more or less follow suite on what the function is returning atm (while letting you have non-intra only audio formats)
[16:43:08 CET] <durandal_1707> ac-4 have sync frames too
[16:43:53 CET] <durandal_1707> and because of current state in ffmpeg, it does not handle seeks very well, because lavc does not call flush
[16:45:21 CET] <jamrial> durandal_1707: would correclty setting keyframes in demuxer or parser rather than in lavf/utils.c as mentioned above help with that?
[16:46:08 CET] <Lynne> doesn't mpv's mkv demuxer have a hack to force mark all audio except truehd as keyframe because muxers don't really set it?
[16:48:01 CET] <jamrial> sounds like a workaround for precisely the current behavior in ffmpeg
[16:49:01 CET] <Lynne> so that's where the broken files came from
[16:55:21 CET] <cone-470> ffmpeg 03Andreas Rheinhardt 07master:91f775e0c533: avformat/apc: Remove unnecessary resetting of flags
[16:55:22 CET] <cone-470> ffmpeg 03Andreas Rheinhardt 07master:a6d292b954cb: avformat/flvenc: Don't reimplement ff_alloc_extradata
[16:55:23 CET] <cone-470> ffmpeg 03Andreas Rheinhardt 07master:86e9747c634b: avformat/iff: Use ff_alloc_extradata
[20:27:30 CET] <cone-191> ffmpeg 03Fei Wang 07master:5fc3099cafc8: avcodec/cbs_av1: rename enable_intraintra_compound flag
[21:47:11 CET] <cone-191> ffmpeg 03Martin Storsjö 07master:6569e9505c78: network: Define ENOTCONN as WSAENOTCONN if not defined
[21:47:12 CET] <cone-191> ffmpeg 03Martin Storsjö 07master:8f70e261fa6f: checkasm: float_dsp: Scale FLT/DBL_EPSILON sufficiently when comparing
[21:47:13 CET] <cone-191> ffmpeg 03Martin Storsjö 07master:c27a85b98355: fate: Use a oneoff test for the tremolo filter
[22:47:59 CET] <jamrial> jkqxz: there are some cbs patches that could use your eyes whenever you have time
[23:00:45 CET] <durandal_1707> why i get integer overflows when calling idctRowCondDC_int16_12bit ?
[23:00:57 CET] <durandal_1707> for Y component it works
[23:01:04 CET] <durandal_1707> for U/V it barfs out
[23:27:58 CET] <iive> U/V are signed or offsetted
[23:30:11 CET] <cone-191> ffmpeg 03James Almer 07master:a23dd33606d5: avcodec/cbs_av1: fix array size for ar_coeffs_cb_plus_128 and ar_coeffs_cr_plus_128
[00:00:00 CET] --- Thu Dec 12 2019