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

[burek]

[03:06:10 CEST] <gramble> hey. i'm having trouble with concatenating some mp4s on my windows ffmpeg install. i'm getting a strange `unknown keyword ' (someblocksymbol)f'` error. i think my input text file may be formatted wrong, but i can't figure it out for the life of me.
[03:29:53 CEST] <cone-697> ffmpeg 03Michael Niedermayer 07master:90d239a441f2: avcodec/mpegvideo_enc: Add missing entry to non_linear_qscale table
[03:29:53 CEST] <cone-697> ffmpeg 03Michael Niedermayer 07master:2d35757814ec: avcodec/mpegvideo: Change mpeg2 unquant to work with higher precission qscale
[03:29:53 CEST] <cone-697> ffmpeg 03Michael Niedermayer 07master:bf9464027ba2: avcodec/mpeg12dec: Move non_linear_qscale to mpegvideodata
[03:29:53 CEST] <cone-697> ffmpeg 03Michael Niedermayer 07master:58fe57d5a05a: avcodec/mpeg12enc: Basic support for encoding non even QPs for -non_linear_quant 1
[08:19:01 CEST] <peloverde> Daemon404: lobby now plz
[08:45:20 CEST] <fritsch> BtbN: http://cgit.freedesktop.org/vaapi/intel-driver/commit/?id=2a72f99d24714f2a58f400ef63b913d4cf9080b3 :-(
[10:05:49 CEST] <kierank> atomnuker: going to Disneyland?
[10:06:23 CEST] <BtbN> fritsch, well, the hybrid driver still claims to support it on my haswell hardware.
[10:13:25 CEST] <__gb__> it's a bug in the hybrid driver
[10:13:49 CEST] <BtbN> It even claims VP8 encoding support
[10:13:50 CEST] <__gb__> the binary EU kernels are there but the number of EU threads would be insufficient
[10:14:02 CEST] <__gb__> VP8 encoding should work on Haswell
[10:14:07 CEST] <BtbN> Which it doesn't on my Braswell NUC
[10:14:13 CEST] <__gb__> with entropy coding performed on the CPU
[10:14:27 CEST] <__gb__> Braswell ought to have full HW encoding support for VP8
[10:14:43 CEST] <BtbN> Ah, so it should come from the normal driver then?
[10:14:53 CEST] <__gb__> yes :)
[10:15:09 CEST] <BtbN> But why was the driver split in the first place? Couldn't the hybrid codecs live in the normal libva-intel-driver?
[10:15:58 CEST] <__gb__> I don't want to comment that...
[10:16:34 CEST] <__gb__> BtbN, no VDD for you?
[10:17:01 CEST] <BtbN> No, i'm in the process of changing jobs right now, quite short on time.
[10:17:41 CEST] <BtbN> btw., did you have a chance to look at the hevc ScalingLists samples? gst and ffmpeg calculate the ScalingLists diffrently, but both show heavy artifacts.
[10:17:49 CEST] <__gb__> at least, the hybrid driver is now implicitly called from the native driver
[10:17:57 CEST] <__gb__> BtbN, I broke my SKL platform :-(
[10:18:45 CEST] <__gb__> BtbN, testing on braswell or skylake?
[10:18:49 CEST] <BtbN> The Lists ffmpeg calculates work for dxva and vdpau, so i'd suspect there's an issue on the driver or even hardware side
[10:18:50 CEST] <BtbN> Braswell
[10:19:19 CEST] <__gb__> btw, are you using the N3700 one?
[10:19:22 CEST] <BtbN> yes
[10:19:29 CEST] <BtbN> NUC5PPYH
[10:19:47 CEST] <__gb__> if the ffmpeg way to calculate scalinglists work for dxva, then this ought to work with va-api as well
[10:20:22 CEST] <BtbN> I basicaly copied the DXVA/VDPAU code to VAAPI, as it has the exact same fields.
[10:21:35 CEST] <__gb__> the api is very similar, up to including the fact that VA surfaces are referenced by indices to the referenceframes[] array?
[10:22:00 CEST] <__gb__> I'd say, usually artifacts could be due to incorrect RefPicList[] instead
[10:22:27 CEST] <BtbN> All samples work perfectly. The only ones that show artifacts are the ones using ScalingLists
[10:22:42 CEST] <atomnuker> kierank: nope, gotta prepare my talk
[10:22:56 CEST] <__gb__> argh
[10:23:00 CEST] <BtbN> If there was an issues with Reference Frames, way more stuff would explode
[10:23:37 CEST] <__gb__> I believe the driver was validated with the same internal tools, so we probably do things wrong in both gst & lavc
[10:23:52 CEST] <__gb__> (which are the same tools used for windows btw)
[10:24:26 CEST] <BtbN> Looking at the trace log, gst and ffmpeg pass diffrent scaling lists, but show the same artifacts.
[10:24:53 CEST] <BtbN> ffmpeg software decoding works fine for them
[10:26:15 CEST] <__gb__> oh, that's the NuC I wanted to buy, reportedly quite stable according to my colleagues with the upstream gfx stack
[10:27:11 CEST] <BtbN> Some Kodi reports say that the CPYH, the lower end one, works better for 4K 60Fps content. Because it has Dual-Channel memory.
[10:28:17 CEST] <BtbN> Wait, that's not a NUC, but a similar device from some other vendor.
[10:28:28 CEST] <__gb__> ark.intel.com mentions they are all the same, i.e. feature dual channel memory
[10:28:42 CEST] <nevcairiel> some only get one mem slot though
[10:28:44 CEST] <BtbN> yes, but the NUCs only have a single RAM slot
[10:28:47 CEST] <__gb__> the N3700 is interesting because of the higher number of EUs for e.g. hybrid VP9 decode
[10:29:11 CEST] <__gb__> pff, ok -- why more memory slots on a lower end product? :)
[10:29:23 CEST] <BtbN> And for copying around 60 4K surfaces per second, the Dual-Channel seems to make the tiny difference it needs for smooth playback
[10:30:12 CEST] <BtbN> It's not horrible on mine, it doesn't drop any frames, but it skips a few while rendering
[10:30:24 CEST] <BtbN> I'd still call it visualy flawless though
[10:30:34 CEST] <wm4> do you run windows on the nucs?
[10:30:40 CEST] <BtbN> No
[10:31:17 CEST] <wm4> linux? doesn't that tear?
[10:31:20 CEST] <nevcairiel> doesnt kodi support zero copy with vaapi now, or something
[10:31:32 CEST] <BtbN> Why would it tear?
[10:31:52 CEST] <BtbN> Kodi, or rather some experimental branch of it, uses the EGL interop.
[10:31:57 CEST] <nevcairiel> on a low mem bandwidth device like the NUC (or generally most Atom-class devices), copying video around in memory is evil
[10:32:30 CEST] <BtbN> As the Intel GPUs also use the system ram, at least to my knowledge, the RAM bandwidth still affects it
[10:32:44 CEST] <wm4> BtbN: it did when I actually tried to play video with a broadwell gpu
[10:32:46 CEST] <BtbN> Without EGL zero-copy you don't even get close to 30 FPS with 4K
[10:33:09 CEST] <wm4> I could choose tearing or enabling tear-free, which kept crashing GL programs
[10:33:25 CEST] <BtbN> I never set any TearFree option, and it works perfectly fine.
[10:33:40 CEST] <BtbN> Propably Kodi doing some magic in the background.
[10:33:55 CEST] <nevcairiel> why is double buffered vsync such a pain on linux anyway?
[10:33:56 CEST] <wm4> which magic?
[10:33:58 CEST] <fritsch> wm4: most likely you misconfigured something or had a quite intrusive compositing desktop?
[10:34:18 CEST] <fritsch> we did not disable gnome3's compositer succesfully
[10:34:21 CEST] <fritsch> fixed that some days ago
[10:34:27 CEST] <fritsch> but also only in that experimenting branch
[10:34:49 CEST] <fritsch> BtbN: at least we don't need to write, but the dual channel makes the difference in reading already I think
[10:35:14 CEST] <wm4> fritsch: no, just plain X11
[10:35:21 CEST] <fritsch> and hey - we talk about 800 skips on a 60 fps source over 10 minutes
[10:35:32 CEST] <wm4> nevcairiel: apparently it's X11's fault
[10:35:32 CEST] <BtbN> 200 for me.
[10:35:35 CEST] <fritsch> wm4: you tested the OE image? no that did not work
[10:35:35 CEST] <BtbN> In the BBB sample.
[10:35:41 CEST] <fritsch> BtbN: was roughly speaking
[10:35:57 CEST] <wm4> fritsch: no, that was when I used mpv some months ago
[10:36:28 CEST] <fritsch> okay - it should work right out of the box
[10:36:36 CEST] <fritsch> there was a bug in xserver some time ago
[10:36:51 CEST] <fritsch> which was quite popular on our forum
[10:36:57 CEST] <fritsch> in combination with some libsdl flags
[10:37:42 CEST] <fritsch> __gb__: do you see any chance - that we could get 10 bit hevc decoding - in a transparent way - e.g. for the start that we push in 10 bit data and get something "properly scaled and perhaps ditherd" back out of vaapi? :-)
[10:37:58 CEST] <fritsch> __gb__: cause hevc 8bit was good start, but the real content via DVB-S2 will be 10 bit sadly
[10:38:13 CEST] <__gb__> depends on the platform :)
[10:38:15 CEST] <fritsch> __gb__: haihao xiang told me - I should ask someone else
[10:38:22 CEST] <fritsch> yeah on windows gpu driven ....
[10:38:41 CEST] <fritsch> but we are on linux and want (at least until the infrastructure is made) have something partly usable
[10:40:47 CEST] <__gb__> for hybrid work, this would depend on the owner of the code to publish it, i.e. the people who write the windows driver :)
[10:41:12 CEST] <BtbN> DVB-S2 will use 10bit?
[10:41:16 CEST] <__gb__> on the other hand, if someone has / can generate spirv code, that's also another possibility
[10:41:20 CEST] <fritsch> yeah - i figured this, cause with the hybrid stuff in place - it should be no issue to incorporate the hevc capable hybrid driver
[10:41:26 CEST] <__gb__> in UK; yes
[10:41:31 CEST] <__gb__> even T2 iirc
[10:41:35 CEST] <fritsch> and in general also yes :-(
[10:41:36 CEST] <nevcairiel> BtbN: most commercial hevc will be 10-bit, broadcast and optical discs :)
[10:41:36 CEST] <__gb__> and already available
[10:41:59 CEST] <BtbN> Interesting, i didn't think there is much hardware that takes any benefit of it
[10:41:59 CEST] <fritsch> __gb__: do you have a contact within intel where we can bring this up?
[10:42:11 CEST] <fritsch> i think hw vendors (braswell based) highly need such a thing
[10:42:26 CEST] <fritsch> so it's not only us nerds that would like to have it :-)
[10:42:29 CEST] <__gb__> as people would tell you on another channel, it's not a technical issue :)
[10:42:40 CEST] <fritsch> yeah, i know a political one
[10:42:49 CEST] <fritsch> and therefore we need to contact the chief politician
[10:43:24 CEST] <__gb__> I don't think braswell as enough processing power for hevc 10b support, unless some VLD offload is done too
[10:43:30 CEST] <nevcairiel> does that actually work properly on windows? I would figure braswell might be too slow
[10:43:31 CEST] <BtbN> Intel should have some interest in their hardware working for common broadcast formats on platforms like OE.
[10:44:06 CEST] <__gb__> intel is very well aware of that, why do you think hybrid hevc 10b actually exists for windows at least :)
[10:44:09 CEST] <fritsch> __gb__: i have see the intel media-sdk has a intel driver (so) packaged that even supports hevc on haswell
[10:44:16 CEST] <fritsch> so - basically the code already exists
[10:44:18 CEST] <__gb__> 8b only iirc
[10:44:23 CEST] <kierank> It's cabac decide iirc
[10:44:53 CEST] <__gb__> fritsch, yes, the code exists in the proprietary linux driver, which is the same as the windows version
[10:45:28 CEST] <fritsch> nice
[10:45:28 CEST] <BtbN> I'd be perfectly fine with a proprietary driver, if it works and is freely available, like the nvidia and intel windows ones.
[10:45:47 CEST] <__gb__> this second part is WIP :)
[10:45:50 CEST] <fritsch> __gb__: vaapi does not support 10 bit surfaces as of now
[10:45:57 CEST] <fritsch> how would that integrate?
[10:46:05 CEST] <fritsch> driver "scaling" for us?
[10:46:17 CEST] <nevcairiel> you need some kind of surface to store the reference frames in full precision
[10:46:26 CEST] <nevcairiel> otherwise you get corruption everywhere
[10:46:44 CEST] <fritsch> yeah, that's why I am asking
[10:46:54 CEST] <nevcairiel> so if vaapi doesnt do 10b surfaces, it either has to hide that internally, and it copies it on output, which would be slow
[10:46:59 CEST] <nevcairiel> or vaapi needs to be extended
[10:47:02 CEST] <__gb__> the staging branch is a good indication of what can exist, and it does reference P010 and P016 formats :)
[10:47:16 CEST] <fritsch> hehe
[10:47:26 CEST] <BtbN> How is 10b even stored? Does it pack pixels together until it reaches some size that fits in common data types?
[10:47:41 CEST] <nevcairiel> BtbN: padded to 16-bit usually
[10:47:44 CEST] <nevcairiel> ie P010
[10:48:08 CEST] <BtbN> So it essentials doubles in size, at least when decoded
[10:48:10 CEST] <BtbN> *y
[10:48:14 CEST] <nevcairiel> yes
[10:48:35 CEST] <BtbN> That will get interesting, when memory bandwidth is already an issue with 8 bit 4K
[10:48:44 CEST] <fritsch> http://cgit.freedesktop.org/vaapi/libva/tree/va/va.h?h=staging&id=3f41b7582431e0e7a02fbf98d324361f60e88ac6#n737 <- can only find this for now
[10:48:48 CEST] <fritsch> and of course no driver support
[10:49:40 CEST] <fritsch> __gb__: so, what can the community do to convince intel's management here? (just naively asking - so we can actually do something and form the future)
[10:50:20 CEST] <__gb__> wrt. driver "scaling", again, the staging branch indicates some API to perform decode+processing :)
[10:50:41 CEST] Action: __gb__ had to double check first prior to even mentioning it :)
[10:51:21 CEST] <__gb__> VAConfigAttribDecProcessing
[10:51:37 CEST] <fritsch> hehe
[10:51:42 CEST] <fritsch> I see something is already prepared
[10:51:54 CEST] <__gb__> there is a reason why this specific API was added, but I could not find any public reference to why this would be needed
[10:52:16 CEST] <fritsch> perhaps that is used vice versa by the blob?
[10:52:27 CEST] <fritsch> to maintain the given NV12 ouput?
[10:52:55 CEST] <fritsch> e.g. blob decodes 10bit + uses the drivers method to scale
[10:53:02 CEST] <fritsch> so that infrastructure can be kept?
[10:53:18 CEST] <__gb__> oh well: http://www.anandtech.com/show/9562/intels-skylake-gpu-analyzing-the-media-capabilities
[10:53:35 CEST] <__gb__> "Video Post Processing & Miscellaneous Aspects"
[10:54:07 CEST] <fritsch> i really wonder why skylke has such a thing
[10:54:12 CEST] <fritsch> but it was forgotten to get 10 bit in hw
[10:54:26 CEST] <fritsch> which would be the perfect usecase ... for a performant chain
[10:54:55 CEST] <__gb__> skylake was not designed last year you know :)
[10:55:15 CEST] <__gb__> neither the year before, and the year before the year before
[10:55:59 CEST] <fritsch> hehe
[10:56:14 CEST] <__gb__> the keyword you want for "driver scaling" (which includes HW fixed-function scaling) is SFC, it seems based on the link
[10:56:52 CEST] <__gb__> well, I of course know the details, but I couldn't find the same level of details yet, so that's probably only teasing for you :)
[10:57:37 CEST] <fritsch> __gb__: oki, so to summarize: if we get the 10 bit blob, we can cope with the rest and given api - so the big question now is: whom to ask, whom to contact in order to get things forward
[11:00:08 CEST] <__gb__> it depends on the customer and some numbers I'd guess
[11:00:27 CEST] <fritsch> we get the customers, we get the numbers
[11:00:32 CEST] <fritsch> that's not the problem
[11:00:47 CEST] <fritsch> and I think ffmpeg here has even much more users than kodi has
[11:00:57 CEST] <__gb__> and I myself kept asking for the same things multiple times
[11:01:08 CEST] <fritsch> yeah - i am good in asking :-)
[11:01:18 CEST] <fritsch> you know that from our VPP work, hehe
[11:01:19 CEST] <BtbN> ffmpeg by itself can't make use of vaapi though.
[11:01:20 CEST] <__gb__> I meant, the same things as you :)
[11:01:27 CEST] <BtbN> yet
[11:02:16 CEST] <nevcairiel> the built-in hwaccels in ffmpe.c are more of a developer tool than actually useful features for users, they would need some crucial additions to become useful and not just crawling slow
[11:02:22 CEST] <nevcairiel> ffmpeg.c*
[11:02:45 CEST] <nevcairiel> i like having them to run FATE against a hwaccel ;)
[11:02:45 CEST] <BtbN> On my nvidia boxes it gives me basicaly CPU-Load-Free transcoding though.
[11:02:57 CEST] <BtbN> vdpau decode, nvenc encode.
[11:03:04 CEST] <fritsch> nevcairiel: we use them
[11:03:36 CEST] <nevcairiel> BtbN: nvidia makes a bit of an exception there, since they handle the missing part with DMA for you :)
[11:03:43 CEST] <nevcairiel> but AMD or Intel, forget it :D
[11:03:55 CEST] <BtbN> Of course the hwaccels in lavc get used. But those are useless without some other application making use of them.
[11:04:08 CEST] <nevcairiel> fritsch: why would you use ffmpeg.c
[11:04:20 CEST] <fritsch> nevcairiel: ah - we don't was a misunderstanding
[11:04:35 CEST] <fritsch> __gb__: i will ask our intel contact, that we got last time when kodi had an issue
[11:04:46 CEST] <fritsch> __gb__: and try to "escalate" things (in a positive way)
[11:04:52 CEST] <fritsch> perhaps we can get something forward
[11:04:59 CEST] <iive> wasn't there some recent addition to mesa, that allows direct access to raw image buffer?
[11:05:01 CEST] <__gb__> who is he? yann?
[11:05:19 CEST] <fritsch> __gb__: let me have a look
[11:05:19 CEST] <iive> containing video surface
[11:06:03 CEST] <__gb__> iive, there are multiple EGL APIs for it, depending on the vendor -- but most would agree on supporting dma_buf anyway
[11:06:20 CEST] <fritsch> __gb__: belinda, liviero; luming yu, victoria a davis, stephen R wood
[11:06:40 CEST] <fritsch> __gb__: according to the answer - pur management :-)
[11:06:43 CEST] <fritsch> pure
[11:07:12 CEST] <fritsch> basically the talk was not useful at all - chris wilson  fixed the bug, but we can try again
[11:09:27 CEST] <__gb__> chris can fix any gfx kernel related problem, you know :)
[11:09:32 CEST] <fritsch> jep
[11:09:50 CEST] <fritsch> yeah - he has done a wole lot for us
[11:09:55 CEST] <fritsch> really nice guy
[11:10:04 CEST] <fritsch> so - is it worth the effort to write  to this persons?
[11:10:17 CEST] <fritsch> or should I write to "Sean something" which enabled some features in BSW lately?
[11:46:41 CEST] <durandal_1707> swscale was written for pentiums
[11:47:06 CEST] <durandal_1707> to quote wm4
[11:50:13 CEST] <wm4> durandal_1707: slight dramatization, but mostly correct
[11:56:26 CEST] <durandal_1707> wm4: you are missing the Disneyland...
[12:04:37 CEST] <wm4> I'm not coming to vdd
[12:05:08 CEST] <iive> why?
[12:05:56 CEST] <wm4> because I'm sitting in fucking italy
[12:06:10 CEST] <iive> why?
[12:06:12 CEST] <wm4> and apparently there's no good way to getfrom here to there
[12:06:52 CEST] <wm4> because planes are not infinitely fast
[12:07:16 CEST] <iive> why it have to be fast?
[12:08:35 CEST] <wm4> because there's not enough time
[12:09:04 CEST] <wm4> I could have gotten up at 3am on saturday, and end up on 9 am on the airport in paris, but I chose not to do this
[12:10:33 CEST] <iive> isn't the conference is Dublin, Ireland?
[12:10:41 CEST] <nevcairiel> its in Paris
[12:10:48 CEST] <nevcairiel> it was in dublin last year
[12:11:09 CEST] <iive> my bad
[12:13:26 CEST] <iive> at least paris is closer to italy :)
[12:25:21 CEST] <nevcairiel> if you need to fly, the distance inside europe really makes no big difference
[13:27:58 CEST] <Plorkyeran> yeah, one hour and two hours on the plane is fairly irrelevant
[13:28:16 CEST] <Plorkyeran> since either way the travel time to/from the airport and airport bullshit will be more significant
[13:46:07 CEST] <BtbN> Yay, i think i finaly finished that chromakey filter.
[13:48:14 CEST] <BtbN> nevcairiel, btw., what's the status of that hevc parsing fix? Is it already in master, or are you still improving it?
[13:49:39 CEST] <nevcairiel> i wanted to give the openhevc guys some more time to answer, but i'll probably send ti to the ML this weekend
[13:49:57 CEST] <BtbN> Ah, the decoder code comes from them?
[13:55:05 CEST] <nevcairiel> mostly yes
[14:03:49 CEST] <iive> BTW, what is happening with the hosting?
[14:06:40 CEST] <BtbN> Works fine for me?
[14:07:57 CEST] <iive> i mean, what happened with the new selected locations? Have the site moved?
[14:26:43 CEST] <cone-099> ffmpeg 03Paul B Mahol 07master:32e1af77ec12: avcodec/dcaenc: fix lfe fir coefficients
[14:26:43 CEST] <cone-099> ffmpeg 03Paul B Mahol 07master:770b0ed0e017: Changelog: add forgotten entry
[14:37:51 CEST] <satiender> I what is resource for capture video from camera or screen in C code using ffmpeg api
[14:42:40 CEST] <J_Darnley> Windows has gdi and dshow input, linux has x11grab and video4linux, macos has something
[14:43:14 CEST] <BtbN> And xcbgrab
[14:43:24 CEST] <J_Darnley> They're all available as input formats in ffmpeg
[14:43:49 CEST] <J_Darnley> As for the API, I don't know
[14:44:24 CEST] <J_Darnley> I would have thought that avformat and the right "filename" would work
[14:49:16 CEST] <durandal_1707> anyone gona adopt -loop option for ffmpeg from libav?
[14:54:29 CEST] <ubitux> durandal_1707: it's not merged?
[14:54:51 CEST] <BtbN> -help full lists it for me
[14:55:27 CEST] <durandal_1707> that is something else IIRC
[14:55:46 CEST] <cone-099> ffmpeg 03Timo Rothenpieler 07master:85c343faade5: avfilter/vf_colorkey: Improve filter description
[14:55:52 CEST] <iive> -loop works only with images.
[14:55:52 CEST] <satiender> durandal_1707: Hi Sir , Now I am capable use ffmpeg Api 
[14:57:47 CEST] <satiender> durandal_1707: can you little bit help me for give some idea or resource link for capture or grab screen with ffmpeg Api in my C code , please just idea or resource 
[15:00:27 CEST] <durandal_1707> I do know nothing about android capture, you are on wrong channel again, next time I will kick you
[15:28:58 CEST] <satiender> durandal_1707 : No , I am talking about linux not android 
[15:29:45 CEST] <durandal_1707> ask on #ffmpeg
[15:30:38 CEST] <satiender> durandal_1707: You kick me , why ?? what I do wrong ??
[15:30:57 CEST] <fritsch> satiender: you are in the wrong channel
[15:31:05 CEST] <fritsch> satiender: #ffmpeg is the user channel
[15:31:11 CEST] <ubitux> ffplay crashes out of the box.
[15:31:18 CEST] <satiender> I am just asking , If don't like then you can ignore my question 
[15:31:28 CEST] <satiender> fritsch : ok
[15:32:00 CEST] <fritsch> "Questions about using FFmpeg or developing with libav* libs should be asked in  #ffmpeg"
[15:34:22 CEST] <durandal_1707> ubitux: not here
[15:34:30 CEST] <ubitux> durandal_1707: ffplay -f lavfi color
[15:34:34 CEST] <ubitux> (or whatever filter)
[15:44:23 CEST] <durandal_1707> ubitux: doesn't happen here
[15:45:20 CEST] <ubitux> ok, i'll bisect
[16:15:32 CEST] <ubitux> i guess it was a misbuild or sth.
[17:24:11 CEST] <wm4> where's the meeting irc log?
[17:26:50 CEST] <cbsrobot_> stefano attached them in the "IRC meeting on Saturday 2015-09-12, UTC 15:00" thread
[17:29:14 CEST] <cone-099> ffmpeg 03James Almer 07master:2f9ab159607f: x86/vp9: add avx2 subpel MC SIMD for 10/12bpp
[17:30:51 CEST] <durandal_1707> michaelni: are you gonna work on swscale modernization?
[17:39:25 CEST] <cbsrobot_> durandal_1707: do you plan to work on >8bit support in drawutils ?
[17:42:58 CEST] <cone-099> ffmpeg 03James Almer 07master:36e1665d3d06: avutil/attributes: add AV_GCC_VERSION_AT_MOST
[17:43:24 CEST] <wm4> durandal_1707: should use zimg instead
[17:46:25 CEST] <durandal_1707> cbsrobot_: not for free :-P
[17:46:43 CEST] <cbsrobot_> durandal_1707: there's a bounty for it!
[17:47:19 CEST] <cbsrobot_> see ticket 3343
[17:48:57 CEST] <durandal_1707> wm4: git repo?
[17:53:13 CEST] <RiCON> durandal_1707: https://github.com/sekrit-twc/zimg/
[17:53:59 CEST] <durandal_1707> nice patch on ml for function ffmpeg doesn use
[18:02:24 CEST] <durandal_1707> wtf zimg doesn't support alpha
[18:27:33 CEST] <michaelni> durandal_1707, if others contribute then probably yes
[18:52:29 CEST] <cone-099> ffmpeg 03Muhammad Faiz 07master:5b48dd75d578: avfilter/avf_showcqt: use frequency domain windowing
[19:09:58 CEST] <durandal_1707> is it ok to write lgpl wrapper for gpl code?
[19:13:01 CEST] <jamrial> durandal_1707: apparently it is, judging by x264/5 wrappers
[19:14:59 CEST] <nevcairiel> the wrapper code can be lgpl, as long as configure still checks the proper license w hen building
[19:22:50 CEST] <zylthinking> hi, I readed aac stream using avformat get the first bytes of aac is 0000000: 0132 15ae 4c3b 0a06 c2e3 b0a0 ac52 140d
[19:23:00 CEST] <zylthinking>  it indeed is not an adts packet, nor a LATM packet\
[19:23:08 CEST] <zylthinking> if it is a aac stream without any header, then I don't know any information of it and can't decode it
[19:23:30 CEST] <zylthinking> what indeed these bytes are?
[19:23:43 CEST] <nevcairiel> if the container provides the missing information, there is avctx->extradata
[19:23:47 CEST] <nevcairiel> but this is a question for #ffmpeg
[19:24:00 CEST] <zylthinking> ok, thanks
[20:16:15 CEST] <cone-099> ffmpeg 03James Almer 07master:e47564828b9b: x86/vp9mc: add missing preprocessor guards
[21:26:59 CEST] <durandal_170> what's about writting blog entry for gsoc?
[22:31:05 CEST] <durandal_170> wm4: it sucks that zimg doesn't support alpha
[23:09:12 CEST] <cone-099> ffmpeg 03Ganesh Ajjanagadde 07master:0fe1c50e5051: all: do standards compliant absdiff computation
[23:37:15 CEST] <cone-099> ffmpeg 03Ganesh Ajjanagadde 07master:b4cb59790015: libswscale/swscale: fix -Wunused-function
[00:00:00 CEST] --- Sat Sep 19 2015