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
guest702 has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
<fflogger>
[editedticket] MasterQuestionable: Ticket #11314 ([avdevice] "alsa" capturing with "-c:a copy" had audio stuttering in AVI) updated https://trac.ffmpeg.org/ticket/11314#comment:7
haihao has quit [Ping timeout: 248 seconds]
haihao_ has joined #ffmpeg-devel
jamrial has quit []
haihao_ has quit [Ping timeout: 265 seconds]
haihao has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 252 seconds]
_whitelogger has joined #ffmpeg-devel
NotWarcop has joined #ffmpeg-devel
Warcop has quit [Ping timeout: 246 seconds]
zsoltiv_ has quit [Ping timeout: 255 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
paulk has quit [Ping timeout: 276 seconds]
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
paulk has joined #ffmpeg-devel
Mirarora has quit [Read error: Connection reset by peer]
deus0ww has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<fflogger>
[editedticket] lanczos-algorithm: Ticket #11317 ([avcodec] Can AVCodec provide more crop information when decoding via MediaCodec?) updated https://trac.ffmpeg.org/ticket/11317#comment:3
Krowl has quit [Read error: Connection reset by peer]
ngaullier has joined #ffmpeg-devel
zenmov_ has quit [Ping timeout: 252 seconds]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 276 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
ngaullie has quit [Read error: Connection reset by peer]
<kurosu>
Is Chris Hodges someone on irc? Rings a bell
deus0ww has joined #ffmpeg-devel
Cheetahze has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Daemon404 has joined #ffmpeg-devel
<JEEB>
elenril: btw it seems like we made AVOptions be applied for outputs before defaults get applied, thus f.ex. `color_trc` and friends stopped working on the output side since the defaults are applied after AVOption was applied
<JEEB>
wonder if we can store the values and apply them after the defaults are set
Daemon404 has left #ffmpeg-devel [#ffmpeg-devel]
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
cone-603 has joined #ffmpeg-devel
<cone-603>
ffmpeg James Almer master:5813e5aa344b: avformat/hevc: fix writing hvcC when no arrays are provided in hvcC-formatted input
<cone-603>
ffmpeg James Almer master:ea91d978e3be: avutil/frame: fix setting plane_padding
<cone-603>
ffmpeg Pavel Koshevoy master:46cb7b8d9dcf: avutil/frame: also align data pointers in av_frame_get_buffer()
<cone-603>
ffmpeg James Almer master:09122bd15c87: avutil/frame: use size_t for total_size in get_video_buffer()
<cone-603>
ffmpeg James Almer master:f0051604c7f1: avformat/movenc: don't write PS NALUs in hvcC for codec tag hvc1
<cone-603>
ffmpeg James Almer master:944212acad7c: avformat/movenc: don't write a calculated avgBitrate when the provided one is unset
<cone-603>
ffmpeg James Almer master:46c6ca3ed165: avcodec/libfdk-aacenc: export CPB properties
<compnnn>
but if anything is unclear or could be added to the docs, let us know as well
<compnnn>
and of course if you have more questions feel free to ask
<steven-netint>
I will be trying to upstream 44k lines of my company's FFmpeg patches. There will probably be lots of questions in the coming months haha
<compnnn>
haha!
<steven-netint>
Thanks for the warm reception
<JEEB>
:)
<JEEB>
you may also bring up here things that you may want comments on before sending to ML
<compnnn>
yea sometimes we do patch reviews here before mailing list patch reviews
<compnnn>
mailing list just gets the most eyeballs
<JEEB>
I'm talking more about general ideas
<compnnn>
well that too
<steven-netint>
alright, thanks
kasper93 has quit [Remote host closed the connection]
<names_are_hard>
Is it normal for some small files to trigger av_codec_iterate() to be called nearly 2000 times?
<names_are_hard>
Possibly relevant line from stdout: [vf#0:0 @ 0x1410d040] Cannot determine format of input 0:0 after EOF
<names_are_hard>
Checking all known codecs and failing to match, possibly?
<BtbN>
If your build has nearly 2000 codecs, yeah
<names_are_hard>
Okay, thanks. And should it be fairly slow? 0.5s
<names_are_hard>
It's some avcodec_find_decoder and avcodec_find_encoder, 700 vs 1200
<BtbN>
impossible to tell what's going on. But if you try to decode something with all decoders there are, doing it in less than a second seems quite fast
<jamrial>
first call might be slow since it will run av_codec_init_static(), but every call after the first should be fast
<names_are_hard>
I'm not specifically trying to use all codecs, it's ffmpeg -i sample -f null -
<BtbN>
well, if it can't tell what the sample is whatsoever, it'll try what it can and give up
<names_are_hard>
Then maybe this line is relevant? [jpeg_pipe @ 0x140e6c40] Format jpeg_pipe detected only with low score of 7, misdetection possible!
<BtbN>
What is the actual issue?
<names_are_hard>
I'm restricting the file header to jpeg magic ff df ff, unsure if that should make a difference
<names_are_hard>
The problem is it really slows the fuzzer down
<names_are_hard>
So, not your code as such (probably?) but makes testing inefficient
<BtbN>
Probing every last possibility is just going to be relatively slow
<names_are_hard>
It does feel unusually slow though. Maybe because it has to start a thread per codec probe?
<names_are_hard>
That's a bunch of context switches
<BtbN>
I don't even think codecs have something like "probing". Formats do.
<names_are_hard>
On samples that get detected (I guess? They don't call avcodec_find_encoder, anyway), I can do approx 250 exec/s, on ones where it has the pattern of high avcodec_find_encoder calls, it's 2 exec/s
<BtbN>
Just blindly generating a completely random file and then seeing what happens seems incredibly inefficient anyway to me
<BtbN>
The chance to hit something that way is gonna be incredibly low
<names_are_hard>
I don't know your terms for things, sorry if I get that part wrong. It's this call in av_codec_iterate() that makes me mildly suspicious: ff_thread_once(&av_codec_static_init, av_codec_init_static);
<names_are_hard>
So I think we need to create and destroy 2000 threads to check the format?
kasper93 has joined #ffmpeg-devel
<jamrial>
that's called once, as the name implies
<BtbN>
Why would that create a thread anyway?
<BtbN>
I'd assume it just uses some atomic internally
<names_are_hard>
I was just guessing from the name
<names_are_hard>
It gets called 2000x times, so ff_thread_once() will fire 2000 times
<BtbN>
yes, and only do something the first time
<BtbN>
that's its whole job
<names_are_hard>
Ah, okay
<names_are_hard>
Not obvious why the cost is so high then
<BtbN>
some codecs do relatively expensive static inits
<BtbN>
like, generating large tables
<BtbN>
to avoid high runtime cost, in exchange for ram usage
<names_are_hard>
Callgrind thinks approx the same number of cycles, so I was assuming something non CPU, waits or context switches etc
<names_are_hard>
Re inefficiency of testing: I'm not generating samples randomly, or blindly. It's a coverage guided fuzzer. They're efficient for the field
<names_are_hard>
But it would be about 50x faster if I could avoid this cost
Cheetahze has quit [Quit: Connection closed for inactivity]
<names_are_hard>
Ah cool, useful info from strace, maybe: 96.96 0.501071 8214 61 1 futex
<names_are_hard>
Almost all the time cost is futex
cone-191 has joined #ffmpeg-devel
<cone-191>
ffmpeg Scott Theisen master:0dceced45c52: avformat/mpegts: add DVB descriptor_tag values already in use
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
Everything has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
NotWarcop has quit [Remote host closed the connection]
<names_are_hard>
Found the root cause. In fftools/ffmpeg.c, transcode(), we have: while (!sch_wait(sch, stats_period, &transcode_ts)) {
<fflogger>
[editedticket] Balling: Ticket #11319 ([avformat] http download without Content-Length warns about ending prematurely) updated https://trac.ffmpeg.org/ticket/11319#comment:1
<names_are_hard>
In fftools/ffmpeg_opt.c we have int64_t stats_period = 500000;
<names_are_hard>
So, there's a forced wait of 0.5s
<names_are_hard>
If I lower that magic number, it's fast. Is that likely to break anything?
<fflogger>
[editedticket] daveisfera: Ticket #11319 ([avformat] http download without Content-Length warns about ending prematurely) updated https://trac.ffmpeg.org/ticket/11319#comment:2
<names_are_hard>
I see: "Set period at which encoding progress/statistics are updated. Default is 0.5 seconds"
<names_are_hard>
I would say that's a bug. If your file takes less than stats_period to finish decoding (or whatever?), there's a forced pause to gather stats on something that's already finished