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

[burek]

[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