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

[burek]

[01:45:25 CEST] <rcombs> Dmitri_Ovch: hmm, have you tried using the OpenCL integration? it looks like that has better support for passing in GPU-side buffers
[01:45:43 CEST] <rcombs> i.e. AV_PIX_FMT_OPENCL
[01:46:31 CEST] <rcombs> also, in either case, how does device selection work?
[01:47:08 CEST] <rcombs> looks like it's just letting the library pick a default? (which is probably fine for most cases I suppose)
[01:48:37 CEST] <rcombs> or, hmm, there is a CreateSurfaceFromVulkanNative function, but there's no AV_PIX_FMT_VULKAN yet
[08:27:50 CEST] <cehoyos> Good morning
[08:28:04 CEST] <cehoyos> Who else had a lovely chat with a lady from Berlin - in English?
[08:53:24 CEST] <akravchenko188> rcombs: AV_PIX_FMT_OPENCL  is planned to support soon. since we submit this change. hopefully this will not take a lots of time
[08:54:58 CEST] <akravchenko188> rcombs: device selection in case of incoming  host buffers is also planned in different commit
[08:55:21 CEST] <rcombs> fair enough, looking forward to seeing those
[08:57:02 CEST] <akravchenko188> since FFmpeg does not have hwcontext_vulkan, vulkan is used internaly in amf uploading from Host to Vulkan surface
[08:58:12 CEST] <akravchenko188> when hwcontext_vulkan is implemented, we could implement full hw pipeline with AV_PIX_FMT_VULKAN
[08:58:36 CEST] <akravchenko188> probably there should be interop between opencl and vulkan, didnt investigated yet
[09:18:29 CEST] <thilo>   cehoyos: uuuh, Berlin is yet another location on the list
[10:22:35 CEST] <cone-170> ffmpeg 03Michael Niedermayer 07master:00ed04d61496: avformat/ifv: Check for EOF in read_index()
[10:22:35 CEST] <cone-170> ffmpeg 03Shiyou Yin 07master:153c60752558: avutil/mips: refactor msa load and store macros.
[12:04:22 CEST] <jdarnley> I see Big Brother shills are out in force in order to dissuade people from using PGP
[12:04:47 CEST] <jdarnley> They have reminded my that my key expires next year.
[12:09:10 CEST] <rburton> getting  qdm2_tablegen.c:(.text+0x36a): undefined reference to `avpriv_request_sample' when building 4.1.4 , 4.1.3 worked.  any ideas?
[12:27:22 CEST] <mkver> Do you use hardcoded tables?
[12:32:16 CEST] <mkver> c8232e50074f6f9f9b0674d0a5433f49d73a4e50 should probably be backported.
[13:29:43 CEST] <rburton> yes, we do!
[13:29:52 CEST] <rburton> i'm just drive-by upgrading, what does that mean? :)
[13:30:04 CEST] <rburton> ah, mkver left
[14:45:49 CEST] <Lynne> rburton: why are you using hardcoded tables?
[15:18:19 CEST] <jdarnley> I wonder how much work it is to replace the "parser" used in expressions with an actual parser, Lua maybe.
[15:54:03 CEST] <whitestone> hello, i am ffmpeg user, i want to know something about the HLS demuxer, i know this is not the channel, but i am searching this info in google and i dont find a lot and in the users channel it looks like no one knows a lot about this demuxer
[17:33:31 CEST] <rburton> Lynne: reading up, dunno.  i can turn that off :)
[17:42:45 CEST] <Lynne> yeah, you should, its not really used anywhere anymore but the mp3 decoder and a few others to generate a few hundred odd floats
[18:23:25 CEST] <JEEB> wbs: since you're the fragmented movenc person - adjusting all packet timestamps to the end of previous fragment or generating an empty sample at the beginning of a fragment to keep the fragment pts continuous?
[18:25:58 CEST] <wbs> JEEB: we do (at least my original code in libav) adjust the first timestamp of a fragment to the guessed end of the previpus
[18:27:43 CEST] <wbs> JEEB: if you know better than what the code guesses, set pkt_duration of the last packet in the prev fragment
[18:34:50 CEST] <wbs> JEEB: although I guess the proper meaning of pkt_duration is from this pts to the next after reordering, but movenc iirc treats it as duration until the next dts
[18:38:40 CEST] <JEEB> wbs: yea, frag_start is ok
[18:40:17 CEST] <JEEB> i just am trying ro think of the least bad way of doing the crap that says one sample per fragment, and i think the spec says that the single sample starts at the fragment start
[18:40:54 CEST] <JEEB> so do I either start wryyy'ing the packet timestamps, or do I add an empty sample in the beginning
[18:41:40 CEST] <JEEB> so that the second sample is then the starting packet
[18:42:13 CEST] <JEEB> of  ourse that means I hope the place i am pushing this crap properly parses multipöe samples in a single fragment
[18:42:56 CEST] <JEEB> since the sample then contains subtitles timed after the start of sample
[18:44:47 CEST] <wbs> JEEB: ah, subs... the current code isn't written with that in mind no
[19:02:12 CEST] <JEEB> wbs: funny enough I think mov_text might more or less be working because it adds extra samples at the end of the segment I think?
[19:02:29 CEST] <JEEB> although not sure how that works when you don't know the required time until the next fragment
[19:02:50 CEST] <JEEB> I did quickly test and mov_text results seemed kind of sane
[19:03:28 CEST] <JEEB> wbs: also I wonder if it's simpler to just limit every sample into its own fragment instead of trying to buffer them until fragment flush
[19:03:51 CEST] <JEEB> which would mean a fragment per subtitle sample, but at that point we're anyways getting enough overhead :P
[22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:ed4c6ce750cf: tools/target_dem_fuzzer: ignore avformat_find_stream_info() failure
[22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:c5f265bb2468: avcodec/atrac9dec: Check conditions before apply_band_extension() to avoid out of array read in initialization of unused variables
[22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:b789ebf681ea: avcodec/h264_cavlc: Fix integer overflows with motion vector residual addition
[22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:7d3581e6bbec: avcodec/h264_refs: Also check reference in ff_h264_build_ref_list()
[22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:6ebbfb377f7b: avcodec/agm: Fix overflow of signed shift
[22:51:34 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:5c46fdf305ca: avformat/utils: Check rfps_duration_sum for overflow
[22:51:35 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:76af425159cf: avcodec/flashsv: add FF_CODEC_CAP_INIT_CLEANUP to flashsv1
[22:51:35 CEST] <cone-407> ffmpeg 03Michael Niedermayer 07master:1123331f59d3: avcodec/flashsv: add FF_CODEC_CAP_INIT_CLEANUP to flashsv2
[00:00:00 CEST] --- Sat Jul 20 2019