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

[burek]

[00:18:51 CET] <cone-291> ffmpeg 03Paul B Mahol 07master:3e491a1fb613: avfilter/af_sofalizer: print size of FFT that failed to init
[00:18:52 CET] <cone-291> ffmpeg 03Paul B Mahol 07master:21234c835d2d: avfilter/af_sofalizer: fix crash with odd IR size
[00:20:58 CET] <Timothy_Gu> BtbN: thanks
[00:22:15 CET] <Timothy_Gu> durandal_170: should 21234c835d2d be backported?
[00:23:11 CET] <durandal_170> If you care :)
[00:24:58 CET] <Timothy_Gu> ok
[00:30:18 CET] <kierank> J_Darnley: can't see what you've done wrong
[00:30:24 CET] <kierank> perhaps consider writing a haar transform
[00:30:32 CET] <kierank> that's much simpler so might help you figure out what's wrong
[00:36:00 CET] <atomnuker> the bug is definitely not in the coefficient deinterlacing code but during the lifting scheme
[00:36:14 CET] <atomnuker> else there wouldn't be much of an image on the screen
[00:36:45 CET] <atomnuker> I'd try to mess with the C transform to get something which looks like it gives the same artifacts
[00:37:09 CET] <J_Darnley> thanks for looking
[00:37:40 CET] <J_Darnley> i'll try another transform first
[00:37:51 CET] <atomnuker> I'll try to debug the code when I have time during the weekend
[02:21:31 CET] <ethe> I'm trying to make a jack outdev; it uses a lot of the same code as the indev, so I put the common functions in jack.c. One of the functions in jack.c requires a function callback, which are not common, however the function (which is in _enc & _dec) cant be found (when linking), I think it's because of the static. Anyone have an idea of how I can solve this? I dont think making it a public function is
[02:21:33 CET] <ethe> the right solution, but that's just me
[02:38:53 CET] <Timothy_Gu> ethe: can you post a diff
[02:42:50 CET] <ethe> Timothy_Gu: https://gist.github.com/43c21e8c236bf4c7efa2
[02:43:32 CET] <ethe> hmm, I'm not tracking all the files it seems
[02:43:58 CET] <Timothy_Gu> ethe: you know what, just send the files themselves, not a diff
[02:44:17 CET] <Timothy_Gu> the diff is pretty hard to read
[02:47:08 CET] <ethe> Timothy_Gu: https://gist.github.com/9f95c1be16f8b7519014
[02:47:41 CET] <Timothy_Gu> ethe: because those files are static, you can't use them in other files
[02:48:05 CET] <Timothy_Gu> remove `static`, and add a ff_ prefix to the functions
[02:48:31 CET] <ethe> and then I get a duplicate symbol
[02:49:24 CET] <Timothy_Gu> what's duplicated?
[02:54:39 CET] <ethe> ff_process_callback
[02:55:59 CET] <ethe> alternatively I could just have start_jack in both _enc & _dec
[03:00:40 CET] <Timothy_Gu> ethe: no, my comment only applies to functions in jack.c
[03:00:47 CET] <Timothy_Gu> i.e. the shared functions
[03:00:59 CET] <Timothy_Gu> functions in individual files should stay static
[03:03:29 CET] <ethe> if I set them to static, then I get undefined symbol, because jack.c needs the process_callback function from _enc when ff_start_jack is called from _enc, and the same with _dec
[03:13:23 CET] <Timothy_Gu> ethe: ah
[03:14:11 CET] <Timothy_Gu> in that case remove jack_set_process_callback call in jack.c and stick it into the two individual files
[03:14:53 CET] <ethe> >.< why didn't I think of that... thanks
[03:56:43 CET] <Compn> Zeranoe : killing off xp support ?
[03:57:05 CET] <Zeranoe> Compn: Yes
[03:57:08 CET] <Compn> aww ;P
[03:57:54 CET] <Compn> just for dailies :P
[03:57:56 CET] <Compn> but still aww.
[03:58:26 CET] <Zeranoe> Is that your primary OS?
[04:07:30 CET] <Compn> my primary testing box
[04:07:54 CET] <Compn> Uptime: 15wks 3days 12hrs 7mins 47secs
[04:09:22 CET] <Compn> not truely important though
[04:12:31 CET] <Compn> i dont know what the statistics of the users on your site are of course
[04:12:36 CET] <Compn> maybe winxp is in minority :P
[04:12:55 CET] <ashish247> Hi
[04:13:07 CET] <Compn> hopefully it is. hopefully people have upgraded, although calling windows 10 anything positive remains difficult.
[04:13:25 CET] <ashish247> I want to contribute to FFmpeg in gsoc 2016
[04:13:35 CET] <Compn> ashish247 : great! greetings.
[04:13:53 CET] <jamrial> mingw-w64 should switch to defaulting to NT6+ API instead of XP already
[04:13:57 CET] <ashish247> I am interested in project creating fuzzing
[04:14:14 CET] <ashish247> Hey Compn
[04:14:39 CET] <ashish247> Please tell me more about the project
[04:14:49 CET] <Compn> i would but i got yelled at last time :D
[04:14:51 CET] <Compn> ehe
[04:15:30 CET] <Compn> ashish247 : talk to kierank and Timothy_Gu 
[04:15:39 CET] <ashish247> Did you worked for same project last time?
[04:16:02 CET] <Compn> ashish247 : i just mean another student wanted to ask questions about fuzz project , and i gave wrong info :)
[04:16:04 CET] <ashish247> When will be they online?
[04:16:36 CET] <ashish247> Ohhh...you can give me some basic idea
[04:16:53 CET] <Compn> ashish247 : no idea, try by email -- kieran at kunhya dot com  and timothygu99 at gmail.com
[04:17:00 CET] <Compn> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016#CreateafuzzingtestsuiteforFFmpeg
[04:17:05 CET] <Compn> you saw this page ?
[04:17:17 CET] <ashish247> No
[04:17:29 CET] <ashish247> Thanks
[04:17:49 CET] <Compn> ashish247 : ok, try to work on the qualification task there. building fffuzz etc
[04:17:54 CET] <Compn> no problem :)
[04:17:54 CET] <ashish247> So many students are working on same project??
[04:18:04 CET] <Compn> many students apply for the same project
[04:18:25 CET] <Compn> then we have to find those students who actually give some effort and have good communications
[04:18:39 CET] <Compn> e.g. idling on irc 
[04:18:41 CET] <ashish247> And what can I do to  get ahead of them
[04:19:01 CET] <ashish247> Cool
[04:19:03 CET] <Compn> idle on irc, do the qualification task, which means you have to fuzz some parts of ffmpeg and create a patch to fix it
[04:19:30 CET] <ashish247> Do I have enough time left to get selected?
[04:19:43 CET] <ashish247> I kind of started late
[04:19:44 CET] <Compn> https://developers.google.com/open-source/gsoc/timeline
[04:20:18 CET] <Compn> the application starts march 14th, which is in 2 weeks. so you have 2 weeks to fuzz ffmpeg and find a crash and make a patch to fix the patch
[04:20:20 CET] <Compn> plenty of time
[04:20:39 CET] <ashish247> Yup
[04:20:42 CET] <Compn> assuming you know how git and building applications works.
[04:21:12 CET] <Timothy_Gu> ashish247: do you have any specific question about the task
[04:21:34 CET] <ashish247> Yes
[04:22:21 CET] <Timothy_Gu> ashish247: So what is your question?
[04:22:52 CET] <Compn> is our ffmpeg wiki page on the gsoc page ? seems like students are missing our wiki page.
[04:22:55 CET] <ashish247> I know c and git....so am I good enough for project
[04:23:15 CET] <Compn> ashish247 : any experience working on open source projects?
[04:23:28 CET] <sej> ashish247: as Compn said, try to do the qualification task first :)
[04:23:29 CET] <ashish247> Not really
[04:23:36 CET] <Compn> its not a prerequisite , just curious.
[04:23:39 CET] <Timothy_Gu> ashish247: many people know C and Git, and all of them are "good enough" for this task.
[04:23:41 CET] <Compn> yeah , do the qualification task. :)
[04:23:53 CET] <Timothy_Gu> ashish247: And yes, many students have expressed the willingness to do this project
[04:24:04 CET] <ashish247> I will first do the qualification task
[04:24:09 CET] <Compn> Timothy_Gu : do you know if any projects in our list have less students asking ?
[04:24:12 CET] <Timothy_Gu> so we will have to pick one student
[04:24:16 CET] <Timothy_Gu> Compn: everything else :p
[04:24:21 CET] <Compn> oh :D
[04:24:23 CET] <sej> lol
[04:24:39 CET] <Compn> ashish247 : there are less students working on our other project ideas, if you want to choose another.
[04:24:40 CET] <ashish247> Hahaha
[04:25:41 CET] <ashish247> Actually this project got my attention...I haven't looked into other projects
[04:25:42 CET] <Compn> some of the other project ideas are more complicated than a fuzzing system :P
[04:25:55 CET] <Compn> the other ideas on this page i mean, https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016
[04:26:04 CET] <sej> ^true story :P
[04:26:29 CET] <ashish247> Can you suggest me something taking into account that I am a beginner
[04:26:59 CET] <Compn> sej : you seem helpful, are you new? 
[04:27:02 CET] <Compn> :)
[04:27:09 CET] <sej> yup :)
[04:27:38 CET] <Timothy_Gu> ashish247: what subjects are you studying in college?
[04:27:43 CET] <Timothy_Gu> (or major)
[04:28:29 CET] <ashish247> Currently I am studying Operating system, algorithms, theory of compiler
[04:28:32 CET] <Timothy_Gu> We offer a lot more "fun" but also more challenging projects, where you can learn a lot more (that's not to say that the fuzzing project is any less important to us)
[04:29:04 CET] <Timothy_Gu> ashish247: so you have some experiences with algorithms etc. Then I would _really_ recommend looking at some other projects
[04:29:06 CET] <ashish247> I am good at data structure
[04:29:31 CET] <sej> imo your personal interests and projects help you more than ur university courses :P
[04:29:40 CET] <ashish247> Please suggest me some
[04:29:43 CET] <Compn> i think "dicom support" might be fairly easy, as there exists specs and implementations.
[04:29:52 CET] <Compn> well not easy, but ... not extremely difficult
[04:30:52 CET] <ethe> Timothy_Gu: So, none of the write functions are being called for some reason. (ffmpeg -f jack -i "1" -f jack "2") is my cmd. https://gist.github.com/3b68c313ff1a6603d381 "Output file #0 does not contain any stream" is the err. Maybe you could point out an obvious mistake?
[04:31:18 CET] <Compn> self test coverage would also be beginner class.
[04:31:24 CET] <Compn> i think. i could be wrong...
[04:31:41 CET] <Compn> truehd encoder = difficult
[04:31:46 CET] <ashish247> Actually ai was interested in fuzzing one
[04:31:52 CET] <Timothy_Gu> Compn: yes, and therefore somebody has already set their eye on it :)
[04:32:10 CET] <Timothy_Gu> ethe: can you post the log?
[04:32:49 CET] <Timothy_Gu> ethe: also be careful with your editor configuration (the file contains some tabs)
[04:33:00 CET] <Compn> ashish247 : no problem. just trying to help. let us know if you have more questions or comments. how can we help you? :)
[04:33:18 CET] <sej> cehoyos not very active on irc?
[04:33:29 CET] <Timothy_Gu> sej: not always
[04:33:29 CET] <ethe> Timothy_Gu: yeah, I'm gonna fix it all up before submitting. I've been switching between editors. output: https://gist.github.com/66ef4adf168d08f6cab0
[04:33:30 CET] <Compn> once in a while he comes on irc
[04:33:47 CET] <sej> oh okay
[04:33:49 CET] <sej> ty
[04:33:50 CET] <Compn> sej : he is easily reachable by email though
[04:34:17 CET] <sej> okay, thanks
[04:34:27 CET] <Compn> i think i can safely say that all ffmpeg devs are easily reached by email (when they arent on vacation anyways)
[04:34:44 CET] <Compn> current ffmpeg devs*
[04:34:54 CET] <sej> do they 'work' in ffmpeg :O
[04:35:05 CET] <sej> i mean they get paid n shit?
[04:35:10 CET] <sej> pardon my language :P
[04:35:29 CET] <Compn> no, this is volunteer thing. some companies pay devs to work on features once in a while though
[04:35:35 CET] <sej> oh
[04:35:41 CET] <Compn> some devs run companies using ffmpeg
[04:35:52 CET] <sej> ya, have seen that somewhere in the site
[04:35:54 CET] <Compn> working on open source project can get you good jobs! :P
[04:36:31 CET] <sej> :)
[04:37:01 CET] <ethe> and it's fun
[04:37:26 CET] <Timothy_Gu> ethe: can't spot anything obvious...
[04:37:37 CET] <cone-824> ffmpeg 03Mats Peterson 07master:ba40b3520d91: lavf/utils: Normalize AVPacket.data to native endian in ff_get_packet_palette()
[04:37:38 CET] <cone-824> ffmpeg 03Mats Peterson 07master:5111c1bef389: lavf/movenc: Add support for palette side data
[04:37:39 CET] <cone-824> ffmpeg 03Michael Niedermayer 07master:2761e250cc87: fate: add qtrle/mace6 stream copy test
[04:37:45 CET] <ethe> :/
[04:38:01 CET] <Timothy_Gu> I have the feeling that I'm missing something VERY obvious...
[04:38:36 CET] <Timothy_Gu> ah
[04:38:51 CET] <Timothy_Gu> ethe: I think you need a AVOutputFormat.audio_codec
[04:38:51 CET] <ethe> Right. It's 3:40am, I have school in 4 hours. If you do find something please ping me, but I'm going to sleep.
[04:39:07 CET] <ethe> oh. 
[04:39:53 CET] <Timothy_Gu> yeah that's probably it. ffmpeg doesn't know which codec to pick without that
[04:40:54 CET] <sej> who has school at 7 40am :O
[04:40:59 CET] <sej> s a d
[04:41:11 CET] <ethe> sweet. it segfaulted, progress!
[04:41:41 CET] <ethe> sej: that's when I can sleep til, it starts at 8:20
[04:41:57 CET] <Timothy_Gu> ethe: i usually wake up at 5:30
[04:42:03 CET] <sej> hmm
[04:42:05 CET] <ethe> Timothy_Gu: thanks again
[04:42:08 CET] <Timothy_Gu> np
[04:43:26 CET] <sej> Timothy_Gu: not mentoring any other projects?
[04:43:34 CET] <sej> i mean other than fuzzing
[04:43:35 CET] <Timothy_Gu> sej: nah
[04:43:52 CET] <Timothy_Gu> considering I'm younger than the minimum age allowed for a GSoC student one is enough :)
[04:44:20 CET] <sej> haha
[04:44:35 CET] <sej> no min age for mentors eh? xD
[04:45:14 CET] <Timothy_Gu> sej: there is one (13 I believe) 
[04:45:18 CET] <Timothy_Gu> they just decreased it this year
[04:45:25 CET] <Timothy_Gu> last year you had to be 18 to mentor
[04:45:31 CET] <sej> oooh
[04:45:38 CET] <sej> you got lucky ;)
[04:45:47 CET] <Timothy_Gu> yeah I guess
[04:45:48 CET] <sej> rather, the students got lucky ;)
[04:45:59 CET] <Timothy_Gu> I actually really want to do that project myself :)
[04:46:11 CET] <sej> hehe
[05:05:57 CET] <Compn> Timothy_Gu is younger than 13?
[05:06:28 CET] <ashish247> Thanks....Compn n Timothy_Gu
[05:07:31 CET] <ashish247> Actually ....my teacher caught me while texting
[05:07:52 CET] <ashish247> Looking forward to working with u guys
[05:09:37 CET] <Timothy_Gu> Compn: no, that's why I can mentor
[05:10:29 CET] <Timothy_Gu> but I was 13 when I sent my first patch to ffmpeg :)
[05:10:48 CET] <Timothy_Gu> ashish247: good luck!
[07:49:10 CET] <ashish247> Hi
[07:49:41 CET] <ashish247> What is the qualifying task of project Discom Support?
[07:51:17 CET] <sej> mail cehoyos
[07:52:09 CET] <ashish247> Email id?
[07:52:41 CET] <Shiz> on the page
[07:58:47 CET] <ashish247> Can't find it
[08:04:38 CET] <Timothy_Gu> ashish247: > Mentor: Carl Eugen Hoyos (cehoyos in #ffmpeg-devel on Freenode IRC, ce AT hoyos.ws)
[08:04:56 CET] <Timothy_Gu> ce at hoyos.ws
[08:05:31 CET] <ashish247> Thanks buddy
[08:06:10 CET] <ashish247> This project is given last in the list does that mean it have least of getting selected?
[08:06:16 CET] <ashish247> Chance*
[08:10:26 CET] <Timothy_Gu> ashish247: the order makes no difference
[08:10:40 CET] <Timothy_Gu> ashish247: plus we can have many difference projects
[08:11:08 CET] <ashish247> Ok buddy
[08:54:38 CET] <ubitux> PATCH v5 1/4 v3
[08:54:40 CET] <ubitux> lol
[08:54:51 CET] <wm4> wat
[08:55:13 CET] <ubitux> you have him on ignore list?
[08:55:32 CET] <wm4> no I'm just selecting all his posts and click mark as read
[08:55:47 CET] <wm4> but why does he have two version markers there
[08:56:08 CET] <ubitux> semantic versioning!
[09:24:51 CET] <ethe> "but I was 13 when I sent my first patch to ffmpeg :)" pretty impressive
[09:27:03 CET] <sej> indeed
[09:48:23 CET] <mateo`> wm4: i just had a look at the API you proposed, it looks like the mediacodecdec could be a good candidate for it. It would make possible to remove the internal buffer queue of the decoder.
[09:49:42 CET] <mateo`> but when mediacodec returns "[...]_TRY_GAIN", it does not guarantee that it's because you have to send/receive on the other end of the decoder
[09:50:31 CET] <mateo`> and the different timeouts will remain
[09:55:55 CET] <wm4> mateo`: what about the async API? (http://sprunge.us/OBcM)
[09:56:10 CET] <wm4> are these timeouts fundamentally needed?
[10:05:54 CET] <mateo`> I would say yes, not 100% sure though
[10:07:16 CET] <mateo`> I'll experiment, see how it goes if I remove them
[10:07:55 CET] <mateo`> But I've seen (I don't remember where) that for some implementations, it allows the codec to do some processing
[10:09:41 CET] <mateo`> wm4: on the other hand, mediacodec have an async API since Android 5
[10:12:16 CET] <wbs> yes, unless you use the new async mediacodec api, you need to use the timeouts, cleverly
[10:12:31 CET] <wm4> who designed this crap
[10:14:49 CET] <mateo`> wbs: thanks for the confirmation
[10:17:07 CET] <wbs> (i.e. ideally zero timeouts, and once the input doesn't provide any free buffers, a longer blocking timeout wait for the output - and it might be good to still periodically poll the input as well)
[10:19:56 CET] <mateo`> what I have at the moment is, fixed input timeout, no timeout on output until it returns a buffer (so the encoder gets feeded at fast as possible)
[10:20:53 CET] <mateo`> it works quite well that way (at least with sw output)
[10:41:40 CET] <cone-696> ffmpeg 03Paul B Mahol 07master:79a54f30c8ba: avfilter/af_sofalizer: fix crash when ir size is not aligned, usually when n_samples are not power of 2
[10:46:21 CET] <ubitux> durandal_170: http://anime.stackexchange.com/questions/5092/why-are-there-sometimes-darkened-scenes-in-new-anime if you want to write a filter to detect peaks violating the regulation
[10:50:51 CET] <cone-696> ffmpeg 03Agatha Hu 07master:362e05f1ea05: avcodec/nvenc: Fix H264 and HEVC vui info update
[11:02:47 CET] <durandal_170> ubitux: you havent seen deflash filter I posted?
[11:02:59 CET] <ubitux> :o
[11:12:25 CET] <jrosser> https://en.wikipedia.org/wiki/Harding_test
[11:15:30 CET] <kierank> durandal_170: there is a document about what the test needs to hit
[11:15:46 CET] <kierank> jrosser: "other tests are available" :)
[11:15:50 CET] <jrosser> indeed
[11:19:51 CET] <ubitux> https://haneefmubarak.com/2016/02/25/assembly-optimizations-i-un-packing-structures/
[11:27:05 CET] <ubitux> (tl;dr owned by gcc at writing simd)
[11:37:07 CET] <wm4> ubitux: interesting
[11:37:15 CET] <wm4> also lol at icc being slowest
[11:44:24 CET] <durandal_170> kierank: I see no documents
[11:45:08 CET] <kierank> I will find them for you soon
[12:02:15 CET] <kierank> durandal_170: http://stakeholders.ofcom.org.uk/binaries/broadcast/guidance/831193/section2.pdf
[12:02:16 CET] <kierank> annex 1
[12:10:43 CET] <kierank> and email tim nich who might be able to help more
[12:53:04 CET] <happysingh33> hey
[12:53:59 CET] <happysingh33> I am having difficulty in deciding project for GSOC...help me guys
[12:54:15 CET] <happysingh33> I am familiar with c++
[12:55:19 CET] <wm4> choose what is most interesting to you
[13:47:37 CET] <durandal_170> michaelni: what's takes so long to push?
[13:52:39 CET] <cone-696> ffmpeg 03Michael Niedermayer 07master:ae76b8422133: avcodec: Extend fft to size 2^17
[13:55:52 CET] <ismail> I have a very simple patch for enabling schannel on cross mingw-w64 on Linux: http://susepaste.org/view/raw/18997210
[13:55:55 CET] <ismail> can someone apply it?
[13:56:04 CET] <ismail> it only lowercases lib names and header
[13:56:35 CET] <rcombs> ismail: are those names valid with msvc as well?
[13:56:54 CET] <ismail> rcombs: msvc is case-insensitive
[13:57:02 CET] <rcombs> ah
[13:57:15 CET] <rcombs> probably fine then; send to the ML and I'd expect it'll get applied
[13:57:29 CET] <rcombs> (I can't test myself; no easily-accessible windows system)
[13:57:33 CET] <ismail> well didn't want to register for one patch but guess I'll do so
[13:57:55 CET] <rcombs> I don't _think_ you need to subscribe to send a patch
[13:58:17 CET] <ismail> oh
[13:58:21 CET] <rcombs> unsubscribed mails just need to be manually approved, but someone'll do that
[13:58:25 CET] <nevcairiel> tell  mingw to fix their shit then, Secur32 is spelled like that in msvc =p
[13:58:52 CET] <ismail> windows is braindead nothing new there
[13:58:58 CET] <wm4> I thought gcc now has a hack to "fix" include filenames
[13:59:05 CET] <wm4> or did I dream that
[13:59:14 CET] <ismail> wm4: well my gcc 5.3.0 doesn't have such magic :-)
[13:59:17 CET] <nevcairiel> why is it braindead to use an uppercase letter =p
[13:59:18 CET] <ismail> though it does make sense
[13:59:23 CET] <rcombs> last I saw mingw is also missing a define or two
[13:59:32 CET] <rcombs> but maybe that was on pre-mingw-w64
[13:59:47 CET] <ismail> rcombs: indeed, time and time I send fixes for those and wine developers do a lot of work too
[14:06:23 CET] <durandal_170> michaelni: still error with afftfilt, looks like every second sample is 0
[14:25:54 CET] <Daemon404> carl wants to keep the N number
[14:25:58 CET] <Daemon404> shock and awe
[14:27:01 CET] <ismail> wtf is that N- anyway
[14:27:06 CET] <wm4> a random number
[14:27:12 CET] <wm4> which is increased linearly
[14:27:23 CET] <wm4> why are there so many version numbers
[14:27:31 CET] <Daemon404> it's akin to a svn revision. it's the commit count
[14:27:43 CET] <wm4> (release number, the N number, each sub-lib has 2 more...)
[14:27:53 CET] <ismail> ah
[14:28:07 CET] <kierank> N is quite useful, no?
[14:28:11 CET] <Daemon404> to whom and why
[14:28:15 CET] <Daemon404> i have never, ever used it
[14:28:17 CET] <ismail> not to me 
[14:28:18 CET] <ubitux> is there a problem with it?
[14:28:29 CET] <ismail> ffmpeg version N-78868-gecba35b Copyright (c) 2000-2016 the FFmpeg developers
[14:28:38 CET] <ismail> how do I know which ffmpeg version is this
[14:28:42 CET] <Daemon404> [13:28] <@ubitux> is there a problem with it?
[14:28:44 CET] <Daemon404> woops
[14:28:50 CET] <Daemon404> git lgo ecba35b
[14:28:52 CET] <Daemon404> log even
[14:28:55 CET] <ubitux> it actually gives you a hint about how much above from last tag it is
[14:29:03 CET] <ismail> Daemon404: users don't have a git tree
[14:29:16 CET] <ubitux> so when you have snapshot tarballs based on the same tag, you know which one to take
[14:29:27 CET] <ubitux> i actually "use" that feature
[14:29:42 CET] <Daemon404> "how much above" is not really useful
[14:29:47 CET] <Daemon404> in any practical sense
[14:29:58 CET] <ubitux> it helps comparing multiple tarballs
[14:29:58 CET] <wm4> I don't even know how to look up a git commit based on it
[14:30:06 CET] <wm4> maybe one could search for it in gitk
[14:30:06 CET] <Daemon404> wm4, you cant
[14:30:13 CET] <Daemon404> not easily
[14:30:23 CET] <Daemon404> ubitux, why the hell are you using tarballs from git
[14:30:29 CET] <wm4> (it shows the commit "number", so you can do manual binary search by scrolling around)
[14:30:32 CET] <Daemon404> use a release tarball or use got
[14:30:33 CET] <Daemon404> git
[14:30:52 CET] <ubitux> because i need to bump snapshot regularly
[14:31:00 CET] <ubitux> it's like micro releases
[14:31:01 CET] <wm4> the tarballs don't contain the N number?
[14:31:08 CET] <Daemon404> "bump snapshot"?
[14:31:21 CET] <ubitux> wm4: i create them with the git describe
[14:31:33 CET] <ubitux> and i have several tarball, i know which one to take based on that number
[14:31:38 CET] <Daemon404> ITC: https://xkcd.com/1172/
[14:31:50 CET] <ubitux> why do you want to remove it?
[14:32:05 CET] <ubitux> i mean will it solve a problem for you to remove it?
[14:32:08 CET] <Daemon404> it causes more confusion than it helps, IMO
[14:32:12 CET] <Daemon404> for users filing bugs
[14:32:22 CET] <nevcairiel> its not about removing it, its about putting some more meaningful information there
[14:32:36 CET] <ubitux> i'd prefer to keep it, i feel that information is useful
[14:32:41 CET] <nevcairiel> I have no clue how old 78868 really is, it could be from 0.8 for all i know
[14:33:00 CET] <ismail> it would be nice to include major version in there
[14:33:02 CET] <Daemon404> i feel like this is a biproduct of the insane versionign and release management
[14:35:22 CET] <wm4> <ubitux> and i have several tarball, i know which one to take based on that number <- I don't understand the use-case
[14:35:37 CET] <Daemon404> neitehr do i
[14:35:49 CET] <Daemon404> see my xkcd link
[14:35:55 CET] <ubitux> you have several snapshots in a directory
[14:36:02 CET] <ubitux> you wanna find the latest one
[14:36:03 CET] <Daemon404> but *why*
[14:36:10 CET] <Daemon404> how do you end up in such a situation
[14:36:12 CET] <ubitux> because i'm doing micro releases
[14:36:20 CET] <Daemon404> [13:36] <@Daemon404> but *why*
[14:36:38 CET] <nevcairiel> and why wouldnt that be possible if it  says n3.1-dev-422 instead
[14:36:41 CET] <ubitux> because i need a smaller granularity than 3 months
[14:37:05 CET] <ubitux> what's 422?
[14:37:20 CET] <nevcairiel> the number of commits since the tag
[14:37:28 CET] <ubitux> well that's fine then
[14:37:34 CET] <nevcairiel> you know, just like 78868, just with more context
[14:37:47 CET] <ubitux> but aren't you talking about dropping that number?
[14:37:50 CET] <ubitux> i don't get it
[14:37:52 CET] <Daemon404> why tarballs
[14:37:55 CET] <Daemon404> what precludes git
[14:37:59 CET] <Daemon404> and just pinning it to a has
[14:38:00 CET] <Daemon404> h
[14:38:14 CET] <ubitux> i don't understand the question
[14:38:26 CET] <Daemon404> why do you have a giant dir of micro version tarballs for whatever the hell you are doing
[14:38:32 CET] <Daemon404> why do you not use git + hash
[14:39:31 CET] <ubitux> i'm working on the git repository, then sometimes i need a release, so git archive a tarball and name it using git describe, this tarball is then uploaded in a directory, and i can point out to that release
[14:39:47 CET] <Daemon404> it sounds a heck of a lot like a way to just vendor and track specific ffmpeg versions
[14:39:51 CET] <ubitux> sometimes i need to rollback, so i just have to look at the release previously using that number
[14:40:07 CET] <Daemon404> ... or... use a git submodule, which has teh netire history of changes
[14:40:16 CET] <Daemon404> and when you update, and what all previosu versions where
[14:40:22 CET] <Daemon404> i dont know what makes you require tarballs
[14:40:48 CET] <ubitux> git submodule are shit, and the package manager takes tarball as input
[14:41:19 CET] <Daemon404> the former argument is BS when its useful for exactly this usecase
[14:41:24 CET] <Daemon404> and kind of dogmatic
[14:41:32 CET] <Daemon404> the latter sounds like a tooling problem
[14:41:36 CET] <Daemon404> but ill give you that one
[14:41:40 CET] <Daemon404> nobody wants to fix package managers
[14:43:33 CET] <omerjerk> can anyone exaplain the reason of the assert statement in the definiteion of get_bits function ? - https://ffmpeg.org/doxygen/trunk/get__bits_8h-source.html
[14:43:43 CET] <omerjerk> why has n to be smaller than 25 ?
[14:43:56 CET] <omerjerk> *smaller than 26
[14:43:57 CET] <Daemon404> because thats the max number of bits that function supports
[14:44:02 CET] <Daemon404> and it is an internal function
[14:44:14 CET] <Daemon404> there is get_bits_long for larger sizes
[14:44:18 CET] <Daemon404> probably for perf reasons
[14:44:34 CET] <omerjerk> ohkay. thanks. 
[14:45:04 CET] <BBB> omerjerk: the internal variable that holds cached bytes is unsigned int, so 32 bit
[14:45:23 CET] <Daemon404> *at least
[14:45:25 CET] <BBB> omerjerk: and you have an offset within the variable for bit offset, so you can have 0-7 bits already rad in the 32bit variable
[14:45:35 CET] <BBB> so it can hold 32-(0-7) filled bits
[14:45:42 CET] <BBB> which is (worst-case) 32-7=25
[14:45:59 CET] <BBB> omerjerk: ergo, 25
[14:49:19 CET] <omerjerk> ohkay. understood. thanks.
[15:24:28 CET] <durandal_170> michaelni: had time to look at it?
[16:05:41 CET] <ashish247> Hey
[16:06:04 CET] <ashish247> Is ffmpeg available for Ubuntu 14.04?
[16:06:16 CET] <cone-696> ffmpeg 03Michael Niedermayer 07master:305344d89e21: avcodec/fft: Add revtab32 for FFTs with more than 65536 samples
[16:06:17 CET] <cone-696> ffmpeg 03Michael Niedermayer 07master:500cb984710c: avfilter/af_afftfilt: Extend to 17bit fft
[16:11:11 CET] <ethe> ashish247: it's available for nearly all platforms
[16:11:54 CET] <ashish247> ethe: thanks
[16:12:22 CET] <wm4> ashish247: ask such questions on #ffmpeg
[17:14:06 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:93629735d76c: avformat: Add a protocol blacklisting API
[17:15:23 CET] <cone-696> ffmpeg 03Anton Khirnov 07master:ec4c48397641: lavf: add a protocol whitelist/blacklist for file opened internally
[17:15:24 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:063b26d35857: Merge commit 'ec4c48397641dbaf4ae8df36c32aaa5a311a11bf'
[17:17:43 CET] <cone-696> ffmpeg 03Vittorio Giovara 07master:0837d1dfe28f: libx264: Fix noise_reduction option assignment
[17:17:44 CET] <cone-696> ffmpeg 03Michael Niedermayer 07master:f435d081b0a6: h264: Add an AVClass pointer to H264Context
[17:17:45 CET] <cone-696> ffmpeg 03Marton Balint 07master:5e555f93009f: mpeg12enc: always write closed gops for intra only outputs
[17:17:46 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:a38eadd7e93d: Merge commit '5e555f93009f0605db120eec78262d0fe337e645'
[17:18:52 CET] <cone-696> ffmpeg 03Diego Biurrun 07master:9328adcc8012: fate: Be silent when fetching Git updates
[17:18:53 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:18d8398caf91: Merge commit '9328adcc8012a1b0e00c465c85b5453589a4f5f7'
[17:19:13 CET] <atomnuker> Daemon404: libavfilter macro went from 102 back to 100 after the blacklisting API addition
[17:19:26 CET] <atomnuker> *micro version
[17:21:27 CET] <nevcairiel> thats fine, when minor is incremented then micro resets to 100
[17:21:56 CET] <atomnuker> ah, makes sense
[17:22:23 CET] <Daemon404> yes
[17:22:54 CET] <cone-696> ffmpeg 03Diego Biurrun 07master:cd846b479774: fate: Ignore errors from concatenating report files
[17:22:55 CET] <cone-696> ffmpeg 03Diego Biurrun 07master:257b30af8ec5: x86: hevc: Fix linking with both yasm and optimizations disabled
[17:22:56 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:89790ba2bfc9: Merge commit 'cd846b47977485bd4063e77a3324e6b7840567a2'
[17:22:57 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:61c554bd5fee: Merge commit '257b30af8ec520c1635092e429606c62d3bcca63'
[17:23:47 CET] <Daemon404> nevcairiel, next commit is lavc: add codec parameters API
[17:23:58 CET] <Daemon404> it doesnt break, but im unsure where i should merge up to, if at all
[17:24:04 CET] <Daemon404> or where to start the Big Effort branch
[17:24:57 CET] <nevcairiel> pushing the api without everything else ready seems like a waste, so probably start it there
[17:25:08 CET] <Daemon404> i thought as much
[17:25:26 CET] <Daemon404> where shall we coordinate
[17:26:13 CET] <wm4> when you push it and something is fucked, you can't unpush it
[17:26:16 CET] <wm4> so a branch seems better
[17:26:19 CET] <Daemon404> yes
[17:29:48 CET] <nevcairiel> just create a branch on github, merge the 2 api commits in and then the big commit, just commit it with all conflicts in place, and we can then slowly work on fixing those (and all other demuxers they dont have)
[17:30:10 CET] <nevcairiel> thats how we did it last time
[17:30:28 CET] <Daemon404> ok
[17:30:37 CET] <Daemon404> i need a list of people to give access to
[17:30:43 CET] <Daemon404> and their github names
[17:31:00 CET] <nevcairiel> either that or just pull from whomever asks for it =p
[17:31:00 CET] <michaelni> Daemon404, ./libavformat/avformat.h:1874:11: error: duplicate member protocol_blacklist
[17:31:07 CET] <Daemon404> wtf?
[17:31:41 CET] <Daemon404> kill me now
[17:31:45 CET] <Daemon404> what a collosal fuck up
[17:31:55 CET] <Daemon404> i removed the wrong struct memeber when moving it down
[17:32:07 CET] <Daemon404> at least the ABI technicslly didnt break >_>
[17:32:23 CET] <nevcairiel> well ABI i snt broken when you cant build a new B
[17:32:24 CET] <nevcairiel> :D
[17:32:33 CET] <Daemon404> its also the same size
[17:34:01 CET] <cone-696> ffmpeg 03Derek Buitenhuis 07master:fb2f16459894: avformat: Fix member name 10L
[17:34:06 CET] <Daemon404> michaelni, fixed
[17:35:19 CET] <atomnuker> 3 minutes, not bad
[17:35:32 CET] <wm4> 10L? is this about cola?
[17:35:49 CET] <wm4> oh commit message says so
[17:35:53 CET] <wm4> how classic
[17:35:57 CET] <Daemon404> it's an old joke
[17:36:33 CET] <Daemon404> atomnuker, i wanted to avoid carl appearing
[17:36:39 CET] <Daemon404> and harassing me
[17:36:47 CET] <kierank> fuck carl
[17:36:58 CET] <Daemon404> do you have his name on hilight ot something, kierank 
[17:37:02 CET] <Daemon404> on*
[17:37:03 CET] <kierank> no it's a reflex
[17:37:07 CET] <jamrial> lol
[17:37:19 CET] <kierank> see the name and I have to type fuck carl
[17:46:00 CET] <JEEB> wm4 the 10L creeps into you. had to explain it to my coworkers, too
[17:49:23 CET] <Timothy_Gu> "Bonus point if a version of this script is available online as a CGI." is this 2003?
[17:50:35 CET] <thardin> who needs CGI when you can have your visitors run your code for you
[17:51:35 CET] <thardin> by which I mean CGI is a perfectly usable technology
[17:51:39 CET] <Daemon404> https://github.com/dwbuiten/FFmpeg/tree/codecpar
[17:51:41 CET] <Daemon404> who wants to help
[17:52:07 CET] <wm4> that's a nice list of conflicting files
[17:52:15 CET] <Daemon404> hence TEP
[17:52:17 CET] <Daemon404> is the name
[17:52:32 CET] <Daemon404> ill add anyone to the push list on it who wants to help
[17:52:47 CET] <wm4> github almost kills itself on the diff
[17:52:57 CET] <Daemon404> using githubs diff ui is a bad idea
[17:52:59 CET] <Daemon404> for any large commit
[17:53:38 CET] <wm4> so did you automatically rename all AVStream.codec to AVStream.codecpar?
[17:53:44 CET] <Daemon404> i didnt touch anything
[17:53:52 CET] <Daemon404> [16:26] <@Daemon404> yes
[17:53:52 CET] <Daemon404> [16:29] <@nevcairiel> just create a branch on github, merge the 2 api commits in and then the big commit, just commit it with all conflicts in place, and we can then slowly work on fixing those (and all other demuxers they dont have)
[17:53:56 CET] <Daemon404> [16:30] <@nevcairiel> thats how we did it last time
[17:53:58 CET] <wm4> I'm wondering why there are conflicts then
[17:53:59 CET] <Daemon404> i did this
[17:54:12 CET] <wm4> e.g. looking at alsa_dec.c
[17:54:27 CET] <wm4> I must be missing something
[17:54:46 CET] <Daemon404>     st->codec->frame_size = s->frame_size;
[17:54:48 CET] <Daemon404> we had this extra
[17:54:50 CET] <Daemon404> git blew up
[17:54:53 CET] <wm4> oh
[17:55:10 CET] <wm4> so what's there to do? 1. fix trivial conflicts, 2. ...?
[17:55:15 CET] <nevcairiel> my github name is my nick, i'll see what i can do later today
[17:55:27 CET] <Daemon404> wm4, start with fixing all conflicts
[17:55:29 CET] <nevcairiel> wm4: fix all the things
[17:55:34 CET] <Daemon404> and then we can move to fixing stuff they dont have
[17:55:36 CET] <Daemon404> and seeing if it builds
[17:55:37 CET] <Daemon404> lol.
[17:55:57 CET] <Daemon404> added both of you
[17:56:00 CET] <nevcairiel> you can build individual files for testing, at least, but runtime tests are hard unless you configure  carefully
[17:56:08 CET] <Daemon404> true
[17:56:19 CET] <nevcairiel> anyhow dinner time
[17:56:31 CET] <Daemon404> ubitux / atomnuker / kierank / jamrial - anyone?
[17:56:35 CET] <Daemon404> michaelni too
[17:57:01 CET] <jamrial> i'll take a look. i'll have to adapt the few de/muxers i wrote anyway
[17:57:12 CET] <Daemon404> github nick?
[17:57:13 CET] <wm4> how do you partition the work?
[17:57:19 CET] <jamrial> same as my nick
[17:57:22 CET] Action: ubitux mixed up lines and though Daemon404 was inviting him to dinner
[17:57:32 CET] <Daemon404> ubitux, sure just head over to britain
[17:58:12 CET] <ubitux> anyway alright i'll help
[17:58:25 CET] <Daemon404> added 
[17:58:26 CET] <ubitux> who handles what?
[17:58:32 CET] <wm4> ubitux: that's the question
[17:58:42 CET] <jamrial> instead of giving access, wouldn't it be better to just accept pull requests?
[17:58:51 CET] <Daemon404> jamrial, thats a ton of work for one person
[17:58:58 CET] <jamrial> fair enough
[17:59:03 CET] <Daemon404> for now, we could just copy/paste the conflicts to an etherpad and just remove them as we push fixes
[17:59:33 CET] <Daemon404> unless someone has a better idea
[17:59:45 CET] <Daemon404> im open to anything.
[17:59:51 CET] <wm4> so if someone wants to fix it -> add to etherpad, when done fixing -> add (fixed) to it
[17:59:59 CET] <Daemon404> nah
[18:00:03 CET] <Daemon404> start with a giant list
[18:00:06 CET] <Daemon404> and just remove it
[18:00:11 CET] <Daemon404> once fixed
[18:00:35 CET] <wm4> "reserving" files seems like a good idea to avoid double work
[18:00:37 CET] <Daemon404> or mark it as WIP or something
[18:00:44 CET] <Daemon404> right
[18:00:52 CET] <Daemon404> its multiplayer pastebin, nothing specia
[18:01:10 CET] <michaelni> also maybe post a patch so others can take a look test / before its pushed if its a really large change
[18:01:29 CET] <Daemon404> michaelni, we can send PRs maybe for large changes?
[18:01:29 CET] <wm4> how do you post a merge commit as patch
[18:01:39 CET] <Daemon404> wm4, there's no merge to be done
[18:01:46 CET] <Daemon404> michaelni, oh you mean the whole thing
[18:01:49 CET] <Daemon404> ok
[18:02:03 CET] <Daemon404> wm4, merge the commit with -s ours, and commit it as a separate commit
[18:02:08 CET] <wm4> Daemon404: it's fixing a merge so in theory it should be squashed
[18:02:26 CET] <wm4> ok
[18:02:39 CET] <ubitux> you merged the 2 commits?
[18:02:43 CET] <ubitux> can't be done one at a time?
[18:02:50 CET] <Daemon404> ubitux, ?
[18:03:03 CET] <Daemon404> i merged the two api additions separately, and cleanly
[18:03:07 CET] <Daemon404> theyre before the big broken one
[18:03:16 CET] <ubitux> oh ok right sorry
[18:03:16 CET] <atomnuker> Daemon404: I'll help
[18:03:32 CET] <Daemon404> added 
[18:03:41 CET] <atomnuker> so AVCodecParameters only affects libavformat?
[18:03:52 CET] <Daemon404> theres conflics in avdevice and stuf too
[18:03:57 CET] <atomnuker> is it going to replace AVCodecContext
[18:04:07 CET] <Daemon404> in lavf
[18:04:11 CET] <Daemon404> yea
[18:04:14 CET] <Daemon404> i think.
[18:04:26 CET] <atomnuker> also, I see libavdevice/pulse was added, didn't we already have a pulseaudio backend?
[18:04:37 CET] <Daemon404> oh
[18:04:39 CET] <Daemon404> the file can be rm'd
[18:04:43 CET] <Daemon404> that was git being dumb
[18:04:48 CET] <Daemon404> because the file didnt exist in our tree
[18:05:23 CET] <atomnuker> libavdevice/pulse_audio_enc.c libavdevice/pulse_audio_dec.c
[18:05:29 CET] <Daemon404> done
[18:05:36 CET] <wm4> the idea of codecpar is that the AVStream.codec field goes away
[18:05:52 CET] <atomnuker> the new libavdevice/pulse.c uses the pulseaudio simple API
[18:05:58 CET] <wm4> so demuxers should set AVStream.codecpar
[18:06:13 CET] <Daemon404> anyway... enjoy, boys and girls
[18:06:17 CET] <Daemon404> ill start hacking after dinner
[18:06:22 CET] <wm4> Daemon404: where's that etherpad
[18:06:22 CET] <Daemon404> i have work-work to do, then dinner, first
[18:06:29 CET] <Daemon404> wm4, i need to figue it out
[18:06:30 CET] <Daemon404> 1 sec
[18:06:30 CET] <atomnuker> ours uses the real API
[18:07:02 CET] <Daemon404> atomnuker, yes i removed the file in the branch just now
[18:07:08 CET] <Daemon404> it wasnt supposed to be there
[18:07:57 CET] <wm4> atomnuker: it's just the old version from Libav
[18:08:09 CET] <atomnuker> yeah, I know
[18:09:54 CET] <Daemon404> https://public.etherpad-mozilla.org/p/ffmpeg-tep2-merge
[18:11:02 CET] <Daemon404> anyway... ill start in a few hrs
[18:11:08 CET] <Daemon404> i dont expect this will be done quickly
[18:12:00 CET] <wm4> and we can push to your repo? (what magic is that)
[18:12:05 CET] <Daemon404> wm4, yes
[18:12:11 CET] <Daemon404> i added you all as collaborators on the repo
[18:14:24 CET] <ubitux> so we can all commit very small "wip" commits?
[18:14:36 CET] <Daemon404> yes
[18:14:47 CET] <Daemon404> itll all be squashed in the ned
[18:14:48 CET] <Daemon404> end
[18:15:01 CET] <wm4> jamrial: did you remove my "wip"?
[18:15:08 CET] <jamrial> no
[18:15:19 CET] <wm4> I thought I added this to srtdec.c
[18:15:32 CET] <jamrial> i see it
[18:15:35 CET] <jamrial> but not from your color
[18:15:42 CET] <Daemon404> i see a wip
[18:15:42 CET] <ubitux> wm4: i did, and put it back
[18:15:47 CET] <ubitux> sorry
[18:15:59 CET] <wm4> jamrial: I see it in red, and you're red in the user list
[18:16:05 CET] <Daemon404> gmm
[18:16:06 CET] <wm4> but I don't see ubitux or another red user
[18:16:10 CET] <jamrial> no, i'm a darker red
[18:16:12 CET] <jamrial> check the ogg stuff
[18:16:19 CET] <wm4> well there are two jamrials there
[18:16:28 CET] <ubitux> i think jamrial filled my nickname
[18:16:30 CET] <ubitux> :D
[18:16:44 CET] <ubitux> is this better?
[18:17:38 CET] <wm4> "not unitux"
[18:17:41 CET] <wm4> ok
[18:17:59 CET] <ubitux> wat
[18:18:11 CET] <wm4> is what I see in the userlist
[18:18:22 CET] <ubitux> there is no ubitux?
[18:18:30 CET] <wm4> no
[18:18:35 CET] <jamrial> oh wow
[18:18:35 CET] <wm4> yes
[18:18:36 CET] <ubitux> in blue?
[18:18:36 CET] <jamrial> lol
[18:18:39 CET] <jamrial> yes i did
[18:18:40 CET] <wm4> I had to scroll
[18:18:46 CET] <jamrial> sorry :p
[18:18:58 CET] <wm4> but there's still a "not unitux"
[18:19:11 CET] <ubitux> yeah
[18:19:21 CET] <jamrial> i see ubitux, blue
[18:20:45 CET] <ubitux> wm4: you can fix the "wip" for srtdec :)
[18:21:33 CET] <wm4> hm picked swfdec.c and I'm already lost
[18:21:38 CET] <jamrial> there's no pix_fmt parameter in AVCodecParameters
[18:22:01 CET] <jamrial> and oggparsedirac.c uses codec->pix_fmt
[18:22:35 CET] <Daemon404> for what
[18:22:45 CET] <wm4> I'd say add such a field for now, we can decide later if it's really needed
[18:23:02 CET] <Daemon404> i dont know if its so valid to have a codec pix_fmt
[18:23:59 CET] <wm4> in theory there's nothing against it
[18:24:42 CET] <Daemon404> afaict that file sets it and nothing uses it
[18:24:50 CET] <Daemon404> dirac.c seems not to
[18:25:34 CET] <jamrial> nevermind,  AVCodecParameters calls it format
[18:26:01 CET] <wm4> ubitux: unrelated to the merge, but this fails to probe (vplayer subs) http://sprunge.us/hjUU
[18:26:02 CET] <Daemon404> ah
[18:26:30 CET] <Daemon404> even when ubitux isnt doing subtitles, he is doing subtitles
[18:27:22 CET] <ubitux> wm4: ah, no '.', ok, will try to fix
[18:27:47 CET] <ubitux> i'm still waiting for the promised 30GB db of subtitles from opensubtitles
[18:27:54 CET] <ubitux> to "fuzz" ffmpeg
[18:28:01 CET] <wm4> heh
[18:28:08 CET] <wm4> 30gb, wtf
[18:28:17 CET] <ubitux> apparently
[18:28:19 CET] <ubitux> :D
[18:28:23 CET] <ubitux> and only text!
[18:30:09 CET] <ubitux> wm4: http://sprunge.us/AeFL
[18:30:15 CET] <ubitux> untested, but might work
[18:30:21 CET] <ubitux> need to check if it doesn't break some other
[18:30:47 CET] <ubitux> actually, maybe not
[18:30:54 CET] <ubitux> well, i'll test properly when i'm back home
[18:39:55 CET] <wm4> dear god, utils.c looks like a mess
[18:40:09 CET] <jamrial> just fixed one thing from that file
[18:40:21 CET] <jamrial> since it's needed to get several other files working
[18:40:35 CET] <wm4> please mark such changes and push, or it's going to turn into a mess
[18:40:42 CET] <jamrial> i pushed it, yes
[18:40:45 CET] <wm4> I'm not testing anything yet
[18:41:07 CET] <wm4> just that fixed source files actually compile
[18:42:32 CET] <Daemon404> you cant really test until they all do
[18:42:56 CET] <nevcairiel> could try partial compiles, but that needs careful thinking
[18:43:04 CET] <ubitux> the non conflicting files also need adjustment, right?
[18:43:12 CET] <nevcairiel> some might
[18:43:25 CET] <nevcairiel> easy to verify, there should be virtually no st->codec access anymore after
[18:43:29 CET] <wm4> yeah, they'll throw deprecation warnings or fail to compile
[18:43:30 CET] <nevcairiel> outside of utils.c 
[18:43:51 CET] <wm4> what's a good RE to catch ->codec but not ->codecpar
[18:44:04 CET] <nevcairiel> ->codec->?
[18:44:04 CET] <wm4> hm should be simple enough
[18:44:09 CET] <wm4> or that
[18:45:24 CET] <Daemon404> wm4, that wont fix the merge conflict crap though
[18:45:30 CET] <Daemon404> <<<<<<<
[18:46:30 CET] <nevcairiel> yeah its probably better to fix those first
[18:47:41 CET] <nevcairiel> i already see the removal of frame_size breaking all sorts of things
[18:48:34 CET] <wm4> yeah
[18:48:59 CET] <nevcairiel> maybe we should just add it to codecparams before we start removing it in all sorts of places
[18:49:09 CET] <jamrial> av_parser_parse2 takes AVCodecContext as parameter. oggparseflac uses it
[18:49:27 CET] <jamrial> doesn't happen in libav. not sure how to deal with this
[18:49:40 CET] <wm4> worst case, create a dummy avctx
[18:50:37 CET] <jamrial> how?
[18:50:39 CET] <nevcairiel> what specifically is it meant to lookup, we have a variety of flac header parsing functions
[18:52:12 CET] <nevcairiel> the only thing it apparently extracts is the sample rate
[18:53:22 CET] <nevcairiel> worst case, build some basic manual parsing like the flac_header function in the same file
[18:54:17 CET] <jamrial> any sample using this "old" header around?
[18:55:02 CET] <nevcairiel> its unfortunately not covered by fate
[18:56:07 CET] <nevcairiel> jamrial: according to the commit it introduced, http://samples.mplayerhq.hu/flac/Yesterday.ogg
[18:56:42 CET] <jamrial> ok, thanks
[18:56:47 CET] <nevcairiel> also trac 1617
[18:57:05 CET] <nevcairiel> https://trac.ffmpeg.org/ticket/1617
[18:57:08 CET] <nevcairiel> has another sample
[18:57:24 CET] <wm4> something here checks strict_std_compliance
[18:57:30 CET] <wm4> it was avctx and is now codecpar
[18:57:42 CET] <nevcairiel> demuxers that check codec compliance are mad
[18:57:50 CET] <wm4> happens a bunch of times
[18:57:51 CET] <nevcairiel> dont we have such a field on the formatcontext as well
[18:57:54 CET] <jamrial> in any case, maybe we'll have to add a av_parser_parse3() that takes a codecpar instead at some point
[18:57:58 CET] <wm4> also it's in muxer code
[18:58:13 CET] <nevcairiel> jamrial: i believe they want to revamp parsers as well
[18:58:23 CET] <Daemon404> theres a patchset posted
[18:58:27 CET] <wm4> oh avformatcontext also has this field
[18:58:33 CET] <nevcairiel> Daemon404: thats for bsf isnt it
[18:58:36 CET] <Daemon404> oh, right
[18:58:40 CET] <Daemon404> i always get the two mixed up
[18:59:52 CET] <wm4> more frame_size, derp
[19:06:00 CET] <nevcairiel> why did asfdec_o conflict, we dont usually modify that
[19:12:00 CET] <jamrial> seek_preroll is in avcodeccontext but not avcodecparameters, and one is supposed to use av_codec_{set,get}_seek_preroll to access it
[19:12:19 CET] <wm4> the accessors are probably Libav ABI compar nonsense
[19:12:27 CET] <wm4> seek preroll should probably be in codecpar
[19:13:20 CET] <jamrial> so we move it and deprecate the accessor functions?
[19:13:30 CET] <wm4> yeah
[19:14:33 CET] <nevcairiel> yeah seems to fit into the audio padding section in codecpar
[19:14:44 CET] <nevcairiel> its kinda like initial padding, but different
[19:15:30 CET] <wm4> rawdec.c wants a framerate and time_base field
[19:15:34 CET] <wm4> (wat)
[19:16:20 CET] <wm4> Libav removed this mechanism at some point
[19:16:26 CET] <nevcairiel> somehow i remember at least one of those ending up in codecpar, but i see neither
[19:16:27 CET] <nevcairiel> or blind
[19:16:49 CET] <wm4> this fuckign code was refactored at leats 10 times
[19:16:55 CET] <wm4> rawdec.c I mean
[19:17:45 CET] <wm4> oh I see they just are in AVStream
[19:22:26 CET] <wm4> st->codecpar->sample_rate = av_q2d(thp->fps);
[19:22:28 CET] <wm4> seriously?
[19:24:31 CET] <durandal_170> libav code?
[19:24:40 CET] <wm4> yes
[19:25:09 CET] <mateo`> I haven't followed the API changes, does codecpar stands for codec parameters ?
[19:25:15 CET] <wm4> yes
[19:25:24 CET] <wm4> it fucks up literally everything
[19:26:34 CET] <nevcairiel> ff_get_extradata sure is a nice utility function, all those tripple error checks in every demuxer it just replaces
[19:34:59 CET] <wm4> why are there even fate changes
[19:35:30 CET] <nevcairiel> apparently handling of some time stamps changed, like duration of the last frame or some shit
[19:35:56 CET] <jamrial> so, avcodeccontext->delay
[19:36:23 CET] <ethe> what's a frame vs a packet vs a sample in terms of audio? and is the input data for an output device interleaved?
[19:36:24 CET] <jamrial> it's also on libav but not moved to codecpar. we use it for opus on ogg and matroska but they don't
[19:36:27 CET] <nevcairiel> usage of that field has always been super inconsistent
[19:36:43 CET] <nevcairiel> isnt that initial_padding
[19:37:33 CET] <wm4> seems so...
[19:37:36 CET] <jamrial> oggparseopus sets it with the "pre_skip" from the opus ogg header
[19:37:50 CET] <nevcairiel> sounds like initial padding
[19:38:00 CET] <Daemon404> i would suggest checking libav-devel archives if something is confusing
[19:38:12 CET] <Daemon404> for the smaller version of whatever bit is confusing
[19:38:42 CET] <nevcairiel> A 'pre-skip' field in the ID header signals the number of samples which should be skipped at the beginning of the stream.
[19:38:50 CET] <nevcairiel> from OggOpus "spec"
[19:39:00 CET] <nevcairiel> so yes, move that into initial_padding
[19:39:16 CET] <nevcairiel> maybe we'll manage to make this delay mess a bit cleaner in the process
[19:41:44 CET] <wm4> wouldn't count on it
[19:41:56 CET] <wm4> we also have a side data to skip samples
[19:41:58 CET] <wm4> which does the same
[19:42:28 CET] <nevcairiel> so ... avpriv_bprint_to_extradata takes an avctx, and its used from both avcodec and avformat
[19:42:49 CET] <nevcairiel> should take the chance and get rid of its avpriv'ness and introduce a new avcodecpar version in avformat or something =p
[19:42:54 CET] Action: wm4 wonders why sample_aspect_ratio is a AVStream field
[19:43:09 CET] <wm4> nevcairiel: sounds good
[19:43:12 CET] <nevcairiel> wm4: because streams and codecs can signal different aspect ratios
[19:43:31 CET] <nevcairiel> so let the user decide which to use
[19:44:09 CET] <wm4> makes sense, but there are MANY such ambiguities
[19:44:17 CET] <wm4> matroska is just adding a whole new load of them
[19:50:08 CET] <wm4> ubitux: user says the subtitle patch works
[19:50:44 CET] <ubitux> huh
[19:50:47 CET] <ubitux> it shouldn't but ok
[19:51:53 CET] <nevcairiel> this stupid etherpad keeps forgetting some names and colors
[19:53:20 CET] <wm4> when users log out?
[19:53:41 CET] <wm4> ah, your color changed
[19:53:42 CET] <wm4> fun
[19:54:45 CET] <nevcairiel> i changed mine manually now
[19:57:17 CET] <wm4> did anyone add seek_preroll yet?
[19:58:22 CET] <nevcairiel> jamrial had that one, didnt he
[19:58:34 CET] <jamrial> yeah, added it and pushed
[19:58:54 CET] <jamrial> we should guard the old one and the functions inside some FF_API check
[19:59:17 CET] <nevcairiel> make a note =p
[19:59:39 CET] <nevcairiel> i also need to un-avpriv one function, but since avpriv is practically public ABI, need to do the dance etc
[20:00:58 CET] <ubitux> time_base.. :(
[20:01:14 CET] <wm4> what for?
[20:02:15 CET] <ubitux> finding a matching dv profile
[20:02:46 CET] <ubitux> it seems there is one in another place though
[20:02:46 CET] <wm4> sounds messed up; maybe export pseudo profile values
[20:02:49 CET] <ubitux> i might use that
[20:03:48 CET] <ubitux> we should flag the one which weren't straightforward to merge
[20:04:00 CET] <ubitux> to make final review more targetted
[20:05:38 CET] <wm4> I tend to add odd things to the commit message, but not sure if they don't just get lost
[20:06:43 CET] <ubitux> ah, right
[20:10:26 CET] <ubitux> btw, any nasty type change of some sort in the codecpar struct?
[20:10:40 CET] <ubitux> like, int to int64 or stuff like that which could create bugs©
[20:12:37 CET] <wm4> why would int->int64 create bugs?
[20:12:48 CET] <ubitux> the other way around maybe
[20:13:18 CET] <ubitux> no one is adjusting av_parser_parse2()?
[20:13:29 CET] <nevcairiel> it shouldnt be
[20:13:44 CET] <ubitux> ah, we cant it's public
[20:13:46 CET] <ubitux> meh
[20:21:03 CET] <ubitux> durandal_170: 7b007a7c1fad57e9ed4b685c1d3b4222f02d9720
[20:21:07 CET] <ubitux> will this still be relevant?
[20:21:40 CET] <durandal_170> what's it?
[20:22:04 CET] <ubitux> one of your commit
[20:22:21 CET] <ubitux> removing "ast->codec->sample_fmt = AV_SAMPLE_FMT_U8" from lavf/flic.c
[20:22:22 CET] <durandal_170> Im on phone
[20:22:29 CET] <ubitux> since "It is supposed to be set from lavc only"
[20:23:08 CET] <durandal_170> is it set from decoder?
[20:23:25 CET] <ubitux> maybe
[20:23:38 CET] <ubitux> depends how we merge on lavc side
[20:23:41 CET] <ubitux> it's about lavf right now
[20:23:46 CET] <ubitux> anyway, i'm flagging the commit
[20:24:25 CET] <Daemon404> damn, you guys have been busy while i ate
[20:25:28 CET] <wm4> hm is one commit per file somehow preferable?
[20:25:55 CET] <nevcairiel> its just how i work
[20:25:59 CET] <nevcairiel> find your own way :D
[20:26:21 CET] <wm4> these are get squashed anyway, so why bother
[20:30:27 CET] <durandal_170> ubitux: I don't see it in ffmpeg repo
[20:32:23 CET] <Fyr> FFMPEG AAC adds 1024 frames at the beginning of the file.
[20:32:35 CET] <ubitux> durandal_170: you'll check later
[20:32:46 CET] <Fyr> a few conversions can shift the timeline unexpectedly.
[20:32:46 CET] <ubitux> no hurry
[20:33:22 CET] <JEEB> Fyr: all AAC encoders have encoder delay
[20:33:32 CET] <jamrial> avcodecparameters doesn't have an avclass
[20:33:32 CET] <JEEB> you use a container like ISOBMFF to code that delay in
[20:33:33 CET] <Fyr> JEEB, no
[20:33:39 CET] <JEEB> yes, they do
[20:33:39 CET] <jamrial> that means av_log can't be used with it, right?
[20:33:48 CET] <Fyr> libfdkaac_enc doesn't give that delay.
[20:33:50 CET] <wm4> jamrial: correct
[20:33:59 CET] <Fyr> ffmpeg's aac does.
[20:34:54 CET] <Fyr> I converted it ten times and found 0.5 s delay of FFMPEG AAC and 0 ms of that of Fraunhofer.
[20:35:01 CET] <JEEB> you are going into incorrect conclusions
[20:35:08 CET] <JEEB> also how exactly do you test
[20:35:11 CET] <Fyr> 0.5 s matters
[20:35:20 CET] <JEEB> of course it does
[20:36:03 CET] <JEEB> anyways, just note how you're testing and I can possibly inform you of various funky things related to this stuff :P
[20:36:14 CET] <Fyr> JEEB, http://pastebin.com/k16XA7us
[20:36:26 CET] <Fyr> that will give you 0.5 s of delay.
[20:36:47 CET] <Fyr> if you compare input.wav and 10 wav.
[20:36:49 CET] <JEEB> ok, first of all ffmpeg cli handles encoder delay in a weird way when you output to a container that doesn't support it
[20:37:01 CET] <JEEB> or well, doesn't support negative timestamps
[20:37:12 CET] <JEEB> it automagically moves the first timestamp to zero :P
[20:37:21 CET] <JEEB> also how are you testing fdk-aac, are you decoding with it per chance?
[20:37:44 CET] <Fyr> I encode it according the scheme I've just posted.
[20:37:51 CET] <JEEB> yes, but how are you decoding
[20:37:54 CET] <JEEB> are you using its decoder?
[20:37:58 CET] <JEEB> or the ffaac decoder?
[20:38:02 CET] <Fyr> it doesn't matter where the problem occur, it must be fixed.
[20:38:35 CET] <Fyr> JEEB, I don't use any decoder, I compare input.wav and 10.wav.
[20:38:52 CET] <JEEB> I mean, when you decode the AAC to wav
[20:39:02 CET] <JEEB> can you see which decoder you're using?
[20:39:07 CET] <Fyr> ffmpeg -i 10.m4a 10.wav
[20:39:24 CET] <Fyr> FFMPEG AAC decoder, methink.
[20:39:29 CET] <JEEB> yeah, and the decoder used can be different depending on your configuration (although most probably it is the ffaac one)
[20:39:36 CET] <JEEB> which is why I ask to make sure
[20:40:00 CET] <wm4> lol sdp.c _actually_ wants to access the encoder
[20:41:39 CET] <JEEB> anyways, let's start with this fact: all AAC encoders have encoder delay and that's just a thing of the audio format. no matter how much you say NONONO, that is a fact (esp. with those parameters). Second of all, encoder delay is marked into that container you're using as far as I can tell (if your FFmpeg is new enough), so when decoding the first packet(s) that contain the encoder delay should have a n
[20:41:45 CET] <JEEB> egative timestamp accordingly (so you can cut the unneeded bits off)
[20:41:50 CET] <JEEB> now, ffmpeg *cli* tries to be clever
[20:42:06 CET] <michaelni> thresh just applied my patch to make diffs show up in merges, should i/someone push some dummy merge of a trivial commit to test it?
[20:42:17 CET] <michaelni> that is merges on cvslog ML
[20:42:18 CET] <JEEB> which is very confusing, but it puts the negative-starting packet at zero when the input doesn't start at zero
[20:42:32 CET] <JEEB> when your output format doesn't support <0 timestamps (such as WAV)
[20:42:52 CET] <Fyr> JEEB, Stream #0:0 -> #0:0 (aac (native) -> pcm_s16le (native))
[20:43:05 CET] <JEEB> ok, thanks for confirming
[20:43:05 CET] <Fyr> i.e. FFMPEG's AAC decoder.
[20:43:34 CET] <JEEB> the reason why you're not getting the delay with fdk-aac most probably is due to some special case in the decoder (I remember faac having one, too so I wouldn't be surprised :P)
[20:43:47 CET] <JEEB> that said I didn't get to check the code yet
[20:44:44 CET] <JEEB> Fyr: when you ffprobe or ffmpeg -i file.mp4|m4a it should show that the audio track doesn't start at zero
[20:44:50 CET] <JEEB> if not, something's wrong
[20:45:41 CET] <Fyr> JEEB, Duration: 00:00:09.50, start: 0.000000, bitrate: 130 kb/s
[20:45:48 CET] <JEEB> ok, that is bugged
[20:45:53 CET] <Fyr> something is wrong
[20:46:01 CET] <JEEB> what version are you on?
[20:46:10 CET] <Fyr> ffmpeg version N-53341-gbd9c587-static
[20:46:20 CET] <Fyr> built with gcc 5.3.1 (Debian 5.3.1-10) 20160224
[20:46:43 CET] <JEEB> did you build it by yourself?
[20:47:18 CET] <Fyr> ffmpeg version N-53341-gbd9c587-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
[20:47:26 CET] <JEEB> ok, so most probably not
[20:48:04 CET] <nevcairiel> hm, avidec uses avpriv_exif_decode_ifd which takes an AVCodecContext, but this codeccontext is only used for logging, nothing else
[20:48:06 CET] <nevcairiel> how annoying
[20:48:55 CET] <wm4> wow seems like 50% or so is already fixed
[20:49:20 CET] <JEEB> Fyr: I have an older version on hand atm and I just did "ffmpeg -i file -c:a aac -b:a 192k delay_test.m4a"
[20:49:29 CET] <JEEB> Duration: 00:03:42.17, start: 0.023220, bitrate: 196 kb/s
[20:49:30 CET] <jamrial> ubitux: bit_rate
[20:49:36 CET] <jamrial> it's int in codecpar
[20:49:42 CET] <jamrial> should be int64_t
[20:49:59 CET] <nevcairiel> we should probably change that again then
[20:50:06 CET] <ubitux> ah! right ok
[20:50:12 CET] <ubitux> dammit dv
[20:50:13 CET] <jamrial> yeah
[20:50:13 CET] <JEEB> Fyr: make sure you're not remuxing because more often than not that is gonna blow your encoder delay info to smithereens
[20:50:41 CET] <ubitux> c->vst->codec->time_base, c->vst->time_base, c->sys->time_base, ...
[20:50:45 CET] <ubitux> which am i supposed to use
[20:50:47 CET] <ubitux> :(
[20:50:50 CET] <JEEB> but yeah, the encoder delay is marked there in that container, and yes, wav output is "borked" as it outputs all the packets
[20:51:02 CET] <JEEB> Fyr: feel free to make a bug report if you care about the WAV output
[20:51:27 CET] <wm4> ubitux: never the codec one
[20:51:34 CET] <JEEB> I think I once went through this with a foobar2000 dev, he similarly took some convincing that the API actually did the right thing
[20:51:45 CET] <ubitux> wm4: yeh, i have to replace the use of c->vst->codec->time_base
[20:51:50 CET] <ubitux> but with which...
[20:51:53 CET] <JEEB> while testing with something like the WAV output seemingly did the wrong thing :P
[20:52:00 CET] <wm4> well it sets it at one point, right
[20:52:12 CET] <wm4> the user-visible timebase is in AVStream
[20:52:34 CET] <wm4> it probably got moved there with the codecpar change, dunno
[20:52:40 CET] <ubitux> there is also c->dv_demux->sys->time_base
[20:53:05 CET] <JEEB> Fyr: and if you are not getting the encoder delay written, you'll have to build basic FFmpeg itself first and then test with it. if it still fails, that's worth a bug report
[20:54:25 CET] <jamrial> i'm wondering if we should really deprecate seek_preroll. none of the other codecpar fields were deprecated from avctx
[20:55:24 CET] <wm4> jamrial: right, the user still wants to access AVCodecContext fields in the actual decoder
[20:57:42 CET] <jamrial> ok, undoing deprecation
[20:58:58 CET] <wm4> if (avcodec_is_open(st->codec)) {
[20:59:02 CET] <wm4> in the mpegts demuxer
[20:59:03 CET] <wm4> wtf
[20:59:12 CET] <JEEB> funky
[20:59:20 CET] <wm4> is this a NOP now?
[20:59:25 CET] <wm4> or can something still open it
[21:03:48 CET] <wm4> assuming NOP
[21:03:54 CET] <wm4> isom.c has another one
[21:05:53 CET] <wm4> isom also wants to set rc_max_rate
[21:07:06 CET] <Daemon404> btu why
[21:07:07 CET] <Daemon404> but*
[21:07:12 CET] <wm4> dunno
[21:07:18 CET] <wm4> libav skips and discards it
[21:07:18 CET] <Daemon404> git blame?
[21:07:32 CET] <Daemon404> i thought rc_max_rate was for encoding
[21:07:33 CET] <JEEB> probably so it can be re-used in remuxing or whatever?
[21:07:34 CET] <wm4> 4547cf68a0d28c01549f84567e4d39a8b40230e7
[21:07:39 CET] <JEEB> nfi tho
[21:07:46 CET] <wm4> some bitrate guessing bullshit
[21:07:55 CET] <Daemon404> that commit explains nothing
[21:07:56 CET] <wm4> "Fixes Ticket4546"
[21:08:22 CET] <wm4> what's ganesh's github handle?
[21:08:29 CET] <nevcairiel> for copy copy, apparently
[21:08:32 CET] <nevcairiel> (what else)
[21:08:42 CET] <nevcairiel> codec copy*
[21:08:46 CET] <JEEB> yeah
[21:09:01 CET] <nevcairiel> dont we have side data for cbp stats now
[21:09:01 CET] <Daemon404> wm4, https://github.com/gajjanag
[21:09:04 CET] <nevcairiel> wonder if those would work there
[21:09:21 CET] <wm4> will use @gajjanag
[21:10:08 CET] <Daemon404> st->codec->bit_rate = avio_rb32(pb); /* avg bitrate */
[21:10:10 CET] <Daemon404> this looks iffy btw
[21:10:16 CET] <Daemon404> for corrupt files
[21:10:23 CET] <wm4> yeah, but at least this field doesn't go away
[21:10:26 CET] <wm4> so not my problem lol
[21:12:57 CET] <Daemon404> of course i am sitting here fixing subtitles for work on the day TEP2 starts
[21:13:07 CET] Action: Daemon404 blames ubitux, who put a jinx on him
[21:13:11 CET] <JEEB> :D
[21:13:21 CET] <ubitux> :D
[21:13:25 CET] <nevcairiel> screw work =p
[21:13:37 CET] <ubitux> Daemon404: hey i simplified it!
[21:14:05 CET] <Daemon404> ubitux, this is unrelated to ffmpeg
[21:14:17 CET] <ubitux> oh, ok
[21:14:19 CET] <Daemon404> but its still a crapshoot
[21:14:34 CET] <Daemon404> the ways programs manage to output mangled subtitles are astounding
[21:14:40 CET] <Daemon404> especially character encoding
[21:14:51 CET] <Zeranoe> Just ran into this: https://trac.ffmpeg.org/ticket/4832 I'll work on a backtrace. Anyone here know of this?
[21:14:55 CET] <ubitux> Daemon404: is it an unsupported subtitles? is ffmpeg supporting that one? @_@
[21:15:10 CET] <Daemon404> ubitux, no it's IE11 being a piece of crap
[21:15:14 CET] <Daemon404> and not doing vtt right
[21:15:22 CET] <ubitux> ok
[21:15:32 CET] <ubitux> if even browser can't handle vtt
[21:15:36 CET] <ubitux> i wonder how we are supposed to
[21:16:00 CET] <Daemon404> ubitux, by embedding a browser
[21:16:04 CET] <Daemon404> like vlc will one day
[21:16:13 CET] <JEEB> are you implying it hasn't yet?
[21:16:21 CET] <Daemon404> it has?
[21:16:39 CET] <JEEB> at least it has one available for it through Qt
[21:16:47 CET] <Daemon404> Zeranoe, i dont think anyone outside of nevcairiel knows qsv here
[21:16:49 CET] <ubitux> apparently we can't embed ie11
[21:17:04 CET] <JEEB> only its chakra engine
[21:17:04 CET] <ubitux> not good enough for subtitles
[21:17:18 CET] <nevcairiel> qsv likes to freeze sometimes, its just the way of the world
[21:17:54 CET] <nevcairiel> i stopped considering it usable
[21:17:55 CET] <Zeranoe> I noticed that
[21:18:01 CET] <Daemon404> do our bug reporting guidelines ask for a backtrace built with debugging symbols?
[21:18:08 CET] <Daemon404> i always see traces with absolute offsets
[21:18:17 CET] <Zeranoe> It isn't every time either, and it's sometimes specific to a CPU
[21:18:40 CET] <Daemon404> that sounds lovely
[21:19:38 CET] <Zeranoe> I updated from a release to the git and it went away, until I jumped on an N3700.
[21:20:16 CET] <wm4> <JEEB> at least it has one available for it through Qt <- chrome
[21:20:21 CET] <wm4> the whole fat thing
[21:20:32 CET] <JEEB> yup
[21:20:45 CET] <Daemon404> yeah but i thought subtitles in vlc were done with the plugin/filter/whatever interface
[21:20:54 CET] <Daemon404> not the gui
[21:21:22 CET] <Zeranoe> I'll add this to the bug, but it can be reproduced with ffmpeg -i in.mp4 -vf unsharp=lx=7:ly=7:la=0.56:cx=7:cy=7:ca=0.28 -c:v h264_qsv -b:v 2000k -preset:v veryslow -y out.mp4
[21:21:43 CET] <Daemon404> Zeranoe, it sounds like the bug/problem is in the qsv library
[21:21:46 CET] <Daemon404> to me
[21:22:00 CET] <Zeranoe> it could be
[21:23:43 CET] <wm4> got, 3rd party devs are going to kill themselves once we're done
[21:23:49 CET] <wm4> god, even
[21:24:09 CET] <Daemon404> wm4, i mena... 99.999% of the stuff that will break was wrong anyway
[21:24:17 CET] <nevcairiel> so whatever happened to codec->framerate, codec->time_base, codec->ticks_per_frame?
[21:24:35 CET] <Daemon404> codec->time_base never made any sense afaik
[21:24:40 CET] <Daemon404> not sure about the other two
[21:24:51 CET] <nevcairiel> apparently libav uses st->internal->avctx in this function .. must be during probing or something
[21:24:51 CET] <wm4> nevcairiel: set AVStream fields
[21:24:53 CET] <wm4> I suppose
[21:24:59 CET] <wm4> oh fuck
[21:25:02 CET] <nevcairiel> i took it upon myself to do utils.c
[21:25:12 CET] <Daemon404> :D
[21:25:18 CET] <wm4> well I guess there'll be a huge number of fate failures
[21:25:47 CET] <nevcairiel> well the internal avctx should not be used by demuxers
[21:25:56 CET] <Zeranoe> nevcairiel: Is a backtrace going to help here?
[21:27:50 CET] <nevcairiel> Zeranoe: probably not
[21:28:06 CET] <Zeranoe> My thoughts too
[21:28:19 CET] <Zeranoe> Is there anything that would help...
[21:32:24 CET] <ubitux> mmh so coded_{width,height} are not available either?
[21:32:40 CET] <nevcairiel> why would the container set those
[21:32:50 CET] <ubitux> it doesn't set them, it reads them
[21:32:55 CET] <ubitux> to guess the dv profile
[21:32:59 CET] <ubitux> just like the time base
[21:33:02 CET] <nevcairiel> silly dv
[21:33:11 CET] <ubitux> see 2139e584391b6db7ad315cf4f6443f87f7813d51
[21:33:17 CET] <ubitux> not sure what i'm supposed to do...
[21:33:18 CET] <ubitux> :(
[21:34:46 CET] <nevcairiel> the muxer needs to know the profile?
[21:34:48 CET] <nevcairiel> dv sure is crazy
[21:34:53 CET] <Daemon404> wut
[21:35:39 CET] <nevcairiel> in any case, that code was ultimately wrong, since it was never guaranteed that the codec context there was actually the one used for encoding
[21:36:09 CET] <Daemon404> nevcairiel, usually it was not
[21:36:16 CET] <Daemon404> iirc you werent supposed to use it anyway
[21:36:19 CET] <Daemon404> the stream ctx i meean
[21:36:25 CET] <nevcairiel> ffmpeg.c probably did
[21:36:27 CET] <nevcairiel> hence the "fix"
[21:36:49 CET] <Daemon404> isnt there some sidedata/metadata/50 other ways to pass it
[21:36:53 CET] <Daemon404> i cant keep track of then all
[21:36:54 CET] <Daemon404> them
[21:39:12 CET] <wm4> hm, nut, mfx, mov, and mux.c are still missing
[21:39:22 CET] <wm4> and libavdevice shit
[21:39:44 CET] <wm4> and oggparsflac.c (?)
[21:40:27 CET] <wm4> right, that one has parse craziness
[21:40:47 CET] <jamrial> i'm on it
[21:40:56 CET] <jamrial> trying a dummy ctx
[21:41:16 CET] <wm4> then you should mark it as wip
[21:42:17 CET] <wm4> AVCodecContex.sample_aspect_ratio -> AVStream.sample_aspect_ratio, correct?
[21:42:28 CET] <nevcairiel> wm4: no codecpar has one
[21:42:32 CET] <wm4> mux.c tries to deal with both, so just remove the avctx one?
[21:42:35 CET] <wm4> oh
[21:43:08 CET] <wm4> ugh, indeed it has
[21:43:13 CET] <wm4> I introduced some bugs earlier, then
[21:43:21 CET] <ubitux> and again, dvenc needs the codec time base
[21:43:33 CET] <Daemon404> ubitux, what is "codec time base" in this context
[21:43:36 CET] <Daemon404> how can a codec have a timebase
[21:43:50 CET] <ubitux> like i know
[21:43:54 CET] <Daemon404> lol ok
[21:43:57 CET] <Daemon404> let's see
[21:44:03 CET] <ubitux> i picked the stream time base
[21:44:05 CET] <Daemon404> dv just seems all sort of nutty
[21:46:00 CET] <ubitux> i'm going to have some fun in dump.c
[21:46:20 CET] <jamrial> wm4: http://pastebin.com/eXwBxkyF is that ok?
[21:46:51 CET] <wm4> mux accesses AVCodecContext.flags & AV_CODEC_FLAG_BITEXACT => ???
[21:46:59 CET] <jamrial> it compiles, but i of course can't test it on this branch. it works when i do the same with git head
[21:47:21 CET] <wm4> jamrial: you don't need to open it?
[21:47:28 CET] <wm4> well maybe that's ok
[21:47:42 CET] <wm4> the parser API will inevitably rewritten anyway
[21:47:56 CET] <jamrial> guess not since it worked
[21:48:00 CET] <ubitux> jamrial: just pass st->internal->avctx 
[21:48:04 CET] <ubitux> to the av parser
[21:48:17 CET] <jamrial> oh, that sounds much simpler, haha
[21:48:18 CET] <jamrial> lets see
[21:48:28 CET] <ubitux> that's how it was done in other places apparently
[21:49:42 CET] <wm4> den = (int64_t)st->time_base.num * st->codec->time_base.den;
[21:49:45 CET] <wm4> some fucked up shit
[21:50:52 CET] <ubitux> if num is st->time_base.num² that's fine!
[21:51:16 CET] <ubitux> wm4: oh wait, tb from st, and tb from codec?
[21:51:20 CET] <ubitux> hehehe
[21:51:53 CET] <wm4> yes
[21:52:02 CET] <wm4> looks like compat crap so I'm leaving it in
[21:54:14 CET] <wm4> I'm stopping now, all what's left are juicy bits (nut, mov), and libavdevice
[21:54:26 CET] <ubitux> what am i gonna do about 0578623?
[21:54:37 CET] <Daemon404> doesnt nut basically use every field, just because
[21:54:54 CET] <ubitux> well i guess i'll keep it as is
[21:54:54 CET] <wm4> Daemon404: yes, it serializes all ffmpeg data structures, or something
[21:55:07 CET] <Daemon404> it shouldnt be hard to fix
[21:55:15 CET] <Daemon404> i dont think it's in the nut spec
[21:55:21 CET] <Daemon404> otherwise libnut could not exist
[21:55:27 CET] <wm4> lol spec
[21:55:30 CET] <wm4> ok, I'll grab it
[21:55:41 CET] <Daemon404> it's still more of a spec than vpx
[21:56:09 CET] <wm4>  st->codec->has_b_frames = stc->decode_delay;
[21:56:11 CET] <wm4> fun start
[21:58:04 CET] <Daemon404> ive only ever used nut for transporting raw video + timestamps myself
[21:58:07 CET] <jamrial> ubitux, wm4: http://pastebin.com/j46bc46h ? can't test it of course since the avctx in avstreaminternal is new from this tep2 merge
[21:59:14 CET] <nevcairiel> personally I would steal the approach from flac_header and parse the sample rate manually
[21:59:22 CET] <nevcairiel> instead of mucking around with the avctx
[21:59:25 CET] <nevcairiel> and the parser
[21:59:27 CET] <jamrial> it's a mess and it's on libavcodec
[21:59:30 CET] <ubitux> st->codecpar->sample_rate = st->internal->avctx->sample_rate;
[21:59:33 CET] <ubitux> jamrial: why? ^
[22:00:13 CET] <nevcairiel> jamrial: well with manually i mean manually, see the flac_header function right above, it replicates extremely basic bitstream parsing
[22:01:45 CET] <jamrial> ubitux: i can remove it, i assumed it would be useful and/or needed
[22:02:09 CET] <jamrial> nevcairiel: i'll give it a try, but imo the internal approach is a simpler change
[22:02:50 CET] <wm4> so what to do with has_b_frames?
[22:02:57 CET] <wm4> do we want it in codecparams?
[22:03:02 CET] <ubitux> jamrial: dunno, it looks out of scope
[22:03:14 CET] <nevcairiel> wm4: which container mucks around with has_b_frames
[22:03:23 CET] <wm4> nevcairiel: nut lol
[22:03:35 CET] <wm4> but I think we also want to transfer it from lavf to lavc
[22:03:46 CET] <wm4> didn't we revert the Libav change to kill it completely
[22:03:53 CET] <nevcairiel> yeah
[22:04:15 CET] <nevcairiel> itrs ratehr h264 specific with questionable meaning, but not having it makes decoding behave rather differently
[22:11:02 CET] <ubitux> can we add dump_separator to codec_par?
[22:11:16 CET] <ubitux> or i can keep using st->codec for now?
[22:11:18 CET] <nevcairiel> wtf is that
[22:11:31 CET] <ubitux> a way to customize the codec stdout dumping
[22:11:41 CET] <nevcairiel> sounds terrible
[22:11:47 CET] <ubitux> yeah whatever
[22:11:58 CET] <ubitux> anyway, is st->codec still OK to use somehow?
[22:12:03 CET] <nevcairiel> no
[22:12:06 CET] <ubitux> :(
[22:12:25 CET] <nevcairiel> but you can still access any AVCodecContext fields for your decoders of course
[22:12:30 CET] <nevcairiel> just not through st->codec
[22:12:45 CET] <ubitux> how then?
[22:13:03 CET] <ubitux> i just need to read field
[22:13:11 CET] <nevcairiel> however you store your decoder
[22:13:48 CET] <ubitux> i'm in av_dump_format
[22:14:01 CET] <carpediem_> Hi developers. I am interested in pursuing GSOC 2016 under FFmpeg. I would like to take a shot at the project "Create a fuzzing testsuite for FFmpeg"
[22:14:03 CET] <ubitux> i only have access to avformat context
[22:14:50 CET] <ubitux> well i'll skip the extraction of the option from the codec context
[22:14:57 CET] <nevcairiel> ubitux: yeah thats not going to be accessible anymore
[22:15:25 CET] <wm4> those nut commits are probably shoddy
[22:15:34 CET] <wm4> Daemon404: be sure to read the commit messages when squashing the shit
[22:17:28 CET] <wm4> carpediem_: contact the mentor
[22:18:32 CET] <carpediem_> cool. Thanks!
[22:18:42 CET] <cone-962> ffmpeg 03Paul B Mahol 07master:781195fa6229: avfilter/af_sofalizer: check if filename was set.
[22:22:53 CET] <wm4> rc_max_rate again
[22:25:02 CET] <Timothy_Gu> I wonder why every single student who requested the fuzzing project is from India...
[22:25:11 CET] <cone-962> ffmpeg 03Paul B Mahol 07master:f81c81cc3abb: avfilter/af_afftfilt: add option for 17 fft case
[22:25:17 CET] <wm4> most students who show interest are from india
[22:26:07 CET] <ubitux> it's very interesting for them economically i believe
[22:26:30 CET] <Timothy_Gu> well, I don't see a bunch of Chinese kids showing up
[22:27:01 CET] <Timothy_Gu> (besides me :) and I can't say this isn't interesting for me economically
[22:27:41 CET] <Daemon404> wm4, ok
[22:27:53 CET] <ubitux> Timothy_Gu: maybe google promoted gsoc there at some point
[22:28:01 CET] <wm4> Timothy_Gu: you'd make a pretty awesome gsoc student
[22:28:12 CET] <ubitux> strange thing is, opw has the same thing
[22:28:16 CET] <ubitux> most candidates were from india
[22:28:42 CET] <ubitux> Timothy_Gu: yeah, can't do it?
[22:28:51 CET] <Timothy_Gu> not in college yet
[22:29:04 CET] <ubitux> that's a requirement?
[22:29:10 CET] <Timothy_Gu> Yes
[22:29:12 CET] <ubitux> :(
[22:29:54 CET] <Timothy_Gu> So apparently I'm old enough to mentor but I'm too young to be a student...
[22:29:58 CET] <wm4> lol
[22:30:00 CET] <ubitux> haha
[22:30:06 CET] <fritsch> hehe
[22:31:01 CET] <nevcairiel> i bet this whole find_stream_info business is just going to explode
[22:31:05 CET] <nevcairiel> but it compiles!
[22:31:09 CET] <wm4> of course it will
[22:31:22 CET] <nevcairiel> i got confused in between when to use codecpar and avctx
[22:32:07 CET] <nevcairiel> there is a fundamental problem there .... it creates the internal avctx once for every stream from the codecpars, but demuxers could potentially still change the codecpars during demuxing
[22:32:23 CET] <nevcairiel> there were a few libav patches before for such cases where they delayed thje stream creation until all info was available
[22:32:33 CET] <nevcairiel> but alas we might still have that problem
[22:32:59 CET] <nevcairiel> well, we will find out, wont we
[22:33:22 CET] <wm4> yeah, through pain and suffering
[22:33:41 CET] <nevcairiel> its probably very obscure formats that suffer from that
[22:33:52 CET] <nevcairiel> but plenty ammo for carl to moan about merges again
[22:34:26 CET] <Daemon404> id like to point out that it is sad that that is a thing to worry about
[22:34:45 CET] <nevcairiel> i just ignore him, its not like that gets him anywhere on that front
[22:35:34 CET] <nevcairiel> i'm sure tep2 will break mplayer three times over as well, since a bunch of parameters go missing that it needs to exist
[22:35:43 CET] <wm4> let him moan
[22:35:49 CET] <wm4> and mplayer gets broken all the time
[22:35:53 CET] <Daemon404> mplayer doesnt need merges to break
[22:35:54 CET] <wm4> mostly due to configure changes
[22:35:56 CET] <Daemon404> it does that all on its own
[22:36:01 CET] <nevcairiel> haha
[22:37:37 CET] <ubitux> isn't mplayer still breaking everytime we add a codec id?
[22:38:22 CET] <Daemon404> lolwut?
[22:39:43 CET] <wm4> holy fuck mov contains avi
[22:39:48 CET] <wm4> I didn't know...
[22:39:48 CET] <JEEB> :o
[22:39:54 CET] <wm4> mov_write_ms_tag...
[22:40:00 CET] <JEEB> I knew of VFW mode in matroska
[22:40:02 CET] <JEEB> but mov!?
[22:40:04 CET] <ubitux> Daemon404: or maybe i'm mistaken with the addition of any CONFIG_<sth> that isn't format/codec/etc 
[22:40:30 CET] <iive> ubitux: i don't see how adding codec_id could break anything.
[22:40:32 CET] <wm4> JEEB: well whatever mov mutation it is
[22:40:46 CET] <ubitux> Daemon404: see r37795 r37432 r37421
[22:40:48 CET] <ubitux> stc
[22:40:50 CET] <ubitux> etc
[22:40:52 CET] <wm4> yeah, changing configure breaks mplayer almost certainly
[22:41:01 CET] <JEEB> all these things you could just take to the back of the barn...
[22:41:41 CET] <wm4> oh no frame_size again
[22:42:45 CET] <jamrial> avctx->time_base. what do i do with that?
[22:42:58 CET] <nevcairiel> hope its not crucial and hide
[22:43:23 CET] <nevcairiel> which one?
[22:43:28 CET] <jamrial> vfwcap.c in libavdevice. if removing it breaks something we'll not find until someone actually uses that .p
[22:44:03 CET] <nevcairiel> shouldnt that set stream timebase or something rather
[22:44:13 CET] <durandal_170> ubitux: flic demuxer have no need to set sample format
[22:44:47 CET] <ubitux> ok ok
[22:45:01 CET] <nevcairiel> jamrial: apparently libav sets st->avg_frame_rate instead
[22:45:32 CET] <wm4> I'v been using st->time_base
[22:45:57 CET] <wm4> which is probably wrong
[22:46:13 CET] <nevcairiel> it is, that one should be set through avpriv_set_pts_info
[22:46:29 CET] <nevcairiel> manually messing with it will likely cause trouble
[22:47:06 CET] <jamrial> nevcairiel is probably right
[22:47:17 CET] <jamrial> libav replaced avctx->time_base with st->avg_frame_rate
[22:50:09 CET] <ubitux> ah
[22:50:27 CET] <ubitux> i guess i know what to do about the dv then
[22:51:37 CET] <nevcairiel> so who makes a new list with all the files we still need to fix? =p
[22:52:16 CET] <ubitux> it's in commit messages, and i flagged them in the list too
[22:52:30 CET] <ubitux> oh sorry you were talking about sth else
[22:52:47 CET] <nevcairiel> i mean the files libav didnt have
[22:53:42 CET] <Daemon404> grep ->codec-> ?
[22:53:47 CET] <ubitux> git grep 'codec->' libavformat|cut -f1 -d:|sort -u
[22:53:55 CET] <Daemon404> or make -k :P
[22:54:15 CET] <Compn> re india and opw/soc ... probably related to h1b visas (shhh conspiracy time :P)
[22:54:31 CET] <wm4> who wants to fix mov.c
[22:54:49 CET] <Daemon404> i can do it tomorrow if its not Super Urgent
[22:54:55 CET] <Daemon404> is it insane?
[22:55:08 CET] <wm4> it's probably a lot
[22:55:13 CET] <wm4> movenc.c was quite much
[22:55:26 CET] <ethe> How does ref counting work? sometimes avpacket->ref is NULL, and other times ->data is NULL and other times, neither of them are NULL
[22:55:28 CET] <wm4> (though mostly I did search&replace, and removing the Libav chunks)
[22:55:45 CET] <wm4> ethe: ref should usually not be NULL
[22:55:47 CET] <nevcairiel> what did we do with frame_size now?
[22:55:50 CET] <nevcairiel> some codecs seem to need it
[22:55:53 CET] <wm4> if ref is null, it's not refcounted
[22:56:01 CET] <wm4> nevcairiel: I left it as is (deprecated codec access)
[22:56:05 CET] <wm4> also, has_b_frames
[22:56:19 CET] <wm4> I have no idea what frame_size is
[22:56:25 CET] <wm4> audio frame size?
[22:56:27 CET] <Timothy_Gu> Compn: gsoc doesn't allow for visas
[22:56:32 CET] <ethe> wm4: is it random if it's refcounted or not?
[22:56:42 CET] <nevcairiel> wm4: yeah size of audio frames typically
[22:56:42 CET] <wm4> ethe: when do you get not refcounted packets?
[22:56:48 CET] <nevcairiel> wm4: for odd raw formats
[22:56:55 CET] <Compn> Timothy_Gu : i mean for those students who graduate and are then eligable for visas. investing in the future...
[22:56:57 CET] <wm4> in some cases I might have tried to use that one function as replacement
[22:57:20 CET] <Compn> Timothy_Gu : basically, google is poaching students for future employment :P
[22:57:24 CET] <ethe> when reading from a AVFIFO
[22:57:33 CET] <wm4> ethe: uh what
[22:57:52 CET] <wm4> ethe: if you mean the data structure, who puts packets there?
[22:57:53 CET] <JEEB> he's deep in avdevice IIRC
[22:57:58 CET] <ethe> yes
[22:58:17 CET] <ethe> wm4: a write packet function
[22:58:41 CET] <wm4> well that's not sane
[22:58:49 CET] <wm4> if it's not refcounted, the data is usually volatile
[22:59:02 CET] <wm4> but this stuff is probably internal to whatever "demuxer" you're touching
[22:59:06 CET] <Compn> Timothy_Gu : whats your opinion on some of the students whove contacted you  about the fuzzing project? have any of them been able to google things for themselves ? like locating our wiki page that explains what needs to be done?
[22:59:29 CET] <Timothy_Gu> Compn: we have one?
[23:00:18 CET] <ethe> wm4: tbh I think it's more of a "oh god wtf am I doing, I have no idea" kind of thing
[23:01:23 CET] <Compn> Timothy_Gu : i count at least 3 people interested in fuzzing project already. 4 including you.
[23:01:43 CET] <Timothy_Gu> Compn: I mean, we have a wiki page that explains what needs to be done?
[23:01:54 CET] <Timothy_Gu> or do you mean the main ideas page
[23:02:09 CET] <Compn> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016
[23:02:27 CET] <Compn> main ideas page i mean
[23:02:38 CET] <wm4> export_orphan_timecode() <- interesting function name
[23:03:34 CET] <wm4> mov.c wants audio_service_type
[23:05:42 CET] <Timothy_Gu> Compn: I think they know about that page, but the instructions aren't as speicfic as they can be
[23:05:57 CET] <cone-962> ffmpeg 03Timo Rothenpieler 07master:95a5fd4581c6: configure: NVENC API version 6 is now required
[23:06:22 CET] <Compn> Timothy_Gu : i'm wondering if i should edit that page and mention that students have already "picked " the fuzzing project and it would be better if other students picked another one ?
[23:06:50 CET] <Compn>  we used to do this in the past, explained to students how to make an account and do this themselves
[23:07:02 CET] <Compn>   not sure if thats happening this year or not
[23:07:11 CET] <Timothy_Gu> Compn: well while it's true that a lot of students picked this one, as they say when the odds are good the good are odd
[23:07:53 CET] <Timothy_Gu> the qualification task page should be updated to incorporate students who are willing to do it
[23:08:10 CET] <Timothy_Gu> I don't want to block off any potential candidates right now
[23:09:02 CET] <Compn> ok fair enough, i wont mess with it then. just bringing it to your attention. :)
[23:09:16 CET] Action: Compn afk
[23:09:23 CET] <wm4> the fuck is AV_CODEC_FLAG2_DROP_FRAME_TIMECODE
[23:09:48 CET] <wm4>  * timecode is in drop frame format. DEPRECATED!!!!
[23:09:50 CET] <wm4> ok
[23:10:16 CET] <cone-962> ffmpeg 03Paul B Mahol 07master:ac15d7a66633: avfilter/vf_histogram: explicitly set 10bit output formats
[23:13:37 CET] <BtbN> what
[23:13:46 CET] <wm4> lol
[23:14:12 CET] <BtbN> at least it's just critical
[23:15:19 CET] <Timothy_Gu> "please paste your full, uncut command output"
[23:16:47 CET] <BtbN> No idea what that guy is doing, but there is no AVFrame in my version of lavc.
[23:16:54 CET] <nevcairiel> there used to be
[23:16:58 CET] <nevcairiel> it was moved
[23:17:19 CET] <BtbN> so he... somehow managed to mix his code?
[23:17:42 CET] <nevcairiel> who knows
[23:21:16 CET] <ethe> Timothy_Gu: you got a small task I can do? avdevice, threads & async APIs are killing me.
[23:21:42 CET] <Timothy_Gu> ethe: what kind of task are you looking for?
[23:21:55 CET] <wm4> ethe: what is the task you're doing? (the avdevice one)
[23:23:20 CET] <ethe> wm4: writing a JACK output device (this is the one I'm currently doing), and adding a SDL2 output device (which is completed but I implemented it without threads, so it's not ideal, but it works perfectly fine)
[23:23:42 CET] <wm4> oh ok, that does sound pretty advanced
[23:25:06 CET] <ethe> Timothy_Gu: An easier task probably. I'm interested in audio stuff, but I know so little about it (and even less about video stuff).
[23:25:25 CET] <cone-962> ffmpeg 03Neil Birkbeck 07master:bbda13a7713b: lavf/matroskadec: Add early support for some of the new colour elements.
[23:25:26 CET] <cone-962> ffmpeg 03Neil Birkbeck 07master:3c658e265517: lavf/dump.c: Print mastering display metadata
[23:31:34 CET] <BtbN> O_O
[23:32:42 CET] <wm4> a miserable mixture of Qt embedded ffmpeg and ARM stuff?
[23:32:57 CET] <BtbN> It is actualy mixing two distinct ffmpeg trees
[23:33:15 CET] <BtbN> And some weird Qt build system
[23:33:42 CET] <BtbN> I'd say this ticket can be closed.
[23:34:13 CET] <wm4> definitely
[23:34:26 CET] <wm4> the interesting part would be how the mixture even happens
[23:34:47 CET] <ethe> Timothy_Gu: got any ideas?
[23:35:03 CET] <Timothy_Gu> ethe: you interested in assembly?
[23:36:13 CET] <ethe> I dont know x86 at all, I know a bit of arm, although I dont have an arm device to test with currently. I'm up for trying something new though
[23:37:47 CET] <Timothy_Gu> ok
[23:38:04 CET] <Timothy_Gu> ethe: you see in https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/x86 we have lots of assembly optimization
[23:38:25 CET] <Timothy_Gu> many of them are in .asm
[23:38:47 CET] <Timothy_Gu> and are assembled by Yasm or NASM
[23:38:57 CET] <Timothy_Gu> but some older ones are inline asm
[23:38:59 CET] <Timothy_Gu> like https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/x86/lpc.c
[23:39:18 CET] <Timothy_Gu> so what we are tring to do is convert them to Yasm/NASM format
[23:40:09 CET] <Timothy_Gu> for the rationale see https://launchpad.net/ffmpeg/+announcement/12726
[23:41:04 CET] <Timothy_Gu> for some examples of how to convert see https://github.com/FFmpeg/FFmpeg/commits/master/libavcodec/x86?author=TimothyGu
[23:41:14 CET] <Timothy_Gu> (my commits are usually the easiest ones :)
[23:41:30 CET] <Timothy_Gu> and of course, the earlier it is the easier it is to understand
[23:41:37 CET] <cone-962> ffmpeg 03Rostislav Pehlivanov 07master:b88be742fac7: vc2enc: do not allocate packet until exact frame size is known
[23:41:38 CET] <cone-962> ffmpeg 03Rostislav Pehlivanov 07master:f21cf2b38365: vc2enc: remove useless alignment on slice encoding
[23:41:39 CET] <cone-962> ffmpeg 03Rostislav Pehlivanov 07master:c45b1aa8241a: vc2enc: minor cosmetic changes
[23:42:44 CET] <Timothy_Gu> https://wiki.videolan.org/X264_asm_intro/ is helpful too, although it's just a little bit outdated
[23:48:39 CET] <wm4> Timothy_Gu: maybe you could think of a gsoc project involving asm?
[23:49:14 CET] <Timothy_Gu> wm4: the part where asm is the most needed rn is probably hevc
[23:49:29 CET] <nevcairiel> thats too complex for a student
[23:49:50 CET] <Timothy_Gu> The student can port from openhevc though
[23:50:14 CET] <nevcairiel> proper hevc asm would probably need a whole bunch of refactoring in the hevc decoder
[23:50:36 CET] <nevcairiel> the openhevc stuff isnt the best
[23:50:45 CET] <Timothy_Gu> there's also the problem of finding mentors
[23:50:48 CET] <wm4> to be fair everyone cherry-picks these patches anyway
[23:50:53 CET] <wm4> for their own builds
[23:52:07 CET] <ethe> loren writes a lot of asm
[23:53:10 CET] <Timothy_Gu> ethe: Yes, pengvado/Loren is probably the best at asm among anyone of us here
[23:53:30 CET] <Gramner> avx2 can be written for a lot of stuff if you're looking for something to do. probably easier to add avx2 versions of existing functions in many cases than to write new asm from scratch
[23:57:03 CET] <Timothy_Gu> Gramner: how much do the 256-bit regs help in performance?
[23:58:08 CET] <Gramner> if you can fully utilize the wider registers? twice as fast as 128-bit regs
[00:00:00 CET] --- Sat Mar  5 2016