[00:17:32 CEST] <Shiz> >ff_h2645 [00:17:33 CEST] <Shiz> excuse me [00:23:46 CEST] <wm4> isn't it wonderfully confusing [00:32:49 CEST] <cone-333> ffmpeg 03foo86 07master:bb7c55807090: avformat/dtsdec: detect core-less streams [00:32:50 CEST] <cone-333> ffmpeg 03James Almer 07master:e3df56f5b4d5: avformat/dtsdec: reduce the scope of crctab [01:21:53 CEST] <cone-333> ffmpeg 03Rostislav Pehlivanov 07master:770d3c85afad: vc2enc: do not print the lavc version if the bitexact flag is enabled [02:09:40 CEST] <Compn> [FFmpeg-devel] A Hackathon for Codec Develovers was in the spam dir [02:12:14 CEST] <Compn> at isp level :\ [02:19:18 CEST] <Daemon404> lol. Not My Problem! [02:19:24 CEST] Action: Daemon404 sleeps [02:51:27 CEST] <Daemon404> michaelni, my latest reply seems to have not gotten to the ml [02:51:33 CEST] <Daemon404> and/or llogan [02:51:44 CEST] <Daemon404> spam filter or something? [02:53:38 CEST] <llogan> Daemon404: i only see spam in the queue [02:53:48 CEST] <Daemon404> really? [02:54:08 CEST] <Daemon404> gmail shows it as sent 10 msn ago [02:54:10 CEST] <Daemon404> mins* [02:54:36 CEST] <Daemon404> oh there it is [02:54:40 CEST] <Daemon404> slow... [02:54:41 CEST] <Daemon404> weird [02:54:45 CEST] <Daemon404> anyway sleep [02:54:47 CEST] <Daemon404> 3am [02:54:48 CEST] <Daemon404> 2am* [02:55:15 CEST] <llogan> not sure why it was so slow. timnich probably would. [04:15:04 CEST] <cone-333> ffmpeg 03Michael Niedermayer 07master:e7a9b434c57c: fate: Add test for broken SPS (Ticket 2580) [06:26:43 CEST] <ffuser> Hi [06:28:14 CEST] <ffuser> Anybody couldn't feel libx264 performance drop on recently ffmpeg git? [06:29:50 CEST] <ffuser> I used 09.april build of ffmpeg. Today I was build 05.May ffmpeg [06:30:12 CEST] <ffuser> Then use for rtmp streaming [06:31:14 CEST] <ffuser> When I streaming rtmp libx264 stream, CPU Usage too higher than before build. and too many frame drops [06:31:34 CEST] <ffuser> Do not had framedrop on old version [06:32:15 CEST] <ffuser> Old version CPU Usage avg : 50~70% but today version Usage avg : 70~100% [06:32:28 CEST] <ffuser> at the same encoding option [09:07:26 CEST] <cone-666> ffmpeg 03Muhammad Faiz 07master:d2f73c3daf02: avfilter/avf_showcqt: add . [10:39:10 CEST] <cone-666> ffmpeg 03Paul B Mahol 07master:5b174dd3f133: avfilter/vf_waveform: fix order of graticule scale items [11:45:20 CEST] <ubitux> if i have a video frame where i need to zero the left and right edges (generally a small number of column, somewhere between 0 and let's say 5 or 6), is it more interesting to 1. process the edges in the main loop by inserting 2 small loop around the line processing code, 2. memset zero the whole frame and then process the "inside", 3. make a column pre (or post) processing after processing the inside [11:45:22 CEST] <ubitux> ? [11:46:27 CEST] <atomnuker> so you do postprocessing, right? [11:46:27 CEST] <durandal_1707> what's faster? [11:47:18 CEST] <atomnuker> if you zero it out before you do postprocessing you might get some undesirable effects (e.g. if you blur it'll also blend the black columns) [11:47:53 CEST] <ubitux> atomnuker: i process the frame except i have to make a zero padding of a few pixels; i'm asking what approach is more likely to be optimal to achieve that [11:48:00 CEST] <ubitux> atomnuker: it's a 1:1 pixel processing, no surrounding [11:48:07 CEST] <ubitux> durandal_1707: that's the question :) [11:49:03 CEST] <ubitux> i'm afraid 1 will cause branching slowdown, 2 being "do too much" and 3 will have cache issues [11:49:52 CEST] <wm4> you could allocate the frame with calloc, which will use mmap, which will use a kernel background thread to zero pages [11:50:07 CEST] <ubitux> wm4: i'm reusing that buffer a lot [11:50:27 CEST] <ubitux> should i re-allocate it everytime instead? [11:51:19 CEST] <ubitux> (wm4: btw, av_calloc is calling memset :p) [11:51:30 CEST] <wm4> that's because av_calloc is stupid [11:51:32 CEST] <nevcairiel> for some reason we dont like using actual calloc [11:51:37 CEST] <nevcairiel> probably because no alignment [11:51:46 CEST] <ubitux> yes that's because of align ofc [11:54:30 CEST] <ubitux> i might use a different trick in the end but anyway [11:54:56 CEST] <ubitux> i'm curious of the general consensus on doing this since it looks like common [11:58:33 CEST] <durandal_1707> why not remove libwavpack wrapper? [12:01:19 CEST] <atomnuker> the native encoder was kinda slow and a bit less efficient last time I tested it [12:27:51 CEST] <durandal_1707> you tested only default, with no args [12:27:53 CEST] <durandal_1707> ? [12:41:25 CEST] <durandal_1707> and you compared with wrapper which supports only s32 sample format [12:41:47 CEST] <durandal_1707> or wavpack itself? [12:43:12 CEST] <atomnuker> I did try optimize_mono (file was a 10 second mono sine wave from lavfi) [12:43:26 CEST] <atomnuker> I don't think I tried compression_level though [13:59:50 CEST] <JEEB> hmm, the last time I tried the H.264-in-movlike muxing wasn't completely broken [14:00:02 CEST] <JEEB> unless mov specifically doesn't handle edit lists [14:36:06 CEST] <Daemon404> i wonder how many bug reports can be summed up with "my file sucks, halp" [14:44:48 CEST] <atomnuker> could someone try to convince the libav not to center the new bitstream writing API around reading while there's still a chance? [14:45:11 CEST] <atomnuker> just to have every single function doing reading to have the prefix bitstream_read_xxx() [14:45:57 CEST] <atomnuker> because it's going to bother me quite a lot to one day have the writing API changed and see bitstream_skip and bitstream_write_skip instead of bitstream_read_skip and bitstream_write_skip [14:47:13 CEST] <Daemon404> atomnuker, reply on the ml [14:48:34 CEST] <atomnuker> no subscription [14:49:49 CEST] <Daemon404> "i really dont waht x to happen, but i cant be arsed to do anything" [14:50:04 CEST] <iive> atomnuker: subscribe [14:51:12 CEST] <iive> you could probably try to hang in their irc channel and discuss it there [14:51:43 CEST] <iive> they do prefer more immediate communication methods [14:52:35 CEST] <Daemon404> sometimes irc is better [14:52:40 CEST] <Daemon404> email can sometimes fan flames [14:52:43 CEST] <Daemon404> and misunderstanding [15:00:05 CEST] <BBB> michaelni: ty for review, will fix these [15:00:34 CEST] <BBB> michaelni: as for const in int16_t *rgb[3], its broken const-ness in C which is why its not const [15:00:40 CEST] <BBB> michaelni: Ill fix the other const and comments [15:34:23 CEST] <Daemon404> nevcairiel, pingpong [15:39:05 CEST] Action: nevcairiel is sleepy [15:39:22 CEST] Action: nevcairiel goes back to sleep before Daemon404 spots him [15:40:01 CEST] <Daemon404> nevcairiel, do you have time soon (tm) to help with h2645 nals? [15:40:15 CEST] <Daemon404> i dont think i am capable of doing that without a huge amount of research [15:40:49 CEST] <nevcairiel> tomorrow i guess, going to step out soon [15:41:03 CEST] <Daemon404> ok [16:04:24 CEST] <cone-261> ffmpeg 03Rick Kern 07master:f1560dbb2a00: lavd/avfoundation: use AVCodecParameters [17:09:29 CEST] <roxlu_> Hi, what does ffmpeg use to convert audio samplerates? [17:10:40 CEST] <roxlu_> oh I guess it's the libswresample ? [17:10:46 CEST] <wm4> yes [17:13:27 CEST] <Shiz> you can use that directly or use libavfilter which uses swresample internally [17:15:46 CEST] <roxlu_> Ok, thanks Shiz [17:16:11 CEST] <roxlu_> I was wondering, when I convert van 32hz to 44.1hz will I get noticeable artifacts? [18:00:23 CEST] <JEEB> lol libutvideo [18:12:15 CEST] <Daemon404> BBB, https://hg.mozilla.org/mozilla-central/file/tip/media/ffvpx [18:12:18 CEST] <Daemon404> have you seen this [18:12:26 CEST] <Daemon404> they seem to have forked and cut down to ffvpx [18:12:35 CEST] <BBB> rofl :D [18:12:37 CEST] <BBB> no [18:12:41 CEST] <BBB> but its hilarious [18:13:02 CEST] <Daemon404> (found via JEEB) [18:13:13 CEST] <JEEB> yeah, I was like "wut, why doesn't this thing have libav*.dll [18:13:18 CEST] <Daemon404> "AVX2 must be disabled on Linux due to the use of yasm 1.1 on the build bots." [18:13:21 CEST] <Daemon404> readme has some gems [18:13:31 CEST] <JEEB> then went into the commit logs and found it cut out [18:13:33 CEST] <JEEB> :D [18:13:43 CEST] <BBB> this is utterly amazing [18:13:47 CEST] <BBB> I love it [18:14:14 CEST] <Daemon404> why are they disabling asm on some platforms, its so odd [18:14:18 CEST] <wm4> mozilla never ceases to amaze [18:14:29 CEST] <BBB> yasm 1.1 doesnt support avx2? [18:14:33 CEST] <BBB> (I suppose) [18:14:39 CEST] <JEEB> it's really, really old [18:14:40 CEST] <BBB> you could upgrade yasm, but why would you do that [18:14:42 CEST] <BBB> thats effort [18:14:43 CEST] <JEEB> like 2011 old [18:14:47 CEST] <Daemon404> anyone know what their "unix32" platform is [18:14:59 CEST] <Daemon404> theyre hard disabling posix_memalign, for example, on it [18:15:03 CEST] <Daemon404> which seems all sorts of wrong [18:15:32 CEST] <cone-261> ffmpeg 03Paul B Mahol 07master:c5d2d3dced64: avcodec/alac: fix 20-bit support [18:15:35 CEST] <JEEB> inb4 common unixy 32bit one [18:15:59 CEST] <BBB> isnt posix_memalign mac-only? [18:16:12 CEST] <Daemon404> no it's linux [18:16:29 CEST] <Daemon404> and bsd [18:16:55 CEST] <Daemon404> i wonder if it has to do with mozilla using jemalloc [18:16:59 CEST] <Daemon404> or some custom allocator [18:17:01 CEST] <Daemon404> (probably) [18:18:05 CEST] <Daemon404> https://hg.mozilla.org/mozilla-central/file/tip/media/ffvpx/libavutil_visibi... <-- or this [18:18:41 CEST] <wm4> ? [18:19:03 CEST] <Daemon404> it seems odd to say the least [18:20:48 CEST] <BBB> ubitux: mozilla loves you ^^ [18:21:19 CEST] <BBB> theres no darwin32.asm [18:21:41 CEST] <Daemon404> look at the mozilla readme [18:21:43 CEST] <Daemon404> they hard disable it [18:22:19 CEST] <ubitux> BBB: mmh? how so [18:22:32 CEST] <BBB> wth [18:22:38 CEST] <BBB> they disable all assembly on 32bit? [18:22:48 CEST] <Daemon404> for darwin [18:22:51 CEST] <BBB> is that b/c we dont allow relocations (-fPIC) on 32bit? [18:22:59 CEST] <BBB> for linux (unix32) also [18:23:27 CEST] <jamrial> firefox 46 (out for a week by now) supposedly already uses ffvp9 [18:23:40 CEST] <Daemon404> BBB, they also hard disable aligned alloc... [18:23:52 CEST] <Daemon404> im thinking maybe their own allocator (jemalloc) isnt aligned enough on 32? [18:23:55 CEST] <Daemon404> just a guess. [18:23:55 CEST] <BBB> on 32bit linux [18:23:59 CEST] <BBB> strange [18:24:24 CEST] <BBB> well I hope it works for them [18:24:53 CEST] <JEEB> I have completely lost the idea of what's available with which version as I've been on either the nightlies or the dev. edition for so long [18:25:32 CEST] <Daemon404> actually you can maybe ask jya [18:25:38 CEST] <Daemon404> he works on firefox's video stuff iirc. [18:25:40 CEST] <Daemon404> and is in here. [18:26:58 CEST] <BtbN> philipl, did you ever test the lossless nvenc modes? I'm quite sure they don't work at all on Kepler, but aparently they also don't work on maxwell, where they should work? [18:28:20 CEST] <ffuser> not work here too, gtx660 [18:29:54 CEST] <BtbN> that's not maxwell [19:01:53 CEST] <BtbN> hm, was hoping i could get an AWS GPU instance to test with, but it's Kepler. [19:02:53 CEST] <llogan> BtbN: they offer grid k520 or something like that right? [19:03:01 CEST] <BtbN> yep, exactly that. [19:03:09 CEST] <BtbN> or some older Fermi one, which doesn't help. [19:03:50 CEST] <BtbN> My Laptop has a Maxwell GPU, but they removed the video unit, or blocked using it. [19:04:11 CEST] <BtbN> no vdpau, no nvenc. [19:07:14 CEST] <llogan> maybe the project could buy one for dev use [19:07:48 CEST] <kierank> vlc has one iirc [19:08:18 CEST] <BtbN> Unfortunately there is no cheap GT Maxwell card, like i got myself for the initial nvenc stuff. It was like 40¬. [19:10:23 CEST] <Compn> j-b : is there a process or form to get reimbursed for hardware dev purchases? ^^^ [19:11:04 CEST] <BtbN> The problem with a more powerfull Maxwell GTX card is that I'm quite sure my sandybridge-generation mainboard would die. [19:11:27 CEST] <nevcairiel> the cheapest is the gtx750 for around 100 [19:11:50 CEST] <BtbN> 750 is maxwell? [19:11:57 CEST] <nevcairiel> yes [19:12:07 CEST] <BtbN> Does it already have the new nvenc stuff? [19:12:42 CEST] <nevcairiel> i dont know when that was introduced [19:12:56 CEST] <BtbN> there are basically two maxwell generations. [19:13:03 CEST] <JEEB> I think the 750 was released around the time of the 960 [19:13:09 CEST] <nevcairiel> no the 750 is much older [19:13:13 CEST] <JEEB> oh [19:13:14 CEST] <nevcairiel> it was the very first maxwell card ever [19:13:14 CEST] <JEEB> ok [19:13:26 CEST] <JEEB> yeah, then it has an older HWenc [19:13:39 CEST] <BtbN> I'm quite sure for all the new nvenc and vdpau features one needs a GM20x chip [19:13:50 CEST] <BtbN> according to Wikipedia the 750 has a GM107 [19:14:05 CEST] <nevcairiel> for the full decode features you need one specific chip, the GM206, which is only on gtx950 and 960 [19:14:35 CEST] <BtbN> strange stuff. [19:14:50 CEST] <BtbN> There is also a GT930 rumored to be released at some point, with a GM108 [19:14:53 CEST] <BtbN> whatever that is [19:15:00 CEST] <nevcairiel> its just newer then the others, and got the newer media chip [19:15:06 CEST] <llogan> the gtx 950 isn't terribly expensive. ~$140 USD [19:15:06 CEST] <wm4> is here a nvidia chip which actually does 4:4:4? [19:15:13 CEST] <nevcairiel> the next generation will likely inherit this [19:15:18 CEST] <JEEB> wm4: supposedly yes [19:15:32 CEST] <JEEB> the driver has 4:4:4 encoding and decoding modes, IIRC [19:15:35 CEST] <wm4> oh wait the GPU I have pretends to support 4:4:4 [19:15:38 CEST] <nevcairiel> oddly enough there is 444 encoding but not decoding =p [19:16:02 CEST] <wm4> H264_HIGH_444_PREDICTIVE [19:16:31 CEST] <llogan> kierank: how can we get our grubby hands on the vlc one? [19:16:39 CEST] <kierank> ask j-b [19:17:27 CEST] <BtbN> I'll get a new PC this christmas, hopefully Intel and Nvidia have their next generations out by then. [19:17:37 CEST] <nevcairiel> nvidia launches in summer [19:17:50 CEST] <nevcairiel> intel, who knows when [19:17:58 CEST] <BtbN> Yeah, Nvidia isn't the one I'm worried about. [19:18:07 CEST] <BtbN> But Kaby Lake would be nice to have [19:18:20 CEST] <BtbN> 10bit HEVC via VAAPI... [19:19:25 CEST] <llogan> Maybe Agatha will give you an nvidia [19:22:06 CEST] <wm4> BtbN: when is that supposed to come out? [19:22:14 CEST] <BtbN> Kaby Lake? [19:22:38 CEST] <wm4> yeah [19:22:41 CEST] <BtbN> "anticipated to enter volume production towards late-2016" [19:22:54 CEST] <wm4> and wasn't Broxton cancelled or something? [19:23:18 CEST] <BtbN> Cannonlake was delayed [19:23:31 CEST] <BtbN> and they release Kaby Lake instead, which is just some minor refresh of Skylake [19:23:41 CEST] <wm4> meh all those codenames [19:24:02 CEST] <BtbN> Broxton is a SoC Platform iirc [19:24:42 CEST] <Compn> are we supposed to optimize for possible vaporware or flop hard ware ? [19:33:49 CEST] <rcombs> Broxton is supposed to have HEVC Main 10 decoding [19:34:18 CEST] <BtbN> i guess because it contains the Kaby Lake CPU/GPU [19:39:56 CEST] <rcombs> (at least, so says the vaapi intel driver repo) [19:46:45 CEST] <nevcairiel> guess we'll never know that now that broxton is dead =p [19:46:46 CEST] <jkqxz> Apollo Lake (Braswell++) isn't cancelled (yet) and will have it. [19:46:53 CEST] <fritsch> :-( [19:47:24 CEST] <fritsch> i really waited for broxton [19:47:26 CEST] <jkqxz> (Core the same as Broxton, different SoC.) [19:47:29 CEST] <fritsch> great potential as set top box [19:47:34 CEST] <fritsch> and cheap [19:48:13 CEST] <nevcairiel> broxton is smartphone/tablet market, apollo lake always was meant as the braswell replacement for NUCs et al [19:49:45 CEST] <fritsch> ETA? end 2016 right? [19:50:01 CEST] <nevcairiel> probably there abouts [19:54:29 CEST] <wm4> fritsch: so what's the vaapi 10 bit situation? [20:04:13 CEST] <fritsch> wm4: driver has it all [20:04:22 CEST] <fritsch> wm4: ffmpeg needs the 10 bit bits [20:04:37 CEST] <fritsch> wm4: and no one replied to our "we need a 16 bit mesa egl interop" [20:05:37 CEST] <fritsch> the hevc 8 to 10 bit in the driver was just 4 fields iirc [20:05:46 CEST] <fritsch> so that one should not be too much work [20:06:03 CEST] <fritsch> but without hw to test it's not really something one can accomplish yet [20:06:10 CEST] <nevcairiel> Did they define a proper output format yet? [20:06:31 CEST] <fritsch> from the driver they use vaPutSurface with RGB [20:06:47 CEST] <fritsch> they defined some P010 format (i always forget the name) [20:07:33 CEST] <fritsch> a) https://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=daf8f6c76287452f2... [20:07:46 CEST] <fritsch> b) https://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=8fadc325d12b86e06... [20:09:11 CEST] <fritsch> #define I_P010 2, 2, 2, {I965_16BITS, I965_8BITS}, 3, { {PLANE_0, OFFSET_0}, {PLANE_1, OFFSET_0}, {PLANE_1, OFFSET_16} } [20:11:07 CEST] <wm4> please not through rgb... [20:11:25 CEST] <fritsch> they need to do that [20:11:33 CEST] <fritsch> as it needs vaPutSurface comaptibility [20:11:46 CEST] <fritsch> but - we want the "real" layoutted surface without vpp processing [20:11:49 CEST] <wm4> yeah, but if that's the only path [20:11:57 CEST] <fritsch> for now - it is, yes :-( [20:12:08 CEST] <fritsch> as we can only map NV12 and RGBA [20:12:19 CEST] <fritsch> in theory from the "bits" it should fit into RGBA [20:12:23 CEST] <wm4> what's the problem with 16 bit support? [20:12:33 CEST] <llogan> that ticket will now never close [20:12:36 CEST] <fritsch> it's not there yet - we only have G8B8 or something [20:12:40 CEST] <fritsch> in the mesa thingy [20:13:48 CEST] <fritsch> 32 bit RGBA should be fine (as transport) but I did not look into detail, if one could "tunnel" the 16 bit layouted buffers that way ... [20:14:03 CEST] <fritsch> though the shaders at our other end don't care (can be made to not care) [20:14:45 CEST] <wm4> same here [20:32:02 CEST] <JEEB> holy... [20:32:15 CEST] <JEEB> would've not thought I'd already see test streams for AC-4 or MPEG-H Audio [20:35:06 CEST] <JEEB> http://dashif.org/test-vectors/#MCA_DOLBY [20:35:15 CEST] <JEEB> and then if one scrolls down there's MPEG-H [20:35:32 CEST] <wm4> wtf is mpeg-h [20:35:42 CEST] <JEEB> where HEVC resides [20:35:56 CEST] <JEEB> there was a theoretical audio format there... I guess it got finalized'ish? [20:37:02 CEST] <JEEB> yeah, seems to have been published late last year https://www.itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG-H [20:37:11 CEST] <JEEB> (Part 3= [20:37:34 CEST] <Shiz> great, a new container [20:37:42 CEST] <Shiz> JEEB: >3D audio [20:37:44 CEST] <Shiz> OUT [20:37:48 CEST] <JEEB> the MMT thing is weird [20:37:53 CEST] <JEEB> like, really weird [20:38:06 CEST] <JEEB> I might have understood it at some point but it seems like a metacontainer [20:38:10 CEST] <JEEB> rather than an actual container [20:38:24 CEST] <JEEB> bases a lot on ISOBMFF [20:38:49 CEST] <Daemon404> object-based audio: for 0 people's home setups [20:38:58 CEST] <Daemon404> unless i replace all my walls with speakers [20:43:45 CEST] <wm4> "finding ways to make money with patented garbage" [20:45:55 CEST] <rcombs> isn't 3D audio aka fancy stereo [20:46:33 CEST] Action: rcombs crosses fingers AC-4 never gains adoption [20:54:35 CEST] <rcombs> JEEB: AC-4: http://puu.sh/oHpDD/348f7d6867.png [20:55:57 CEST] <JEEB> :D [20:55:59 CEST] <JEEB> pretty much [20:57:12 CEST] <TD-Linux> so AC-4 is different than Dolby Atmos Home Theater? [20:57:39 CEST] <JEEB> if it's object based stuff then it's highly likely that one is the marketing name for the other [20:57:49 CEST] <nevcairiel> no its a different format [20:57:53 CEST] <JEEB> ah [20:58:34 CEST] <nevcairiel> they seem to target ac-4 at broadcast more directly [21:00:14 CEST] <TD-Linux> I guess broadcast has different requirements, such as the format not being secret [21:01:16 CEST] <JEEB> it can be very close to that, though. looking at the DTS "specs" :) [21:01:24 CEST] <nevcairiel> who broadcasts dts? [21:01:28 CEST] <Daemon404> america [21:01:32 CEST] <nevcairiel> really? [21:01:37 CEST] <nevcairiel> i though its all ac3 or mp2 [21:02:07 CEST] <TD-Linux> we also use 8VSB. sorry [21:02:18 CEST] <JEEB> they tried to push it at least, but I have no idea if it's actually used [21:02:40 CEST] <JEEB> just saying that getting into the race doesn't require the spec to be complete :) [21:02:41 CEST] <Daemon404> dts is in atsc [21:02:47 CEST] <JEEB> oh lol [21:03:21 CEST] <rcombs> Amos is an extension stream in TrueHD, right? [21:03:25 CEST] <rcombs> *Atmos [21:03:27 CEST] <nevcairiel> isnt A/52 even a ATSC spec [21:03:29 CEST] <rcombs> or can it also be carried separately [21:03:49 CEST] <wm4> I still wonder whether or not atmos passthrough works with the ffmpeg spdif muxer [21:03:53 CEST] <nevcairiel> rcombs: the consumer variant is just an extension on top of an existing 5.1 or 7.1 stream [21:04:03 CEST] <nevcairiel> wm4: works for my users, or so they claim [21:04:09 CEST] <rcombs> "works" [21:04:19 CEST] <rcombs> "turns on the atmos light" [21:04:25 CEST] <wm4> yeah that [21:04:27 CEST] <Daemon404> nevcairiel, who the hell has atmos equpment at home [21:04:29 CEST] <wm4> the light is the important part [21:04:31 CEST] <nevcairiel> dunno [21:04:32 CEST] <nevcairiel> not me [21:04:37 CEST] <nevcairiel> i dont even use a HDMI receiver anymore [21:04:42 CEST] <rcombs> I have a receiver that allegedly supports it [21:04:47 CEST] <rcombs> (for testing the LED) [21:04:56 CEST] <JEEB> :D [21:05:10 CEST] <JEEB> those magical leds [21:05:17 CEST] <rcombs> apparently it supports height channels [21:05:29 CEST] <nevcairiel> yeah consumer atmos is just height channels so far, either 2 or 4 [21:05:32 CEST] <rcombs> (only if you don't use the surround-back channels) [21:05:36 CEST] <nevcairiel> on top of a base surround signal [21:06:45 CEST] <rcombs> iirc they call it 5.1.2 [21:06:53 CEST] <nevcairiel> indeed [21:07:04 CEST] <nevcairiel> the 5.1 signal is just base truehd and untoucehd by the extension [21:07:05 CEST] <rcombs> can't do 7.1.2 'cause that would require more physical equipment [21:07:16 CEST] <wm4> (lol) [21:07:18 CEST] <nevcairiel> there are receivers with full 7.1.4 [21:07:24 CEST] <nevcairiel> you just cheaped out! [21:07:25 CEST] <nevcairiel> :D [21:07:35 CEST] <rcombs> my setup's just 5.1 [21:07:42 CEST] <rcombs> like, y'know, everybody [21:08:05 CEST] <nevcairiel> i have 7.1 [21:08:09 CEST] <nevcairiel> although no height channels [21:08:16 CEST] <nevcairiel> (or an atmos receiver for that matter) [21:08:29 CEST] <rcombs> I have an atoms receiver [21:08:41 CEST] <rcombs> it's made entirely of matter [21:10:01 CEST] <cone-261> ffmpeg 03Petru Rares Sincraian 07master:7a679e4ac099: fate: Add test for vorbis encoder [21:16:00 CEST] <jamrial> why do we still have that encoder? we even discourage it's use everywhere it's mentioned [21:17:45 CEST] <Daemon404> jamrial, in case war breaks out [21:17:49 CEST] <Daemon404> we can use it as a weapon [21:19:02 CEST] <jamrial> i mean, it's apparently so bad that not even the ogg muxer dares using it as a default if libvorbis is missing. it uses FLAC instead [21:32:17 CEST] <durandal_1707> clueless people are clueless [21:35:57 CEST] <RiCON> jamrial: isn't that because it needs -strict or something? [21:47:03 CEST] <jamrial> ah, true [21:51:53 CEST] <TD-Linux> Daemon404, less a weapon and more a doomsday device [22:26:14 CEST] <Daemon404> 42 [22:28:08 CEST] <durandal_1707> yes, answer to universe and everything [00:00:00 CEST] --- Fri May 6 2016