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

[burek]

[00:00:17 CEST] <Compn> http://ffmpeg.org/developer.html
[00:00:26 CEST] <Compn> Whichever way, changes should be reviewed by the maintainer of the code before they are committed. 
[00:00:40 CEST] <Compn> or later on
[00:00:40 CEST] <Compn> Send your changes as patches to the ffmpeg-devel mailing list, and if the code maintainers say OK, you may commit. This does not apply to files you wrote and/or maintain.
[00:00:49 CEST] <Compn> Also note, the maintainer can simply ask for more time to review!
[00:01:02 CEST] <Compn> and then rule 19 
[00:01:03 CEST] <Compn> Make sure that no parts of the codebase that you maintain are missing from the MAINTAINERS file. If something that you want to maintain is missing add it with your name after it. If at some point you no longer want to maintain some code, then please help finding a new maintainer and also don’t forget updating the MAINTAINERS file.
[00:01:40 CEST] <Compn> please dont get upset, and feel free to request to change maintainers file (or rm it)
[00:01:47 CEST] <Compn> i'm just pointing out how you are wrong :)
[00:02:49 CEST] <Compn> >why bother, no one cares about developer policy/rules anymore, its anarchy
[00:05:36 CEST] <wm4> yep, means nothing
[00:07:14 CEST] <wm4> in this case the maintainer apparently wasn't aware that his maintained code was deprecated for years
[00:07:39 CEST] <Compn> yes i read the discussion
[00:08:03 CEST] <Compn> Daemon404 : i'm 90% sure that even clone will fail if you use wrong login (instead of anonymous clone)
[00:10:48 CEST] <Compn> sorry, its just hilarious, years ago commit messages were "fix bug" and then devs complained, so we made policy , now devs complain they dont like the policy anymore :P
[00:11:10 CEST] <Compn> obviously different waves of devs over the past 10 years. still, amusing.
[00:12:14 CEST] <Compn> why no one bothers to change policy if they dont like it, sigh
[00:13:45 CEST] <wm4> I kind of opened the wrong door with doubting the maintainer thing
[00:14:02 CEST] <wm4> because the bikeshed and infighting might go into this direction
[00:14:04 CEST] <wm4> well whatever
[00:14:31 CEST] <Compn> ahhhh dont worry about it
[00:14:36 CEST] <Compn> i predict peaceful negotiations.
[00:14:38 CEST] <Compn> :P
[00:22:39 CEST] <jamrial> doens't matter. let that thread devolve into shit flinging if that's the end result
[00:22:55 CEST] <jamrial> carl's commit is not valid so it wont go in
[00:43:55 CEST] <philipl> JEEB: Kodi has transitioned, althought they do grumble that with the new API ffmpeg is making vdpau calls. Apparently they liked how the old API made the application do more work :-)
[01:27:32 CEST] <BBB> __gb__: in case it matters, I think (for consistency) that removing the vld suffix in the non-deprecated code sounds good
[01:29:02 CEST] <wm4> philipl: I had the same issue
[01:29:20 CEST] <wm4> vdpau preemption is hard to handle, and the new api makes it harder
[01:41:44 CEST] <philipl> wm4: blame libav? :-P
[01:42:30 CEST] <philipl> Because it allocates resources internally that need to be invalidated?
[01:43:07 CEST] <philipl> There's a reset flag in the context which looks like it's supposed to be related to pre-emption but I don't see it being used properly.
[02:02:46 CEST] <BBB> whoooo wants to review https://github.com/rbultje/ffmpeg/commit/6a770eabd16bcd9c61f9b7a896d4f93ee8440f43 ?
[02:03:03 CEST] <BBB> or any of the -ab related ones
[02:12:59 CEST] <jamrial> huh, i thought i replied to that email
[02:13:19 CEST] <BBB> you did?
[02:13:42 CEST] <jamrial> no, i didn't. i thought i did :p
[02:13:59 CEST] <BBB> ah, ok, I thought my mail client had gone blind
[03:53:19 CEST] <cone-190> ffmpeg 03Michael Niedermayer 07master:c1507db61760: fate: Force simple idct for fate-asf-repldata
[03:57:20 CEST] <llogan> i wonder if there is a more efficient way to keep docs updated. such as dumping directly from AVOption.
[04:23:07 CEST] <cone-190> ffmpeg 03Ronald S. Bultje 07master:6495c4c68713: lavfi: fix compilation with FF_API_OLD_FILTER_OPTS=0.
[05:14:52 CEST] <philipl> ubitux: Can you reply to Niklesh about the ASS default style?
[05:14:59 CEST] <philipl> I don't see how you access that
[10:01:16 CEST] <ubitux> philipl: ah damn, forgot to answer, will do
[11:44:18 CEST] <wm4> nevcairiel: so, are we ok with the VAAPI pixfmt renaming?
[11:44:45 CEST] <wm4> (seems a bit unnecessary, but I don't mind, especially if it comes with larger API changes)
[11:45:40 CEST] <nevcairiel> i find it unnecessary, but i dont really care
[11:49:58 CEST] <__gb__> I still think this is necessary for sanity purposes :)
[11:52:08 CEST] <wm4> then let's just give green light
[11:55:21 CEST] <wm4> __gb__: do you have push access?
[11:59:09 CEST] <__gb__> if the server is still on videolan.org, yes, of course
[11:59:22 CEST] <__gb__> but backlogging shows some issues at the moment?
[11:59:38 CEST] <wm4> dunno, try it
[12:01:15 CEST] <nevcairiel> it works fine for everyone except Daemon404 with his yodel internet
[12:08:48 CEST] <cone-247> ffmpeg 03Paul B Mahol 07master:fa95965f5aee: avfilter/vf_histogram: make it possible to pick color components for levels mode
[12:21:05 CEST] <wm4> __gb__: one minor thing: you could mention in APIchanges that AV_PIX_FMT_VAAPI has the same function and value as AV_PIX_FMT_VAAPI_VLD
[13:26:09 CEST] <__gb__> michaelni, ok with lavu 54.30.101 & lavc 56.57.102 or do you prefer bumping the minor instead?
[13:30:20 CEST] Action: __gb__ opted for lavu 54.31.100 & lavc 56.58.100 based on statistical analysis
[13:31:23 CEST] <wm4> that should be fine
[13:32:12 CEST] <j-b> use 100.100.100
[13:38:29 CEST] <michaelni> __gb__, ok
[13:38:50 CEST] <cone-247> ffmpeg 03Neil Birkbeck 07master:3dabebc272b0: libavformat/matroskaenc.c: fix small memory leaks on error
[13:50:58 CEST] <cone-247> ffmpeg 03Sven Dueking 07master:6eecb91fbc27: avcodec/qsvenc: Added PicTiming SEI
[14:17:00 CEST] <cone-247> ffmpeg 03Gwenole Beauchesne 07master:9f8e57efe440: vaapi: define a unique pixel format for VA-API (AV_PIX_FMT_VAAPI).
[14:17:01 CEST] <cone-247> ffmpeg 03Gwenole Beauchesne 07master:babd340f5849: vaapi: streamline public context structure.
[14:17:02 CEST] <cone-247> ffmpeg 03Gwenole Beauchesne 07master:8813d55fa597: vaapi: fix usage of invalid buffer ids.
[14:17:03 CEST] <cone-247> ffmpeg 03Gwenole Beauchesne 07master:9d1d7b367eeb: vaapi: drop unused include.
[14:30:24 CEST] <cone-247> ffmpeg 03Ivan Uskov 07master:fffae8e605c8: libavcodec/qsvdec.c: the ff_get_format() missed at refactoring has been restored
[14:58:54 CEST] <Daemon404> nevcairiel, no it works now
[15:44:15 CEST] <cone-247> ffmpeg 03Pedro Arthur 07master:62d176de1224: swscale: refactor vertical scaler
[15:48:41 CEST] <BBB> michaelni: do you have further thoughts on the -ab -> -b:a thing?
[16:16:00 CEST] <cone-247> ffmpeg 03Ronald S. Bultje 07master:99b9f0136c6e: fate: rename -error option to -error_rate.
[16:20:03 CEST] <cone-247> ffmpeg 03Henrik Gramner 07master:18b101ff595c: checkasm: Explicitly declare function prototypes
[16:20:04 CEST] <cone-247> ffmpeg 03Henrik Gramner 07master:e6b8797b827c: checkasm: x86: properly save rdx/edx in checked_call()
[16:43:07 CEST] <michaelni> BBB, if nothing breaks and all keeps working i have no further comments or thoughts
[16:44:12 CEST] <BBB> stuff seems to work for me
[16:44:23 CEST] <BBB> (I tested that -ab works after the patch with FF_API_OLD_AVOPTIONS=0)
[16:44:41 CEST] <BBB> (in ffmpeg bla bla -i bla bla -ab bla bla output.mp2)
[17:15:36 CEST] <wm4> what does the h264 decoder do if it gets 2 frames in 1 packet?
[17:17:53 CEST] <nevcairiel> thats an invalid API call =p
[17:18:09 CEST] <nevcairiel> probably error out or complain loudly
[17:18:16 CEST] <nevcairiel> or just skip one and error later about missing things
[17:18:35 CEST] <wm4> I don't know if that's what's happening, but at least I see no misbehavior
[17:18:47 CEST] <wm4> so, seems unlikely
[17:36:11 CEST] <BBB> wm4: I think it decodes both, but only returns one
[17:36:19 CEST] <BBB> (probably the first one)
[17:36:27 CEST] <BBB> and the second one may be cached for future return
[17:36:42 CEST] <BBB> so if you do that a lot, youll eventually have a ton of frames cached internally, causing huge decoder delay
[17:37:23 CEST] <nevcairiel> in short, we have a parser for that :D
[17:37:36 CEST] <BBB> wm4: I think the part where it may screw up has to do with frame threading, since well call setup_finished after the first frame is set up, even though the second ref isnt available yet then for next threads to use as one
[17:37:50 CEST] <BBB> wm4: but if you disable (frame) threading, it may work
[17:37:57 CEST] <BBB> and yes, use a parser
[17:38:26 CEST] <wm4> I'm comparing the MMAL decoder and the ffmpeg software decoder, and I'm trying to figure out why the MMAL decoder does not return a timestamp for a specific frame
[17:38:46 CEST] <wm4> but so far it looks like they decode exactly the same data
[17:38:55 CEST] <wm4> just that MMAL sometimes misses the timestamp
[17:40:55 CEST] <wm4> (and of course changing threads doesn't change anything in ffmpeg's results)
[17:50:02 CEST] <Daemon404> frozen summer fun will have ended?!
[17:50:04 CEST] <Daemon404> VDD is ruined.
[17:51:30 CEST] <kierank> you mean I can't get drunk and sing let it go
[17:51:47 CEST] <j-b> Daemon404: I'm sooo sorry
[17:51:58 CEST] <Daemon404> kierank, sure you can
[17:52:01 CEST] <j-b> yep
[17:53:01 CEST] <tab1293> Can anyone explain what the read, write, and seek callback functions are supposed to do in avio_alloc_context http://ffmpeg.org/doxygen/trunk/avio_8h.html#a853f5149136a27ffba3207d8520172a5
[17:53:28 CEST] <Daemon404> tab1293, you dont need them unless you want custom i/o
[17:53:41 CEST] <tab1293> Daemon404, yes I know, I do want custom I/O
[17:53:44 CEST] <Daemon404> ok
[17:53:50 CEST] <Daemon404> they do what they say on the tin
[17:54:02 CEST] <Daemon404> is there anything specific you need to know?
[17:54:42 CEST] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper.c
[17:54:53 CEST] <tab1293> I am just a little confused as to what the docs mean when saying 'the function for refilling the buffer'
[17:55:02 CEST] <JEEB> basically you do something like this and set them accordingly
[17:55:04 CEST] <Daemon404> tab1293, it reads from your i/o
[17:55:06 CEST] <nevcairiel> it gives you a buffer, and a number of bytes it wants
[17:55:14 CEST] <nevcairiel> read buf_size bytes, put them into buffer
[17:55:17 CEST] <nevcairiel> return buf_size
[17:55:20 CEST] <nevcairiel> done!
[17:55:40 CEST] <nevcairiel> (return a number smaller than buf_size if there arent that many bytes left)
[17:56:01 CEST] <nevcairiel> JEEB: you really build that in C? you mad.
[17:56:12 CEST] <JEEB> inorite
[17:56:33 CEST] <nevcairiel> interestingly your other files are cpp =P
[17:57:03 CEST] <Daemon404> i heard JEEB does COM packing at night
[17:57:07 CEST] <Daemon404> for kinks
[17:57:42 CEST] <tab1293> so when exactly is your read_packet function called. should it be responsible for putting data into your i/o buffer? 
[17:58:02 CEST] <JEEB> it's pretty much c, but it was easier to compile the rest as c++
[17:58:16 CEST] <Daemon404> tab1293, it is called whenever libavformat wants to read more into the buffer
[17:58:23 CEST] <JEEB> you still need a whole lot pf COM shit
[17:58:35 CEST] <Daemon404> aka when it exhausts the previois read, or needs more data
[17:59:45 CEST] <tab1293>  Daemon404 I am trying to do custom i/o over a network. If I am trying to read a stream off of a socket, should the read or write packet function be pulling data off the socket and putting into the buffer?
[18:00:00 CEST] <Daemon404> you know we have networking built in for many protocols right?
[18:00:27 CEST] <Daemon404> tab1293, how you buffer your i/o is up to you, i guess
[18:00:40 CEST] <Daemon404> you can look at the socket code for our internal read/write if you want
[18:00:44 CEST] <Daemon404> it may be helpful
[18:01:43 CEST] <tab1293> okay I'll take a look is it libavformat/network.c?
[18:01:56 CEST] <tab1293> and also do you know the answer to my previous question?
[18:02:00 CEST] <philipl> ubitux: thanks!
[18:02:14 CEST] <Daemon404> tab1293, which question?
[18:03:46 CEST] <tab1293> Should read_packet or write_packet be responsible for loading an input stream's data into the custom buffer?
[18:04:35 CEST] <tab1293> still having trouble wrapping my head around the purpose of each function
[18:04:54 CEST] <Daemon404>  int(*)(void *opaque, uint8_t *buf, int buf_size)  read_packet, 
[18:04:58 CEST] <Daemon404> it's exactly as nevcairiel said
[18:05:07 CEST] <Daemon404> you get a pointer, and a size, you fill that much
[18:09:26 CEST] <tab1293> Daemon404, okay but where is the opaque object coming from? 
[18:09:51 CEST] <Daemon404> when you create the avio context you set it
[18:09:55 CEST] <Daemon404> as avioctx->opaque
[18:09:59 CEST] <Daemon404> it's whatever you want
[18:10:05 CEST] <Daemon404> your own thing
[18:10:46 CEST] <Daemon404> it can be e.g. state for your custom i/o
[18:12:25 CEST] <tab1293> Daemon404, okay i didn't see any explicit setting of that member in https://www.ffmpeg.org/doxygen/2.5/avio_reading_8c-example.html
[18:13:04 CEST] <Daemon404> ?
[18:13:07 CEST] <Daemon404> it's right there
[18:13:08 CEST] <Daemon404> &bd
[18:13:47 CEST] <tab1293> ohh whoops, was confusing bd with something else
[18:13:53 CEST] <tab1293> okay makes sense now
[18:20:56 CEST] <cone-247> ffmpeg 03Paul B Mahol 07master:2fa019958b4f: avfilter: add showfreqs filter
[20:11:03 CEST] <BBB> volunteer wanted for reviewing https://github.com/rbultje/ffmpeg/commit/e5bb803bdee35d67e1ffd4cc001a155fdf120730 ?
[20:12:52 CEST] <sanjana> Hello everyone. I am Sanjana Sharma, a third year undergraduate CSE student in IIIT Hyderabad. I would like to contribute to this community. Can anyone guide me how I can start with it? 
[20:12:58 CEST] <wm4> BBB: emuedge seems like dark magic to me
[20:13:17 CEST] <wm4> BBB: and that lowres change looks strange, but that too is dark magic to me
[20:13:33 CEST] <BBB> always enable emu-edge is the basic assumption
[20:15:57 CEST] <jamrial> sanjana: there are many ways you can contribute. you could check http://trac.ffmpeg.org/ for bug tickets and fix some of them, or for feature requests and implement them
[20:16:55 CEST] <jamrial> you can browse ffmpeg's source tree for FIXME/TODO stuff and see if you can do something about them
[20:17:31 CEST] <jamrial> find something you're interested into and see if you can improve it
[20:17:57 CEST] <sanjana> jamrial: Thank you. Will get back to you. :)
[20:18:05 CEST] <jamrial> you could add new decoders, demuxers/muxers, filters, or improve/extend existing ones
[20:18:13 CEST] <llogan> you can subscribe to ffmpeg-devel to watch how patch submissions and reviews occur (but it's a high volume list)
[20:18:32 CEST] <jamrial> basically, whatever you feel like doing and think it will be useful
[20:19:31 CEST] <llogan> make sure to know basic git usage. if you're into hardware you can setup a fate client.
[20:19:38 CEST] <jamrial> take a look at https://ffmpeg.org/developer.html#Contributing as well
[20:20:34 CEST] <sanjana> Thanks a lot! :)
[20:35:20 CEST] <cone-247> ffmpeg 03Lou Logan 07master:4918726d4123: doc/indevs: add various missing options
[20:49:09 CEST] <cone-247> ffmpeg 03Lou Logan 07master:2edb7ab1cba6: MAINTAINERS: add myself as a docs maintainer
[21:39:23 CEST] <cone-247> ffmpeg 03Michael Niedermayer 07master:0b7829901bc9: */version.h: Add note/recommandition about bumping major
[21:41:53 CEST] <wm4> BBB, j-b: so what's the latest day and time of day I could appear on VDD?
[21:42:48 CEST] <BBB> saturday morning 9am
[21:43:30 CEST] <wm4> sounds impossible
[21:44:40 CEST] <Daemon404> people who show up late are forced to respond to users on libav-user
[21:45:03 CEST] <JEEB> lol
[21:45:13 CEST] <JEEB> a day on #ffmpeg could be enough :P
[21:47:15 CEST] <llogan> guest ML queue monkey
[22:10:50 CEST] <klaxa> okay, i think i found what i was doing wrong with AV_OPT_TYPE_BINARY, in any case, i now have a string representing binary data, are there convenience functions to turn such a string into binary again?
[22:11:04 CEST] <klaxa> i want to fill a sockaddr_storage struct with the data i get from av_opt_get()
[22:11:32 CEST] <klaxa> like i said, the string is in hex-representation, how do i reverse that?
[22:11:32 CEST] <BtbN> It's C. A string _is_ binary data.
[22:12:02 CEST] <klaxa> yes, av_opt_get() writes the binary data in ascii in a string though
[22:12:15 CEST] <nevcairiel> hm libav working on hevc simd, i bet it'll conflict bad with our stuff :(
[22:12:39 CEST] <klaxa> i.e. "1234" which in binary is not "1234" but whatever the ascii chars' numbers are as integers
[22:14:12 CEST] <klaxa> for example, getting a byte with the value 0x02 returns "02" which has the value 0x3032
[22:14:47 CEST] <klaxa> do you understand what my problem is?
[22:30:47 CEST] <BBB> nevcairiel: why?
[22:30:57 CEST] <BBB> nevcairiel: and why not just copy what the openhevc people wrote?
[22:31:15 CEST] <BBB> in the end, what matters is whos faster :)
[22:31:35 CEST] <nevcairiel> BBB: its libav, its NIH
[22:32:00 CEST] <nevcairiel> i should check how the things are written in our copy, and make sure th eirs doesnt diverge entirely
[22:32:39 CEST] <BBB> klaxa: snprintf(buf, %02x, data[0]); <-> sscanf(buf, %02x, &data[0]);
[22:32:43 CEST] <BBB> klaxa: is that helpful?
[22:33:16 CEST] <klaxa> ah, scanf is probably even better, i implemented a function that uses strtol()
[22:33:21 CEST] <klaxa> thanks BBB
[22:33:30 CEST] <BBB> yw
[22:37:27 CEST] <BBB> nevcairiel: a very quick look suggests we already have these optimizations that theyre talking about there
[22:37:36 CEST] <BBB> our mc is split by width (otherwise you cant write efficient assembly)
[22:37:46 CEST] <BBB> nevcairiel: and we have neon+x86
[22:38:21 CEST] <nevcairiel> which is why i am afraid they do something differently and we cannot benefit from each others things
[22:38:23 CEST] <BBB> nevcairiel: whats annoying about our simd is that its sse4/avx2 only
[22:38:41 CEST] <kierank> BBB: what's wrong with sse4/avx?
[22:39:25 CEST] <BBB> kierank: not everyone has sse4 cpus
[22:39:29 CEST] <philipl> 10 year old computers are computers too...
[22:39:32 CEST] <BBB> I typically recommend sse2/ssse3 as baseline
[22:39:36 CEST] <kierank> yes but to play hevc
[22:39:59 CEST] <wm4> I couldn't play HEVC with my previous core 2 duo
[22:40:00 CEST] <BBB> Im pretty sure I can play 1080p vp9 at 100fps
[22:40:09 CEST] <nevcairiel> BBB: for hevc, i wouldnt really want to play it at anything without sse4
[22:40:19 CEST] <philipl> Yeah.
[22:40:23 CEST] <BBB> (and I have a pre-sandybridge system)
[22:40:23 CEST] <iive> i've heard that sssse3 and sse4 doesn't have many new instruction useful for multimedia
[22:40:39 CEST] <iive> how hard is porting to sse2?
[22:40:40 CEST] <BBB> iive: you were sadly misinformed
[22:40:46 CEST] <ubitux> (these optims are just NIH provocation or half of it is actually new?)
[22:40:51 CEST] <BBB> ssse3 introduced pmaddubsw, which is probably the best thing in the world
[22:41:05 CEST] <BBB> theres some other instructions also that are good
[22:41:11 CEST] <iive> multiply and add bytes to word
[22:41:19 CEST] <JEEB> sse3 was the useless'ish
[22:41:23 CEST] <wm4> ubitux: why do you call it a provocation
[22:41:23 CEST] <philipl> __gb__: Will the skylake vp9 acceleration be exposed through vaapi?
[22:41:37 CEST] <wm4> skylake has vp9?
[22:41:46 CEST] <BBB> nevcairiel: I think we can play hevc on ssse3 machines
[22:41:47 CEST] <BBB> nevcairiel: I
[22:41:49 CEST] <ubitux> wm4: dunno, what would be the other reason?
[22:41:53 CEST] <philipl> It has partial dedicated vp9 with GPGPU doing other parts
[22:41:55 CEST] <BBB> nevcairiel: not sure about sse2& that may be far off
[22:42:03 CEST] <BBB> nevcairiel: but ssse3 should work, even for hd material (1080p)
[22:42:10 CEST] <wm4> ubitux: they prefer to ignore ffmpeg's existence, thus it can't be a "NIH provocation"
[22:42:37 CEST] <ubitux> dunno, i don't believe in this ignore
[22:42:44 CEST] <ubitux> that would be too stupid
[22:42:52 CEST] <philipl> wm4: I'm guessing it will be as they've added vp9 to vaapi - I assume they wouldn't do that if there's no hardware to back it this year.
[22:43:12 CEST] <nevcairiel> i'm still sad dxva2 doesnt have specs for vp8/vp9 to use the intel hardware
[22:43:38 CEST] <philipl> nevcairiel: yeah, but that would require MS acknowledge that vp8/9 exist.
[22:43:47 CEST] <philipl> nvidia hardware has support too, but no API.
[22:44:18 CEST] <BBB> well, so
[22:44:23 CEST] <BBB> ubitux: the good thing is
[22:44:32 CEST] <BBB> ubitux: we can now use checkasm to quickly check perf of theirs vs ours asm
[22:44:34 CEST] <nevcairiel> even the CUVID API doesnt support vp8/9, which is weird
[22:44:36 CEST] <BBB> and then we know which is better
[22:45:20 CEST] <jamrial> anton's patches don't mention openhevc as the source of the asm, so i wonder if they really rewrote it...
[22:45:21 CEST] <ubitux> assuming usages match
[22:45:22 CEST] <philipl> nevcairiel: There was a linux nvidia driver release that claimed to add vp8 support but no cuda release has vp8 headers
[22:46:09 CEST] <philipl> nevcairiel: In theory, it's on the vdpau todo list but low priority
[22:47:54 CEST] <BBB> jamrial: I think its new
[22:48:03 CEST] <BBB> jamrial: since its sse2/ssse3/avx, not sse4/avx2
[22:48:10 CEST] <BBB> its like, they wrote exactly that which we dont have
[22:48:25 CEST] <BBB> Id almost suggest to merge it so we have complete instruction set coverage, but that would be stupid
[22:48:37 CEST] <BBB> would be very ffmpeg though, MERGE EVERYTHING!!112
[22:48:45 CEST] <BBB> :-p
[22:48:59 CEST] <BBB> (j/k, in case anyone is thinking thats serious)
[22:50:06 CEST] <iive> can you write better ones?
[22:50:07 CEST] <jamrial> heh
[22:50:13 CEST] <jamrial> looks like they refactored some stuff. the prototypes don't match
[22:50:24 CEST] <jamrial> it wont be a conflic-less merge
[22:50:29 CEST] <cone-247> ffmpeg 03Michael Niedermayer 07master:034e6fbd9cdb: configure: Check for CoreServices/CoreServices.h and make vda+viedotoolbox depend on it
[22:50:48 CEST] <iive> jamrial: refactoring is their second name :)
[22:50:55 CEST] <wm4> nice typo
[22:51:25 CEST] <BBB> iive: yes
[22:51:29 CEST] <BBB> iive: the question is if I will
[22:51:51 CEST] <iive> write them under GPL, and ask for ransom :)
[22:51:55 CEST] <BBB> no
[22:52:03 CEST] <BBB> most companies use gpl code internally in their datacenters
[22:52:07 CEST] <BBB> it doesnt help anyone
[22:52:26 CEST] <BBB> iive: theres very expensive and elite companies out there using our code. hevc is extremely valuable and difficult to understand and write
[22:52:43 CEST] <BBB> if they want me to write their corporate code and make it 2x as fast as anything theyll ever see, theyll have to pay me
[22:52:51 CEST] <BBB> they can also wait for someone else to write it for free
[22:53:05 CEST] <iive> they will wait...
[22:53:09 CEST] <BBB> I know
[22:53:10 CEST] <BBB> :)
[22:54:00 CEST] <BBB> I still get questions about why the vp9 decoder ubitux/me wrote (+ some simd from jamrial) is so much faster than xyz
[22:54:05 CEST] <BBB> people do see its faster
[22:54:08 CEST] <BBB> they also dont understand why
[22:54:28 CEST] <iive> :))
[22:54:41 CEST] <BBB> so &
[22:55:03 CEST] <iive> do you have a fixed bounty for the task?
[22:56:28 CEST] <BBB> nothing specific
[22:56:43 CEST] <jamrial> before the high bitdepth changes, VP9 had probably the most clean looking and slick code in our tree
[22:57:15 CEST] <BBB> yeah the hbd stuff made it a little ugly :(
[22:57:28 CEST] <BBB> it also got ~2% slower or so?
[22:57:33 CEST] <BBB> it wasnt ideal
[22:57:38 CEST] <BBB> but it does support hbd now&
[22:58:05 CEST] <jamrial> no idea, didn't bench before and after
[23:00:00 CEST] <BBB> it sounds like you consider vp9 a snowflake (http://www.stilldrinking.org/programming-sucks)
[23:00:08 CEST] <BBB> sorry about that
[23:03:07 CEST] <jamrial> haha
[23:25:30 CEST] Action: Daemon404 catches up on vdpau lulz
[23:26:41 CEST] <jamrial> libav's hevc is wildly different to our. they apparently lack a lot of openhevc changes from the past two years
[23:39:59 CEST] <smarter> yeah, I gave up reviewing and merging those changes in libav
[23:42:48 CEST] <j-b> wm4: what can you do?
[23:42:50 CEST] <smarter> if there's an effort to make the two projets converge I'd be willing to spend time to merge the two codebases, otherwise it's not very motivating work
[23:45:31 CEST] <BBB> I second that
[23:46:10 CEST] <j-b> smarter: can I talk to you in private?
[23:46:13 CEST] <smarter> j-b: sure
[00:00:00 CEST] --- Thu Aug 20 2015