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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
<IndecisiveTurtle>
I'm probably using the api wrong then :thinking: I'll look it up more, appologies for the time waster :/
<Lynne>
just copy what filters do
<Lynne>
or what ffv1enc_vulkan does
<IndecisiveTurtle>
Will look thx. From a quick comparison I think it might be cause I misunderstood ff_vk_shader_update_img_array into a "update nth binding from nth image view" when its per binding, so related to my misunderstading of the binding assingment
<Lynne>
ah, I see
<IndecisiveTurtle>
So I batched all 6 image views into a single call lol
<Lynne>
not sure how that works
tyuploscet has joined #ffmpeg-devel
<Lynne>
yeah, that function updates the entire array in a single binding at once
HumbleLeader has quit [Quit: Client closed]
<Lynne>
it only updates as many planes as there are planes in the pixel format of the avframe
<Lynne>
so you need to call ff_vk_shader_update_img_array once per avframe
<IndecisiveTurtle>
What if I want to change pipeline layouts, do I have to call it again?
<Lynne>
change pipeline layouts_
<Lynne>
?
<IndecisiveTurtle>
upload shader needs 2 bindings (input and output planes) while all other shaders need only 1 plane array, so the layout of shader is different
<Lynne>
of course you have to update each descriptor binding independently
<Lynne>
update_img_array only updates one descriptor binding from one shader, it can't know that you also want to update another descriptor binding from another shader with the same data
<IndecisiveTurtle>
So have to call it again for each shader rebind? I think for normal descriptors if the pipeline has a "compatible" layout you can bind it once at the start, so was wondering if an update call could be saved if the bindings are common for all shaders
<Lynne>
didn't know that
<Lynne>
you should update it regardless for now, copying a few bytes over pcie shouldn't take more than tens of microseconds, its not a bottleneck in this case
<tyuploscet>
Is " VHS noise " will be removed ?
mkver has joined #ffmpeg-devel
tyuploscet has quit [Ping timeout: 240 seconds]
cone-455 has quit [Quit: transmission timeout]
Marth64[m] has quit [Quit: Leaving]
\\Mr_C\\ has quit [Remote host closed the connection]
tyuploscet has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
bencoh has quit [Ping timeout: 252 seconds]
bencoh has joined #ffmpeg-devel
tyuploscet has quit [Ping timeout: 240 seconds]
thilo has quit [Ping timeout: 248 seconds]
thilo has joined #ffmpeg-devel
Marth64[m] has joined #ffmpeg-devel
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
Mirarora has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
ngaullier has quit [Remote host closed the connection]
<fflogger>
[newticket] Saafo: Ticket #11402 ([undetermined] opus file generated by ffmpeg cannot be decoded with opus-tools) created https://trac.ffmpeg.org/ticket/11402
<Lynne>
it was designed for audio and it only makes sense in its simplest possible definition for audio
<Lynne>
but then you have the fact that ogg supports concatenations, and the fact that each single codec defines the granulepos to mean something else, and it becomes this
<BBB>
chained ogg <3
<BBB>
hack after hack after hack after ... oops is that a CoC violation?
___nick___ has quit [Ping timeout: 265 seconds]
___nick___ has joined #ffmpeg-devel
<Lynne>
the worst part by far of chained ogg is the fact that its recommended that all streams get new serial IDs
<Lynne>
...why?
<Lynne>
isn't the point of chaining that you have seamless switching?
<Lynne>
instead, you are supposed to group streams by codec, then by stream type, and iterate over all streams before and after, and try to match them up
<Lynne>
(but all of this is of course not even specified but just what makes sense)
<Lynne>
but hey, something good came out of ogg, the fact that you are supposed to CRC every single page always, and if you lost sync, you are supposed to CRC up to 64k of data on every single individual byte until you are back in sync motivated me to write avtransport
<Lynne>
where losing sync is impossible
mkver has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
_av500_ is now known as av500
<BtbN>
nevcairiel: is that just the order changing? That could be threading in ffmpeg.c I guess
<BtbN>
though there is only one demuxer
blb has quit [Quit: brb]
System_Error has quit [Remote host closed the connection]
<nevcairiel>
BtbN: no it seems to fail to analyze the input file, not getting a resolution for the video streams, for some reason
<nevcairiel>
which seems like an odd failure to be sporadic about
ccawley2011 has joined #ffmpeg-devel
<FantasticLeader>
how to donate decoder to ffmpeg?
microlappy has joined #ffmpeg-devel
<jamrial>
haasn: see what FantasticLeader pasted above. log100 has no EOTF function, but should it matter when the output is also log100?
microlappy has quit [Client Quit]
FantasticLeader has quit [Quit: Client closed]
FantasticLeader has joined #ffmpeg-devel
abdo has quit [Ping timeout: 265 seconds]
abdo has joined #ffmpeg-devel
<FantasticLeader>
for log100 thing i was trying it with exr decoder, and its -apply_trc option
System_Error has quit [Ping timeout: 264 seconds]
rvalue has joined #ffmpeg-devel
<beastd>
BBB, Lynne: I don't even know much of the ogg container, but when reading a bit on the surface i had some of the same questions you just brought up. chaining and serial etc.
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 248 seconds]
iive has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
<kurosu>
BBB: disparaging ogg? That's riscy business that may indeed get on some people nervves
<FantasticLeader>
blame format instead of fixing mess
<FantasticLeader>
very convenient
<beastd>
It is what it is! Much better to blame the format instead of the people ;-)
<FantasticLeader>
people are lazy
<FantasticLeader>
here
<FantasticLeader>
i blame lazy people
<beastd>
mov/mp4 is also very suboptimal XD
<FantasticLeader>
no, the ffmpeg implementation needs improvements
<beastd>
one does not exclude the other ;-)
<FantasticLeader>
i discern between format and inefficient implementation
<FantasticLeader>
if you can not explain why bug happens than you can not explain why format is bad
<beastd>
the inherent complexity of the format is quite obvious. and i have heared about more missing moov atoms in my life than i even want to remember ;-P
<beastd>
FantasticLeader: patches for understood bugs are of course welcome anyway
<FantasticLeader>
if something is complex does not mean it is also complicated
<Lynne>
everyone has at least 7 stories to tell about isobmff/mp4
<FantasticLeader>
but first story about was ogg
<FantasticLeader>
not mov
Guest64 has joined #ffmpeg-devel
<FantasticLeader>
its 2025
<beastd>
\o/
<FantasticLeader>
and gapless still not properly done for aac,mp3,
<Lynne>
sorry :(
<Lynne>
it kinda works in the most popular cases
<Lynne>
but not in general
<FantasticLeader>
yea, it sometimes depends on buggy encoder
<FantasticLeader>
but concentrate on reference encoder only
<FantasticLeader>
iirc there are format signals and bitstream signals that set number of samples to trim from start/last packet?
* JEEB
has never touched the reference AAC encoder (or the MPEG-1 Layer 3 encoder)
<FantasticLeader>
the reference encoders are more like proof of concept
<FantasticLeader>
i'm concentrated on most useful/popular/paid/pro encoders
<JEEB>
I think with MPEG-H Audio they finally made the license kinda OK, but it's still under a license that I'd rather not look at (since they limit code use for specifically implementations of that format). granted, you don't have to look at the code to build it.
<JEEB>
for AAC I'm not sure if the reference implementation is with an open source license
<JEEB>
or MPEG-1 Layer 3
<FantasticLeader>
what about the IAMF audio codec, elipse or whatever is name now?
<FantasticLeader>
the open source "variant" of atmos
<FantasticLeader>
and what/where is mov files with apac fourcc audio track?
<FantasticLeader>
is that real codec?
<FantasticLeader>
or some leaked demo
<JEEB>
IAMF seemed to be just a container level channel/object mapping thing...
<BtbN>
nevcairiel: huh, yeah. I don't have an immediate idea what would be causing THAT
<JEEB>
because IIRC different cameras utilize different bayer patterns
<FantasticLeader>
there is no 12bit bayer pix format
<FantasticLeader>
yes
<FantasticLeader>
i dunno about pattern part
<FantasticLeader>
i picked something that looks good enough
<JEEB>
that's OK, just that we still have hope that the info could be somewhere
<JEEB>
if not then all I can say is "lol"
<JEEB>
since all applications then need to have a list hard-coded
<JEEB>
to correctly display every camera's bayer
<FantasticLeader>
decoder have some bytes that it skips, probably have some bits that represent pattern
<FantasticLeader>
yes
<FantasticLeader>
i know
<FantasticLeader>
different patterns give different output when debayered
<FantasticLeader>
i have DNG lossless transcode of prores raw
<JEEB>
also the lol comment was not aimed at the RE effort, that's cool. mostly just if they really went for dumb stuff when defining it like requiring all implementations :)
<FantasticLeader>
so i probably could try to fix that, if i knew another DNG transcode of different file that have different pattern
<JEEB>
(to have a hard-coded list)
<JEEB>
but yea, if there are skipped things those could be metadata
<JEEB>
we'll see when we get there
<JEEB>
apparently panasonic's GH6 will have prores raw
<JEEB>
if I get my hands on one I could try checking its output
<JEEB>
> when the camera is tethered to the atomos ninja v+
<JEEB>
wtf
<JEEB>
how is that the camera getting support
<FantasticLeader>
cool, i have sony A7SIII got from web, its pattern looks to be rggb
<JEEB>
would have expected that plugging in a nice fast USB SSD would have been enough
<FantasticLeader>
now i only need to locate unused bits and find where is pattern stored
FantasticLeader has quit [Quit: Client closed]
FantasticLeader has joined #ffmpeg-devel
<FantasticLeader>
if there are only 4 possible bayer patterns, than its probably stored as single number somewhere
<FantasticLeader>
because searching for 0 1 1 2 or similar shows nothing
<JEEB>
ah, ok. so GH7 actually supports it internally
<JEEB>
no need for an atomos piece of shit
<FantasticLeader>
there is demo rawconverter for windows/mac that can convert prores raw to dng
<FantasticLeader>
so if you can not find pattern other way around
<FantasticLeader>
because dng store that info in verbose way
<JEEB>
wow, someone actually provided a GH7 sample
<FantasticLeader>
is colormatrices in mov a bayer pattern?
<JEEB>
which box are you talking about?
<FantasticLeader>
because maybe data is duped in container and also in bitstream level
<JEEB>
yea, I would have expected container to be utilized as one possibility.
<FantasticLeader>
its just metadata
<JEEB>
as a related thing, I recall prores stuff can have alpha being either pre-multiplied or not, they actually have a flag. but I never looked it up whether it's in the container or bit stream'
<Compn>
#11386: defect: Subtitles and MOV are not working anymore (closed: invalid)
<Compn>
With FFmpeg 7.1 up to daily git of 30/12/2024, adding srt subtitles are not working anymore. Works fine with FFmpeg 7.0 and older Some notes: when removing -tag:s:s:0 tx3g , it does not throw an error but the subtitle cannot be played o\
<Compn>
if you want to use the batch modify to change the ticket
<BtbN>
Can't batch modify the tags
<Compn>
i see that
<BtbN>
guess I gotta look directly at the DB to find anything out of the ordinary
<BtbN>
the ticket was originally fine, and it broke on the comment, right?
<BtbN>
hm, no. All changes for it look benign
<BtbN>
it must be in the original ticket
<JEEB>
looking at the plugin's svn under trac-hacks.org it does have HTML templates and stuff, so wouldn't be surprised if something then threw things off
<JEEB>
but I'll let you check the DB entry for anything funky
* Compn
wonders why he typo character
grundnotch has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
abdu has quit [Ping timeout: 240 seconds]
grundnotch has left #ffmpeg-devel [#ffmpeg-devel]
<BtbN>
tickets aren't even tagged from what I can tell
abdo has quit [Ping timeout: 265 seconds]
fflogger has quit [Remote host closed the connection]
fflogger has joined #ffmpeg-devel
cone-065 has joined #ffmpeg-devel
<cone-065>
ffmpeg Koushik Dutta master:252fc2e04729: avfilter/scale_vulkan: add dynamic crop region and aspect ratio match
<BtbN>
Managed to get a backtrace: https://bpa.st/4JBSOEFT7WDI5VPNSBRXOKYGOI seems like whatever output was in that ticket, it accidentally contains wiki formating, and that formating makes the parser crash, leading to this whole mess
fflogger has quit [Remote host closed the connection]