#ffmpeg-devel on 2025-04-15 — irc logs at libera.irclog.whitequark.org

2025-03-03 01:04 michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct

00:07 Sean_McG has quit [Ping timeout: 245 seconds]

00:10 ahmedhamed has quit [Quit: Connection closed for inactivity]

00:25 Traneptora has joined #ffmpeg-devel

00:26 abdu has quit [Quit: Client closed]

00:28 Traneptora has quit [Client Quit]

00:37 thilo has quit [Ping timeout: 272 seconds]

00:39 thilo has joined #ffmpeg-devel

00:39 thilo has quit [Changing host]

00:39 thilo has joined #ffmpeg-devel

01:04 <jamrial> mkver: we could also remove the av prefix from this api namespace, since it's CLI only

01:04 <mkver> yeah

01:19 ppa_csharp has joined #ffmpeg-devel

01:20 ppa_csharp has quit [Client Quit]

01:23 mkver has quit [Ping timeout: 276 seconds]

01:24 jamrial_ has joined #ffmpeg-devel

01:25 kekePower7 has joined #ffmpeg-devel

01:27 jkhsjdhjs_ has joined #ffmpeg-devel

01:27 jkqxz_ has joined #ffmpeg-devel

01:29 JEEB_ has joined #ffmpeg-devel

01:34 markh has quit [*.net *.split]

01:34 jamrial has quit [*.net *.split]

01:34 microchip_ has quit [*.net *.split]

01:34 jkhsjdhjs has quit [*.net *.split]

01:34 sm2n has quit [*.net *.split]

01:34 psykose has quit [*.net *.split]

01:34 BradleyS has quit [*.net *.split]

01:34 witchymary has quit [*.net *.split]

01:34 odrling has quit [*.net *.split]

01:34 uau has quit [*.net *.split]

01:34 Lynne has quit [*.net *.split]

01:34 JEEB has quit [*.net *.split]

01:34 jkqxz has quit [*.net *.split]

01:34 kekePower has quit [*.net *.split]

01:34 kekePower7 is now known as kekePower

01:34 jkhsjdhjs_ is now known as jkhsjdhjs

01:57 Anthony_ZO has joined #ffmpeg-devel

02:11 markh has joined #ffmpeg-devel

02:11 microchip_ has joined #ffmpeg-devel

02:11 sm2n has joined #ffmpeg-devel

02:11 psykose has joined #ffmpeg-devel

02:11 BradleyS has joined #ffmpeg-devel

02:11 witchymary has joined #ffmpeg-devel

02:11 odrling has joined #ffmpeg-devel

02:11 uau has joined #ffmpeg-devel

02:11 Lynne has joined #ffmpeg-devel

02:26 minimal has quit [Quit: Leaving]

02:27 kasper93 has quit [Quit: kasper93]

02:28 kasper93 has joined #ffmpeg-devel

02:59 compn has quit [Read error: Connection reset by peer]

02:59 compn has joined #ffmpeg-devel

03:09 grillo_02 has joined #ffmpeg-devel

03:10 grillo_0 has quit [Ping timeout: 272 seconds]

03:10 grillo_02 is now known as grillo_0

03:13 usagi_mimi has quit [Quit: WeeChat 4.5.2]

03:24 jamrial_ has quit []

03:56 aaabbb has quit [Changing host]

03:56 aaabbb has joined #ffmpeg-devel

05:14 Guest44 has joined #ffmpeg-devel

05:16 <Guest44> Hello, I found mpeg file can call av_seek_frame success, but av_read_frame will always return EOF, is it a bug?

05:17 <Guest44> should i send email to ffmpeg-dev or libav?

05:24 <aaabbb> https://ffmpeg.org/bugreports.html

05:24 <aaabbb> bug tracker is the simplest

06:19 <fflogger> [newticket] honglongyu: Ticket #11546 ([avcodec] mjpeg file call av_read_frame return EOF after seek) created https://trac.ffmpeg.org/ticket/11546

06:20 DodoGTA has quit [Read error: Connection reset by peer]

06:41 JEEB_ is now known as JEEB

