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

Fri May 26 03:05:04 EEST 2017

[01:06:44 CEST] <thardin> annnd a minimal configuration that runs twice as fast. going to leave this running overnight
[01:28:18 CEST] <thebombzen> is there a reason the trac server is significantly slower than the rest of the website? seems like an odd speed differential
[01:29:24 CEST] <kierank> hosted in a different place iirc
[01:31:46 CEST] <cone-223> ffmpeg 03James Almer 07master:f8c73e87532a: avformat/movenc: always check for new extradata on a packet
[01:31:46 CEST] <cone-223> ffmpeg 03James Almer 07master:7631f14bb35e: avformat/matroskaenc: check packet side data for AAC extradata updates
[01:31:46 CEST] <cone-223> ffmpeg 03James Almer 07master:8b3ec51de8a0: avformat/latmenc: check packet side data for AAC extradata updates
[01:31:46 CEST] <cone-223> ffmpeg 03James Almer 07master:210388a1979d: avcodec/adtsenc: check packet side data for AAC extradata updates
[01:31:46 CEST] <cone-223> ffmpeg 03James Almer 07master:f63c3516577d: avcodec/aac_adtstoasc: propagate new extradata using packet side data
[01:31:46 CEST] <cone-223> ffmpeg 03James Almer 07master:437ad467c250: avformat/mux: remove autobsf extradata propagation hack
[01:31:47 CEST] <cone-223> ffmpeg 03James Almer 07master:f1cdc01e7208: ffmpeg: remove bsf extradata propagation hack
[01:31:48 CEST] <cone-223> ffmpeg 03James Almer 07master:94ec89eb6732: doc/libav-merge: remove line about aac_adtstoasc
[01:31:51 CEST] <jamrial> ubitux: ^ another one down
[01:36:30 CEST] <thebombzen> another question about the trac: is there any sort of guidelines on what bugs are "important" or "normal" or do you just play it by ear
[01:39:51 CEST] <jamrial> critical = data loss (like input file being overwritten and such). important = regressions. normal = not regressions. minor = doc mistakes or stuff like that i guess
[01:40:04 CEST] <jamrial> just choose normal and let whoever handles the ticket choose that for you
[01:41:20 CEST] <nevcairiel> feature requests = always wish
[01:47:50 CEST] <thebombzen> what exactly is a "regression"? is that "used to work and now doesn't" or something?
[01:48:19 CEST] <nevcairiel> basically
[03:11:06 CEST] <llogan> thebombzen: some info here http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/issue_tracker.txt;hb=HEAD
[03:11:22 CEST] <thebombzen> thx
[04:26:04 CEST] <jamrial> rcombs: ping
[04:33:27 CEST] <cone-223> ffmpeg 03James Almer 07master:8ea5ee10a2d6: avcodec/libopenh264dec: fix return error value when h264_mp4toannexb_bsf is not found
[04:44:19 CEST] <stevenliu> Hi guys
[04:44:27 CEST] <stevenliu> I have a question
[04:44:54 CEST] <stevenliu> It's Summer here, can i print ffmpeg picture on T-shirt?
[04:47:03 CEST] <stevenliu> Hi guys, I have a question,  It's Summer here, can i print ffmpeg picture on T-shirt?
[04:47:24 CEST] <stevenliu> for example, the logo of the ffmpeg.org :D
[05:38:58 CEST] <rcombs> jamrial: pong
[05:40:09 CEST] <jamrial> rcombs: could you test https://pastebin.com/raw/4S4zuTRL?
[05:41:04 CEST] <rcombs> hmm, what demuxers AV_PKT_DATA_NEW_EXTRADATA for AAC?
[05:41:20 CEST] <rcombs> or would that be on the output of the BSF
[05:41:32 CEST] <jamrial> the bsf
[05:41:38 CEST] <rcombs> ah, makes sense
[05:41:42 CEST] <rcombs> sure, I'll give it a go
[05:52:25 CEST] <jamrial> michaelni: "src/libavcodec/jpeg2000dec.c:304:40: warning: too many arguments for format [-Wformat-extra-args]" since 89325417e7
[06:14:34 CEST] <rcombs> jamrial: seems to work as expected
[06:14:59 CEST] <jamrial> rcombs: ok, thanks
[06:15:25 CEST] <rcombs> (ffplay'd an mpegts file with -acodec aac_at)
[06:21:16 CEST] <jamrial> as long as it was adts, that should do it
[06:27:29 CEST] <cone-223> ffmpeg 03James Almer 07master:954e2b3d34b7: avcodec/audiotoolboxdec: check packet side data for AAC extradata updates
[10:42:13 CEST] <ubitux> how much can i overread in aac ps stereo_interpolate?
[10:43:15 CEST] <ubitux> and actually overwrite (the read should be "safe")
[10:44:54 CEST] <atomnuker> you should be able to read as much as you need, since this appears to be done on coefficients which are padded and aligned
[10:45:22 CEST] <ubitux> it doesn't seem that i can overwrite
[10:45:29 CEST] <atomnuker> as for overwriting, none since you'll mess up coefficients from other bands
[10:45:38 CEST] <ubitux> that's too bad :(
[10:45:48 CEST] <atomnuker> vmaskmov?
[10:46:08 CEST] <atomnuker> (I think aarch64 had an alternative to that)
[10:46:34 CEST] <ubitux> yeah well, it would have been much better if i could just write 1 more float im/re pair
[10:47:23 CEST] <ubitux> i have a working function, but it's just reading 1 pairs of float per channel
[10:47:30 CEST] <ubitux> (and writing fwiw)
[10:48:00 CEST] <ubitux> if i could read 2 pairs of float per channel instead... 
[10:48:33 CEST] <ubitux> anyway, i'll keep it simple for now, but it's doing the same as the c basically
[10:49:01 CEST] <atomnuker> there is a way but the gains would be less than 2x since the extra instructions needed to handle overwriting
[10:49:41 CEST] <ubitux> couldn't we just +1 on the buffer declaration?
[10:52:35 CEST] <atomnuker> why do you want to overwrite, isn't len always a multiple of 4?
[10:54:04 CEST] <ubitux> ah? is it? didn't actually check
[10:54:28 CEST] <ubitux> if it's a multiple of 2 that's good enough for me
[10:54:49 CEST] <atomnuker> do check, I really doubt it isn't (since there's x86 asm for that function)
[10:55:58 CEST] <ubitux> Assertion !((stop - start) & 1) failed at src/libavcodec/aacps.c:977
[10:56:06 CEST] <ubitux> doesn't seem to be a multiple of 2
[10:57:37 CEST] <ubitux> the x86 asm does only 1 float pair writing per channel AFAICT
[11:22:39 CEST] <atomnuker> ubitux: you could still overwrite though
[11:22:55 CEST] <atomnuker> check out stereo_processing() in aacps.c
[11:23:06 CEST] <atomnuker> INTFLOAT (*l)[32][2], INTFLOAT (*r)[32][2]
[11:23:40 CEST] <atomnuker> just increase the second dimension
[11:23:56 CEST] <ubitux> yes that's what i was suggesting by increasing the buffer
[11:24:23 CEST] <ubitux> but i'll go for a simple version of the asm for now anyway
[11:29:40 CEST] <cone-722> ffmpeg 03Michael Niedermayer 07master:5782e0ba8cc3: avcodec/jpeg2000dec: Fix copy and paste error
[14:46:05 CEST] <Tehme> Hello. I have a question about avcodec and CUVID. When I do this: https://pastebin.com/iVv1Yc2w I have the following error: https://pastebin.com/dHyquQz2 . Looks like my libnvcuvid.so does not have cuvidGetDecoderCaps() function. Why does avcodec try to load it then? I have a proprietary NVIDIA driver 375.39 and CUDA SDK 8, ffmpeg version is 3.3.
[14:47:06 CEST] <nevcairiel> you need a newer driver
[14:47:54 CEST] <Tehme> I saw somewhere that 340+ is ok, let me check it.
[14:49:56 CEST] <nevcairiel> the video sdk 8.0 has only been supported in drivers 378
[14:50:52 CEST] <Tehme> thank you nevcairiel
[15:10:50 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:5f91786fc8ad: avcodec/wavpack: Fix: runtime error: signed integer overflow: 3 * -2147483648 cannot be represented in type 'int'
[15:10:50 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:ea71a48c7e8a: avcodec/wavpack: Fix runtime error: left shift of negative value -14778
[15:10:50 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:4dc3714c48e7: avcodec/tscc2: Skip duplicate frames
[15:13:25 CEST] <Tehme> So, if the latest driver for linux is 375.66, does it mean I can't use ffmpeg's h264_cuvid decoder?
[15:14:28 CEST] <RiCON> it's not the latest for linux though
[15:14:34 CEST] <RiCON> maybe it's the latest in your distro
[15:14:49 CEST] <Tehme> what is the latest then?
[15:29:24 CEST] <RiCON> 381.22 apparently
[15:34:21 CEST] <DHE> no nvenc?
[15:35:32 CEST] <DHE> oh, decoder, n/m
[15:43:48 CEST] <RiCON> Tehme: don't send unrequested private messages
[15:43:49 CEST] <RiCON> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/nvidia
[15:50:56 CEST] <Tehme> RiCON: thank you
[16:17:12 CEST] <BBB> does anyone want to review the hevc patch?
[16:18:37 CEST] <durandal_170> no
[16:22:20 CEST] <jamrial> BBB: there's no maintainer for hevc, so if you know it works and ubitux confirmed it, then just push it
[16:23:15 CEST] <BBB> I didnt say I knew hevc
[16:23:23 CEST] <BBB> but I feel bad about keeping it broken :-p
[16:25:18 CEST] <jamrial> nobody really knows it well i guess. the core devs for it have been kinda awol for a while :p
[16:25:57 CEST] <jamrial> maybe jkqxz does, seeing he's writing that neat raw bitstream parsing feature
[16:29:42 CEST] <BBB> uhm
[16:29:43 CEST] <BBB> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[16:29:44 CEST] <BBB> @       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
[16:29:45 CEST] <BBB> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[16:29:48 CEST] <BBB> what did you guys do
[16:30:23 CEST] <jamrial> got that while trying to push?
[16:30:33 CEST] <BBB> yes
[16:30:39 CEST] <atomnuker> nope, dry-run works fine for me
[16:31:11 CEST] <atomnuker> both ipv4 and ipv6
[16:31:21 CEST] <BBB> my push and fetch url are different, maybe thats why?
[16:31:33 CEST] <BBB> one is https, one is ssh
[16:31:42 CEST] <atomnuker> that's okay here
[16:31:46 CEST] <nevcairiel> when did you push last
[16:31:55 CEST] <nevcairiel> the server changed a few weeks  back
[16:32:02 CEST] <nevcairiel> which would trigger this
[16:32:06 CEST] <atomnuker> that was a month ago
[16:32:16 CEST] <BBB> Thu Apr 6 13:58:59 2017 -0400
[16:32:23 CEST] <nevcairiel> might be then
[16:32:54 CEST] <jamrial> BBB: https://mailman.videolan.org/pipermail/vlc-devel/2017-April/112787.html
[16:35:02 CEST] <BBB> ty
[16:35:09 CEST] <cone-006> ffmpeg 03Ronald S. Bultje 07master:ca2209d67af0: hevc: fix race condition in max_ra/seq_decode.
[16:35:10 CEST] <cone-006> ffmpeg 03Ronald S. Bultje 07master:d98f34d7d440: frame_thread_encoder: extend critical code covered by finished_task_mutex.
[16:35:29 CEST] <BBB> ok, so 2 bugs remaining: one for field decoding where owner doesnt match the processing AVCodecContext, and mpegvideo*
[16:35:38 CEST] <BBB> whoooooo wants to fix mpegvideo?
[16:35:56 CEST] <BBB> I promise free ice cream at the next vdd to whoever fixes mpegvideo
[16:36:19 CEST] <BBB> <and there was mere silence :(>
[16:37:45 CEST] <jamrial> isn't mpegvideo the one with the nightmarish all-purpose context?
[16:38:11 CEST] <BBB> yes
[16:38:18 CEST] <BBB> long live mpegvideo and dsputil
[16:41:55 CEST] <j-b> 'morning
[16:45:42 CEST] <BBB> aha! j-b will fix mpegvideo
[16:52:09 CEST] <j-b> haha
[16:52:17 CEST] <j-b> mpegvideo? is that still a thing?
[16:52:29 CEST] <nevcairiel> of course, for mpeg124
[16:53:23 CEST] <ubitux> so if anyone is ever confused at wtf these freaking aarch64 do based on the shitty doc, this may help: http://sprunge.us/TCdM
[16:53:58 CEST] <ubitux> (only the last lines matter)
[16:55:56 CEST] <iive> ubitux: NICE :D
[17:03:23 CEST] <ubitux> btw, i'm running a fate valgrind instance on a BBB since about 24h 
[17:03:27 CEST] <ubitux> it's ofc not done yet
[17:03:36 CEST] <BBB> lol
[17:03:37 CEST] <ubitux> one of my many brillant idea
[17:03:53 CEST] <ubitux> heh sorry i meant beaglebone black by "BBB"
[17:03:54 CEST] <BBB> and Im trying to encode a 4K video on my android phone
[17:04:04 CEST] <BBB> also a brilliant idea
[17:04:18 CEST] <ubitux> in software?
[17:04:23 CEST] <BBB> its a joke :D
[17:04:34 CEST] <ubitux> it's not a joke on my side :(
[17:04:45 CEST] <BBB> is there any reason you did that? do you expect that itll find issues that the x86 instance wont find?
[17:04:55 CEST] <BBB> or did you encounter bugs that warranted this?
[17:04:59 CEST] <BBB> or is this just exploratory?
[17:05:06 CEST] <ubitux> i like to do what people never did, especially if it's stupid
[17:05:11 CEST] <ubitux> you can call me an artist
[17:05:16 CEST] <BBB> uhm...
[17:05:24 CEST] <BBB> okaaaaaay...
[17:05:25 CEST] <ubitux> anyway, yeah i just wanted to do run valgrind on an arm board
[17:05:31 CEST] <BBB> :D
[17:05:36 CEST] <ubitux> and that was the only one i had left
[17:05:46 CEST] <ubitux> i mean, i also have a rpi1
[17:05:48 CEST] <BBB> so uhm
[17:05:51 CEST] <J_Darnley> "Unexpected."  "Never seen before."  "Unique."  "5/7"
[17:05:52 CEST] <BBB> while its running
[17:05:53 CEST] <ubitux> but i couldn't get fame until next year
[17:06:09 CEST] <BBB> does it fry chips and fish?
[17:06:20 CEST] <ubitux> while with the BBB i may have hope for next week
[17:06:21 CEST] <jamrial> BBB: i mean, x264 has arm optimizations, so maybe some people do encode videos on their phones :p
[17:06:24 CEST] <BBB> I mean, if youre an artist, you could just as well be pragmatic about it and use it to prep dinner
[17:06:33 CEST] <atomnuker> ubitux: speaking of aarch64, I compiled a kernel for my odroid c2 last night and had to have a water bottle filled with ice above to cool it
[17:06:41 CEST] <BBB> anyway
[17:06:45 CEST] <BBB> sorry Im teasing too much
[17:07:03 CEST] <ubitux> BBB: http://b.pkh.me/homelab.jpg  see the hanging one with the blue eth cable? that's the one
[17:07:06 CEST] <atomnuker> then it worked fine this morning with the mainline kernel and it doesn't boot now :/
[17:07:09 CEST] <BBB> I hope it finds issues, not that I like issues, but it would basically mean it was worth it
[17:07:30 CEST] <BBB> ubitux: you need to clean that up :D
[17:07:35 CEST] <ubitux> hehe, yeah
[17:08:11 CEST] <ubitux> BBB: i ran this with valgrind stable, so it will likely raise the same issue we hit from last time
[17:08:23 CEST] <ubitux> especially since i couldn't build ffmpeg with --disable-optimization, it will raise more issue
[17:08:42 CEST] <BBB> I thought that issue was avx related?
[17:08:46 CEST] <BBB> so that shouldnt occur on arm
[17:09:06 CEST] <ubitux> we have some uninitialized mem issue unrelated to avx
[17:09:16 CEST] <ubitux> https://bugs.kde.org/show_bug.cgi?id=378622
[17:09:18 CEST] <ubitux> https://bugs.kde.org/show_bug.cgi?id=378627
[17:09:23 CEST] <ubitux> these two will likely show up
[17:09:29 CEST] <ubitux> svn version wouldn't help though indeed
[17:10:23 CEST] <ubitux> maybe i should also run a tsan instance on that board&
[17:11:09 CEST] <ubitux> atomnuker: due to overheating or boot/kernel bug?
[17:11:25 CEST] <atomnuker> no, I think its the image
[17:11:41 CEST] <atomnuker> I used a nightly image and I guess it only *occasionally* works
[17:12:45 CEST] <ubitux> still 3.14.79 here
[17:13:08 CEST] <ubitux> it has "sensitive" stuff running, so i'm not experimenting on it
[17:13:21 CEST] <atomnuker> it worked great on mainline until it didn't though
[17:14:13 CEST] <atomnuker> personally I would never trust anything without a bios and x86 cpu
[17:14:51 CEST] <atomnuker> I bought a rpi v3 in october and guess what? its memory is crap
[17:15:38 CEST] <ubitux> yeah, these boards really suck
[17:15:39 CEST] <atomnuker> it kept rebooting when I tried to compile ffmpeg and if it didn't the compiler itself printed out some machine bug
[17:16:01 CEST] <ubitux> the only thing they don't suck is power, so i have a bunch of them to run all kind of different services instead of a single x86 machine
[17:16:17 CEST] <atomnuker> yeah. that's true, they're cheap to run
[17:16:54 CEST] <atomnuker> NUCs are pretty good too though, I hear atoms are not power hungry
[17:17:06 CEST] <atomnuker> though they're expensive, min 100 euros or so
[17:17:36 CEST] <ubitux> yeah i have two of them, but i use them as desktop and mediacenter
[17:17:37 CEST] <atomnuker> (about the same as an odroid c2 because of the huge tax bill you get if you order one)
[17:17:49 CEST] <ubitux> more appropriate usage than running single services
[17:18:23 CEST] <atomnuker> do you have any mips based devices?
[17:18:55 CEST] <ubitux> nope
[17:19:24 CEST] <ubitux> mmh maybe the edgerouter is running on mips, i should check
[17:20:02 CEST] <ubitux> Linux ubnt 3.10.14-UBNT #1 SMP Mon Nov 14 03:56:39 PST 2016 mips GNU/Linux
[17:20:06 CEST] <ubitux> yeah that's actually a mips
[17:20:16 CEST] <ubitux> but don't expect me to compile and run ffmpeg on my router
[17:23:19 CEST] <jamrial> your art has limits then :p
[17:23:35 CEST] <kierank> atomnuker: the point is to cross-compile ffmpeg
[17:23:37 CEST] <kierank> then run it on rpi
[17:23:47 CEST] <kierank> not that i am capable of that
[17:25:11 CEST] <atomnuker> kierank: even if it did run it would still cause the kernel to oops because the memory is faulty
[17:25:19 CEST] <kierank> that i have never seen
[17:25:44 CEST] <kierank> 15:25:46 up 56 days, 19:33,  1 user,  load average: 0.00, 0.01, 0.05
[17:25:47 CEST] <kierank> not bad for a rpi2
[17:26:00 CEST] <atomnuker> mine is okay if you don't load it as well
[17:26:37 CEST] <atomnuker> the 4 year old rpi I have is still running without issues, but those new models are shit
[17:27:03 CEST] <atomnuker> those wifi and bluetooth interface drivers on old stock kernels are horrible and I had to turn them off
[17:29:56 CEST] <ubitux> atomnuker: 4yr old rpi? rpi1 ?
[17:30:04 CEST] <atomnuker> yep, the first one
[17:30:10 CEST] <ubitux> so without any neon
[17:30:40 CEST] <ubitux> don't wanna try to add a fate tsan instance on it? :)
[17:30:43 CEST] <atomnuker> Features : half thumb fastmult vfp edsp java tls
[17:30:54 CEST] <atomnuker> sure, I have trust in it
[17:32:33 CEST] <atomnuker> I'll start compiling ffmpeg, hopefully won't take longer than a day
[17:32:40 CEST] <jamrial> isn't the first rpi like a pentium 2 performance wise? tsan could take days there...
[17:33:00 CEST] <kierank> get atomnuker to buy an rpi3 on prime now
[17:33:40 CEST] <atomnuker> I had an old pentium 2 NEC for 10 years but threw it away 4 or so years ago, wish I kept it
[18:08:16 CEST] <atomnuker> ubitux: tsan? what would be the point, its only a single cpu?
[18:08:55 CEST] <ubitux> i suppose you still have context switches :p
[18:09:22 CEST] <ubitux> the point is to test that are atomics in x86 also actually are on arm
[18:09:25 CEST] <ubitux> that kind of stuff
[18:09:38 CEST] <ubitux> test [instr] that are atomics
[18:23:36 CEST] <atomnuker> ubitux: how do I run fate tsan? just compile with --cc="clang -fsanitize=thread"?
[18:24:04 CEST] <jamrial> use --toolchain
[18:24:29 CEST] <ubitux> --toolchain=clang-tsan or gcc-tsan
[18:24:57 CEST] <atomnuker> and after it gets compiled?
[18:25:07 CEST] <ubitux> just run fate normalliz
[18:25:09 CEST] <ubitux> normally
[18:25:29 CEST] <ubitux> i use --extra-cflags=-fsanitize=thread --extra-ldflags=-fsanitize=thread though personally
[18:25:34 CEST] <ubitux> (instead of the toolchain)
[18:25:42 CEST] <ubitux> because of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308
[18:29:59 CEST] <ubitux> atomnuker: oh i forgot, make fate with THREADS
[18:30:21 CEST] <ubitux> i currently use THREADS=2 to limit reports
[18:31:41 CEST] <ubitux> atomnuker: this is my config: http://b.pkh.me/gcc-tsan.cfg
[18:37:33 CEST] <atomnuker> error: unsupported option '-fsanitize=thread' for target 'armv7l-unknown-linux-gnueabihf'
[18:37:46 CEST] <ubitux> ah, too bad :)
[18:37:51 CEST] <atomnuker> that's clang
[18:37:58 CEST] <atomnuker> I think the gcc -fsanitize one works
[18:38:05 CEST] <ubitux> ah? cool
[18:45:30 CEST] <atomnuker> libtsan0 is missing from raspbian's repo
[18:45:52 CEST] <atomnuker> based on debian 8.0 yet still hasn't seen packages newer than 2012
[18:47:11 CEST] <atomnuker> this is another reason why these arm boards suck, your choices are either outdated ubuntu with proprietary crap, outdated debian with some proprietary crap or outdated diy arch images with some proprietary crap
[18:47:19 CEST] <ubitux> https://archlinuxarm.org/platforms/armv6/raspberry-pi
[18:47:21 CEST] <ubitux> :°
[18:48:11 CEST] <atomnuker> 2500 km away from the sd card and the machine to do anything about it :/
[18:49:16 CEST] <ubitux> did you send into space?
[18:49:30 CEST] <ubitux> +it
[18:50:35 CEST] <ubitux> anyway, i can do it myself, i also have that board :p
[19:32:14 CEST] <jamrial> rcombs: i sent a couple more patches for audiotoolbox to the ml
[19:34:52 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:6d6fc4105b87: avcodec/diracdec: Factor quant matrix reads
[19:34:53 CEST] <cone-006> ffmpeg 03Michael Niedermayer 07master:b946bd8ef2c7: avcodec/diracdec: Fix off by 1 error in quant check
[21:20:10 CEST] <cbsrobot> durandal_1707: in the vf_upmixer sholdn't there be a delay on the ls and rs (or lb and rb) channels for the 5.1 upmix?
[21:20:43 CEST] <durandal_1707> cbsrobot: no
[21:21:45 CEST] <durandal_1707> delay is when it comes to your ears
[21:23:53 CEST] <cbsrobot> I tested a few upmix examples on http://forum.doom9.org/archive/index.php/t-152034.html
[21:24:24 CEST] <cbsrobot> and I find grezen sounds ok most of the times
[21:24:35 CEST] <cbsrobot> search fro grezen on that page
[21:25:00 CEST] <cbsrobot> in these upmixes the rear channels always get 0.02 seconds delay
[21:25:10 CEST] <durandal_1707> that commands are flawed
[21:25:17 CEST] <cbsrobot> and also a frequency cut for the rear channels
[21:25:19 CEST] <cbsrobot> ok
[21:25:31 CEST] <cbsrobot> I'll try your filter when I have time
[21:25:36 CEST] <durandal_1707> they do not phase shift rear channels with hilbert
[21:28:11 CEST] <durandal_1707> the filter works with single sample i could find
[21:28:46 CEST] <durandal_1707> it clearly separates sounds that is originating from rear channels
[21:29:20 CEST] <durandal_1707> using it on ordinary stereo files you get mediocre results
[21:30:17 CEST] <durandal_1707> if you can find more pro logic enxoded files let me know
[22:07:49 CEST] <rcombs> jamrial: oh sweet, I hadn't heard about that new filtering mechanism; looks super nice
[22:08:46 CEST] <jamrial> yeah, simplifies decoders like this a lot
[22:20:29 CEST] <atomnuker> ubitux: man what the hell, I tried a ton of different images and yet this damned blue light refuses to do its job
[22:20:35 CEST] <atomnuker> this thing seems utterly broken
[22:21:25 CEST] <atomnuker> it was behind a door, still in its cover and I was ssh'd typing when it just disconnected
[22:22:39 CEST] <atomnuker> well, so much for "made in korea", this thing seems straight out of their southern neighbours
[22:27:58 CEST] <atomnuker> piece of crap
[22:29:40 CEST] <jamrial> the odriod?
[22:29:48 CEST] <atomnuker> yeah
[22:33:06 CEST] <iive> atomnuker: btw, are you using the original power supply for the rpi3? i've heard that they are quite sensitive about their voltage levels.
[22:33:40 CEST] <atomnuker> yep, got a starter pack which had a 5v 2a supply
[22:35:01 CEST] <iive> :|
[22:36:38 CEST] <BBB> crap, koda is going zscale :(
[22:55:51 CEST] <ubitux> atomnuker :(
[00:00:00 CEST] --- Fri May 26 2017