[01:09] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:0d4a66ee7f48: avformat/aviobuf: ffio_ensure_seekback: only copy the initialized part of the buffer [01:09] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:61b5ef775413: libavformat/aviobuf: keep track of the original buffer-size and restore it after probe/ensure-seekback [01:27] <cone-517> ffmpeg.git 03Vittorio Giovara 07master:e50f5d3cf9ef: Alias PIX image encoder and decoder [01:27] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:12ab07be4472: Merge commit 'e50f5d3cf9ef9a16982a5cb4d8b1916cd963aa5b' [02:05] <cone-517> ffmpeg.git 03Vittorio Giovara 07master:9718c31ef60c: fate: add Alias PIX tests [02:05] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:62094e2fddf5: Merge remote-tracking branch 'qatar/master' [04:07] <cone-517> ffmpeg.git 03Andreas Cadhalpun 07master:cf3bfc970c7a: Fix texinfo error due to wrong @subsubsection [04:07] <cone-517> ffmpeg.git 03Andreas Cadhalpun 07master:d473f2d18aef: Fix spelling errors in texi files: more informations --> more information allows to --> allows one to [05:03] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:d5c9843cd2e7: configure: fix VP7 standalone build [05:03] <cone-517> ffmpeg.git 03Michael Niedermayer 07master:57e939d96380: avcodec/vp7: Fix null pointer dereference in vp7_decode_frame_header() [09:07] <nevcairiel> JEEB: i knew this day would come, someone gave me a AAC file which uses SSR... [11:24] <Compn> nevcairiel : does that mean you have to support it now? :P [11:30] <nevcairiel> nah i just have to tell them to get lost [13:03] <cone-106> ffmpeg.git 03Michael Niedermayer 07release/2.2:a80a7131d11a: swscale/swscale: fix integer overflow [13:03] <cone-106> ffmpeg.git 03Michael Niedermayer 07release/2.2:adad1ba5d86b: avcodec/vorbisdec: use the stored previous window type only when the actual previous is not known [13:03] <cone-106> ffmpeg.git 03Michael Niedermayer 07release/2.2:2c566744c41e: avcodec/vorbis: fix decoding of single element huffman trees [13:03] <cone-106> ffmpeg.git 03Michael Niedermayer 07release/2.2:314f055c294b: dox/scaler:fix bicubiclin typo [13:03] <cone-106> ffmpeg.git 03Michael Niedermayer 07release/2.2:b40ab81d1f54: avcodec/x86/mpegvideoenc_template: fix integer overflow [13:03] <cone-106> ffmpeg.git 03James Almer 07release/2.2:1103aec1df38: x86/cpu: check for OS support before enabling AVX2 [13:03] <cone-106> ffmpeg.git 03Michael Niedermayer 07release/2.2:ef0c503d3781: avcodec/h264_mp4toannexb_bsf: prepend global headers before any in stream parameter sets [13:03] <cone-106> ffmpeg.git 03wm4 07release/2.2:81cfe391135c: vf_pullup: simplify, fix double free error [13:03] <cone-106> ffmpeg.git 03Michael Niedermayer 07release/2.2:194485cfbaac: avfilter/vf_pullup: zero freed memory for saftey [13:03] <cone-106> ffmpeg.git 03Andreas Cadhalpun 07release/2.2:3cd1c8653b51: Fix texinfo error due to wrong @subsubsection [13:03] <cone-106> ffmpeg.git 03Andreas Cadhalpun 07release/2.2:31c21d2f6905: Fix spelling errors in texi files: more informations --> more information allows to --> allows one to [13:18] <BBB> was my email html-formatted? [13:18] <BBB> I hope not [14:23] <ubitux> BBB: seems not [16:53] <superware> is there a way to hint avformat_find_stream_info about a network stream codec? I want to save time while ensuring the right parameters are being detected. [16:57] <Compn> dunno superware . try asking on libav-user list for 3rd party app development / api questions ? or stick around here and #ffmpeg wait for answer :) [16:57] <Compn> sorry i cannot help [17:13] <superware> ok, thanks [18:18] <haasn> I'd be interested in adding BT.2020 support to swscale, possibly so I can transcode BT.709 content to BT.2020 for testing and comparison purposes [18:19] <haasn> I'd also be interested in what kind of improvement we could see from using BT.2020-CL to encode even BT.709 or BT.2020-NCL content; when reducing the bitrate [18:19] <haasn> So for that I'd need correct conversion in swscale as well [18:22] <wm4> "good luck" [18:26] <kierank> 709 to 2020 and vice versa iirc is not as simple as you think [18:26] <kierank> there are various papers on the topic [18:27] <haasn> kierank: I don't follow, why? [18:27] <haasn> 709 to 2020ncl in particular should just be a simple matrix multiplication [18:27] <haasn> 709 or 2020ncl to 2020cl would be more complicated, I haven't quite worked out the details in my head [18:28] <haasn> worst case scenario is go through RGB [18:29] <kierank> it's 2020 to 709 apparently that's nontrivial [18:30] <kierank> linear approximations according to the discussion I see [18:30] <kierank> i don't know why though [18:30] <haasn> I guess it depends on what exactly we're talking about [18:31] <kierank> anyway afaik swscale doesn't do yuv matrix conversions like that [18:31] <kierank> ffmbc ported theirs from avisynth [18:31] <haasn> adjusting between primaries is a mess [18:31] <nikitos_> Hello! I have asked my question in #ffmpeg and libav-users. Does libavcodec supports vaapi encoding (uses hardware accels)? In other places they answered no, ffmpeg doesn`t support it, But when I`m building ffmpeg with libva (vaapi) support it have h264_accel in hardware accels section. What is it? [18:31] <haasn> but the encoding techniques should be equivalent, they all cover the exact same range [18:32] <JEEBsv> nikitos_: it's the _decoder_ [18:32] <JEEBsv> as I said [18:32] <haasn> kierank: how does swscale do Y'CbCr conversions? [18:32] <haasn> say, from R'G'B' to BT.709 Y'CbCr [18:32] <kierank> hardcoded to 601 [18:32] <haasn> err.. [18:32] <kierank> yuv to rgb will work though [18:33] <nikitos_> Oh! I see! thanks. [18:33] <kierank> also you'd need to add a 12-bit pixel format [18:33] <haasn> is the implication of that that encoding from an RGB source (like a .png) into Y'CbCr that it will *always* use BT601 Y'CbCr values? [18:33] <kierank> I believe yes [18:34] <haasn> interesting [18:34] <haasn> x264 uses swscale under the hood right? so if I encode with x264 input.png --colormatrix BT.709 # this will produce a mistagged file? [18:35] <JEEBsv> yes [18:35] <haasn> okay [18:35] <JEEBsv> x264 uses lavf/lavc/swscale for input and colorspace conversion [18:35] <haasn> I guess the bottom line for that is make sure you're using the correct Y'CbCr source and just don't touch it [18:35] <JEEBsv> the only thing x264 does internally is bit depth conversion [18:35] <haasn> kierank: BT.2020 supports 10-bit too; but I guess 12 bit will be needed for full compatibility, yes [18:36] <haasn> 12 bit shouldn't be much harder than 10 bit, no? It's the same calculation, you just replace in 2^(12-8) instead of 2^(10-8) when deriving the constants [18:36] <kierank> won't be difficult but there might need to be some assembly changes [18:37] <haasn> okay [18:37] <kierank> haasn: if you don't mind me asking how come you are interested in 2020 [18:39] <haasn> kierank: I implemented it in mpv and I want more sources/evaluation/testing beyond the clips I generated. I'm interested in seeing if BT.2020-CL can produce a quality/filesize improvement even for BT.709 content like Blu-rays [18:39] <haasn> As for how I got the idea to implement it in the first place? I.. don't actually know [18:39] <haasn> I forgot [18:39] <JEEBsv> he learned about it and then specs were thrown at him [18:39] <haasn> kierank: half of it is being prepared and one-upping every other player ;) [18:40] <JEEBsv> and he still is pure regarding swscale [18:42] <wm4> kierank: he's a color nerd, he can't not do it [19:25] <superware> is there a way to hint avformat_find_stream_info about a network stream codec? I want to save time while ensuring the right parameters are being detected. [19:25] <JEEB> not really, but you can make the amount of data it uses for checking small [19:25] <JEEB> *smaller [19:35] <superware> JEEB: if the default is 5 seconds, why does it always take 5 seconds if it can also identify it in 500ms? [19:36] <wm4> superware: well there are various things which can make it slow [19:37] <wm4> probe buffer size, analyze duration, and overhead when opening a file [19:37] <superware> it's a network stream [19:37] <wm4> e.g. in one case I found out that reading the mp4 headers took so long because it was reading over the whole damn file [19:37] <superware> wow [19:38] <wm4> so IMO you'll have to special-tune it in the worst case, and according to your use case [19:38] <superware> it seemed logical that hinting the codec might reduce the probing time [19:39] <BtbN> well, mp4 is a little bit strange there. The header is at the end [19:39] <superware> "at the end"? of each frame? [19:40] <BtbN> of the file. [19:40] <superware> I'm opening a SDP file describing the codec [19:40] <superware> BtbN: in my case it's a RTP network stream [19:40] <BtbN> a stream can't be mp4 [19:40] <superware> h.264 [19:40] <BtbN> that's not a container [19:41] <superware> hmm [19:43] <superware> it's an IP camera, which container can it be? [19:43] <superware> H264 over RTSP? [19:44] <superware> I mean over RTP [19:50] <wm4> BtbN: for mp4 it should just seek to the end, but in my case it was skipping over the whole file in increments; aynway, that was just an example how opening a file can become extremely slow [19:51] <BtbN> wm4, that's because it is not neccesarily at the end [19:51] <BtbN> it can be litteraly anywhere in the file [19:51] <wm4> BtbN: I understand that, but in this case it had something to do with index creation or something [20:25] <cone-106> ffmpeg.git 03Diego Biurrun 07master:c3a0b3eb64be: arm: build: Maintain decoder objects separate from infrastructure objects [20:25] <cone-106> ffmpeg.git 03Michael Niedermayer 07master:68014c6ed98b: Merge commit 'c3a0b3eb64be441ca897629e8ecd80d5b51fded7' [21:14] <Compn> something something free speech [21:19] <JEEB> something something the type of people who usually play that card :) [21:32] <cone-106> ffmpeg.git 03Aleksi Nurmi 07master:ae17878fb2ab: BRender PIX image decoder [21:32] <cone-106> ffmpeg.git 03Michael Niedermayer 07master:f392949f1ac7: Merge commit 'ae17878fb2ab100264226c84c58f5b95a703312f' [21:43] <cone-106> ffmpeg.git 03Vittorio Giovara 07master:bb36b9aa7ef8: fate: add BRender PIX tests [21:43] <cone-106> ffmpeg.git 03Michael Niedermayer 07master:09ebd87a34b9: Merge remote-tracking branch 'qatar/master' [22:52] <cone-106> ffmpeg.git 03Michael Niedermayer 07master:850642331829: avcodec/brenderpix: remove unused variable [22:52] <cone-106> ffmpeg.git 03Michael Niedermayer 07master:a4f27a3f579b: avcodec/brenderpix: propagate error codes [22:52] <cone-106> ffmpeg.git 03Michael Niedermayer 07master:72bff8da479a: avcodec: Make ff_print_debug_info2() independant of Picture struct [23:40] <cone-106> ffmpeg.git 03Timothy Gu 07master:cb11b9e89e15: dnxhdenc: make get_pixel_8x4_sym accept ptrdiff_t as stride [23:40] <cone-106> ffmpeg.git 03Timothy Gu 07master:9d34dce05ba7: x86: convert DNxHDenc inline asm to yasm [23:43] <wm4> ubitux: what the hell is with this AVBPrint stuff [23:43] <wm4> ubitux: and wouldn't it be easier to use a static buffer [23:59] <ubitux> wm4: that's just like bstr [23:59] <ubitux> string helper, a lot of benefits [00:00] --- Fri Mar 28 2014