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

[burek]

[03:14:44 CET] <cone-169> ffmpeg 03Felipe Astroza 07master:b7665642f18a: libavformat/tee: tee was passing a wrong option name for fifo's format_options
[05:32:17 CET] <cone-169> ffmpeg 03Steven Liu 07master:2f7cc21b6122: avformat/hlsenc: refine the code readable for time unit
[05:32:18 CET] <cone-169> ffmpeg 03Steven Liu 07master:1bb192ef6c17: avformat/flvenc: refine the flvenc shift_data code
[10:24:19 CET] <cone-757> ffmpeg 03Paul B Mahol 07master:08e5732318a4: avfilter: add EIA-608 line extractor
[12:05:07 CET] <mateo`> michaelni: can you give a try at the next merge branch (https://github.com/mbouron/FFmpeg/tree/merge-libav), green-block-artifacts-from-canon-100-hs.MOV is no more green anymore
[12:06:54 CET] <ubitux> you probably want to update that branch with the latest version of the attachment-631 race fix
[12:07:02 CET] <ubitux> michaelni: could you push that one btw?
[12:07:08 CET] <ubitux> (assuming it works ofc)
[12:09:21 CET] <mateo`> i'll apply michael patch on top of the merge branch and see if all goes well (and disable our test)
[12:26:42 CET] <cone-757> ffmpeg 03Michael Niedermayer 07master:25f4f08ba5b4: avcodec/h264dec: Fix regression with "make fate-h264-attachment-631 THREADS=8"
[12:27:04 CET] <mateo`> fate THREADS=8 and fate THREADS=1 pass on the merge branch with michael applied on top, green-block-artifacts-from-canon-100-hs.MOV is still ok
[12:54:40 CET] <michaelni> ubitux, this is green: ./ffplay -threads 1 -i ~/tickets/1069/green-block-artifacts-from-canon-100-hs.MOV
[12:55:22 CET] <ubitux> michaelni: mateo` says it's not on the latest branch, i'm not available for testing right now, see with him
[12:55:34 CET] <ubitux> he was the one to fix that
[12:56:29 CET] <michaelni> ahh ok, iam a bit behind
[13:01:08 CET] <mateo`> i can update the branch (to include michael's patch on top if needed)
[13:01:43 CET] <mateo`> michaelni: are you using this branch https://github.com/mbouron/FFmpeg/tree/merge-libav ?
[13:02:21 CET] <mateo`> HEAD is at af5c3de0961f21c2bbfe7aa6aa38554deb967f8a
[13:05:52 CET] <michaelni> yes iam doing now
[13:16:48 CET] <durandal_1707> atomnuker: would you recognize mdct code if its badly obfuscated?
[13:18:20 CET] <atomnuker> sure
[13:18:27 CET] <atomnuker> forward or inverse?
[13:26:50 CET] <durandal_1707> atomnuker: working on atrac9 decoder, main function uses 4 tables of doubles of 256 elements
[13:27:40 CET] <durandal_1707> each table have 256 elements
[13:31:41 CET] <durandal_1707> atomnuker: https://paste.ubuntu.com/23857519/
[13:39:57 CET] <atomnuker> durandal_1707: huh, that's odd, it does a very forward-mdct-like folding (if ( result >= 4 )) in the front
[13:40:15 CET] <atomnuker> does the program have an encoder as well?
[13:40:29 CET] <durandal_1707> yes
[13:49:38 CET] <atomnuker> a3 in the arguments is a flag to switch between a forward and inverse
[13:50:17 CET] <atomnuker> if ( a3 - 2 >= 0 ) is the fft (a3 seems to vary between 2 (inverse) and 3 (forward))
[13:50:48 CET] <atomnuker> the second if ( result >= 4 ) is the forward mdct post-rotation
[13:51:34 CET] <atomnuker> the first if ( v7 < result ) is the inverse twiddle pre-multiply
[13:52:28 CET] <atomnuker> the last section (if ( v59 < result )) is a the inverse post twiddle rotation
[13:53:17 CET] <atomnuker> seems pretty standard, our mdct should work
[13:56:32 CET] <durandal_1707> a3 is 8 for 48000 sample rate input
[14:04:36 CET] <atomnuker> durandal_1707: back, can you decode the coefficients yet?
[14:08:20 CET] <durandal_1707> atomnuker: thats stranges it have getbits1 and im still exploring binary
[14:11:59 CET] <durandal_1707> atomnuker: i just have numbers from those 4 tables i captured from app while it was running
[14:12:38 CET] <durandal_1707> i will work on coefficients later
[14:14:35 CET] <atomnuker> those are the twiddles
[14:20:09 CET] <durandal_1707> atomnuker: they are doubles not integers afaic
[14:23:03 CET] <atomnuker> well, yeah, they need to be the same as the sample format since the samples get multiplied by them
[14:27:18 CET] <durandal_1707> and a3 is 8 for highest bitrate and samplerate combo
[14:52:58 CET] <mateo`> ubitux: i ll rebase the merge on top of master
[14:54:10 CET] <ubitux> sure
[14:54:41 CET] <ubitux> you might want to drop the merge of the next commit
[15:08:37 CET] <michaelni> mateo`, cant find a failure with af5c3de096
[15:12:26 CET] <ubitux> yey.
[15:18:51 CET] <mateo`> ubitux: rebased branch -> https://github.com/mbouron/FFmpeg/tree/merge-libav
[15:19:00 CET] <mateo`> the commit message still needs to be edited though
[15:20:31 CET] <ubitux> yeah, i can do that if you want
[15:20:55 CET] <ubitux> so do we want to merge the 2nd commit including the FATE test as well inside the merge?
[15:21:22 CET] <mateo`> ubitux: you can edit the message if you feel inspired :D
[15:21:28 CET] <mateo`> (because i kind of don't atm)
[15:23:19 CET] <ubitux> gonna make a few cleanups but yeah it should be ready to go
[15:25:27 CET] <mateo`> i'll soon be afk for 5 hours so, i would feel more confident in life if i know the merge is applied before the end of day :D
[15:25:55 CET] <mateo`> i wonder what will be the next blocker though
[15:27:27 CET] <ubitux> i should be done with what i'm currently doing in an hour or two, then i'll cleanup the merge and work on the next ones
[15:27:36 CET] <ubitux> til i reach the next blocker and whine about it
[15:28:59 CET] <cone-757> ffmpeg 03Steven Liu 07master:1033f56b074d: avformat/hlsenc: improve to write m3u8 head block
[15:29:07 CET] <mateo`> you mean the hevc ones ? :D
[15:29:27 CET] <mateo`> lot of fun ahead...
[16:18:13 CET] <cone-757> ffmpeg 03Anton Khirnov 07master:4a9bab3db0d9: h264: fix decoding multiple fields per packet with slice threads
[16:18:14 CET] <cone-757> ffmpeg 03Anton Khirnov 07master:38efff92f1ef: FATE: add a test for H.264 with two fields per packet
[16:18:15 CET] <cone-757> ffmpeg 03Clément BSsch 07master:744801989099: Merge commit '38efff92f1ef81f3de20ff0460ec7b70c253d714'
[16:18:20 CET] <ubitux> mateo` ^
[16:19:45 CET] <ubitux> can anyone who can test dxva merge the next commit?
[16:25:11 CET] <wm4> which one is that?
[16:25:41 CET] <ubitux> 33f6690eb4 hevc: offer DXVA2 for 10bit 420
[16:25:43 CET] <ubitux> a8fce24b9c avconv_dxva2: support HEVC Main10 decoding
[16:25:59 CET] <wm4> I think we support this in ffmpeg
[16:26:04 CET] <wm4> not sure if they can just be skipped
[16:26:08 CET] <ubitux> the 2nd one is indeed under nevcairiel's name
[16:26:20 CET] <ubitux> but the first one looks somehow not upstream
[16:27:12 CET] <ubitux> but as i can't test, i'd better have someone more comfortable with that merge these two
[16:27:18 CET] <wm4> yeah you can skip those commits
[16:27:22 CET] <ubitux> so i can continue the merge effort
[16:27:26 CET] <ubitux> you sure about that?
[16:27:31 CET] <wm4> yes, 100%
[16:27:45 CET] <ubitux> why isn't 10-bit support present in our set_sps() function?
[16:27:45 CET] <wm4> for 33f6690eb4 and a8fce24b9c
[16:28:00 CET] <wm4> let me check
[16:28:03 CET] <ubitux> oh actually it might be
[16:28:13 CET] <wm4> yes it is
[16:28:18 CET] <ubitux> alright
[16:28:24 CET] <ubitux> i'll skip both then
[16:28:26 CET] <ubitux> thx
[16:28:30 CET] <wm4> the code is just weirdly different, but it works for us
[16:28:37 CET] <ubitux> i see
[16:29:08 CET] <wm4> (both suck a bit... this should be totally cleaned up by letting the hwaccels signal the pixfmts)
[16:32:45 CET] <cone-757> ffmpeg 03Anton Khirnov 07master:33f6690eb4e2: hevc: offer DXVA2 for 10bit 420
[16:32:46 CET] <cone-757> ffmpeg 03Clément BSsch 07master:5f74ce0e4d5a: Merge commit '33f6690eb4e21acc4b581688eecfc4cc5ea9515e'
[16:34:45 CET] <cone-757> ffmpeg 03Hendrik Leppkes 07master:a8fce24b9c5a: avconv_dxva2: support HEVC Main10 decoding
[16:34:46 CET] <cone-757> ffmpeg 03Clément BSsch 07master:8504d64bcbd1: Merge commit 'a8fce24b9c5a87187f5bd864b18f5b3e575f8c3d'
[16:36:16 CET] <ubitux> alright, where is my arm toolchain now.
[17:10:49 CET] <BBB> is anyone interested in reading/commenting on the swscale wiki doc? maybe kierank?
[17:13:15 CET] <ubitux> the "dither" thing i mention in the dumped log could be "extracted"
[17:13:20 CET] <ubitux> but /lazy
[17:19:26 CET] <kierank> Yes will do tomorrow
[17:24:51 CET] <wm4> I should look into whether swscale can be replaced by zimg
[17:26:05 CET] <atomnuker> zimg is c++ and uses intrinsics
[17:26:18 CET] <Compn> would be interesting to have support for multiple swscalers , like gimp, imagemagick, zimg etc
[17:26:34 CET] <Compn> ffmpeg -scaler zimg or -scaler sws :P
[17:26:52 CET] <jamrial> well, we do that with swresample
[17:26:59 CET] <jamrial> so it's not too far out there :p
[17:29:01 CET] <wm4> atomnuker: and?
[17:38:17 CET] <Compn> hmmm seems we maybe missing xavc-s format too :\
[17:50:46 CET] <cone-757> ffmpeg 03Michael Niedermayer 07master:755933cb5cd1: avcodec/mjpegdec: Check remaining bitstream in ljpeg_decode_yuv_scan()
[18:00:29 CET] <BBB> wm4: if its better, maybe we should
[18:01:17 CET] <BBB> wm4: but my interest isnt so much in zimg, its more in writing a great scaler, even if thats NIH - I tend to develop better if I know how the software works and it uses technologies that I understand (so no c++, for example)
[18:03:32 CET] <wm4> writing something new sounds fine too
[18:04:43 CET] <BBB> (Im totally fine with using zimg if its better, in fact I think we should, Im just unlikely to contribute to it myself because I dont udnerstand it)
[18:06:20 CET] <ubitux> replace sws with an incompatible api in c++? huh. 
[18:06:28 CET] <ubitux> we already have a wrapper, don't we?
[18:07:03 CET] <ubitux> --enable-libzimg + -vf zscale, end of the story
[18:09:22 CET] <wm4> ubitux: no, for general conversion (also it has a C API)
[18:09:45 CET] <wm4> the problem right now is that libswscale is used by default, which will result in many broken files / botched transcodes
[18:09:51 CET] <ubitux> and we're going to dump zimg in the repository and merge with the upstream regularly?
[18:09:57 CET] <bencoh> broken files?
[18:09:57 CET] <ubitux> let's be realistic for a minute :p
[18:10:07 CET] <wm4> ubitux: external libs do exist
[18:10:19 CET] <ubitux> for builtin and essential features?
[18:10:31 CET] <wm4> bencoh: when not properly converting between colorspaces
[18:11:00 CET] <wm4> ubitux: h264 encoding is one of the most important things and requires an external lib
[18:11:21 CET] <ubitux> because we don't have an encoder
[18:11:37 CET] <bencoh> wm4: is it a sws bug, or just people that don't configure it properly?
[18:11:38 CET] <ubitux> our codebase doesn't rely on that encoder
[18:11:52 CET] <ubitux> we have all our tools and filters that actually depends on swscale
[18:12:19 CET] <ubitux> you can't ditch it out and say "now we're going to use an external library"
[18:12:31 CET] <wm4> bencoh: missing features
[18:12:53 CET] <bencoh> why not add it then?
[18:12:58 CET] <wm4> ubitux: swscale isn't always used either, only if conversion or scaling is required somewhere
[18:13:15 CET] <bencoh> unless you think sws is utterly broken / beyond repair, which I doubt
[18:13:19 CET] <wm4> bencoh: because swscale is nearly unmaintainable/unhackable
[18:13:19 CET] <ubitux> which is everywhere basically
[18:13:36 CET] <ubitux> look at how much tests passes on fate if you --disable-swscale
[18:14:14 CET] <ubitux> (~2400/3000)
[18:14:53 CET] <ubitux> so basically 20% of the tests heavily relies on sws
[18:15:01 CET] <ubitux> we can't say the same about an h264 encoder
[18:15:18 CET] <ubitux> also, FATE is not covering much of libavfilter
[18:16:03 CET] <BBB> which botched encodes
[18:16:20 CET] <BBB> I dont think swscale is fundamentally buggy
[18:16:22 CET] <BBB> it has bugs, sure
[18:16:31 CET] <BBB> but to say it causes tons of botched transcodes isnt realistic IMO
[18:17:03 CET] <BBB> and sure if you want zimg, its there, use it, its great
[18:17:13 CET] <BBB> (I guess?)
[18:17:23 CET] <BBB> but Id like to have an internal scaler thats great also
[18:17:33 CET] <BBB> swscale isnt buggy, but great doesnt really apply either
[18:28:00 CET] <wm4> BBB: try to transcode anything that involves hdr and whatever else swscale doesn't support
[18:28:16 CET] <BBB> hahaha ok HDR is an issue yes
[18:50:33 CET] <ubitux> is it me or fate is quite colored lately?
[18:52:06 CET] <ubitux> also, somehow fate-filter-stereotools fails here on an emulated arm
[18:52:19 CET] <ubitux> but that might be related to a derp in my toolchain
[18:53:34 CET] <ubitux> http://sprunge.us/SYGV
[19:22:25 CET] <cone-757> ffmpeg 03Janne Grunau 07master:71a047211457: checkasm: arm: report the first clobbered register in checkasm_checked_call
[19:22:26 CET] <cone-757> ffmpeg 03Clément BSsch 07master:9f1c81e5ec90: Merge commit '71a0472114574993df7035f4de9aa007e03817b8'
[19:24:21 CET] <cone-757> ffmpeg 03Andreas Cadhalpun 07master:c0fd2fb27beb: swscale: Rename sws_context_class to ff_sws_context_class
[19:24:22 CET] <cone-757> ffmpeg 03Clément BSsch 07master:4ad5b9363fcf: Merge commit 'c0fd2fb27bebd1d5ab028e6df6bca9119d269122'
[19:28:18 CET] <cone-757> ffmpeg 03Diego Biurrun 07master:facdfe408055: swscale: Add proper ff_ prefix to init functions
[19:28:19 CET] <cone-757> ffmpeg 03Clément BSsch 07master:4181d7741dc9: Merge commit 'facdfe40805559963b5875931af9406ed5ddcd5c'
[19:30:09 CET] <cone-757> ffmpeg 03Diego Biurrun 07master:5ece6911010b: apichanges: Fill in missing hashes and dates
[19:30:10 CET] <cone-757> ffmpeg 03Clément BSsch 07master:727c463ff7d8: Merge commit '5ece6911010b3464d2fdacfa8031c15b5bd83418'
[19:33:41 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:446353ea1844: checkasm: arm: Don't start new const blocks for each string
[19:33:42 CET] <cone-757> ffmpeg 03Janne Grunau 07master:59aeed93e4e9: cheackasm/arm: remove NEON instructions from checkasm_checked_call_vfp
[19:33:43 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:37961044c6cc: checkasm: arm: Ignore changes to bits 0-4 and 7 of FPSCR
[19:33:44 CET] <cone-757> ffmpeg 03Clément BSsch 07master:f84ece0a9831: Merge commit '37961044c6'
[19:36:06 CET] <cone-757> ffmpeg 03James Almer 07master:fd5e6a095f69: x86util: Extend SPLATW for avx2
[19:36:07 CET] <cone-757> ffmpeg 03Clément BSsch 07master:1400598c0e31: Merge commit 'fd5e6a095f69495c558069315d6b36ea410c31fa'
[19:37:33 CET] <ubitux> ok now we have a bunch of hevc commits related to SIMD
[19:38:14 CET] <ubitux> i know we have a bunch of them, but we also skipped some previously (see doc/libav-merge.txt)
[19:38:21 CET] <ubitux> is anyone motivated to work on this?
[19:38:44 CET] <ubitux> ETA: 835 commits
[19:40:53 CET] <ubitux> it's strange no one seems to care about hevc
[19:44:48 CET] <philipl> patents are fun.
[21:13:07 CET] <wbs> michaelni: if there's no comments on the vp9/arm patchset from last week, can you push it? it's tested on arm and aarch64 and arm/msvc, build tested for arm and aarch64 ios
[21:14:33 CET] <wm4> wbs: you don't have push access?
[21:17:51 CET] <wbs> wm4: dunno, maybe I have
[21:20:23 CET] <michaelni> wbs, you should have
[21:28:36 CET] <Compn> he may not have his original key still ? 
[21:28:43 CET] <Compn> wbs : if you need to update keys just ask michaelni :)
[21:28:45 CET] <Compn> i think
[21:28:56 CET] Action: Compn forgets where our git server is now
[21:30:23 CET] <michaelni> if it helps theres a rsa key with "martin at sphere" named mstorsjo.pub which should have access
[21:32:18 CET] <wbs> ok, I can probably try then
[21:45:30 CET] <wbs> michaelni: so one pushes to the videolan gitosis setup right?
[21:46:41 CET] <wm4> I use git at source.ffmpeg.org:ffmpeg as push url
[21:46:53 CET] <michaelni> wbs, yes
[21:46:57 CET] <wbs> wm4: ok, thanks
[21:47:12 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:cda9a3e80b74: arm: vp9dsp: Restructure the bpp checks
[21:47:13 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:a4d4bad75c0b: arm: Add NEON optimizations for 10 and 12 bit vp9 MC
[21:47:14 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:2ed67eba969e: arm: Add NEON optimizations for 10 and 12 bit vp9 itxfm
[21:47:15 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:1e5d87eec337: arm: Add NEON optimizations for 10 and 12 bit vp9 loop filter
[21:47:16 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:48ad3fe1beee: aarch64: vp9dsp: Restructure the bpp checks
[21:47:17 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:638eceed4752: aarch64: Add NEON optimizations for 10 and 12 bit vp9 MC
[21:47:18 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:ceb36b81781f: aarch64: Add NEON optimizations for 10 and 12 bit vp9 itxfm
[21:47:19 CET] <cone-757> ffmpeg 03Martin Storsjö 07master:9f10cff61042: aarch64: Add NEON optimizations for 10 and 12 bit vp9 loop filter
[21:47:49 CET] <ubitux> nice
[22:47:16 CET] <BBB> ubitux: nobody seems to want to touch hevc with a 10-foot stick
[22:47:43 CET] <ubitux> that seems to be a ffmpeg thing mostly though
[22:47:50 CET] <BBB> ubitux: yes, the patent situation isnt helping. I mean, its a pretty good codec, particularly the way it does intra
[22:48:03 CET] <BBB> but the coefficient coding and inter support are very questionable
[22:48:10 CET] <BBB> (as in: utterly garbage)
[22:48:33 CET] <JEEB> yeah, the licensing situation killed it off before it flew
[22:48:43 CET] <BBB> and having to code 34 (?) intra prediction simd functions per size also doesnt help
[22:48:56 CET] <BBB> especially given how infrequent most of them are actually used :)
[22:49:00 CET] <JEEB> and there's no official non-drm content around for which you'd need the decoder for
[22:49:14 CET] <JEEB> and the drm stuff is limited to plastic boxes anyways
[22:49:21 CET] <BBB> yeah...
[22:49:35 CET] <BBB> maybe they will learn a lesson
[22:49:57 CET] <BBB> next time, make sure some big company uses it before you charge crazy billions
[22:50:09 CET] <JEEB> ayup
[22:50:27 CET] <JEEB> because even if you take that partially back you've already spilled the coffee
[22:50:36 CET] <JEEB> if you know what I mean
[22:55:16 CET] <BBB> ;)
[23:01:33 CET] <ubitux> still, we'll have to deal with the hevc merges at some point
[23:04:03 CET] <cone-757> ffmpeg 03Michael Niedermayer 07master:9e6a2427558a: avcodec/vp56: Check for the bitstream end, pass error codes on
[23:32:32 CET] <nevcairiel> ubitux: the currently upcoming hevc merges are mostly ports from us or openhevc (which we also have), careful noop'ing or cosmetic differences should be most of it
[23:33:14 CET] <ubitux> ok
[23:33:29 CET] <nevcairiel> the real new asm comes later
[23:33:31 CET] <ubitux> i'll look at it maybe tomorrow if no one takes over it
[23:34:58 CET] <nevcairiel> iirc some of the dsp context members got renamed in libav, not sure if we want to rename ours or keep ours, but that should be the most complex thing in those patches
[23:36:43 CET] <nevcairiel> i fly back home on saturday, so by next week i can help out as well as time permits (no clue what work waits for me in the inbox :D)
[23:41:41 CET] <cone-757> ffmpeg 03Carl Eugen Hoyos 07master:6d6faa2a2ded: lavc/svq3: Fail for media key encryption.
[23:49:07 CET] <Zeranoe> Are there any decoders/encoders that are not multi-core/thread?
[23:50:23 CET] <ubitux> many according to ffmpeg -decoders and ffmpeg -encoders
[23:50:31 CET] <atomnuker> no audio encoders are though
[23:50:45 CET] <atomnuker> durandal_1707 did attempt to add frame threading IIRC
[23:50:55 CET] <atomnuker> (why didn't that work out though?)
[23:51:08 CET] <Zeranoe> Oh I see, F and S
[23:51:28 CET] <Zeranoe> atomnuker: no audio encoders are NOT multi-core?
[23:51:57 CET] <atomnuker> no audio encoder we have supports any threading
[23:52:05 CET] <Zeranoe> I see
[23:52:23 CET] <durandal_1707> atomnuker: flac need updating extradata
[23:52:39 CET] <durandal_1707> needs syncing
[23:52:54 CET] <atomnuker> isn't it like ogg where it only made the extradata in the init function?
[23:53:18 CET] <Zeranoe> Has the threading support been tested on 4+ cores? My i7 does fine, but I know there are CPUs with more
[23:53:41 CET] <durandal_1707> atomnuker: nope
[23:54:11 CET] <atomnuker> durandal_1707: what about tta then, sure its not as popular but still
[23:54:31 CET] <BBB> Zeranoe: I think we pretty regularly with 8 threads, Ive tested some codecs (h264, vp8, vp9 etc.) with up to 20 or so
[23:54:55 CET] <atomnuker> IIRC the commit did touch a few things outside of the codecs, would be nice to still support at least 1 or 2 which don't require extradata
[23:54:58 CET] <Zeranoe> BBB: Nice, do you publish those results, or could you tell me the hardware?
[23:55:06 CET] <durandal_1707> atomnuker: it had with wavpack
[23:55:10 CET] <BBB> mac pro w/ 12 cores
[23:55:18 CET] <BBB> I Dont remember details, not my computer anymore
[23:55:46 CET] <BBB> Zeranoe: results were that it got faster  with more threads ;) and results were correct
[23:55:58 CET] <cone-757> ffmpeg 03Marton Balint 07master:5049f05f27c2: avutil/channel_layout: fix remains of old syntax in docs and comments
[23:55:59 CET] <cone-757> ffmpeg 03Marton Balint 07master:c4618f842a2d: avutil/channel_layout: add av_get_extended_channel_layout
[23:56:00 CET] <cone-757> ffmpeg 03Marton Balint 07master:977fd8841921: avfilter/formats: do not allow unknown layouts in ff_parse_channel_layout if nret is not set
[23:56:02 CET] <Zeranoe> I wonder if any testing has been done on Windows... Hmmm, who's the Windows guy.... 
[23:56:09 CET] <atomnuker> durandal_1707: the wavpack encoder doesn't use extradata as well
[23:56:42 CET] <Zeranoe> BBB: I always enjoy a correct result.
[23:57:00 CET] <BBB> it helps to keep users happy right?
[23:57:39 CET] <llogan> we have some Windows instances on FATE. not sure what kind of hardware they use though.
[23:57:47 CET] <Zeranoe> What the heck, the new MacPro is a cylinder
[23:57:56 CET] <llogan> trash can
[23:58:10 CET] <Zeranoe> A $4k trash can
[23:58:48 CET] <Zeranoe> BBB: Cores right, not hyperthreading?
[23:58:57 CET] <Zeranoe> I don't even see a 12core one for sale
[23:59:06 CET] <BBB> right, 12 physical cores
[23:59:25 CET] <jamrial_> nevcairiel: whatever happened to your fate instances? they haven't run in almost a month
[23:59:33 CET] <BBB> (up to a 12-core Xeon E5 CPU)
[23:59:37 CET] <BBB> (according to wikipedia
[23:59:46 CET] <nevcairiel> jamrial_: i shut them down while i wasnt home for a month
[23:59:51 CET] <Zeranoe> Oh there it is
[23:59:57 CET] <jamrial_> nevcairiel: oh, i see
[00:00:00 CET] --- Wed Jan 25 2017