[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