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
rvalue has quit [Ping timeout: 264 seconds]
mkver has quit [Ping timeout: 240 seconds]
rvalue has joined #ffmpeg-devel
qeed has quit [Quit: Leaving]
<sdc>
heya would someone be able to point me to a reference on what dynamic reconfiguration is / how it's implemented?
<sdc>
I submitted a patch removing that line but I got feedback that it was there to support dynamic reconfiguration, I did a little searching but I'm not sure what that means still
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
<compn>
ah
<compn>
no idea :D
<compn>
sdc, did you already post the bugreport to trac? its possible that devs would fix it if so
\\Mr_C\\ has quit [Remote host closed the connection]
Wenbin_Chen has joined #ffmpeg-devel
taniey has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Ping timeout: 272 seconds]
lexano has quit [Ping timeout: 264 seconds]
jamrial has quit []
Marth64 has joined #ffmpeg-devel
<Marth64>
mkver, elenril: I have hit an unfortunate snag with DVD. Since making the change to not register streams on the subdemuxer directly (v11), I can't set PTS wrapping options via avpriv_set_pts_info() on the subdemuxer.. So now, I've got some dual layer DVDs with a break on the second layer where PTS resets to 0. If I start the demuxing at (chapter where second layer starts - 1), this causes
<Marth64>
PTS wrapping to be incorrect and timestamps get wild.
<Marth64>
If I undo the change, or even add the avpriv_set_pts_info() call in mpeg.c (as a proof of concept), timestamps are correct.
<Marth64>
Discovered this deep during testing, wish I had realized it sooner.
<Marth64>
But it's the last pending issue left.
qeed has joined #ffmpeg-devel
<Marth64>
correct_ts_overflow = 0; to the rescue ! <3
<Marth64>
problem solved
cone-194 has joined #ffmpeg-devel
<cone-194>
ffmpeg Steven Liu master:0c8e64e268a9: mailmap: remap my email accounts
<Marth64>
v14 posted to ML. passed all my testing
<Marth64>
and with bunch of fixes
Wenbin_Chen_ has quit [Remote host closed the connection]
Wenbin_Chen has joined #ffmpeg-devel
Marth128 has joined #ffmpeg-devel
Marth64 has quit [Killed (NickServ (GHOST command used by Marth128!~Marth64@188.215.95.177))]
Marth128 is now known as Marth64
<compn>
reminds me of weirdness with mpv playing a vob and the time only shows 30 secs and resets all the time
<Marth64>
this demuxer should make that a non-issue now that if you have the original dvd structure
<Marth64>
if mpv has interest in using it, it should work wonders there once seeking is added.
<Marth64>
VOBs are evil in their full form and should never be demuxed directly
<Marth64>
many things interleaved in there, and without their headers effectively you are reverse engineering it
Marth128 has joined #ffmpeg-devel
Marth64 has quit [Killed (NickServ (GHOST command used by Marth128))]
Marth128 is now known as marth64
<marth64>
I am not that familiar with mpv though. most of my time is with VLC
marth64 is now known as Marth64
AbleBacon has quit [Read error: Connection reset by peer]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 255 seconds]
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Remote host closed the connection]
Marth64 has quit [Remote host closed the connection]
HarshK23 has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
Wenbin_Chen has joined #ffmpeg-devel
qeed has quit [Ping timeout: 272 seconds]
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
taniey has quit [Ping timeout: 255 seconds]
taniey has joined #ffmpeg-devel
blb has quit [Ping timeout: 272 seconds]
blb has joined #ffmpeg-devel
rooisnoek has joined #ffmpeg-devel
rooisnoek has quit [Client Quit]
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 240 seconds]
av500 has joined #ffmpeg-devel
cone-194 has quit [Quit: transmission timeout]
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
c1480 has quit [Quit: WeeChat 3.5]
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 256 seconds]
<JEEB>
OK, a positive thing is that the threaded ffmpeg doesn't seem to be causing fill-up of memory any more for this H.264+AV1 output test case I have, but it does seem to not be able to read the live input quickly enough. will have to check the details. I do still get 100/1000 buffers queued messages around so there's buffering at some point in the flow
<JEEB>
I would guess it is due to SVT-AV1 being quite a bit more buffering than the x264 outputs
<galad>
at the default settings svt-av1 buffers ~100 input frames before outputing one
Krowl has quit [Read error: Connection reset by peer]
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
any1 has quit [Ping timeout: 268 seconds]
Wenbin_Chen_ has joined #ffmpeg-devel
any1 has joined #ffmpeg-devel
<JEEB>
ok, it was using up memory :D just looked at the monitoring. just that you don't get an obvious OOM
Wenbin_Chen has quit [Ping timeout: 264 seconds]
any1 has quit [Ping timeout: 260 seconds]
any1 has joined #ffmpeg-devel
Teukka has quit [Ping timeout: 260 seconds]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 255 seconds]
Marth64 has joined #ffmpeg-devel
derpydoo has quit [Ping timeout: 240 seconds]
Wenbin_Chen has joined #ffmpeg-devel
purva has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Ping timeout: 255 seconds]
taniey has quit [Ping timeout: 272 seconds]
taniey has joined #ffmpeg-devel
taniey has quit [Quit: Leaving]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Remote host closed the connection]
kurosu has quit [Quit: Connection closed for inactivity]
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
tufei has quit [Remote host closed the connection]
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
Wenbin_Chen has joined #ffmpeg-devel
purva has quit [Quit: Connection closed for inactivity]
<haasn>
elenril: huh somehow I missed to commit some side data attachment points in my series, I think I accidentally stashed them
<haasn>
I'll just convert all of the remaining, that way there is no ambiguity
<haasn>
fixed (updated my branch link)
jamrial has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<haasn>
pushed also some conversions for remaining callsites, even though they aren't necessary to switch over to the new API (yet)
ngaullie has joined #ffmpeg-devel
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen has quit [Remote host closed the connection]
ngaullier has quit [Ping timeout: 256 seconds]
jnbek has quit [Quit: kthx]
jnbek has joined #ffmpeg-devel
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
Krowl has quit [Read error: Connection reset by peer]
Traneptora has joined #ffmpeg-devel
<Marth64>
good day
englishm has quit [Ping timeout: 256 seconds]
HarshK23 has quit [Ping timeout: 260 seconds]
HarshK23 has joined #ffmpeg-devel
Traneptora has quit [Read error: Connection reset by peer]
termos has quit [Ping timeout: 260 seconds]
jluthra has quit [Ping timeout: 246 seconds]
termos has joined #ffmpeg-devel
englishm has joined #ffmpeg-devel
kylophone has quit [Ping timeout: 256 seconds]
sdc has quit [Ping timeout: 246 seconds]
compn has quit [Ping timeout: 246 seconds]
tortoise has quit [Ping timeout: 260 seconds]
jluthra has joined #ffmpeg-devel
englishm has quit [Ping timeout: 264 seconds]
termos has quit [Ping timeout: 260 seconds]
TD-Linux has quit [Ping timeout: 246 seconds]
<Marth64>
quiet day
TD-Linux has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
kylophone has joined #ffmpeg-devel
Nightrose has quit [Ping timeout: 268 seconds]
tortoise has joined #ffmpeg-devel
sdc has joined #ffmpeg-devel
termos has joined #ffmpeg-devel
<elenril>
[distant rumbling intensifies]
kurosu has quit [Ping timeout: 246 seconds]
<elenril>
haasn: very nice
<elenril>
so it's all done then?
Nightrose has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
kylophone has quit [Ping timeout: 264 seconds]
Dmitri_Ovch has quit [Ping timeout: 246 seconds]
sdc has quit [Ping timeout: 256 seconds]
Lypheo9 has joined #ffmpeg-devel
termos has quit [Max SendQ exceeded]
Dmitri_Ovch has joined #ffmpeg-devel
termos has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
sdc has joined #ffmpeg-devel
Lypheo has quit [Read error: Connection reset by peer]
Lypheo9 is now known as Lypheo
jluthra has quit [Ping timeout: 264 seconds]
englishm has joined #ffmpeg-devel
<Marth64>
i met a user in real life yesterday for the first time
<Marth64>
a user who actually knows they are using it
kylophone has joined #ffmpeg-devel
<JEEB>
:D
<JEEB>
yea that is always fun to happen
jluthra has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
Traneptora has quit [Read error: Connection reset by peer]
<Marth64>
yes was refreshing
<Marth64>
i signed up to help them with a command
kylophone has quit [Ping timeout: 256 seconds]
Traneptora has joined #ffmpeg-devel
HarshK23 has quit [Ping timeout: 264 seconds]
<Marth64>
i remember when i first learned order mattered in the command line
<Marth64>
mind completely blown
jluthra has quit [Ping timeout: 246 seconds]
<Marth64>
map order*
termos has quit [Ping timeout: 268 seconds]
kurosu has quit [Ping timeout: 256 seconds]
sdc has quit [Ping timeout: 256 seconds]
Nightrose has quit [Ping timeout: 246 seconds]
<JEEB>
I've now been surprised that if you have a filter complex with unnamed outputs it will get mapped
<JEEB>
even if you have explicit maps
<Traneptora>
I thought dangling outputs in filter complex would produce an error?
HarshK23 has joined #ffmpeg-devel
Traneptora has quit [Read error: Connection reset by peer]
haxar has quit [Ping timeout: 246 seconds]
termos has joined #ffmpeg-devel
<JEEB>
so did I, so did I...
kekePower has quit [Read error: Connection reset by peer]
kurosu has joined #ffmpeg-devel
kekePower has joined #ffmpeg-devel
<haasn>
elenril: yeah, I left some that are a bit more suspect and/or only used for encoding and/or used in contexts in which we don't have access to avctx
HarshK23 has quit [Ping timeout: 260 seconds]
cone-834 has joined #ffmpeg-devel
<cone-834>
ffmpeg James Almer master:f9f56fdc3763: avformat/mpegts: add a ts_id exported option
<cone-834>
ffmpeg James Almer master:4b8be3616dd4: avformat/mpegts: remove decoding param from ts_packetsize option
Traneptora has joined #ffmpeg-devel
termos has quit [Ping timeout: 260 seconds]
jluthra has joined #ffmpeg-devel
termos has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
<jamrial>
koda using chatgpt to write replies to nicolas emails does not really help
haxar has joined #ffmpeg-devel
kylophone has joined #ffmpeg-devel
Nightrose has joined #ffmpeg-devel
omegatron has joined #ffmpeg-devel
<Marth64>
yikes
sdc has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
<kierank>
jamrial: it turns the ml from farce to comedy at least
Teukka has quit [Ping timeout: 256 seconds]
Marth64 has quit [Ping timeout: 255 seconds]
Marth64 has joined #ffmpeg-devel
<cone-834>
ffmpeg Jan Ekström release/6.1:fef22c87ada4: {avcodec,tests}: rename the bundled Mesa AV1 vulkan video headers
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
<JEEB>
there, since there were no objections that has now also fixed the 6.1 builds
rodeo has quit [Ping timeout: 264 seconds]
compn has joined #ffmpeg-devel
rodeo has joined #ffmpeg-devel
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
kurosu has quit [Ping timeout: 256 seconds]
kurosu has joined #ffmpeg-devel
<Marth64>
DVD menu demuxing is almost done
<Marth64>
(tm)
<Marth64>
you can choose between main menu and sub menu. but i didn't add ability to list them yet
<Marth64>
so youll have to know their coordinate if you want submenu
termos has quit [Ping timeout: 246 seconds]
lexano has joined #ffmpeg-devel
kylophone has quit [Ping timeout: 246 seconds]
termos has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
kylophone has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
lexano has quit [Remote host closed the connection]
<Marth64>
yeah, I can push menus out today in a seperate patch
<Marth64>
its good2go
<Marth64>
gonna write docs in the meantime
Krowl has quit [Read error: Connection reset by peer]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
AbleBacon_ has joined #ffmpeg-devel
AbleBacon has quit [Ping timeout: 256 seconds]
AbleBacon_ has quit [Remote host closed the connection]
AbleBacon_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<thardin>
is it just me or is the hls muxer kinda shit?
<courmisch>
compn: in light of what he posted recently, I'd rather he be permanently banned, so I won't be missing an opportunity to report him, small time contributor or not
<thardin>
streaming to youtube with rtmp: no problems. streaming with hls: buffering...
<Marth64>
hmm
<thardin>
might have to do with lack of threading I suspect
<Marth64>
clients can be janky too
<thardin>
5.1.4 is kind of old^Wstable
<Marth64>
but you said youtube so
<Lynne>
thardin: you can stream with hls to youtube?
<thardin>
yes
<Lynne>
what do you do, point it at a manifest?
<courmisch>
also, I didn't realise so many people didn't understand the meaning of "should"
<courmisch>
RFC2119 and all
<JEEB>
Lynne: other media servers just take in the POST of each segment and manifest update
<thardin>
with -f hls. works, but again it buffers a lot. like every 30 seconds. speed is nowhere realtime
<Lynne>
reminds me I still have active akamai credentials, I could host my own twitch and still have bandwidth to spare :)
<JEEB>
when I tested it with akamai and such, it seemed to work well enough
<Lynne>
until they notice anyway
<Marth64>
elenril: would you consider merging the menu support too? 300 lines exactly. it will be it's own patch so folks can review it seperately if not.
<JEEB>
but yes, the hls muxer only gets focus from certain people so I would agree that it probably has a lot of stuff that could be done better
<Lynne>
what about dash? do they accept it?
<thardin>
don't know
sdc has quit [Ping timeout: 246 seconds]
sdc has joined #ffmpeg-devel
<thardin>
seems doing HLS muxing in a separate ffmpeg process works
sdc has quit [Ping timeout: 264 seconds]
sdc has joined #ffmpeg-devel
<Lynne>
dash has in my experience been better
<Lynne>
but if it doesn't accept it, not much that can be done
<JEEB>
the dash and hls writers share various bits of code, so I'd expect that if there's something holding back one muxer, that would probably hold the other one, too
<Lynne>
dash has better defined pulling behaviour
<JEEB>
the things tend to be push, not pull
<JEEB>
*these
<Lynne>
dash or hls don't have that, right? clients just figure out when to get new segments
<JEEB>
yes, and you are supposed to push segments+manifest update at more or less the correct times.
<JEEB>
so you push your segments, then an update to manifest(s) (if required, dash can be time based)
<JEEB>
and then the media server receiving either serves it as-is, or processes it somehow
<sdc>
would someone be able to point me to a reference for "dynamic reconfiguration" in the context of filters?
Wenbin_Chen_ has joined #ffmpeg-devel
cone-834 has quit [Quit: transmission timeout]
Wenbin_Chen has quit [Ping timeout: 272 seconds]
rvalue has quit [Ping timeout: 264 seconds]
rvalue has joined #ffmpeg-devel
Wenbin_Chen has joined #ffmpeg-devel
Wenbin_Chen_ has quit [Remote host closed the connection]
Wenbin_Chen_ has joined #ffmpeg-devel
ngaullie has quit [Ping timeout: 252 seconds]
Wenbin_Chen has quit [Read error: Connection reset by peer]
<jamrial>
courmisch: nice use of _Generic
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 240 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<jkqxz>
courmisch: Not enough love, maybe. ckd_sub: "*r = a + b" ?
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
<haasn>
courmisch: shouldn't that ckd_sub_##suffix be (a - b)?
<haasn>
oh, sniped by jkqxz
Krowl has joined #ffmpeg-devel
<jkqxz>
Go team actually-read-the-code!
Marth64 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg-devel
<Traneptora>
why not const type sum = a + b; *r = sum; return sum < a;
<Traneptora>
seems like that would avoid a second addition or a second dereference
<wbs>
that's UB
<Traneptora>
it is? how so
<wbs>
if a and b are signed integers, then overflow is undefined. if the compiler knows that b is nonnegative, then it can also conclude that "sum < a" will never be true
<wbs>
that's the main thing about UB - you can generally never have UB happen and then check whether it has happened; one has to check before, to make UB not happen
<elenril>
Marth64: not sure what you mean by that question exactly
<elenril>
send the patch and people (who may or may not include me) may or may not look at it
<wbs>
oh sorry, this is about unsigned types, then it's a different thing, nevermind
<Marth64>
Marth64: ignore, just got excited earlier cause I got it working.
<Marth64>
elenril* wow I am tired.
<Marth64>
I'll send a patch when appropriate
<elenril>
how does it even work?
<elenril>
a data stream or something?
<Marth64>
the menus themselves are just mpeg-ps streams. so if you tell it "I want menu X," you'll get the video and audio of the menu. no looping or interactivity or anything like that
<Lynne>
oh no, it's that sleep() patch again
<Marth64>
but useful because (a) some discs have animations and music worth perserving, (b) some discs hide parts of the main feature itself into the menu streams
<elenril>
how does the interactive stuff work?
<Marth64>
elenril: based on key inputs to the DVD remote, which trigger activations of the graphical subpicture stream (dvd_subtitle) - in menus, the subpicture is the highlighting of the choice you selected with a remote
<Marth64>
none of which i plan to implement
<Marth64>
while it would be cool, it's out of scope for a demuxer methinks
Krowl has quit [Read error: Connection reset by peer]
<elenril>
I'm sure stream groups are the answer
<Marth64>
dvdnav all the way start-to-end + enabling the highlighting is what is necessary. the catch is that streams are no longer guaranteed, they can change dynamically
<Marth64>
if going down that route...which is essentilaly writing a full player
<elenril>
probably not
<Marth64>
but I just wanted the ability to at least preserve meaningful menus
Wenbin_Chen_ has quit [Read error: Connection reset by peer]
Wenbin_Chen has joined #ffmpeg-devel
<mkver>
jamrial: iff is also used in channel_layouts.h.
<jamrial>
probably the doxy elenril or koda wrote
<mkver>
1/5 seems to have landed on the ML. And so have two patches replacing 5/5.
<Lynne>
do compilers have a hint to reorder and pack structures optimally?
<mkver>
Lynne: Do you want the compiler (or a profiler) give you hints about how to reorder structs? Or do you want the compiler to reorder structure elements on its own? If it is the latter: Don't. Some parts of the code presume stuff not guaranteed by the standard. E.g. AV_OPT_TYPE_BINARY must point to a pointer immediately followed by an int size field.
<Lynne>
it's not a structure which requires any particular order, just something to store lots of small state data and flags
<mkver>
Great, that new mov-mp4-pcm-float test leaks.
<mkver>
What's going on with ubitux's FATE boxes?
Traneptora has quit [Quit: Quit]
<cone-963>
ffmpeg Andreas Rheinhardt master:94fadd335bd1: avformat/iamf_writer: Don't leak on error when adding ParamDefinition
<cone-963>
ffmpeg Andreas Rheinhardt master:840f192540cc: avformat/iamf_writer: Remove nonsense check
<cone-963>
ffmpeg Andreas Rheinhardt master:e7c33c92d1eb: avformat/iamf_writer: Don't memset twice
<cone-963>
ffmpeg Andreas Rheinhardt master:18af922c536a: avformat/iamf: Don't mix ownership and non-ownership pointers
<cone-963>
ffmpeg Andreas Rheinhardt master:c5845afd0953: avformat/iamf_writer: Return proper error codes
<cone-963>
ffmpeg Andreas Rheinhardt master:1f7cd5d4348a: avformat/iamf_writer: Fix leaks on error
<thardin>
libx264 doesn't have a realtime deadline option?
<kierank>
that's speedcontrol which was never merged