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

[burek]

[07:33:32 CET] <cone-910> ffmpeg 03Karthick J 07master:ca5ec4cbbcf3: avformat/dashenc: Added option to repeatedly publish master playlist
[07:33:32 CET] <cone-910> ffmpeg 03Karthick J 07master:2e67f751b55b: avformat/dashenc: Added comments
[09:50:54 CET] <JEEB> #7637 sounds like fun with sanity checks :P
[09:52:02 CET] <JEEB> (or just failed duration handling, although the empty initial sample description sounds a bit weird)
[11:23:30 CET] <j-b> 'morning
[11:26:25 CET] <BradleyS> o/
[12:41:09 CET] <atomnuker1> I found out that /usr/bin/mjpeg_simd_helper
[12:41:11 CET] <atomnuker1> is a thing
[12:41:33 CET] <kierank> atomnuker1: what is it
[12:41:51 CET] <atomnuker1> its only job is to tell you what values you can put in MJPEGTOOLS_SIMD_DISABLE to disable certain simd optimizations
[13:08:27 CET] <durandal_1707> do we have KBD window already implemented in AAC?
[13:10:38 CET] <durandal_1707> oh, we have it
[13:13:16 CET] <durandal_1707> :) less work
[13:20:25 CET] <atomnuker1> you can make your own with ff_kbd_window_init in case the coeff is different
[13:20:51 CET] <durandal_1707> yes, very nice
[13:28:48 CET] <durandal_1707> well, i need to modify FF_KBD_WINDOW_MAX to 2048
[13:29:44 CET] <atomnuker1> what window shapes are used for the mod-15 and the other nptwo transforms?
[13:32:11 CET] <durandal_1707> some strange formulas, various combination, look from page 170
[13:32:33 CET] <durandal_1707> it uses KBD_LEFT and KBD_RIGHT
[13:49:00 CET] <durandal_1707> hmm, this is either simplified version (using some math to simplify forumulas) or completely different thing
[13:56:45 CET] <durandal_1707> the bessel stuff is different
[13:58:03 CET] <durandal_1707> hmm, AC3 uses it too, lets see AC3 spec
[14:01:32 CET] <durandal_1707> not useful, its hardcoded single table
[14:13:39 CET] <durandal_1707> ac4 uses same alpha as aac for similar windows, so it must be that thing, or there is another very similar window that allows reversible mdct
[17:12:42 CET] <cone-965> ffmpeg 03Gyan Doshi 07master:cdf17cf92b0f: doc: -report defaults to loglevel debug
[18:04:53 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:160851bceed7: avcodec/arbc: Check nb_tiles against dimensions
[18:04:54 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:32d022d26db4: avcodec/mjpegdec: Fix stereo3d memleak
[18:04:55 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:e4289cb253e2: avcodec/error_resilience: Use a symmetric check for skipping MV estimation
[18:04:56 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:286a33e42944: avcodec/wcmv: Copy/Init frame later
[18:04:57 CET] <cone-965> ffmpeg 03Michael Niedermayer 07master:976dae8b32f4: avcodec/wcmv: Avoid copying frames if they are unchanged
[20:17:52 CET] <durandal_1707> WOW, I got recognisable audio from ac4 decoder, but it is not realtime speed
[20:17:59 CET] <JEEB> najs
[20:19:49 CET] <thardin> coolers
[21:01:45 CET] <JEEB> wow
[21:01:47 CET] <JEEB> M264
[21:01:50 CET] <JEEB> some matrox encoder
[21:02:16 CET] <nevcairiel> one of those super old 264 variants?
[21:02:33 CET] <JEEB> nah, probably just Matrox's HW encoder
[21:02:41 CET] <JEEB> wonder for which piece of hardware
[21:03:13 CET] <atomnuker1> hey, matrox, they were the name of hard drivers some years ago
[21:03:25 CET] <atomnuker1> actually never, they were crap
[21:34:21 CET] <jkqxz> There is something very weird going on there.  It dlopens some libraries, and the symbols it looks for have "ffmpeg" in the names?
[21:34:29 CET] <jkqxz> Also, H.264 4:2:2 only!
[21:35:13 CET] <JEEB> well the added AVCodec is also interesting but I'd just put that under "newbie mistakes"
[21:41:19 CET] <thardin> it's dlopen()ing .so/.dll files
[21:41:35 CET] <thardin> which is a no-no by policy IIRC
[21:43:42 CET] <JEEB> yea that sounds funky
[21:46:56 CET] <thardin> that type punning via union seems like a double-whammy of both being undefined behavior (maybe unspecified), and endian specific
[21:49:17 CET] <jkqxz> It kindof looks they have a (possibly-sensible) patch for lavc support, but it's then had an outer dynload layer quickly hacked in to evade copyright.  We're only seeing that outer layer, so it's bizarre.
[21:50:13 CET] <thardin> myeah it reeks of gpl circumvention
[21:50:18 CET] <jkqxz> (Since the symbols it loads are basically the ffmpeg codec implementation functions themselves.)
[21:50:58 CET] <thardin> also I was wrong, type punning is fine in C
[21:51:02 CET] <thardin> not C++ tho
[22:08:45 CET] <j-b> +   m264_decoder->init_m264_decoder = dlsym(lib_handle, "m264_ffmpeg_decoder_init");
[22:09:11 CET] <j-b> That feels very very weird
[22:20:11 CET] <thardin> lol
[22:21:23 CET] <thardin> would be funnier if it took AVCodecContext* instead of void*
[22:22:05 CET] <JEEB> :D
[22:22:46 CET] <thardin> that M264DecoderInfo struct just defined in the .c file instead of a header
[22:24:17 CET] <thardin> >If it fails to load, you just continue? Honestly?
[22:24:22 CET] <thardin> hah, I totally missed that
[23:41:48 CET] <kierank> JEEB: wtf
[23:41:57 CET] <kierank> this is someone's blob afaik
[23:42:16 CET] <nevcairiel> it looks very blobish and unpolished
[23:42:51 CET] <JEEB> yes
[23:43:07 CET] <JEEB> I mean, the .so/.dll loading already yells "BLOB"
[23:43:16 CET] <JEEB> and then it just keeps rolling forwards from that
[23:47:22 CET] <kierank> JEEB: why though
[23:48:37 CET] <JEEB> my guess is someone just got told to try and integrate their stuff into FFmpeg
[23:56:58 CET] <BtbN> thardin, well, it's precisely how all the nvidia stuff works as well, to avoid ffmpeg binaries using it to only work on nvidia systems.
[23:59:18 CET] <cone-815> ffmpeg 03Andreas Rheinhardt 07master:c5b452ed2f16: filter_units, trace_headers: Always use fragment from context
[23:59:18 CET] <cone-815> ffmpeg 03Andreas Rheinhardt 07master:b8c45bbcbc20: libavcodec/cbs: Stop needlessly reallocating the units array
[00:00:00 CET] --- Tue Feb 26 2019