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

[burek]

[00:01:59 CET] <rcombs> well whether you're using that new API or not, you still need to do a malloc at some point
[00:02:50 CET] <rcombs> but I don't see this adding any new per-frame mallocs?
[00:05:27 CET] <kierank> if it's adding more side data it's adding more mallocs
[00:09:24 CET] <rcombs> stream-global side data, though
[00:09:38 CET] <rcombs> not stuff that's allocated on each frame
[00:09:40 CET] <rcombs> just once at init
[00:33:39 CET] <wm4> do the mallocs really hurt you
[00:42:26 CET] <pross> apart from the effort to inspect 264 patches, i guess, no.
[00:45:29 CET] <kierank> wm4: not sure tbh
[00:48:08 CET] <nevcairiel> so far the patches only add one alloc over the entire encoding process
[00:48:20 CET] <nevcairiel> not even per-frame
[00:48:26 CET] <nevcairiel> one global per stream
[00:51:46 CET] <wm4> clearly unacceptable overhead
[00:53:15 CET] <kierank> if a file has captions, afd, 3d crap that's a malloc per frame
[00:53:18 CET] <kierank> if it's interlaced 2x mallocs
[03:14:38 CET] <cone-653> ffmpeg 03Ganesh Ajjanagadde 07master:1bed09a30ef9: swresample: allow double precision beta value for the Kaiser window
[03:20:52 CET] <cone-653> ffmpeg 03Ganesh Ajjanagadde 07master:a5202bc968cf: swresample/resample: improve bessel function accuracy and speed
[10:06:34 CET] <nevcairiel> kierank: those per frame things already exist today, and noone complained yet, so its not exactly adding new things
[10:42:57 CET] <cone-660> ffmpeg 03Paul B Mahol 07master:0cfd4a993f30: avformat/rsd: add XMA support
[10:52:54 CET] <bencoh> 47
[11:42:25 CET] <cone-660> ffmpeg 03Matt Oliver 07master:f98417451291: avutil/x86/intmath: Correct intrinsic headers for older compilers.
[11:46:24 CET] <durandal_1707> 5000th bug!
[11:55:43 CET] <nevcairiel> such a buggy software
[13:15:49 CET] <cone-660> ffmpeg 03Agatha Hu 07master:ddbad1589828: avcodec/nvenc: update nvenc default parameters
[13:37:45 CET] <wm4> nevcairiel: did you say dxva doesn't like it if you destroy the dxva decoder before unreferencing all its surfaces?
[13:42:56 CET] <nevcairiel> Yes
[13:43:13 CET] <nevcairiel> I keep a ref to the decoder for that
[13:43:18 CET] <wm4> that seems illogical... so the best course of action is to refcount the decoder itself?
[13:44:08 CET] <nevcairiel> the decoder is a COM object so its refcounted already, I just increas the count everytime I ref a surface, and decrease it when unrefing the surface
[13:44:14 CET] <nevcairiel> its all in ffmpeg_dxva.c too
[13:44:41 CET] <wm4> it'd be nice if all that code was just in lavc
[13:44:55 CET] <wm4> you know, hwaccel 2.0 and stuff
[13:45:34 CET] <nevcairiel> dunno, surface management can be a bit tricky, so having that in my own code allows me to make decisions that lavc maybe couldnt
[13:46:16 CET] <fritsch> +1
[13:47:31 CET] <wm4> we can always provide a masochist option for those who want to do everything themselves
[13:47:40 CET] <fritsch> it's not that easy
[13:47:52 CET] <fritsch> especially if rendering, zero copy, interop is involved
[13:48:04 CET] <fritsch> one wants to have the influence
[13:48:15 CET] <wm4> like what specifically?
[13:48:24 CET] <fritsch> for example in vdpau
[13:48:33 CET] <fritsch> we allocate them ourselves, interop with renderer
[13:48:46 CET] <fritsch> and are quite happy to manage deletion, reusing and so on ourselves
[13:48:55 CET] <fritsch> same for vaapi
[13:48:57 CET] <wm4> vdpau doesn't require anything special when creating surfaces for interop
[13:49:02 CET] <wm4> same for vaapi
[13:49:34 CET] <fritsch> reconfigure on render would then need to reconfigure decoder
[13:49:40 CET] <wm4> and
[13:49:52 CET] <wm4> actually no
[13:49:54 CET] <wm4> why would it?
[13:50:06 CET] <fritsch> when the target surfaces, if scaling is involved change
[13:50:17 CET] <wm4> ?
[13:50:31 CET] <wm4> what has scaling have to do with this
[13:50:38 CET] <rcombs> speaking of hardware stuff, anyone else wanna poke at lavc and lavfi APIs for all-hardware transcode pipelines
[13:51:41 CET] <rcombs> I originally picked RPi MMAL as the first implementation to work on because the APIs are reasonably high-level, but I'm falling into a bunch of weird cases where they don't work properly for undocumented reasons without useful logs
[13:53:06 CET] <rcombs> https://github.com/rcombs/FFmpeg/tree/mmalenc fun stuff
[13:54:56 CET] <fritsch> wm4: think of multiple vdpau / vaapi threads that do postprocecssing / deinterlacing on different thread - all point to allocated surfaces
[13:55:21 CET] <wm4> fritsch: but surfaces are always refcounted in lavc, so there's no problem
[13:56:37 CET] <fritsch> this also works for "interoped" surfaces?
[13:56:54 CET] <fritsch> yeah, obviously  - if you still have a ptr to the original one
[13:57:37 CET] <fritsch> need to think over it - all our videocodecs manage the surfaces themselves
[13:58:28 CET] <wm4> so what do you do if a decoder needs to be destroyed or reinitialized, while a frame is still displayed or in the filter chain?
[14:05:32 CET] <fritsch> render is flushed, all frames not yet displayed are skipped
[14:05:44 CET] <wm4> doesn't seem ideal
[14:06:06 CET] <fritsch> why not? - we have a renderqueue - with ~ 5 frames in there
[14:06:36 CET] <fritsch> what would you do?
[14:06:42 CET] <wm4> and they get dropped?
[14:06:51 CET] <fritsch> they are not displayed anymore
[14:06:55 CET] <fritsch> removed from renderqueue
[14:07:08 CET] <wm4> in my code, the renderer doesn't have to care at all what happens to the decoder
[14:07:22 CET] <fritsch> but when you interop
[14:07:26 CET] <fritsch> the surface is just gone
[14:07:28 CET] <fritsch> that moment
[14:07:33 CET] <wm4> the renderer gets refcounted frames that remain valid until it unrefs them, the end
[14:07:38 CET] <fritsch> okay
[14:07:41 CET] <fritsch> that works
[14:08:57 CET] <fritsch> so
[14:09:08 CET] <fritsch> in case of vdpau / vaapi
[14:09:23 CET] <fritsch> ffmpeg would keep the context open as long as the last surface is destroyed?
[14:09:26 CET] <fritsch> right?
[14:09:43 CET] <fritsch> so - then you have your issue - there is hw out there that can only open a single hw decoding context at a time
[14:09:53 CET] <fritsch> the Pi, old AMD gpus
[14:10:02 CET] <wm4> I never talked about having ffmpeg create the context
[14:10:13 CET] <wm4> wait
[14:10:19 CET] <wm4> depends what context we're talking about
[14:10:27 CET] <fritsch> but it needs the context to destroy these surfaces
[14:10:29 CET] <wm4> the decoder, or the hw API context itself
[14:11:38 CET] <fritsch> dl_vdp_device_create_x11
[14:11:43 CET] <fritsch> this one for vdpau for example
[14:12:27 CET] <wm4> that still has to be created by the API user of course
[14:24:28 CET] <BtbN> What the hell is up with that waressearcher2 in #ffmpeg?
[14:24:56 CET] <fritsch> he is going on your nerves?
[14:25:04 CET] <fritsch> the name alone is going on my nerves
[14:26:05 CET] <BtbN> He keeps trying to smalltalk talk with random people, in german. Since a few weeks
[14:27:59 CET] <fritsch> hehe
[14:28:04 CET] <fritsch> a bot perhaps?
[14:28:41 CET] <fritsch> some research project and the student providing the english translation was not finished in time?
[14:36:30 CET] <ubitux> 2015-09-24 22:19:10     waressearcher2  Zenk_BR: your inglish is allright
[14:36:41 CET] <ubitux> 2015-09-27 23:06:55     waressearcher2  Dexstarrrr: I need money but I have no idea what qsv is
[14:36:51 CET] <ubitux> ok i'm stopping the grep for now
[14:37:12 CET] <fritsch> lol
[15:06:41 CET] <fritsch> BtbN: I see
[15:06:43 CET] <fritsch> :-)
[16:50:19 CET] <ubitux> ok, async proto working; trying to see how it fits with seeking and i'll submit
[16:50:28 CET] <ubitux> most likely first draft/rfc tmr
[16:50:48 CET] <wm4> what has seeking to do with it?
[16:51:27 CET] <ubitux> it's more like an high level api; so i need to see how it's going to fit with flushing etc
[19:59:26 CET] <ubitux> michaelni: didn't you add some avopt sanity checks somewhere not that long ago?
[20:54:52 CET] <durandal_1707> can somebody review wav patches?
[22:04:33 CET] <cone-516> ffmpeg 03Bryan Huh 07master:72f9a6349cae: avformat/cache: Avoid int-overflow in cache compare function
[22:12:01 CET] <michaelni> atomnuker, as you are maintainer you should have OP here
[22:13:14 CET] <michaelni> btw, there are some aac patches on ffmpeg-devel from andreas, i think you and claudio know aac best to review these (in some cases theres the question of what range of values is valid
[22:13:49 CET] <michaelni> that is what to reject and what is ok, allowing any value seem to cause problems with fuzzed files
[23:59:09 CET] <cone-516> ffmpeg 03Simon Thelen 07master:70fb5eadc580: ffmpeg: Don't try and write sdp info if none of the outputs had an rtp format.
[23:59:10 CET] <cone-516> ffmpeg 03Simon Thelen 07master:b02201efb531: doc/ffmpeg: Clarify that the sdp_file option requires an rtp output.
[00:00:00 CET] --- Tue Nov 10 2015