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

[burek]

[00:00:46 CEST] <jamrial> am i missing something, or is https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixfmt.h#L470 superfluous judging by the enum above?
[00:02:20 CEST] <rcombs> jamrial: huh, wacky
[00:02:24 CEST] <rcombs> sure looks like it
[00:02:37 CEST] <rcombs> maybe somebody #ifdefs it?
[00:03:10 CEST] <nevcairiel> might be a merge artifact
[00:03:21 CEST] <jamrial> most likely that, yeah
[02:51:01 CEST] <J_Darnley> Fuck!  I forgot I was supposed to not upgrade Thunderbird!
[02:59:50 CEST] <J_Darnley> BBB: Sorry that I sent that mail directly to you.
[03:00:09 CEST] Action: J_Darnley goes to bed.
[11:36:26 CEST] <wm4> #define ALLOW_INTERLACE
[11:36:36 CEST] <wm4> didn't know you could disable all deinterlacing in h264 lavc
[11:47:19 CEST] Action: wm4 stares at the use of the "state" variable in h264_parser.c
[12:16:01 CEST] <wm4> what's this mode called where h264 codes separate fields as separate slices, why is BBC switching between this and non-field coded slices, how does interlacing without separate fields even work, and why does the h264 parser not merge both field slices into a single packet (making remuxing from .ts generally fail)?
[12:16:12 CEST] <wm4> also did I mention yet that I fucking hate interlacing?
[12:16:26 CEST] <wm4> kierank: maybe you know something?
[12:17:30 CEST] <wm4> my current impulse would be just making h264_parser.c merge those slice NALs into a single packet, but I'm afraid of this dumb state machine
[12:18:33 CEST] <wm4> it's basically Open Binary code
[12:19:23 CEST] <wm4> state ^= 5;            // 2->7, 1->4, 0->5
[12:19:46 CEST] <wm4> no explanations what the states mean
[12:19:58 CEST] <wm4> random magic
[12:20:30 CEST] <wm4> return i - (state & 5) - 5 * (state > 7);
[12:20:32 CEST] <wm4> "fuck you too"
[12:25:13 CEST] <J_Darnley> Oh my.  Reminds me of the overloaded variables in AVS.  Sorry I can't help.
[12:25:19 CEST] <jkqxz> The state field is documented: "contains the last few bytes in MSB order".  I totally believe that from the code :P
[12:26:03 CEST] <wm4> not sure where you see this
[12:26:13 CEST] <nevcairiel> thats a different state field
[12:26:59 CEST] <jkqxz> It's used to store the state value.
[12:27:10 CEST] <wm4> I'm talking about the local variable in h264_find_frame_end
[12:27:39 CEST] <wm4> oh.
[12:27:57 CEST] <wm4> should have the same semantics
[12:28:20 CEST] <nevcairiel> the state jkqxz talks about is typically used to find startcodes
[12:28:45 CEST] <nevcairiel> the other statemachine in h264_parser is quite a bit more crazy
[12:28:58 CEST] <nevcairiel> anyway merging the fields into one packet is likely going to break all the things
[12:29:06 CEST] <wm4> which other things?
[12:29:12 CEST] <wm4> well fine, so how do I fix remuxing
[12:29:24 CEST] <nevcairiel> tell people to shove off if they report interlaced problems
[12:29:25 CEST] <nevcairiel> :)
[12:29:28 CEST] <jkqxz> By mixed frames and fields, do you mean like in camp_mot_picaff0_full.26l?
[12:30:37 CEST] <wm4> don't know, this is a stream captured by the BBC, and it appears field_pic_flag goes on and off randomly
[12:31:43 CEST] <wm4> (probably some sort of encoder decision)
[12:34:37 CEST] <wm4> nevcairiel: I'm not sure what's wrong with merging them - shouldn't each packet contain a complete frame?
[12:35:02 CEST] <jkqxz> Yeah, it does that.  (That stream is the "haha fuck you" conformance test for PicAFF: <http://sprunge.us/AFAj>.)
[12:35:47 CEST] <nevcairiel> wm4: a field per packet is fine as well, in ts they can even  have distinct timestamps per field
[12:36:38 CEST] <nevcairiel> in another note, how do you remux to ts then? :p
[12:36:40 CEST] <wm4> in this case they don't (or at least neither the lavf ts demuxer nor the utils.c fuckmagic is setting any)
[12:37:08 CEST] <wm4> I think we're trying to remux to mkv
[12:49:11 CEST] <ubitux> src/libavutil/arm/intmath.h:77:5: error: impossible constraint in asm
[12:49:12 CEST] <ubitux>      __asm__ ("usat %0, %2, %1" : "=r"(x) : "r"(a), "i"(p));
[12:49:14 CEST] <ubitux> :(
[12:51:39 CEST] <ubitux> maybe that's because of disable-optimization
[12:54:22 CEST] <ubitux> no, doesn't seem to make a difference
[12:54:44 CEST] <ubitux> i don't understand why it wouldn't be able to solve that given that the argument looks constant
[12:54:58 CEST] <ubitux> (it comes from libavfilter/colorspacedsp_template.c)
[12:55:01 CEST] <BtbN> Because it's told to not even try?
[12:55:25 CEST] <wm4> and the compiler can't generate that code?
[12:55:52 CEST] <ubitux> doesn't seem so
[12:56:10 CEST] <ubitux> (gcc 6.3.1, armv7l)
[13:04:04 CEST] <wm4> I mean, using pure C
[13:04:16 CEST] <wm4> ideally a good compiler would use usat instead of generating more stupid code
[13:06:30 CEST] <nevcairiel> thats why inline asm is a problem, it puts severe constraints on compiler behavior resulting in such errors
[13:07:07 CEST] <ubitux> wm4: the generated code is like 8 instructions here
[13:07:38 CEST] <ubitux> maybe it's smaller with a constant though
[13:08:15 CEST] <ubitux> yeah 5 instruct with a constant
[13:08:23 CEST] <ubitux> still no usat
[13:08:30 CEST] <ubitux> anyway
[13:08:34 CEST] <ubitux> ffmpeg doesn't compile :p
[13:09:27 CEST] <ubitux> i wonder why it doesn't been detected before
[13:48:26 CEST] <JEEB> ubitux: does clang do the same?
[13:54:16 CEST] <ubitux> JEEB: the number of instructions? pretty much yes
[13:54:29 CEST] <ubitux> haven't tried for ffmpeg compilation yet, because it takes& a long time
[13:55:16 CEST] <JEEB> k
[13:55:22 CEST] <ubitux> i'm retrying compilation with optimizations enabled first
[13:55:41 CEST] <ubitux> (i forgot to clean previously so it may have derped)
[15:28:43 CEST] <cone-977> ffmpeg 03James Almer 07master:11827ea3f041: fate: add aac-al_sbr_ps_06_ur test
[15:39:08 CEST] <ubitux> lol at this comment: //l is s, r is d
[15:39:46 CEST] <ubitux> jamrial: nice, i guess i'll be able to test the ipodpdpdpd thing after the simple stereo interpolate :)
[15:40:40 CEST] <jamrial> oh wtf, i wrote 06 instead of 04 in the commit message
[15:41:52 CEST] <jamrial> ubitux: heh, you reminded me how google would refuse to search ipdopd and change it into ipod for me :p
[15:42:34 CEST] <kierank> jamrial: you use the + modifier
[15:42:36 CEST] <kierank> and it should work
[15:52:03 CEST] <cone-977> ffmpeg 03Michael Niedermayer 07master:4bc3008d0445: avcodec/jpeglsdec: Check get_bits_left() before decoding a picture
[15:52:04 CEST] <cone-977> ffmpeg 03Max Justicz 07master:ca616b0f72c6: avcodec/sanm: Fix uninitialized reference frames
[16:34:56 CEST] <BBB> ubitux: have you checked tsan reporting lately? has it been clear-ish?
[16:36:10 CEST] <ubitux> afaik it's in the same state as when you "left" it
[16:36:26 CEST] <ubitux> so hevc/h264 fails sometimes and mpeg* is broken
[16:36:50 CEST] <BBB> mpeg* and frame_thread_encoder
[16:36:56 CEST] <ubitux> yeah
[16:37:02 CEST] <BBB> ok thats not terrible
[16:37:13 CEST] <ubitux> + slices
[16:37:17 CEST] <BBB> oh right slices
[16:37:21 CEST] <ubitux> which are broken in different ways
[16:37:43 CEST] <BBB> h264 slices is pretty broken
[16:38:02 CEST] <BBB> I should probably look at that
[16:38:06 CEST] <BBB> I thought I fixed some of that
[16:38:09 CEST] <BBB> maybe just not enough
[16:38:19 CEST] <ubitux> i'd rather have the the !slices first, but sure
[16:38:30 CEST] <BBB> I agree
[16:38:40 CEST] <ubitux> so we can have at least one green thread instance
[16:38:42 CEST] <BBB> if I leave it in a 90% state nobody will ever care to get it up to 100%
[16:38:47 CEST] <ubitux> which is much easier to monitor
[16:38:50 CEST] <BBB> mpeg* is hard though
[16:38:58 CEST] <BBB> but I guess someone has to care
[16:38:59 CEST] <BBB> hm
[16:39:00 CEST] <BBB> ...
[16:39:00 CEST] <BBB> ok
[16:39:25 CEST] <BBB> still pretty good, only 65 failing tests
[16:39:29 CEST] <BBB> it used to be several 100s
[16:39:40 CEST] <BBB> not saying its ok to see 65 tests fail
[16:39:44 CEST] <BBB> just saying there was some improvement
[16:41:04 CEST] <ubitux> yes, it's definitely much better
[16:41:33 CEST] <ubitux> and i love the fact that we're pretty close to be able to use it to detect new races :)
[16:42:21 CEST] <BBB> oh I remember the hevc one
[16:42:28 CEST] <ubitux> jamrial: shouldn't we have the aac test in checkasm?
[16:42:32 CEST] <BBB> so, theres this thing called end of sequence slices
[16:42:50 CEST] <BBB> which update one variable and otherwise dont do anything
[16:42:51 CEST] <ubitux> jamrial: typically testing the expected boundary constraints
[16:43:15 CEST] <BBB> but because theyre after a slice, they interfere with frame threading in the sense that they update a variable after finish_setup() was called
[16:43:30 CEST] <BBB> so maybe the eob slice should be split and decoded in its own thread even though its not technically a video frame
[16:43:31 CEST] <BBB> WDYT?
[16:43:45 CEST] <BBB> (by the parser)
[16:43:45 CEST] <jamrial> ubitux: i guess, but i'm not going to write it. last time i tried to add float dsp tests it had problems everywhere
[16:46:35 CEST] <ubitux> BBB: hevc, h264 or mpeg?
[16:46:41 CEST] <BBB> hevc
[16:46:42 CEST] <ubitux> jamrial: what kind of problem?
[16:46:58 CEST] <ubitux> fuzz-related issues?
[16:48:08 CEST] <jamrial> ubitux: no, some tests failing if ran after others, x86_32 failing no matter what
[16:48:10 CEST] <jamrial> seemed like something related to emms not being handled right by the generic checkasm code
[16:48:35 CEST] <graphitemaster> << -1 * 2 - 1
[16:48:41 CEST] <graphitemaster> er, wrong channel
[16:49:18 CEST] <ubitux> jamrial: so we don't have any float tests in checkasm currently? oO
[16:49:26 CEST] <jamrial> yes, we do
[16:49:33 CEST] <jamrial> synth_float
[16:49:51 CEST] <jamrial> what we don't have is tests that return a float instead of void
[16:50:55 CEST] <ubitux> BBB: the code setting that var can not be taken out of the slice thread?
[16:51:12 CEST] <ubitux> BBB: it's very vague to me what you're trying to accomplish :p
[16:51:43 CEST] <ubitux> jamrial: ooh, ok, well the aac dsp doesn't seem to do something else so it should be fine :)
[16:52:08 CEST] <ubitux> at least the ps code, i think the sbr code mateo` is working on has some return (but only ints iirc)
[16:56:54 CEST] <BBB> ubitux: frame thread, not slice thread
[16:57:22 CEST] <BBB> jamrial: someone added emms handling to mmx code at some point
[16:57:36 CEST] <BBB> jamrial: but I dont remember how it works grrrrmbl
[16:58:11 CEST] <jamrial> yes, but it didn't fix the issues i saw
[16:58:33 CEST] <jamrial> in any case, it also wasn't working right in x86_64, where it's all sse, so maybe i fucked up somewhere else
[16:59:13 CEST] <jamrial> it's in the ml, the float_dsp port patch. some tests fail if you run it as part of the entire suite but don't if you run them individually
[16:59:32 CEST] <jamrial> they also doesn't make checkasm report the run as failed. it's weird
[17:00:16 CEST] <jamrial> so i said fuck it, i'll stick with ints where everything is cozy :p
[17:00:52 CEST] <ubitux> :)
[17:04:05 CEST] <jamrial> https://pastebin.com/DWhMcwX3 this is the output on x86_64
[17:04:55 CEST] <jamrial> same seed, fails (but doesn't report it as failed at the end) if run as part of the whole suite, succeeds if ran alone
[17:06:14 CEST] <jamrial> one of the "failing" tests is the one that retuns a float, something no other test currently in checkasm does
[17:07:05 CEST] <jamrial> it's a direct port of the libavutil/tests file, which works fine, so i'm guessing something in the generic checkasm code is not playing nice with it
[17:08:22 CEST] <mateo`> ubitux: only one function returns something (a float) in the sbrdsp
[17:08:39 CEST] <ubitux> ah that's actually a float, ok
[17:09:49 CEST] <mateo`> as ubitux said, i'm working on porting the sbrdsp to aarch64 (something like 40% of the work is done)
[17:13:49 CEST] <BBB> ubitux: wanna test a patch for me?
[17:13:57 CEST] <BBB> ubitux: for the hevc frame-thread issue
[17:14:00 CEST] <ubitux> sure
[17:14:12 CEST] <BBB> its totally hacky but maybe it works
[17:14:31 CEST] <BBB> (itll take me a while to recompile everything with tsan and Im doing something else also :-/ )
[17:14:41 CEST] <BBB> https://pastebin.com/V2YW31Qm
[17:14:50 CEST] <ubitux> well, i need to resetup a local build as well
[17:14:55 CEST] <jamrial> from sbrdsp i wrote autocorrelate some time ago. i remember it was fun trying to figure out the first and last pass
[17:15:00 CEST] <ubitux> it will take some time but i'll do it
[17:15:06 CEST] <jamrial> looking at it now, i have no idea how to read all those "comments" i left next to some instructions :P
[17:21:30 CEST] <BBB> hm no that doesnt do anything useful at all
[17:23:53 CEST] <BBB> aha I made a mistake between eos/last_Eos
[17:24:07 CEST] <BBB> ok a slight change makes it work and is probably fundamentally more correct than what it currently does
[17:24:11 CEST] <BBB> lemme see if this fixes the tsan report
[17:24:21 CEST] <BBB> oh I dont see it
[17:24:22 CEST] <BBB> tsk tsk
[17:24:25 CEST] <BBB> why not
[17:25:48 CEST] <BBB> ubitux: ok so I cant reproduce the issue, it seems
[17:25:53 CEST] <BBB> but I think I know how to fix it
[17:25:54 CEST] <BBB> so...
[17:25:56 CEST] <ubitux> which test is it supposed to fix, hevc-conformance-NoOutPrior_A_Qualcomm_1?
[17:26:20 CEST] <BBB> yes
[17:26:25 CEST] <BBB> but not the patch I just gave
[17:26:26 CEST] <BBB> one sec
[17:26:30 CEST] <ubitux> i can reproduce more easily increasing the number of threads
[17:26:46 CEST] <ubitux> anyway, i have a tsan build for which i can reproduce
[17:27:04 CEST] <ubitux> THREADS=8 fails almost all the time
[17:27:29 CEST] <ubitux> btw, when it's all green i'll increase the number of threads
[17:27:38 CEST] <BBB> https://pastebin.com/us4Rs1qp
[17:27:39 CEST] <ubitux> (currently the fate instance is at 2)
[17:27:56 CEST] <BBB> it reproduces here very sparringly
[17:27:59 CEST] <BBB> I cant reproduce with that patch
[17:28:11 CEST] <BBB> but itd be nice if you can reproduce more consistently to see if the patch fixes it
[17:28:50 CEST] <ubitux> it seems to fix the issue indeed
[17:28:52 CEST] <BBB> hey that would actually make hevc green
[17:28:54 CEST] <BBB> nice
[17:28:57 CEST] <BBB> on to h264 again then
[17:29:19 CEST] <J_Darnley> I hope those Typhoons and Galaxies flying overhead are on their way to "bomb the shit" out of Brussels.
[17:30:35 CEST] <ubitux> BBB: hevc-conformance-CONFWIN_A_Sony_1 failed thoughj
[17:30:43 CEST] <ubitux> hevc-conformance-CAINIT_A_SHARP_4 as well
[17:31:35 CEST] <ubitux> ah fuck i forgot to disable the stripping
[17:32:13 CEST] <BBB> ohwell
[17:32:21 CEST] <J_Darnley> :(  pretty coloured smoke but no fire
[17:35:17 CEST] <BBB> ubitux: patch sent
[17:35:58 CEST] <ubitux> BBB: http://b.pkh.me/hevc-conformance-OPFLAG_C_Qualcomm_1.err
[17:36:38 CEST] <BBB> oh that one again :(
[17:36:42 CEST] <ubitux> (hevc-conformance-OPFLAG_C_Qualcomm_1)
[17:36:42 CEST] <BBB> Ive seen that before
[17:36:52 CEST] <BBB> I have not yet been able to determine what causes it
[17:37:53 CEST] <BBB> it suggests a frame is decoded (multi-slice) in multiple threads, causing owner[] to be wrong
[17:37:58 CEST] <ubitux> BBB: http://b.pkh.me/hevc-conformance-CAINIT_A_SHARP_4.err
[17:38:02 CEST] <ubitux> how about this one?
[17:38:02 CEST] <BBB> thats certainly possible and I havent dont a lot of work on that yet
[17:38:08 CEST] <BBB> same
[17:38:13 CEST] <BBB> better backtrace though
[17:38:43 CEST] <BBB> its possible that owner[] is not set correctly in hevc for interlaced pictures split in two frame decoding threads
[17:38:57 CEST] <BBB> I only fixed that for h264
[17:39:18 CEST] <nevcairiel> hevc interlaced is not something we support anyway
[17:39:38 CEST] <BBB> maybe its something else
[17:39:38 CEST] <ubitux> got it again with another test
[17:39:39 CEST] <BBB> anyway
[17:39:48 CEST] <BBB> I need to look deeply into one of these failing instances
[17:39:51 CEST] <BBB> at some point I will
[17:40:10 CEST] <BBB> its not very high priority because it has no practical implications
[17:40:12 CEST] <BBB> afaik
[17:40:16 CEST] <BBB> but it needs fixing obviously
[17:40:41 CEST] <ubitux> it happens a lot with a bunch of threads
[17:41:01 CEST] <ubitux> http://sprunge.us/fRQM
[17:41:10 CEST] <ubitux> i haven't checked all but it does seem to be always the same
[17:41:13 CEST] <BBB> ok, good to know
[17:41:19 CEST] <BBB> Ill dig deeper at some point
[17:41:26 CEST] <BBB> I sort of know what it means but not exactly ;)
[17:41:34 CEST] <BBB> and hevc is & bla, vp9 much more important
[17:41:37 CEST] <BBB> and at least vp9 is clean
[17:42:24 CEST] <BBB> the h264 fail one is also the same btw
[17:42:29 CEST] <BBB> so I guess I have no choice but to dig into it
[17:42:31 CEST] <BBB> brrrrr
[17:42:36 CEST] <BBB> I dont like that at all
[17:42:39 CEST] <ubitux> :(
[17:42:52 CEST] <ubitux> don't worry, once fixed, forever green
[17:43:09 CEST] <BBB> ;)
[17:43:17 CEST] <iive> until next merge ;)
[17:43:57 CEST] <ubitux> speaking of merges, i got no answer wrt dashenc
[17:44:05 CEST] <ubitux> (from the guy who did the bitrate thing)
[17:44:15 CEST] <ubitux> no one wants to give it a try?
[17:44:50 CEST] <RiCON> dashenc or dashdec?
[17:44:54 CEST] <ubitux> enc
[17:45:10 CEST] <RiCON> oh, libav merges
[17:45:10 CEST] <RiCON> nvm
[17:45:13 CEST] <ubitux> i feel like dropping our changes in favor of the work from the original author since we don't have a maintainer
[17:45:42 CEST] <BBB> that may be reasonable, yes
[17:45:44 CEST] <ubitux> (BBB: "Tthis")
[17:46:06 CEST] <jamrial> ubitux: i'd say do that if the guy that wrote out bitrate thing isn't answering. there are a bunch of other dashenc commits from libav, so keeping our version may create conflicts in the future
[17:46:10 CEST] <BBB> fixed
[17:46:40 CEST] <ubitux> jamrial: yeah, it's going to be a pain
[17:46:53 CEST] <ubitux> i don't want to do it :(
[17:47:15 CEST] <thardin> has anyone gotten afl to work with ffmpeg?
[17:47:25 CEST] <thardin> feeling slightly inspired to give it a go again
[17:47:49 CEST] <BBB> is afl the complicated fuzzer?
[17:47:57 CEST] <BBB> didnt kierank try that?
[17:48:16 CEST] <kierank> thardin: yes it's pretty straightforward
[17:48:28 CEST] <thardin> CC=afl-gcc or so?
[17:48:46 CEST] <kierank> yes
[17:48:49 CEST] <kierank> configure as well
[17:48:53 CEST] <kierank> this might help
[17:48:53 CEST] <kierank> https://github.com/openBroadcastSystems/fffuzz
[17:49:00 CEST] <kierank> unless you specifically want to use ffmpeg.c
[17:49:27 CEST] <kierank> tbh there's low hanging fruit with zzuf first
[17:50:02 CEST] <thardin> lavf always seems more suspect to me, so fuzzing ffprobe kinda seems most relevant
[17:50:05 CEST] <BBB> ubitux: oh, btw, I did at some point briefly look into fixing tsan for mpeg*
[17:50:16 CEST] <BBB> ubitux: and its going to be a bloody and deadly and torturous pain
[17:50:20 CEST] <BBB> ubitux: just so you know :-p
[17:51:00 CEST] <BBB> hi gh0st__ 
[17:51:11 CEST] <ubitux> because of the famous and beloved MpegEncContext?
[17:51:17 CEST] <thardin> but a minimal decoder CLI should be useful too, thanks
[17:53:23 CEST] <BBB> ubitux: as part of update_context, it does update_context(MpegEncContext *dst, MpegEncContext *src) { [..] *dst = *src; [..] }
[17:53:31 CEST] <kierank> thardin: fuzzing containers i  think is a nontrivial problem
[17:53:41 CEST] <BBB> ubitux: and lets just say that will take incredibly long to unwind in a way that can be proven to be correct
[17:54:08 CEST] <BBB> ubitux: especially for someone like me who is superficially aware of mpeg bitstream syntax things but has no detailed knowledge of any of it
[17:54:32 CEST] <ubitux> BBB: your face when you will realize it's for 5-6 sparse fields you'll have to figure out in a struct of 1000s of fields
[17:54:35 CEST] <ubitux> :3
[17:54:42 CEST] <thardin> kierank: no doubt
[17:54:57 CEST] <BBB> ubitux: you will hear me scream
[17:55:11 CEST] <BBB> but yes
[18:04:20 CEST] <gh0st__> BBB:hey!
[18:05:23 CEST] <BBB> one more week!
[18:05:56 CEST] <gh0st__> BBB: Yeah, I am ready! =)
[19:14:27 CEST] <ubitux> [aarch64] so i have v0=AXXX v1=BXXX, i want f(v0,v1) = AABB; i'm going for zip1.2(zip1.4(v0,v0) zip1.4(v1,v1))
[19:14:32 CEST] <ubitux> anything else to suggest?
[19:14:56 CEST] <ubitux> 3 zip are overkill, given that i have to do the same for all the other X
[19:15:51 CEST] <ubitux> v0=ABCD v1=EFGH ’ {AAEE, BBFF, CCGG, DDHH}
[19:16:02 CEST] <ubitux> (4 different regs)
[19:17:23 CEST] <atomnuker> <pshufb in aarch64-ise>
[19:31:02 CEST] <iive> ubitux: no (un)pack equivalents?
[19:31:22 CEST] <ubitux> that's what zip/uzp do
[19:31:44 CEST] <ubitux> basically the tools are zip/uzp and the pshuf joker is "ext"
[19:31:52 CEST] <ubitux> which i probably want to avoid
[19:32:33 CEST] <iive> do you have a url to description of the (un)zip ?
[19:32:48 CEST] <ubitux> with 4 zip i end up with {AACC, BBDD, EEGG, FFHH}, now i technically need 2 more instruction to swap CC with EE and swap DD with FF
[19:32:55 CEST] <ubitux> iive: the arm doc is shit
[19:33:23 CEST] <ubitux> https://developer.arm.com/docs/100069/latest/a64-simd-vector-instructions/uzp1-vector
[19:33:59 CEST] <ubitux> they still haven't dare to draw freaking graphics like in the intel doc
[19:34:23 CEST] <ubitux> there are also the trn (transpose) ones that may help
[19:35:02 CEST] <ubitux> so zip[12], uzp[12], trn[12] and ext joker
[19:37:34 CEST] <iive> wow, that's bad...
[19:37:42 CEST] <iive> what is arangement specifier?
[19:39:23 CEST] <ubitux> it refers to the "type", treat it like 8, 16, 32 or 64 bits entries
[19:39:33 CEST] <ubitux> and the variants refering to half of the ref
[19:39:37 CEST] <ubitux> s/ref/reg/
[19:39:42 CEST] <iive> int or float too?
[19:39:49 CEST] <ubitux> yeah it doesn't matter
[19:39:52 CEST] <ubitux> it's the size
[19:40:29 CEST] <ubitux> 8B is the lower-only version of 16B, 4H is the lower-only version of 8H, etc
[19:40:37 CEST] <iive> so is 16b  16bits or 16 integer cells?
[19:41:12 CEST] <ubitux> 16B refers to the "8-bit" layout of the whole SIMD register
[19:41:18 CEST] <ubitux> "16 bytes"
[19:41:36 CEST] <ubitux> 8H refers to the "16-bit" layout of the whole SIMD register
[19:41:41 CEST] <ubitux> "8 half words"
[19:42:33 CEST] <ubitux> the asm is pretty cool tbh
[19:42:37 CEST] <mateo`> if you want the fancy version (armv7 only): https://community.arm.com/processors/b/blog/posts/coding-for-neon---part-5-rearranging-vectors
[19:42:38 CEST] <ubitux> the doc just sucks
[19:42:47 CEST] <ubitux> yep i got that page
[19:43:06 CEST] <ubitux> i'm interested in the rev, unfortunately it's in place and i don't want that
[19:43:17 CEST] <ubitux> i want to swap the 2D layout of 2 given registers
[19:45:43 CEST] <ubitux> v0.D={A,B} v1.D={C,D} and i want v0.D={A,C} v1.D={B,D} 
[19:45:53 CEST] <ubitux> i can probably do that with trn*
[19:46:00 CEST] <ubitux> anyway.
[19:46:01 CEST] <mateo`> trn if what you look for
[19:46:22 CEST] <mateo`> if->is
[19:47:12 CEST] <ubitux> yeah i need to figure out again what's it's doing
[19:47:29 CEST] <ubitux> i really need to draw all of them at some point
[19:47:32 CEST] <iive> ubitux: vzip as first step, give you {ABCD}x{EFGH} -> {AEBF}x{CGDH} , doesn't it?
[19:48:08 CEST] <ubitux> this is arm, aarch64 is simpler, you have 1 dst for 2 src
[19:48:32 CEST] <ubitux> you can ignore the inplace manipulations, it's much easier
[19:48:39 CEST] <iive> so no vzip for you
[19:48:46 CEST] <iive> ?
[19:48:46 CEST] <ubitux> yeah but zip1() and zip2()
[19:49:00 CEST] <iive> would they give you the same result?
[19:49:50 CEST] <iive> {AEBF}x{AEBF}->{AAEE}x{BBFF}
[19:50:03 CEST] <ubitux> v0=ABCD v1=EFGH ’ {zip1(v0,v0), zip2(v0,v0), zip1(v1,v1), zip2(v1,v1)} ’ {AACC, BBDD, EEGG, FFHH}
[19:50:33 CEST] <ubitux> now i need 2 more instr to swap into {AAEE, BBFF, CCGG, DDHH}
[19:50:39 CEST] <mateo`> my bad, trn is not going to work for that
[19:50:54 CEST] <ubitux> mateo`: i think it might do it
[19:51:02 CEST] <iive> ubitux: see what i've written
[19:51:55 CEST] <ubitux> assuming i understood your notation it should be possible with 2 zip
[19:52:58 CEST] <ubitux> (i'm understanding zip1(AEBF,AEBF)=AAEE and zip2(AEBF,AEBF)=BBFF)
[19:53:05 CEST] <iive> 3 vzips or 6 zip?s
[19:53:12 CEST] <ubitux> just 2
[19:53:21 CEST] <iive> to make all 4 results
[19:53:45 CEST] <iive> also you need 2 register copy
[19:53:47 CEST] <ubitux> 4 zip for all 4 results before the last 2 swap
[19:56:01 CEST] <ubitux> in the end, i want v0=ABCD v1=EFGH ’ {AACC, BBDD, EEGG, FFHH}
[19:56:14 CEST] <ubitux> right now i have v0=ABCD v1=EFGH ’ {AACC, BBDD, EEGG, FFHH} with 4 zip
[19:56:27 CEST] <ubitux> and i need just 2 swap if i figure out the proper instruct
[19:56:29 CEST] <iive> hum, no. no register copy required in zip1/2
[19:57:03 CEST] <iive> ubitux: you have to mix the 2 different vectors first
[19:57:12 CEST] <iive> then mix the results with themselves
[19:57:55 CEST] <ubitux> (sorry right in the end i want {AAEE, BBFF, CCGG, DDHH})
[19:58:10 CEST] <iive> yes
[19:58:12 CEST] <ubitux> anyway, i'll go back in my brain instead of talking
[19:58:21 CEST] <iive> and you have to get AEBF , CGDH first
[19:58:37 CEST] <iive> let me write it down and i'll paste it 
[20:00:41 CEST] <iive> i think i'm done, should i paste it here or in pastebin?
[20:00:45 CEST] <iive> or private?
[20:01:02 CEST] <ubitux> doesn't matter
[20:01:29 CEST] <iive> v1=ABCD
[20:01:29 CEST] <iive> v2=EFGH
[20:01:29 CEST] <iive> v3=zip1(v1,v2) ; {ABCD}x{EFGH}->{AEBF}
[20:01:29 CEST] <iive> v4=zip2(v1,v2) ; {ABCD}x{EFGH}->{CGDH}
[20:01:29 CEST] <iive> v5=zip1(v3,v3) ; {AEBF}x{AEBF}->{AAEE}
[20:01:29 CEST] <iive> v6=zip2(v3,v3) ; {AEBF}x{AEBF}->{BBFF}
[20:01:31 CEST] <iive> v7=zip1(v4,v4) ; {CGDH}x{CGDH}->{CCGG}
[20:01:33 CEST] <iive> v8=zip2(v4,v4) ; {CGDH}x{CGDH}->{DDHH}
[20:04:35 CEST] <ubitux> oh, so only with zips
[20:05:18 CEST] <ubitux> let me check if it matches why original expectation
[20:05:22 CEST] <ubitux> thanks
[20:05:29 CEST] <iive> you are welcome :D
[20:06:38 CEST] <iive> or course, v5/6/78 could reuse v1/2/3/4
[20:14:29 CEST] <BBB> ubitux: I have a hard time reproducing the update_context_from_user cases :-(
[20:14:40 CEST] <thardin> running afl with a small test program. it was pretty good at finding obvious buffer overflow problems
[21:01:41 CEST] <thardin> there we go, got afl-fuzz running with ffprobe on a small mxf file
[21:19:29 CEST] <llogan> Compn, michaelni: I'll be unavailable to clear the ML queue from May 30-June 15 (mistakenly mentioned this in #ffmpeg).
[21:20:24 CEST] <michaelni> llogan, ok, understood
[21:35:06 CEST] <atomnuker> thardin: mxf? have you found something yet?
[21:35:55 CEST] <thardin> only some "hangs" which only seem to be that it took a few more milliseconds than the default
[21:36:38 CEST] <thardin> one case perhaps interesting, takes about 100 ms
[21:37:22 CEST] <wm4> you should fuzz subtitle parsers lol
[21:37:28 CEST] <wm4> I heard it's all the rage these days
[21:38:54 CEST] <atomnuker> interesting, I thought mxf was pretty bad
[21:39:18 CEST] <wm4> it just means the code isn't too bad, not the format
[21:41:00 CEST] <thardin> lol yes
[21:41:21 CEST] <cone-977> ffmpeg 03Michael Niedermayer 07master:89325417e7b3: avcodec/jpeg2000dec: Check tile offsets
[21:41:22 CEST] <cone-977> ffmpeg 03Michael Niedermayer 07master:bce362d36ccf: avcodec/wavpack: Fix runtime error: left shift of negative value -1
[21:41:23 CEST] <cone-977> ffmpeg 03Michael Niedermayer 07master:cfec0d647525: avcodec/cllc: Check bitstream end before decoding pixels
[21:41:35 CEST] <thardin> the format is fairly nasty, but at the same time maybe that encourages defensive coding
[21:42:14 CEST] <thardin> don't think I have any file with subs
[21:42:28 CEST] <thardin> I guess mkv would be a candidate
[21:42:36 CEST] <thardin> I'll have to.. acquire some
[21:44:05 CEST] <atomnuker> ubitux did some subtitle fuzzing not long ago btw
[21:44:40 CEST] <atomnuker> he also has the entire opensubtitles database before the site went down
[21:48:24 CEST] <thardin> I suppose the thing to do is convert a file with subs to rawvideo
[21:49:01 CEST] <Compn> llogan : k buddy 
[21:49:48 CEST] <Compn> wm4 : so was the problem with opensubtitle plugin or everybodys glue code ?
[21:50:01 CEST] <Compn> wm4 : also why not opensubtitle just sanitize these subtitle files
[21:50:25 CEST] <wm4> 4 different bugs or something
[21:50:27 CEST] <Compn> someone came into #mplayer asking about it , we had no idea haha 
[21:50:31 CEST] <wm4> in a sensationalistic package
[21:51:00 CEST] <wm4> atomnuker: I'm pretty sure the site still exists?
[21:51:38 CEST] <Compn> opensubtitles.org still up 
[21:51:51 CEST] Action: Compn wants kloofy to come back tho
[21:58:51 CEST] <atomnuker> huh, I was sure it was "down" a few weeks ago because it had several million dmca requests and was useless because it complied
[22:09:34 CEST] <RiCON> atomnuker: could you rebase your psyacoustics patch? i wanted to do a windows build to someone asking to test it in hydrogenaudio
[22:10:28 CEST] <atomnuker> ok, hold on, I made some improvements to transient detection
[22:12:28 CEST] <thardin> "sub2video: non-bitmap subtitle"
[22:12:36 CEST] <thardin> do I need to configure with freetype?
[22:15:14 CEST] <thardin> giving --enable-libfontconfig --enable-libfreetype a go
[22:18:59 CEST] <thardin> nope
[22:20:13 CEST] <wm4> lol
[22:20:23 CEST] <wm4> welcome to the funny world of ffmpeg.c
[22:20:37 CEST] <wm4> you need to pass the subtitle file to vf_sub I think
[22:21:09 CEST] <thardin> trac wiki claims -vf subtitles=video.mkv
[22:22:48 CEST] <wm4> yes
[22:23:11 CEST] <thardin> no "subtitles" filter
[22:23:16 CEST] <atomnuker> RiCON: https://pars.ee/temp/opuspsy_v3.patch
[22:23:46 CEST] <RiCON> thanks
[22:23:47 CEST] <atomnuker> only does transient detection, dual stereo search (useless for anything below 400kbps) and intensity stereo search (pretty good)
[22:25:18 CEST] <atomnuker> it'll be much better once I complete my evil plan to have a lambda value which maps to band boosts
[22:26:42 CEST] <atomnuker> RiCON: is that for Lumitopia? I hadn't checked the thread since I posted last month
[22:26:48 CEST] <RiCON> atomnuker: yeah
[22:28:18 CEST] <pfelt> is the person that is the moderator for the -devel mailing list on here?
[22:28:33 CEST] <RiCON> it's llogan, i think?
[22:30:44 CEST] <pfelt> oh yah know what, i just looked at the archives and figured out what happend.
[22:30:47 CEST] <pfelt> nm.
[22:44:56 CEST] <thardin> --enable-filter=subtitles
[22:48:13 CEST] <thardin> didn't work :[
[22:49:30 CEST] <thardin> aha --enable-libass needed. it should complain about that
[23:11:23 CEST] <wm4> does anyone know about the libopus encoder? someone claims it's very slow on lesser hardware
[23:14:36 CEST] <atomnuker> wm4: not possible, the thing runs on mmu-less microprocessors
[23:15:30 CEST] <TD-Linux> wm4, there's #opus (or me or atomnuker)
[23:15:46 CEST] <wm4> I mean encoder, not decoder
[23:16:12 CEST] <TD-Linux> no, the encoder is pretty fast too. you can run 1000 of them on a desktop in realtime
[23:17:08 CEST] <wm4> hm I guess I'll have to take a closer look then
[23:19:54 CEST] <TD-Linux> (note it does have speed levels, and it defaults the slowest which is about 100x realtime on my laptop, but you can set it faster if you want)
[23:20:31 CEST] <thardin> managed to get a 4.4k mkv with subs to fuzz
[00:00:00 CEST] --- Thu May 25 2017