[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