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.0.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
IndecisiveTurtle has quit [Ping timeout: 246 seconds]
IndecisiveTurtle has quit [Ping timeout: 264 seconds]
quietvoid has quit [Quit: No Ping reply in 180 seconds.]
quietvoid has joined #ffmpeg-devel
<elenril>
huh, select filter can have multiple outputs
<elenril>
....and it triggers the same issue as scale2ref
<elenril>
I guess it doesn't get used much
<JEEB>
I have utilized scale2ref for making sure subpictures are of the correct size before overlaying
vtorri has joined #ffmpeg-devel
vtorri has quit [Read error: Connection reset by peer]
vtorri_ has quit [Ping timeout: 268 seconds]
vtorri has joined #ffmpeg-devel
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 264 seconds]
Krowl has quit [Read error: Connection reset by peer]
<haasn>
Is there a way to refcopy only the data inside an AVFrame without touching the properties (e.g. pts)?
<haasn>
like av_frame_ref() / av_frame_replace() but weaker
<haasn>
also like av_frame_copy() but referencing the buffers if possible
<haasn>
I guess it's easy enough to just do "by hand"
<haasn>
but surprising there's not a function for this
<Lynne>
av_frame_clone?
<Lynne>
ah, refcopy
<nevcairiel>
it seems like an unusual task, tbh
<nevcairiel>
there is a bunch of properties on avframe that are mandatory to interpret the buffers, so not copying those would more often be wrong then not
<haasn>
wholly justified objection
<haasn>
in this case it doesn't really matter since the involved logic will probably get replaced soon anyway
<haasn>
so I'll just make a placeholder helper
<haasn>
nevcairiel: what properties are there besides width/height/linesize/format?
<haasn>
and I mean, it would break either way if you just av_frame_copy()
<haasn>
without changing those properties
<haasn>
so creating a ref instead of copying the data doesn't seem much different
<haasn>
by this logic av_frame_copy() shouldn't exist either
<haasn>
actually, maybe av_frame_copy() should just ref the buffers if possible
<haasn>
but that would probably break 50 billion downstream users
<nevcairiel>
av_frame_copy and av_frame_ref are distinct for reasons :D
<nevcairiel>
but yes av_frame_copy expects you to have a properly allocated frame already
<nevcairiel>
it doesnt mess with the buffers, it just copies into them
<nevcairiel>
so a well-formed frame before is always a well-formed frame after - that is not necessarily the case if you update the buffers themselves without updating also metadata, even if its just formst, w/h and the appropriate audio fields
Krowl has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<kasper93>
Traneptora: jpegxl parser is overreading data, and while bitstream reader checks that, still the AV_INPUT_BUFFER_PADDING_SIZE padding has to be initialized
<kasper93>
found by MSAN
<Traneptora>
isn't it being initialized by being an array member of the context?
<kasper93>
only in one case
<kasper93>
the else branch is using input buffers directly
<Traneptora>
lemme check the code
<Traneptora>
in either case the parser returns AVERROR_BUFFER_TOO_SMALL, which it checks regularly if overread occurs
<Traneptora>
but you're saying that the overread, even if ignored, is uninitialized which is annoying asan
<Traneptora>
ah, in this case it doesn't "matter" but not because it was unread, but because the parser checks if any overrun occurred and aborts out
<Traneptora>
well not aborts out but returns an error message
<Traneptora>
see: line 858 of the same file
<Traneptora>
but msan is probably not sophisticated enough to check that
<kasper93>
well it is way past the unint access and use
<kasper93>
and I have 8 other reports
<kasper93>
I'm not saying jpegxl parser is not working, just want to unblock sanitizers
<Traneptora>
kasper93: what would the practical difference be between calling memset on the array in the jepgxl_anim_dec patch, versus just declaring the array and assigneing it = { 0 };
<Traneptora>
is one better than the other? I believe both wold solve the issue
<kasper93>
I perfer to be explicit why this needs to be cleared, ={0} works too, but we only need padding cleard in fact.
<Traneptora>
what happens if the head is the entire file?
<Traneptora>
like if the animation is so tiny it fits inside like 256 bytes or something
<kasper93>
I don't know, what would be the difference then?
<cone-290>
ffmpeg Zhao Zhili master:baf3123c1c84: avutil/executor: Allowing thread_count be zero
<cone-290>
ffmpeg Zhao Zhili master:6aeb084c395d: avcodec/vvc: Don't create new thread when thread_count is 1
<Traneptora>
kasper93: difference would be that the "padding" that you zero wouldn't be the same padding that's at the end of the buffer
<Traneptora>
dunno if that matters
<kasper93>
should be fine as long as there is padding
Krowl has quit [Read error: Connection reset by peer]
vtorri has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 255 seconds]
vtorri_ has joined #ffmpeg-devel
<haasn>
michaelni: do you still understand how in_v_chr_pos etc. work?
<haasn>
is it (0, 0) for topleft and (128, 128) for center?
vtorri has quit [Ping timeout: 256 seconds]
<haasn>
if so, why does swscale default to using (128, 128) for 4:2:0 content?
<haasn>
shouldn't it default to topleft/left (MPEG)?
<haasn>
and why does it change to 64 and 192 resp. for interlaced content?
<haasn>
is it because 64 = 128 / 2, and 192 = 64 + 128; or is it because 64 = 128 - 64, and 192 = 128 + 64?
<haasn>
(in particular, for bottom-aligned content, should it be 128 and 256 or 192 and 320?)
vtorri has joined #ffmpeg-devel
<haasn>
(and what are API users of vf_scale supposed to do when scaling interlaced content with custom chroma location)
vtorri_ has quit [Ping timeout: 256 seconds]
vtorri_ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<haasn>
other sources online claim that topleft chroma should be (-128, -128), but then I really don't understand why swscale defaults to (128 << subsampling) - 128 which equals 128 for 4:2:0
<nevcairiel>
obviously swscale is so old that center chroma location was still the talk of the town then
<JEEB>
just like bt.601
<michaelni>
IIRC mpeg-1 and mpeg-2 chroma locations differed for 4:2:0
<nevcairiel>
center is mpeg1, yes
vtorri has quit [Ping timeout: 256 seconds]
<JEEB>
yup
<nevcairiel>
i think i saw a reasonably explanation of the values somewhere
<nevcairiel>
but i forgot where
<haasn>
ffmpeg wiki says (0,0) is topleft, (128,128) is center
<haasn>
that just leaves the question of how to handle interlaced content correctly
<haasn>
how does interlaced chroma work?
vtorri has joined #ffmpeg-devel
<michaelni>
interlaced content is evil
<haasn>
one chroma line is shared for both luma fields?
<haasn>
or is the chroma plane also interlaced?
ocrete has joined #ffmpeg-devel
<michaelni>
chroma is interlaced in 4:2:0
<michaelni>
the vertical locations are fun
<haasn>
"With interlaced material, 4:2:0 chroma subsampling can result in motion artifacts if it is implemented the same way as for progressive material. The luma samples are derived from separate time intervals, while the chroma samples would be derived from both time intervals. It is this difference that can result in motion artifacts. The MPEG-2 standard allows for an alternate interlaced sampling
<haasn>
scheme, where 4:2:0 is applied to each field (not both fields at once). This solves the problem of motion artifacts, reduces the vertical chroma resolution by half, and can introduce comb-like artifacts in the image. "
<haasn>
lovely
<michaelni>
btw, mpeg4 spec has some easy to understand diagrams about the locations of interlaced 4:2:0 chroma
vtorri_ has quit [Ping timeout: 256 seconds]
vtorri_ has joined #ffmpeg-devel
<haasn>
thx, will take a look
<michaelni>
the only reasonable way to handle chroma is to convert it to progressive using neual net then do whatever filter one wants and then convert back. Directly handling interlaced will likely lead to worse results
<michaelni>
"Figure 6-2 -- Vertical and temporal positions of samples in an interlaced frame with top_field_first=1" this in mpeg4 spec and surrounding diagrams
<michaelni>
but i suspect other specs have similar diagrams this is just the one i remember
vtorri has quit [Ping timeout: 268 seconds]
<haasn>
leaves the question of how should we handle UNSPECIFIED chroma loc
<haasn>
status quo would be to default to center siting
vtorri has joined #ffmpeg-devel
<JEEB>
H.273 is now where that stuff is supposed to be centralized after JVET decided that they shouldn't just copypasta the same stuff to new video format specs
<JEEB>
it has this really "nice" image as "Chroma 4:2:0 sample location type" and the Figure 9 there
<haasn>
but maybe in 2024 we can deviate from libswscale status quo and default to left chroma
<haasn>
otoh, center is used for JPEG
<haasn>
you can make the argument that chroma location is vastly more noticeable in still images than moving video
<haasn>
so perhaps we should err on the side of caution and default to the correct location for jpeg :)
<michaelni>
about chrom loc, i liked center because its from a mathematical point of view the "simplest" thing to do. Its also in some sence what is done with luma while the co-located makes absolute chroma location depend on luma resolution, but it all also depens a bit how location is defined
vtorri_ has quit [Ping timeout: 256 seconds]
<JEEB>
haasn: yea, image use case (JPEG) versus video use case (most video during the last 15+ years)
<JEEB>
for both color stuff and chroma location
vtorri_ has joined #ffmpeg-devel
<haasn>
obviously in "strict" mode it would just be an error
<haasn>
to not set chroma loc
<michaelni>
haasn, compute phase / do a cross correlation to find where the planes match best ;)
<JEEB>
although main thing would be that things would get properly flagged in the output, whatever the picked thing was.
<haasn>
yes that is a perfectly reasonable thing to do in realtime when setting up the scalers without image data being available :)
<michaelni>
great you agree, so thats solved
vtorri has quit [Ping timeout: 256 seconds]
<haasn>
can we also agree that we should just ban interlaced content?
<michaelni>
yes
vtorri has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 246 seconds]
<haasn>
that diagram is actually really helpful, thanks
<JEEB>
how does it compare to figure 9 of H.273? :D
<JEEB>
which is the one they utilized from H.264 onwards
<JEEB>
at least
<JEEB>
not sure if MPEG-4 Part 2 had that
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 246 seconds]
vtorri has joined #ffmpeg-devel
<kasper93>
>ban interlaced content << +1 for me
<haasn>
so the correct logic is v_pos / 2 for even rows and (v_pos / 2) + 128 for odd rows
<haasn>
for topleft aligned (luma cosited) chroma this would end up with v_pos 0 for even rows and v_pos 128 for odd rows (since the chroma samples are aligned with the *other* luma row)
vtorri_ has quit [Ping timeout: 256 seconds]
<haasn>
there, now avscale is hooked up to swscale and should already be a working improvement since it automatically sets these fields (which I'm pretty sure nobody sets correctly ever) :)
<nevcairiel>
wasnt there a function to generate them from the enum, or was i hallucinating that
<nevcairiel>
or maybe i made that somewhere...
<haasn>
indeed, though that doesn't handle interlaced content
<haasn>
tomorrow I will add tests and then submit the first draft of avscale, which so far just wraps swscale inside a saner API and plumbs all metadata correctly
<haasn>
but the plan is to go from here by designing a new high-level scaling pipeline which will re-use all the low-level stuff from swscale but avoid sws_init_context() etc.
<haasn>
avscale also replicates most of the logic from vf_scale, which will allow vf_scale to effectively turn into just filter_frame() { av_frame_copy_props(dst, src); av_scale_frame(dst, src); }
<haasn>
or put another way, users can now just use av_scale_frame() to get the equivalent of vf_scale for free
<haasn>
including correct handling of interlaced content
arch1t3cht4 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 264 seconds]
arch1t3cht4 is now known as arch1t3cht
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 255 seconds]
vtorri has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 264 seconds]
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 268 seconds]
vtorri has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 268 seconds]
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 256 seconds]
vtorri has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 268 seconds]
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 255 seconds]
vtorri has joined #ffmpeg-devel
Krowl has quit [Quit: Krowl]
vtorri_ has quit [Ping timeout: 264 seconds]
vtorri_ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 264 seconds]
vtorri has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 246 seconds]
<JEEB>
haasn: good job
Krowl has quit [Read error: Connection reset by peer]
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 256 seconds]
vtorri has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 256 seconds]
<kasper93>
is it over?
vtorri_ has joined #ffmpeg-devel
vtorri_ was kicked from #ffmpeg-devel by elenril [vtorri_]
vtorri has quit [Ping timeout: 272 seconds]
cone-290 has quit [Quit: transmission timeout]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Traneptora>
kasper93: responded on ML
cone-033 has joined #ffmpeg-devel
<cone-033>
ffmpeg Theo Fabi release/7.0:40ddddca45c3: avdevice/avfoundation: add external video devices
ngaullier has quit [Ping timeout: 240 seconds]
<frankplow>
Does anyone know of a way to set different C compiler flags for only certain files? I want to add -Werror for only libavcodec/vvc/* in our CI.
<Lynne>
don't even think about it
<frankplow>
? I don't mean in FATE, in the GitHub actions CI we run ourselves. There aren't any warnings at the minute.
<jamrial>
frankplow: maybe pragmas
<frankplow>
jamrial: Patch them in as a CI step you mean?
<jamrial>
probably easier than patching custom rules to makefile
<courmisch>
heresy
<courmisch>
where are elenrils when one needs them
<jamrial>
courmisch: not upstream, ENOCARE
<courmisch>
error: 'ENOCARE' undeclared here
Livio has quit [Ping timeout: 268 seconds]
Livio has joined #ffmpeg-devel
fennewald has quit [Ping timeout: 260 seconds]
fennewald has joined #ffmpeg-devel
<jdarnley>
frankplow: /quit
<jdarnley>
oops
<jdarnley>
please ignore
michaelni has quit [Ping timeout: 268 seconds]
Livio has quit [Ping timeout: 264 seconds]
michaelni has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
<Marth64>
Sorry about the spam on my 3rd patch (ignore the patch). It takes me a while to run through the test scenarios and I missed a beat on that one.
<Marth64>
Really I should write automated tests.
<Marth64>
I'll wait for the other 2 patches to be reviewed first then come back to the trim patch together with seeking a little later on.
<Marth64>
Those 2 have been through tougher testing.
<Marth64>
also I top posted. double strike. :(
beastd has joined #ffmpeg-devel
cone-033 has quit [Quit: transmission timeout]
<thardin>
unacceptable
<thardin>
seven years, no trial
<Marth64>
haha will be more patient next time
Warcop has quit [Remote host closed the connection]