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

[burek]

[07:28:50 CEST] <cone-553> ffmpeg 03Steven Liu 07master:bd8a5c6b7ce7: avformat/hlsenc: improve compute after_init_list_dur
[10:16:00 CEST] <thardin> hm no baptiste
[11:23:32 CEST] <gagandeep> related to frame_threading: ff_thread_await_progress() only allows execution to start once 'all the previous threads' that had to use ff_thread_report_progress have reported the required progress number
[11:24:23 CEST] <gagandeep> also the earlier threads that don't use report_progress for that same number are not considered for waiting?
[11:24:46 CEST] <gagandeep> same number = progress int in report and await progress
[11:26:21 CEST] <nevcairiel> every thread should always report progress when you use that model
[11:26:40 CEST] <nevcairiel> and if its only a final progress report when its entirely done with the frame
[11:27:09 CEST] <nevcairiel> although for performance its better to do it more fine-grained
[11:28:32 CEST] <gagandeep> thanks, also for communicating buffer info b/w threads i need to use update_thread_context, or any other way?
[11:29:31 CEST] <gagandeep> cause one thread in cfhd gets all the coefficients and i need to use 2nd thread to make it actually do something
[11:32:48 CEST] <gagandeep> buffer in this case is NOT AVBuffer, but av_malloc buffer used to hold coefficients
[13:01:22 CEST] <kierank> https://sorting.cr.yp.to/
[14:04:28 CEST] <memeka> hi ...
[14:05:04 CEST] <memeka> when having decoder -> filter ... is it possible to know in the decoder that its output will go through a specific filter?
[14:06:04 CEST] <memeka> or to access decoder->priv in the filter?
[14:13:02 CEST] <cone-553> ffmpeg 03Jun Zhao 07master:09628cb1b4cc: avutil/pixelutils: correct the function name in comments
[14:21:58 CEST] <nevcairiel> no thats not possible
[14:22:05 CEST] <nevcairiel> those components are all separate
[14:25:18 CEST] <memeka> nevcairiel: is there a way then to "signal" between them?
[14:25:52 CEST] <nevcairiel> a tight coupling between such components is probably not a good idea in general
[14:26:04 CEST] <memeka> nevcairiel: i want to do dmabuf between decoder and filter, so I need the filter to signal the decoder to export dmabuf ....
[14:26:28 CEST] <nevcairiel> the filter does not control that, the outer layer (ie. the user) would indicate this
[14:27:02 CEST] <memeka> nevcairiel: indicate it to the decoder?
[14:27:46 CEST] <nevcairiel> yes
[14:27:54 CEST] <memeka> can't it be done using AVPixelFormat?
[14:28:26 CEST] <nevcairiel> thats how it is done, but filters cant tell decoders the format they want, decoders always deliver the format they have
[14:29:14 CEST] <memeka> is there a way then for the decoder to know a filter is being used?
[14:29:25 CEST] <nevcairiel> no
[14:29:34 CEST] <nevcairiel> the user is responsible for setting this up
[14:29:40 CEST] <nevcairiel> the filter and the decoder cannot talk to each other
[14:30:24 CEST] <memeka> thx 
[14:35:13 CEST] <atomnuker> yep, the user can specify what output pixel format to use for decoding as well as filtering
[14:37:53 CEST] <atomnuker> memeka: tbh I really think v4l decoders should always output dmabufs
[14:38:28 CEST] <atomnuker> you can easily download them without going through lavfi if you want them to
[14:38:57 CEST] <atomnuker> and on the devices that v4l decoders are available you don't have the speed needed to do operations on raw frames in ram
[14:39:35 CEST] <memeka> atomnuker: i wonder, is it better then to have a filter that outputs the buffers?
[14:39:46 CEST] <atomnuker> what?
[14:39:54 CEST] <atomnuker> go system ram -> filter -> dmabuf?
[14:40:02 CEST] <memeka> so the decoder is always dmabuf, and then there is a filter that takes in a dmabuf and gives you the content
[14:40:17 CEST] <memeka> if you want it
[14:40:37 CEST] <atomnuker> there's already a filter to get you a raw buffer in ram, its called hwdownload
[14:41:05 CEST] <memeka> right...
[14:41:36 CEST] <atomnuker> but we can't break behavior, by default hardware decoders decode to system ram
[14:42:07 CEST] <atomnuker> using the command line you need to force them if you want to get a native zero-copy frame in device memory via -hwaccel_output_format <format>
[14:42:50 CEST] <atomnuker> so what the decoder needs to do is detect whether the format is drmprime and if so output dmabufs
[14:42:50 CEST] <memeka> how does the hardware decoder knows that?
[14:43:28 CEST] <nevcairiel> it would call get_format2 and get told
[14:43:36 CEST] <memeka> hmmm is there a way to activate a filter automatically?
[14:44:15 CEST] <atomnuker> if you want to download a frame in the decoder to system ram you can use lavu's hwcontext functions
[14:44:22 CEST] <atomnuker> no need for a filter
[14:44:36 CEST] <memeka> atomnuker: i am thinking of v4l2 hardware scaler
[14:44:50 CEST] <atomnuker> absolutely no filters in lavc, thank you very much
[14:44:55 CEST] <memeka> so you get the drmprime, you do scaling, then send another drmprime
[14:45:25 CEST] <jdarnley> Aren't there already some HW scalers you can steal from to do that?
[14:45:45 CEST] <atomnuker> yep, plenty, libavfilter/vf_scale_(vaapi/cuda/qsv).c
[14:45:53 CEST] <memeka> would they be activated automatically on DRMPRIME ?
[14:46:02 CEST] <nevcairiel> no
[14:46:36 CEST] <atomnuker> you need to add any and all hardware filters manually
[14:46:37 CEST] <nevcairiel> zero-copy hardware chains require the user to properly set it up
[14:46:40 CEST] <nevcairiel> for all hardware variants
[14:47:18 CEST] <jdarnley> Here the user means either the user of the command line or the user of the libraries.
[14:47:31 CEST] <memeka> yeah i understand
[14:47:44 CEST] <memeka> so you can't make it invisible ....
[14:49:52 CEST] <jdarnley> Invisible to whom?  You can probably hide it all from the end user by making your program smart enough.
[14:51:51 CEST] <memeka> jdarnley: invisible to existing software :)
[14:52:18 CEST] <nevcairiel> proper hardware usage does require software aware of it
[14:54:56 CEST] <atomnuker> yep, with very good reason - downloading and uploading is very expensive generally, so that's definitely not something that can be done without the API user's knowledge
[00:00:00 CEST] --- Thu Jul 12 2018