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

[burek]

[00:12:43 CEST] <rcombs> considering working on Matroska edition support in lavf
[00:13:08 CEST] <rcombs> wondering how to expose the multiple editions
[00:13:45 CEST] <rcombs> picking one could be done with a private option, but it seems useful to have an API for listing them, and if we're going to have that then editions themselves may as well be a bit more native
[00:15:01 CEST] <cone-569> ffmpeg 03James Almer 07master:3d1690b8c69c: avutil: undo FF_API_CRYPTO_CONTEXT deprecation
[01:09:31 CEST] <J_Darnley> The help already states that options precede the file to which they refer.
[01:54:39 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:cf52ae003b42: avutil/mem: add av_warn_unused_result
[01:57:02 CEST] <BBB> nevcairiel: go go go go go!
[02:32:33 CEST] <wm4> rcombs: how would that even be possible without ordered chapters support? without them, editions are pretty useless
[02:33:45 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:a878dfa4f57d: avcodec/ffv1: Initialize vlc_state on allocation
[03:31:47 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:b9fb1db9b42c: aactab: move ltp_coef[] from aacdectab to aactab
[03:31:48 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:8dd2d5e70a30: aacenc: indicate that TNS is off by default
[03:31:49 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:564db3e55dfd: aacenc_pred: correct header information
[03:31:50 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:2d9b5ae071c0: aacenc: slightly simplify and remove a redundant variable
[03:31:51 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:3f3be1c07ac0: aacenc: correctly zero prediction_used array
[03:31:52 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:148cf4690c81: aacenc_pred: only print predictor information if profile is aac_main
[03:31:53 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:83900c0ed34c: aacenc: (re)enable Mid/Side coding by default
[03:31:54 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:27d23ae07424: aacenc: add support for encoding files using Long Term Prediction
[03:55:18 CEST] <rcombs> wm4: I meant both
[03:59:34 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:3835554bf8ed: avfilter/avfiltergraph: fix -Wunused-result warnings
[04:17:39 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:e9299df7a6df: aacenc: partially revert previous commits to set options via a profile
[04:29:20 CEST] <atomnuker> alright, that about wraps it up folks, the only profile left to implement is AAC_HE
[04:30:53 CEST] <atomnuker> I'll fix up TNS so it can be enabled by default, Claudio has to merge his techno-synth psy-cutoff fix consisting of a few one-liners
[04:31:16 CEST] <atomnuker> and we'll remove the flag
[04:32:19 CEST] <atomnuker> SSR doesn't seem like it's easily doable using the current encoder and I haven't seen any files at all encoded using that profile
[04:33:35 CEST] <atomnuker> and parametric stereo doesn't seem like it's worth the effort and the quality loss for dubious gains with very specific audio files
[05:49:00 CEST] <Timothy_Gu> BtbN: can you review https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181184.html when you get the time? thx
[06:44:40 CEST] <atomnuker> just noticed, turning on Mid/Side by default decreased the stddev in fate and I forgot to fix the targets, will push the new ones in a few mins
[07:01:05 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:777b305bed15: fate: adjust aac encoder test values and introduce MS and LTP tests
[07:38:53 CEST] <atomnuker> I had no idea ffmpeg is still compilable by gcc 3.4 from 2005, but apparently it's miscompiling the M/S coding
[08:03:32 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:590008e69619: aacenc: increase fuzz on aac-ms-encode test
[10:16:59 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:d2a1029724f5: opencl: Print error string when compilation fails
[10:17:00 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:893a648182e4: opencl: Print compilation log
[10:17:01 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:17c68933f44f: opencl: Use "opencl" as log context name
[10:17:02 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:801eca1372dd: opencl: Force the use of 1.2 APIs
[11:05:45 CEST] <BtbN> Timothy_Gu, huh, I don't have that mail. But sure
[11:07:13 CEST] <BtbN> Could you paste the patch somewhere? I have no idea how to get a propper patch out of the archives.
[11:08:09 CEST] <BtbN> But it looks good, feel free to push.
[12:11:00 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:8d18d28918df: aacenc_tns: add moving average filter for LTP
[12:11:01 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:f3ad901a32c9: aacenc_tns: disable coefficient compression by default
[12:11:02 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:bf39beca8784: aacenc_tns: simplify encoding function
[12:11:03 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:fa4d900c275f: aacenc_tns: rework TNS descision logic
[12:11:04 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:8ce6e24db428: fate: adjust the target for the new TNS changes
[12:11:05 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:dfba1be96350: aacenc_tns: enable Temporal Noise Shaping by default
[12:11:06 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:d4da15563fb2: fate: add a parameter to disable TNS for the other encoder tests
[12:12:01 CEST] <ubitux> @_@
[12:24:47 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:6eff30b0bcf9: fate: increase fuzz on AAC LTP encoding test
[12:29:28 CEST] <michaelni_> atomnuker,  "make  fate-aac-ltp-encode" fails with Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:157 (needs  --assert-level=2 i assume)
[12:30:21 CEST] <atomnuker> I always use assert-level 2
[12:30:35 CEST] <atomnuker> hm
[12:34:11 CEST] <atomnuker> michaelni_: with which sample does it happen with?
[12:34:46 CEST] <michaelni_> fate-suite//audio-reference/luckynight_2ch_44kHz_s16.wav
[12:34:49 CEST] <ubitux> according to make fate-aac-ltp-encode V=1, /home/ux/fate-samples/audio-reference/luckynight_2ch_44kHz_s16.wav
[12:34:59 CEST] <ubitux> i also have the abort
[12:39:17 CEST] <atomnuker> can't replicate yet, but on it
[12:59:25 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:58b19b6f636e: tests/fate-run: Remove PROGSUF from function calls
[12:59:26 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:acf23d9451e9: avformat/genh: Check av_new_packet() return value
[12:59:27 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:92a26261d1cc: avformat/rsd: Check av_new_packet() return value
[13:00:45 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:780dba01f9ae: aacenc_ltp: fix assertion
[13:01:23 CEST] <atomnuker> michaelni_ ubitux: fixed, that was a lame mistake
[13:11:13 CEST] <michaelni_> atomnuker, thx
[13:14:36 CEST] <wm4> rcombs: well, how do you intend to implement them at all?
[13:18:24 CEST] <ubitux> atomnuker: can't use av_clip_uintp2(lag, 11) btw?
[13:19:50 CEST] <atomnuker> didn't know there was such a function, thanks
[13:22:46 CEST] <nevcairiel> can we call that super-ticket closed by now? :)
[13:23:10 CEST] <ubitux> what's remaining before removing the experimental bit?
[13:23:24 CEST] <kurosu> 500 posts in that ticket
[13:23:26 CEST] <nevcairiel> claudios two fixes
[13:23:33 CEST] <ubitux> :)
[13:23:35 CEST] <ubitux> ok
[13:23:51 CEST] <nevcairiel> so with any luck this weekend
[13:25:06 CEST] <nevcairiel> in other news my braswell NUC arrived, hopefully Intels vp9 dxva2 isnt broken and i can finish my code!
[13:25:26 CEST] <ubitux> yay :)
[13:26:28 CEST] <kurosu> isn't that hybrid ? not a big deal I guess, as getting dvxa2 vp9 support was a big incentive
[13:26:30 CEST] <kurosu> will it have any other use afterwards?
[13:26:52 CEST] <nevcairiel> i dont really care how the driver implements it, hardware or hybrid
[13:27:03 CEST] <nevcairiel> if i can get it to work, it will work on any implementation
[13:27:07 CEST] <kurosu> as long as it plays realtime
[13:27:21 CEST] <wm4> which intel cpus supposedly support vp9?
[13:27:48 CEST] <kurosu> > haswell, ie broadwell, braswell and skylake ?
[13:27:56 CEST] <nevcairiel> haswell doesnt
[13:27:57 CEST] <kurosu> (not sure about broadwell)
[13:28:05 CEST] <nevcairiel> broadwell seems to
[13:28:27 CEST] <nevcairiel> so broadwell, braswell and skylake
[13:28:47 CEST] <wm4> ok... skylake definitely doesn't report vp9 on linux
[13:28:51 CEST] <ubitux> no overview of hevc/vp9 enc&dec hw support somewhere?
[13:28:58 CEST] <nevcairiel> probably somewhere
[13:29:04 CEST] <wm4> ubitux: there's a bad wiki page
[13:29:06 CEST] <wm4> but no
[13:29:11 CEST] <wm4> if you mean ffmpeg's
[13:29:30 CEST] <nevcairiel> i think he meant hardware
[13:29:33 CEST] <ubitux> no, unrelated to ffmpeg, just to see which codec is getting ground
[13:32:21 CEST] <nevcairiel> i dont know of a nice overview, just that Intel supports vp9-hybrid since gen8, thats broadwell/braswell, skylake is gen9
[13:32:30 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:b0a3c614b4e3: aacenc_ltp: replace av_clip() with av_clip_uintp2()
[13:32:31 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:b1d290920de5: fate: use -profile:a aac_ltp instead of -aac_ltp 1 for LTP encode test
[13:33:55 CEST] <nevcairiel> (gen9 adds full hardware hevc main and hybrid main10, gen8 only had hybrid main, no 10 at all)
[13:34:48 CEST] <nevcairiel> presumably vp8 is fully hardware accelerated, but current drivers dont seem to implement the Microsoft vp9 dxva2 spec yet
[13:35:50 CEST] <fritsch> on windows ...
[13:35:53 CEST] <fritsch> the world seems more bright
[13:36:26 CEST] <fritsch> i will stop caring for linux hevc 10 bit support ... it's not worth the hassle ...
[13:36:28 CEST] <nevcairiel> i really cant complain about that, i even managed to make zero copy dxva2 hevc10 decoding work a couple weeks ago
[13:36:39 CEST] <fritsch> next gen CPUs to be released in 2k16 will have hw to do it
[13:36:52 CEST] <fritsch> and then linux should be fine again
[13:37:10 CEST] <fritsch> linux is not really a market for intel anymore ...
[13:37:20 CEST] <nevcairiel> does vdpau do 10-bit?
[13:37:21 CEST] <fritsch> vaapi wise
[13:37:26 CEST] <ubitux> what's the state of h26[45]/vp9 10-bit on ARM btw?
[13:37:30 CEST] <fritsch> it's planned philipl said
[13:37:36 CEST] <fritsch> vp9 and hevc 10 bit
[13:37:37 CEST] <fritsch> work
[13:37:41 CEST] <nevcairiel> ubitux: no h264 10-bit from everyone
[13:37:42 CEST] <fritsch> on android
[13:37:46 CEST] <nevcairiel> anyone*
[13:37:49 CEST] <fritsch> and amlogic
[13:37:51 CEST] <ubitux> sad.
[13:38:02 CEST] <fritsch> h264 10 bit <-
[13:38:03 CEST] <nevcairiel> but 265 you might get lucky eventually
[13:38:04 CEST] <fritsch> hevc you mean
[13:38:20 CEST] <ubitux> no i meant h264 too
[13:38:21 CEST] <nevcairiel> and vp9 10-bit .. you keep dreaming :)
[13:38:24 CEST] <ubitux> :D
[13:38:34 CEST] <nevcairiel> dxva2 only covers profile0, that is 420 8
[13:38:57 CEST] <ubitux> i mean, i have a ton of h264 10-bit material, and i was wondering if sth !intel could play them :p
[13:39:16 CEST] <fritsch> ubitux: amd radeon oss vdpau
[13:39:17 CEST] <fritsch> no joke
[13:39:23 CEST] <fritsch> christian könig had some patches ready
[13:39:26 CEST] <nevcairiel> its not true though
[13:39:34 CEST] <nevcairiel> you will not a spec compliant image
[13:39:37 CEST] <nevcairiel> +get
[13:39:42 CEST] <fritsch> it was some internal hack
[13:39:43 CEST] <fritsch> yes
[13:39:54 CEST] <nevcairiel> it uses the 8-bit decoder, so you can hope it doesnt artifact too badly
[13:39:59 CEST] <fritsch> hehe
[13:40:01 CEST] <fritsch> yeah
[13:40:06 CEST] <ubitux> small amd radeon hw out there?
[13:40:13 CEST] <nevcairiel> some people liked to advertise that as 10-bit support
[13:40:17 CEST] <nevcairiel> i can only laugh at them
[13:40:29 CEST] <wm4> <nevcairiel> i really cant complain about that, i even managed to make zero copy dxva2 hevc10 decoding work a couple weeks ago <- was it worth it?
[13:40:48 CEST] <nevcairiel> wm4: why not, 0% cpu load when decoding 4k 10-bit?
[13:40:58 CEST] <nevcairiel> well 0 is a bit over the top, maybe 1% for parsing
[13:41:19 CEST] <wm4> don't know, you always sounded pretty convinced over your copyback approach
[13:41:27 CEST] <nevcairiel> that works fine too
[13:41:35 CEST] <nevcairiel> but some people just have low-end systems
[13:41:52 CEST] <nevcairiel> and while you give up some flexibility with using the zero copy mode, it works fine on those 
[13:42:07 CEST] <nevcairiel> 10-bit 4k is quite a bit of data that otherwise roams around the bus
[13:43:35 CEST] <nevcairiel> it wasnt actually hard to get it working, just needed to convince the video renderer to accept it and treat it properly, which surprisingly wasnt that bad
[13:44:12 CEST] <nevcairiel> the only annoying part is that Microsofts Enhanced Video Renderer can accept dxva2 surfaces with 10-bit content, but software buffers don't work, need to go 8-bit there
[13:44:17 CEST] <nevcairiel> its one of those wtf moments :p
[13:45:25 CEST] <wm4> fun
[13:49:19 CEST] <Compn> just have to tell the hentai groups to stop encoding 10bit h264.... ;p
[13:52:46 CEST] <nevcairiel> while this NUC is installing windows, i can go have some lunch \o/
[13:56:12 CEST] <kierank> atomnuker: shall I copy you the crashing files on avdev and ffmpeg build?
[13:57:01 CEST] <nevcairiel> kierank: maybe you should try fuzzing with raw audio files and appropriate command lines, then you can get all these annoyances with the demuxer and whatnot out of the way
[13:57:28 CEST] <kierank> doesn't seem to be demuxer related (look at the valgrind log)
[13:57:44 CEST] <nevcairiel> but it tries to decode your wav file as aac, who knows whats going on :D
[13:57:54 CEST] <kierank> it seems to be warped files being misdetected as aac and the decoded garbled audio causing the encoder to crash
[13:58:15 CEST] <kierank> but I guess there might be a less circuitous route
[13:58:36 CEST] <fritsch> might be related to: https://trac.ffmpeg.org/ticket/4864#comment:2
[13:58:42 CEST] <fritsch> happens more often
[13:58:46 CEST] <fritsch> in other places
[13:58:56 CEST] <nevcairiel> thats specifically mp3 being annoying
[13:58:59 CEST] <fritsch> this was ac3 as mp3
[13:59:26 CEST] <nevcairiel> the mp3 probe can be quite forgiving and accept whatever files
[13:59:38 CEST] <fritsch> "Plays fine with WMP, I don't know if this will be fixed in FFmpeg."
[13:59:47 CEST] <fritsch> i don't understand this answer btw.
[14:00:15 CEST] <nevcairiel> noone  understands carl sometimes
[14:00:18 CEST] <fritsch> hehe
[14:00:38 CEST] <fritsch> does that mean: he does not know, if he feels like fixing it
[14:00:47 CEST] <fritsch> or he does not know, if someone will fix it
[14:00:52 CEST] <fritsch> or if it's "fixable"
[14:00:53 CEST] <fritsch> :-)
[14:00:59 CEST] <fritsch> yeah, let's keep it open anyways
[14:03:06 CEST] <nevcairiel> why does trac open a .ts file in a text viewer instead of offering me a download
[14:29:32 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:4c9805538db0: aacenc_ltp: correct header description comment
[15:02:09 CEST] <cone-569> ffmpeg 03Clément BSsch 07master:8c9c8fd035a9: avfilter/selectivecolor: fix correction_method option range
[15:08:43 CEST] <J_Darnley> nevcairiel: I guess the server says its mime type is text ot html
[15:39:26 CEST] <cone-569> ffmpeg 03Hendrik Leppkes 07master:a8e86b0e3f38: libavformat/Makefile: remove unnecessary object file from wtv demuxer
[15:51:53 CEST] <durandal_1707> atomnuker: are you going to add he-aac?
[16:43:37 CEST] <cone-569> ffmpeg 03Timothy Gu 07master:ed53c14a3ce2: chromakey: Use the pixel descriptor API for chroma subsampling info
[16:47:48 CEST] <Timothy_Gu> BtbN: okay thx. pushed
[16:59:33 CEST] <ubitux> btw, the "unit" thing in AVOption is weird; the const avoption .unit should simply refer to the related option name, instead of adding a double string of (often) the exact same value in the main option
[16:59:44 CEST] <ubitux> or i'm missing something?
[17:06:46 CEST] <nevcairiel> Timothy_Gu: your funny parsing comment totally confused ganesh :D
[17:07:14 CEST] <Timothy_Gu> I'd like to declare 3 arguments to be stored on registers, 2 arguments on the stack, and 2 gprs. can I do that?
[17:07:20 CEST] <Timothy_Gu> nevcairiel: yes it did :(
[17:07:31 CEST] <Timothy_Gu> (in x86 asm)
[17:07:33 CEST] <nevcairiel> registers == gprs
[17:07:41 CEST] <Timothy_Gu> yes ik
[17:07:54 CEST] <nevcairiel> you mean in that particular order?
[17:07:57 CEST] <nevcairiel> then no, you cannot
[17:08:18 CEST] <nevcairiel> you can only have trailing arguments on the stack, not some in the middle
[17:08:34 CEST] <nevcairiel> of course you could emulate that yourself by simply loading the last 2 arguments into a reg
[17:08:39 CEST] <Timothy_Gu> no the two args are trailing
[17:08:50 CEST] <Timothy_Gu> and i want two free additional registers
[17:08:56 CEST] <Timothy_Gu> not used for the args
[17:09:02 CEST] <nevcairiel> i'm confused now
[17:09:12 CEST] <nevcairiel> you want 5 arguments, 2 on stack?
[17:09:16 CEST] <Timothy_Gu> yes
[17:09:17 CEST] <nevcairiel> and 2 tmp registers?
[17:09:19 CEST] <Timothy_Gu> yes
[17:09:36 CEST] <nevcairiel> that should be possible
[17:09:46 CEST] <nevcairiel> just declare 5 regs, 3 arguments
[17:09:54 CEST] <nevcairiel> i think
[17:10:00 CEST] <Timothy_Gu> oh
[17:10:20 CEST] <nevcairiel> although getting ahold of the stack arguments might be a bit weird then
[17:10:22 CEST] <nevcairiel> i dunno
[17:10:26 CEST] Action: nevcairiel reads docs
[17:10:42 CEST] <J_Darnley> on x68-64 4 or 6 args are passed registers
[17:10:51 CEST] <J_Darnley> *in registers
[17:11:10 CEST] <J_Darnley> The first param controls automatically loaded arguments
[17:11:25 CEST] <J_Darnley> The second how many registers you want to use
[17:11:38 CEST] <J_Darnley> total that is
[17:11:51 CEST] <nevcairiel> you need to use stack pointer math to find your last two arguments then, though
[17:12:09 CEST] <J_Darnley> rXm will work in that case
[17:12:22 CEST] <nevcairiel> ah right
[17:12:24 CEST] <nevcairiel> i forgot
[17:12:29 CEST] <J_Darnley> or rXmp depending on size
[17:13:07 CEST] <nevcairiel> "cglobal foo, 3, 5, X, arg1, arg2, arg3, tmp1, tmp2" should work then
[17:13:12 CEST] <Timothy_Gu> so if i declared 3,5, my first args are in r0, r1, and r2 (properly named of course), next two args are in r3mp and r4mp, and two free registers are r3 and r4?
[17:14:03 CEST] <J_Darnley> Yes, if on 32 bit
[17:14:10 CEST] <Timothy_Gu> does that work with 64-bit since r3mp is technically equivalent to r3?
[17:14:29 CEST] <nevcairiel> i would hope x86inc is s mart enough and doesnt assign r3 to tmp1 then
[17:15:19 CEST] <J_Darnley> I don't think it is.
[17:15:54 CEST] <Timothy_Gu> :(
[17:16:44 CEST] <J_Darnley> Use the DEFINE_TMP_REG macro to set which registers are used on which platform
[17:17:30 CEST] <J_Darnley> Yadif has an example of differing register usage
[17:18:05 CEST] <Timothy_Gu> ok i'll take a look
[17:18:21 CEST] <J_Darnley> (I'm sure others do too but I know yadif)
[17:48:35 CEST] <ubitux> i have a memory corruption with a normal aac encode with ffmpeg; atomnuker, interested?
[17:49:26 CEST] <ubitux> http://pastie.org/pastes/10488769/text
[17:51:06 CEST] <kierank> wow
[17:51:11 CEST] <ubitux> happens only with -profile:a aac_ltp (i was looking at #2686 and it was mentioned)
[17:51:22 CEST] <kierank> ah
[17:51:35 CEST] <ubitux> (86.69%  ffmpeg_g  ffmpeg_g            [.] ff_aac_update_ltp btw..)
[17:54:22 CEST] <ubitux> ADTS frame size too large: 8804 (max 8191)
[17:54:25 CEST] <ubitux> damn.
[17:54:31 CEST] <ubitux> i'm going to have some trouble making a small sample.
[17:54:58 CEST] <kierank> mux it in latm
[17:55:02 CEST] <ubitux> can't codec copy a aac :(
[17:55:23 CEST] <ubitux> ah i'm stupid.
[17:57:36 CEST] <ubitux> zsh: floating point exception (core dumped)
[17:57:44 CEST] <ubitux> funny, i'm getting this with a sample of it...
[18:04:59 CEST] <Timothy_Gu> apparently my WIP asm file stalls yasm ...
[18:06:54 CEST] <JEEB> make sure it's newer than 1.2
[18:07:17 CEST] <JEEB> https://github.com/yasm/yasm/commit/e32ff2c2abc22532a58c9b687d922500d23fd709
[18:07:22 CEST] <JEEB> you pretty much want to have this
[18:08:16 CEST] <Timothy_Gu> yasm --version
[18:08:16 CEST] <Timothy_Gu> yasm 1.3.0
[18:08:17 CEST] <Timothy_Gu> Compiled on May  3 2015.
[18:08:26 CEST] <Timothy_Gu> I think I messed somewhere with the macros
[18:08:31 CEST] <Timothy_Gu> *messed up
[18:08:35 CEST] <ubitux> atomnuker: http://trac.ffmpeg.org/ticket/4943
[18:11:20 CEST] <Timothy_Gu> hmm seems like it's because of a typo DEFINE_REG_TMP -> DECLARE_REG_TMP
[18:11:39 CEST] <Timothy_Gu> nice one yasm
[18:19:19 CEST] <Timothy_Gu> J_Darnley: how can you access a 64-bit argument in x86_32?
[18:19:38 CEST] <nevcairiel> thats a bit more tricky
[18:20:25 CEST] <Timothy_Gu> hm ok
[18:28:25 CEST] <cone-569> ffmpeg 03Ganesh Ajjanagadde 07master:01790484c130: avfilter/internal: add av_warn_unused_result
[18:33:18 CEST] <nevcairiel> i should setup distcc, poor braswell is melting trying to rebuild avcodec all the time
[18:40:48 CEST] <cone-569> ffmpeg 03Marton Balint 07master:df239b761951: concatdec: fix file_start_time calculation regression
[18:43:06 CEST] <jamrial> nevcairiel: ccache?
[18:45:57 CEST] <atomnuker> ubitux: I can't seem to replicate the LTP crash
[18:46:14 CEST] <ubitux> i can replicate with many inputs actually
[18:46:20 CEST] <atomnuker> can you tell me if it still happens if you put -aac_tns 0 ?
[18:48:43 CEST] <ubitux> will test in a moment
[18:49:00 CEST] <ubitux> btw, i believe this: http://pastie.org/10488930 might improve speed (untested, random crashes don't help)
[18:49:29 CEST] <ubitux> you might also want to define a NBITS 11 to make sure the samples_num is indeed interpreted as a scalar in that part
[18:50:01 CEST] <ubitux> (and use 1<<11 and 1<<10 instead of samples_num and 1024, maybe)
[18:50:01 CEST] <nevcairiel> hm
[18:50:06 CEST] <nevcairiel> my vp9 hwaccel kind of works
[18:50:12 CEST] <nevcairiel> it can decode key frames, apparently
[18:51:05 CEST] <nevcairiel> ..and then something weird happens on the next frame :D
[18:51:48 CEST] <ubitux> atomnuker: i can't reproduce the crash anymore; i'm starting to wonder if it was a ccache or random breakage on my system
[18:52:43 CEST] <atomnuker> ubitux: even if you reenable aac_tns?
[18:52:52 CEST] <ubitux> yeah, sth is fishy
[18:53:03 CEST] <ubitux> gonna cleanup ccache cache & rebuild everything.
[18:54:19 CEST] <J_Darnley> Timothy_Gu: for arithmetic I have no idea.  You would have to look it up
[18:58:01 CEST] <Timothy_Gu> ok
[18:58:25 CEST] <Timothy_Gu> i'm using it in psraw anyway so i guess I can just pass in the stack offset
[19:09:25 CEST] <rcombs> wm4: planning on going the lazy route in avformat/matroskadec (which should cover the vast majority of use-cases)
[19:14:03 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:66d36668031d: tests/fate-run: Remove ./ from run ffmpeg call
[19:14:04 CEST] <cone-569> ffmpeg 03Michael Niedermayer 07master:c38a6077eea8: avcodec/aacenc: Fix "libavcodec/aacenc.c:540:13: warning: ISO C90 forbids mixed declarations and code"
[19:17:36 CEST] <ubitux> atomnuker: i know what you're going to say, but can you reproduce with my patch applied?
[19:18:21 CEST] <ubitux> i wonder if it's a race
[19:20:09 CEST] <atomnuker> ubitux: how'd you know what I was going to say? I'd like to know what I was going to say.
[19:20:19 CEST] <nevcairiel> my vp9 hwaccel works now... but only if threading is disabled
[19:20:23 CEST] <nevcairiel> f'ing threading with hwaccels
[19:20:24 CEST] <atomnuker> your patch did speed up encoding by a second for 10 second files
[19:20:32 CEST] <ubitux> atomnuker: that if my patch is the cause of the crash
[19:20:34 CEST] <nevcairiel> i should just patch it out of the sources secretly
[19:20:38 CEST] <ubitux> i should patch it myself
[19:20:52 CEST] <ubitux> (but i swear the crash happened before my patch too :()
[19:20:58 CEST] <ubitux> (now i can only trigger it with my patch applied)
[19:21:04 CEST] <ubitux> atomnuker: ah, that sounds pretty good
[19:21:10 CEST] <ubitux> does it look correct to you?
[19:22:06 CEST] <wm4> nevcairiel: propose a patch that disables threading while hwaccel is active
[19:22:48 CEST] <nevcairiel> the real problem is that i dont know if its just a bug in my code or  just the usual threading failure
[19:22:53 CEST] <atomnuker> ubitux: yes, fate-aac-ltp-encode doesn't fail so it's probably making identical files
[19:24:46 CEST] <fritsch> nevcairiel: is there any hwaccel that actually uses threading?
[19:25:09 CEST] <nevcairiel> fritsch: no, they dont, and avcodec fudges it in such a way that frame threads just execute serially and never in parallel
[19:25:14 CEST] <fritsch> we also handle that specially in kodi
[19:25:16 CEST] <nevcairiel> but that doesn't account for a bunch of othre things
[19:25:18 CEST] <fritsch> to not run into issues
[19:25:27 CEST] <fritsch> most when processing thumbnails
[19:25:39 CEST] <fritsch> okay
[19:25:46 CEST] <nevcairiel> ie. avcodec doesnt know what the user code is going to do with the hw surfaces
[19:25:55 CEST] <wm4> only vlc wants hwaccel and threads
[19:26:04 CEST] <nevcairiel> because they have lazy devs
[19:26:05 CEST] <nevcairiel> :P
[19:26:08 CEST] <fritsch> hehe
[19:26:16 CEST] <wm4> they want to use lavc's native sw decoding fallback
[19:26:26 CEST] <fritsch> they don't have to loose it
[19:26:28 CEST] <nevcairiel> yes, thats the lazy approach
[19:26:29 CEST] <ubitux> atomnuker: https://github.com/ubitux/FFmpeg/compare/ltp-fast  and with that last one?
[19:26:29 CEST] <fritsch> see how kodi does it
[19:26:36 CEST] <wm4> fritsch: how does kodi do it
[19:26:41 CEST] <fritsch> wait I show you
[19:26:49 CEST] <fritsch> that was a very long discussion
[19:26:50 CEST] <nevcairiel> i do it clean and re-open the codeccontext
[19:26:53 CEST] <nevcairiel> similar to mpv i believe
[19:26:53 CEST] <fritsch> cause if hwaccel opening failed
[19:26:57 CEST] <fritsch> we ended single threaded
[19:27:08 CEST] <wm4> nevcairiel: yes
[19:27:21 CEST] <wm4> I completely destroy and recreate the context
[19:27:27 CEST] <nevcairiel> same
[19:27:38 CEST] <atomnuker> ubitux: already did those, didn't result in much of a speedup
[19:27:43 CEST] <ubitux> ok
[19:27:46 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecFFmpeg.cpp
[19:27:58 CEST] <ubitux> atomnuker: and with these patches, can't reproduce the crash?
[19:28:11 CEST] <fritsch> so in case hwaccel fails to init we fully reopen
[19:28:14 CEST] <fritsch> and set hints to software
[19:28:22 CEST] <nevcairiel> sounds about the same
[19:28:25 CEST] <ubitux> it seems to help triggering
[19:29:02 CEST] <nevcairiel> thats what we do as well, if hwaccel fails for some reason, just do a complete reset and re-open the decoder with software
[19:29:13 CEST] <nevcairiel> just vlc didnt want to do this, so now we have hacks :)
[19:29:15 CEST] <nevcairiel> that barely work
[19:29:56 CEST] <atomnuker> ubitux: nope
[19:30:00 CEST] <ubitux> ok :(
[19:30:23 CEST] <ubitux> should i send, apply, wait, or drop the patches?
[19:30:35 CEST] <nevcairiel> maybe i can at least figure out why it crashess with threads, it didnt do that with h264 previously
[19:31:01 CEST] <atomnuker> ubitux: well, I've already got a few more optimizations on top of your patches
[19:31:08 CEST] <ubitux> ok ok
[19:31:16 CEST] <ubitux> well i drop & wait then
[19:31:21 CEST] <wm4> IMO a player needs to be more flexible about fallbacks, up to a point that the fallback (or hwaccel) might use a different AVCodec, or not even lavc at all
[19:31:39 CEST] <nevcairiel> yeah i can do that
[19:31:48 CEST] <ubitux> atomnuker: perf still says 82.41% in ff_aac_update_ltp, so i'm assuming there is a lot of room for improvement
[19:31:50 CEST] <nevcairiel> i can fallback from vc1 hwaccel to the MS DMO decoder if need be
[19:31:57 CEST] <nevcairiel> and that works nicely
[19:31:59 CEST] <ubitux> anyway, thx, i'll check if i can reproduce the crash
[19:35:17 CEST] <nevcairiel> nice to see that my vp9 hwaccel works otherwise though
[19:36:27 CEST] <nevcairiel> wm4: unfortunately preventing frame threading with hwaccel is not really doable, since it sets up threading first and only then asks get_format eventually, and falling out of threaded mode is not going to be pretty
[19:38:29 CEST] <wm4> can't it just send all work to a single thread?
[19:38:39 CEST] <wm4> (I have no idea how exactly frame threading works)
[19:39:09 CEST] <nevcairiel> could do it other way around, prevent hwaccel with threading
[19:39:46 CEST] <wm4> wouldn't that break vlc hw decoding?
[19:40:07 CEST] <nevcairiel> look at me caring
[19:40:26 CEST] Action: rcombs stares at nevcairiel 
[19:40:49 CEST] <nevcairiel> apparently it crashes because every thread calls get_format
[19:40:54 CEST] <nevcairiel> i wonder how other decoders do that
[19:40:56 CEST] Action: nevcairiel checks
[19:44:48 CEST] <Compn> did someone say binary codec loader ?
[19:44:54 CEST] <Compn> ms dmo...
[19:46:11 CEST] <BBB> nevcairiel: h264 disallows threads and hwaccel
[19:46:17 CEST] <BBB> nevcairiel: you need to add such a check for vp9 also
[19:46:21 CEST] <BBB> but it works! nice
[19:46:24 CEST] <BBB> congrats
[19:46:25 CEST] <nevcairiel> BBB: you would be surprised to know the opposite is true
[19:46:25 CEST] <BBB> very cool
[19:46:31 CEST] <BBB> ?????
[19:46:34 CEST] <nevcairiel> it does not disallow it
[19:46:34 CEST] <BBB> gotta be kidding me
[19:46:35 CEST] <BBB> really?
[19:46:49 CEST] <BBB> I would just disallow it
[19:46:51 CEST] <BBB> but who am I
[19:46:56 CEST] <nevcairiel> someone hacked it in a couple years ago
[19:46:58 CEST] <BBB> I would swear it used to disallow it at some point
[19:47:01 CEST] <nevcairiel> and it causes a bunch of issues
[19:49:08 CEST] <wm4> all these obscure half-working features that cause trouble for everyone are awesome
[19:49:51 CEST] <nevcairiel> last time i talked abour removing them a couple devs got all outraged
[19:50:23 CEST] <Compn> slice threading ?
[19:50:27 CEST] Action: Compn runs
[19:51:02 CEST] <nevcairiel> so.. is get_format really supposed to be called everytime the size changes?
[19:51:25 CEST] <nevcairiel> i dont think all other codecs do that
[19:56:21 CEST] <wm4> well, you may need to reinit the hwaccel, right?
[19:59:02 CEST] <nevcairiel> i'll just forget about the threading issue and propose a patch to disable the combination at a later time
[19:59:16 CEST] <nevcairiel> or just do it locally in vp9 because EBROKEN
[20:03:26 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:c37d2cd01cd6: avformat/vag: fix demuxing stereo files
[20:03:56 CEST] <BBB> well the threading is initialized somewhere else
[20:04:09 CEST] <BBB> maybe a cap so a codec can indicate if it supports mt+hwaccel at the same time
[20:04:14 CEST] <BBB> and only set that in h264
[20:08:37 CEST] <nevcairiel> ah, as expected, the real crash is in the intel driver
[20:08:40 CEST] <nevcairiel> with mt
[20:08:56 CEST] <nevcairiel> i can live with that, it does weird things with the other codecs as well
[20:09:22 CEST] <wm4> I can't really comprehend how hwaccel with threading works at all
[20:09:47 CEST] <nevcairiel> it just ensures that no more than one decoder thread runs at a time
[20:10:00 CEST] <nevcairiel> and that part is fine
[20:10:22 CEST] <wm4> certainly it can't run multiple threads, because there's so much shared state that would conflict
[20:10:42 CEST] <BBB> maybe you can report the crash to intel and ask them to fix it
[20:10:43 CEST] <BBB> :-p
[20:10:45 CEST] <nevcairiel> however, the problem starts when the calling code starts using the surface afterwards, which is no logner controlled by avcodec, so  calling code and next decoder thread collide and who knows what happens
[20:11:40 CEST] <nevcairiel> hrm for other weird reasons, running the decoder in mt mode allocates the same surface for the first X frames
[20:11:44 CEST] <nevcairiel> why would it do that o.o
[20:12:46 CEST] <wm4> scary
[20:12:58 CEST] <nevcairiel> thats certainly reason for my crash
[20:13:42 CEST] <rcombs> I can't really comprehend how hwaccel works at all
[20:13:52 CEST] <rcombs> (mostly because I haven't looked very closely)
[20:16:41 CEST] <nevcairiel> ..as if its not actually allocating a new frame on the new threads
[20:16:45 CEST] <nevcairiel> but why the hell would it not
[20:17:09 CEST] <rcombs> seen that libav patch adding qsv transcoding in ffmpeg?
[20:17:17 CEST] <rcombs> it kinda scares me
[20:17:37 CEST] <rcombs> hoping that's just temporary and something more generic replaces it
[20:22:02 CEST] <wm4> the years of cleanup work always have to be preceded by something
[20:23:06 CEST] <BBB> qsv transcoding?
[20:23:12 CEST] <BBB> what is that
[20:23:21 CEST] <JEEB> intel stuff
[20:24:23 CEST] <BtbN> A giant horrible mess, specialy on linux.
[20:25:24 CEST] <rcombs> now with extra dedicated handling in avconv.c
[20:25:44 CEST] <rcombs> (to do no-copy hardware transcode pipelines)
[20:26:16 CEST] <rcombs> Intel wrote a patch like that for their previous hardware transcoding infrastructure, too
[20:26:26 CEST] <rcombs> on top of ffmpeg, like, 0.9 or something
[20:30:10 CEST] <nevcairiel> 99% of the code is contained in a single extra file, so its not too bad imho
[20:39:45 CEST] <nevcairiel> ok its broken because it keeps re-allocating the hwaccel on every thread, because the vp9 decoder actually runs a full init for every frame thread to allocate a few things, no idea how to prevent that from happening
[20:44:58 CEST] <wm4> clearly this is a good enough reason to just disallow threads
[20:45:01 CEST] <wm4> with hwaccel
[20:45:12 CEST] <wm4> I suggest adding a simple check, and let decoder init fail
[20:45:24 CEST] <nevcairiel> init doesnt know if we do hwaccel yet
[20:45:28 CEST] <wm4> so if get_format returns a hwaccel and there are multiple threads -> error
[20:45:44 CEST] <nevcairiel> but yeah could throw it in get_format checks
[20:49:47 CEST] <nevcairiel> https://github.com/Nevcairiel/FFmpeg/commit/a8d8ade7f4bbf0ade12e619768a8bed538c26684
[20:49:50 CEST] <nevcairiel> this should already do it
[20:50:23 CEST] <wm4> yeah
[20:50:37 CEST] <wm4> but vlc will be mad
[20:51:25 CEST] <nevcairiel> the change in itself is not perfect because it still calls get_format first
[20:51:39 CEST] <nevcairiel> but its the cleanest position to put it
[20:54:05 CEST] <fritsch> nevcairiel: if you see the code I posted before
[20:54:13 CEST] <fritsch> nevcairiel: you see the work around for the getFormat call
[20:54:18 CEST] <fritsch> if I see that correctly
[20:54:54 CEST] <fritsch> mmh, VC1 only
[20:54:59 CEST] <fritsch> i think we did not test VP9 :-)
[20:55:02 CEST] <fritsch> might be the same issue
[21:03:00 CEST] <cone-569> ffmpeg 03Derek Buitenhuis 07master:516d34de424f: mpegts: Make the pat_period a double
[21:03:01 CEST] <cone-569> ffmpeg 03Derek Buitenhuis 07master:4ffdba2418ab: mpegts: Make the sdt_period a double
[21:30:46 CEST] <nevcairiel> wm4: i sent the hwaccel threading patch as a rfc
[21:32:26 CEST] <wm4> cue to drama
[21:33:44 CEST] <wm4> ah, ffmpeg-devel only
[21:44:40 CEST] <nevcairiel> iirc reimar was one of the local devs that complained last time
[21:44:46 CEST] <nevcairiel> lets see if someone is still alive that cares
[22:37:23 CEST] <cone-569> ffmpeg 03Marton Balint 07release/2.8:e0e28dad9092: concatdec: fix file_start_time calculation regression
[22:53:53 CEST] <nevcairiel> BBB: majority of fate-vp9 also passes with the hwaccel, just some special ones like resizing frames dont work .. thats probably going to be annoying to support, too
[22:54:11 CEST] <BBB> its part of profile 0, so it should work
[22:54:18 CEST] <BBB> you may have to do some special reinitialization
[22:54:31 CEST] <BBB> is resize the only one that doesnt work? or is there more?
[22:54:44 CEST] <nevcairiel> yeah it needs handling on the api user side, as right now any size change throws away everything
[22:55:00 CEST] <BBB> in your code, you mean?
[22:55:05 CEST] <BBB> right, you shouldnt do that
[22:55:08 CEST] <BBB> you need to keep refs
[22:55:10 CEST] <BBB> thats important
[22:55:14 CEST] <wm4> a resize should cause get_format to be called, to reinit the decoder
[22:55:20 CEST] <wm4> wait what
[22:55:25 CEST] <wm4> keep refs on resizes?
[22:55:28 CEST] <BBB> yes
[22:55:33 CEST] <BBB> vp9 includes scaling in profile 0
[22:55:33 CEST] <wm4> that's fucking trippy
[22:55:33 CEST] <nevcairiel> vp9 specifically allows refs with different sizes
[22:55:35 CEST] <BBB> like mpeg4
[22:55:43 CEST] <BBB> wm4: tell that to the dude that added it (not me!)
[22:55:48 CEST] <wm4> lol
[22:56:00 CEST] <wm4> anyway, I don't think get_format implies flushing, or does it?
[22:56:02 CEST] <nevcairiel> the dxva2 spec even specifies which scaling algorithm the hardware should use
[22:56:28 CEST] <nevcairiel> there is however one problem to the entire deal
[22:56:35 CEST] <BBB> I feel that scaling in vp9 is like mbaff in h264
[22:56:42 CEST] <BBB> Im not sure itll re-appear in vp10
[22:56:42 CEST] <nevcairiel> dxva2 at least has to create all surfaces up front and init the encoder with a list of said surfaces
[22:56:53 CEST] <nevcairiel> decoder*
[22:57:12 CEST] <nevcairiel> so.. i have to re-create the decoder with the new sized surfaces, but somehow keep references
[22:57:13 CEST] <wm4> this preallocation stuff is annoying
[22:57:23 CEST] <nevcairiel> i could try to be creative and copy the old surfaces onto the new one or something
[22:57:28 CEST] <nevcairiel> but its not going to be pretty
[22:57:45 CEST] <nevcairiel> but yes BBB, vp-05-resize is the only fate test that fails
[22:57:53 CEST] <nevcairiel> and of course all non-profile0 tests dont use the hwaccel
[22:57:54 CEST] <BBB> congrats
[22:58:00 CEST] <wm4> do these references really have to be part of the preallocated surface list?
[22:58:01 CEST] <BBB> yeah thats ok
[22:58:26 CEST] <nevcairiel> wm4: i have no idea, but I would assume it just barfs otherwise
[22:58:49 CEST] <nevcairiel> not sure this feature is worth giving me a headache right now though
[22:58:58 CEST] <BBB> hehehe
[22:59:04 CEST] <wm4> do you know on resize if or which frames need to be "kept"?
[22:59:17 CEST] <BBB> I probably spend >50% of total ffvp9 time (simd not included) on scaling
[22:59:19 CEST] <BBB> wm4: all
[22:59:29 CEST] <wm4> nasty, then
[22:59:29 CEST] <BBB> wm4: sclaing is completely unrelated to ref frame management
[22:59:32 CEST] <nevcairiel> so the answer is, you dont
[22:59:34 CEST] <BBB> so all refs stay alive on a resize
[22:59:46 CEST] <BBB> you dont scale the refs though; scaling happens in mc
[22:59:52 CEST] <BBB> (Im serious)
[22:59:54 CEST] <wm4> how does thw sw decoder handle it??
[22:59:54 CEST] <nevcairiel> yeah i understood that part
[23:00:01 CEST] <BBB> wm4: you scale in mc
[23:00:06 CEST] <BBB> in the per-block decoding loop
[23:00:10 CEST] <BBB> Im serious
[23:00:38 CEST] <wm4> I mean, how does it handle the surfaces?
[23:00:56 CEST] <nevcairiel> software doesnt really care
[23:01:12 CEST] <nevcairiel> it just creates a new frame pool, and the old frames get deleted as soon as they are unref'ed
[23:01:26 CEST] <wm4> uh, ok
[23:01:56 CEST] <nevcairiel> the dxva2 spec mentions that knowing the maximum size would be super as i could pre-alloc the frames then and just draw small frames on big surfaces
[23:02:04 CEST] <nevcairiel> but really, when do you know that
[23:02:19 CEST] <wm4> lol
[23:02:34 CEST] <wm4> this part of vp9 is really not sane
[23:02:46 CEST] <wm4> being too clever about obscure things like midstream resizing
[23:02:57 CEST] <nevcairiel> I might try to implement that in my own code and see how it works, and maybe if I feel really crazy backport to ffmpeg_dxva2.c
[23:02:59 CEST] <BBB> thats easy to say as an engineer writing decoders
[23:03:10 CEST] <wm4> BBB: so can every mc reference a scaled part of another frame?
[23:03:13 CEST] <BBB> you should see the sparkles in the eyes of users, when they hear this is part of the base codec
[23:03:24 CEST] <nevcairiel> why would users care
[23:03:31 CEST] <nevcairiel> how do you even feed that to vpxenc
[23:03:31 CEST] <BBB> wm4: if the ref size != my size, the mc automatically scales
[23:03:40 CEST] <BBB> I dont think vpxenc supports it
[23:03:46 CEST] <BBB> theres just test scripts
[23:03:50 CEST] <nevcairiel> so, no real world samples
[23:03:53 CEST] <wm4> BBB: fucking hell, so it's active only when frame sizes change?
[23:03:54 CEST] <nevcairiel> i'm not going to do this then!
[23:03:56 CEST] <BBB> correct
[23:04:00 CEST] <BBB> wm4: yes
[23:04:06 CEST] <BBB> nevcairiel: good idea :-p
[23:04:08 CEST] Action: wm4 shakes head
[23:04:25 CEST] <BBB> oh you want it to work on zooms?
[23:04:27 CEST] <BBB> like in mpeg4?
[23:04:29 CEST] <nevcairiel> going to clean up some parts in the patch
[23:04:47 CEST] <nevcairiel> there are one or two ugly parts in vp9.c that i had to do though :(
[23:05:03 CEST] <BBB> Ill look
[23:05:10 CEST] <BBB> if I hate it, Ill poke you
[23:05:14 CEST] <nevcairiel> https://github.com/Nevcairiel/FFmpeg/commit/35a617787638e82f99dda87a590ec4ffb940be65#diff-73b2f06f81e7f6cdc34af712153ea2f2L581
[23:05:22 CEST] <nevcairiel> that block in particular was super annoying
[23:05:36 CEST] <nevcairiel> you check AVFrame->format :(
[23:06:30 CEST] <BBB> do you need the segmentation map in hw?
[23:06:35 CEST] <nevcairiel> no
[23:06:41 CEST] <nevcairiel> just some of the metadata
[23:06:57 CEST] <nevcairiel> all that is in vp9.h in master now is enough
[23:07:04 CEST] <BBB> so cant you skip allocating that then?
[23:07:12 CEST] <BBB> in vp9_alloc_frame
[23:07:17 CEST] <nevcairiel> i suppose
[23:07:28 CEST] <nevcairiel> is that big enough to care?
[23:08:19 CEST] <nevcairiel> i can also skip decoding the compressed frame headers, nothing of that is needed
[23:08:23 CEST] <nevcairiel> but meh optimizations :)
[23:09:10 CEST] <BBB> lol
[23:09:21 CEST] <BBB> I mean, I would, because why not
[23:10:35 CEST] <BBB> also nice gotos
[23:10:48 CEST] <BBB> can you unindent the #define?
[23:11:28 CEST] <nevcairiel> hwaccel_max? sure
[23:19:23 CEST] <TD-Linux> the main use case for the scalable reference frames is video conferencing, where you want to react to a change in available bandwidth by changing res
[23:20:31 CEST] <nevcairiel> cant you just do what everyone does and send a new intra and be done with it
[23:21:08 CEST] <TD-Linux> intra frames are really expensive and terrible
[23:21:44 CEST] <TD-Linux> however, doing something like limiting the # of references that are saved in a resolution change to 1 would have been sane
[23:32:57 CEST] <nevcairiel> i could make the hwaccel support decreasing the size without much trouble, as i can keep the same surfaces then
[23:33:01 CEST] <nevcairiel> increasing is another matter
[23:35:23 CEST] <nevcairiel> i suppose if you are dealing with video conferencing, you might know the maximum size beforehand and could setup the decoder with that info
[23:37:53 CEST] <TD-Linux> yeah that's how I would do it, to avoid runtime allocation. but I guess vp9 doesn't really have a way to signal that
[23:38:57 CEST] <TD-Linux> though, I guess you can't have the same src and dest buffer for scaling, so maybe not
[23:40:26 CEST] <nevcairiel> if the bitstream actually included that max size, that would've been nice
[23:53:18 CEST] <cone-569> ffmpeg 03Rostislav Pehlivanov 07master:7303962f1467: aacenc_ltp: adjust and speed up autocorrelation calculations
[00:00:00 CEST] --- Sun Oct 18 2015