[09:43:41 CEST] <durandal_1707> michaelni: thank you very much, you made yet another developer to leave due to your f* bad patches, for how long? [11:46:56 CEST] <michaelni> durandal_1707, i do not know what you talk about. What patch? who? and how could a posted patch do that even ? [12:04:00 CEST] <cone-983> ffmpeg 03Bodecs Bela 07master:09a4853930e7: av_format/hlsenc: fix %v handling by format_name function [16:59:18 CEST] <durandal_1707> michaelni: Lynne left because of you [17:00:46 CEST] <BBB> ... [17:01:20 CEST] <BBB> I wish I had something meaningful to add here, but lately when I look at this tab in my IRC client, half of the time I see the same people arguing again and again [17:01:23 CEST] <BBB> this is getting really unhealthy [17:17:37 CEST] <kurosu> I have a bad view of the mailing list activity: is its activity getting worse or? Sure all the rage today is AV1, and so it happens elsewhere, but... [17:25:36 CEST] <jamrial> kurosu: the ml isn't too bad lately. but i think he's talking about michael's fuzzing related patches, many of which fix UB like integer overflows, and make the codebase somewhat uglier [17:25:52 CEST] <jamrial> some people have expressed their dislike for those [17:39:43 CEST] <michaelni> I wish these issues could be fixed in a prettier way but we need to fix them. leaving UB is not really an option [17:58:50 CEST] <kurosu> jamrial: Yeah, I wasn't particularly wondering about that particular instance, but more like if their proportion had increased [17:59:56 CEST] <kurosu> As for the particular instance, I bet it causes more happy users of the libs than developpers, indeed [20:00:45 CEST] <durandal_1707> michaelni: you are bad leader and developer, because you force your only solution upon others, you are dictator [20:38:58 CEST] <jamrial> durandal_1707: why do you feel the need to troll like this? [21:30:03 CEST] <jya> BtbN: any link to code I could look at? [21:31:11 CEST] <BtbN> All the stuff in fftools, primarily ffmpeg.c and its hw.c [21:31:15 CEST] <JEEB> for specifically vaapi there's a vaapi transcoding example which I have never tried [21:31:18 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/vaapi_transcode.... [21:31:27 CEST] <JEEB> but it seems to use the newer decoding API [21:31:30 CEST] <JEEB> with vaapi [21:35:29 CEST] <jya> JEEB: I'm happy to limit the code to a specific version of ffmpeg. [21:35:52 CEST] <jya> If that can convince people to finally update their machine, I'd be happy [21:36:21 CEST] Action: jya still have Libav 0.8 users with Ubuntu 12.04 [21:36:33 CEST] <JEEB> both the fftools command line tools and the example for vaapi transcoding should contain all the necessary stuff to get rolling with vaapi [21:36:43 CEST] <JEEB> so in that sense BtbN and me have given you the basic pointers :P [21:37:07 CEST] <JEEB> the example is shorter but I give no guarantees for it. you can attempt to compile it and see if it works as expected (it will decode and encode with vaapi) [21:37:12 CEST] <JEEB> and then look at the decoding part :P [21:37:24 CEST] <JEEB> then there's the fftools (ffmpeg.c etc) directory [21:37:32 CEST] <jya> I got a bit confused with the various examples on how to provide the vacontext structure info [21:37:33 CEST] <JEEB> which has the command line app's hwaccel implementation [21:37:39 CEST] <BtbN> I guess the primary issue for Firefox still is that hwdecoders output NV12 and the like? [21:37:48 CEST] <jya> Some example seem to indicate that this is now obsolete [21:38:08 CEST] <BtbN> All that plumbing moved to lavu, into the hwcontext and hwframes APIs [21:38:41 CEST] <JEEB> the example I linked includes hwcontext.h etc [21:38:45 CEST] <jya> Nv12 is not the problem. We are rolling our new webrender compositor. It has a unique shader requirement for all platforms [21:38:58 CEST] <jya> Write a single shader for use on all platforms. [21:39:12 CEST] <jya> And we have Nv12 support on Windows and Mac already [21:39:45 CEST] <JEEB> and it uses av_hwdevice_ctx_create(&hw_device_ctx, AV_HWDEVICE_TYPE_VAAPI, NULL, NULL, 0); [21:39:52 CEST] <JEEB> which I *think* is the newer way? [21:39:53 CEST] <JEEB> :P [21:40:15 CEST] <JEEB> so I would kind of recommend just taking a look at the decoding side of that example [21:40:41 CEST] <JEEB> and then asking more specific questions IFF you hit issues [21:53:44 CEST] <jya> JEEB: will do, thanks. [21:54:44 CEST] <jya> Iirc, in the original version from a vaapi surface Id you could map it to an opengl id. Is that still the case? [21:58:01 CEST] <electrotoscope> Hey, apologies for the newbie question, but what's the process for code posted to the ffmpeg-devel mailing list getting merged into the main code? [21:58:50 CEST] <JEEB> electrotoscope: it gets posted, then hopefully someone notices and has time to look at it [21:59:08 CEST] <JEEB> the patchwork link to the patch can also be ping'd here, and after a few days you can ping the actual patch on the mailing list [22:00:19 CEST] <electrotoscope> So that would be just responding to the thread and saying ping? This is the thread I'm curious about http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245331.html [22:00:37 CEST] <electrotoscope> Don't want to be a nuisance but don't want it to get forgotten [22:03:04 CEST] <JEEB> bumping the version is basically the versions in a library's header [22:03:11 CEST] <JEEB> MAJOR.MINOR.MICRO [22:07:07 CEST] <electrotoscope> Would you say for this I should bump the Micro? [22:08:02 CEST] <JEEB> I don't remember the exact requirements for new features/options but the general documentation for developers should have that :P [22:08:38 CEST] <JEEB> > Depending on the change, you may need to change the version integer. Incrementing the first component means no backward compatibility to previous versions (e.g. removal of a function from the public API). Incrementing the second component means backward compatible change (e.g. addition of a function to the public API or extension of an existing data structure). Incrementing the third component means [22:08:44 CEST] <JEEB> a noteworthy binary compatible change (e.g. encoder bug fix that matters for the decoder). The third component always starts at 100 to distinguish FFmpeg from Libav. [22:08:47 CEST] <JEEB> from https://www.ffmpeg.org/developer.html [22:09:15 CEST] <JEEB> minor is usually done for new formats and codecs [22:11:08 CEST] <electrotoscope> Hmm okay cool cool [22:34:16 CEST] <electrotoscope> How do I find the library's header? like for vf_drawtext.c what would I be changing? [22:34:40 CEST] <JEEB> that's within libavfilter [22:35:05 CEST] <JEEB> and if you look at the list of .h headers there :P [22:35:06 CEST] <JEEB> libavfilter/avfilter.h [22:35:10 CEST] <electrotoscope> oh version.h? okay cool cool [22:35:13 CEST] <JEEB> or wait [22:35:14 CEST] <JEEB> version.h [22:35:18 CEST] <JEEB> yea :P probably that one [22:35:35 CEST] <electrotoscope> makes sense! [22:54:50 CEST] <electrotoscope> Remade patch, hopefully good now! http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245567.html [22:54:51 CEST] <electrotoscope> Thanks!! [23:00:21 CEST] <durandal_1707> jamrial: i'm simply stating facts, you either ignore that or live in your own world [00:00:00 CEST] --- Thu Jun 20 2019