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.2 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo_ has quit [Ping timeout: 260 seconds]
thilo_ has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 265 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 264 seconds]
tufei__ has joined #ffmpeg-devel
tufei__ has quit [Client Quit]
tufei has joined #ffmpeg-devel
tufei_ has quit [Ping timeout: 260 seconds]
jamrial has quit []
arch1t3cht3 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 276 seconds]
arch1t3cht3 is now known as arch1t3cht
System_Error has joined #ffmpeg-devel
another is now known as another|
jarthur has quit [Quit: jarthur]
___nick___ has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
mark4o has joined #ffmpeg-devel
markh has quit [Ping timeout: 276 seconds]
mark4o is now known as markh
mkver has quit [Ping timeout: 260 seconds]
ccawley2011 has quit [Ping timeout: 252 seconds]
cubicibo has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
cubicibo5 has joined #ffmpeg-devel
<elenril>
jamrial: looking at the code, it also seems that reget_buffer() could result in duplicate side data
<jamrial>
because of the ff_decode_frame_props() call on an old frame?
cubicibo has quit [Ping timeout: 256 seconds]
<elenril>
yes
<elenril>
it will add global side data every time
<elenril>
and packet side data will also accumulate
<elenril>
would be nice to find a file that triggers that
<jamrial>
there can only be one packet side data entry of a given type per packet at least, unlike frames
<elenril>
?
<elenril>
that should be true for frames as well
<jamrial>
you can add as many entries for any type as you want in frames, whereas in packets the new entry will replace the old
<elenril>
>can
<elenril>
the result is not well-defined
<elenril>
so not code should ever do that
cubicibo5 has quit [Quit: Client closed]
ccawley2011 has joined #ffmpeg-devel
<elenril>
but anyway, do you see a better solution than having decode.c merge decoder-set left/right into global/packet stereo3d?
<elenril>
could also:
<jamrial>
decoder-set left/right side data should not be made global unless you can ensure which views are being output, so it sounds like a job for the caller
<elenril>
how does the caller know which view is left?
<jamrial>
it's in the frame output by the decoder
<elenril>
err I don't follow then
<jamrial>
global side data (for the output stream) should describe what will be in the coded stream. you can take an mv-hevc sample and reencode it into two separate streams. each of those then should have stereo3d side data saying left or right
<elenril>
yes
<elenril>
but this information is unknowable to the decoder, and should indeed be in the caller
<elenril>
that's not the question though
<elenril>
the question is how to achieve left/right information being available in get_buffer(), while avoiding suplicate side data entries
<elenril>
gtg
<jamrial>
maybe replace av_frame_new_side_data() with av_frame_side_data_new() and the unique flag in ff_decode_frame_props()
<jamrial>
but that will nuke the old one
<kurosu>
wbs: the online docs for IsProcessorFeaturePresent are outdated? Gotta love have 2, if not more, ways of determining CPU flags...
<wbs>
kurosu: yes, they don't seem to have been updated to include all the latest flags from the latest winsdk
<wbs>
(also, what 2 ways of detecting features, there's at least as many ways as there are OSes - and on linux there's like 3 different ways :P)
<kurosu>
Yeah, ARM. And other ISAs, but just not x86
<kurosu>
Also. PF_AVX512F_INSTRUCTIONS_AVAILABLE
<kurosu>
Yeah, very important
<nevcairiel>
windows has never really shown much interest in highly granular x86 feature tests, maybe because noone cared as you can easily do it yourself without much pain, so they just had what they needed
<nevcairiel>
I assume on ARM its tricky to do it yourself, hence more interest in that function?
<wbs>
yep
<kurosu>
It was more about the nightmare that AVX512 cpuflags are (cue Venn diagram etc)
<nevcairiel>
just view all of SSE as a similar grouping, and its not that different :D
<nevcairiel>
just took more years
Labnan- has quit [Ping timeout: 245 seconds]
Labnan has joined #ffmpeg-devel
<wbs>
all the various SVE subfeatures isn't really any simpler than AVX512 tbh
___nick___ has quit [Ping timeout: 265 seconds]
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
Kwiboo has quit [Client Quit]
<wbs>
the fun thing about feature detection on arm, is that it _is_ possible to do it all yourself like on x86, but it requires the kernel to fix up those instructions that trap, and expose the real cpuid register values that way. modern linuxes support it, but windows and macos don't
Kwiboo has joined #ffmpeg-devel
IndecisiveTurtle has quit [Remote host closed the connection]
IndecisiveTurtle has joined #ffmpeg-devel
<nevcairiel>
so those functions are not just some library helper, but have to actually go into the kernel somehow?
<wbs>
yeah; the cpuid registers are not available to userspace at all. so the kernel needs to present the info somehow, using platform specific APIs. but if you do try to access the registers, the cpu faults (like any fault), and the kernel can choose to emulate the instruction - which linux does these days
<haasn>
do we care about parallel scaling of both fields of interlaced frames? Current vf_scale does not handle this
<haasn>
I think it's fine to continue ignoring it, as it simplifies the implementation slightly
<haasn>
since I can split the fields at a much higher level of abstraction
<haasn>
if we really care about this minor gain in performance (from what? eliminating some ting amounts of downtime?) we could add an asynchronous API and use it instead
<haasn>
but I think it's overkill
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
Daemon405 is now known as Dameon404
Kwiboo has quit [Quit: .]
Dameon404 is now known as Daemon404
Daemon404 has quit [Changing host]
Daemon404 has joined #ffmpeg-devel
Kwiboo has joined #ffmpeg-devel
<jamrial>
elenril: one option is to ensure the global side data does not make it to the frame if there's one already there (or rather, merge them if there's extra information from the container not present in the bitstream), then implement propagation of global side data through the lavfi filterchain
<jamrial>
the cli could then initialize the output with it instead of the first frame's side data
<jamrial>
the problem with this approach is that the filterchain will not be aware of you requesting a given view from the decoder, so the global side data would need to be amended in the cli, which is probably dirty
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
Kwiboo has quit [Client Quit]
Kwiboo has joined #ffmpeg-devel
quietvoid has quit [Ping timeout: 252 seconds]
Kwiboo has quit [Read error: Connection reset by peer]
Kwiboo- has joined #ffmpeg-devel
Kwiboo- has quit [Client Quit]
Kwiboo has joined #ffmpeg-devel
quietvoid has joined #ffmpeg-devel
quietvoid has quit [Ping timeout: 245 seconds]
quietvoid has joined #ffmpeg-devel
haihao has quit [Remote host closed the connection]
haihao has joined #ffmpeg-devel
feiw has quit [Remote host closed the connection]
feiw has joined #ffmpeg-devel
uartie has quit [Remote host closed the connection]
uartie has joined #ffmpeg-devel
IndecisiveTurtle has quit [Remote host closed the connection]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 248 seconds]
jarthur has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 246 seconds]
___nick___ has quit [Ping timeout: 246 seconds]
___nick___ has joined #ffmpeg-devel
ccawley2011_ has quit [Read error: Connection reset by peer]
iive has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
beastd has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #ffmpeg-devel
cone-339 has joined #ffmpeg-devel
<cone-339>
ffmpeg James Almer master:1c706cec46b8: avformat/mov_chan: add extra checks to channel description count
<cone-339>
ffmpeg James Almer release/7.0:3e6cec12865d: avformat/mov_chan: add extra checks to channel description count
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 264 seconds]
rvalue- is now known as rvalue
beastd has quit [Ping timeout: 244 seconds]
<cone-339>
ffmpeg Lynne master:12f158ca8f2e: hw_base_encode_h265: split off SPS/PPS/VPS generation from VAAPI
<cone-339>
ffmpeg Dave Airlie master:b4283f93e183: cbs_h265: add raw filler encoding