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
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
<elenril>
mkver: any plans for making refstruct public?
<mkver>
Not in the immediate future. Do you have plans for it?
<elenril>
I'm thinking about using it to replace fftools/objpool
<elenril>
and possibly avpriv_packet_list
<mkver>
Making it public would not be difficult; making it interoperate nicely with AVBuffer would entail allocating the AVBuffer jointly with the user-buffer and reusing it to store the refstruct stuff as well.
<mkver>
The avpriv_packet_list can already be unavprived by using the opaque pointer as next pointer (demuxers don't set it and muxers can clear user-set opaque pointers as the user will never see this packet again anyway).
rvalue has quit [Read error: Connection reset by peer]
<mkver>
I once made a patch for this.
rvalue has joined #ffmpeg-devel
<elenril>
it's just just about unavpriving it, that code is also quite ugly
witchymary has quit [Remote host closed the connection]
cone-653 has quit [Quit: transmission timeout]
<stefan_>
A few libraries are autodetected, most libraries are only used when enabled. What are the rules for enabling auto-detect of a library?
<jdarnley>
Should libraries, any libraries, be auto detected?
jamrial has joined #ffmpeg-devel
<stefan_>
I understand that some libabries are not auto-detected, because they would change the license to GPL. I'm asking for VapourSynth. I updated the implementation that it does link to it at build time, but load the library at runtime, like AviSynth. VapourSynth is LGPL 2.1 or later like ffmpeg, so I don't see any reason why not to auto-include VapourSynth support, because ffmpeg does not even require the library to be installed. It just checks
<stefan_>
if the OS can load libraries at runtime
<stefan_>
I changed it that it does *not* link to it at build time
<mkver>
elenril: Btw: jamrial's bd4ef145c0c1a has an issue: hevc_update_thread_context() updates the SPS if it has changed and sets AVCodecContext fields based upon the VUI stuff contained in it. Yet some of these VUI stuff gets overridden by SEIs and so said commit synced them explicitly after the place where the new SPS has been set. Actually, these AVCodecContext fields are synced generically, so one should just not set them even
<mkver>
when the SPS changes during update_thread_context.
Krowl has joined #ffmpeg-devel
sfan5 has quit [Quit: Quit]
sfan5 has joined #ffmpeg-devel
<elenril>
mkver: so just drop the call from hevc_update_thread_context()?
<mkver>
set_sps needs to be changed, too.
<jdarnley>
Does ffmpeg make any guarantees about the alignment of side data?
<jdarnley>
Would it be the default alignment for an allocation?
<jamrial>
jdarnley: no guarantees in general
<jdarnley>
Yes a quick look at the code suggests it is whatever av_buffer_alloc() oprovides
<jamrial>
packet side data must be allocated with av_malloc family of functions (which includes av_realloc)
<mkver>
jdarnley: How much alignment do you need? And what for?
<jdarnley>
4 bytes
<jdarnley>
Wondering how much of a C spec violation it is to read a uint32_t from the pointer
<jamrial>
you can always just use AV_R{LB}32
<jdarnley>
It is for s12m timecode side data
<jdarnley>
Yeah in ffmpeg and ffmpeg-using code I can
<jdarnley>
But not for something else that is supposed to be ffmpeg-compatible
<jdarnley>
It is for s12m timecode side data so not a big problem
<jdarnley>
I don't know why it was decided it should start with a count value instead of just using the size.
<mkver>
jdarnley: av_realloc etc. always provides enough alignment for basic types.
<jdarnley>
That is what I thought
<mkver>
(Whether it is a violation of the effective type rules to directly read it via an uint32_t depends upon how the value to be read has been written.)
tmm1 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
tmm1 has quit [Ping timeout: 272 seconds]
vtorri_ has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 260 seconds]
vtorri has joined #ffmpeg-devel
vtorri_ has quit [Ping timeout: 268 seconds]
witchymary has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
tmm1 has joined #ffmpeg-devel
tmm1 has quit [Ping timeout: 256 seconds]
Sean_McG has joined #ffmpeg-devel
Sean_McG has quit [Quit: leaving]
frankplow has quit [Quit: Goodbye]
frankplow has joined #ffmpeg-devel
frankplow has quit [Client Quit]
frankplow has joined #ffmpeg-devel
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
ngaullier has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
tmm1 has joined #ffmpeg-devel
tmm1 has quit [Ping timeout: 272 seconds]
cone-433 has joined #ffmpeg-devel
<cone-433>
ffmpeg James Almer master:127545350fcc: avformat/mov: use the updated default value for horizontal_disparity_adjustment in the eyes box
System_Error has quit [Remote host closed the connection]
witchymary has quit [Read error: Connection reset by peer]
witchymary has joined #ffmpeg-devel
stefan__ has joined #ffmpeg-devel
stefan_ has quit [Ping timeout: 260 seconds]
Krowl has quit [Quit: Krowl]
System_Error has joined #ffmpeg-devel
stefan_ has joined #ffmpeg-devel
stefan__ has quit [Ping timeout: 252 seconds]
AbleBacon has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 264 seconds]
tmm1 has joined #ffmpeg-devel
tmm1 has quit [Ping timeout: 252 seconds]
__monty__ has joined #ffmpeg-devel
<__monty__>
I'm getting `make: *** [tests/fate/filter-audio.mak:209: tests/data/hls-list.m3u8] Error 134` when building. I believe 134 is SIGABRT. Any pointers on whether or not this test failure is significant?
tmm1 has joined #ffmpeg-devel
<BtbN>
read the actual error
<mkver>
__monty__: rm tests/data/hls-list.m3u8 && make tests/data/hls-list.m3u8 V=1, then run this command standalone.
tmm1 has quit [Ping timeout: 268 seconds]
vtorri has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
stefan_ has quit [Ping timeout: 264 seconds]
vtorri has quit [Ping timeout: 252 seconds]
vtorri has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 268 seconds]
<__monty__>
There is seemingly no other output so I don't know how I would read "the actual error." This is when running the make command from mkver.
iive has joined #ffmpeg-devel
<JEEB>
__monty__: that's why V=1 was noted and he even gave you the exampple commands to re-run it with the added verbosity
<JEEB>
that then gives you the exact command(s) run
<JEEB>
which should in any case let you check out the reason for failure further
vtorri has joined #ffmpeg-devel
vtorri has quit [Ping timeout: 264 seconds]
vtorri has joined #ffmpeg-devel
<jamrial>
Daemon404: the spec for vexu->eyes->stri says "Moreover, both has_left_eye_view and has_right_eye_view can be set to 0 to indicate that the frame is monoscopic"
<jamrial>
this doesn't really match what you came up with for AVStereo3DView