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
markh has quit [Remote host closed the connection]
markh has joined #ffmpeg-devel
<kurosu>
I won't check vvcenc code, but except whitelisting files for each instruction sets, everything seems flimsy. It's not hard with CMake, but if they haven't been tidy with their code (eg mixing SSE and avx2) then tough luck
<kurosu>
Intrinsic code
<nevcairiel>
you do need the instruction flags for intrinsics to work, you would add them per-file generally if you care, but that doesnt stop the global constructor from actually running code from a file that uses it
<kurosu>
global constructor? Because the files/functions using intrinsics need that? I'd have hoped they used function pointer assignments
<kurosu>
I guess that's no vvenc or checking flags even before LoadLibrary/dlopen on the vvenc lib then
<nevcairiel>
i'm not sure how they manage instruction sets, maybe they just require AVX2, which wouldnt surprise me that much, anything else it would probably be way too slow anyway
<nevcairiel>
of course wanting to static link that lib in the ffmpeg build doesnt allow you any control over loading
cone-471 has joined #ffmpeg-devel
<cone-471>
ffmpeg Anton Khirnov master:d2096679d5b5: compat/w32pthreads: change pthread_t into pointer to malloced struct
<elenril>
nevcairiel: ^should fix your failures
ngaullier has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 252 seconds]
<wbs>
elenril: thanks, re getting the spurious failures fixed! (now if we'd also could get rid of the spurious threading/subtitle failures it'd also be really nice) :P
<elenril>
it would, wouldn't it
<elenril>
I think so too
<wbs>
yep; for public cases where I use ffmpeg as testcase to validate nightly compiler builds, I've refrained from updating to 7.x due to that (not sure how often those issues would crop up in that environment though)
ngaullie has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
Raz- has quit [Remote host closed the connection]
av500 has quit [Remote host closed the connection]
av500 has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 252 seconds]
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
av500 has quit [Remote host closed the connection]
av500 has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
av500 has quit [Remote host closed the connection]
av500 has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
<fflogger>
[editedticket] haasn: Ticket #8496 ([swscale] Conditional jump or move depends on uninitialised value with small input) updated https://trac.ffmpeg.org/ticket/8496#comment:1
<fflogger>
[editedticket] haasn: Ticket #1972 ([swscale] swscale: vertical line at the right side with rgb24 -> yuv410p conversion (odd width)) updated https://trac.ffmpeg.org/ticket/1972#comment:3
<thardin>
-use_mfra_for causes mov.c to probe the wrong duration
mkver has joined #ffmpeg-devel
<thardin>
movenc also seems to write bigger mfra boxes than necessary
<jamrial>
how so?
<thardin>
if the size of the file and all timestamps fit in 32 bits then a version 0 traf can be written
<thardin>
which is 8 bytes smaller per entry. which can be quite a lot for certain files
<jamrial>
ah, that's true
<thardin>
trying to get mov.c to read the last fragment only when probing. it's going so-so
<Daemon404>
thardin, if that is happening then the mfra is broken
<Daemon404>
or our probe code is broken
<thardin>
Daemon404: what happens is that -use_mfra_for triggers mov_read_default() to exit early without reading any fragment headers
<thardin>
which makes sense for a fragmented file. but we do need to least the last header to get the duration. this should mean 5-6 seeks for this particular file, rather than 400. right now I've gotten it down to 4
Sean_McG has joined #ffmpeg-devel
<thardin>
there we go, now it does 6 seeks and gets the duration right
<elenril>
Daemon404: consider the possibility that everything is broken
<elenril>
also, can we kill draw_horiz_band?
<elenril>
it is supported by zero codecs for which it might be useful
<thardin>
mov_switch_root() is the way to go
<wbs>
elenril: talk to kieran, iirc he meddled with codecs with less-than-a-frame latency decoding
<Daemon404>
thardin, ive never experienced that sort of seeking when probing using use_mfra_for (which i explicitly use to probe efficiently over a network)
<Daemon404>
unless this is new behavior
<thardin>
Daemon404: do you get the correct duration?
MyNetAz has quit [Remote host closed the connection]
<Daemon404>
i dont use probe duration at work because it is useless for UGC :)
<thardin>
because without reading the last fragment you probably don't
<Daemon404>
it was a fix for the 400 seeks, but didnt consider duration
<thardin>
yeah and it's not enabled by default
<Daemon404>
we have it hard enabled at $dayjob ;)
<Daemon404>
likely for the same reason spotify do
<thardin>
yeah
<thardin>
so fixing this slightly better should make both groups happier
<Daemon404>
yep
<thardin>
there's still the question of why -use_mfra_for has both pts and dts options
<Daemon404>
that i dont know
<Daemon404>
it was just there when michael i think added it
<Daemon404>
commit message didnt say iirc
<thardin>
would be nice to yeet it entirely
<Daemon404>
im pretty sure mfra is defined as always pts
<elenril>
mkver: are you ok with me continuing your work on h264 progress?
<mkver>
Did you get rid of the owner field?
<elenril>
looking into it currently
<mkver>
All is easy if this is gone.
<elenril>
couldn't we just drop it and call report_progress unconditionally?
<elenril>
oh right we can't, nevermind
<elenril>
anyway, I'll try to have a closer look this week
___nick___ has joined #ffmpeg-devel
<Daemon404>
this stuff all reminds me i need to investigate avidec.c and "non-interleaved avi"...
<Daemon404>
these files fail bigtime to probe over a network
___nick___ has quit [Client Quit]
<thardin>
mxf too
<Daemon404>
and i have no idea wtf they are (other than most seem to used packed bitstreams for h264 in avi)
<Daemon404>
some of the code is old enough that it is fabrice code too
<Daemon404>
so extra opaque
<elenril>
isn't non-interleaved avi exactly what it says on the tin?
<Daemon404>
it really isn't though
<Daemon404>
because all the files it claims are ... are interleaved
<Daemon404>
but may be packed bitstream
___nick___ has joined #ffmpeg-devel
<Daemon404>
i suspect somehow related to that (bframe hack)
<thardin>
I've seen some mov files lately that are muxed in 1 second clumps. that is, one second of video, then one second of audio, then video etc
<Daemon404>
i wonder if it does something nuts like seeking inside the packed packets
<Daemon404>
because avi has no reordering
<Daemon404>
thardin, mov and mp4 have no ordering or interleaving requirements
<Daemon404>
if you want to make packets in reverse, you can
<Daemon404>
and youre boned.
<thardin>
yeah but it brings with it some fun questions
<thardin>
I think at the moment it demuxes them in the order stored in the file. so you get lumpy output
<Daemon404>
ive never seen a real file with out of order packets tbf
<thardin>
or in your cursed example you get packets in reverse order I guess?
<Daemon404>
i just know you *can*
<thardin>
you can point packets at the same offset too. which could be useful for further compression if for example silence compresses to the same bits
zenmov has quit [Ping timeout: 244 seconds]
<thardin>
people do that with Doom .WAD files
<Daemon404>
with the caveat that it would break basically every playback stack probably
<thardin>
if there's a common prefix -> point into previously written data
<Daemon404>
proposal to add wad demuxer/muxer
<thardin>
fits poorly with ffmpeg's data model
<Daemon404>
with the end goal of lavfi runnign doom ofc
<Daemon404>
if a toaster can, why cant we/
<thardin>
of course. it could be useful for *someone* after all
zenmov has joined #ffmpeg-devel
<thardin>
I toyed around with writing a better .wad packer recently. but improvements were very marginal and compatibility becomes a question. interestingly the original game is much more lax that modern forks
<thardin>
the same goes for WOLF3D
<elenril>
Daemon404: I'm sure lavfi can run doom
<elenril>
filters can accept commands
<thardin>
alright fate-mov passes
<Daemon404>
elenril, well if we support dlopen, anything is possible
<thardin>
I'll add my little sidx variant as well. and maybe a test for the duration too
<Daemon404>
doom, chinese malware, etc
<elenril>
without objective morality, everything is permitted
<thardin>
spoopy
<thardin>
can FATE cases share CMD etc? I forget
<elenril>
like $(A_BUNCH_OF_TESTS): CMD = ...?
<elenril>
if so, yes
<thardin>
mkay. let's see..
<thardin>
yep that works
<thardin>
so now there's one test that checks that mfra does 6 seeks, and sidx 3 seeks
<thardin>
for these files that I've engineered to be really bad
<JEEB>
nice
<thardin>
adding an ffprobe -show_streams tests on top to check the duration
<thardin>
bitrate differs. but perhaps that's unavoidable?
<JEEB>
welcome to "let's see what this value exposed is actually based upon"
<thardin>
right, data_size isn't computed correctly at that point because it needs to parse all moof for that
<thardin>
and lacking that it falls back on computing it from filesize
<thardin>
or maybe from duration?
<thardin>
from samplerate etc by the looks of things, because it is 41000*2*8 = 705600
<JEEB>
yup
<jamrial>
thardin: fate-mov doesn't include fate-movenc btw
<jamrial>
in case you're changing the muxer too
<thardin>
right
<thardin>
that could be a separate patchset maybe. we'll see
<nasso>
i found a strange crash when transfering frames from vulkan to cuda that only happens when the cuda context is initialized from the vulkan context, and not the other way around. i got curious and spun up gdb and it looks like its because the AVVkFrame is missing a VkDeviceMemory for the second plane
<nasso>
but im not sure why deriving the vulkan context from the cuda context fixes it?
<thardin>
patches posted
<fflogger>
[newticket] sylware: Ticket #11355 ([trac] [email] missing support for email addresses with IPv4 and IPv6 literals) created https://trac.ffmpeg.org/ticket/11355
<thardin>
oh no fate failure. but is my patch at fault? let's se
<jamrial>
thardin: the ref file doesn't seem to be included in patch 5/6
<thardin>
they're in the zip
<jamrial>
i don't mean the mp4 files, i mean tests/ref/fate/mov-mfra-probe
Marth64 has joined #ffmpeg-devel
<thardin>
ah. wups
ngaullie has joined #ffmpeg-devel
mkver has quit [Ping timeout: 265 seconds]
ngaullier has quit [Ping timeout: 246 seconds]
<elenril>
I wonder if sylware is paul
<jamrial>
on trac? doubt it, he's written me to report bugs
<jamrial>
he has no reason to hide his identity
<elenril>
he has no reason to do lots of things he does
<Marth64>
is cc candidate allowed to vote for cc?
<JEEB>
yes
<JEEB>
if you are in the GA, you are voting. at least I recall previously voting for TC, too.
<JEEB>
I mean, in various IRL votes people eligible that are balloting also can vote in that ballot
hidden_identity has joined #ffmpeg-devel
<Marth64>
I figured since I got the email, just wanted to verify. thanks!
<thardin>
hmm it changes time_base from 1/24 to 1/48
___nick___ has quit [Ping timeout: 272 seconds]
___nick___ has joined #ffmpeg-devel
<thardin>
avg_frame_rate changes from 1200000000/49590001 to 0/0
<thardin>
which I guess causes r_frame_rate to be used
esu has quit [Ping timeout: 264 seconds]
esu has joined #ffmpeg-devel
<thardin>
more seriously the patch that attempts to only parse the last fragment results in only half the video packets being demuxed
<thardin>
food time
<hidden_identity>
hi, what is status of subtitle filtering support, hls protocol support and AC-4 decoding ? Why not using already available API provided by operating systems?
ngaullie has quit [Read error: Connection reset by peer]
<JEEB>
subtitle filtering requires someone to pick up the work. HLS itself is supported so you will have to be more specific than that. AC-4 also is a patch set that needs to be picked up since there is a work in progress decoder
<llyyr>
what OS has APIs for subtitles and hls?
ngaullier has joined #ffmpeg-devel
<kepstin>
I'm pretty sure with iOS you can use an entire "video player" as a component via api which supports HLS and displaying subtitles, but that seems kind of irrelevant for the ffmpeg use case.