06:57 System_Error has quit [Ping timeout: 264 seconds]

07:16 System_Error has joined #ffmpeg-devel

07:41 ngaullier has joined #ffmpeg-devel

07:42 ngaullier has quit [Remote host closed the connection]

07:44 ngaullier has joined #ffmpeg-devel

07:50 ngaullier has quit [Remote host closed the connection]

07:52 <fflogger> [editedticket] fildens: Ticket #11430 ([avformat] [Regression] Data stream in output may glitch "-stats" display since 7.0) updated https://trac.ffmpeg.org/ticket/11430#comment:15

07:52 ngaullier has joined #ffmpeg-devel

08:35 mkver has joined #ffmpeg-devel

08:57 DodoGTA has joined #ffmpeg-devel

09:12 dim^ has quit [Quit: leaving]

09:34 j45_ has joined #ffmpeg-devel

09:34 j45 has quit [Read error: Connection reset by peer]

09:34 j45_ is now known as j45

09:34 j45 has joined #ffmpeg-devel

09:34 j45 has quit [Changing host]

10:02 OctopusET has quit [Ping timeout: 248 seconds]

10:02 OctopusET has joined #ffmpeg-devel

10:24 mkver has quit [Ping timeout: 265 seconds]

10:28 abdu has joined #ffmpeg-devel

10:32 mkver has joined #ffmpeg-devel

10:33 TheVibeCoder has joined #ffmpeg-devel

10:34 <TheVibeCoder> Lynne: the braw is not bayer at all, its some subsamples rgb/yuv variant

10:34 <Lynne> nope, braw is 100% bayer

10:34 <TheVibeCoder> how so?

