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?
rvalue has joined #ffmpeg-devel
<Lynne> jkqxz: ping
<Gramner> or through the extern keyword (which makes things easy to grep for) if you don't like the current push/pop pragmas. e.g. https://code.videolan.org/videolan/dav1d/-/blob/master/include/common/attributes.h?ref_type=heads#L120
<Lynne> that's pretty good
<mkver> I like that EXTERN thing.
<llyyr> JEEB: I tried your file, and I can reproduce the seeking to 0 issue and my patch does fix it
SystemError has joined #ffmpeg-devel
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
qeed has quit [Quit: qeed]
qeed has joined #ffmpeg-devel
<jdek> mkver: its the same configure command with disable static enable shared
<mkver> What is the output of readelf -sW libavformat/iamf.o
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Ping timeout: 272 seconds]
mkver has quit [Quit: Leaving]
mkver has joined #ffmpeg-devel
Sean_McG has quit [Quit: leaving]
mkver has quit [Ping timeout: 264 seconds]
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
lemourin has quit [Quit: The Lounge - https://thelounge.chat]
SystemError has quit [Ping timeout: 260 seconds]
lemourin has joined #ffmpeg-devel
SystemError has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Ping timeout: 264 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
jamrial has quit []
SystemError has quit [Ping timeout: 260 seconds]
SystemError has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
dykai has joined #ffmpeg-devel
SystemError has quit [Ping timeout: 260 seconds]
SystemError has joined #ffmpeg-devel
Mister_D has quit [Ping timeout: 255 seconds]
dykai has quit [Ping timeout: 264 seconds]
jarthur has quit [Quit: jarthur]
<JEEB> llyyr: nice. will then check it after $dayjob
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<Lynne> wow, risc-v vp9 patches
<Lynne> I was under the impression they weren't actively optimizing since it's always H264 asm that gets done first, but I guess they skipped it
ssfl has joined #ffmpeg-devel
ssfl is now known as a
a is now known as Guest5541
Guest5541 is now known as sunyuechi
<sunyuechi> Rise released a task for optimizing H264 for RISC-V, but I missed it.
sunyuechi has quit [Remote host closed the connection]
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Ping timeout: 260 seconds]
Krowl has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Remote host closed the connection]
Wenbin_Chen__ has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
ngaullier has quit [Quit: Leaving]
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Ping timeout: 255 seconds]
Wenbin_Chen__ has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Ping timeout: 260 seconds]
rajiv_ has quit [Ping timeout: 255 seconds]
averne has quit [Quit: quit]
averne has joined #ffmpeg-devel
rajiv_ has joined #ffmpeg-devel
rajivharlalka has joined #ffmpeg-devel
rajiv_ has quit [Ping timeout: 264 seconds]
rajivharlalka_ has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
rvalue has quit [Ping timeout: 255 seconds]
rvalue has joined #ffmpeg-devel
rajivharlalka has quit [Ping timeout: 260 seconds]
rajivharlalka_ is now known as rajivharlalka
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #ffmpeg-devel
<elenril> haasn: what's the status of your scale2ref work?
j45 has quit [Quit: ZNC 1.8.2 - https://znc.in]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
rajivharlalka2 has joined #ffmpeg-devel
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:5229778440bf: avcodec/libx264: fix extradata when config annexb=0
<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
Wenbin_Chen__ has joined #ffmpeg-devel
<JEEB> elenril: it's really generic; "Reference Processing Unit"
<JEEB> and opaque
<jamrial> haasn: just got your email
<haasn> (I resent it)
* haasn .oO( re-/sent/, not /resent/ )
<JEEB> elenril: also it's only mentioned in only one document or so. so most people *only* know it as "RPU"
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
<cone-407> ffmpeg Niklas Haas master:d5648a806fda: avcodec/dovi_rpu: use OR instead of addition
<cone-407> ffmpeg Niklas Haas master:f04a2ba30230: avcodec/dovi_rpu: fix off-by-one in loop
SystemError has joined #ffmpeg-devel
<quietvoid> haasn: what do you mean AV1 doesn't have a configuration record? it should but with the corrected profile
<mkver> Do we need an APIChanges entry if a function that is not yet stable (i.e. has been added recently) is changed?
<jamrial> imo yes, at least micro
<jamrial> how recently anyway?
<mkver> It's from JEEBs set.
<jamrial> then yeah
<Traneptora> if not ill merge it in a few hours
<mkver> no
<mkver> JEEB: Patches for you
<JEEB> alright
<JEEB> will take a look as I get home
<JEEB> have had to actually be in an office building today :D
Sean_McG has joined #ffmpeg-devel
* Sean_McG waves
<Sean_McG> just a heads-up, I'm out of town for the weekend and my FATE nodes will be powered off while I'm gone.
<Lynne> mkver: did some more cleanups - https://github.com/cyanreg/FFmpeg/commits/aac_cleanup_3/
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<elenril> ...so I should read RPU as "thing"
<JEEB> more or less
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
<elenril> jamrial: btw https://trac.ffmpeg.org/ticket/10907 seems like a bug in libdav1d
<jamrial> not encoding, it was related to remuxing
<elenril> or our wrapper
<elenril> jamrial: that block is encoder-only though
<jamrial> ah, then i mixed things
rajivharlalka3 has joined #ffmpeg-devel
<Lynne> very few of our code does anything with the frame cropping fields :/
<jamrial> yeah. encoders should definitely do something with them
<jamrial> as in, you can pass non cropped h264 to an encoder if you use -apply_cropping 0, yet the encoder will not care about it
<Lynne> we don't have a strict definition of the field, though, so should encoders crop it out, or signal it natively, or forward it to the container?
<jamrial> encoders should crop it out. maybe have it as an option like with decoders
Sean_McG has quit [Quit: Lost terminal]
jarthur has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
Wenbin_Chen__ has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<jamrial> elenril: no, didn't mix things. https://ffmpeg.org//pipermail/ffmpeg-devel/2023-October/315541.html what i did is skipping propagating the input cropping side data if it was applied during decoding
<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
AbleBacon has joined #ffmpeg-devel
<elenril> jamrial: https://up.khirnov.net/7p
<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?
<elenril> is there a reason you didn't do something like https://up.khirnov.net/a9
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
<elenril> and it would have no other callers
Guest52 has joined #ffmpeg-devel
<galad> I think the new colorspace and color_range fields in AVFilterLink are not being propagated correctly when initializing an AVFilterGraph, I had to make this changes to get it work: https://gist.github.com/galad87/2c6aab05a35ae325d889eaf09a7797a0
Livio has joined #ffmpeg-devel
<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
iive has joined #ffmpeg-devel
elastic_dog has quit [Ping timeout: 256 seconds]
Livio is now known as ChuckNorris
ChuckNorris is now known as Livio
Livio has quit [Quit: leaving]
Livio has joined #ffmpeg-devel
elastic_dog has joined #ffmpeg-devel
<mkver> wbs: Sent v3 of the static_assert check: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-March/324030.html
<mkver> elenril: Your opinion on the above patch.
<elenril> do you expect me to have one?
<mkver> Don't you have opinions on everything?
<elenril> I have no opinions on risc-v assembly
<elenril> the patch looks reasonable to me and I have no objection to dropping support for ancient gcc versions
* JEEB facepalms at (yet another part of) x265
<Lynne> which part?
<JEEB> apparently sticking a completely invalid xyzzy(-1337,... string into "master-display" is not BAD_VALUE
<JEEB> happily returning zero
<JEEB> then you get a warning when it attempts to write the SEI out
<JEEB> mkver: responded with an LGTM for the set
<JEEB> *a
<BBB> mkver: can we apply the cbs_vp8 patches? I feel kinda bad for the guy for just leaving it dangling
<JEEB> galad: is that reproable with the cli or just API usage?
<galad> I tried only with the api inside handbrake
<JEEB> ok
<JEEB> but yea, those props are not being propagated like other values near them.
<haasn> do we have somewhere the opposite of ff_h2645_extract_rbsp(), taking a RBSP and encapsulating it into a NAL (with emulation prevention)?
<JEEB> does any part of CBS do that?
<JEEB> possibly cbs_h2645_assemble_fragment ?
<haasn> yeah seems so
<haasn> I guess they just do it manually in-place
<JEEB> which is mapped to the H.264 and H.265 CBS's assemble_fragment
<JEEB> (and H.266 , the file name caught me first :) )
<mkver> Yeah, it is done in cbs when assembling the fragment.
<mkver> And at various other parts of the code, too.
<JEEB> so x265 does actually check the value string for a bunch of things when param_parse is called, but for the MDCV they just strdup
<JEEB> so as long as that doesn't fail you're golden
<JEEB> then within the actual bit stream writing they decide they want to parse a string
<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
lexano has quit [Ping timeout: 255 seconds]
Guest52 has quit [Quit: Client closed]
Livio has quit [Quit: leaving]