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
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
<elenril>
llyyr: I sent a patch a couple days ago
<elenril>
you should be in CC
<elenril>
did you not get it?
<llyyr>
gmail moment
<llyyr>
the mailing list is unable to sent to gmail atm I think
<elenril>
you should have received a copy from my mailserver directly too
<compn>
surprisingly i did well with the metal chopstix
<compn>
i thought they would be impossible but no
System_Error has quit [Remote host closed the connection]
<aaabbb>
does the h261 decoder not mark keyframes correctly or something? when encoding with h261, all frames are identified as P frames, which also leads to buggy warnings that the stat frame is not a keyframe
<aaabbb>
how did i miss that? at least my hunch was right that it's just not marking keyframes correctly. sad that the patch is 5 years old with no progress
<compn>
well if you can answer the question then maybe it can get applied
<compn>
:D
<compn>
aka if someone encodes with a binary h261 encoder and we look at the frames...
<aaabbb>
the patch according to its description reflects the h261 encoder behavior
<compn>
michaelni, re plugin libavfilter by meta, i asked dev. he said he will ask the meta mothership if he can send the patch ,and then he will send it if so
<Lynne>
BBB: most of the decoder is already written, its all a matter of just gluing all the parts the encoder needed with a few more lines...
<Lynne>
...of vulkan
<compn>
what is the speed like? i didnt see a benchmark :D
<Lynne>
depends on the CPU you're comparing against
<BBB>
compn: didn't I reply that to the ML?
<BBB>
"IIRC that question was asked during the Q&A, and he was going to look into that."
<BBB>
:)
<Lynne>
but much its better than even a high-end CPU, unless you have one with at least 500 cores
<compn>
BBB, yes i'm just specifying it was me who asked, and clarifying that we are waiting on meta approval
Kei_N has joined #ffmpeg-devel
<BBB>
right, ok
<compn>
Lynne, 94x it is! :D
<compn>
Lynne, it is impressive. i am a fan of ffv1 and i know archivists would probably enjoy this feature
<compn>
oops i mean what is the ffv1 vulkan encoder speed like
<compn>
sorry i mixed up vulkan talk
<Lynne>
its not a very nicely written codec, it carries all old versions on its back like APE, but hey, it works
<Lynne>
IndecisiveTurtle: your bitstream writer only really works if the address of what you're writing is aligned
<Lynne>
so if you write a uint32_t to an address not aligned to 4, pretty much universally all implementations will fail
<IndecisiveTurtle>
I do recall printing the generated slice sizes in shaders and all of them were divisible by 4 so I didn't hit that problem in vc2 much. But it will fail if pb_start doesn't have first 2 bits of 0
<Lynne>
yeah, I have a hacky way to get around this in ffv1, but I decided its too unreliable
<Lynne>
I've left an aligned and unaligned put_bits version
<IndecisiveTurtle>
Maybe good to align slice sizes to 4 to make it always work?
<IndecisiveTurtle>
But well thats probably not in the spec of the codecs so a bad hack I imagine
microlappy has joined #ffmpeg-devel
microlappy has quit [Client Quit]
microlappy has joined #ffmpeg-devel
blb has quit [Ping timeout: 265 seconds]
blb has joined #ffmpeg-devel
<Lynne>
the issue is that ffv1 uses range coder for the slice header
<Lynne>
which may result in a variable number of bytes written before each slice's data begins
<Lynne>
and you can't really predict it well
<Lynne>
hmm, maybe its doable
<Lynne>
by just starting to write the data a safe distance away and just copying it during the end
<Lynne>
since we have to do a copy in ffv1 anyway
microlappy has quit [Quit: Konversation terminated!]
lemourin has quit [Quit: Ping timeout (120 seconds)]
<michaelni>
haasn, your swscale4 branch segfaults with ./ffmpeg -f lavfi -i testsrc=s=4096x16 -vf scale=1:1 -bitexact -vframes 1 /tmp/file-4k1.jpg
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
<michaelni>
about the referened patch, by eye it looks reasonable, is there some branch that i can test ?
lemourin has quit [Client Quit]
lemourin has joined #ffmpeg-devel
<haasn>
michaelni: it’s also on swscale4 (one of the earlier commits)
<haasn>
Fixed the bug with bgr565 on that branch too
lemourin has quit [Client Quit]
lemourin has joined #ffmpeg-devel
lemourin has quit [Client Quit]
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
<haasn>
elenril: about the samples, I will reassemble my PC today (finally)
compn has quit [Remote host closed the connection]
<haasn>
And can send it to you
compn has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest9369
<Lynne>
oof, did it break?
lemourin has quit [Client Quit]
Guest9369 has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
lemourin has quit [Client Quit]
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
lemourin has quit [Client Quit]
lemourin has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]