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 6.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
jamrial has quit []
aaabbb has quit [Remote host closed the connection]
aaabbb has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
qeed has quit [Quit: Leaving]
Sk0tik has quit [Ping timeout: 256 seconds]
Marth64 has quit [Read error: Connection reset by peer]
AbleBacon has quit [Read error: Connection reset by peer]
clark_hung has quit [Quit: Client closed]
clark_hung has joined #ffmpeg-devel
MrZeus__ has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 252 seconds]
cone-167 has joined #ffmpeg-devel
<cone-167>
ffmpeg Anton Khirnov master:c9f38210fc49: fftools/ffmpeg: merge DemuxPktData into FrameData
<cone-167>
ffmpeg Anton Khirnov master:9d7000b1bea0: fftools/ffmpeg: attach wallclock timing information to packets and frames
<cone-167>
ffmpeg Anton Khirnov master:5256b2fbe603: fftools/ffmpeg_mux: print latency information in -debug_ts muxing output
elastic_dog has quit [Ping timeout: 246 seconds]
dellas has joined #ffmpeg-devel
elastic_dog has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 245 seconds]
navi has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
philipl has quit [Ping timeout: 256 seconds]
philipl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
dellas has quit [Ping timeout: 246 seconds]
cone-167 has quit [Quit: transmission timeout]
mkver has quit [Ping timeout: 256 seconds]
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
rvalue has quit [Ping timeout: 268 seconds]
zsoltiv__ has quit [Ping timeout: 256 seconds]
jamrial has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<ubitux>
ok so both prores encoders have the quicktime bug
Krowl has joined #ffmpeg-devel
Teukka has quit [Ping timeout: 264 seconds]
<Daemon404>
what is 'quicktime bug' here?
<JEEB>
nice
<Daemon404>
im curious as id have expected to hear from the companies using it (i.e. everyone)
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
<ubitux>
Daemon404: videos with alpha have random blinking glitches; if i fix prores_aw so that alpha is honored in quicktime the same thing happens than with prores_ks
<Daemon404>
ah alpha
<Daemon404>
that explains why
<ubitux>
now i'm trying to make it glitch with videotoolboxenc
<ubitux>
to make sure that's something on quicktime side and not us
<Daemon404>
wouldnt be shocking
<Daemon404>
qt has all sorts of problems that never getvfixed
<ubitux>
thing is i can't report it to apple until i reproduce with their encoder
<ubitux>
pretty sure that's on their side tbh
<wbs>
the HEVC HW encoder on iphones had a funny bug for years; it was kinda crappy, kinda like encoding in some random uninitialized bits, more of it the lower bitrate you used. Long ago this was really apparent, and I reported some bugs. That was fixed and it wasn't quite as visible, but the encoder was still just worse than h264 for low bitrates. In the end, it turned out that it worked fine in 1 out of 8
<wbs>
different possible configurations ...
<wbs>
... (realtime on/off, bframes on/off, quality or bitrate mode) but was more or less broken in the other ones
<wbs>
but suddenly out of the blue, this got fixed in some late iOS 15.x version last year
<wbs>
(same thing with desktop macos on apple silicon)
<Daemon404>
normal apple way
<wbs>
yes, but I was pleasantly surprised to see them actually fix it
<Daemon404>
even when i report bugs directly to their engineers, as soon as it can be confirmed to be their bug, they ghost me
<Daemon404>
and it gets fixed in some new os 2 years later
<wbs>
yep
<nevcairiel>
cant possibly admit fault? :d
<Daemon404>
it has happened so much and to enough people i assume there is some sort of policy around it
<Daemon404>
to what end i dunno
<ubitux>
they don't want to leak information
<kierank>
Daemon404: prores is their codec
<kierank>
so they don't care about 3rd party implementations
<kierank>
so it's not a bug
<Daemon404>
yeah but im talking in general here
<Daemon404>
not specifically prores
<ubitux>
they have a very strict policy even internally wrt information disclosure
<Daemon404>
i mean im talking about me reporting bugs to them
<Daemon404>
as soon as you ghost me i know its real
<Daemon404>
real useful policy
<ubitux>
yeah but you're running an informatin leak blind attack here, hackerman
zsoltiv_ has joined #ffmpeg-devel
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
clark_hung has quit [Quit: Client closed]
<courmisch>
eh, GStreamer's FFmpeg fork sends me merge notifications
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 260 seconds]
mkver has quit [Ping timeout: 246 seconds]
Krowl has quit [Read error: Connection reset by peer]
lexano has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 245 seconds]
Kei_N has joined #ffmpeg-devel
<haasn>
is it acceptable to av_assert that an AVFilterContext has at least one input or output?
<haasn>
i.e. av_assert2(ctx->nb_inputs > 0 || ctx->nb_outputs > 0)
<haasn>
I cannot think of a possible reason to have a filter with no inputs or outputs, but maybe somebody else knows more
<Daemon404>
do src filters have an input?
<Daemon404>
or was that meant to be an &&
<Daemon404>
oh assert, derp
dellas has joined #ffmpeg-devel
<Daemon404>
reading gard
<Daemon404>
hard
<jamrial>
writing too :p
<Daemon404>
android keyboard yo
AbleBacon has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
<Lynne>
yeah, we have source filters and null output filters too (a/null + some audio-stats related filters)
<Lynne>
and optional in+out filters too (ebur128 can output video)
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
blb has joined #ffmpeg-devel
<wbs>
elenril: no idea, I probably just copied something else. what does it do?
<elenril>
you have to say -autorotate 0/1
<elenril>
or -noautorotate
<elenril>
it's quite confusing
<wbs>
oh, right. as it's on by default, I presume -noautorotate is the only form anybody cares about
<KyleSiefring>
I'm seeing some performance improvements in x264 over the last 2 years on x86 at ultrafast lowdelays speeds. Any ideas what might be causing this? I don't see much in the commit logs that would cause this.
<BtbN>
Did you buy a new CPU?
<elenril>
mkver: what do you think about turning AVMutex into a { pthread_mutex_t lock; char initialized; } struct?
<mkver>
I don't like the idea.
<elenril>
why not?
<mkver>
E.g. it would mean that we have one char for every mutex (and presumably also for every condition variable), but if these are part of the same structure, one only needs one counter.
<elenril>
right
<mkver>
See libavcodec/pthread.c.
<elenril>
that does not generalize easily though, does it?
<mkver>
?
<elenril>
I don't see how the code from lavc/pthread.c could be reused in other places without a lot of code duplication
<mkver>
Where do you want to reuse it?
<mkver>
In lavu?
<elenril>
in ffmpeg CLI
<elenril>
but more generally anywhere we create or destroy mutexes
<mkver>
Then these functions can be duplicated for shared builds as usual.
<mkver>
(I also pondered adding another version of these functions that doesn't need to store the number of initialized mutexes/conds, but instead uninit all mutexes/conds in case of errors; useful for AVThreadMessage and AVExecutor.)
<elenril>
it seems a lot more complexity for saving a few bytes
<mkver>
We'll probably disagree on this.
<elenril>
I guess so, you seem to place much higher value on memory savings
<mkver>
I consider your approach to be unelegant, because adding this all AVMutexes will incur costs where there is no benefit.
<elenril>
it would simplify the code
<mkver>
I don't think so.
<elenril>
a flags is very easy to understand
<elenril>
magic macros operating on struct offsets are not
<mkver>
As is using ff_pthread_init() and ff_pthread_free().
<elenril>
the caller still needs to define the offsets
<courmisch>
pthread_mutex_t is so last century
<mkver>
And that leads to less code than adding an pthread_mutex_init/destroy for every mutex.
<elenril>
mkver: so would you move that function to libavutil/thread.h?
<elenril>
and how to use it in ffmpeg CLI for shared builds
<courmisch>
I have actually both simplified and shrunk muteces
<courmisch>
And it would be even simpler if I hadn't had to deal with thread cancellation.
<elenril>
in what code?
<courmisch>
above
<mkver>
elenril: Copying it into ffmpeg CLI for shared builds should work just as copying it into a library.
<courmisch>
a VLC mutex is just 12/16 bytes on 32/64-bit platforms
<courmisch>
init cannot fail, destruction is unnecessary, and we have reliable support for asserting that a mutex is locked or not locked
<elenril>
vlc has custom mutices?
<elenril>
that sounds pretty blasphemous
<courmisch>
also lock cannot fail, trylock returns a boolean and unlock cannot fail
<courmisch>
so much simpler
<psykose>
until it doesn't work ;)
<courmisch>
return an error when the only possible errors are UB is just dumb
<elenril>
pthread_mutex_unlock cannot fail if you're using it correctly
<courmisch>
elenril: but it returns an int
<elenril>
you can ignore it
<courmisch>
and it makes zero sense for mutex_init to be allowed to fail
<courmisch>
any sane mutex implementation is just a data structure, it shouldn't be possible to fail to create
<elenril>
why couldn't it allocate internally
<courmisch>
because that's inefficient and bug-prone
<courmisch>
the only point of pthread_mutex_t is that it can be used over shared memory. Now when was the last time you used that feature?
<courmisch>
yeah, me neither
cone-496 has joined #ffmpeg-devel
<cone-496>
ffmpeg Anton Khirnov master:0fcea80b2a32: fftools/ffmpeg: replace InputStream.file_index by a pointer
<cone-496>
ffmpeg Anton Khirnov master:882bc8049dea: fftools/ffmpeg: move InputStream.codec_desc to private data
<cone-496>
ffmpeg Anton Khirnov master:06d5dc11db25: fftools/ffmpeg_sched: actually initialize/destroy schedule_lock
<cone-496>
ffmpeg Anton Khirnov master:84201d8af625: fftools/ffmpeg_filter: move FilterGraph.graph to FilterGraphThread
<cone-496>
ffmpeg Anton Khirnov master:9afe3f527449: fftools/ffmpeg: move InputStream.discard to private data
<cone-496>
ffmpeg Anton Khirnov master:4224895a87dc: fftools/ffmpeg: replace OutputStream.file_index by a pointer
<cone-496>
ffmpeg Anton Khirnov master:116bc5a9f3d1: fftools/ffmpeg: drop unused InputFile.eof_reached
<cone-496>
ffmpeg Anton Khirnov master:2c540976143b: fftools/ffmpeg_demux: move InputFile.readrate to private data
<cone-496>
ffmpeg Anton Khirnov master:0d01e61807b3: fftools/ffmpeg_mux: move OutputStream.sq_idx_mux to private data
<cone-496>
ffmpeg Anton Khirnov master:4549f202227b: fftools/ffmpeg: drop OutputFile.sq_encode
<cone-496>
ffmpeg Anton Khirnov master:98d706b81854: fftools/ffmpeg_sched: move trailing_dts() higher up
<cone-496>
ffmpeg Anton Khirnov master:2305091a3a7b: fftools/ffmpeg: update the reported timestamp at the end
<cone-496>
ffmpeg Anton Khirnov master:5c5140ded2c1: fftools/ffmpeg_sched: track dts+duration as last_dts
<courmisch>
BBB: I suppose that means FFmpeg has been too naughty by Santa Claus standards
<BBB>
nah, it's just organic development - write what you need and testing was considered important later than some simd by itself. it's normal
<BBB>
but ... we can be good citizens and improve the situation
<courmisch>
good luck getting sponsored to write checkasm tests
<courmisch>
or finding enough time and motivation to do much of them on your own
<Gramner>
if having tests is a project requirement for adding new simd the act of writing tests becomes an inseparable part of the work of writing new simd for code where no tests exist. should be easier to justify sponsored resources on tests that way
<courmisch>
you can't do that post-facto
<Gramner>
you can't change the past of course, but you can do that whenever new code is being written
<courmisch>
requiring tests for new DSP functions is fine, requiring tests for new implementation of existing DSP functions just creates a huge penalty threshold on newer code that suddenly gets literally hundreds of tests to write for *existing* code
<Gramner>
also I'm not sure writing tests really slows development of new code down. how do you even write new code without tests? just write something and push it assuming you got everything right on the first try?
<courmisch>
that's a good question. I don't understand how people wrote those existing untested functions
<cosminaught>
do we think adding these tests would likely reveal and fix some bugs? If so there's definitely an easy argument to make for sponsoring some of this work
<courmisch>
but writing checkasm tests is definitely much slower than just writing custom fire-and-forget code
<courmisch>
cosminaught: it's already done it with a depressingly high ratio
<courmisch>
cosminaught: the win64 port seems especially badly broken
<Gramner>
if you write simd for a decoder you can decode the file and verify the hash of the output, but that's slow and very error-prone
<courmisch>
writing tests for code that you didn't write is also slow and very error-prone
<courmisch>
I know what I'm talking about here :(
<jamrial>
courmisch: checkasm tests for previously writen asm functions have revealed issues, yeah. win64 input argument being the most common
<Gramner>
yeah, in some cases that can be true I guess. especially when the input ranges etc. are non-obvious (transforms...)
<jamrial>
despite those never really manifesting in real world scenarios
<Gramner>
in some cases it's just a case of throwing in random data in a buffer, those are easy and fast
<courmisch>
Gramner: my last checkasm test is pretty much one of those simple case, and yet it broke SSE
<Gramner>
although even a rudimentary tests that doesn't cover all edge cases etc. is WAY better than no test
<courmisch>
and I don't know if it's the test being too demanding or SSE being buggy
<jamrial>
it was a win64 input argument failure, was it not?
<jamrial>
in abs_pow34_sse
<courmisch>
the last failure seems to be assuming even length
<courmisch>
it reproduces on Linux too
iive has joined #ffmpeg-devel
<Lynne>
courmisch: printf debugging into where the function is called is how I did it
<courmisch>
Lynne: that's more of a trick to find where you went wrong than if you went right, IMO
<Lynne>
I don't do designs on paper anymore, I just make a plan in my head which I change 50 times as I'm writing it :)
<courmisch>
designs on paper? I only use paper for maths, not for designs
<Lynne>
notepad counts as paper too
<courmisch>
I don't do designs on text editors
<Lynne>
you don't do step by step checking as you're writing code then?
<courmisch>
I wouldn't call writing an assembler kernel "design"
<courmisch>
that terminology might make sense for your complex FFT/DCT stuff
<courmisch>
not for simple loops
elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #ffmpeg-devel
elastic_dog has quit [Client Quit]
elastic_dog has joined #ffmpeg-devel
<Lynne>
yeah, I guess so
<Lynne>
I remember the last time I wrote a simple loop, which turned into a 2 week long saga with insane edge cases
<courmisch>
edge cases are not so common an occurence in RVV
<courmisch>
we don't have to worry much about alignments nor tails