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

[burek]

[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.c;h=279d20f636f02b31a40d10bea723e905181709b9;hb=HEAD
[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