10:35 <Lynne> it's the ONLY '''raw''' format out there which keeps its bayer tiling

10:36 <Lynne> rest of cinema gear, except arrirraw and cinemadng does some variant of yuv conversion in camera and relies on LUTs

10:36 <Lynne> (so does braw, there's a massive lut embedded in the mov we don't yet parse, but less so)

10:38 <TheVibeCoder> if its is bayer, so it always uses same pattern? what you see when you zoom in with debayered output?

10:39 <TheVibeCoder> in prores raw i clearly see bayer pattern and data is not subsampled

10:39 <TheVibeCoder> in braw, if its really bayer its magic

10:41 <Lynne> https://files.lynne.ee/braw.png

10:41 <Lynne> looks fine after debayering

10:44 <TheVibeCoder> can you share single frame of this in braw format?

10:46 <Lynne> yeah, give me a moment to find the source

10:46 <TheVibeCoder> want to compare output to the gbrp12 decoder

10:48 <Lynne> https://files.lynne.ee/A001_07200146_C483.braw

10:49 <TheVibeCoder> half of 1 gb

10:49 <TheVibeCoder> do i need to pay for traffic?

10:51 <Lynne> are you on a metered connection?

10:52 <TheVibeCoder> asking for you, my side can fetch TBs and more

10:52 <TheVibeCoder> anyway its too late...

10:52 <Lynne> I hardly get any traffic

10:55 <TheVibeCoder> https://0x0.st/8fOz.png

10:56 <TheVibeCoder> this is gbrp12 decoder (librempeg) with -vf exposure=2 filter

10:58 <TheVibeCoder> there is still small green tint (because of BRAW hidden color stuff)

10:59 <Lynne> its definitely bayer

11:01 <TheVibeCoder> also watch for banding and overflow/folding of values, because i couldnt dechiper all binary stuff, also there is newer bitstream, with different coefficients/coding I never got to implement/RE

11:02 Guest44 has quit [Quit: Client closed]

11:03 <Lynne> I'm not sure it's bayer

11:03 <Lynne> they keep talking about partial debayering

11:03 <TheVibeCoder> i never was, prores raw is really bayer, and DNG-TIFF with extra stuff (its special lossless jpeg coding...)

11:05 <Lynne> i?

11:05 <TheVibeCoder> there is also patent to read, but it probably have more unknowns than it reveal new thinigs

11:06 <Lynne> what does braw do that isn't bayer?

11:06 <TheVibeCoder> that decorrelate chunk

11:06 <TheVibeCoder> prores raw does not have it

11:09 <TheVibeCoder> https://github.com/librempeg/librempeg/blob/master/libavcodec/braw.c#L376 also here, but it outputs directly to gbrp12

11:09 <TheVibeCoder> that part is speculation, by interpreting patent

11:10 <TheVibeCoder> they probably do correlating thing inside camera....

11:12 <TheVibeCoder> there would not be need for that if all 4 components are of same size when doing IDCT

11:12 <TheVibeCoder> but in BRAW, there is 2 IDCT of 8x8

11:12 <TheVibeCoder> and 2 IDCT of 8x4

11:12 <haasn> how the heck is vfmadd slower than vmulps + vaddps as two separate istructions

11:13 <TheVibeCoder> amd or intel?

11:16 <Lynne> haasn: fma is very sensitive to latency

11:16 <Lynne> mul+add can be pipelined, but fma is a single uop

11:19 <haasn> TheVibeCoder: ryzen 9

11:22 <TheVibeCoder> yea, latency is the thing, it will need to wait more

11:22 <TheVibeCoder> but perhaps there is way to avoid that?

11:24 <TheVibeCoder> or really not

11:26 <Lynne> TheVibeCoder: does librempeg support prores raw?

11:27 <TheVibeCoder> yes at least on variant of bayer pattern that i encountered in wild

11:27 <TheVibeCoder> *on

11:27 <TheVibeCoder> *one

11:28 <TheVibeCoder> so its missing recognizing other/different patterns, need to find right spot in bitstream when/how its signaled

11:28 <TheVibeCoder> *where/how

11:29 <TheVibeCoder> prores raw have almost 95% code stolen from prores

11:30 jamrial has joined #ffmpeg-devel

11:30 <TheVibeCoder> also there is 2 variants of prores raw, I think one is fully 12 bit (higher quality) and other is 10bit (when looking at pixel distribution in waveform)

11:32 <mindfreeze> Lynne: if i use Blackmagic raw's ExtractFrame example part of their SDK, i get the deocded frame to be https://people.videolan.org/~mindfreeze/outputRGBAU8.png

11:32 <mindfreeze> Probably you already tested them.

11:34 <TheVibeCoder> yea, different tint, good luck figuring out right color transfer and other stuff...

11:35 <Lynne> mindfreeze: there's absolutely no way to get that image ever via ffmpeg

11:36 <Lynne> at least without applying the very same filters they used

11:36 <mindfreeze> i wonder if we use the embedded metadata information o the clip (like LUT Cube and apply it), will that improve anything. Probably they only useful if we want to get as BT709 or anything else to transform

11:36 <mindfreeze> https://paste.debian.net/1369585/

11:37 <Lynne> TheVibeCoder: is all prores raw bayer, or do they have partially debayered patterns?

11:39 <TheVibeCoder> to me it appears its real bayer pattern, and not some hack

11:39 <TheVibeCoder> at least there is no sign of subsampled dct in codebase

11:40 <TheVibeCoder> there is only on dct variant used, unlike 2 in braw

11:41 <TheVibeCoder> also they have lowres stuff

11:41 <TheVibeCoder> iirc

11:41 <TheVibeCoder> and most of code is GPU-oriented

11:41 <TheVibeCoder> and yes BRAW too

11:41 <haasn> I guess I could switch from row-strided ops to column-strided linear ops; to make the sequence fma m0, m4, m8; fma m1, m4, m9; fma m2, m4, m10; fma m3, m4, m11 instead of fma m0, m4, m8; fma m0, m5, m9; fma m0, m6, m10; ...

11:42 <haasn> I guess the read-add-write critical path on m0 here is the problem

11:42 <TheVibeCoder> its uses nv/cuda thing, so if you can dechiper BRAW bytecode dealing with shader code you can maybe improve color situation

11:46 <TheVibeCoder> mindfreeze: issue is that BRAW also have special own version of color-transfer/primaries math behind all of this...

11:47 <Lynne> they also do noise reduction via their own libraries

11:48 <mindfreeze> yeah see that now

11:48 <mindfreeze> (https://people.videolan.org/~mindfreeze/BlackmagicGeneration5ColorScienceTechnicalReference.pdf)

11:48 <Lynne> which is completely NG IMHO, no professional gear should ever do processing to the extent that they do

11:49 <TheVibeCoder> i had pngg sample that have 0 post-processing as done by software

11:49 <TheVibeCoder> so realistic goal would be to try to reach that output

11:49 <TheVibeCoder> aka 0-calibration

11:50 <TheVibeCoder> i guess i could do it all i I owned device and/or software, but I was never much into that.

12:08 mkver has quit [Ping timeout: 276 seconds]

12:14 Gramner has quit [Remote host closed the connection]

12:20 abdu has quit [Ping timeout: 240 seconds]

12:28 <fflogger> [editedticket] MasterQuestionable: Ticket #11217 ([ffmpeg] Output "-ss" memory consumption regression) updated https://trac.ffmpeg.org/ticket/11217#comment:28

12:31 Gramner has joined #ffmpeg-devel

12:36 TheVibeCoder has quit [Quit: Client closed]

12:41 abdu has joined #ffmpeg-devel

12:45 <fflogger> [editedticket] MasterQuestionable: Ticket #11430 ([avformat] [Regression] Data stream in output may glitch "-stats" display since 7.0) updated https://trac.ffmpeg.org/ticket/11430#comment:16

12:47 abdu has quit [Ping timeout: 240 seconds]

12:49 abdu has joined #ffmpeg-devel

13:12 mkver has joined #ffmpeg-devel

13:18 abdu has quit [Ping timeout: 240 seconds]

13:19 abdu has joined #ffmpeg-devel

13:34 abdu has quit [Ping timeout: 240 seconds]

13:35 abdu has joined #ffmpeg-devel

13:46 minimal has joined #ffmpeg-devel

13:58 cone-805 has joined #ffmpeg-devel

13:58 <cone-805> ffmpeg Nicolas George master:0040d7e60896: lavfi/src_movie: set pkt_timebase

13:59 <haasn> what reward do I get when my asm code triggers an assertion in nasm during compilation?

14:07 pross has quit [Ping timeout: 245 seconds]

14:08 <jamrial> haasn: a bug report # :p

15:05 abdu has quit [Quit: Client closed]

15:18 abdu has joined #ffmpeg-devel

15:22 Anthony_ZO has quit [Ping timeout: 245 seconds]

15:22 Traneptora has joined #ffmpeg-devel

15:25 Martchus has quit [Quit: ZNC 1.6.3 - http://znc.in]

16:34 Martchus has joined #ffmpeg-devel

16:49 <another|> Lynne: hmm... am I stupid? What do I have to do to enable ffv1_vulkan?

16:50 <jamrial> another|: you need libglslang or libspirv-tools

16:50 <jamrial> and of course vulkan headers

16:55 <another|> hmm.. I think I have all those

16:56 <another|> Is there any configure flag?

16:56 <jamrial> yes, --enable-libglslang

16:57 <jamrial> or --enable-libshaderc

16:58 cone-805 has quit [Quit: transmission timeout]

16:59 <another|> which one is preferred?

17:01 <jamrial> no idea, but apparently shaderc depends on glslang anyway

17:45 <another|> err... how th do I convert from nv12 to vulkan pix fmt?

17:46 <JEEB> hwupload

17:47 <another|> unfortunately not

17:50 ngaullier has quit [Remote host closed the connection]

17:51 <another|> it's already in hw

17:51 mkver has quit [Ping timeout: 245 seconds]

17:51 <JEEB> oh

17:51 <JEEB> so another hw pix_fmt which needs to get converted to vulkan

17:51 mkver has joined #ffmpeg-devel

17:52 <JEEB> I thought that also used to be the territory of hwupload, but not sure with the vulkan hw format

17:52 <JEEB> `hwupload,format=pix_fmts=vulkan` or something

17:53 <JEEB> hwmap is the other filter dealing with hw frames which is not hwdownload (which goes to RAM)

17:54 <another|> hmm.. okay. hwupload works for sw->hw

17:55 <JEEB> and I've at least previously seen it work for hw->hw

17:55 <JEEB> but I would not be surprised if that was back then

17:55 <JEEB> and for specific hw pixel formats

17:56 <another|> I thought vulkan hw decode to vulkan hw encode should work pretty straight forward

17:56 <JEEB> uhh, it should :D

17:56 <JEEB> so your input is a vulkan hw frame?

17:56 <another|> alas..

17:56 <JEEB> so it's not the hw pixel format that is the problem but the actual data within it?

17:57 <another|> My input is nv12 from h264_vulkan

17:57 <JEEB> then either scale_vulkan or libplacebo filter to whatever ffv1enc_vulkan requires

17:58 <another|> already tried scale_vulkan

17:59 <another|> haven't compiled with libplacebo in this build since I'd need to use placebo git

17:59 <JEEB> scale_vulkan=format=blah gives an error?

18:00 <JEEB> seems to support yuv420p, yuv444p outside of nv12

18:00 <JEEB> oh, is its input limited to RGB?

18:01 <JEEB> since if input and output formats differ the first check is `!ff_vk_mt_is_np_rgb(s->vkctx.input_format)`

18:01 <JEEB> and if true, it errors out

18:02 <JEEB> I would expect libplacebo to be able to at least interpret NV12, but ┐(´д｀)┌

18:03 <another|> umpf. I think I give up for now

18:04 <JEEB> the encoder doesn't support NV12 input I guess so that's why without conversions you cannot just push the hw decoded frame through

18:06 DauntlessOne4 has quit [Ping timeout: 276 seconds]

18:08 ___nick___ has joined #ffmpeg-devel

18:09 DauntlessOne4 has joined #ffmpeg-devel

18:13 Sean_McG has joined #ffmpeg-devel

18:14 <Sean_McG> I suspect I already know the answer, but other than RPi and the fruit company, are there any other options for an ARM64 desktop?

18:19 <Sean_McG> I know nVidia has an AI workstation coming out as well

18:19 Traneptora has quit [Quit: Quit]

18:25 <nevcairiel> other then all the random SBCs from a variety of unknown companies?

18:26 <Sean_McG> aye

18:26 <Sean_McG> I'm guessing that's a no

18:32 Traneptora has joined #ffmpeg-devel

18:34 Traneptora has quit [Client Quit]

18:37 uau_ has joined #ffmpeg-devel

18:37 Traneptora has joined #ffmpeg-devel

18:37 abdu has quit [Ping timeout: 240 seconds]

18:37 uau has quit [Killed (iridium.libera.chat (Nickname regained by services))]

18:37 uau_ is now known as uau

18:39 <Lynne> another|: did you figure it out?

18:40 <Lynne> JEEB: ffv1 supports yuv420p, just not nv12, though support could be added

18:40 <JEEB> yea, that makes sense

18:40 <JEEB> since most likely you did not think of supporting hwdec frames as-is

18:41 <JEEB> as usually for ffv1 something else is the input :)

18:41 <BtbN> There's a bunch of ARM Laptops available now

18:41 <Sean_McG> I'd intend to run Linux on them, so the Windows Snapdragons are out of the question.

18:45 <another|> Lynne: so vulkan == yuv420p ?

18:46 <Lynne> if you do vulkan decode using av1/h264/hevc, you get nv12

18:46 <Lynne> the software format is independent of the hardware format

18:46 abdu has joined #ffmpeg-devel

18:46 <Lynne> if you upload a software format, that format stays with vulkan

18:47 <BtbN> Linux is still severely lacking on the ARM front

18:47 <BtbN> doesn't help that ARM is complete wild west, no standardization

18:47 <BtbN> by the time a device tree and all the drivers have made it upstream, the device is half obsolete

18:47 <BtbN> plus, i'm not sure if Linux wants to become a dumping ground for a bazillion of device trees and craptastic drivers

18:51 <another|> Lynne: so "vulkan" is kind of a meta format?

18:51 ___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]

18:51 <Lynne> yes

18:51 <BtbN> all the hwformats are

18:56 ___nick___ has joined #ffmpeg-devel

18:57 <another|> huh? is nv12 not a HW format?

18:59 <JEEB> pixel formats have two formats

18:59 <JEEB> due to hysterical raisisns

18:59 <kepstin> nv12 is a layout of pixels in memory - the memory can either be memory accessible by the cpu, or memory accessible by the gpu

18:59 <JEEB> so in case of hw formats you get {format=vulkan, sw_format=nv12}

19:00 <JEEB> whihc means "vulkan base pixel format, the actual contents are nv12"

19:01 <tmatth> Lynne: getting build breakage on hwcontext_vulkan.c: https://paste.debian.net/1369649/

19:02 <JEEB> tmatth: I got that when I had a different set of vulkan headers in my sysroot which were older (feb 2024)

19:02 <JEEB> so the configure check probably passed due to system headers, and then the additional custom sysroot stuff then got included first in that stuff

19:03 <tmatth> JEEB: yeah in my case I just have whatever the distro is shipping, haven't installed any custom stuff

19:04 abdu94 has joined #ffmpeg-devel

19:04 <tmatth> so I'm guessing a configure check needs to be stricter or some ifdefs need to be added

19:04 <JEEB> then re-run configure and if it indeed succeeds then the configure check indeed needs to be stricter

19:05 abdu has quit [Ping timeout: 240 seconds]

19:05 <JEEB> see ffbuild/config.log for what exactly passes

19:11 <another|> glslang or shaderc ?

19:13 <tmatth> JEEB: yeah I had already re-run configure before bugging you all :)

19:14 <JEEB> :)

19:14 <tmatth> it's checking for vulkan >= 1.3.277

19:17 <tmatth> apparently the problematic struct is "Provided by VK_VERSION_1_4" https://registry.khronos.org/vulkan/specs/latest/man/html/VkPhysicalDeviceShaderExpectAssumeFeatures.html

19:18 <JEEB> the header check did attempt to check for that I think

19:18 <JEEB> in my case the pkg-config check didn't succeed

19:21 <tmatth> in my case pkg-config passed because I have 1.3.290

19:21 <jamrial> the vulkan checks look for VK_VERSION_1_3, so if that needs 1_4 and can't be made optional, then the check needs to be updated

19:22 <jamrial> Lynne: ^

19:22 <tmatth> jamrial: yeah

19:26 <jkqxz_> Is there a TRANSPOSE8x8D hidden somewhere?

19:26 jkqxz_ is now known as jkqxz

19:28 <jamrial> doesn't look like

19:28 <jamrial> tmatth: http://pastie.org/p/4kwjGxmfnezVzky2beeYXO maybe this fixes it for you

19:30 <jamrial> or http://pastie.org/p/6J16Es7QT9paHW1j1bjJjv (fixing empty lines in the diff)

19:31 <Lynne> patch sent

19:33 <jamrial> yeah, same thing :p

19:36 <jkqxz> Hmm: <https://code.videolan.org/videolan/dav1d/-/blob/master/src/x86/itx16_avx2.asm?ref_type=heads#L2644-L2669>. Looks right.

19:37 <jkqxz> Would that want to be added to x86util or just use it in-place?

19:38 <jamrial> in-place until something else needs it, imo

19:41 <fflogger> [newticket] merolac: Ticket #11547 ([ffmpeg] Support for SEGA CD/MEGA CD video and audio codecs used in Road Avenger videogame) created https://trac.ffmpeg.org/ticket/11547

19:41 <tmatth> Lynne, jamrial: thx that fixed it for me

19:42 <Lynne> jamrial: yours is correct, go ahead and push it

19:43 <tmatth> (I tested Lynne's version FWIW)

19:44 System_Error has quit [Ping timeout: 264 seconds]

19:45 <tmatth> jamrial's version didn't work for me

19:46 <jamrial> so your headers define VK_KHR_shader_expect_assume but not VkPhysicalDeviceShaderExpectAssumeFeatures?

19:47 cone-721 has joined #ffmpeg-devel

19:47 <cone-721> ffmpeg James Almer master:f29475a89ecb: avutil/hwcontext_vulkan: check if expect_assume is supported by the header

19:48 <tmatth> I have "#define VK_KHR_shader_expect_assume 1" and "typedef struct VkPhysicalDeviceShaderExpectAssumeFeaturesKHR "...that's it

19:49 <jamrial> oh

19:50 <jamrial> tmatth: and http://pastie.org/p/4G4du5lObbhfHkIh2FAqIm ? (on current git head, so with the above commit)

19:51 <tmatth> jamrial: yes, that works thanks

19:53 <cone-721> ffmpeg James Almer master:0e5967569861: avutil/hwcontext_vulkan: use the typedef'd name for the expect_assume struct

19:53 System_Error has joined #ffmpeg-devel

19:54 <tmatth> btw the latency between seeing commit notifications here and being able to pull them is pretty high (this is probably old news)

19:55 <jamrial> tmatth: your headers are weird either way. maybe some indev snapshot before 1.4 was finished?

19:57 <tmatth> for reference it's https://launchpad.net/ubuntu/oracular/+package/libvulkan-dev

19:58 <tmatth> maybe more usefully https://launchpad.net/ubuntu/+source/vulkan-loader/1.3.290.0-1

19:59 kasper93 has joined #ffmpeg-devel

19:59 kasper93 is now known as Guest686

19:59 Guest686 has quit [Ping timeout: 268 seconds]

20:04 ___nick___ has quit [Ping timeout: 248 seconds]

20:04 kasper93 has quit [Ping timeout: 268 seconds]

20:06 mkver has quit [Ping timeout: 260 seconds]

20:06 kasper93 has joined #ffmpeg-devel

20:07 <jamrial> tmatth: ah, i guess it's an extension in 1.3 that got officialized in 1.4, where VkPhysicalDeviceShaderExpectAssumeFeatures was introduced

20:08 <tmatth> jamrial: good to know

20:15 microlappy has joined #ffmpeg-devel

20:31 <Lynne> tmatth: did encoding work?

20:31 <Lynne> you can use -async_depth to make it faster

20:31 IndecisiveTurtle has joined #ffmpeg-devel

20:40 <tmatth> Lynne: compilation worked didn't get as far as encoding

21:11 microlappy has quit [Quit: Konversation terminated!]

21:12 microlappy has joined #ffmpeg-devel

21:15 microlappy has quit [Client Quit]

21:28 abdu94 has quit [Ping timeout: 240 seconds]

22:00 abdu has joined #ffmpeg-devel

22:08 abdu has quit [Quit: Client closed]

22:08 IndecisiveTurtle has quit [Ping timeout: 252 seconds]

22:09 jamrial has quit []

22:11 pross has joined #ffmpeg-devel

22:17 <tmatth> Lynne: I only have vulkan decoding for h264 and hevc

22:18 <tmatth> this is with NVidia Quadro M2200 so not terribly surprising

22:23 <toots5446> michaelni: Just sent a v12 of the patchset with the metadata decoding logic reverted to the simpler original implementation.

22:31 abdu has joined #ffmpeg-devel

22:40 wyatt8740 has quit [Ping timeout: 252 seconds]

22:40 wyatt8740 has joined #ffmpeg-devel

22:45 wyatt8740 has quit [Ping timeout: 265 seconds]

22:45 wyatt8750 has joined #ffmpeg-devel

22:53 jamrial has joined #ffmpeg-devel

22:53 cone-721 has quit [Quit: transmission timeout]

22:53 jamrial has quit [Client Quit]

22:53 jamrial has joined #ffmpeg-devel

22:54 jamrial has quit [Client Quit]

22:56 jamrial has joined #ffmpeg-devel

23:00 <Lynne> tmatth: and ffv1, since we only use compute shaders for it

23:10 <tmatth> Lynne: that doesn't show up when I run ffmpeg -encoders | grep vulkan

23:23 jamrial has quit []

23:30 jamrial has joined #ffmpeg-devel

23:33 <Lynne> tmatth: you said decode

23:33 <Lynne> did ffv1_vulkan appear when you ran ./configure?

23:33 jamrial has quit [Read error: Connection reset by peer]