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

[burek]

[00:14:26 CEST] <cone-248> ffmpeg 03Bryan Huh 07master:949444348b75: avformat/dump: Fix sign bug in reported "start" time
[00:51:00 CEST] <cone-248> ffmpeg 03Jan Sebechlebsky 07master:2ea5ab6fc6b1: avformat/tee: Refactor close_slaves function in tee muxer
[01:38:41 CEST] <furkan> close
[01:38:48 CEST] <furkan> oops
[02:24:56 CEST] <cone-248> ffmpeg 03James Almer 07master:868bce48f6d8: avformat/framehash: add sidedata checksum
[02:24:57 CEST] <cone-248> ffmpeg 03James Almer 07master:0efafc584903: avformat/framehash: enable new output
[03:58:48 CEST] <rcombs> Daemon405: 6f69f7a8b breaks automatic bitstream filtering when the bsf reads input extradata (though it works fine when it only writes it); thoughts on this patch to fix? https://gist.github.com/cc357b39e5dad4eb7cb45e987736185e
[04:32:29 CEST] <michaelni> rcombs, can you add a fate test for this once its fixed ?
[04:40:50 CEST] <rcombs> probably
[04:41:46 CEST] <rcombs> one for mp4toannexb and one for adtstoasc, I guess
[04:49:26 CEST] <michaelni> k, if theres something to upload to fate-samples, ping me
[05:00:32 CEST] <rcombs> michaelni: nah, it'll probably just be remuxing existing h264 and aac samples
[06:31:47 CEST] <jamrial> rcombs: the size checks seem superfluous. av_malloc already does them
[06:34:25 CEST] <rcombs> jamrial: I was copying behavior from ff_alloc_extradata, which returns EINVAL in that case, but if you think it's unnecessary I'm not attached to it
[06:38:27 CEST] <jamrial> ah, if you want to signal einval then yeah, keep them
[06:38:36 CEST] Action: rcombs shrugs
[06:38:39 CEST] <rcombs> doesn't hurt either way
[10:47:42 CEST] <ubitux> Daemon405: re: c849ed8b2fa2e3d6d4464c652b403fe4a0b9746e there is another ref in that file
[11:49:27 CEST] <kierank> michaelni: why are you sending emails saying my student has no mentor
[12:19:12 CEST] <durandal_1707> michaelni: one of your changes broke bmp parser, please fix it
[12:19:33 CEST] <durandal_1707> last two commits to file
[12:21:38 CEST] <michaelni> durandal_1707, how can i reproduce this ?
[12:22:47 CEST] <durandal_1707> michaelni: see ticket #5438
[12:24:26 CEST] <durandal_1707> basicall supporting bmps with no size of file is fruitless
[12:25:27 CEST] <michaelni> kierank, because mentoring means doing a shitload of work and noone seems doing that work
[12:25:48 CEST] <kierank> well you are wrong
[12:27:45 CEST] <michaelni> none of the students patches have any replies or reviews, if that doesnt mean "noone seems doing the work" then i dont know what does
[12:28:04 CEST] <kierank> that's because it's code I wrote...
[12:28:15 CEST] <kierank> and the student is working on getting it into mainline
[12:28:23 CEST] <kierank> carl said student didn't send patches, student then sent patches
[12:28:31 CEST] <michaelni> ahh, ok but still
[12:28:35 CEST] <michaelni> someone has to review it
[12:28:44 CEST] <kierank> yes, get carl to do it
[12:28:47 CEST] <kierank> he was the one complaining
[12:28:53 CEST] <michaelni> its not carls job
[12:29:09 CEST] <kierank> if he complains about lack of patches he should damn well review them
[12:29:29 CEST] <michaelni> its his job as admin to complain if something is missing
[12:31:42 CEST] <kierank> to be more precise patch 1 is mine/Stefano/Andreas and 2/3 is by the student
[12:31:58 CEST] <kierank> but they are dependent so someone needs to review 1
[12:36:39 CEST] <michaelni> so we need someone to review the patches over the course of gsoc (that is now till end) for this project to be possible
[12:36:54 CEST] <kierank> oh for god sake
[12:37:00 CEST] <kierank> how hard is it for you to understand
[12:37:12 CEST] <kierank> the first patch in the patchset is my patch so I can't review it
[12:37:17 CEST] <kierank> the next two are dependent
[12:37:28 CEST] <kierank> so I am waiting for a review of 1 so that I can review 2/3
[12:37:43 CEST] <kierank> the rest of the patches for gsoc I will review as mentor
[12:37:56 CEST] <kierank> ALSO, since it's a test suite program like fate these patches won't necessarily go into mainline
[12:38:00 CEST] <kierank> are you happy now?
[12:39:18 CEST] <michaelni> can you find someone to review patches that you cant review ? (its your job as mentor IMO)
[12:39:46 CEST] <kierank> michaelni: speak for yourself
[12:39:54 CEST] <kierank> and the number of times you push patches to git without review
[12:40:20 CEST] <wm4> lol.
[13:41:37 CEST] <fritsch> since ffmpeg 3.x we continuingly run into segfaults, when convertion from yuv to rgba ... which is only workarounded by aligning the buffer's start adress to 16 byte
[13:41:56 CEST] <nevcairiel> its generally wise to do that anyway
[13:42:03 CEST] <nevcairiel> because the alternative is using extremely slow conversion
[13:42:07 CEST] <fritsch> yeah, we have a home grown kodi since years :-)
[13:42:12 CEST] <fritsch> and supply sometimes external buffers
[13:42:18 CEST] <fritsch> but three more places to go
[13:42:19 CEST] <fritsch> and fine
[13:42:25 CEST] <fritsch> though, it's kind of a regression
[13:42:48 CEST] <durandal_1707> what arch?
[13:42:52 CEST] <fritsch> arm
[13:43:03 CEST] <fritsch> https://github.com/fritsch/xbmc/commit/a7c9359722aa039132d652379237a9c5522abc5c <- last one
[13:43:13 CEST] <nevcairiel> probably some new arm optimization that doesnt have checks
[13:43:20 CEST] <durandal_1707> there where patches for it?
[13:43:24 CEST] <fritsch> jep
[13:43:32 CEST] <fritsch> my colleague tracked it down to a certain commit
[13:43:34 CEST] <fritsch> one moment, please
[13:43:54 CEST] <mateo`_> It's probably mine I guess
[13:44:04 CEST] <fritsch> will ping you some time later ... oral exam and the student is appearing :-)
[13:44:09 CEST] <fritsch> mateo`_: yeah, i think so
[13:45:39 CEST] <mateo`_> fritsch: if you can give me your use-case, ie: using sws scale directly or whatever, i'll make a patch
[13:46:26 CEST] <fritsch> yeah - i tried to reproduce from command line but could not
[13:46:34 CEST] <fritsch> most likely as ffmpeg allocates its buffers correctly
[13:46:39 CEST] <fritsch> one use case you see in the above commit
[13:46:52 CEST] <fritsch> http://xbmclogs.com/p2bizm4cv <- basically
[13:46:53 CEST] <fritsch> last line
[13:47:03 CEST] <fritsch> if you get this warning it will crash
[13:47:13 CEST] <fritsch> shortly afk - thx much
[13:48:07 CEST] <mateo`_> yeah because it's an unscaled conversion and it beleives there is no generic accelerated path if i remember correctly
[13:51:41 CEST] <ubitux> aren't image buffers fed to ffmpeg always supposed to be aligned?
[13:51:55 CEST] <ubitux> or basically allocated with av alloc* funcs?
[13:52:01 CEST] <wbs> not for swscale at least
[13:53:23 CEST] <nevcairiel> i think i've had x86 scaling also crash before without alignment
[13:54:11 CEST] <wbs> it has occasionally been broken, but mostly should work. would probably good to have tests for it (or declare clearly that it isn't supported)
[13:54:24 CEST] <wbs> at least for input it really should be supported though
[13:55:20 CEST] <mateo`_> so we need a check before on the src alignment before it reaches the accelerated path ...
[13:55:33 CEST] <mateo`_> -before
[13:57:55 CEST] <ubitux> i see all kind of mova in x86 code
[13:58:15 CEST] <ubitux> but maybe that's for other stuff
[13:58:21 CEST] <nevcairiel> if he gets that particular warning its using C code though
[13:58:49 CEST] <nevcairiel> maybe the C does evil things that crash on arm due to type alignment constraints?
[13:58:50 CEST] <ubitux> nevcairiel: no, that warning is broken
[13:58:52 CEST] <ubitux> :D
[13:58:58 CEST] <Daemon405> ubitux, feel free to remove that ref
[13:59:01 CEST] <nevcairiel> lol
[13:59:24 CEST] <ubitux> nevcairiel: the warning is raised if it doesn't find the optimisation in the "first pass of setting simd functions"
[13:59:32 CEST] <ubitux> or sth along these lines :p
[13:59:46 CEST] <ubitux> anyway, yuv420p to rgb* is an unscaled accelerated path
[14:00:02 CEST] <ubitux> on arm & aarch64 at least
[14:00:25 CEST] <ubitux> i'm not sure how we're supposed to deal with unaligned buffers here
[14:02:58 CEST] <ubitux> fritsch: can you show a backtrace and registers?
[14:03:24 CEST] <Daemon404> wm4, next merges are the hw stfuf youve been waiting for i think
[14:03:39 CEST] <Daemon404> from jkqxz 
[14:04:05 CEST] <wm4> dunno
[14:04:12 CEST] <Daemon404> well, some of them
[14:04:52 CEST] <wm4> ah, hwcontext shit
[14:05:48 CEST] <wm4> and another annoying deprecation
[14:06:18 CEST] <wm4> and ahead is the new bitstream API
[14:09:11 CEST] <Daemon404> yes
[14:09:17 CEST] <Daemon404> i want yo get both in today
[14:09:19 CEST] <Daemon404> if possible
[14:10:01 CEST] <nevcairiel> bsf api may break autobsf to some degree
[14:10:23 CEST] <nevcairiel> not sure if its fully compatible with our hacks to the extradata
[14:11:09 CEST] <nevcairiel> it would also be nice to finally decide on one way to update extradata in bsfs, i've at least seen two in post-bsf-rewrite in libav
[14:11:48 CEST] <nevcairiel> (sidedata and updating output codecpar)
[14:12:18 CEST] <wm4> sounds like a pain
[14:12:35 CEST] <wm4> is sidedata for mid-stream updates or so?
[14:12:49 CEST] <nevcairiel> both could be midstream =p
[14:13:18 CEST] <nevcairiel> personally i would probably just make the filters all emit sidedata, and then catch that sidedata in generic bsf code and update codecpar from that
[14:13:22 CEST] <nevcairiel> but what do i know
[14:25:20 CEST] <jkqxz> Daemon404:  Do poke me if there is anything annoying in those merges; I'm happy to deal with it myself.
[14:25:57 CEST] <Daemon404> jkqxz, sure.
[14:28:50 CEST] <jkqxz> (I think the first set should be mostly fine, but the (avconv|ffmpeg)_vaapi.c one a bit later might be nasty.)
[14:29:04 CEST] <Daemon404> :)
[14:32:03 CEST] <cone-945> ffmpeg 03Luca Barbato 07master:1098f5c0495c: svq3: Use a separate buffer for decoding the slices
[14:32:03 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:7af788aa6257: Merge commit '1098f5c0495c61a98d4ff6b8e24c17974d4bace5'
[14:38:33 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:b1f01e85a92d: lavu: add a way to query hwcontext frame constraints
[14:38:34 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:afccfaf26ac8: Merge commit 'b1f01e85a92d401a9b29c79f23db36b7685e8c09'
[14:45:22 CEST] <fritsch> ubitux: sadly not - working on it. It only happens on user's systems - not on mine
[14:46:03 CEST] <fritsch> ubitux: https://github.com/FFmpeg/FFmpeg/commit/b32a42295ad7b254f9662082d799c0aae2071c2e <- the user affected pointed on this commit, but as I did not bisect it myself ... i cannot verify
[14:46:07 CEST] <fritsch> aligning the buffers fixed the issues
[14:46:17 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:d264c720f7b7: lavu: deprecate AV_PIX_FMT_VAAPI_*, replace with AV_PIX_FMT_VAAPI
[14:46:18 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:eb2da769bddf: Merge commit 'd264c720f7b74286840719e506daba39f83b438b'
[14:47:19 CEST] <fritsch> ubitux: the fix (to use aligned buffers fixed the issue) user reported back: http://forum.kodi.tv/showthread.php?tid=269232&pid=2310549#pid2310549 (sorry, just a user ... they speakk as l33t 4s th3y l1k3)
[14:48:36 CEST] <ubitux> fritsch: i know that's not a valid answer to the issue, but is it a problem to have these buffers aligned?
[14:48:46 CEST] <fritsch> no, not at all
[14:48:47 CEST] <fritsch> :-)
[14:48:50 CEST] <fritsch> i will align them anyways
[14:49:16 CEST] <fritsch> now I saw the issue ... but it's most likely regression as one needs to make really sure that users don't supply their own bufers
[14:49:28 CEST] <fritsch> which are 16 aligned concerning the stride, but not concerning memory adress
[14:53:53 CEST] <wm4> why are you using libswscale for RGB conversion at all?
[14:56:02 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:551c6775abb5: lavu: VAAPI hwcontext implementation
[14:56:03 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:28abb216cbd5: Merge commit '551c6775abb5e0ad34c26d7e23bc6fbbe8ccc9d4'
[15:01:11 CEST] <cone-945> ffmpeg 03Mark Thompson 07master:07a844f32ebb: lavfi: generic hardware surface upload and download filters
[15:01:12 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:8688d3af39e8: Merge commit '07a844f32ebb78503981df017fa3ebfedb75fe1c'
[15:02:04 CEST] <cone-945> ffmpeg 03Luca Barbato 07master:9765549f551f: mpegts: Forward the errors on mpeg4 objects parsing
[15:02:05 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:0520d573db71: Merge commit '9765549f551ff40869aee1a6492b6a976c86cfe9'
[15:02:39 CEST] <cone-945> ffmpeg 03Andreas Cadhalpun 07master:a2d1922bde8d: takdec: ensure chan2 is a valid channel index
[15:02:40 CEST] <cone-945> ffmpeg 03Derek Buitenhuis 07master:e1a8f7818cc8: Merge commit 'a2d1922bde8db2cdac95051918fe81ae18c0376b'
[15:02:51 CEST] <Daemon404> nevcairiel, next commit is "lavc: add a new bitstream filtering API"
[15:02:57 CEST] <Daemon404> i assume this wont be "simple"?
[15:18:32 CEST] <fritsch> wm4_: why not?
[15:18:40 CEST] <fritsch> it's easy to supply our given buffer
[15:18:43 CEST] <wm4_> isn't it slow
[15:18:48 CEST] <fritsch> nope
[15:18:53 CEST] <fritsch> context setup perhaps
[15:18:56 CEST] <wm4_> on what shit devices does this run?
[15:19:00 CEST] <fritsch> lol
[15:19:04 CEST] <fritsch> on the xbox 1 :-)
[15:19:06 CEST] <wm4_> (and why are they fast enough for this)
[15:19:12 CEST] <wm4_> lol indeed
[15:19:23 CEST] <fritsch> pi, arm devices and so on
[15:19:38 CEST] <fritsch> and our texturepacker needs RGBA
[15:19:44 CEST] <wm4_> the rpi can output RGB just fine
[15:19:50 CEST] <wm4_> s/RGB/YUV
[15:19:52 CEST] <fritsch> it's not about outputting
[15:20:04 CEST] <fritsch> see for example: https://github.com/xbmc/xbmc/pull/9623/commits/a7c9359722aa039132d652379237a9c5522abc5c
[15:20:11 CEST] <fritsch> it's used to extract a thumb image
[15:20:15 CEST] <fritsch> and store it as texture
[15:20:25 CEST] <ubitux> wm4_: hey sws is fast now for this!
[15:20:26 CEST] <wm4_> ah, that makes sense
[15:20:54 CEST] <fritsch> i think I hit all the sws_scales in our code ... and when interacting with sws_scale memory adress should be 16 aligned now
[15:20:57 CEST] <wm4_> if you want a total freak usage of libswscale, mpv uses it to render subtitles to YUV surfaces (only used in encoding more or for good old Xv)
[15:23:13 CEST] <fritsch> as we depend on sws_scale in those methods anyways ... we should use av_malloc
[15:23:21 CEST] <fritsch> right away ... to be "safe" for the future
[15:23:39 CEST] <fritsch> at least when we allocate in the classes where sws_scale happens
[15:24:17 CEST] <fritsch> that was for the wrong channel
[15:24:37 CEST] <wm4_> still good advice though
[15:25:06 CEST] <wm4_> I'd just use AVFrame everywhere
[15:25:20 CEST] <wm4_> and maybe I should resend my patch that adds a AVFrame libswscale API
[15:29:30 CEST] <cone-706> ffmpeg 03Michael Niedermayer 07master:8e26bdd59bf5: avcodec/bmp_parser: Ensure remaining_size is not too small in startcode packet crossing corner case
[15:29:33 CEST] <michaelni> durandal_170, fixed the bmp case
[15:42:00 CEST] <Daemon404> nevcairiel, feel liek helping me out with the bsf stuff at some point?
[15:48:11 CEST] <durandal_170> merbzt: I stare at decompiler output and couldnt find nothing wrong with our decoder
[15:55:14 CEST] <durandal_170> except that lpc filter is missing
[16:01:22 CEST] <nevcairiel> Daemon404: i have like an hour now, then nothing until saturday or so
[16:02:17 CEST] <Daemon404> urg
[16:02:39 CEST] <Daemon404> you seem to understand the problem space a lot better than me though
[16:03:35 CEST] <nevcairiel> going to the cinema tonight, and got some appointments tomorrow
[16:03:41 CEST] <nevcairiel> but that patch shouldnt be that bad
[16:03:49 CEST] <nevcairiel> just need to update the BSFs libav doesnt have
[16:03:52 CEST] <Daemon404> i wasnt sure how to handle some extradata stuff we have but they dont
[16:03:56 CEST] <Daemon404> in shared bsfs
[16:04:00 CEST] <nevcairiel> like what
[16:04:24 CEST] <Daemon404> aac_adtstoasc_bsf.c shows one
[16:04:37 CEST] <nevcairiel> dont they have that
[16:05:20 CEST] <nevcairiel> like I ranted on earlier, for some reason libav shows two variations on handling extradata, either they update the outgoing codecpar directly, or they send extradata changed sidedata
[16:05:37 CEST] <wm4_> what did elenril say to this
[16:05:43 CEST] <nevcairiel> i forgot to ask, i think
[16:06:01 CEST] <Daemon404> ah... right...
[16:06:30 CEST] <Daemon404> do you want me to skip merging the avconv bsf conversion
[16:06:33 CEST] <nevcairiel> for some reason the aac bsf doesnt even allow the extradat to change beyond the first frame
[16:06:35 CEST] <Daemon404> because i dont think i CAN merge it anyway
[16:06:43 CEST] <Daemon404> since we havent converted to codecpar in ffmpeg.c
[16:06:46 CEST] <nevcairiel> so changing codecpar is probably the better approach
[16:06:53 CEST] <nevcairiel> and works with autobsf better
[16:07:02 CEST] <Daemon404> lemme guess: no autobsf fate tests
[16:07:06 CEST] <nevcairiel> so for the moment i would skip the sidedata approach
[16:07:30 CEST] <Daemon404> heh
[16:07:48 CEST] <nevcairiel> what other bsfs do we have that change extradata
[16:08:08 CEST] <nevcairiel> mp4toannexb bsfs dont support changing extradata mid-stream, since mp4-style doesnt allow that
[16:08:39 CEST] <Daemon404> libavcodec/remove_extradata_bsf.c ?
[16:08:44 CEST] <Daemon404> (lol why does this exist)
[16:08:52 CEST] <nevcairiel> clearly thats a onetime change to extradata as well
[16:08:53 CEST] <nevcairiel> and no idea
[16:09:29 CEST] <Daemon404> my big problem is that we dont have anything that tests bsfs well in fate
[16:09:33 CEST] <Daemon404> autobsf, concat, etc
[16:09:35 CEST] <Daemon404> nothin'.
[16:10:48 CEST] <Daemon404> nevcairiel, ill try and merge today and maybe we can attempt to start to tackle ffmpeg.c conversion sometime soon
[16:10:51 CEST] <Daemon404> keyword: attemot
[16:10:54 CEST] <Daemon404> s/o/p/
[16:11:18 CEST] <nevcairiel> sure
[16:12:36 CEST] <Daemon404> btw
[16:12:50 CEST] <Daemon404> weve been runnign post-codecpar ffmpeg for a subset of transcodes at work
[16:12:57 CEST] <Daemon404> nothing really of note has failed or changed
[16:12:57 CEST] <Daemon404> afaik
[16:13:02 CEST] <Daemon404> seems pretty stable.
[16:14:06 CEST] <nevcairiel> maybe we should add a aac adts -> mkv including autobsf test to fate if its really not tested
[16:14:13 CEST] <nevcairiel> its the prime example what autobsf was supposed to fix
[16:14:38 CEST] <Compn> durandal_170 : so you found truemotion2rt sample  ? :)
[16:15:23 CEST] <Daemon404> nevcairiel, i was also planning to add a chapters/ffprobe test
[16:15:30 CEST] <Daemon404> since fate failed to catch that chapters regression yesterday
[16:15:43 CEST] <durandal_170> Compn: lol no, piotr created them...
[16:18:40 CEST] <Daemon404> libavcodec/bsf.h [copied from libavcodec/chomp_bsf.c with 53% similarity]
[16:18:42 CEST] <Daemon404> lol git...
[16:18:42 CEST] <Compn> best solution :)
[16:19:12 CEST] <nevcairiel> Daemon404: copyright header, i assure you
[16:19:12 CEST] <Compn> durandal_170 : what codecs are you working on next? just curious :)
[16:19:53 CEST] <Daemon404> nevcairiel, yep
[16:22:40 CEST] <durandal_170> Compn: optimfrog
[16:23:41 CEST] <wm4_> fritsch: how terrible is amlogic?
[16:24:10 CEST] <fritsch> don't ask :-(
[16:24:16 CEST] <fritsch> it's a "streaming" decoder
[16:24:26 CEST] <fritsch> made for decode + render by their own
[16:24:32 CEST] <fritsch> so the moment you don't care about audio
[16:24:39 CEST] <fritsch> you don't care about dropping / skipping
[16:24:42 CEST] <fritsch> don't render subtitles
[16:24:44 CEST] <fritsch> it's nice :-)
[16:25:05 CEST] <fritsch> the moment you want to exactly know when the pic appears and do proper a/v sync
[16:25:08 CEST] <fritsch> it sucks
[16:25:25 CEST] <fritsch> in kodi it was used for years with a global "player" clock
[16:25:43 CEST] <fritsch> and it just told the player: this  pic will be presented one frame in the future
[16:25:47 CEST] <fritsch> no matter how late it was
[16:25:52 CEST] <fritsch> we have big problems with it currently
[16:25:57 CEST] <fritsch> as maintainer is gone
[16:26:14 CEST] <wm4_> maintainer gone? on the kodi or the amlogic side?
[16:26:19 CEST] <fritsch> we experimented with the v4l api
[16:26:22 CEST] <fritsch> to get the frames back
[16:26:27 CEST] <fritsch> yeah for kodi
[16:27:50 CEST] <wm4_> terrible
[16:27:51 CEST] <fritsch> wm4_: you need to make a video player around it?
[16:28:02 CEST] <wm4_> some are asking
[16:28:08 CEST] <fritsch> if yes, check kodi's AMLogic.cpp and VideoCodecAML.cpp
[16:28:29 CEST] <fritsch> i can also give you the contact of the really cool first author
[16:28:39 CEST] <fritsch> in kodi it is used "bypass" style
[16:28:47 CEST] <fritsch> you set a chain via sysfs / procfs
[16:28:56 CEST] <wm4_> wat
[16:28:58 CEST] <fritsch> and decoded stuff directly hits the output
[16:29:10 CEST] <fritsch> this thingy is not ment like:
[16:29:20 CEST] <fritsch> frame = aml->decode(data);
[16:29:23 CEST] <fritsch> display(frame);
[16:29:30 CEST] <Daemon404>     do {
[16:29:30 CEST] <Daemon404>         bsf->next = first_bitstream_filter;
[16:29:30 CEST] <Daemon404>     } while(bsf->next != avpriv_atomic_ptr_cas((void * volatile *)&first_bitstream_filter, bsf->next, bsf));
[16:29:35 CEST] <Daemon404> well this is.... something
[16:29:39 CEST] <Daemon404> (from ffmpeg)
[16:29:45 CEST] <wm4_> Daemon404: yeah, duplicated all over the place
[16:29:54 CEST] <wm4_> (for other component lists)
[16:30:05 CEST] <wm4_> this code dies now, doesn't it
[16:30:22 CEST] <Daemon404> at least where im looking, it dies
[16:30:26 CEST] <Daemon404> cant say for teh copypasted bits
[16:31:00 CEST] <wm4_> fritsch: ARM/Linux stuff is so sad
[16:33:15 CEST] <fritsch> yeah - you can be our AMLCodec maintainer if you want :-)
[16:34:32 CEST] <wm4_> fritsch: so the v4l API didn't work?
[16:34:47 CEST] <fritsch> it worked
[16:34:50 CEST] <fritsch> but slow as hell
[16:35:00 CEST] <fritsch> there is an open PR on github
[16:35:04 CEST] <fritsch> about it
[16:35:48 CEST] <wm4_> and apparently the hw works fine on android
[16:36:38 CEST] <fritsch> yes
[16:36:53 CEST] <fritsch> wait it was not v4l at the end
[16:36:56 CEST] <fritsch> let me recheck
[16:37:28 CEST] <fritsch> it was the ION driver
[16:38:24 CEST] <wm4_> uh what's ION?
[16:38:33 CEST] <fritsch> https://github.com/xbmc/xbmc/pull/9432/commits/194ba453080db5cb0762ff7f091081800e8e1bb1
[16:38:38 CEST] <fritsch> that's what they use in android
[16:38:44 CEST] <fritsch> to use amlogic via mediacodec
[16:38:49 CEST] <fritsch> wrapper to wrapper to wrapper
[16:38:52 CEST] <fritsch> wrapped up nicely
[16:42:38 CEST] <Daemon404> nevcairiel, the annexb filters differ annoyingly from libav
[16:43:16 CEST] <wm4_> fritsch: blergh wtf
[16:43:51 CEST] <Daemon404> libavcodec/hevc_mp4toannexb_bsf.c: Optional argument "private_spspps_buf" to avoid extradata modification.
[16:43:54 CEST] <Daemon404> so this is why
[16:43:56 CEST] <Daemon404> ugh...
[16:44:01 CEST] <Daemon404> what the hell.
[16:44:10 CEST] <Daemon404> of cours it is from nablet...
[16:44:33 CEST] <nevcairiel> we have avoptions in the new design, should at least make it a bit saner
[16:44:47 CEST] <Daemon404> nevcairiel, yeah but merging with that commit makes it far more annoying/complicated
[16:44:58 CEST] <Daemon404> is it even still needed (other than for api compat)
[16:45:09 CEST] <nevcairiel> dunno
[16:45:25 CEST] <Daemon404> as far as i concerned its a shitty hack
[16:45:35 CEST] <wm4_> is this the only place where a bsf uses the argument?
[16:46:05 CEST] <nevcairiel> its nabblet code, they have done nothing but make ffmpeg worse
[16:46:28 CEST] <Daemon404> ... ok so
[16:46:35 CEST] <Daemon404> i cant see, given this commit, how the fuck you'd actually set it
[16:46:48 CEST] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=0b8b18b4fbbd800849d5381a7a90d0e2fcfe6a22
[16:46:52 CEST] <nevcairiel> arguments to the old bsf design was freaking insane
[16:47:52 CEST] <wm4_> av_bitstream_filter_filter(c->bsfc, avctx, "private_spspps_buf", &dummy_p, &dummy_int, NULL, 0, 0);
[16:48:04 CEST] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1defff85
[16:48:08 CEST] <Daemon404> the same crap applied to h264
[16:48:10 CEST] <wm4_> this one would parse the initial extradata
[16:48:11 CEST] <Daemon404> makign merging a big pita
[16:49:53 CEST] <Daemon404> motivation = gone
[16:50:11 CEST] <Daemon404> i dont feel like spending time makign a shit hack work
[16:50:58 CEST] <wm4_> ffmpeg development in a nutshell
[16:52:42 CEST] <Daemon404> i think i made hevc work, but... meh
[16:53:08 CEST] <wm4_> the problem is fixing the old API emulation, right?
[16:54:49 CEST] <Daemon404> wm4_, i have to be careful in writing to teh correct buffer too
[16:55:00 CEST] <Daemon404> also can avoption even take a pointer
[16:55:35 CEST] <wm4_> pointer to what?
[16:55:50 CEST] <Daemon404> the spspps buf.
[16:56:14 CEST] <Daemon404> see: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=0b8b18b4fbbd800849d5381a7a90d0e2fcfe6a22
[16:56:37 CEST] <Daemon404> oh, wait those are not passed
[16:56:38 CEST] <Daemon404> bleh
[16:56:41 CEST] <Daemon404> i just dont want to deal with this
[17:02:03 CEST] <Daemon404> https://github.com/dwbuiten/FFmpeg/commit/037bdc6bf0ffb2c6b1350200637926df6447cc37
[17:02:09 CEST] <Daemon404> nevcairiel / wm4_ - i left off here.
[17:02:15 CEST] <Daemon404> no motivation to deal with nablet's crap
[17:06:11 CEST] <nevcairiel> Daemon404: the aac filter uses the weird sidedata approach, which i dont think makes much sense, but it sounds like you wont finish that tonight either way, so i can work on that hopefully tomorrow morning for a bit before i have to leave again
[17:06:32 CEST] <Daemon404> nevcairiel, i was planning on working on it after making stuff... work/build
[17:06:40 CEST] <Daemon404> but meh
[17:07:17 CEST] <Daemon404> id like someone to poke h264/hevc, really.
[17:09:18 CEST] <nevcairiel> their hack is probably not needed anymore anyway because new bsfs have a in and out context and dont overwrite the only context they have without question
[17:09:35 CEST] <Daemon404> i know. i wanted to just remove it.
[17:09:44 CEST] <Daemon404> but i wasnt sure that was ok or not
[17:19:16 CEST] <jamrial> Daemon404: BBB said he'd convert his vp9 bsf
[17:19:26 CEST] <jamrial> and you should poke durandal_170 for dca_core
[17:19:26 CEST] <Daemon404> sure, but that was never my issue :P
[17:19:40 CEST] <jamrial> just saying :p
[17:20:00 CEST] <nevcairiel> its really trivial to convert things
[17:20:16 CEST] <nevcairiel> i would not even try to merge conversions, just do it myself
[17:40:53 CEST] <durandal_170> so, merges are still comming?
[17:41:28 CEST] <Daemon404> durandal_170, i merged like 60 commits in the last 2 days
[17:41:31 CEST] <Daemon404> have some patience
[17:41:38 CEST] <Daemon404> current WIP is merging the new bsf api
[18:02:56 CEST] <durandal_170> someone was sloppy when doing ff_get_extradata for codecpar
[18:03:20 CEST] <durandal_170> Passing codecpar to log context
[18:03:43 CEST] <Daemon404> good thing you put in so much time to help us and review. 
[18:13:06 CEST] <durandal_170> ok to push fix?
[18:15:03 CEST] <Daemon404> if it is super trivial
[18:23:15 CEST] <durandal_170> it is
[18:24:13 CEST] <durandal_170> just add AVFormatContext to ff_get_extradata
[18:30:42 CEST] <cone-626> ffmpeg 03Paul B Mahol 07master:323b8c95e410: avformat: add AVFormatContext to ff_get_extradata()
[19:03:55 CEST] <Daemon404> roflmao x32
[19:08:45 CEST] <JEEB> lol
[19:35:18 CEST] <llogan> michaelni: why did you remove yourself as a backup Outreachy admin?
[19:36:22 CEST] <Daemon404> presumably because he doesnt want to be
[19:37:44 CEST] <llogan> as the only remaining backup admin i would like to know the actual reason
[19:43:59 CEST] <michaelni> llogan, ive reverted it, so iam backup admin again too
[19:45:10 CEST] <michaelni> but iam happy to remove myself again if someone wants/prefers
[19:46:19 CEST] <llogan> michaelni: i was just curious since i did not hear anything from anyone. if you don't want to be backup that is fine with me, but you should at least let Kieran and I know.
[20:22:51 CEST] <cone-233> ffmpeg 03Paul B Mahol 07master:c9fb81ff411a: avcodec/atrac3: pass AVCodecContext to av_log if available
[20:45:21 CEST] <Daemon404> atrac lossless is a thing?
[20:48:53 CEST] <JEEB> yeah
[20:49:17 CEST] <wm4_> is that dolby trying to make money or what
[20:49:32 CEST] <Daemon404> atarc is sony
[20:49:55 CEST] <JEEB> I should poke ATRAC9 when I have the free time, since they decided to use it for PS4/Vita :V
[20:50:04 CEST] <JEEB> so much audio NIH
[20:53:37 CEST] <TD-Linux> the best part is the PS4 also ships libopus, so they actually have a better audio codec available
[20:59:02 CEST] <JEEB> lol
[20:59:07 CEST] <Daemon404> and people actually will play ps4 games
[20:59:09 CEST] <Daemon404> unlike the vita.
[21:02:00 CEST] <JEEB> yeah, although it's still somewhat alive in a single region
[22:19:51 CEST] <jamrial_> durandal_170: if you're really going to replace scalarproduct_and_madd_int16 with scalarproduct_and_madd_int32 on wmalossless instead of trying to find a way to use one or the other depending on bps, then you can remove the emms_c() after it
[22:20:17 CEST] <jamrial_> there's no need for it anymore
[22:20:52 CEST] <durandal_170> Ok
[22:33:41 CEST] <cone-182> ffmpeg 03Paul B Mahol 07master:9cd2ca9966d0: avcodec/ralf: add support for mono
[23:49:43 CEST] <mgraczyk> Hello, I have a question about adding a new channel layout to FFmpeg.
[23:50:18 CEST] <mgraczyk> I am adding Ambisonic coding support to Opus, and I would like to tell libopusenc that it should be encoding ambisonics.
[23:50:40 CEST] <mgraczyk> It looks like the channel layout structures are based around a bit vector for particular physical channels.
[23:50:55 CEST] <mgraczyk> Ambisonics do not follow such a pattern, but I believe it can be considered a channel layout.
[23:51:21 CEST] <mgraczyk> How could we go about adding ambisonics as a channel layout? Or should we pass it in as a different kind of parameter?
[23:58:13 CEST] <cone-544> ffmpeg 03James Almer 07master:c8ed93efcf4d: avformat/yop: alloc codecpar extradata only once
[00:00:00 CEST] --- Fri Apr 15 2016