[Ffmpeg-devel-irc] ffmpeg-devel.log.20151012
burek
burek021 at gmail.com
Tue Oct 13 02:05:02 CEST 2015
[00:03:10 CEST] <iive> klaussfreire: other than MIPS, are there functions that should be optimised for SIMD? I mean, on x86* cpu?
[00:03:45 CEST] <cone-214> ffmpeg 03Ronald S. Bultje 07master:93866c2aa251: intmath: remove av_ctz.
[00:03:52 CEST] <klaussfreire> Probably. The hottest function the quantization functions by a huge margin the last time I profiled
[00:04:22 CEST] <klaussfreire> If those were to be optimized (as they are on MIPS) the impact would be huge.
[00:04:40 CEST] <BBB> I suppose you dont speak x86 assembly?
[00:04:43 CEST] <BBB> wanna learn?
[00:04:52 CEST] <klaussfreire> I do
[00:05:12 CEST] <klaussfreire> I'm more comfortable with intel notation, though, so working on inline assembly on gcc is painful to my eyes
[00:05:29 CEST] <BBB> most of our assembly is intel style, no?
[00:05:33 CEST] <BBB> we dont have much inline anymore
[00:05:40 CEST] <BBB> except for very old codecs/code
[00:05:52 CEST] <klaussfreire> What's done with yasm, but inline assembly is on AT&T format (gcc uses AT&T)
[00:06:07 CEST] <ubitux> since it's an encoder, shouldn't we wait a bit for the code to mature & get tested enough before adding the optim?
[00:06:18 CEST] <jamrial> we have been getting rid of all the inline assembly for a while now
[00:06:22 CEST] <BBB> ubitux: depends on how long it takes to write assembly
[00:06:32 CEST] <BBB> if it takes a few minutes and makes it 50% faster...
[00:06:35 CEST] <BBB> Id do it right now :-p
[00:06:38 CEST] <ubitux> :)
[00:06:48 CEST] <BBB> klaussfreire: ok, so, send patches ;) Ill review them if I can
[00:07:04 CEST] <BBB> ubitux: some pieces have a higher tendency to change than other pieces, also
[00:07:09 CEST] <BBB> like, sad never changes very much
[00:07:20 CEST] <BBB> so each video codec should have optimized sad, huge impact, little effort
[00:07:27 CEST] <BBB> (motion search is affected by this)
[00:07:53 CEST] <BBB> forward transforms are harder, theyre difficult, esp. for bigger sizes, and they may indeed functionally change
[00:10:26 CEST] <BBB> is j_darnley still not back?
[00:11:04 CEST] <ubitux> try /invite
[00:13:29 CEST] <cone-214> ffmpeg 03Marton Balint 07master:4ce75387cdcb: ffplay: close streams and AVFormatContext in the main thread
[00:13:30 CEST] <cone-214> ffmpeg 03Marton Balint 07master:148418a2bce3: ffplay: eliminate stream_component_close forward declaration
[00:24:59 CEST] <cone-214> ffmpeg 03Andreas Cadhalpun 07master:ec0275843d8e: avcodec: remove leftover iff_byterun1 decoder
[00:27:15 CEST] <jamrial> while 4x realtime is not too horrible, it's still considerably slower than other encoders (libmp3lame, libopus, libvorbis, fdk-aac), so it would certainly be nice to speed it up a bit
[00:50:51 CEST] <rcombs> got AES-NI decryption working
[00:53:52 CEST] <jamrial> nice
[00:56:34 CEST] <kierank> rcombs: <3
[00:56:45 CEST] <rcombs> now to add all the cpuflag stuff for it
[00:59:18 CEST] <michaelni_> klaussfreire, "./ffmpeg -i matrixbench_mpeg2.mpg -strict experimental -ab 64k -acodec aac test.aac" fails with
[00:59:28 CEST] <michaelni_> Assertion sfdiff >= 0 && sfdiff <= 2*60 failed at ./libavcodec/aaccoder_twoloop.h:402
[01:00:09 CEST] <michaelni_> klaussfreire, this will need --assert-level=2 or 1
[01:00:24 CEST] <michaelni_> to fail
[01:02:58 CEST] <michaelni_> also atomnuker, ^ (dunno which commit broke this, didnt bisect)
[01:03:52 CEST] <klaussfreire> michaelni: I'll take a look
[01:03:58 CEST] <rcombs> also checkasm
[01:08:05 CEST] <cone-214> ffmpeg 03James Almer 07master:e8903fbf8ecf: x86/vf_w3fdif: simplify w3fdif_simple_high
[01:08:06 CEST] <cone-214> ffmpeg 03James Almer 07master:224a529b449f: x86/vf_w3fdif: use aligned loads in w3fdif_simple_high
[01:08:41 CEST] <michaelni_> klaussfreire, atomnuker failure caused by 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec
[01:09:54 CEST] <klaussfreire> Probably because that one introduced the assert
[01:10:06 CEST] <michaelni_> ahh, that makes sense
[01:10:41 CEST] <michaelni_> also the code needs to be optimized, the new code is really slow
[01:12:04 CEST] <klaussfreire> Can you send over the mpg? The one in fate samples has no audio track
[01:12:50 CEST] <klaussfreire> Yes, I know about the slowness, will work on it later
[01:13:56 CEST] <michaelni_> klaussfreire, should be this: https://samples.ffmpeg.org/benchmark/testsuite1/matrixbench_mpeg2.mpg
[01:29:11 CEST] <iive> michaelni_: BBB already offered to help with SIMD speedup.
[01:36:42 CEST] <BBB> iive: klaussfreire said he knows simd, so he can do it himself
[01:36:50 CEST] <BBB> Ill help review patches or whatever
[01:37:35 CEST] <iive> <BBB> if it takes a few minutes and makes it 50% faster...
[01:37:35 CEST] <iive> <BBB> Id do it right now :-p
[01:38:00 CEST] <BBB> but the if condition is not satisfied
[01:38:10 CEST] <iive> anyway, this shouldn't be reason to delay the patch further.
[01:38:21 CEST] <BBB> which patch? its already in
[01:38:35 CEST] <iive> is it committed?
[01:38:36 CEST] <klaussfreire> I'd wait. There's probably algorithm optimizations that could be applied first
[01:39:06 CEST] <BBB> iive: klaussfreires patch is in, atomnukers work on top of that not yet, ask him when itll be ready
[01:40:15 CEST] <iive> that is the patch from the aac thread, isn't it?
[01:40:31 CEST] <klaussfreire> BBB: Well, actually, if want and you can optimize quantize_band_cost functions we can do both at the same time. You with the SIMD and me with the algorithm parts.
[01:41:18 CEST] <iive> klaussfreire: is the quantization function already separated as DSP one? If there is MIPS optimization I would think it is.
[01:41:54 CEST] <BBB> klaussfreire: if only I had nothing else to do ;)
[01:41:59 CEST] <BBB> klaussfreire: Ill see what I can do
[01:42:02 CEST] Action: iive looks for quantize_band_cost
[01:42:12 CEST] <klaussfreire> Yes and no. As in, yes, but it's inlined (by the compiler) in the search_for_quantizers function. You'd have to do what mips does: replace the search_for_quantizers function with one that is linked to an optimized version
[01:42:14 CEST] <BBB> cost functions tend to be harder to optimize
[01:54:14 CEST] <BBB> yeah, so the cost part is always hard to optimize
[01:54:24 CEST] <BBB> I can certainly try some micr-optimizations, but it wont have simd-like effects
[01:54:38 CEST] <BBB> quantize_band itself is probably easy to optimize (havent checked what it does exactly)
[02:14:07 CEST] <cone-214> ffmpeg 03Rostislav Pehlivanov 07master:5f760da6b600: aacenc_utils: add 'inline' flag to find_form_factor, silence warning
[02:22:38 CEST] <iive> n8 ppl
[02:30:25 CEST] <atomnuker> damn, the twoloop coder is now over 600 continous lines
[02:39:18 CEST] <rcombs> having a nice game of "OK, how did 14860616832 get in that register"
[02:44:24 CEST] <cone-214> ffmpeg 03Rostislav Pehlivanov 07master:d25c033ddd73: aaccoder_twoloop.h: simplify and comment ff_pns_bits()
[03:01:00 CEST] <cone-214> ffmpeg 03Michael Niedermayer 07release/2.8:9579550b2b86: avcodec/h264_mp4toannexb_bsf: Use av_freep() to free spspps_buf
[03:01:01 CEST] <cone-214> ffmpeg 03uઠ07release/2.8:02d8abf0f576: h264_mp4toannexb: fix pps offfset fault when there are more than one sps in avcc
[03:01:02 CEST] <cone-214> ffmpeg 03Michael Niedermayer 07release/2.8:c149a4afeef5: avcodec/pngdec: Check blend_op.
[03:07:37 CEST] <rcombs> aes_crypt_c: 785.9
[03:07:37 CEST] <rcombs> aes_crypt_aesni: 23.3
[03:07:37 CEST] <rcombs> aes_crypt_avx: 23.6
[03:10:19 CEST] <rcombs> \o/
[03:11:54 CEST] <jamrial> avx?
[03:12:09 CEST] <rcombs> VEX-prefixed AESNI
[03:12:17 CEST] <jamrial> ah
[03:13:03 CEST] <jamrial> doesn't look like you gained anything with it, though
[03:13:10 CEST] <rcombs> yeah
[03:13:20 CEST] <jamrial> awesome numbers nonetheless :p
[03:13:45 CEST] <rcombs> but there are some oddities around switching between VEX- and non-VEX-prefixed SIMD instructions
[03:13:50 CEST] <rcombs> that can end up slowing things down
[03:15:03 CEST] <rcombs> next up: support encryption as well as decryption (and add tests for that); AESNI-ize the key expansion as well
[03:16:12 CEST] <rcombs> and then split this giant diff into some reasonably-sized patches
[03:16:27 CEST] <rcombs> (most of it is adding AESNI as a cpuflag all over the place)
[03:17:24 CEST] <rcombs> also I should probably do something or other in crypto_bench
[03:18:13 CEST] <rcombs> and I can probably unroll a bit and get those numbers down a little further
[03:18:43 CEST] <rcombs> also, I'd expect this also gets a boost when running on multiple blocks
[03:18:54 CEST] <rcombs> (and there are actually 0 tests for that case right now)
[03:29:29 CEST] <jamrial> why do you need to touch crypto_bench? isn't the choice between aes-ni or normal c code done in av_aes_init()?
[03:39:31 CEST] <rcombs> jamrial: seems like it'd be useful to bench the implementations against each other?
[03:39:41 CEST] <rcombs> you can do that in checkasm too, but not against the other libs
[03:45:06 CEST] <jamrial> ah. yeah, i guess
[03:49:21 CEST] <TheRyuu> 03:13 < rcombs> that can end up slowing things down <---except on AMD where there is no penalty for mixing them (IIRC)
[03:49:38 CEST] <rcombs> I don't recall the details
[03:52:29 CEST] <TheRyuu> it was because of the register file states on Intel processors, AMD's don't have them
[03:55:50 CEST] <TheRyuu> but in general it was a bad idea to mix them because of the (large) pentaly on Intel processors
[04:01:11 CEST] <cone-214> ffmpeg 03Claudio Freire 07master:07b3b779a9f7: AAC encoder: fix assertion error re SF differences
[04:17:57 CEST] <atomnuker> question: does any preprocessor not support stringification (e.g. MACRO(whatever) -> define MACRO(name) -> printf("%s\n", #name))?
[04:19:22 CEST] <atomnuker> MSVC seems to support it
[04:25:51 CEST] <jamrial> are you thinking about AV_STRINGIFY?
[04:26:23 CEST] <jamrial> check libavutil/macros.h
[04:27:06 CEST] <rcombs> encryption done
[04:27:09 CEST] <rcombs> lavu AES-128 size: 1048576 runs: 1024 time: 0.890 +- 0.119
[04:27:09 CEST] <rcombs> gcrypt AES-128 size: 1048576 runs: 1024 time: 1.202 +- 0.219
[04:33:18 CEST] <jamrial> nice
[04:34:49 CEST] <rcombs> crypto AES-128 size: 1048576 runs: 1024 time: 12.768 +- 1.227
[04:34:57 CEST] <rcombs> I don't know what OpenSSL's doing but it's not fast
[04:35:13 CEST] <rcombs> though maybe it's OSX's shipping OpenSSL being really old
[04:38:03 CEST] <jamrial> how does it compare to libavutil without aesni?
[04:39:15 CEST] <rcombs> aes_crypt_c: 785.9; aes_crypt_aesni: 23.3
[04:39:30 CEST] <rcombs> haven't tried it in crypto_bench yet
[04:40:00 CEST] <jamrial> yeah, i meant crypto_bench numbers of openssl vs libavutil withou aesni
[04:40:13 CEST] <rcombs> ah
[04:41:17 CEST] Action: rcombs checks
[04:42:32 CEST] <rcombs> lavu AES-128 size: 1048576 runs: 1024 time: 43.428 +- 4.912
[04:42:32 CEST] <rcombs> crypto AES-128 size: 1048576 runs: 1024 time: 13.781 +- 3.598
[04:42:32 CEST] <rcombs> gcrypt AES-128 size: 1048576 runs: 1024 time: 1.339 +- 0.331
[04:42:37 CEST] <rcombs> (that's without AESNI)
[04:42:49 CEST] <jamrial> so our c version is abysmal :p
[04:43:08 CEST] <rcombs> heh
[04:43:32 CEST] <rcombs> gcrypt is obviously a slightly less efficient aesni implementation
[04:43:36 CEST] <jamrial> gcrypt is obviosuly using aesni, but openssl isn't and is four times faster than ours
[04:43:50 CEST] <rcombs> and libcrypto probably has some sort of ASM but not aesni
[04:45:29 CEST] <jamrial> could be
[04:55:39 CEST] <rcombs> aes_decrypt_c: 1027.3 aes_decrypt_aesni: 22.2 aes_decrypt_avx: 22.6
[04:55:39 CEST] <rcombs> aes_encrypt_c: 1797.2 aes_encrypt_aesni: 54.2 aes_encrypt_avx: 54.4
[04:58:51 CEST] <rcombs> hmm, not sure why encrypt is so much slower
[05:01:02 CEST] <rcombs> ah, heh
[05:01:15 CEST] <rcombs> it's because my encrypt test used an iv, but the decrypt one didn't
[05:20:30 CEST] <rcombs> alright, initial patches sent
[05:38:00 CEST] <rcombs> jamrial: what's wrong with DECLARE_ALIGNED there?
[05:39:03 CEST] <cone-214> ffmpeg 03Michael Niedermayer 07master:ce0834bdd6e6: avformat/flvdec: set broken_sizes for "metadatacreator : MEGA"
[05:41:21 CEST] <jamrial> it fails with some compilers
[05:42:13 CEST] <rcombs> :\
[06:04:35 CEST] <Timothy__Gu> rcombs: https://github.com/openssl/openssl/tree/master/crypto/aes/asm
[06:05:08 CEST] <rcombs> that doesn't look like fun
[06:05:14 CEST] <Timothy__Gu> nope
[06:09:43 CEST] <rcombs> could be worth looking into improving sha performance with this as well, but I'm sure as hell not wading through all that perl
[06:12:29 CEST] <rcombs> "Also change the CPUFLAG_AVX define to include this new one instead of CPUFLAG_SSE42" <-- jamrial: AVX doesn't require AESNI, does it?
[06:15:02 CEST] <jamrial> it doesn't require it, but the presence of avx implies the presence of aesni
[06:15:52 CEST] <rcombs> on all real CPUs?
[06:15:55 CEST] <jamrial> yeah
[06:16:00 CEST] <jamrial> https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
[06:16:40 CEST] <jamrial> aesni implies sse4.2, avx implies aesni, etc
[06:20:03 CEST] <rcombs> bit weird that the ia32 developer manual explicitly mentions "both AVX and AES flags"
[06:20:19 CEST] <rcombs> instead of just saying AVX
[06:20:36 CEST] <rcombs> (for VEX-encoded AESNI)
[07:37:30 CEST] <rcombs> I got it down farther
[07:37:32 CEST] <rcombs> lavu AES-128 size: 1048576 runs: 1024 time: 0.568 +- 0.062
[07:37:32 CEST] <rcombs> gcrypt AES-128 size: 1048576 runs: 1024 time: 1.126 +- 0.108
[07:38:20 CEST] <rcombs> aes_decrypt_c: 717.9 aes_encrypt_c: 742.8
[07:38:20 CEST] <rcombs> aes_decrypt_aesni: 20.8 aes_encrypt_aesni: 19.3
[07:46:54 CEST] <rcombs> lavu AES-128 size: 1048576 runs: 1024 time: 0.593 +- 0.106
[07:46:54 CEST] <rcombs> lavu_c AES-128 size: 1048576 runs: 1024 time: 42.427 +- 2.384
[07:55:57 CEST] <Timothy__Gu> https://github.com/bnagy/cgasm looks pretty cool
[08:29:35 CEST] <Gramner> rcombs: AVX does not imply AES-NI on real cpu:s. see http://ark.intel.com/products/53428/Intel-Core-i3-2130-Processor-3M-Cache-3_40-GHz for example, compared to http://ark.intel.com/products/68332/Intel-Core-i3-2115C-Processor-%283MB-Cache-2_00-GHz%29
[08:29:51 CEST] Action: rcombs looks at jamrial
[08:29:52 CEST] <Gramner> it's disabled on some cpus for who knows what reason
[08:31:17 CEST] <jamrial> well, that sucks
[08:32:08 CEST] <jamrial> can at least be safely assumed that aesni implies sse4.2 on all available cpus?
[08:32:13 CEST] <Gramner> so you should probably put the cpuflag (in x86inc at least) at the bottom together with the other weird/random stuff
[08:33:11 CEST] <Gramner> sse4.2 seems to be implied, no guarantees though
[08:34:16 CEST] <jamrial> do you suggest having aesni pull sse4.2 on x86inc.asm and cpu.c then? or have it standalone?
[08:35:27 CEST] <rcombs> I rely on at least SSE2 in this code, and that's obviously a safe assumption
[08:35:33 CEST] <jamrial> true
[08:37:06 CEST] <Gramner> I'd have to look into the various µarchs that has aes-ni first to say for sure, but I'd go with 4.2 implied for now
[08:37:27 CEST] <rcombs> OK, going with that then
[08:40:00 CEST] <rcombs> jamrial: poke me when you don't have any more comments
[08:41:09 CEST] <jamrial> i don't for now
[08:41:17 CEST] <rcombs> alright
[08:41:21 CEST] Action: rcombs rebases+resends
[08:42:05 CEST] <jamrial> just the first patch (and maybe sixth if you want). no need to send the whole set again :p
[08:42:43 CEST] <rcombs> that's more work :P
[08:42:44 CEST] <rcombs> but OK
[08:57:58 CEST] <cone-243> ffmpeg 03Claudio Freire 07master:b629c67ddfce: AAC encoder: memoize quantize_band_cost
[09:01:54 CEST] <Gramner> rcombs: you could also subtract 0x60 from r5 at the start (and adjust the code that follows), that way you reduce code size a little bit since you can use offsets from 0x60 to -0x60 instead of 0x00 to -0xC0. offsets that fit into one signed byte (-0x80 to 0x7F) only takes one byte instead of 4 to encode
[09:02:07 CEST] <rcombs> oh, interesting
[09:02:32 CEST] <Gramner> also are you supposed to use CRYPT xm0, [r0 + r5 - 0x10] with the -0x10 offset twice?
[09:03:53 CEST] <rcombs> oh whoops
[09:04:07 CEST] <rcombs> I haven't tested the 192 or 256-bit routes yet
[09:04:40 CEST] <Gramner> ah, you should fix checkasm to test all of that
[09:04:46 CEST] <rcombs> yeah, I should
[09:04:50 CEST] <rcombs> also, crypto_bench
[09:04:54 CEST] <rcombs> also, aes-test
[09:05:25 CEST] <rcombs> Gramner: so, I need to use at one 0x70
[09:05:53 CEST] <rcombs> oh wait, no I don't
[09:06:01 CEST] <rcombs> since the offset is fixed for the last 2 CRYPTs
[09:06:29 CEST] <rcombs> so I can just do `[r0 + 0x20]` and `[r0 + 0x10]`
[09:07:04 CEST] <rcombs> &and 0x70 fits in a signed byte anyway
[09:07:10 CEST] <rcombs> I'm a derp
[09:09:06 CEST] <jamrial> you could define the AVAES struct in the asm file and use named struct members as offset
[09:10:01 CEST] <rcombs> jamrial: the only offset I'm using now is 0
[09:10:41 CEST] <rcombs> well, and the array indexes within that 0
[09:10:56 CEST] <rcombs> but no other struct members
[09:11:06 CEST] <jamrial> ok
[09:11:28 CEST] <rcombs> so that would get me out of passing the rounds as an arg but eh
[09:12:29 CEST] <rcombs> I suppose he had no further input, then
[09:39:51 CEST] <rcombs> oh boy, found bugs the existing tests don't catch
[09:41:04 CEST] <JEEB> nice stuff :)
[09:41:14 CEST] <JEEB> also <3 for the AES instruction stuff
[09:41:26 CEST] <wm4> but the NSA!
[09:43:12 CEST] <ubitux> you will soon be able to use av_aes_crypt to discuss with them
[09:43:41 CEST] <JEEB> :D
[09:52:08 CEST] <rcombs> you can already do that
[09:52:14 CEST] <rcombs> you'll just be able to do it faster
[09:55:18 CEST] <rcombs> OK, resent patches with fixed 192 and 256-bit key support; tomorrow I'll probably do something about crypto_bench and look into key expansion
[09:55:18 CEST] <ubitux> rcombs: no, it's going to use special blackboxed backdoor instructions from now on
[09:55:36 CEST] <rcombs> uh
[09:55:43 CEST] <ubitux> what was the fuss all about "recently"?
[09:55:45 CEST] <rcombs> I'm not sure how you'd backdoor an instruction
[09:55:49 CEST] <ubitux> special random instruction in intel?
[09:56:00 CEST] <rcombs> well a rng maybe
[09:56:18 CEST] <rcombs> but this has testable and deterministic output
[09:56:31 CEST] <rcombs> I suppose it could store your plaintext in cache space or something
[09:56:37 CEST] <rcombs> but how's the NSA going to extricate that
[09:57:41 CEST] Action: rcombs shrugs; sleeps
[09:58:11 CEST] <ubitux> :)
[09:58:23 CEST] <ubitux> anyway, good work; i'm curious how it compare to a recent openssl
[10:09:53 CEST] <Gramner> RDRAND is allegedly backdoored by NSA, that's why people don't trust it
[10:10:21 CEST] <Gramner> it's also kind of hard to audit a hardware PRNG
[10:11:17 CEST] <Gramner> I don't think intel will give you all the schematics for it, and even if they do you can't really prove that it's what's actually used
[10:11:19 CEST] <nevcairiel> that seems like one of those internet rumors you can never disprove anyway and ruins a perfectly fine instruction
[10:13:31 CEST] <Gramner> iirc some snowden leaks indicated that some hardware were compromised, but it didn't state which ones
[10:16:18 CEST] <wm4> even if the hw rng is compromised, shouldn't it not matter if you put it through a proper software rng with some other entropy?
[10:16:45 CEST] <Gramner> there's also RDSEED which is supposed to be a real RNG using thermal noise instead of just a PRNG
[10:19:23 CEST] <Gramner> wm4: yes, but then it's faster and easier to not use it at all since it doesn't increase entropy
[10:19:56 CEST] <Gramner> and if it do allow it to increase entropy then you can be compromised
[10:20:00 CEST] <Gramner> that's my understanding of it
[10:24:43 CEST] <durandal_1707> Why is abi now broken with libav?
[10:26:06 CEST] <wm4> is it?
[10:28:13 CEST] <durandal_1707> yes see iff codec id change
[10:31:04 CEST] <wm4> well it's not like anyone is truly serious about this grotesque nonsense
[10:31:14 CEST] <wm4> but trying to remove it gets you flamed anyway
[10:31:34 CEST] <nevcairiel> other ABI breaking changes were pushed weeks ago already
[10:32:52 CEST] <nevcairiel> ie. http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=655b6dcb34b25d591e15ede17673ea6cb8074711
[10:34:11 CEST] <wm4> so why are there still traces of AV_HAVE_INCOMPATIBLE_LIBAV_ABI left
[10:34:20 CEST] <nevcairiel> cause noone removed them
[10:34:49 CEST] <nevcairiel> its really not that many spots though
[10:35:11 CEST] <nevcairiel> seems to only be avcodec_find_best_pix_fmt2
[10:38:56 CEST] <Timothy__Gu> I'm surprised the two filters with opencl are faster with it enabled
[10:40:35 CEST] <wm4> Timothy__Gu: isn't that what you'd expect
[10:43:42 CEST] <Timothy__Gu> seeing how vdpau etc perform I'd expect opencl to make it slower
[10:43:52 CEST] <Timothy__Gu> denoise fps: cpu/openclcpu/openclgpu 16/45/68
[10:44:06 CEST] <Timothy__Gu> for some reason cpu and openclgpu are bit exact but openclcpu isn't
[10:44:52 CEST] <Timothy__Gu> on a haswell btw
[10:48:12 CEST] <wm4> and how does vdpau factor into this?
[10:49:22 CEST] <Timothy__Gu> well vdpau is hardware
[10:49:36 CEST] <Timothy__Gu> and doesn't memcpy make it a lot slower?
[10:50:03 CEST] <Timothy__Gu> apparently opencl is very different
[10:51:47 CEST] <wm4> opencl can in theory run on the CPU too
[10:52:03 CEST] <wm4> but if it runs on the GPU (where it'll actually have an advantage over hand-written asdm
[10:52:19 CEST] <wm4> ...over hand-written asm I guess), then it'll have to copy back too
[10:53:07 CEST] <wm4> anyway, due to the way vdpau works, it forces conversion to RGBA when filtering
[10:54:46 CEST] <iive> in theory on PCIE memcpy from/to video shouldn't be that slow. It is usually a problem where the video card uses 2D tiling (aka 16x16 MB ) and does the conversion in software.
[10:55:39 CEST] <Timothy__Gu> heh
[11:03:10 CEST] <wm4> nevcairiel: so, if you say that color range/space change should not trigger a reinit of any kind, isn't my original patch fine, and actually avoids reinit in these cases?
[11:03:28 CEST] <nevcairiel> i guess so
[11:03:49 CEST] <wm4> michaelni_: what's your opinion`
[11:03:50 CEST] <wm4> ?
[11:05:06 CEST] <wm4> "(check for example the vo_vdpau.c module from MPlayer)"
[11:05:07 CEST] <wm4> lol
[11:05:11 CEST] <wm4> that's such a bad idea
[11:05:19 CEST] <wm4> because the code is all over the place there
[11:05:41 CEST] <nevcairiel> dont we have the ffmpeg_<hwaccel>.c modules as a sort of example implementation
[11:05:46 CEST] <wm4> yes
[11:05:51 CEST] <JEEB> hmm, seems like current revision only fails some AAC test?
[11:05:52 CEST] <wm4> I'll edit
[11:07:23 CEST] <wm4> also what the hell is c66x
[11:07:43 CEST] <nevcairiel> no id ea
[11:07:47 CEST] <nevcairiel> we dont have that in the codebase
[11:09:15 CEST] <wm4> it was added by a "jbrower888" 2 months ago
[11:09:39 CEST] <nevcairiel> the vo_vdpau note has been there since the page was created, so there is that
[11:13:18 CEST] <wm4> well in general this page is pretty devoid of information
[11:13:34 CEST] <JEEB> hmm, can you list a history of FATE runs for a specific machine?
[11:13:43 CEST] <wm4> if I were new to ffmpeg and wanted to implement hw decoding as an API user, I'd go all sorts of WTF
[11:13:59 CEST] <JEEB> for example I can show http://fate.ffmpeg.org/report.cgi?time=20151012082956&slot=x86_64-archlinux-gcc-threads but I'd like to see the revision history of that
[11:14:19 CEST] <nevcairiel> JEEB: click on the time column in the main overview
[11:14:56 CEST] <JEEB> ah
[11:14:57 CEST] <JEEB> thanks
[11:15:36 CEST] <bencoh> wm4: TI DSP maybe (c66x) (?)
[13:26:04 CEST] <satiender> hi , anybody can help me
[13:26:24 CEST] <satiender> I want access the camera with ffmpeg api
[13:26:31 CEST] <satiender> in my c program
[13:26:39 CEST] <satiender> please help
[13:26:41 CEST] <satiender> ??
[13:51:53 CEST] <saste> satiender, looks at libavdevice
[13:52:19 CEST] <saste> you need to use the v4l2 device
[13:52:36 CEST] <saste> it works like a demuxer, so the demuxer API example should work
[13:53:00 CEST] <satiender> saste : but that is in linux , i want to record Android phone camera
[13:53:10 CEST] <saste> satiender, also, your question belongs to #ffmpeg-user
[13:53:59 CEST] <satiender> saste : according to you anybody can help me on ffmpeg-user mailinglist
[13:54:12 CEST] <satiender> regarding that problem
[13:54:16 CEST] <satiender> :(
[13:54:45 CEST] <saste> satiender, I mean the #ffmpeg channel, this is for ffmpeg internal development
[13:55:27 CEST] <satiender> but those people said to me please ask on ffmpeg-dev
[13:57:19 CEST] <nevcairiel> then they are wrong
[13:57:39 CEST] <nevcairiel> is that why we get so many users here, someone keeps sending them?
[13:59:34 CEST] <ubitux> it seems it's only the same user recently :)
[14:02:13 CEST] <durandal_1707> kode54: are you vgmstream maintainer
[14:06:34 CEST] <martijnb> I kind of doubt someone would've sent him here
[14:06:46 CEST] <martijnb> but I'm not here 24/7 so *shrug*
[14:08:48 CEST] <wm4> isn't the problem that ffmpeg has no android media capture
[14:09:04 CEST] <nevcairiel> i'm sure you could use the JNI to build it
[14:09:08 CEST] Action: nevcairiel hides
[14:09:12 CEST] <martijnb> xD
[14:23:14 CEST] <mateo`> nevcairiel: exactly.
[14:25:57 CEST] <mateo`> anyway ..., I'm still looking at avoiding to decode a whole frame in avformat_find_stream_info/try_decode_frame just to get the codec width/height/pix_fmt
[14:27:17 CEST] <mateo`> I have a hack that sets the avctx->skip_frames to AVDISCARD_ALL and i've manages to let certain decoder only sets the relevant parameters without decoding the frame
[14:27:55 CEST] <mateo`> but it doesn't sound right as AVDISCARD_ALL does not mean that the decoder should still set the codec parameters
[14:29:59 CEST] <mateo`> any ideas on how to accomplish this ?
[14:30:39 CEST] <mateo`> adding a codec option ("only_parameters/no_decode/whatever) does not feel right either
[14:30:41 CEST] <wm4> what are you trying to do?
[14:31:58 CEST] <mateo`> actually ffmpeg decode twice images, once in avformat_find_stream_info, once when you do the actual decode
[14:32:35 CEST] <mateo`> try_decode_frame decode a frame and throw it away
[14:32:44 CEST] <mateo`> in lavf/utils.c
[14:33:08 CEST] <wm4> I mean as an API user, you could possibly skip calling avformat_find_stream_info
[14:33:29 CEST] <wm4> as it is now, libavformat tries (IMHO) to get too much information, but some API users might rely on the "too much bit"
[14:34:11 CEST] <wm4> other than that, you could probably change the parsers for the codecs in question to return this information (so that lavf doesn't decode I guess), but I barely know how this works
[14:34:12 CEST] <mateo`> wm4: for images it does nothing, it set the flags to NOHEADER
[14:37:07 CEST] Action: wm4 wonders why everything still works when removing avformat_find_stream_info from his own code
[14:39:11 CEST] <wm4> aha some .ts fail showing video
[14:40:21 CEST] <wm4> the fascinating part is that this might be due to the extradata hack in utils.c that extracts SPS into extradata on the fly
[14:41:31 CEST] <mateo`> wm4: getting the information from the parsers sounds like a good plan
[14:42:07 CEST] <mateo`> but i don't think the parser will be able to set the pixel format
[14:42:28 CEST] <wm4> that really depends how much the parser parses
[14:42:37 CEST] <mateo`> the h264_parser.c already extracts the width and height for example
[14:42:52 CEST] <wm4> although setting the pixel format in libavformat is utterly nonsensical
[14:42:56 CEST] <mateo`> it might be good to do the same for jpeg and png
[14:43:02 CEST] <wm4> different decoders could return different pixfmts for the same data
[14:43:06 CEST] <mateo`> yes
[14:43:43 CEST] <wm4> e.g. the h264_parser.c duplicates the pixfmt code
[14:44:20 CEST] <wm4> (and it's not doing that very well...)
[14:56:57 CEST] <mateo`> but since we want the pixel format that will actually be choosed by the decoder ...
[14:57:37 CEST] <wm4> you can't know that without using exactly the same decoder as the user requested
[14:57:42 CEST] <wm4> everything else is not robust
[14:58:07 CEST] <wm4> IMO determining pixfmt in the demuxer is insane and will remain non-sense for all times
[15:03:13 CEST] <mateo`> wm4: is it mandatory for the pix_fmt to be known after a call to avformat_find_stream_info ?
[15:04:06 CEST] <wm4> I don't know
[15:05:53 CEST] <nevcairiel> it tries very hard to figure it out, so if it isnt set anymore, its certainly a regression
[15:06:35 CEST] <wm4> it could set it to a dummy value
[15:06:39 CEST] <wm4> as good as any other value
[15:07:41 CEST] <mateo`> if we want to have it set from the decoder, it would be good to not decode the whole picture
[15:08:13 CEST] <wm4> well there's no such thing yet as returning an AVFrame (= successful decode) and not having any data
[15:10:34 CEST] <mateo`> my hack abuses AVDISCARD, no frame are returned, but the codec parameters are set
[15:11:36 CEST] <mateo`> what do you think about a codec option which is optionally handled by the codecs so it doesn't break compatibility
[15:14:07 CEST] <wm4> sounds like a bad hack
[15:14:41 CEST] Action: ubitux discovers AV_CODEC_ID_PROBE
[15:14:46 CEST] <ubitux> you don't want to git grep it
[15:17:24 CEST] <ubitux> i see a skip_idct field in the same idea as skip_frame
[15:17:34 CEST] <ubitux> which might also be relevant for probing, in different context
[15:18:14 CEST] <ubitux> i believe it's interesting to have a way for probe to say to the codec "you do not need to decode, just fill the info"
[15:18:44 CEST] <ubitux> which could be expressed as setting skip_idct or similar no decode related flags for images
[15:21:21 CEST] <mateo`> skip_frame = AVDISCARD_ALL would be the best choice but, if you want no probing regression all codecs that honor the flags should be patched to properly set width/height/pix_fmt
[15:21:51 CEST] <mateo`> it is doable, but it sounds like a hack
[15:22:16 CEST] <ubitux> i'd suggest to add a AV_CODEC_FLAGS[2]_something
[15:22:20 CEST] <ubitux> but that's just me
[15:23:00 CEST] <ubitux> what's AV_CODEC_FLAG2_NO_OUTPUT?
[15:23:10 CEST] <ubitux> ah, encoding only
[15:24:15 CEST] <ubitux> maybe extend the meaning of that one
[15:25:13 CEST] <ubitux> but i'd go for a AV_CODEC_FLAG2_NO_DECODE
[15:28:40 CEST] <wm4> <ubitux> i believe it's interesting to have a way for probe to say to the codec "you do not need to decode, just fill the info" <- me too
[15:28:48 CEST] <wm4> it'd be useful for frame dropping (for perf)
[15:29:14 CEST] <ubitux> you can already use -skip_frame all
[15:29:17 CEST] <ubitux> :p
[15:29:35 CEST] <ubitux> but current discard politic doesn't mean "fill the info"
[15:30:08 CEST] <ubitux> all the decoders could be fixed to do that
[15:30:20 CEST] <ubitux> but they're not exactly trivial to fix
[15:30:30 CEST] <ubitux> and there is a risk of regression in doing so
[15:31:26 CEST] <wm4> I know you can drop frames
[15:31:37 CEST] <wm4> but the thing is, you don't know when it dropped a frame
[15:32:04 CEST] <wm4> it's indistinguishable from other reasons the decoder doesn't return a frame
[15:33:28 CEST] <BBB> mateo`: I think a flag for this is a great idea (Im assuming you want to find w/h/fmt from sps/pps/etc. or from vp9 kf header?)
[15:33:39 CEST] <mateo`> BBB: yes
[15:34:15 CEST] <BBB> it may fit AVDISCARD_ALL already
[15:34:17 CEST] <BBB> Id go for it
[15:34:34 CEST] <BBB> because in order to know what frame to discard, we have to know the frame type (which means header parsing)
[15:35:12 CEST] <mateo`> i've already a patch with AVDISCARD_ALL and mjpeg/png decoders patched, but i got some h264 probing regression in fate
[15:35:27 CEST] <BBB> h264 wants more info
[15:35:33 CEST] <BBB> like whether we have b frames
[15:35:35 CEST] <BBB> bpp
[15:35:38 CEST] <mateo`> i wanted to discuss it before continuing fixing all the codecs that honors the AVDISCARD flag
[15:35:41 CEST] <BBB> some other things that I probably forgot
[15:35:43 CEST] <BBB> timestamp related stuff
[15:35:57 CEST] <BBB> michaelni_: ^^
[15:36:05 CEST] <ubitux> so should the avdiscard politic adjusted in h264 & friends, or should we add another flag?
[15:36:23 CEST] <BBB> Im ok with avdiscard_all being used for this purpose
[15:36:27 CEST] <BBB> but other flag is fine also
[15:36:42 CEST] <nevcairiel> discard for h264 is already quite complex, making it more so seems like a bad idea to me
[15:36:44 CEST] <ubitux> will it be fast to probe these info in h264?
[15:37:24 CEST] <BBB> yes
[15:37:27 CEST] <BBB> its sps/pps stuff only
[15:37:41 CEST] <BBB> and slice header obviously
[15:37:45 CEST] <BBB> (to get the sps/pps id)
[15:38:07 CEST] <nevcairiel> to fully probe the same h264 info as today, you still need to handle a bunch of the other stuff, like, it probes the size of the re-ordering buffer etc
[15:44:32 CEST] <BBB> right, but thats all in the headers
[15:47:41 CEST] <mateo`> the parser should be able to get that
[16:34:39 CEST] <saste> anybody tested qsv encoding/decoding with ffmpeg and has benchmarks?
[16:38:36 CEST] <Daemon404> omg aac patches
[16:38:51 CEST] <Daemon404> saste, i dont know about ffmpeg, but libav has iirc
[16:39:18 CEST] <nevcairiel> its kind of on my list, for encoding at least, as $work wants to use it
[16:43:31 CEST] <saste> also, from my understand it relies on the mfx_dispatcher by lu_zero, since the intel media library doesn't support any pkgconfig file as is
[16:43:32 CEST] <cone-163> ffmpeg 03Rostislav Pehlivanov 07master:e679a1e65f52: aacenc_quantization: fix header description
[16:43:54 CEST] <Daemon404> saste, i think he has other fixes in it
[16:44:05 CEST] <Daemon404> but the whole situation is pretty stinky, i think.
[16:44:20 CEST] <Daemon404> the fact that mfx_dispatcher has to be a thing is pretty meh
[16:45:15 CEST] <nevcairiel> meh, its not that different to libva or what have you, some headers and a glorified binary loader for a driver implementation
[16:45:30 CEST] <Daemon404> i didnt say libva wasnt meh too ;p
[16:56:25 CEST] <cone-163> ffmpeg 03Rostislav Pehlivanov 07master:b3deaece87b5: aacenc: add support for encoding 7.1 channel audio
[16:57:08 CEST] <rcombs> oh good
[16:57:55 CEST] <rcombs> pretty close to what I had a while back
[16:59:07 CEST] <cone-163> ffmpeg 03Bela Bodecs 07master:1f3a29e999b6: lavf/tee: allow multiple stream specifiers in select.
[16:59:08 CEST] <cone-163> ffmpeg 03Alex Agranovsky 07master:cf28490e564d: avfilter/drawtext: allow to format pts with strftime
[16:59:53 CEST] <nevcairiel> why does 8 channels get written as 7 in the audio config
[16:59:55 CEST] <nevcairiel> weird aac is weird
[16:59:59 CEST] <Daemon404> wut
[17:00:08 CEST] <Daemon404> does 5.1 get written as 5 too?
[17:00:11 CEST] <nevcairiel> no
[17:00:13 CEST] <nevcairiel> only 8
[17:00:20 CEST] <nevcairiel> probably because the field is 4 bits in size
[17:00:36 CEST] <nevcairiel> hm but that would fit 8
[17:00:53 CEST] <nevcairiel> who knows
[17:01:34 CEST] <nevcairiel> there probably is some convoluted reason why they decided to do that
[17:01:49 CEST] <Daemon404> olol
[17:02:00 CEST] <Daemon404> some special snowflake channel mapping stuff maybe
[17:02:12 CEST] <nevcairiel> let me check my spec!
[17:02:42 CEST] <atomnuker> pretty sure it's because no one has exactly 7 channel audio system
[17:02:50 CEST] <nevcairiel> 6.1 isnt that arcane
[17:02:59 CEST] <Daemon404> i have 6.1 samples
[17:03:01 CEST] <Daemon404> EVA used 6.1
[17:03:02 CEST] <atomnuker> oh, that
[17:03:17 CEST] <atomnuker> yeah, coalgirls' rips used that
[17:03:31 CEST] <atomnuker> pulseaudio still can't mix it correctly :|
[17:03:35 CEST] <Daemon404> coalgirls' rips are incorrect iirc
[17:03:41 CEST] <Daemon404> since they used flac with no channel mask
[17:03:46 CEST] <Daemon404> and 6.1 is not defined as a mappign in flac
[17:03:48 CEST] <Daemon404> without a mask
[17:03:56 CEST] <nevcairiel> to be honest 6.1 can be a bitch
[17:04:03 CEST] <nevcairiel> because there is two common channel orders
[17:04:11 CEST] <Daemon404> http://mod16.org/hurfdurf/?p=184
[17:04:18 CEST] <Daemon404> i remember this post from the time
[17:04:21 CEST] <nevcairiel> (and recent flac specs added 6.1 and 7.1)
[17:04:31 CEST] <Daemon404> yeah
[17:04:34 CEST] <Daemon404> not in 2011
[17:05:07 CEST] <atomnuker> at least they dropped it (or were the BDs changed) for 3.33
[17:05:15 CEST] <RiCON> 3.33 only had 5.1
[17:06:37 CEST] <rcombs> michaelni_: your command crashes because crypto.c calls av_aes_crypt with count=0
[17:07:04 CEST] <michaelni_> it didnt crash before
[17:07:17 CEST] <rcombs> yeah, it's an easy fix
[17:07:33 CEST] <rcombs> I'm just adding a check in the C wrapper
[17:07:46 CEST] <rcombs> but it's a silly case and I think the consumer should be less dumb about it
[17:12:33 CEST] <michaelni_> yes but its public API/ABI so ensuring all consumers dont do that is not within our power
[17:12:50 CEST] <rcombs> yeah, thus the check
[17:21:51 CEST] <wm4> michaelni_: ping on the h264 get_format issue? nevcairiel says color_range changes shouldn't trigger a reinit at all
[17:27:05 CEST] <nevcairiel> interesting, Microsoft actually released a specification for vp8/9 dxva
[17:27:07 CEST] Action: nevcairiel reads
[17:27:28 CEST] <BBB> microsoft, vp8
[17:27:29 CEST] <BBB> ...
[17:27:43 CEST] <BBB> Im wondering why
[17:28:04 CEST] <nevcairiel> because they are adopting vp8 and 9 in their new browser, so adding official hw accel is good for them
[17:28:17 CEST] <BBB> oh theyre adopting both? I thought it was just vp9
[17:28:20 CEST] <nevcairiel> http://www.microsoft.com/en-us/download/details.aspx?id=49188 if anyone else wants to have a look
[17:28:22 CEST] <BBB> thats nice
[17:28:24 CEST] <j-b> lobbying works \o/
[17:28:35 CEST] <j-b> BBB: only 200 email on that thread :)
[17:28:43 CEST] <BBB> what thread?
[17:28:45 CEST] <michaelni_> wm4, if you and nevcairiel agree on a solution for this then iam fine with it too
[17:28:49 CEST] <BBB> and wehres your email?
[17:30:11 CEST] <nevcairiel> my nvidia card only offers the vp9 profile though, wonder if the intel gpu would offer vp8 as well
[17:30:51 CEST] <fritsch> nevcairiel: afaik it does vp8 on linux with this external "gpu assisted driver"
[17:30:59 CEST] <fritsch> nevcairiel: but for vp9 you need > hsw
[17:31:12 CEST] <nevcairiel> i'm never plagued with old hardware
[17:31:43 CEST] <fritsch> hehe
[17:31:54 CEST] <wm4> awesome, it's like the hevc patent shitmess gave vp9 a prod
[17:31:56 CEST] <fritsch> BtbN: <- afaik works on that, too
[17:32:16 CEST] <nevcairiel> i doubt he works on dxva
[17:32:17 CEST] <fritsch> though iirc a lot of infrastructure work for ffmpeg needs to be done
[17:32:20 CEST] <rcombs> wm4: now maybe someone will actually work on the encoder
[17:32:21 CEST] <fritsch> VP9 + vaapi
[17:32:28 CEST] <BtbN> In theory, yes. But I don't exactly have a lot of time at the moment.
[17:32:35 CEST] <nevcairiel> the infrastructure for new codecs is pretty little
[17:32:42 CEST] <nevcairiel> actually implementing the codecs is the hard work
[17:32:54 CEST] <nevcairiel> adding the hooks to hevc took me maybe an hour back then
[17:33:06 CEST] <BtbN> The hwaccel hooks in vp8/9 could get a bit messy, as it might need quite a bit of refactoring.
[17:33:24 CEST] <nevcairiel> i'll just blame BBB for a bad decoder
[17:33:30 CEST] <Daemon404> nevcairiel, i thought it was 9 only
[17:33:34 CEST] <Daemon404> they announce vp8?
[17:33:41 CEST] <rcombs> that reminds me
[17:33:42 CEST] <nevcairiel> "DirectX Video Acceleration Specification for VP8 and VP9 video decoding"
[17:33:46 CEST] <nevcairiel> you tlel me
[17:33:47 CEST] <BtbN> philipl made some work on it, but it's not complete.
[17:33:54 CEST] <wm4> I thought the decoder was pure awesomeness
[17:33:59 CEST] <rcombs> I could probably implement hardware scaling and deinterlacing using qsv
[17:34:07 CEST] <rcombs> (postproc)
[17:34:09 CEST] <fritsch> wm4: i think nevcairiel comment on that was ironic
[17:34:12 CEST] <BBB> wm4: Ive never done any hardware work, so I dont know if its awesome for hardware integration
[17:34:19 CEST] <wm4> oh ok
[17:34:27 CEST] <rcombs> but I likely won't because it's a licensing mess on Linux so I'll need it in VAAPI instead
[17:34:38 CEST] <nevcairiel> all it really needs is easy access to the raw bitstream after header parsing
[17:34:39 CEST] <BBB> wm4: you probably want to do hader parsing in sfotware and then give the block data to the hw and call a function/callback
[17:34:51 CEST] <BBB> nevcairiel: should be easy, I mean, the data pointers are right there
[17:34:52 CEST] <wm4> BBB: similar to h264 I imagine
[17:34:54 CEST] <BBB> wm4: yeah
[17:35:16 CEST] <BBB> nevcairiel: but why dont you try and see if it really _is_ easy :-p
[17:35:45 CEST] <nevcairiel> i will
[17:35:54 CEST] <fritsch> for the vaapi task, one can probably have a look on how intel does it with libyami - after the hooks are in
[17:36:00 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/0d50fb0737f35aad3c0aff56626cba69d1b07bc3
[17:36:07 CEST] <BtbN> That's the patch for most of the hooks
[17:36:09 CEST] <BBB> signed/unsigned has performance penalties?
[17:36:11 CEST] <BBB> thats new to me
[17:36:28 CEST] <BBB> Generally signed/unsigned conversions have some unforeseen performance penalties.
[17:36:31 CEST] <BtbN> only thing that seems to be still missing is the pix_fmt stuff to announce which hwaccels are supported. And there is no obvious point to to that.
[17:37:28 CEST] <rcombs> fritsch: hmm
[17:37:36 CEST] <fritsch> there was a recent discussion on the microsoft support forums that "with newer intel drivers" youtube would stutter ... later it was revelead that youtube sends VP9 on google chrome automatically now
[17:37:42 CEST] <fritsch> and the gpu assisted decoding sucks badly
[17:37:47 CEST] <fritsch> in comparison with hw h264 decoding
[17:37:48 CEST] <rcombs> fritsch: could probably add libyami support in ffmpeg then
[17:38:03 CEST] <wm4> there was a libyami patch
[17:38:03 CEST] <fritsch> rcombs: basically libyami is just another wrapper over libva
[17:38:09 CEST] <rcombs> yeah
[17:38:10 CEST] <fritsch> but it's "complete"
[17:38:16 CEST] <rcombs> like qsv
[17:38:22 CEST] <rcombs> but LGPL instead of& that mess
[17:38:25 CEST] <nevcairiel> vp9 sure has a bunch of odd-sounding parameters in the dxva picparams struct
[17:38:28 CEST] <fritsch> everything (even non released) intel hw support is in there
[17:38:32 CEST] <fritsch> including HEVC encoding
[17:38:36 CEST] <rcombs> very nice
[17:38:41 CEST] <rcombs> wm4: what month
[17:38:52 CEST] <fritsch> https://github.com/01org/libyami/commits/master <-
[17:38:57 CEST] <BtbN> It's kind of sad that instead of fixing their actual API, they release wrappers...
[17:38:57 CEST] <fritsch> latest brings VP8 to Baytrail
[17:38:58 CEST] <wm4> not sure, I only remember that I essentially rejected it
[17:39:05 CEST] <rcombs> fritsch: I'm looking at that :)
[17:39:12 CEST] <rcombs> wm4: in concept or due to implementation issues
[17:39:25 CEST] <wm4> january 2015
[17:39:32 CEST] <rcombs> heh, back a while
[17:39:36 CEST] <wm4> the implementation was... not so good
[17:39:41 CEST] <BtbN> But seeing that nobody wants to deal with libva, adding libyami encoders might be worthwhile
[17:39:53 CEST] <wm4> and conceptually, it wasn't so great either, and redundant with our hwaccel stuff
[17:40:03 CEST] <wm4> (this was for decoding only)
[17:40:22 CEST] <fritsch> it seems libyami is what intel is pushing
[17:40:25 CEST] <fritsch> that and gstreamer
[17:40:47 CEST] <j-b> libyami is a joke.
[17:40:57 CEST] <j-b> and a mess
[17:40:59 CEST] <fritsch> __gb__: <- started some vaapi ffmpeg rework lately and hopefully continues
[17:41:24 CEST] <rcombs> would it be preferable to have all that stuff within lavc/lavfi?
[17:41:44 CEST] <j-b> rcombs: what stuff?
[17:41:47 CEST] <rcombs> decoding is one thing but encoding and postprocessing are a bunch of work
[17:42:22 CEST] <wm4> postprocessing is probably not so hard
[17:42:24 CEST] <rcombs> ("one thing" meaning "redundant with the existing vaapi hwaccel as long as you're not also encoding")
[17:42:37 CEST] <BtbN> The problem with encoding in libva is that you have to generate the entire bitstream yourself...
[17:42:42 CEST] <BtbN> Which is a horrible mess
[17:42:43 CEST] <rcombs> wm4: haven't looked too closely at that but encoding with libva is not fun
[17:42:47 CEST] <rcombs> I've done it
[17:42:57 CEST] <BtbN> Rate controls is also a major pain
[17:42:59 CEST] <BtbN> -s
[17:43:01 CEST] <rcombs> (the patch isn't worth looking at)
[17:43:19 CEST] <rcombs> (just shoved the libva h264enc sample code in a lavc wrapper)
[17:43:30 CEST] <wm4> BtbN told us tales of libva encoding, yes
[17:43:33 CEST] <wm4> and how bad it is
[17:43:47 CEST] <fritsch> you just need to read the libva ML
[17:43:48 CEST] <rcombs> well I might get to work with Intel on libyami stuff
[17:43:50 CEST] <fritsch> for that :-(
[17:44:06 CEST] <BtbN> It wouldn't be that bad if it would generate the entire bitstream itself...
[17:44:16 CEST] <rcombs> if we think that would be preferable to having it all in lavc
[17:44:19 CEST] <BtbN> which is easily could, it requests all the data that's in there as parameters anyway
[17:44:26 CEST] <fritsch> rcombs: if you work with them - they don't answer me for hevc-10 bit gpu assisted decoding :-9
[17:46:23 CEST] <rcombs> would be interested to see what route __gb__'s going
[17:51:48 CEST] <nevcairiel> BBB: first glance it doesnt seem too bad, and most of the values I need seem to be in the context as well
[17:52:12 CEST] <BBB> \o/
[17:57:25 CEST] <jamrial> ubitux: there's something really wrong with your fate clients
[17:57:41 CEST] <jamrial> they keep failing random tests
[17:59:24 CEST] <cone-163> ffmpeg 03Rostislav Pehlivanov 07master:0f4334df45ee: aacenc: add support for changing options based on a profile
[18:00:06 CEST] <atomnuker> nevcairiel: now you can use -profile:a mpeg2_aac_low to disable any MPEG4 features
[18:00:37 CEST] <nevcairiel> \o/
[18:00:40 CEST] <nevcairiel> thanks
[18:06:47 CEST] <nevcairiel> BBB: apparently the only annoying part will be segmentation, it seems to use somewhat different names from what i can find in header parsing so far
[18:06:55 CEST] <TheRyuu> 10:19 < Gramner> and if it do allow it to increase entropy then you can be compromised <---how? if you xor rdrand with a software rng then it's impossible to lose entropy
[18:07:04 CEST] <BBB> nevcairiel: poke me for what youre looking for and Ill help you translate it
[18:09:32 CEST] <Gramner> TheRyuu: that's exactly what the linux kernel does (or did at least, I don't know if they changed it). the result is this: https://twitter.com/defusesec/status/408975222163795969
[18:10:51 CEST] <rcombs> wm4: one thing I'd like to do with vaapi (or libyami, whatever) and am currently not quite sure on is overlays (for subtitles)
[18:10:59 CEST] <rcombs> but I'd imagine that's doable
[18:12:09 CEST] <TheRyuu> Gramner: ah, I didn't know about that, yea the linux kernel now uses it as the IV (or whatever you call it) for the SHA transform
[18:12:10 CEST] <rcombs> Gramner: huh, how does that work?
[18:12:19 CEST] <rcombs> oh
[18:12:28 CEST] <rcombs> well that seems dumb
[18:12:30 CEST] <wm4> rcombs: good question
[18:12:53 CEST] <TheRyuu> also yea, how does that work...
[18:15:07 CEST] <wm4> maybe possible with vpp
[18:15:13 CEST] <TheRyuu> https://defuse.ca/files2/poc/pocorgtfo03.pdf
[18:15:15 CEST] <TheRyuu> section 6
[18:15:23 CEST] <TheRyuu> apparently that's the whitepaper for it
[18:16:32 CEST] <TheRyuu> I think his argument is that the output from the linux rng is in memory when rdrand is called so rdrand could theoretically read that value and return the inverse
[18:16:46 CEST] <wm4> I see no such vpp filter though
[18:16:58 CEST] <cone-163> ffmpeg 03Rostislav Pehlivanov 07master:e2749ef60a88: aacenc_utils: fit find_form_factor() below 80 chars per line
[18:16:59 CEST] <cone-163> ffmpeg 03Rostislav Pehlivanov 07master:ccd3b3df39de: fate: increase fuzz on fate-aac-tns-encode test
[18:18:03 CEST] <Gramner> xor is not a good choice for that reason, a hash functionwould be better. then you at least cannot forge a particular output just from knowing other parts of the input
[18:18:20 CEST] <rcombs> "It works by observing the stack in order to cancel out the other sources of entropy."
[18:18:44 CEST] <TheRyuu> this attack has a lot of what if's
[18:20:04 CEST] <rcombs> I mean, if they really wanted to they could have any given instruction check if it's in Linux's RNG code and screw with things
[18:20:36 CEST] <Gramner> indeedy. if an attacker has full control of your cpu then you're screwed from the start anyway. avoiding a single instructions isn't magically going to make your code tamper-proof
[18:20:45 CEST] <rcombs> yeah
[18:21:59 CEST] <Gramner> having a compromised PRNG is a lot more easy to implement and much harder to detect than such a scheme though
[18:22:55 CEST] <rcombs> not much more complicated if the compromised PRNG has to scan the stack anyway
[18:23:07 CEST] <rcombs> (but yes probably harder to detect)
[18:23:49 CEST] <rcombs> either way I'm not really concerned
[18:24:11 CEST] <rcombs> if the NSA's coming after my data there are probably easier ways they could do it
[18:25:32 CEST] <drv> what is the deal with these /*align 16*/ comments? are they actually enforced?
[18:25:35 CEST] <TheRyuu> I think that if available rdrand should be used, at least combined in some manner with another CSPRNG
[18:25:51 CEST] <drv> e.g. add_int16 in lossless_videodsp has align 16 on the pointers, but the sse2 asm checks for unaligned and handles it anyway
[18:26:13 CEST] <rcombs> it's certainly fine for all of ffmpeg's RNG uses
[18:26:36 CEST] <rcombs> except the ones that need to be deterministic
[18:26:49 CEST] <rcombs> &which is a bunch of them
[18:29:11 CEST] <TheRyuu> it drives me insane when software roll their own RNG solutions when OS provided ones are already available too you (see putty, openssl)
[18:29:55 CEST] <TheRyuu> especially when in the case of openssl I don't think it ever reseeds it unless you tell it to
[18:32:20 CEST] <Gramner> I'd say realistically RDRAND could be compromised, but only to the extent that it's an issue if you're not mixing the output with anything else. I'd be extremely surprised if it does any fancy memory snooping to tweak it's output or whatever
[18:33:49 CEST] <Gramner> so basically that the underlying algorithm could be flawed, similar to dual_ec_drbg
[18:42:23 CEST] <BBB> drv: not enforced, but expected
[18:42:39 CEST] <BBB> drv: so some x86 (sse2) or arm (neon) simd may expect pointers to be 16byte aligned and crash if theyre not
[18:43:20 CEST] <rcombs> and others will be slow!
[18:48:14 CEST] <rcombs> one nice thing about the VEX-encoded versions of XMM instructions is that they don't require alignment by default
[18:58:00 CEST] <ubitux> jamrial: http://pastie.org/pastes/10476999/text maybe related? :(
[18:58:17 CEST] <ubitux> i see this only once though
[19:05:37 CEST] <nevcairiel> BBB: re segmentation, it asks for something called feature_data[8][4] and feature_mask[8], and i'm not quite sure what these are, any hints?
[19:07:34 CEST] <nevcairiel> i should probably find the vpx sources, it seems to match to their variable names
[19:28:45 CEST] <kierank> atomnuker: do you care about aacencoder crashes at this stage?
[19:29:15 CEST] <atomnuker> yes
[19:29:21 CEST] <atomnuker> where does it happen?
[19:29:37 CEST] <kierank> I am fuzzing it on avdev
[19:30:21 CEST] <atomnuker> well, in that case not yet
[19:30:28 CEST] <atomnuker> well, kinda
[19:30:30 CEST] <atomnuker> yes
[19:30:51 CEST] <kierank> http://pastie.org/private/xlnfw9vfkn7dbxgwfaurug
[19:33:20 CEST] <atomnuker> hm, this might happen due to the caching
[19:34:03 CEST] <kierank> all of the fuzz crashes happen in the same place
[19:34:22 CEST] <kierank> which is good because there's only one crash
[19:35:07 CEST] <Daemon404> or 10 crashes which all gte caught at the same place
[19:35:46 CEST] <kierank> one crash so far i mean
[19:37:04 CEST] <kierank> nondeterministic too...
[19:37:12 CEST] <kierank> possibly based on the source
[19:46:33 CEST] <kierank> if I put the file in a different directory no crash
[19:46:35 CEST] <kierank> very bizzare
[19:47:54 CEST] <BBB> nevcairiel: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9.c;h=ed0d905a0adb433596f2f65478304ab7189f3109;hb=HEAD#l745
[19:48:25 CEST] <BBB> nevcairiel: in libvpx, these features are enum bits, q=0,lf=1,ref=2,skip=3
[19:48:28 CEST] <nevcairiel> guess i need to figure out how these features map into that one value then
[19:48:32 CEST] <BBB> nevcairiel: then, the mask is simply that bitmask
[19:48:49 CEST] <BBB> so q_enabled << 0 | lf_enabled << 1 | ref_enabled << 2 | skip_enabled << 3
[19:48:52 CEST] <BBB> with proper braces
[19:49:09 CEST] <nevcairiel> I have a more annoying task right now, you localized VP9Context in vp9.c, i need to move it to vp9.h, but its not cooperating
[19:49:11 CEST] <BBB> and the feature_data is the individual value of each of these 4
[19:49:30 CEST] <BBB> I have a more elaborate patch that may be helpful
[19:49:38 CEST] <BBB> shall I sent you what I have and see if that helps?
[19:49:52 CEST] <BBB> I tried to split it in stuff that is decoder specific and stuff that is in the header"
[19:50:00 CEST] <BBB> the decoder stuff stays in .c, the header stuff moves to .h
[19:50:02 CEST] <nevcairiel> if it makes VP9Context and VP9Frame available to things outside of vp9.c, it would help
[19:50:11 CEST] <BBB> not vp9context
[19:50:17 CEST] <BBB> do you really need vp9context?
[19:50:23 CEST] <BBB> and vp9frame, also no
[19:50:27 CEST] <nevcairiel> well i need a boatload of info thats in it
[19:50:29 CEST] <BBB> so I guess its orthogonal to what you want
[19:50:44 CEST] <nevcairiel> all the info from header parsing
[19:50:49 CEST] <BBB> dont you just need frame header stuff?
[19:50:58 CEST] <BBB> I mean you dont need things like linesize, do you?
[19:51:04 CEST] <nevcairiel> no
[19:51:33 CEST] <nevcairiel> its mostly frame header parsing yes
[19:51:34 CEST] <wm4> michaelni_, nevcairiel: sorry if I annoy you, but I git mixed signals from you: is it necessary to do a full reinit on J pixfmt changes (between the same J and non-J format), or not? what about GBRP?
[19:52:00 CEST] <nevcairiel> BBB: if you show me what you've got, i'll tell you if it was useful ;)
[19:52:41 CEST] <nevcairiel> i might need to move the context still after wards, but we'll see
[19:53:08 CEST] <BBB> ok
[19:53:17 CEST] <BBB> let me unpack this from unrelated stuff in the same patch :-p
[19:54:05 CEST] <nevcairiel> its slightly unusual that you dont have the context in a header already, guess you didnt really split vp9 decoding into several files
[20:03:24 CEST] <BBB> nevcairiel: sorry &
[20:08:32 CEST] <nevcairiel> BBB: https://github.com/Nevcairiel/FFmpeg/commit/81fd33403af7052e77edfb25607a2b6a0e8d1e68 very evil? slightly bad? you died in disgust?
[20:08:49 CEST] <BBB> I have a slightly nicer version of that
[20:08:55 CEST] <BBB> but something broke in fate, so let me debug my version
[20:09:29 CEST] <nevcairiel> there was some interdependency between vp9data, vp9dsp and vp9, so that got slightly ugly
[20:14:11 CEST] <BBB> yeah
[20:16:02 CEST] <BBB> nevcairiel: http://pastebin.com/hRWVX9vS
[20:16:33 CEST] <BBB> nevcairiel: it splits slightly less stuff out into vp9.h
[20:16:50 CEST] <BBB> Ive been using that to expose the header to applications in some test stuff I wrote
[20:17:10 CEST] <nevcairiel> definitely need access to the full AVFrames to get to the surfaces
[20:17:18 CEST] <nevcairiel> otherwise it looks somewhat promising
[20:17:25 CEST] <wm4> hm, nobody cares, so I guess I'll just hack-fix it in mpv
[20:17:30 CEST] <BBB> well your callbacks can carry frames right?
[20:17:38 CEST] <BBB> but you can also expose the frames separately I suppose
[20:17:53 CEST] <BBB> anyway, what Im trying to get to is: lets not export everything into vp9.h, its somewhat ugly
[20:18:02 CEST] <BBB> lets keep the decoder-specific bits inside, and export only pieces we really need
[20:18:06 CEST] <nevcairiel> i need all of the ref frames etc, the callbacks are generic, not vp9 specific :)
[20:18:29 CEST] <nevcairiel> the problem is
[20:18:34 CEST] <nevcairiel> all I have is AVCodecContext
[20:18:42 CEST] <nevcairiel> AVCodecContext->priv_data is VP9Context
[20:18:47 CEST] <nevcairiel> so i need to somehow start from there
[20:19:06 CEST] <Daemon404> someone want to push that init patch i sent?
[20:19:14 CEST] <Daemon404> i cant be arsed to run my vm with the right keys atm
[20:19:19 CEST] <Daemon404> :x
[20:19:37 CEST] <BBB> can you make the pieces that you need (refs/header) part of a struct that is on top of VP9Context and exported in the ehader?
[20:20:23 CEST] <nevcairiel> suppose we could use one of those ugly first-element-in-struct kinda deals
[20:20:32 CEST] <BBB> thats what I was thinking, yes
[20:20:39 CEST] <BBB> if its getting really ugly we can export everything
[20:20:51 CEST] <BBB> but Id prefer not to, since its .. well .. really mostly internal stuff that you shouldnt need
[20:20:55 CEST] <BBB> do whatever feels best :-p
[20:21:17 CEST] <BBB> if my patch still works, Id be realy happy, because then I dont need to regenerate it for my test tools
[20:21:23 CEST] <BBB> I guess we can also just try applying it upstream
[20:21:46 CEST] <nevcairiel> my work is supposed to go upstream when its done anyway, so that would be a good start
[20:22:38 CEST] <Daemon404> there are far worse ways you could do it
[20:27:08 CEST] <cone-163> ffmpeg 03Derek Buitenhuis 07master:1156b634c18f: avcodec: Don't lock on init for codecs without an init function
[20:30:41 CEST] <Daemon404> thanks jamrial
[20:30:55 CEST] <jamrial> np
[20:31:31 CEST] <Daemon404> right now im going through each codec to see if theyre threadsafe init...
[20:31:35 CEST] <Daemon404> tons of codecs not marked a s such
[20:31:37 CEST] <Daemon404> as*
[20:31:42 CEST] <nevcairiel> of course
[20:31:45 CEST] <nevcairiel> the flag is new
[20:31:55 CEST] <Daemon404> a bunch were marked at the time it was added
[20:31:58 CEST] <Daemon404> but... a random ubset
[20:32:00 CEST] <Daemon404> subset*
[20:43:43 CEST] <nevcairiel> BBB: the bitstream header struct looks fine, it contains 90% of what i need, one or two enabled flags are simply not exported by the decoder, but i can fix that .. the only really missing thing is the ref frames, I'll try to come up with something to expose that
[20:45:51 CEST] <BBB> ok cool
[20:45:59 CEST] <BBB> which enabled did I forget to export?
[20:46:06 CEST] <BBB> that sounds obscure, I should be exporting everything
[20:46:10 CEST] <BBB> (or maybe Im stupid)
[20:46:27 CEST] <nevcairiel> mode_ref_delta_update is what my spec calls it
[20:46:44 CEST] <nevcairiel> apparently a flag if something gets updated in this frame
[20:47:27 CEST] <nevcairiel> oh and the subsampling bits are missing, they are in the old header ... but i could re-create them from the pixfmt..
[20:47:30 CEST] <BBB> lf deltas
[20:47:38 CEST] <BBB> subsampling bits are in the pixfmt
[20:47:45 CEST] <BBB> I didnt feel like it made sense to double export them
[20:47:57 CEST] <BBB> I mean, you could just look at avctx->pix_fmt and get the appropriate pixdesc and get them from there
[20:47:58 CEST] <BBB> right?
[20:48:04 CEST] <nevcairiel> yeah
[20:48:10 CEST] <nevcairiel> this thing only supports 4:2:0 anyway
[20:48:19 CEST] <nevcairiel> but they like to build them future proof and add fields for this
[20:48:26 CEST] <BBB> nevcairiel: s->h.lf_delta.enabled
[20:48:29 CEST] <BBB> is what youre looking for
[20:48:40 CEST] <nevcairiel> no, thats mode_ref_delta_enabled
[20:48:54 CEST] <klaussfreire> kierank: I heard the AAC encoder is crashing on fuzzing tests? Is it built with assert-level=2 ?
[20:49:04 CEST] <BBB> oh you want the thing based on which each individual s->h.lf_delta.ref/mode gets updated?
[20:49:10 CEST] <BBB> yeah Im not storing that :-p
[20:49:20 CEST] <BBB> you can add that obviously
[20:49:42 CEST] <nevcairiel> BBB: i figured its this bit http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9.c;h=ed0d905a0adb433596f2f65478304ab7189f3109;hb=HEAD#l724
[20:49:52 CEST] <BBB> right
[20:50:02 CEST] <nevcairiel> but i will double check with the vpx
[20:50:07 CEST] <BBB> no, youre right
[20:50:09 CEST] <BBB> its correct
[20:50:22 CEST] <BBB> libvpx stores that somewhere, I dont - feel free to add it in the appropriate place
[20:50:34 CEST] <nevcairiel> since there is no real vp9 spec, all the dxva2-vp9 variable names correspond to what vpx calls it in their source
[20:50:40 CEST] <BBB> you can see the decoder is slightly less optimized for hardware usage and slightly more for software only minimalism
[20:51:11 CEST] <nevcairiel> (in before I also have to do this for vp8 all over)
[20:56:49 CEST] <cone-163> ffmpeg 03Lou Logan 07master:329bd254750f: doc/filters: s/nb_inputs/inputs for stack filters
[21:00:06 CEST] <BBB> nevcairiel: well, our famous david conrad wrote the header parsing there, so maybe he was more descriptive than I was
[21:01:10 CEST] <nevcairiel> usually no point exporting flags that get never used after
[21:01:15 CEST] <nevcairiel> who knows why the hwaccel wants it
[21:02:54 CEST] <BBB> well it clearly does want it
[21:03:20 CEST] Action: BBB needs to find a way to bribe people to review his latest round of vp9 asm patches
[21:03:28 CEST] <BBB> nobody would do that for fun, I fear
[21:06:28 CEST] <Daemon404> \o/ AESNI
[21:08:20 CEST] <Gramner> BBB: the few comments I already posted applied to several of the patches, but I have no idea which patch is which anymore and whether or not those comments have been fixed in all places already
[21:09:26 CEST] <BBB> Gramner: I tried to fix all comments
[21:09:29 CEST] <Gramner> I mean, there's like 2^17 vp9 idct patches. they all look the same to me!
[21:09:44 CEST] <nevcairiel> BBB: https://github.com/Nevcairiel/FFmpeg/commit/aff4aaa19327c1dd2bb8d8a20e006481120d562b .. this should allow using VP9SharedContext to access this limited subset of data directly from the decoder
[21:09:48 CEST] <BBB> says the guy maintaining the 2^18 sad functions in x264
[21:10:00 CEST] <nevcairiel> (not a fan of my chose struct name, but i couldnt think of something better)
[21:10:05 CEST] <nevcairiel> *chosen
[21:10:21 CEST] <Daemon404> BBB, lies, some of them are SATD
[21:10:24 CEST] <nevcairiel> also sucky github not showing big diff
[21:10:34 CEST] <BBB> nevcairiel: lgtm
[21:11:02 CEST] <BBB> nevcairiel: and yes vp9.c part missing in github
[21:11:04 CEST] <ubitux> https://fr.surveymonkey.com/r/QCP7JSS
[21:11:04 CEST] <Daemon404> nevcairiel, they had to limit it cause it was crippling people's PCs with their js/styles
[21:11:06 CEST] <BBB> but its ok, it makes sense
[21:11:22 CEST] <nevcairiel> BBB: the part is there, github just choose to collapse the diff
[21:11:26 CEST] <ubitux> survey starts now; to the ~10 developers who answers the survey the first time, please do it again, otherwise it won't be counted
[21:11:34 CEST] <BBB> nevcairiel: if I expand it, it shows source, not diff
[21:11:38 CEST] <nevcairiel> BBB: https://github.com/Nevcairiel/FFmpeg/commit/aff4aaa19327c1dd2bb8d8a20e006481120d562b.patch
[21:12:22 CEST] <BBB> used to be s->keyframe
[21:12:23 CEST] <Gramner> x264 $ git grep "cglobal.*sad" | wc -l
[21:12:24 CEST] <Gramner> only 32
[21:12:29 CEST] <BBB> now its s->s.h.keyframe
[21:12:37 CEST] <BBB> in b4 someone mentions MpegEncContext
[21:12:41 CEST] <ubitux> durandal_1707: if you can share https://fr.surveymonkey.com/r/QCP7JSS on G+; llogan on twitter, that would be nice
[21:12:47 CEST] <BBB> but patch is fine, ty
[21:12:59 CEST] <nevcairiel> BBB: yeah that looks a bit funny, but what can you do
[21:13:04 CEST] <BBB> not much :)
[21:13:06 CEST] <Compn> ehe ubitux i'm curious what kind of responses we will get
[21:13:14 CEST] <Compn> ubitux : are you going to post that to -devel and -user ?
[21:13:22 CEST] <ubitux> it's already done
[21:13:26 CEST] <Compn> :)
[21:13:36 CEST] <ubitux> maybe api ml too?
[21:17:52 CEST] <jamrial> Compn: moar speed from users. better high level api from libav* devs. longer old api life from distro maintainers :p
[21:19:46 CEST] <Daemon404> ubitux, still lacks misc comments
[21:20:08 CEST] <ubitux> Daemon404: did you raise that and i missed it?
[21:20:17 CEST] <Daemon404> yes
[21:20:22 CEST] <ubitux> arg, sorry
[21:20:27 CEST] <ubitux> let me try to add it
[21:20:41 CEST] <Daemon404> i just think it's unwise to limit responses to things we can think of
[21:20:43 CEST] <Daemon404> it
[21:20:47 CEST] <Daemon404> it's self-selecting, in a wya
[21:20:49 CEST] <Daemon404> way*
[21:21:28 CEST] <ubitux> Daemon404: done
[21:21:39 CEST] <Daemon404> cool.
[21:21:41 CEST] <llogan> ubitux: what text would you like to accompany the link on twitter?
[21:22:40 CEST] <ubitux> maybe "Anonymous & fast survey for the project directions @ ..."?
[21:22:45 CEST] <ubitux> you're the 140 chars king
[21:22:49 CEST] <ubitux> i'm not used to this stuff
[21:23:05 CEST] <llogan> are there any devs here on twitter that i'm not following?
[21:23:32 CEST] <Daemon404> i only discovered nevcairiel has twitter today
[21:23:39 CEST] <Daemon404> with like two tweets
[21:24:47 CEST] <nevcairiel> i have tweets?
[21:25:00 CEST] <nevcairiel> i guess i asked some people something sometime
[21:25:15 CEST] <llogan> i guess generally we are too busy coding and fixing bugs to be tweeting. or are introverted hermits.
[21:25:17 CEST] <nevcairiel> i dont use it for "sharing"
[21:27:59 CEST] <nevcairiel> great, now ffmpeg follows me
[21:29:48 CEST] <ubitux> are you implying that you're the new ffmpeg leader?
[21:31:14 CEST] <J_Darnley> What does the new God Emperor of FFmpeg desire?
[21:35:15 CEST] <ubitux> i should have created different collector for different sources
[21:35:17 CEST] <ubitux> but well.
[21:37:29 CEST] <llogan> ubitux: tweeted
[21:37:35 CEST] <ubitux> thx
[21:38:00 CEST] <llogan> maybe i'll make a news entry later
[21:38:23 CEST] <ubitux> feel free to drop the "fr" in the url if you do
[21:38:41 CEST] <llogan> oui
[21:38:45 CEST] <rcombs> Gramner: check_func() runs once per function name, not per function pointer
[21:41:31 CEST] <Gramner> rcombs: ah, i missed that you used i as part of the name, sorry. also to be correct it's actually once per function pointer per function name
[21:41:55 CEST] <rcombs> ah yeah
[21:53:25 CEST] <ubitux> michaelni_: can you upload the new version of the webvtt sample so i can test & apply the patchset?
[21:53:31 CEST] <ubitux> "fate/subtitles: Add a new test for WebVTT"
[21:55:10 CEST] <durandal_1707> ubitux: change irc wall msg?
[21:56:47 CEST] <ubitux> feel free to, i'm not so sure
[21:56:57 CEST] <ubitux> i feel like only new users potentially read it
[21:58:30 CEST] <michaelni_> ubitux, updates sample
[21:58:34 CEST] <michaelni_> updateD
[21:58:37 CEST] <ubitux> thx
[22:09:21 CEST] <nevcairiel> BBB: i found another piece of info i need, and not sure where to move it .. its the segmentation probs, ie. prob.seg and prob.segpred (whatever prob means?), as they are not in the segmentation struct moving them would take them out of context making their names somewhat wrong, suggestion? :)
[22:09:59 CEST] <BBB> oh, right
[22:10:01 CEST] <BBB> ...
[22:10:05 CEST] <BBB> move them into header, I guess
[22:10:30 CEST] <BBB> Im trying to fix that crap in vp10, but segmentation is one of these pieces in vp9 that just didnt fit in with anything else in the bitstream, very oddly mashed together
[22:10:53 CEST] <BBB> also, sorry about that :)
[22:11:02 CEST] <nevcairiel> what does prob mean? does it mean anything?
[22:11:19 CEST] <nevcairiel> the only word that comes to mind is probability, but that seems wrong
[22:11:24 CEST] <ubitux> "problems"
[22:11:30 CEST] <ubitux> :(
[22:12:01 CEST] <nevcairiel> guess i'll move them into the segmentation struct then
[22:18:17 CEST] <jamrial> BBB: are you participating in vp10 design/development?
[22:18:24 CEST] <BBB> not really
[22:18:26 CEST] <BBB> I mean, a little
[22:18:43 CEST] <BBB> I filed a lot of bugs when I wrote ffvp9 on stuff thats bad
[22:18:53 CEST] <BBB> and Im trying to help here and there fixing some of these bads
[22:19:01 CEST] <jamrial> ah, i see
[22:19:04 CEST] <BBB> nevcairiel: prob is probability, yes
[22:19:27 CEST] <BBB> nevcairiel: its egment id prediction (segpred), and segmentation id (seg)
[22:20:25 CEST] <nevcairiel> and the probability is some kind of hint for the vlc reader?
[22:21:47 CEST] <ubitux> RiCON: i wonder if it would make sense to remove the <rt>.*</rt> content
[22:21:48 CEST] <BBB> its an arithmetic coder, like in h264 cabac
[22:21:54 CEST] <ubitux> or put them into parenthesis or sth
[22:22:09 CEST] <BBB> h264 uses states, which are adaptive; probabilities are like state, but 8bit instead of 7bit, and non-adaptive within the reader
[22:22:16 CEST] <BBB> instead theyre adapted per-frame
[22:22:20 CEST] <BBB> (independent of the reader)
[22:22:37 CEST] <cone-163> ffmpeg 03Ricardo Constantino 07master:53886d695513: avcodec/webvttdec: Deal with WebVTT escapes
[22:22:38 CEST] <cone-163> ffmpeg 03Ricardo Constantino 07master:a96dbdc14f3d: fate/subtitles: Add a new test for WebVTT
[22:22:39 CEST] <cone-163> ffmpeg 03Ricardo Constantino 07master:6eaf97c2894d: avformat/webvttdec: Don't stop parsing on comments
[22:24:24 CEST] <ubitux> for the bidi stuff, it might have been relevant to have a sample with arabic + numbers at the same time, but whatever
[22:24:52 CEST] <ubitux> mmh. i should have wait 24 hours for the samples to be populated, sorry
[22:29:09 CEST] <nevcairiel> BBB: this spec talks about "uncompressed header" and "compressed header" of a frame. does that tell you anything in particular?
[22:29:23 CEST] <BBB> yes
[22:29:31 CEST] <BBB> one of them is bit coded (like a regular bitreader)
[22:29:49 CEST] <BBB> the other is arithmetically coded, and contains most probability updates plus some random crap that shouldve been in the uncompressed header
[22:30:00 CEST] <nevcairiel> could you point me to the point where the uncompressed ends?
[22:30:06 CEST] <nevcairiel> (it wants the size of it)
[22:30:25 CEST] <nevcairiel> mm i think i found it
[22:33:15 CEST] <nevcairiel> i wonder if it counts the size of the compressed header into the uncompressed header
[22:33:23 CEST] <nevcairiel> well guess i'll test
[22:34:22 CEST] <RiCON> ubitux: implementing ruby using ass would be hard, so replacing <rt></rt> with parenthesis would be good enough
[22:35:17 CEST] <Daemon404> baptiste already did it
[22:35:18 CEST] <Daemon404> iirc
[22:35:24 CEST] <Daemon404> internally
[22:36:45 CEST] <RiCON> dunno if michaelni_ uploaded the new sample with the
[22:41:30 CEST] <BBB> nevcairiel: sorry, Im walking on and off
[22:41:55 CEST] <nevcairiel> no problem
[22:42:02 CEST] <nevcairiel> i found it already
[22:44:56 CEST] <rcombs> https://gist.github.com/5ba0ddc171f85f9c2677 <-- new AES benchmarks for 128, 192, and 256-bit encryption, versus all available libs
[22:47:47 CEST] <ubitux> rcombs: do you have a branch so i can test with a recent crypto lib?
[22:48:37 CEST] <rcombs> ubitux: https://gist.github.com/199d871da4715f60f8f4
[22:49:09 CEST] <cone-163> ffmpeg 03Alexandra Hájková 07release/2.8:f235f511a01c: asfdec: alloc enough space for storing name in asf_read_metadata_obj
[22:49:10 CEST] <cone-163> ffmpeg 03Alexandra Hájková 07release/2.8:8118fdf8bb92: asfdec: add more checks for size left in asf packet buffer
[22:49:11 CEST] <cone-163> ffmpeg 03Andreas Cadhalpun 07release/2.8:173053a1252c: hls: only seek if there is an offset
[22:49:12 CEST] <cone-163> ffmpeg 03Andreas Cadhalpun 07release/2.8:13d374942481: doc: fix spelling errors
[22:49:35 CEST] <ubitux> rcombs: i mean a branch with that & your AESNI changes :)
[22:50:00 CEST] <rcombs> I can push to my github fork in a minute
[22:50:12 CEST] <ubitux> cool, thx :)
[22:50:13 CEST] <rcombs> lemme finish tweaking crypto_bench to do tests against the C version too
[22:50:19 CEST] <ubitux> sure
[23:03:43 CEST] <spicypixel> question: can you use DXVA decode support at the same time as quicksync encoding with ffmpeg?
[23:05:20 CEST] <nevcairiel> mm it doesnt work, the driver offers a picture parameter buffer which is too small to fit the structure from the spec
[23:05:34 CEST] Action: nevcairiel updates driver
[23:10:42 CEST] <kode54> durandal_1707: I do maintain the foobar2000 plugin, and a source repository, if not the official one
[23:11:03 CEST] <nevcairiel> ah new driver and now i get a proper buffer, but another error
[23:11:05 CEST] <nevcairiel> progress!
[23:18:27 CEST] <ubitux> anyone has an idea which entry in the survey matrix has the biggest score (toward urgency)
[23:18:29 CEST] <ubitux> ? :)
[23:19:01 CEST] <jamrial> high level api?
[23:19:04 CEST] <ubitux> it's kind of early to say this is relevant (~40 answers), but still, it's funny
[23:19:17 CEST] <nevcairiel> more refactoring?
[23:19:17 CEST] <nevcairiel> :D
[23:19:30 CEST] <ubitux> more speed optimizations... :)
[23:19:36 CEST] <nevcairiel> thats expected
[23:19:54 CEST] <jamrial> heh
[23:19:55 CEST] <ubitux> really?
[23:19:58 CEST] <ubitux> i wasn't expecting this
[23:20:33 CEST] <wm4> is the final questionaire up yet
[23:20:39 CEST] <ubitux> sure
[23:20:51 CEST] <ubitux> https://surveymonkey.com/r/QCP7JSS
[23:20:54 CEST] <jamrial> if those ~40 are mostly vlc, lavfilters, etc users (aka, not devs of any kind), then it isn't unexpected
[23:21:44 CEST] <ubitux> 35% api user, 83% cmd line user, 20% ff contrib/dev, 5% packagers
[23:22:33 CEST] <ubitux> anyway, we'll see, it's still pretty fresh, and too low numbers to make conclusions
[23:23:02 CEST] <ubitux> hevc probably needs some love
[23:23:06 CEST] <jamrial> mmh, i could see people that simply use vlc/mpc-hc/lavfilters not knowing which to choose out of those
[23:23:41 CEST] <ubitux> yeah indeed
[23:23:56 CEST] <ubitux> should i add an entry quickly?
[23:24:02 CEST] <wm4> we should have asked for XP support
[23:24:03 CEST] <ubitux> or we should ignore these users?
[23:24:17 CEST] <jamrial> if you can then yeah
[23:24:35 CEST] <ubitux> give me a copy pastable entry to add
[23:25:59 CEST] <wm4> sorry that all the ideas come now
[23:26:13 CEST] <wm4> but a question whether API should be simplified should also be there
[23:26:29 CEST] <wm4> that's more "positive" than "API compatibility"
[23:26:44 CEST] <jamrial> "An user of applications that implement FFmpeg (video players, converters, etc)"
[23:26:47 CEST] <jamrial> idk
[23:27:01 CEST] <ubitux> wm4: API redesign & cleanups?
[23:27:03 CEST] <jamrial> maybe you can rephrase it a bit
[23:27:22 CEST] <ubitux> "A" user? i never know :(
[23:28:10 CEST] <jamrial> "a", yeah
[23:28:15 CEST] <ubitux> "A user of applications using FFmpeg libraries (video players, converters, etc)"?
[23:28:17 CEST] <jamrial> english is hard
[23:28:47 CEST] <jamrial> sure
[23:29:00 CEST] <ubitux> done
[23:29:40 CEST] <ubitux> let's not adjust even further
[23:29:56 CEST] <ubitux> we can still make more survey in the future, let's remember the mistakes on this one
[23:35:51 CEST] <rcombs> https://gist.github.com/665d39bb1ac1a6f6e8a0 <-- ubitux: done, pushing to my repo in a sec
[23:39:19 CEST] <Compn> so any results from the poll yet ?
[23:41:22 CEST] <rcombs> ubitux: https://github.com/rcombs/FFmpeg/tree/aesni
[23:41:56 CEST] <rcombs> the cpuflag stuff in crypto_bench is kinda janky but does the job for now
[23:44:54 CEST] <rcombs> also I'm not sure if that's against libcrypto_1.0.2d or the old 0.9.8 OS X ships
[00:00:00 CEST] --- Tue Oct 13 2015
More information about the Ffmpeg-devel-irc
mailing list