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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
qeed has joined #ffmpeg-devel
Livio_ has joined #ffmpeg-devel
Livio has quit [Ping timeout: 255 seconds]
rvalue has quit [Ping timeout: 260 seconds]
lexano has quit [Ping timeout: 240 seconds]
rvalue has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
s55 has quit [Read error: Connection reset by peer]
s55 has joined #ffmpeg-devel
qeed has quit [Remote host closed the connection]
jamrial has quit []
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 260 seconds]
jarthur has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
cone-039 has quit [Quit: transmission timeout]
chainik1 has quit [Quit: (╯°□°）╯︵ ┻━┻]
chainik1 has joined #ffmpeg-devel
bilboed has quit [Quit: Ping timeout (120 seconds)]
bilboed has joined #ffmpeg-devel
rajivharlalka has joined #ffmpeg-devel
<rajivharlalka>
Hi, I have written my first test : [PATCH] tests/fate/filter-audio.mak: add test for ATEMPO audio filter . Would be happy to receive feedback and reviews on it.
<rajivharlalka>
Though on a side note, was trying to understand what does the fate exactly tries to test for. Is it just for compatibility on different env?
<rajivharlalka>
as I could see the outputs of the tests are it's generated by the built tool, hence couldn't find a actual way to see if the output is what I actually desired.
<JEEB>
FATE tests correctness and that the correct result is received across architectures/systems
<rajivharlalka>
That makes sense and what I expected. Is there something that is done/could be done similar to what the unit/integration etc tests exist.
Wenbin_Chen_ has joined #ffmpeg-devel
<JEEB>
there are unit tests as well which are put into FATE as well, see as an example the recent test I added for the side data array stuff
<rajivharlalka>
Sure. But firstly I need to look why my patches fail on patchwork everytime. something's wrong/
<Traneptora>
rajivharlalka: patchwork runs make fate. what happens locally when you run make fate?
<Traneptora>
you may want to acquire the sample suite. to do so: make fate-rsync SAMPLES=./ffmpeg-samples/
<Traneptora>
and then you can do make fate SAMPLES=./ffmpeg-samples/
<rajivharlalka>
fetching samples would take some time for me, rsync blocked on my university network 🃏
<Traneptora>
that is a really interesting thing to block
<rajivharlalka>
would be more interested when you know that 80 and 443 are the only ports open :)
<Traneptora>
that's gotta disrupt some protocols if I've seen it
<rajivharlalka>
so inevitably, we dont have access to anything except 'some' websites.
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
<Lynne>
I'm not sure if I need to do a lookup using ref_frame_idx[i] in cbs_ctx->ref[i].saved_order_hints
<Lynne>
the ref frame bias is saved in the picture context when the frame is decoded
Krowl has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 255 seconds]
ngaullier has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 268 seconds]
Workl has quit [Read error: Connection reset by peer]
yigithan has joined #ffmpeg-devel
yigithan has quit [Remote host closed the connection]
yigithan has joined #ffmpeg-devel
yigithan has left #ffmpeg-devel [#ffmpeg-devel]
yigithan has joined #ffmpeg-devel
yigithan has quit [Remote host closed the connection]
rajiv_ has joined #ffmpeg-devel
thelounge6949 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
wbs has quit [Ping timeout: 256 seconds]
thelounge6949 has quit [Client Quit]
ngaullier has quit [Read error: Connection reset by peer]
wbs has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
signalhunter has quit [Quit: Zzz]
Wenbin_Chen__ has quit [Ping timeout: 272 seconds]
<BtbN>
No
<BtbN>
aaabbb
<BtbN>
I think the only actual correct fix would be to reject invalid sizes
IndecisiveTurtle has joined #ffmpeg-devel
MetaNova has quit [Ping timeout: 246 seconds]
MetaNova has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
<haasn>
elenril: do options like -strict that exist for both avcodec and avformat get forwarded to both on the command line?
cone-879 has joined #ffmpeg-devel
<cone-879>
ffmpeg James Almer master:97d2990ea624: avformat/iamf_reader: propagate avio_skip() error values
yigithan has joined #ffmpeg-devel
yigithan has quit [Remote host closed the connection]
yigithan has joined #ffmpeg-devel
signalhunter has joined #ffmpeg-devel
ngaullier has quit [Read error: Connection reset by peer]
jamrial has quit [Read error: Connection reset by peer]
<mkver>
haasn: IIRC strict is forwarded to lavc only; that's why there is f_strict
jamrial has joined #ffmpeg-devel
<haasn>
I see
<yigithan>
Hello, I want to fix #9613 (volumedetect), I have to implement a histogram for float audio. Should I use 65536 bins histogram which is same as 16 bit integer that already in filter. If yes should I scale and distribute float values according to Min and Max values or distribute full range. I was thinking to implement both of them and while printing stats I can choose best one on the fly acc
yigithan has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<haasn>
we don't have put_ue_golomb()? :(
<jamrial>
haasn: maybe set_ue_golomb?
<haasn>
oh, indeed
<haasn>
strange naming
<jamrial>
yeah
<cone-879>
ffmpeg James Almer master:456c8ebe7c7d: avcodec/hevc_ps: allocate only the required HEVCHdrParams within a VPS
Krowl has joined #ffmpeg-devel
<haasn>
(-n) >> x is implementation defined behavior right?
<haasn>
can we assume it does sign bit extending shift or not?
<mkver>
haasn: We already presume it.
IndecisiveTurtle has quit [Ping timeout: 240 seconds]
<haasn>
great, thanks
<mkver>
(This has been explicitly documented in b706ddbae3f4a11, but elenril removed it in 9177556bb9493.)
<mkver>
elenril: Was this intentional?
<elenril>
probably not
kurosu has quit [Quit: Connection closed for inactivity]
<mkver>
Does configure actually distinguish between flags for the C preprocessor and e.g. the C++ preprocessor?
<jamrial>
don't think so
<Marth64>
so it looks like if muxing two files in one command, and one muxer fails to write headers, process hangs waiting for that muxer's thread to start
<Marth64>
i have been looking into it
<mkver>
Should ping elenril on that
<jamrial>
Lynne: can you review "[PATCH 1/2] avcodec/hevc_ps: fix setting HEVCHdrParams fields"?
<Marth64>
elenril: #10916
<Marth64>
will keep you posted, i have tracked down potential problem area in the mux/sched code and learning it in the process.
<Marth64>
if one mux_check_init fails but another succeeds, scheduler still waits on thread join for the failing muxer
<jamrial>
happy equinox btw
<Marth64>
indeed, spring is nice
<Marth64>
i am just worried someone runs this in a batch job with no timeout and triggers the condition, they will hang
Krowl has quit [Ping timeout: 264 seconds]
Krowl has joined #ffmpeg-devel
<Marth64>
(whch is exactly how i found it)
kurosu has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Ping timeout: 264 seconds]
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Ping timeout: 256 seconds]
Krowl has quit [Ping timeout: 255 seconds]
Krowl has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Ping timeout: 252 seconds]
MisterMinister has joined #ffmpeg-devel
* Sean_McG
peeks in
<Marth64>
gm!
<Sean_McG>
you too
Krowl has quit [Read error: Connection reset by peer]
<mkver>
Lynne: I don't like that you are initializing both the static fixed and float tables for each decoder.
<Lynne>
ah, good point
Marth64 has quit [Ping timeout: 255 seconds]
Marth64 has joined #ffmpeg-devel
<michaelni>
mkver, if you want something changed for the sh4 box easiest is to send me a patch against: https://pastebin.com/Tf5H9JNM
<mkver>
I actually wanted you to test whether that configure patch makes this box compile again.
<michaelni>
mkver, i have no local sh4 setup anymore, the fate client is the last i have, i could test it but i first need to figure out how it worked in the past ...
tufei has quit [Remote host closed the connection]
<mkver>
michaelni: Same for alpha, I presume?
<JEEB>
&48
tufei has joined #ffmpeg-devel
<michaelni>
i dont have the alpha-linux-gnu-gcc-4.7 that i used previously but i seem to have some others interrestingly
<Daemon404>
52
<michaelni>
mkver, the alpha one i have locally builds without your patch already (built with gcc 8 (Ubuntu 8.4.0-1ubuntu1~18.04)) thats alpha-linux-gnu-gcc-8
<mkver>
That is not surprising; the new gcc uses proper C11 headers that #define static_assert _Static_assert
<michaelni>
which version do we need for this ?
<mkver>
For your old fate-boxes (GCC 4.7) that apparently use non-C11 headers.
<BtbN>
glibc pre-2.28 does not support C11
<BtbN>
That means minimum CentOS 8 or Ubuntu 20.04.
AbleBacon has joined #ffmpeg-devel
<Daemon404>
18 is eol
<Daemon404>
even 20 is soon
<Daemon404>
as will be centos 8
<Daemon404>
i actually thought we dropped alpha explicitly, years ago.
<mkver>
BtbN: How did you arrive at 2.28? We don't use C11 threads, so the note on C11 threads in the release notes for 2.28 doesn't apply.
<BtbN>
Some dependencies do though, and have wild assumptions in their headers
<michaelni>
btw the alpha binary of ffprobe i just build works under qemu :)
<BtbN>
Most notably OpenAL will break completely when C11 is enabled but there is no threads.h
<mkver>
Daemon404: We still have alpha ASM; Libav probably has removed the alpha-specific code, but anyway FFmpeg should compile on alpha just as it should compile on any posix system.
<mkver>
BtbN: Then these are restrictions of dependencies, but not of FFmpeg.
<Daemon404>
i agree assuming such systems exist and are actually updated
<Daemon404>
unlike e.g. 1386.
<Daemon404>
i386*
<michaelni>
sh4 binary off ffprobe also works
<mkver>
michaelni: Are you compiling with new GCC/new headers or with my configure patch?
<michaelni>
i compile with the oldest compiler thats available on the oldest box i have ;)
<michaelni>
i would have to test on the fate client itself
<michaelni>
thats even older
<mkver>
That is too new to actually test my patch.
<mkver>
Yes, that's why it is currently broken.
<JEEB>
sounds like some ubuntu 16 docker container or something could be used to test since the c11 stuff is not limited to some specific arch, right?
<mkver>
Exactly.
<michaelni>
mkver, maybe you can just push it and see if it fixes it ?
<JEEB>
I think I have podman in my dev VM, let me pull xenial. I think that has 4.7 or 4.8
<mkver>
Ok, but first I wait for wbs.
<JEEB>
podman run --rm -it ubuntu:xenial brought me a shell :)
<mkver>
JEEB: Hopefully it also has the same old headers.
<Marth64>
apt-get install build-essential :D
<JEEB>
wat, xenial already had 5.3
<JEEB>
mein gott
<JEEB>
time to go older
<JEEB>
ok, debian jessie (8) has 4.8 :D
<mkver>
Lynne: You have several AAC_RENAME in your aacdec.c that make no sense given that this file is not templated.
rvalue has quit [Ping timeout: 252 seconds]
<JEEB>
lol
<JEEB>
first thing to fail with 4.8 is vvc_mc.asm
Krowl has quit [Read error: Connection reset by peer]
<JEEB>
well, not really gcc but nasm
rvalue has joined #ffmpeg-devel
<mkver>
JEEB: That means it has already compiled libavcodec/ccaption_dec.c. Did you use my configure patch?
<JEEB>
ok, so then the headers are new enough here, or the failure is only on 4.7
<JEEB>
I was testing vanilla first :)
<mkver>
Then this toolchain is unaffected by the issue.
<mkver>
I now also sent a second patch that does not provide fallback defines, but simply tests for static_assert.
<JEEB>
went further down history lane
<JEEB>
gcc 4.7 here we go
<JEEB>
yes! git.videolan.org still lets you clone over HTTP :D
<JEEB>
(TLS stuff is too old)
<JEEB>
-_- so ubuntu 14.04 also has new enough headers :D
<JEEB>
avcodec/ccaption_dec.c still compiling
Marth64 has quit [Remote host closed the connection]
<mkver>
JEEB: Thanks for your efforts; there is really no reason to waste any more of your time on this.
<mkver>
IMO this is a good reason to fix this in michaelni's builds by adding --extra-cflags=-Dstatic_assert=_Static_assert
<JEEB>
mkver: yea, not to mention that the next one backwards (13.10) even fails to run as a container :D
elastic_dog has quit [Ping timeout: 255 seconds]
elastic_dog has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 259 seconds]
cone-929 has joined #ffmpeg-devel
<cone-929>
ffmpeg James Almer master:535b1a93f56a: avcodec/hevc_ps: fix setting HEVCHdrParams fields
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Remote host closed the connection]
<BtbN>
hm, this xstack situation is definitely weird
<BtbN>
I just can't think of a clean solution other than bailing if non-even-resolutioned subsampled frames come in
<BtbN>
Like, take for example someone wanting to vstack two 3x3 sized frames. It would generate a frame of 3x6, or subsampled to 1.5x3. All the calculations for the subsampling use AV_CEIL_RSHIFT, i.e. they round up.
<BtbN>
So it'll then try to write a 2 pixels worth of height (rounded up from 1.5) starting at row 2, cause also rounded up
<BtbN>
and in turn overwrite the frame
Traneptora_ has joined #ffmpeg-devel
<Traneptora_>
I would like to add the abiilty to seek to a demuxer, but I'm not sure where to start
<BtbN>
well, first would be to find out if the format can be seeked in in the first place
<Traneptora_>
BtbN: in this case I want to allow seeking to 0
<Traneptora_>
to seek to the start of file
<Traneptora_>
the format is jpegxl_anim, which is generally non seekable, but I want "seek to 0" to work
Mister_D has joined #ffmpeg-devel
<Lynne>
Traneptora_: .read_seek = fn() { avio_seek(s->pb, 0, SEEK_SET); return 0; } or along the lines
MisterMinister has quit [Ping timeout: 272 seconds]
<Traneptora_>
Lynne: what arguments does read_seek take? how do I return "this seek failed" for nonzero seeks?
<mkver>
Traneptora: The pos of the packet returned is wrong (off by the initial size).
<Traneptora_>
what do you mean?
<mkver>
Wait, it does not use av_get_packet(). Then it is simply wrong.
<Traneptora_>
what is simply wrong?
rodgort has quit [Quit: Leaving]
<Lynne>
stream_id, timestamp and flags, you may also need to call avpriv_update_cur_dts(0)
<Traneptora_>
what are you guys referring to
<mkver>
The position of the returned packet will be -1 (i.e. unknown). But then you can't use AVFMT_GENERIC_INDEX at all.
<Traneptora_>
please clarify, I'm missing context
<Traneptora_>
is the existing code wrong? what is wrong about it?
<Traneptora_>
what is it doing that it shouldn't do, and what should it do instead?
Kei_N_ has quit [Read error: Connection reset by peer]
<mkver>
With this patch, -stream_loop works with streamcopy; decoding does not really work because the timestamps are unset and lots of frames are dropped.
<mkver>
For normal demuxers: No. But your demuxer returns the whole file in one packet.
<Traneptora_>
if the file is seekable, if it's a stream it reads 4096
<Traneptora_>
e.g. from a pipe
<Traneptora_>
decoding works before this patch, so does that make this a regression?
<mkver>
What regresses?
<Traneptora_>
well decoding works
<mkver>
What regressed?
<Traneptora_>
in git master, right now, decoding works
<mkver>
decoding with -stream_loop still does not work.
<mkver>
Without this patch, even demuxing does not work with -stream_loop.
<Traneptora_>
oh, I see. how would one fix it? the decoder ignores the demuxer timestamps
<mkver>
The demuxer does not set timestamps.
<mkver>
Not even using AVSTREAM_PARSE_FULL_RAW provides them.
<Traneptora_>
mkver: demuxer can't really provide timestamps. can the parser do that?
rodgort has joined #ffmpeg-devel
<mkver>
Strange. If i set pkt->pts and dts to zero in the demuxer, ffprobe says that the pts and dts of the returned packet are -2.
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
Wenbin_Chen__ has joined #ffmpeg-devel
<Traneptora_>
mkver: I see your fix, I'm seeing if I can commit a more elegant solution that also takes into account the streaming case
<mkver>
That should be simple: pos = avio_tell - initial->size is the position of the returned data.
<Traneptora_>
well, not necessarily. if initial isn't null then it's the first packet
<Traneptora_>
otherwise initial will be null. I have a size_t count; in the context, and then I zero it when initial is non-null, and set it to count++
<Traneptora_>
I think that should work
<mkver>
Yeah, and that is why I subtract the size of initial.
<Traneptora_>
oh that's a minus
<Traneptora_>
I misread that
<Traneptora_>
avio_tell - offset, but yea, that'll work
<Traneptora_>
although, in the event that it's not the first packet, avio_tell will be zero, and initial will be null (as it's unrefed immediately), so its size will have to be cached somewhere
<Traneptora_>
er, not avio_tell, but initial->size
<mkver>
?
<mkver>
If it is not the first packet, avio_tell won't return zero (why should it do so?).
<Traneptora_>
typo
wyatt8740 has joined #ffmpeg-devel
wyatt8750 has quit [Ping timeout: 256 seconds]
wyatt8750 has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 256 seconds]
<Traneptora_>
mkver: sent to ML
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
<Lynne>
why do some non-install headers do FF_VISIBILITY_PUSH_HIDDEN?
<BtbN>
so the symbols don't end up exported
<Lynne>
but they're prefixed with ff_, those don't get exported
<BtbN>
Only when linking with the ffmpeg linker script
<BtbN>
Which also isn't supported by all platforms
<Lynne>
the macro is only defined for gcc, doesn't that universally support it?
<Lynne>
also, why some headers, but not all?
<BtbN>
I think it's relatively new? It should probably be used everywhere
<wbs>
Lynne: when referencing a symbol in a different object file, the compiler can generate more efficient code for the access, if the declaration indicates that the variable is hidden (i.e. won't be referenced from another .so)
<BtbN>
gcc supports it, sure. I'm thinking of stuff like MSVC
<wbs>
(and iirc that was part of the reason for adding it)
<jamrial>
that macro broke riscv gcc for jdek, btw
mkver has quit [Ping timeout: 256 seconds]
<Lynne>
I'm guessing we can't hide everything by default and export what we need like dav1d
<jdek>
jamrial: didn't get a chance to look into it yet though
<wbs>
see the commit message of e.g. e10e27a2ead8848648b29a1b397cc240206e9c3d and 0b95a6a1d0b3d9c06aedd5fc929804661addd263
<jamrial>
jdek: if you revert the commit i mentioned, it should compile again
cone-929 has quit [Quit: transmission timeout]
Traneptora_ has quit [Quit: Quit]
Marth64 has quit [Changing host]
Marth64 has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
rajivharlalka has quit [Quit: Connection closed for inactivity]
<BtbN>
I don't see a problem with just a global default visibility hidden
<BtbN>
given we export explicitly via a linker script as well
<Lynne>
problem is compiler support
<Lynne>
oh, windows by default exports nothing, and -fvisibility=hidden is supported by gcc/clang for decades
<Lynne>
and if it isn't, everything gets exported by default, which still works fine on minor compilers
<Lynne>
I think that's better than explicitly marking what should be hidden, I don't want to start adding pragmas to every header
mkver has joined #ffmpeg-devel
<mkver>
Lynne: So that the compiler knows that these symbols come from the same DSO.
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
Wenbin_Chen__ has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
<mkver>
When you use -fvisibility=hidden, GCC and Clang mark things defined in the same translation unit as hidden; but they don't expect everything from other translation units to be from the same DSO and produce suboptimal code.
<Lynne>
mkver: so visibility=hidden wouldn't help with speeding up table access?
<mkver>
When the table is declared in the translation unit, then the compiler can infer from fvisibility=hidden that this table won't be interposed and can therefore optimize as if the table were static. But if the table is from a different translation unit, then it has to be presume the worst: That this thing is interposed.
<Gramner>
'-fvisibility=hidden' only applies to definitions, not declarations
<mkver>
Yes. And therefore it is not as powerful as declaring visibility via attributes/pragmas.
<Gramner>
you can do both
<Gramner>
-fvisibility=hidden to hide symbols by default, and attributes/pragmas on data symbol declarations to improve code gen