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

[burek]

[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_visibility.h <-- 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=daf8f6c76287452f2bc37af83d9078831ba0a8b0
[20:07:46 CEST] <fritsch> b) https://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=8fadc325d12b86e06aa3deb5a1e5c6298ad4b89a
[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