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

[burek]

[00:34:56 CET] <J_Darnley> How can I make a feature request for the fate website?
[00:35:21 CET] <J_Darnley> I would like to suggest a link from a report page to the slot to which it belongs.
[00:37:51 CET] <cone-897> ffmpeg 03Carl Eugen Hoyos 07master:9bc281beae6d: lavf/icodec: Improve autodetection.
[00:40:53 CET] <jamrial> J_Darnley: Timothy_Gu was making changes to it. check http://fatebeta.ffmpeg.org/
[00:41:10 CET] Action: J_Darnley nods
[02:58:52 CET] <BBB> Gramner: why is it UNIX64 * 3 + 5 instead of 5 + UNIX64 * 2?
[02:59:06 CET] <BBB> Gramner: Im sure it works, I just thought win64 had 4 regs and unix64 6, not 7
[03:53:51 CET] <cone-852> ffmpeg 03Michael Niedermayer 07master:89f464e9c229: avcodec/tiff: Check subsample & rps values more completely
[04:16:17 CET] <Gramner> BBB: rax i used as an implicit value-passing register in some cases
[09:00:02 CET] <rcombs> are we going to remove vo-aacenc now that the native encoder is decidedly better and out of experimental
[10:42:33 CET] <cone-828> ffmpeg 03Paul B Mahol 07master:bb2f8bdeca93: doc/filters: add yet another fftfilt example
[11:09:33 CET] <durandal_1707> michaelni: can I get comments on afftfilt?
[11:34:27 CET] <wm4> ubitux: who is supposed to free AVCodecContext.subtitle_header?
[11:34:34 CET] <wm4> the user? even though avcodec set it?
[11:39:59 CET] <nevcairiel> wm4: just use avcodec_free_context and stop worrying
[11:40:40 CET] <wm4> ah, this function exists... ok then
[11:41:02 CET] <nevcairiel> before it existed contexts had no free function, so there was no choice but have the user free stuff
[11:42:26 CET] <jkqxz> Hi.  I'm one of those crazy people writing vaapi encoders.
[11:42:56 CET] <wm4> hi crazy person
[11:43:02 CET] <jkqxz> I was somewhat bemused by the immediate focus on what was, from my point of view, a mostly uninteresting part of the patch (context initialisation/communication), to the exclusion of everything else.
[11:43:09 CET] <wm4> (but you got to be crazy, since apparently vaapi's encode API is insane)
[11:43:33 CET] <jkqxz> But I can see that from an infrastructure point of that is the important thing to get right at the beginning before accepting anything else, so fair enough.
[11:43:41 CET] <wm4> jkqxz: isn't that just the bikeshedding effect
[11:43:55 CET] <wm4> it's very hard to verify whether the encoder itself is correct
[11:43:57 CET] <kierank> how many hwaccel apis do we need
[11:43:59 CET] <jkqxz> Probably, but I didn't want to accuse people of that...
[11:44:19 CET] <wm4> but many wanted to have hwaccel filtering in libavfilter, and none of them got the "no global state" part right
[11:44:41 CET] <wm4> kierank: you should ask how many APIs does intel need
[11:45:22 CET] <jkqxz> Is there going to be any answer for the hardware context in libav* which people find acceptable beyond "let the user deal with it"?
[11:46:39 CET] <wm4> "let the user deal with it" is the right approach, which means ffmpeg_vaapi.c will have to explicitly set the context on the AVCodecContext etc.
[11:47:05 CET] <wm4> also, while we're at it, Libav also has pending patches for a relatively similar thing, I think
[11:47:09 CET] <nevcairiel> we will just never find global state acceptable, if that isnt involved, we might find it acceptable
[11:47:56 CET] <nevcairiel> but since we dont have a "global" context to replace global state, that comes down to having the user app keep track of that to some degree
[11:51:12 CET] <wm4> jkqxz: this is also an API issue, and once public APIs are added, they're very hard to fix
[11:51:27 CET] <wm4> as opposed to, say, a bug in the vaapi bitstream writing
[11:52:48 CET] <jkqxz> Yeah, that's why I was trying to say "I don't really want this to be a public API" about the libavutil parts.  It just ended up as that in libavutil because it had to be used by both libavcodec and libavfilter.
[11:54:25 CET] <jkqxz> Ok, I can move the particularly nasty parts in the ffmpeg driver (and get the user to do it).
[11:54:40 CET] <jkqxz> (The global state around connections, that is.)
[11:55:31 CET] <wm4> ffmpeg.c is its own program and not a library, so global state is perfectly acceptable there
[11:59:44 CET] <jkqxz> So, threading issues.  Would it be sensible for the context provided by the user to include lock/unlock function pointers to get rid of that problem too?  (Or null to say that whatever it is has exclusive access, I guess.)
[12:01:12 CET] <wm4> yeah
[12:01:47 CET] <wm4> I'm not sure about the state of libva thread-safety, but I seem to remember that at least some drivers needed it
[12:14:46 CET] <jkqxz> It's entirely delegated to the driver from libva, and the drivers seem highly ambivalent about it.  Locking here is just safer, I think.
[12:16:09 CET] <wm4> I also think that, although it's regretable having to expose this as API to the user
[12:25:50 CET] <jkqxz> It works for forward compatibility.  If it becomes a nonissue in future versions then those fields can just be zero/ignored.
[12:29:04 CET] <jkqxz> Backward compatibility is a problem, though, because the existing decoder context does not have these fields.  What changes are acceptable there?
[12:45:11 CET] <wm4> jkqxz: generally, you can add new fields at the right place
[12:45:28 CET] <wm4> the right place is at the end of the struct, or if there are fields marked as internal at the end, before the first internal field
[12:45:59 CET] <wm4> jkqxz: you should also look at the Libav patches
[12:51:45 CET] <jkqxz> I assume you're referring to the set beginning <https://lists.libav.org/pipermail/libav-devel/2016-January/074082.html>?
[12:53:16 CET] <jkqxz> How do you know how big the struct the user allocated was, and therefore whether the new members you added are even present?  (For ABI compatibility, not API.)
[12:58:33 CET] <wm4> jkqxz: yes, those patches
[12:58:40 CET] <jkqxz> Parts 1-3 of that patch are already present in ffmpeg.  Part 4 is a rename and adding an alloc function to avoid exactly the size problem I just stated.  Hmm.
[12:58:49 CET] <wm4> yeah
[12:59:03 CET] <wm4> it's not possible, so an alloc function is needed
[12:59:24 CET] <wm4> which is annoying, I think this was done at least 2 or 3 times before for other hwaccels
[13:02:22 CET] <durandal_1707> ubitux: I managed to get other inputs from streamselect, just not when also using audio, it doesn't make sense to me, I'm using framesync
[13:05:16 CET] <jkqxz> So you'd like av_hwaccel_alloc_context(enum type)?
[13:09:16 CET] <wm4> jkqxz: personally I'd probably prefer it, but the Libav discussion seemed to go into direction of keeping the individual alloc functions
[13:57:09 CET] <jkqxz> So: add a new member "void *(*alloc_context)(void)" to AVHWAccel, then add "void *av_hwaccel_alloc_context(enum AVCodecID codec_id, enum AVPixelFormat pix_fmt)" (in avcodec/utils.c?) which walks the hwaccel list and calls the right one.
[13:58:29 CET] <jkqxz> Then update all existing hwaccels to have that, which either calls their own custom allocation function or is a stub new one just returning av_mallocz(sizeof(context)).
[13:59:43 CET] <jkqxz> Would a patch to that effect be entertained?  (The specific allocation function still works if it already existed.)
[14:08:20 CET] <wm4> jkqxz: personally, I'd wait until Libav has pushed the new alloc context API, and then use that... or if you don't want to wait, I can ask them whether they can accelerate it, and/or we apply the patch just to ffmpeg
[14:08:48 CET] <wm4> the main thing is that ffmpeg and Libav should have the same API
[14:11:47 CET] <jkqxz> The discussion there didn't look very conclusive.
[14:59:29 CET] <wm4> so if libswresample converts 7.1 to 7.1(wide), should it really replace the SL/SR pair with silence?
[15:16:49 CET] <cone-294> ffmpeg 03Mats Peterson 07master:5da1477fa01b: lavc/rawdec: Use AV_PIX_FMT_PAL8 for 1-bit raw QuickTime video
[15:31:48 CET] <durandal_1707> michaelni: what can be done if complex expr is different from real one?
[15:53:43 CET] <michaelni> durandal_1707, complex coefficients would allow changing phase for example
[16:04:01 CET] <BBB> michaelni: can you review the videodsp patch?
[16:53:05 CET] <BBB> ty
[17:02:33 CET] <michaelni> np
[17:27:19 CET] <cone-294> ffmpeg 03Ronald S. Bultje 07master:0f88b3f82faf: videodsp: fix 1-byte overread in top/bottom READ_NUM_BYTES iterations.
[18:35:19 CET] <Daemon404> nevcairiel, where are your mingw builds located?
[19:40:56 CET] <cone-294> ffmpeg 03Paul B Mahol 07master:4e17efd852bd: avfilter/avf_showfreqs/showspectrum: rename skip_samples to hop_size
[19:54:47 CET] <durandal_1707> can filter call avfilter_config_links?
[19:55:10 CET] <nevcairiel> Daemon404: https://files.1f0.de/mingw/
[19:58:43 CET] <cone-294> ffmpeg 03Michael Niedermayer 07master:3ef5de0f1977: avcodec/put_bits: Assert buf_ptr in flush_put_bits()
[19:58:44 CET] <cone-294> ffmpeg 03Michael Niedermayer 07master:03d83ba34b20: avcodec/gif: Fix lzw buffer size
[20:02:06 CET] <Daemon404> nevcairiel, ok
[20:02:08 CET] <Daemon404> thx
[21:17:38 CET] <tmm1> wm4: squashed and rebased my closed caps PR
[22:27:13 CET] <fritsch> nevcairiel:  http://we.tl/1E13wA4YJW <- any interest in a sample with dolby digital plus including atmos bits?
[22:27:23 CET] <fritsch> nevcairiel: first one is truehd with atmos bits
[22:27:36 CET] <fritsch> the german and french track "should be" ddd+ and atmos additions
[22:27:56 CET] <fritsch> tunneled via some "reserved data" in eac3 format
[22:39:51 CET] <durandal_1707> atmos is not allowed to be decoded by other software
[22:40:35 CET] <durandal_1707> I don't want to be sued/go to jail
[00:00:00 CET] --- Tue Jan 19 2016