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
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
lexano has quit [Ping timeout: 256 seconds]
<mkver>
jdek: Your debug report is crazy: There is no --enable-shared in your configure command line, yet it creates shared libs although we default to static libraries.
<mkver>
Is lavf/iamf.o built with your config?
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Ping timeout: 272 seconds]
<mkver>
Gramner: Why only on data symbols? When the compiler has to presume that a call will happen through the plt, the generated code may be worse (e.g. for 32bit x86, probably also for other arches than x64).
Marth64 has quit [Remote host closed the connection]
<Gramner>
mainly because it's annoying to do it for every function symbol, and on decent architectures it only matters for data symbols post-linking
rvalue has quit [Ping timeout: 264 seconds]
<Gramner>
and for 32-bit x86 the only relevant os is windows, where it's not applicable
<Lynne>
we already define most tables using DECLARE_ALIGNED, maybe we can sneak a visibility into the macro?
rajivharlalka has left #ffmpeg-devel [#ffmpeg-devel]
rajivharlalka has joined #ffmpeg-devel
<haasn>
elenril: well, it breaks all users of this filter
<haasn>
Probably the correct way forward involves either rewriting framesync to support multiple outputs, or rewriting scale2ref to use a custom activate function
<elenril>
does scale2ref even need to exist?
<haasn>
But doing the latter is annoying because it would require reimplementing all of ff_filter_activate_default , while not being able to reuse any of its components
<haasn>
elenril: *shrug *
<elenril>
deprecate scale2ref, replace with the version with one output?
darkapex has quit [Ping timeout: 268 seconds]
darkapex has joined #ffmpeg-devel
<haasn>
To be honest I’m not happy with how it requires the use of the split filter either
<haasn>
Well
<haasn>
We could add the ability to do this to vf_scale itself, in theory
<haasn>
Would solve some other issues with the patch as well
<haasn>
Like adding an extra input option to vf_scale
<haasn>
Or even arbitrarily many
<haasn>
I like that approach the most, I think
<elenril>
you'd need to invent a syntax for referring to those arbirarily many inputs
mkver has joined #ffmpeg-devel
<haasn>
that would also break the inversion of main and ref params that scale2ref does, which is convenient because it allows the default formula of w=iw and h=ih to continue working
<haasn>
hrm
<haasn>
elenril: here's an idea that might just work, and IMO makes this filter a bit more well-principled (and reduces the amount of special cases)
<haasn>
we add new variables ref_w, ref_h; and at filter init time we add a second input IFF one of these variables is used in any expression
<haasn>
so -vf [a][b]scale2ref[out] becomes [a][b]scale=w=ref_w:h=ref_h
<elenril>
can we easily detect that?
<haasn>
yes
<haasn>
we already do it at init time to detect illegal formulas
<haasn>
maybe if AVExpr was more flexible we could allow for multiple inputs like iw2 iw3 iw4 etc.
<elenril>
fflisp, your time has come
<haasn>
ffjs
<haasn>
in a completely unrelated note, is there an existing helper function somewhere to convert an AVRational to a given denominator, giving the closest numerator (possibly rounding)?
<haasn>
av_reduce() exists but seems a bit clumsy
<haasn>
and not sure if it solves that problem exactly
<haasn>
av_expand(av_make_q(1, 2), 10) = 5
<haasn>
round(av_q2d(q) * den) does it
<haasn>
but can it be done without floats
lexano has joined #ffmpeg-devel
<haasn>
I guess what I want is the equivalent of av_reduce(&out, NULL, q.num * den, q.den, 1); where the `1` applies only to limit q.den, not q.num
<haasn>
q2 = av_mul_q(q, av_make_q(den, 1)); (q2.num + (q2.den >> 1)) / q2.den also does it
omegatron has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
Wenbin_Chen_ has joined #ffmpeg-devel
elastic_dog has quit [Ping timeout: 260 seconds]
cone-407 has joined #ffmpeg-devel
<cone-407>
ffmpeg Andreas Rheinhardt master:ee736ff80ed9: avformat/flvenc: Avoid avio_write(pb, "", 0)
SystemError has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
elastic_dog has joined #ffmpeg-devel
<JEEB>
elenril: scale2ref is useful for subtitles on video; f.ex. DVB subs can change their canvas size, compared to the video res (HD subs on HD surface, then switching to SD subs on HD surface etc)
dykai has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
dykai has quit [Quit: dykai]
<elenril>
does anyone know what's the status of suncc?
<elenril>
last oracle studio seems to be july 2017
<JEEB>
I would be surprised if they still poked at it actively
<elenril>
it does seem to support c11 though
<elenril>
...which means we can probably drop emulated atomics
<elenril>
but I don't suppose anyone can actually test that
<cone-407>
ffmpeg Zhao Zhili master:c775163a8c03: avcodec/decode: log hwaccel name
<cone-407>
ffmpeg Zhao Zhili master:4869171aa911: Changelog: mention ffplay with hwaccel decoding support
jamrial has joined #ffmpeg-devel
<haasn>
elenril: if I attach side data to the first AVPacket generated by an encoder, will it end up in the bitstream in the same way that AVStream->codecpar->coded_side_data would?
<elenril>
you mean in the muxed file?
<haasn>
yeah
<haasn>
basically can I just attach the correct dovi configuration record to the first AVPacket
<elenril>
depends on the muxer
<elenril>
in general the semantics is different
<elenril>
codecpar side data by definition applies to the whole stream
<elenril>
for packet side data it's not clear, and really depends on the side data type
<haasn>
awkward
<haasn>
even more awkward is that for something like whether or not an enhancement layer is present, the correct decision can't even be made by the encoder itself
<elenril>
IMO if you want it to apply to the whole stream, the encoder should put it in coded_side_data on encoder init
<haasn>
it seems that the dovi configuration record needs to be synthesized by some layer in between the encoder and the muxer, which knows how many streams there are (and whether there is an enhancement layer), but also whether the individual frames contain RPUs
<elenril>
if at all possible
<haasn>
oh, we could do that
<haasn>
in particular if we have an encoder option for it
<haasn>
though auto-detection would require looking at the first frame
<elenril>
looking at what in the first frame?
<haasn>
presence/absence of AV_FRAME_DATA_DOVI_METADATA
<haasn>
and the colorspace fields
<elenril>
at least ffmpeg CLI does have the first frame when opening th encoder
<haasn>
though I guess colorspace fields are known at the avctx level
<elenril>
but also I've just been thinking we might want a global-side-data field in lavfi source/sink
<JEEB>
yea, at init point in theory they should be @ color
<haasn>
elenril: what happens if AVCodecContext.coded_side_data and AVStream->codecpar->coded_side_data contain the same side data
<elenril>
huh?
<elenril>
for which process?
Krowl has joined #ffmpeg-devel
<haasn>
for transcoding in ffmpeg.c
<elenril>
typically for demuxing you propagate codecpar to codec context
<JEEB>
haasn: also after my commit you now have AV_FRAME_DATA_DOVI_METADATA of first AVFrame in avctx
<elenril>
and the reverse for muxing
<haasn>
JEEB: oh neat
<elenril>
so containing the same side data is normal and expected
<JEEB>
under decoded_side_data
<JEEB>
(it's really "user asked for this configuration" side data)
<haasn>
somehow my email client stopped picking the right sender email to reply to the ML with, IFF I'm replying to elenril
<haasn>
:shrug:
<elenril>
mwahaha
<elenril>
some convoluted mail-followup-to handling maybe?
<haasn>
in other news, I implemented full generation of dovi RPUs from the decoded structs
<jamrial>
nice
<elenril>
what does RPU stand for again?
<haasn>
I think JEEB knows
<elenril>
seems everyone knows that, but I don't follow these newfangled things
<haasn>
it's just some generic non-term
<haasn>
but RPU = per-frame struct
<jamrial>
i bet r stands for raw
<haasn>
as opposed to the configuration record = per-stream struct
<haasn>
.. as would have been explained in the email that the ML ate
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
<elenril>
haasn: so the configuration record should not be propagated beyond the decoder, right?
Marth64 has joined #ffmpeg-devel
<Sean_McG>
Marth \o
<elenril>
haasn: my position is basically that that block should not exist at all in its current form
<Marth64>
gm Sean, et. al. happy friday
<elenril>
because it teleports data that should be propagated along the pipeline
Krowl has quit [Read error: Connection reset by peer]
<Marth64>
everything teleports data now. sad state of internet affairs
<jamrial>
elenril: container cropping propagation also depends on that block, so what would be the alternative? adding fields to buffersrc and buffersink?
<elenril>
teleportation is sinful
<elenril>
jamrial: isn't it attached to frames?
<elenril>
jamrial: did we add container cropping side data yet?
<jamrial>
no
<jamrial>
because of that block :p
<elenril>
heh
<jamrial>
it comes from demuxers, and would be propagated through codecpar->coded_side_data
<elenril>
cropping should be applied at the decoding/filtering stage anyway
<jamrial>
in my last set ffmpeg.c would insert a crop filter if it finds it, i think
<elenril>
so why would you want to propagate it to the encoder
<BtbN>
A bunch of codecs have cropping info in the bitstream
<jamrial>
you did not like it for the same reasons as the above
<elenril>
yay, yet more teleportation
<jamrial>
teleporting and that the block itself should not exist
cone-407 has quit [Quit: transmission timeout]
cone-809 has joined #ffmpeg-devel
<cone-809>
ffmpeg Andreas Rheinhardt master:c89f6ae6899e: avcodec/libdav1d: Stop mangling AVPacket.opaque
<cone-809>
ffmpeg Andreas Rheinhardt master:3fd047ee3057: avcodec/librav1e: Don't unnecessarily create new references
<haasn>
quietvoid: wait, really? I could have sworn somewhere that it's written that AV1 does not use a config record
<haasn>
but actually, you're right, looking at my test streams it does seem it uses a different profile.. agh
<haasn>
quietvoid: ah, it was your sample files from that MR (av1-large.ivf) that does not have a config record
<haasn>
but official DV test streams do seem to have it
<JEEB>
ivf is basically not a container, so not surprising
<JEEB>
config records are container level metadata usually
<haasn>
okay that makes sense
<haasn>
15:43 <@elenril> haasn: so the configuration record should not be propagated beyond the decoder, right? -> except for transcoding
<haasn>
where you probably want to preserve it as-is
<haasn>
err, remuxing*
<jamrial>
yeah, same situation as container cropping
<haasn>
for transcoding yeah you can strip it after decoding because all the relevant data can be reconstructed from the frame-level RPU
<elenril>
haasn: there's no decoding in streamcopy
<haasn>
right
<elenril>
I meant just transcoding
<elenril>
so this problem would go away just by getting rid of that block entirely
<haasn>
yes, so if the decoder strips this data it would be perfectly sufficient for our use case
<haasn>
I think so
<haasn>
do you want to send a patch?
<elenril>
working on it
<haasn>
okay, then I'll continue working on the encoder side for now
<JEEB>
mkver: hah that double frame_data. that is a funky one
<mkver>
JEEB: It is idempotent, nothing leaks.
<JEEB>
that's positive :) anyways, LGTM'd that. quickly looked at the patches regarding my recent additions, and yea the old API not being consty while the new API was got funky
<JEEB>
will probably give a LGTM to the bunch after grabbing something to eat
<JEEB>
elenril: btw my next step in that avctx side data stuff is to add first lists to the encoder definitions regarding which side data they support, which should then allow for ffmpeg.c to not copy all the things, but only the stuff that the encoder flags as supported.
<JEEB>
I wonder if that alleviates your concern regardign that
<JEEB>
(and also for codec-generic logic there probably should be a list for the codec_id)
<JEEB>
so that you wouldn't have to integrate the same logic for each encoder for format X
<JEEB>
I just did not want to add it into the initial set because the initial set seemed to get thrown around during review and the more you add the more you have to rework each time you're asked to rework stuff
ngaullier has quit [Ping timeout: 260 seconds]
<Marth64>
will have RCWT dec fixed up in the next few hours. will continue to focus on the CLI hang bug after
<Marth64>
it has been kind of fun to learn the scheduler logic, it is overall clean and easy to follow
<jamrial>
elenril: that looks good, but will it help handling container cropping?
<elenril>
JEEB: maintaining a per-encoder list sounds cumbersome
<elenril>
it seems preferable to have a per-side-data-type list
<elenril>
that tells you things like "this side data makes sense in global headers"
<JEEB>
my original reason for an encoder list was actually `ffmpeg -h encoder=libsvtav1` :D
<jamrial>
that's what we have in decode.c
<elenril>
or "this side data can be meaningfully present multiple times"
<JEEB>
so that would then list Supported configuration side data: blah or so
<elenril>
"configuration"
<JEEB>
I'm not limited to that word, just wanted to put some wording out :)
s55 has quit [Ping timeout: 260 seconds]
<elenril>
I don't really see what you even mean by that word
<JEEB>
the side data is passed to the encoder to correctly configure the encoder or to take stuff into account
<JEEB>
like the HDR10 metadata being for me encoder config
<elenril>
global side data, in other words
<JEEB>
pretty much, yes
<JEEB>
since dynamic stuff is supposed to work outside of init()
<JEEB>
in theory if our init would become less important this stuff would have been simpler. but alas, encoder open is a Big Thing for us
<JEEB>
we expect side data etc be ready by then
<JEEB>
...
<JEEB>
extradata
<elenril>
this is not about us
<elenril>
the notion of "global headers" follows from the way certain containers and codecs work
<JEEB>
sure, I'm mostly just contrasting to VLC
<JEEB>
where apparently f.ex. the x264 module is just checking its configuration in init()
<JEEB>
then if it succeeds it's OK. but the final config is done at the receipt of first frame
<elenril>
jamrial: it won't
<elenril>
but it's a step in that direction
<JEEB>
also I think the way of integrating the HDR10 stuff etc for various encoders could be that we would have generic logic for specific side data types in case the encoder doesn't say it supports that specific side data type
<JEEB>
so that CBS would then generate stuff
<JEEB>
and then we attempt to patch encoder's extradata etc with it :)
<JEEB>
(or just first packet, not sure where that went after all)
s55 has joined #ffmpeg-devel
s55 has quit [Client Quit]
s55 has joined #ffmpeg-devel
<IndecisiveTurtle>
Lynne: Done with the demo boilerplate and now have been testing the shader. You mentioned it should be able to both do the transform in-place and not need deinterleaving, correct? Or is interleaving allowed and that can be performed in a separate compute pass?
<IndecisiveTurtle>
Asking because I faced the issue during downsizing where it would overwrite pixels in the other sections, which me realize why that code did the interleaving step
sr55 has joined #ffmpeg-devel
sr55 has quit [Client Quit]
s55 has quit [Ping timeout: 256 seconds]
<elenril>
and now there's the question of whether and when should encoders propagate decoded_side_data to coded_side_data
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
<jamrial>
elenril: not if they included it in the encoded bitstream, at least
<elenril>
it's not so obvious to me
<JEEB>
yea, why would you f.ex. not add the HDR10 metadata into the mp4 container as well as in the bit stream?
<elenril>
you might legitimately want to have the information present in both codec and container headers
<jamrial>
fair enough
<jamrial>
also, do we want decoders to export global side data in avctx->decoded_side_data? right now, decoders like h264 just export it in every frame
<elenril>
IMo yes
<elenril>
but also, what kind of side data
cone-809 has quit [Quit: transmission timeout]
<jamrial>
mastering, cll, the usual
<elenril>
that one is from SEIs, no?
<jamrial>
yeah
<elenril>
then it's legitimately per-frame
<jamrial>
those seis apply to the entire coded stream until they are cancelled by another sei of the same type, in general
<jamrial>
and so tend to show up once
s55 has joined #ffmpeg-devel
Dariusz has quit [Remote host closed the connection]
Marth64 has quit [Remote host closed the connection]
<Lynne>
IndecisiveTurtle: deinterleaving shouldn't happen at all in the encoder, but it can be useful to test if the output makes sense
<elenril>
mkver: iirc you did some refactoring of frame_thread_encoder, right?
kurosu has quit [Quit: Connection closed for inactivity]
<mkver>
Why should we go through AVCodecParameters? If at all, we would need a (non-public) function to copy AVCodecContext (there was once a public function for this purpose).
<elenril>
because maintaining such a function would be annoying
<IndecisiveTurtle>
Lynne: I see. From the research I think what happens is, first a horizontal pass is done where the average of 2 pixels a,b is placed on the left side and a-b/2 on the right side as "detail". And then repeat with a vertical pass.
<IndecisiveTurtle>
In a lecture I found it worked on 2x2 blocks and computed the average of these for the top-left, a-b+c-d/4 for top-right etc. Ffmpeg implementation doesn't seem to match that though, I tried to do the math and I ended up with (a+3b+c+d)/4+(3/2) for top-left pixel after transform for example, which didn't make much sense to me
<elenril>
of course nothing documents how large intra_matrix should be
<mkver>
elenril: Did you expect anything else?
<elenril>
I am known for my naive optimism
<mkver>
s/naive/delusional/
<Lynne>
IndecisiveTurtle: err, I get x+y+z+w/4 for the top left
<Lynne>
how did you get 3b there, plus a random fraction
<IndecisiveTurtle>
Hm let me try it again then, I knew something must have gone wrong there :/
<IndecisiveTurtle>
Ok did it again and now got a+b+c+d+4/4 seems I lost a sign there while computing hehe. Though still entirely correct so something's wrong again
cone-726 has joined #ffmpeg-devel
<cone-726>
ffmpeg Andreas Rheinhardt master:6ecc2f0f6f50: avcodec/libx264: Remove unused variable
<cone-726>
ffmpeg Andreas Rheinhardt master:c77164390b64: fftools/ffmpeg_enc: Don't call frame_data twice
<haasn>
now we don't need to passthrough dovi RPUs at all, we can just synthesize them on the fly
Dariusz has joined #ffmpeg-devel
<michaelni>
new fate sh4 client has been added with gcc 11
<cone-726>
ffmpeg Andreas Rheinhardt master:244db7103797: avcodec/libx265: Don't use AVBPrint unnecessarily
<cone-726>
ffmpeg Andreas Rheinhardt master:b9fcc135c570: avcodec/libx265: Pass logctx as void*, not AVClass**
<cone-726>
ffmpeg Andreas Rheinhardt master:26398da8f300: avutil/frame: Constify av_frame_side_data_get()
<cone-726>
ffmpeg Andreas Rheinhardt master:b7bec5d3c9ec: avutil/frame: Rename av_frame_side_data_get and add wrapper for it
<cone-726>
ffmpeg Andreas Rheinhardt master:d11b5e6096b8: avutil/frame: Use av_realloc_array(), improve overflow check
<mkver>
michaelni: Fine by me if you want to retire your old boxes. You could also have added -Dstatic_assert=_Static_assert to your cflags.
<michaelni>
mkver, send patch to add that, more sh4 support is most important. Then we can finally drop x86-64 support
<mkver>
"Then we can finally drop x86-64 support": ?
<IndecisiveTurtle>
Lynne: Uploaded my code to github https://github.com/GPUCode/haar2d_vulkan The shader is simple, just takes the averages for each pixel and stores them back to the same location. Though I don't think it can be run multiple times on the same image, without deinterleaving it first so the next leven can work on the upper 1/4
<IndecisiveTurtle>
If that needs to be supported together with the other two requirements, it will need to become more complex
<michaelni>
mkver, you want to make a big announcement ? we have only a few days left before april 1st but we can also do some other announcement thats just a random idea
deus0ww has quit [Ping timeout: 260 seconds]
deus0ww has joined #ffmpeg-devel
<Lynne>
if you want, I can write something funny
<Lynne>
IndecisiveTurtle: it does need to be supported, you don't get a haar transform with just averages
<cone-726>
ffmpeg Andreas Rheinhardt master:eb3ee7f141d3: avformat/mp3enc: Improve query_codec
<cone-726>
ffmpeg Andreas Rheinhardt master:b8124fe35ef9: libavformat/westwood_audenc: Use proper logcontext
<cone-726>
ffmpeg Andreas Rheinhardt master:233e13f285c9: avformat/mux: Rename FF_FMT_ALLOW_FLUSH->FF_OFMT_FLAG_ALLOW_FLUSH
<cone-726>
ffmpeg Andreas Rheinhardt master:789c5b03db3b: avformat/amr: Move write_header closer to muxer definition
<cone-726>
ffmpeg Andreas Rheinhardt master:a48e839a221d: avformat/mux_utils: Don't report that AV_CODEC_ID_NONE can be muxed
<cone-726>
ffmpeg Andreas Rheinhardt master:c6bc2d4fea99: fate/filter-audio: Don't use pcm output for channelsplit test
<cone-726>
ffmpeg Andreas Rheinhardt master:f4167842c12a: avformat/mux: Add flag for "not more than one stream of each type"
<cone-726>
ffmpeg Andreas Rheinhardt master:03b04eef72a5: avformat: Enforce one-stream limit where appropriate
<cone-726>
ffmpeg Andreas Rheinhardt master:a24bccc23859: avformat/mux: Add flag for "only default codecs allowed"
<cone-726>
ffmpeg Andreas Rheinhardt master:2ccb45511fa9: avformat/ttmlenc: Avoid unnecessary block
<cone-726>
ffmpeg Andreas Rheinhardt master:37f0dbbc3911: avformat: Enforce codec_id where appropriate
<cone-726>
ffmpeg Andreas Rheinhardt master:073251316e1b: avformat: Make init function out of write_header functions if possible