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

[burek]

[00:05:04 CEST] <baptiste> "we are a team"
[00:12:46 CEST] <atomnuker> man, I just cut my headphone cable (on purpose)
[00:12:58 CEST] <atomnuker> there's tar-black liquid coming out of the ends
[00:13:30 CEST] <atomnuker> probably some weird rubber chemical process, but it kinda reminds me of that black liquid in prometheus
[00:15:38 CEST] <llogan> or the "food" in The Matrix?
[00:15:43 CEST] <llogan> baby food
[00:19:26 CEST] <atomnuker> no way, did they actually use baby food as the prop?
[00:22:42 CEST] <llogan> hmm..maybe i'm thinking of some other moving or just remembering it wrong. i only say it once or twice
[00:27:53 CEST] <atomnuker> you've only seen the matrix once? blasphemy
[00:29:01 CEST] <atomnuker> (though it's not blasphemy if you've seen the second movie at least a few more times)
[00:29:02 CEST] <iive> they had baby food in the matrix, but afair it was white
[00:42:57 CEST] <rcombs> https://github.com/foo86/dcadec/issues/30 <-- in case anybody wants to be sad
[00:50:27 CEST] <llogan> rcombs: is the sadness because it's still an open ticket, or because of some angry person?
[00:56:56 CEST] <iive> don't feed the trolls
[01:02:40 CEST] <rcombs> llogan: pick your poison
[01:03:10 CEST] <rcombs> that it's so old of a ticket and the only thing going on is pointless troll-feeding
[01:07:11 CEST] <jamrial> foo86 is awol, so who knows when and if that and every other ticket will be closed
[01:14:46 CEST] <rcombs> either move the code into lavc, or fork the repo and "tag a release" there to hopefully make package managers happy
[01:22:36 CEST] <cone-320> ffmpeg 03Timothy Gu 07master:712235dd8fb3: configure: Print large lists in more columns if the screen size allows
[01:28:22 CEST] <cone-320> ffmpeg 03Ganesh Ajjanagadde 07master:27cbe4588aea: avformat/format: silence -Wdiscarded-qualifiers
[01:29:59 CEST] <cone-320> ffmpeg 03Ganesh Ajjanagadde 07master:9aaa54135c20: avformat/mpjpegdec: silence unused variable/function warnings
[01:31:40 CEST] <cone-320> ffmpeg 03Ganesh Ajjanagadde 07master:80d23d9d32d0: swscale/swscale: silence unused function warning
[02:20:21 CEST] <cone-320> ffmpeg 03Michael Niedermayer 07master:fa5358f07d0c: avcodec/rv34: Delay failure return for B frames with a missing reference
[02:20:21 CEST] <cone-320> ffmpeg 03Michael Niedermayer 07master:d64f7d421307: avformat/avidec: disable parsing for RV40
[02:23:42 CEST] <BBB> jamrial: any more comments on the simd? or ok to commit?
[02:31:17 CEST] <jamrial> BBB: the jmp used in the 12bit 8tap functions sounds like it would make them be a bunch of cycles slower than the 10bit counterparts, but at least here the checkasm benchmark is all over the place
[02:31:58 CEST] <BBB> all over the place?
[02:32:01 CEST] <BBB> what do you mean?
[02:32:16 CEST] <BBB> the jmp is outside the main loop so its not so bad, the goal is to make the binary smaller
[02:32:21 CEST] <jamrial> vp9_put_8tap_smooth_64v_10bpp_sse2: 12416.4
[02:32:22 CEST] <jamrial> vp9_put_8tap_smooth_64v_12bpp_sse2: 13003.0
[02:32:34 CEST] <jamrial> vp9_avg_8tap_smooth_64v_10bpp_sse2: 13189.5
[02:32:35 CEST] <jamrial> vp9_avg_8tap_smooth_64v_12bpp_sse2: 13058.9
[02:33:02 CEST] <jamrial> slower on put but faster on avg, which i think is weird
[02:33:50 CEST] <jamrial> i don't think binary size is a problem anyway
[02:34:31 CEST] <jamrial> but then again, this is 12bit. doubt it will be used much
[02:34:36 CEST] <jamrial> 10bit has more chances
[02:36:02 CEST] <BBB> is that stable?
[02:36:18 CEST] <BBB> it may be that the loop is not aligned? then again its quite a long loop so that shouldnt matter
[02:36:52 CEST] <BBB> also, how do you bench just one function?
[02:37:34 CEST] <jamrial> i didn't. i ran checkasm --bench and looked the results for the ones i was interested in
[02:38:44 CEST] <BBB> vp9_avg_8tap_smooth_64hv_10bpp_sse2: 18507.1
[02:38:44 CEST] <BBB> vp9_avg_8tap_smooth_64hv_12bpp_sse2: 16647.7
[02:38:45 CEST] <BBB> vp9_put_8tap_smooth_64hv_10bpp_sse2: 15897.8
[02:38:46 CEST] <BBB> vp9_put_8tap_smooth_64hv_12bpp_sse2: 14952.5
[02:38:49 CEST] <BBB> its really all over the place for me
[02:38:50 CEST] <jamrial> and yes, ran it more than once and the results are always the same. put somewhat slower, avg slightly faster
[02:39:03 CEST] <BBB> I think the reason that the 12bpp is faster is because the code is already cached when it runs
[02:39:07 CEST] <jamrial> try disabling power saving features for your cpu if you didn't
[02:39:13 CEST] <BBB> so if you invert the bit_depth order, it does the opposite
[02:39:53 CEST] <BBB> evidence:
[02:39:54 CEST] <BBB> vp9_avg_8tap_smooth_64hv_10bpp_sse2: 17017.5
[02:39:55 CEST] <BBB> vp9_avg_8tap_smooth_64hv_12bpp_sse2: 17840.4
[02:39:56 CEST] <BBB> vp9_put_8tap_smooth_64hv_10bpp_sse2: 17078.7
[02:39:57 CEST] <BBB> vp9_put_8tap_smooth_64hv_12bpp_sse2: 15742.9
[02:39:59 CEST] <BBB> oh wait that went wrong
[02:40:50 CEST] <jamrial> so in a real world scenario where you play either 10bit or 12bit it wouldn't matter?
[02:41:08 CEST] <BBB> I dont think so
[02:41:12 CEST] <BBB> but it wont change my order
[02:41:13 CEST] <BBB> weird
[02:42:28 CEST] <BBB> just 12:
[02:42:29 CEST] <BBB> vp9_avg_8tap_smooth_64hv_12bpp_sse2: 18735.3
[02:42:30 CEST] <BBB> vp9_put_8tap_smooth_64hv_12bpp_sse2: 16934.0
[02:42:49 CEST] <BBB> just 10:
[02:42:50 CEST] <BBB> vp9_avg_8tap_smooth_64hv_10bpp_sse2: 17132.5
[02:42:51 CEST] <BBB> vp9_put_8tap_smooth_64hv_10bpp_sse2: 15520.7
[02:43:21 CEST] <BBB> so maybe 12 is a little slower
[02:44:52 CEST] <BBB> overall the results are very noisy for me with --bench
[02:45:00 CEST] <BBB> I think bench just doesnt do enough iterations tbh
[02:45:16 CEST] <jamrial> yeah, it doesn't
[02:45:24 CEST] <jamrial> Gramner said that's something that remains to be added
[02:45:42 CEST] <jamrial> x264's checkasm does several iterations in contrast
[02:48:50 CEST] <jamrial> BBB: anyway, the patches are ok regardless of doing jmp or code duplication
[03:10:54 CEST] <BBB> jamrial: if we decide its helpful, we can always add code dup later, its a very minor change (the code is bpp-agnostic)
[03:11:00 CEST] <BBB> and ty
[03:11:23 CEST] <jamrial> sure, and no prob
[03:12:01 CEST] <cone-320> ffmpeg 03Ronald S. Bultje 07master:6354ff03833b: vp9: add fullpel (put) MC SIMD for 10/12bpp.
[03:12:02 CEST] <cone-320> ffmpeg 03Ronald S. Bultje 07master:77f359670fdb: vp9: add fullpel (avg) MC SIMD for 10/12bpp.
[03:12:03 CEST] <cone-320> ffmpeg 03Ronald S. Bultje 07master:344d519040f0: vp9: add subpel MC SIMD for 10/12bpp.
[03:12:05 CEST] <BBB> \o/
[03:12:11 CEST] <BBB> already faster than libvpx
[03:12:17 CEST] <BBB> now to make it MUCH MUCH MUCH faster
[03:17:18 CEST] <jamrial> Timothy_Gu: you may want to undo the commit michaelni mentioned is wrong
[04:24:20 CEST] <cone-320> ffmpeg 03Claudio Freire 07master:8df9bf8e39b5: AAC encoder: refactor to resynchronize MIPS port
[04:54:14 CEST] <cone-320> ffmpeg 03Timothy Gu 07master:d36eac698f65: Revert "avformat/format: silence -Wdiscarded-qualifiers"
[04:54:25 CEST] <Timothy_Gu> jamrial: done, thx
[07:22:15 CEST] <durandal_1707> who is gona fix our dcadec?
[10:13:03 CEST] <Gramner> 4 hours of waiting for the next flight... oh well, at least there's free wifi
[10:13:30 CEST] <kierank> Gramner: delays?
[10:13:42 CEST] <Gramner> no, just a long time between flights
[10:14:08 CEST] <Gramner> 3 separate flights
[10:16:29 CEST] <Gramner> there was actually an air france alternative that would have been a lot faster, but it involved a really tight transfer in stockholm - with the arrival and departure at opposite ends of the airport
[10:16:31 CEST] <durandal_1707> videolan have moneyz?
[10:16:44 CEST] <Gramner> would basically have to run the entire way and any delay would've fucked it up
[10:16:49 CEST] <Gramner> so i skipped that
[10:17:00 CEST] <martijnb> 2 years ago I got stuck in Birmingham airport for 4 hours, first snow of the season
[10:17:22 CEST] <martijnb> only place to sit was next to a store with "let it snow, let it snow, let it snow" on loop
[10:17:36 CEST] <Gramner> haha
[10:18:08 CEST] <martijnb> thought it was funny, the first 15 minutes
[10:18:12 CEST] <martijnb> qq
[10:21:04 CEST] <Gramner> yeah, I guess that could get old really fast
[10:21:47 CEST] <martijnb> once you get past customs, the airport is tiny
[10:21:59 CEST] <martijnb> where are you stranded?
[10:22:26 CEST] <Gramner> stockholm
[10:22:57 CEST] <Gramner> been here almost 2 hours though, so not that much leftg
[11:02:16 CEST] <cone-089> ffmpeg 03Luca Barbato 07master:22cc57da64bf: rtpdec: Forward the memory failure
[11:02:16 CEST] <cone-089> ffmpeg 03Hendrik Leppkes 07master:157969321a93: Merge commit '22cc57da64bfd73f2206969486b0aa183ee76479'
[11:08:39 CEST] <cone-089> ffmpeg 03Alexandra Hájková 07master:971177f751a6: dcadec: scan for extensions in a separate function
[11:08:40 CEST] <cone-089> ffmpeg 03Hendrik Leppkes 07master:ecaa6cf7b84a: Merge commit '971177f751a6e2931232accceab438bce277bde8'
[11:24:49 CEST] <cone-089> ffmpeg 03Alexandra Hájková 07master:777885983533: dcadec: set channel layout in a separate function
[11:24:50 CEST] <cone-089> ffmpeg 03Hendrik Leppkes 07master:04eff9682225: Merge commit '777885983533235ccda5145f96317fc8cd0a18ab'
[11:28:13 CEST] <cone-089> ffmpeg 03Kevin Wheatley 07master:4a664224502b: pixfmt: Add new SMPTE color primaries and transfer characteristic values
[11:28:14 CEST] <cone-089> ffmpeg 03Hendrik Leppkes 07master:e8fbd80e1488: Merge commit '4a664224502b42e3b28949d905a8de7769892184'
[11:28:27 CEST] <cone-089> ffmpeg 03Henrik Gramner 07master:781a25e9c419: checkasm: v210: Fix array overwrite
[11:28:28 CEST] <cone-089> ffmpeg 03Hendrik Leppkes 07master:ea33b1ea300b: Merge commit '781a25e9c419dd66063597cc5d70e8919de60561'
[11:31:12 CEST] <cone-089> ffmpeg 03Paul B Mahol 07master:ddf378895f6f: avfilter: add stereo tools filter
[11:31:13 CEST] <cone-089> ffmpeg 03Paul B Mahol 07master:695ff5dc6d9e: avfilter/af_sidechaincompress: use doubles instead of floats
[11:34:26 CEST] <cone-089> ffmpeg 03Steve Lhomme 07master:e3d4784eb31b: d3d11va: WindowsPhone requires a mutex around ID3D11VideoContext
[11:34:27 CEST] <cone-089> ffmpeg 03Hendrik Leppkes 07master:7c46f24bde12: Merge commit 'e3d4784eb31b3ea4a97f2d4c698a75fab9bf3d86'
[11:52:32 CEST] <cone-089> ffmpeg 03Vittorio Giovara 07master:7bb1c1bfd22d: avconv_opt: Allow printing private options
[11:52:33 CEST] <cone-089> ffmpeg 03Hendrik Leppkes 07master:e34939ca762b: Merge commit '7bb1c1bfd22de2200743af04ebd0c7c775f56f7e'
[12:21:53 CEST] <atomnuker> the wifi at the hotel seems to randomly cut off SSH connections, just pointing this out to whoever's listening and coming to the VDD
[12:22:16 CEST] <BtbN> That's sadly quite normal.
[12:22:31 CEST] <BtbN> They don't cut SSH connections, they cut long running TCP connections.
[12:22:41 CEST] <BtbN> I have seen that a couple times already.
[12:23:03 CEST] <BtbN> OpenVPN that imediately reconnects helps against that
[12:23:27 CEST] <kierank> atomnuker: send keepalive
[12:23:30 CEST] <kierank> putty can do that
[12:29:20 CEST] <nevcairiel> if they really just cut long running tcp connections, then no keep alive is going to save you
[12:29:35 CEST] <atomnuker> nope, not even a 10 second keepalive can keep the connection open
[12:31:42 CEST] <TimNich> keeps the streaming media contetn down...
[13:08:43 CEST] <kierank> I have a UDP tunnel
[14:42:43 CEST] <cone-089> ffmpeg 03Paul B Mahol 07master:969ce025cc42: avfilter/vf_atadenoise: fix file permissions
[14:57:17 CEST] <Gramner> status: "await information" on the last flight leg, sounds like a good sign
[15:03:19 CEST] <RiCON> doc/ffprobe-all.pod around line 14998: You can't have =items (as at line 15009) unless the first thing after the =over is an =item
[15:03:31 CEST] <RiCON> seems to be a typo since the stereotools commit
[15:04:04 CEST] <RiCON> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/filters.texi;h=4df236323619becd7bfd497c41a37e20e0e8fae3;hb=ddf378895f6ff9ee1a5c5420acf5b62e078ab68f#l2420
[15:04:15 CEST] <RiCON> ^ in this line and 2424 as well
[15:05:02 CEST] <nevcairiel> those tables are meant to be item i assume
[15:07:38 CEST] <cone-089> ffmpeg 03Paul B Mahol 07master:f825883eeb50: avfilter/af_sidechaincompress: do not use floats
[15:09:34 CEST] <RiCON> changing to item fixes it
[15:12:54 CEST] <cone-089> ffmpeg 03Paul B Mahol 07master:00776e75b179: doc/filters: stereotools: fix mistake
[15:17:51 CEST] <cone-089> ffmpeg 03Michael Niedermayer 07master:e1ac0ecbbabe: avcodec/mips/aaccoder_mips: Remove duplicate include
[15:37:30 CEST] <zidanne> latest ffmpeg from master branch: this stream does not work I dont know why. It works with VLC. Can anyone check? http://trtcanlifm-lh.akamaihd.net/i/RADYO1_1@182345/master.m3u8
[15:41:32 CEST] <Gramner> BBB: checkasm does 1000 iterations of each bench by default (there's a define for that in checkasm.h)
[15:42:38 CEST] <Gramner> you really need to disable power saving stuff when running benchmarks though if you haven't done that, at least that makes the variances really small for me
[15:44:03 CEST] <BBB> zidanne: file a bug please (trac.ffmpeg.org)
[15:44:26 CEST] <Gramner> furthermore, --bench=<pattern> will only benchmark functions whose name starts with <pattern> which makes things a bit faster
[15:44:32 CEST] <BBB> oh thats nice
[15:44:56 CEST] <zidanne> BBB: so it didnt work by your side too? :|
[15:45:47 CEST] <BBB> I didnt try
[15:46:25 CEST] <Gramner> also, benchmarks are written to stdout, everything else to stderr. so you can just discard stderr when doing lots of benchmarks (no benchmarks are written on failure, so it will still be noticable if something fails)
[15:46:28 CEST] <BBB> maybe it doesnt work because its a m3u file, ffmpeg isnt a media player, its a media library, we dont support all playlists
[15:47:07 CEST] <zidanne> its hls
[15:48:26 CEST] <zidanne> this is what I do: ./ffmpeg -v 9 -loglevel 99 -i http://trtcanlifm-lh.akamaihd.net/i/RADYO1_1@182345/master.m3u8
[15:50:30 CEST] <BBB> zidanne: its a playlist
[15:50:46 CEST] <zidanne> Apple HLS, live streaming, ffmpeg has support for it normally.
[15:51:41 CEST] <BBB> ok, so file a bug
[15:51:58 CEST] <durandal_1707> I get 404 error
[16:14:36 CEST] <cone-089> ffmpeg 03Paul B Mahol 07master:245bf7c18a71: doc/filters: showfreqs: fix typo
[16:36:55 CEST] <cone-089> ffmpeg 03James Almer 07master:655b6dcb34b2: lavc/lavf: remove incompatible abi checks for the new 64bit fields
[16:56:51 CEST] <cone-089> ffmpeg 03Hendrik Leppkes 07master:3a8e4477124b: lavf/utils: remove some left-over cruft from the 32-bit size fields
[17:12:24 CEST] <BtbN> philipl, i might finaly get some hardware that's nvenc_hevc capable. But no hevc via vdpau.
[17:12:43 CEST] <BtbN> My potential new Work-Laptop has a 940M
[17:59:47 CEST] <BBB> j-b: do we schedule the ffmpeg/libav metrics thing on-site?
[17:59:58 CEST] <BBB> I recall thats how it was a few years ago but I dont know how it goes nowadays
[18:00:13 CEST] <j-b> yes
[18:00:18 CEST] <j-b> unconference is onsite
[18:00:30 CEST] <BBB> Gramner: I kinda like checkasm, I hope you dont mind my hacky randomize_buffer for loopfilter (it needs to be el weirdo else it doesnt cover all filter options)
[18:00:32 CEST] <kierank> BBB: obe2 is no more but I will setup a replacement
[18:00:36 CEST] <BBB> j-b: cool, thanks
[18:00:40 CEST] <BBB> kierank: oh :(
[19:07:12 CEST] <RiCON> some talks at vdd look interesting, any idea if they will be recorded?
[19:08:52 CEST] <iive> it would be a shame, conference about video to not be recorded ;)
[19:10:08 CEST] <RiCON> i can't find any of previous vdd, so that's why i ask
[19:19:08 CEST] <jamrial> BBB: any reason you didn't add subpel avx2 functions? judging by the 8bit ones they should work as is, no need to add instructions to shuffle data between lanes or anything like that
[19:19:31 CEST] <BBB> jamrial: yes they should work, but I have no avx2 cpu, sorry
[19:19:34 CEST] <jamrial> can't test it because Intel SDE doesn't work on Win10 yet
[19:19:40 CEST] <jamrial> figures
[19:19:43 CEST] <BBB> Im just waiting for someone with an avx2 cpu to drive by and add them basically
[19:19:59 CEST] <BBB> Im planning to buy a skylake mbp later this year if it comes out
[19:20:14 CEST] <BBB> but last time I checked the high end mbp didnt have skylake yet
[19:20:23 CEST] <BBB> or whatever it was that they were doing on the lowend ones
[19:20:28 CEST] <BBB> I thought it was skylake, cant remember for sure
[19:20:57 CEST] <jamrial> you could get a broadwell one instead. it's not like skylake client has avx512 anyway
[19:22:04 CEST] <jamrial> wonder why did Intel go that route
[19:22:55 CEST] <nevcairiel> because they know that avx512 will be mostly useless in consumer workloads
[19:23:34 CEST] <BBB> not true, hevc/vp9 could benefit from avx512
[19:25:33 CEST] <kurosu> by the time avx512 is in a consumer intel chip, that chip will have hevc main10 and vp9 (profile 0?) h/w decoders
[19:25:54 CEST] <kurosu> that leaves encoders
[19:26:32 CEST] <BBB> encoders are interesting
[19:26:46 CEST] <nevcairiel> not fro the consumer
[19:27:11 CEST] <BBB> hm...
[19:27:14 CEST] <BBB> well anyway
[19:27:24 CEST] <BBB> I dont have avx2 right now
[19:27:35 CEST] <BBB> anyone want to add 10/12bpp avx2 mc simd to vp9mc_16bpp.asm?
[19:28:00 CEST] <BBB> RiCON: needs people to do recording, so probably not
[19:29:17 CEST] <jamrial> i can't even run Intel SDE on an Archlinux VM because it doesn't support kernel 4.x, lol
[19:29:28 CEST] <jamrial> they haven't updated it since April
[19:37:10 CEST] <durandal_1707> anyone want to write simd for me?
[19:47:18 CEST] <RiCON> BBB: so at most just slides :(
[19:47:25 CEST] <BBB> likely
[19:47:35 CEST] <BBB> durandal_1707: depends what youre looking for& if its like psnr, Ill write you some
[19:47:40 CEST] <BBB> or I can teach you to do it yourself
[20:10:19 CEST] <jamrial> RiCON: does d3d11va work for you after updating mingw-w64 from msys2?
[20:10:31 CEST] <jamrial> configure still fails for me, but with a different error
[20:13:22 CEST] <RiCON> didn't test yet, i usually build without hwaccels, testing now
[20:25:50 CEST] <RiCON> still doesn't work
[20:26:06 CEST] <RiCON> but at least it doesn't break configure
[20:27:31 CEST] <wm4> j-b: it's probably way too late for this, but just how late could I arrive?
[20:30:23 CEST] <cone-089> ffmpeg 03Ganesh Ajjanagadde 07master:63cdb6e4a59e: avutil/log: fix zero length gnu_printf format string warning
[20:34:15 CEST] <cone-089> ffmpeg 03James Almer 07master:763ffa202978: checkasm: add flacdsp decorrelate tests
[20:55:24 CEST] <philipl> BtbN: jolly good.
[20:55:55 CEST] <philipl> BtbN: I don't think there's any mobile part with a gm206 yet.
[20:57:50 CEST] <fritsch> git bisect bad
[20:58:01 CEST] <fritsch> sorry
[20:58:38 CEST] <BtbN> The intel GPU on that i5-5200U could support hevc though
[20:59:18 CEST] <fritsch> BtbN: nope - that's a broadwell
[20:59:23 CEST] <fritsch> only via the gpu on windows oly
[21:01:09 CEST] <fritsch> hybrid I want to say
[21:06:33 CEST] <kierank> lglinskih: hello
[21:06:40 CEST] <kierank> Do you want to come to the lobby
[21:10:49 CEST] <kierank> We are going to the lindustrie bar across the road
[21:13:25 CEST] <lglinskih> kierank: hi! I'm staying not at the hotel=/
[21:13:48 CEST] <kierank> :(
[21:23:12 CEST] <cone-089> ffmpeg 03Paul B Mahol 07master:d4a9e6c1a1f2: avcodec/dcaenc: unbreak >4 channel support
[21:24:42 CEST] <durandal_1707> kierank: with who are you?
[21:25:03 CEST] <kierank> Vlc people
[21:25:35 CEST] <kierank> Safe to visit
[21:29:57 CEST] <durandal_1707> unsafe to go out alone
[21:33:27 CEST] <fritsch> i got a nice ts file where ffmpeg always detects mp3, but it seems the audio is ac3 really
[21:33:34 CEST] <fritsch> http://fritsch.fruehberger.net/ffmpeg/BestRecipesEver.ts
[21:33:38 CEST] <fritsch> sorry for the content :-)
[21:38:59 CEST] <durandal_1707> fritsch: please open bug report
[21:39:22 CEST] <fritsch> durandal_1707: can you reproduce?
[21:39:34 CEST] <fritsch> then I will do - I had a very, very old mplayer version here
[21:39:43 CEST] <fritsch> which identified it correctly, same as mediainfo
[21:39:54 CEST] <fritsch> but did not find a ffplay version that identified it correctly
[21:39:54 CEST] <durandal_1707> yes, I can
[21:39:58 CEST] <fritsch> seince version 1.0
[21:40:00 CEST] <fritsch> i bisected
[21:40:01 CEST] <fritsch> :-)
[21:40:11 CEST] <fritsch> oki, will do
[21:42:24 CEST] <fritsch> durandal_1707: uploading sample, it's called mp3ac3.ts
[22:33:04 CEST] <kylophone> Working on an audio filter and having trouble figuring out how samples are arranged/interleaved in AVFrame->data[0]. Any good docs for this? 
[22:39:16 CEST] <BtbN> Depends entirely on the format and channel layout
[22:46:59 CEST] <kylophone> I see. Looks like I should be casting to a pointer type that matches the sample size. Since data is a uint8_t buffer.
[22:49:56 CEST] <kylophone> That would make iterating through the samples much easier. 
[22:51:27 CEST] <kylophone> Is multichannel PCM sample data interleaved in this buffer by default, or does that depend on format as well?
[22:52:54 CEST] <BtbN> I don't have too much of an idea about audio formats, but i think most are interlaved, one sample per channel
[22:53:15 CEST] <BtbN> There propably are also some that make use of the multiple input buffers
[22:53:36 CEST] <nevcairiel> it depends, there is sample formats for interleaved, and formats for planar (every channel its own buffer)
[22:57:26 CEST] <fritsch> afaik between arround ffmpeg 1.2 the default internal representation was changed to planar internally
[22:57:40 CEST] <fritsch> which forced us (at this time back) to revisit half of our audio engine :-)
[22:59:14 CEST] <nevcairiel> you could just interleave them again
[22:59:23 CEST] <nevcairiel> this is what those decoders used to do before the change anyway
[22:59:32 CEST] <nevcairiel> they decoded to channel buffers, and then interleaved the output
[23:00:38 CEST] <nevcairiel> or even worse, converted to int16 and interleaved, instead of native 32-bit float output or something ;)
[23:00:47 CEST] <fritsch> yeah, we now fully use planar internally
[23:01:01 CEST] <fritsch> and think that step was the right decision
[23:01:07 CEST] <fritsch> much more efficient
[23:01:26 CEST] <fritsch> only at the very last step - on the sinks
[23:01:33 CEST] <fritsch> we change that again
[23:02:03 CEST] <nevcairiel> most audio output APIs need interleaved anyway, so depending on how much processing you actually do, and if those processing steps (which often come from external libraries) support planar, its often easier to just interleave earlier
[23:02:30 CEST] <fritsch> we basically use a complete ffmpeg centric audio engine
[23:02:36 CEST] <fritsch> which uses ffmpeg resampler and other things
[23:02:44 CEST] <fritsch> therefore we are not forced to convert any time early
[23:03:12 CEST] <fritsch> the audio engine is mostly OS transparent, e.g. no hacks besides LE BE stuff in there
[23:03:27 CEST] <fritsch> the only platform specifics are in the implemented sinks
[23:03:39 CEST] <nevcairiel> if you use lavfi, it might secretly interleave if a filter doesnt support planar
[23:03:48 CEST] <fritsch> https://github.com/xbmc/xbmc/tree/master/xbmc/cores/AudioEngine/Engines/ActiveAE
[23:04:08 CEST] <fritsch> we use ffmpeg for everything in order to not have to cope with that ourselves
[23:04:32 CEST] <fritsch> some things like Limiter or our passthrough parsing code, we did ourselves
[23:04:53 CEST] <fritsch> but it feels good when we don't need to maintain all that code and leave it to the experts
[23:05:14 CEST] <fritsch> so AE basically does the channel mapping from AE to ffmpeg notation
[00:00:00 CEST] --- Fri Sep 18 2015