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

[burek]

[00:00:04 CEST] <Daemon404> michaelni, if im not around mail me them, or putthem on github or something
[00:01:11 CEST] <michaelni> ok, i probably wont have time tomorrow for testing but ill try to test more after that
[00:01:34 CEST] <Daemon404> its not going to be ready to merge tomorrow lol.
[00:02:04 CEST] <Daemon404> i was aiming for sunday or monday next week.
[00:02:14 CEST] Action: michaelni is afraid that it gets pushed without more testing, i think there are quite a few issues left in it
[00:02:43 CEST] <Daemon404> i need to put it over git master before anything else
[00:03:40 CEST] <Daemon404> then ti can be tested, but at some point it should be merged
[00:03:51 CEST] Action: Daemon404 is not a fan of infinite testing
[00:04:09 CEST] <Daemon404> and im not sure users will spend much time testing non-master
[00:06:57 CEST] <michaelni> btw was the assertion failure fixed ? 
[00:07:07 CEST] <Daemon404> no its on my todo
[00:07:13 CEST] <michaelni> ahh k
[00:07:15 CEST] <Daemon404> see: [22:56] <@Daemon404> im not doing any fixes today though, im beat.
[00:54:40 CEST] <Timothy_Gu> anybody actually at MS Build?
[00:58:23 CEST] <kierank> some vlc guys are
[00:58:29 CEST] <kierank> so j-b I guess
[02:07:43 CEST] <kierank> dammit work assembly
[02:09:40 CEST] <j-b> Timothy_Gu: I am there, yes.
[02:14:36 CEST] <kierank> Gramner: have I got the semantics of palignr wrong?
[02:14:37 CEST] <kierank> palignr  m2, m0, m4, 6
[02:14:53 CEST] <kierank> it does m4 concated witht m0
[02:14:57 CEST] <kierank> shifts 6 bytes right
[02:14:58 CEST] <kierank> and stores in m2
[02:15:18 CEST] <kierank> it doesn't do the same as the equivalent movu from memory
[02:18:44 CEST] <kierank> i.e
[02:18:51 CEST] <kierank>     mova   m0, [r0]
[02:18:51 CEST] <kierank>     mova   m4, [r0+mmsize]
[02:18:51 CEST] <kierank>     palignr  m2, m0, m4, 6
[02:19:01 CEST] <kierank> I expect m2 to be the same as movu [r0+10]
[02:31:36 CEST] <BBB> kierank: I believe its the other way around
[02:31:45 CEST] <BBB> kierank: so palignr m2, m4, m0, 6
[02:31:57 CEST] <BBB> it makes more sense in the inverse at&t syntax
[02:32:24 CEST] <kierank> m2, m4, m0, 10 works for me
[02:32:29 CEST] <kierank> which I don't understand at all
[02:32:45 CEST] <kierank> but thanks
[02:32:57 CEST] <BBB> oh, maybe it was 10, yes
[02:33:07 CEST] <BBB> anyway, yes palignr is very confusing
[02:33:12 CEST] <BBB> I always get it wrong the first time
[02:33:19 CEST] <BBB> which isw hy I dont use it very much :-p
[02:41:27 CEST] <kierank> I don't understand why the c is of a similar speed still though
[02:41:30 CEST] <kierank> perhaps a problem for tomorrow
[02:44:45 CEST] <kierank> hmm perf says all the time is spent in vpalig
[02:46:36 CEST] <jamrial> what's your cpu? palignr is slow in some arches and relatively fast in others
[02:46:47 CEST] <kierank> haswell
[02:47:02 CEST] <kierank> on my sandy bridge laptop the function is about twice as fast
[02:47:09 CEST] <kierank> on haswell it's about the same as the c
[02:47:23 CEST] <jamrial> yeah, palignr is slower on haswell than sandy/ivy
[02:47:39 CEST] <jamrial> shouldn't be that bad, though
[02:48:59 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/n5KCHRE5/
[02:49:02 CEST] <kierank> looks like that
[02:58:08 CEST] <kierank> a shuffle and blend might be better
[02:58:15 CEST] <kierank> but I will find out at a sane hour
[03:02:57 CEST] <rcombs> is that a CPU instruction or a dance move
[03:14:22 CEST] <kierank> probably better to do a single shuffle for luma and chroma and mask after
[03:17:45 CEST] <jamrial> why not just do an unaligned load instead of aligned load + palignr?
[03:18:32 CEST] <jamrial> alternatively shift + or to emulate palignr
[04:21:37 CEST] <BBB> emulate palignr is terrible, but movu should be ok, yes
[05:24:34 CEST] <Daemon404> oh good, im sure no trolls will respond to the codecpar mail with a link to a WIP tree on the ML
[05:24:38 CEST] <Daemon404> especially not carl
[05:24:58 CEST] <Daemon404> this cant possibly backfire.
[08:11:08 CEST] <wm4> lol 48h wait?
[08:11:16 CEST] <wm4> we've waited for weeks
[08:11:38 CEST] <wm4> at this rate it'll never get merged
[09:02:33 CEST] <durandal_1707> no need to wait
[09:45:40 CEST] <Gramner> kierank: you should store constants in registers instead of using memory operands in every instruction. it will make things faster on many cpu:s and reduces code size. weird that palignr is slow on haswell though, I know it's garbage on some older amd µarchs but it has the same latency/throughput as any other shuffle instruction on haswell
[09:45:50 CEST] <Gramner> 1/1
[09:46:26 CEST] <kierank> It doesn't seem to be palignr actually because when I removed it, the function was slow still
[09:47:10 CEST] <Gramner> start with avoiding memory operands everywhere then and see what happens
[09:48:09 CEST] <Gramner> modern intel µarchs is generall ok with tons of memory loads though, but some other µarchs not so much.
[10:16:06 CEST] <Gramner> here's a more sensible palignr visualization btw https://i.imgur.com/35VrZ8C.png
[10:38:50 CEST] <kierank> Gramner: putting the masks in registers seems to make it faster but loading too much stuff makes it slow
[10:39:22 CEST] <kierank> oh wait
[10:39:23 CEST] <kierank> ignore me
[10:40:00 CEST] <funman> /ignore kierank
[10:40:33 CEST] <Gramner> also, that functions only does one line right? changing it to process one frame at a time would make stuff faster since you'd avoid the overhead of the function call + function prologue for each input line
[10:41:25 CEST] <kierank> that's not trivial because of the edge cases
[10:41:40 CEST] <kierank> and also because I process 3 v210 "blocks" at a time currently
[10:42:51 CEST] <kierank> Gramner: http://pastebin.com/qPk9rTRX
[10:43:00 CEST] <kierank> (lol gone comic sans)
[10:43:40 CEST] <kierank> the multiplies are permutations of each other but not simple ones
[10:45:37 CEST] <Gramner> luma/chroma masks seems indentical except inverted. you could simply use only the chroma mask and go with pandn instead of pand for luma (this is what x264 does iirc)
[10:45:56 CEST] <kierank> they aren't quite inverted actually
[10:49:34 CEST] <kierank> technically the x264 code is wrong
[10:50:31 CEST] <Gramner> it is?
[10:51:30 CEST] <kierank> the masks aren't the exact inverse of each other
[10:51:47 CEST] <kierank> because you need to mask out the two unused bits per uint32_t for both components
[10:52:06 CEST] <kierank> those bits are undefined so they could be set and then break your pmulhrsw
[10:53:37 CEST] <Gramner> the checkasm test in x264 uses completely random data as input, and it passes
[10:54:07 CEST] <Gramner> no bits in the input that are explicitly set to zero beforehand
[10:55:39 CEST] <kierank> I see
[10:55:39 CEST] <Gramner> those bits are shuffled out by pshufb i think
[11:01:42 CEST] <kierank> no much change still
[11:05:10 CEST] <Gramner> the code is quite shuffle-heavy (and unavoidably so). sandy/ivy has 3 scalar execution units and 2 shuffle ones. haswell has 4 scalar and 1 shuffle
[11:05:31 CEST] <Gramner> it's going to perform worse compared to c on haswell than on sandy/ivy
[11:05:52 CEST] <Gramner> i think it should still be faster than scalar though
[11:05:59 CEST] <Gramner> what are the numbers?
[11:07:18 CEST] <Gramner> I don't know why Intel decidec to murder shuffle performance on haswell. and it's the same on skylake
[11:15:11 CEST] <dinux5> What is "validating a bitstream" ?
[11:19:33 CEST] <Gramner> kierank: oh, and there's no point in having an "aligned" avx version since movdqu when used on aligned data has the same performance as movdqa on all cpus with avx. might even be that case with ssse3 but I don't know for sure
[11:21:47 CEST] <kierank> asm 56991880 decicycles in abcd,    2048 runs,      0 skips
[11:21:48 CEST] <kierank> c 52278297 decicycles in abcd,    2048 runs,      0 skips
[11:24:09 CEST] <Gramner> with what width (e.g. how many loop iterations in the asm)?
[11:25:13 CEST] <kierank> that's per frame
[11:32:35 CEST] <ubitux> kierank: isn't the c simdified by gcc?
[11:33:50 CEST] <ubitux> mmh apparently not
[11:41:29 CEST] <Gramner> weird that it's so slow compared to c. compare it to the v210 asm in x264 which is quite similar (load, pand, pshufb, pmulhrsw)
[11:41:34 CEST] <Gramner> plane_copy_deinterleave_v210_c: 20550
[11:41:34 CEST] <Gramner> plane_copy_deinterleave_v210_ssse3: 4672
[11:41:34 CEST] <Gramner> plane_copy_deinterleave_v210_avx2: 3373
[11:42:37 CEST] <kierank> http://paste.ubuntu.com/15575417/
[11:42:46 CEST] <kierank> on top of https://github.com/kierank/ffmpeg-sdi
[11:43:04 CEST] <kierank> yes it's so slow for some reason
[11:43:30 CEST] <kierank> ./ffmpeg_g -f v210 -s 1920x1080 -i /dev/zero -f rawvideo -y /dev/null
[11:47:18 CEST] <ubitux> you should try something different than zero, maybe it's affecting the prediction somehow
[11:47:59 CEST] <ubitux> there is no branching though
[11:54:55 CEST] <Gramner> put the timer around just the function pointer call to get rid of the overhead/noise of all the other code
[12:00:35 CEST] <kierank> asm   56479 decicycles in abcd,    2047 runs,      1 skips
[12:00:49 CEST] <kierank> actually
[12:00:51 CEST] <kierank> asm   50214 decicycles in abcd,   65526 runs,     10 skips
[12:01:01 CEST] <kierank> c   48170 decicycles in abcd,   65524 runs,     12 skips
[12:51:58 CEST] <kierank> There must be something I can do to make it faster
[12:58:33 CEST] <cone-543> ffmpeg 03wm4 07master:f099cb2f8a51: lavu: improve documentation of some AVFrame functions
[12:58:33 CEST] <cone-543> ffmpeg 03wm4 07master:a5f5b8b96a97: lavc: factor apply_param_change() AV_EF_EXPLODE handling
[13:24:12 CEST] <Gramner> kierank: the asm is faster for me on haswell (pulled from your github + applied the patch you linked).
[13:24:16 CEST] <Gramner> 53030040 decicycles in abcd, 256 runs, 0 skips (c)
[13:24:16 CEST] <Gramner> 36980280 decicycles in abcd, 2048 runs, 0 skips (asm)
[13:24:54 CEST] <Gramner> oh, copied the 256 runs for c, but it's consistently the same anyway
[13:29:41 CEST] <kierank> Gramner: what command are you using
[13:29:52 CEST] <kierank> I guess I could be getting burnt by cpu throttling or something
[13:30:10 CEST] <Gramner> the same as you used
[13:32:00 CEST] <kierank> very strange
[13:32:11 CEST] <kierank> I am on Intel(R) Xeon(R) CPU E3-1265L v3 @ 2.50GHz
[13:32:45 CEST] <Gramner> "Genuine Intel(R) CPU 0000 @ 2.80GHz" <- them ES naming schemes
[13:38:13 CEST] <kierank> Gramner: so strange
[13:38:44 CEST] <kierank> but thanks
[13:39:59 CEST] <Gramner> 50k vs 33k cycles with just the function pointer call
[13:40:18 CEST] <Gramner> decicycles*
[13:46:16 CEST] <Gramner> or did the compiler you used auto-vectorize the c?
[13:46:25 CEST] <Gramner> i have a somewhat older gcc on this machine
[13:47:23 CEST] <Gramner> 4.8.4 to be precise
[13:47:53 CEST] <kierank> not vectorised on my machine
[13:48:32 CEST] <kierank> ah is it running the uyvy code?
[13:48:49 CEST] <kierank> i.e is the output uyvy42210?
[13:49:01 CEST] <kierank> it might be using the planar code
[13:50:16 CEST] <kierank> hmm on another haswell I can replicate your results
[13:50:17 CEST] <kierank> wtf 
[13:51:26 CEST] <Gramner> oh wait didn't you have some super weird performance issues before with one of your machines? i vaguely remember discussing that. it's not _that_ machine is it?
[13:52:51 CEST] <kierank> Ah, no that was a machine which had two PSUs and if one of them was disconnected, the CPU silently downclocked unbeknownst to the OS
[13:53:15 CEST] <Gramner> ah ok
[13:56:21 CEST] <Gramner> you didn't accidentally make some change in the asm on the machine that it's slow on compared to the other one?
[13:59:56 CEST] <kierank> I will try with a clean clean build
[14:03:23 CEST] <kierank> let me try on a xeon e5
[14:04:13 CEST] <Gramner> you can get rid of half of the pmulhrsw instructions btw if you do the or before
[14:06:07 CEST] <kierank> yeah faster on the e5 haswell as well
[14:07:47 CEST] <kierank> hmm that's a good idea
[14:40:48 CEST] <Gramner> kierank: maybe something like this (untested if it's actually correct, but the concept of it) http://pastebin.com/th4twbq1
[14:41:18 CEST] <kierank> thanks, was going to write that later
[14:59:19 CEST] <cbsrobot> kierank: on Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
[14:59:31 CEST] <cbsrobot> 25354510 decicycles in abcd,    4096 runs,      0 skips (asm)
[14:59:43 CEST] <cbsrobot> 49719353 decicycles in abcd,    4096 runs,      0 skips (c)
[14:59:53 CEST] <kierank> thanks, something odd about my e3 haswell it seems
[15:00:03 CEST] <Gramner> that's ivy bridge though I assume
[15:00:09 CEST] <kierank> yes
[15:53:07 CEST] Action: ubitux likes the cbz/cbnz/tbz/tbnz instructions
[17:08:20 CEST] <Daemon404> michaelni, 
[17:08:20 CEST] <Daemon404> [concat @ 0x3b023c0] Unsafe file name '/home/daemon404/dev/f/codecpar/10secMov.mov'
[17:08:23 CEST] <Daemon404> concatfile.txt: Operation not permitted
[17:08:26 CEST] <Daemon404> ^ git head
[17:08:51 CEST] <Daemon404> i suppose it mus tbe relative or something
[17:09:35 CEST] <Daemon404> seems so.
[17:09:36 CEST] <Daemon404> nvm
[17:09:36 CEST] <durandal_1707> why you use concat?
[17:10:23 CEST] <Daemon404> because michaelni reported a regression
[17:10:30 CEST] <Daemon404> i would not use it myself.
[17:14:26 CEST] <Daemon404> nevcairiel, why was it you had concat.c listed at one point on the etherpad?
[17:14:38 CEST] <Daemon404> nothing changed in it
[17:14:41 CEST] <Daemon404> seems bsf related
[17:14:56 CEST] <nevcairiel> the bsf stuff seemed broken in it and failed in tests
[17:15:14 CEST] <Daemon404> i left it sitll using st->codec
[17:15:14 CEST] <nevcairiel> how it uses bsf seems questionable either way
[17:15:26 CEST] <Daemon404> bsf in utils.c uses the deprecated api
[17:15:36 CEST] <Daemon404> where does it?
[17:15:48 CEST] <Daemon404> concat.c looks incredibly trivial
[17:15:55 CEST] <nevcairiel> i wonder if it wont stop working if we change ffmpeg.c to codecpar
[17:16:04 CEST] <nevcairiel> because st->codec is literally empty then
[17:16:17 CEST] <Daemon404> one solution is to merge the new bsf api first.
[17:17:04 CEST] <nevcairiel> concat is a demuxer, so you could use the internal avctx temporarily
[17:17:11 CEST] <Daemon404> oh silly me
[17:17:12 CEST] <Daemon404> im retarded
[17:17:17 CEST] <Daemon404> i was lookign at concat.c
[17:17:19 CEST] <Daemon404> not concatdec.c
[17:17:22 CEST] <Daemon404> the problem is obvious now.
[17:17:39 CEST] <Daemon404> internal avctx is not good enough for the bistream filters
[17:17:42 CEST] <Daemon404> thats why i didnt change utils.c
[17:17:50 CEST] <Daemon404> waiting on the new bsf api and wil lchange it then
[17:19:39 CEST] <JEEB> :)
[17:20:43 CEST] <Daemon404> yeah switching back from internal avctx to st->codec fixes it.
[17:20:56 CEST] <Daemon404> nevcairiel, are you ok with waiting for the new api to fix the uses?
[17:21:00 CEST] <Daemon404> seems like teh sanest thing to do
[17:21:32 CEST] <ubitux> Daemon404: yes, relative path or use the -safe option
[17:21:34 CEST] <nevcairiel> probably fine
[17:21:50 CEST] <Daemon404> ill switch tee.c back too
[17:22:28 CEST] <Daemon404> ubitux, it worked when i gave it absolute path that had a file in the same dir as CWD
[17:22:33 CEST] <Daemon404> hence my confusio
[17:22:34 CEST] <Daemon404> n
[17:25:05 CEST] Action: Daemon404 runs fate now with assert-level=2
[17:25:23 CEST] <Daemon404> it's a shame ffmpeg doesnt have somethign similar to libav's oracle
[17:25:26 CEST] <Daemon404> would be useful 
[17:27:17 CEST] <wm4> this fork bullshit is just a huge load of bullshit
[17:27:31 CEST] <Daemon404> settle down now
[17:28:46 CEST] <Daemon404> it's too early in the day for flames, for me
[17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:11b4acab8b67: swscale/arm/yuv2rgb: remove 32bit code path
[17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:466e209e6efb: swscale/arm/yuv2rgb: fix comments in load_args_yuv422p
[17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:b3ea901945c8: swscale/arm/yuv2rgb: factorize lsl in load_args_yuv422p
[17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:2aec59c07cec: swscale/arm/yuv2rgb: remove unused store of dst + linesize in load_args_yuv422p
[17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:0649fe0fae96: swscale/arm/yuv2rgb: factorize lsl in load_args_yuv420p
[17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:0286b56f2fa5: swscale/arm/yuv2rgb: factorize lsl in load_args_nvx
[17:29:22 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:562653b7317d: swscale/arm/yuv2rgb: macro-ify
[17:29:23 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:ff4885facee0: swscale/arm/yuv2rgb: rename {process_1l,process_2l,compute}_16px{,_internal} macros
[17:29:24 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:339668301e45: swscale/arm/yuv2rgb: re-order compute_rgba macro arguments
[17:29:25 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:5629361cc24d: swscale/arm/yuv2rgb: save a few instructions by processing the luma line interleaved
[17:29:26 CEST] <cone-283> ffmpeg 03Matthieu Bouron 07master:58994d7bca27: swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part
[17:29:54 CEST] <Daemon404> i should remember do disable docs more often
[17:30:01 CEST] <Daemon404> it's the longest job of the build process
[17:32:26 CEST] <Daemon404> is there something that ffmpeg started doing differently for its cli lately?
[17:32:36 CEST] <Daemon404> whenever ffmpeg crashes or asserts i have to reset my terminal
[17:32:41 CEST] <Daemon404> or characters i type are invisible
[17:33:09 CEST] <nevcairiel> someone tried to "improve" it, probably got worse in the process, you know how it does
[17:33:11 CEST] <nevcairiel> goes*
[17:33:16 CEST] <cone-283> ffmpeg 03Clément BSsch 07master:eadaef2a63fe: sws/aarch64: disable ff_hscale_8_to_15_neon temporarly
[17:33:36 CEST] <nevcairiel> someone argued that it cant be fixed in 100% of the cases anyway, so lets just leave it as broken as possible
[17:34:00 CEST] <Daemon404> oh good.
[17:34:09 CEST] <Daemon404> and yeah it never used to do this.
[17:36:19 CEST] <cone-283> ffmpeg 03Aaron Boxer 07master:b6b4b0a65e02: avcodec/j2kenc: Add attribution to OpenJPEG project:
[17:36:28 CEST] <BBB> why would cmp             xd, r6m give me error: label or instruction expected at start of line?
[17:42:07 CEST] <BBB> whats wrong with the fork tis time?
[17:45:07 CEST] <omerjerk> hey can anyone help me with some doubt regarding ALS decoder ?
[17:45:23 CEST] <omerjerk> I'm almost done with the qualification task 
[17:45:48 CEST] <omerjerk> Just stuck a bit at final reconstruction of the floating point number. 
[17:46:26 CEST] <omerjerk> So, has anyone dealt with ALS before here ? :)
[17:46:30 CEST] <omerjerk> thanks in advance. 
[17:51:49 CEST] <michaelni> Daemon404, nicolas posted some shell magic to fix the term messups (and i would prefer it wasnt needed but i think no solution was found that everyone liked)
[17:52:39 CEST] <wm4> I don't understand why ffmpeg messes with the terminal at all
[17:54:03 CEST] <Daemon404> it probably has something to do with printing status
[17:54:18 CEST] <Daemon404> michaelni, where can i find this?
[17:55:03 CEST] <michaelni> its for handling things like q uit , chaning verbosity, dislpaying qp histograms, sending messages to filters, dumping packets as hex on a keypress cycle through debug modes ... (just press ?  to see a list of keys for ffmpeg while it runs)
[17:56:17 CEST] <michaelni> i have to find the mail but for bash it was: bash_tty_mode=$(stty -g) \n PROMPT_COMMAND='stty $bash_tty_mode'
[17:56:37 CEST] <Daemon404> all right
[17:59:40 CEST] <michaelni> not sure theres a mail where its all summarized, there are multiple mails from nicolas where taks about the issue
[18:00:15 CEST] <michaelni> easy to find when searching for something like stty in the body and nicolas in from
[18:00:54 CEST] <Daemon404> is tehre an easy way to match a codec id to a name? 
[18:01:01 CEST] <Daemon404> find_decoder and find_encoder fail with 100359
[18:01:50 CEST] <wm4> gdb, print (AVCodecID)100359
[18:01:59 CEST] <Daemon404> ah
[18:01:59 CEST] <michaelni> avcodec_get_name()
[18:02:50 CEST] <Daemon404> bin_data
[18:02:55 CEST] <Daemon404> fun...
[18:08:16 CEST] <durandal_1707> omerjerk: what's problem?
[18:11:20 CEST] <omerjerk> wait, 
[18:11:23 CEST] <omerjerk> posting the question
[18:13:39 CEST] <omerjerk> http://i.imgur.com/T3pQdUI.png
[18:13:56 CEST] <omerjerk> I'm getting confused at the point 11.6.9.3.3.2
[18:14:19 CEST] <omerjerk> I've written rest of the code, which includes decoding of the difference singal.
[18:14:42 CEST] <omerjerk> What I'm not getting is, why do we need to multiply truncated integer to 2^-23
[18:15:03 CEST] <omerjerk> I can't see any code like that in the source code of the reference software. 
[18:16:30 CEST] <omerjerk> Also, I'm maintaining my code here - https://github.com/omerjerk/FFmpeg/commits/float
[18:17:33 CEST] <wm4> that's equivalent to shifting, isn't it
[18:17:52 CEST] <wm4> to bring something like a [0..2^23] range to [-1..1] or whatever?
[18:18:08 CEST] <wm4> well my example is wrong but whatever
[18:18:30 CEST] <omerjerk> aah.
[18:18:32 CEST] <omerjerk> okay.
[18:18:41 CEST] <omerjerk> this makes sense. 
[18:21:35 CEST] Action: Daemon404 stabs mpegts.c
[18:28:12 CEST] <Daemon404> this is so insane
[18:28:18 CEST] <Daemon404> how did this ever work
[18:31:22 CEST] <Gramner> those code segments are the best. things that are clearly wrong but somehow works anyway and ideally breaks everything or makes things worse when they are fixed
[18:32:44 CEST] <Gramner> usually because of 3 other bugs and the combination of those by pure chance makes things work out in the end
[18:33:16 CEST] <Daemon404> seems like this, yes
[18:34:45 CEST] <ethe> wm4: how would you do that? x-((2^23)/2)/(2^23)?
[18:37:44 CEST] <Daemon404> michaelni, ping
[18:38:00 CEST] <Daemon404> is dts supposed to be detected as STREAM_TYPE_PRIVATE_DATA (6)
[18:38:30 CEST] <Daemon404> it's always setting teh coded_id as bin_data. it only worked before because it was allowed to modify it later back to CODEC_ID_NONE
[18:38:33 CEST] <Daemon404> which is all sorts of weird
[18:39:25 CEST] <michaelni> the request_probe system is mandatory for mpeg-ts/ps
[18:39:42 CEST] <michaelni> i dont know of my head what dts sets
[18:39:45 CEST] <Daemon404> trying to figure out how it works
[18:39:56 CEST] <Daemon404> it used to call the parser with avctx->codec_id as NONE, and it happened to work since one of the parser coded ids is always NONE
[18:40:03 CEST] <Daemon404> (it failed to match it as DCA)
[18:40:13 CEST] <Daemon404> im not sure if that is even intended behavior
[18:40:34 CEST] <Daemon404> request_probe is working fine
[18:40:48 CEST] <michaelni> the parsers should only be run over the data after the codec is identified IIRC
[18:40:48 CEST] <Daemon404> it's just the initial call to parser which is triggering that
[18:40:59 CEST] <Daemon404> right
[18:41:10 CEST] <Daemon404> but even in git master/HEAD it calls it twice with CODEC_ID_NONE
[18:41:29 CEST] <Daemon404> which happens to work since parser->coded_id[i] where i > 0 is 0.
[18:41:44 CEST] <michaelni> that sounds like a bug
[18:41:55 CEST] <Daemon404> thats my thinking too.
[18:43:29 CEST] <Daemon404> let me poke it a bit more
[18:45:27 CEST] <Daemon404> i might be mistaken
[18:49:07 CEST] <michaelni> hmm, av_parser_init checks for AV_CODEC_ID_NONE at the top and fails then (noticed as i just wanted to add exactly such code to see what happens if it fails fr NONE)
[18:49:39 CEST] <Daemon404> michaelni, i think i was mistaken about NONE being passed
[18:49:50 CEST] <Daemon404> i did noticed the assert didnt trigger if NONE was passed though
[18:49:53 CEST] <Daemon404> which still seems wrong
[18:51:27 CEST] <Daemon404> i see the problem in codecpar branch, it is unrelated
[18:51:35 CEST] <Daemon404> but probably NONE should still be fixed
[18:52:06 CEST] Action: michaelni is ust trying to add a assert != none in git master
[18:52:27 CEST] <Daemon404> ;)
[19:09:28 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:9f03b85045fd: avcodec/parser: assert that the codec id is not NONE in av_parser_parse2()
[19:43:31 CEST] <Daemon404> just that ac3 regression left right now...
[19:43:44 CEST] <Daemon404> i cant figure out where the hell the ac3 packet timestamps come from
[19:43:46 CEST] <Daemon404> in framecrc
[19:46:12 CEST] <Daemon404> back into the horrible world of muxer timestamp generation...
[19:48:08 CEST] <durandal_1707> from demuxer?
[19:48:21 CEST] <Daemon404> nope
[19:53:03 CEST] <Daemon404> or, it should be
[19:53:09 CEST] <Daemon404> but i cannot find where ac3 packet timestamps are ste
[19:54:26 CEST] <wm4> you could check with ffprobe whether the demuxer sets them
[19:54:39 CEST] <Daemon404> it does
[19:54:52 CEST] <Daemon404> i checked what values av_interleaved_fwrite_frame was gettign from ffmpeg.c
[19:55:10 CEST] <wm4> then the pts is determined by lavf/utils.c by using the frame duration
[19:55:47 CEST] <Daemon404> where
[19:56:19 CEST] <Daemon404> because all the packet durations are correct
[19:56:35 CEST] <Daemon404> but pts/dts is NOPTS/0 for the first N fames post-merge
[19:58:56 CEST] <wm4> I'm not quite sure
[20:00:37 CEST] <Daemon404> i never ever want to look at utils.c timestamps again after this merge
[20:01:28 CEST] <Daemon404> hmm wtf
[20:01:35 CEST] <Daemon404> pkt->pts = -9223372036854775808 pkt->dts = -9223372036854775808
[20:01:35 CEST] <Daemon404> pkt->pts = 9223090561878065151 pkt->dts = 9223090561878065151
[20:01:43 CEST] <Daemon404> at some point this happens in read_frame_internal
[20:01:44 CEST] <JEEB> o_O
[20:01:48 CEST] <wm4> RELATIVE_TS_BASE?
[20:03:20 CEST] <Daemon404> it happens N frames in here
[20:03:23 CEST] <Daemon404> instead of 1 frame in
[20:03:30 CEST] <Daemon404> where it should
[20:03:31 CEST] <Daemon404> hmm.
[20:07:17 CEST] <Daemon404> think i found it maybe
[20:08:12 CEST] <Daemon404> hmm no.
[20:20:52 CEST] <angus> Hey folks
[20:21:02 CEST] <angus> can I get a sanity check here?
[20:21:14 CEST] <angus> https://ffmpeg.org/doxygen/2.8/avio_8c_source.html#l00098
[20:21:30 CEST] <angus> line 239 static struct URLProtocol *url_find_protocol(const char *filename)
[20:22:09 CEST] <angus> how does this funtion work? it seems URLProtocol *up is set to NULL, but never set to anything else
[20:22:55 CEST] <ethe> up is set within the while condition
[20:23:23 CEST] <angus> shouldn't that segfault?
[20:23:45 CEST] <ethe> why would it segfault?
[20:23:59 CEST] <angus>   while (up = ffurl_protocol_next(up)) {
[20:24:13 CEST] <angus>  URLProtocol *ffurl_protocol_next(const URLProtocol *prev)    37 {    38     return prev ? prev->next : first_protocol;    39 }
[20:24:54 CEST] <nevcairiel> seems fine to me?
[20:25:01 CEST] <angus> oh, derp, first_protocol is returned
[20:25:08 CEST] <nevcairiel> thats typical linked list traversal
[20:29:59 CEST] <kierank> Gramner: works, thanks a lot
[20:31:11 CEST] <Gramner> it does? wow, i changed a bunch of stuff without testing it more than just making sure it compiled
[20:36:49 CEST] <kierank> Gramner: oddly it looks right but the md5sum doesn't match
[20:37:31 CEST] <Gramner> might have messed up a value somewhere in one of the constants
[20:38:46 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:1d64a9d9f6e1: fate: Add regression test for Ticket 1239
[20:38:47 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:7615197b6e8b: fate: Test for Ticket4560
[20:38:48 CEST] <cone-283> ffmpeg 03Michael Niedermayer 07master:0de1c1ab869f: fate: add demux test for TS with AC3 (Ticket 4864)
[20:42:53 CEST] <Gramner> kierank: v210_uyvy_chroma_shuf3: db 5, 6,-1,-1, 8, 9, 1,-1,10,11,-1,-1,13,14,-1,-1 <- should be -1, not 1, after 9
[20:43:38 CEST] <kierank> hmm yes
[20:44:10 CEST] <Gramner> does that fix it?
[20:44:19 CEST] <kierank> checking now
[20:44:37 CEST] <kierank> yes
[20:44:47 CEST] <Gramner> cool
[20:47:09 CEST] <Gramner> the multiple masks and multipliers are also just permutations of each other, could just have store one of each and pshufd the permuted ones in the prologue to save some cache. just need to make sure that the permuted ones are placed in registers for 32-bit
[20:48:04 CEST] <kierank> ah I don't care much for 32-bit
[20:48:12 CEST] <durandal_1707> so what speedup you get now?
[20:51:56 CEST] <kierank> twice as fast as c on non-insane machine
[20:53:08 CEST] <kierank> not sure if it's worth upstreaming because it uses a pixel format that doesn't exist in the file world
[21:23:13 CEST] <Daemon404> there... ac3 shit fixed
[21:23:17 CEST] <Daemon404> have i mentioned i hate utils.c lately
[21:25:33 CEST] Action: Daemon404 hates our timestamp code
[21:26:31 CEST] Action: jamrial throws INT64_MINs at Daemon404
[21:26:34 CEST] <wm4> not sure if anyone loves it
[21:27:31 CEST] <Daemon404> its 3:30pm and i havent eaten a single meal today because i was fixing timestamps
[21:27:35 CEST] Action: Daemon404 lives a healthy life
[22:09:45 CEST] <cone-283> ffmpeg 03Ronald S. Bultje 07master:98038e2ee0c4: swscale: fix bt709 yuv2rgb coefficients.
[22:09:46 CEST] <cone-283> ffmpeg 03Ronald S. Bultje 07master:b3eda69490db: swscale: add bt2020 yuv2rgb coefficients.
[23:44:08 CEST] <michaelni> Daemon404, make fate on your codecpar branch fails fate-aac-latm_000000001180bc60, [fate-aac-latm_stereo_to_51, fate-vcr2
[23:49:47 CEST] <michaelni> these passed yesterday
[00:00:00 CEST] --- Sat Apr  2 2016