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.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
mkver has quit [Read error: Connection reset by peer]
<michaelni>
pointing to anything that is not under ffmpeg.org domain is just weird and will cause problems
<BtbN>
Hmm? It's set up as a mirror and you can't push to it.
iive has quit [Quit: They came for me...]
<another|>
(something something nameservers)
<michaelni>
git.ffmpeg.org/ffmpeg.git is the main public repository and has been since a long time
<michaelni>
for historic reasons sgit@source.ffmpeg.org:ffmpeg is used for pushing
<michaelni>
i mean git@source.ffmpeg.org:ffmpeg
<michaelni>
git.ffmpeg.org is also used for pushing for fateserver, ffmpeg-web patchwork_job_runner patchwork_jobs_devops
<michaelni>
git@source.ffmpeg.org:ffmpeg is the odd exception
<michaelni>
we could update source.ffmpeg.org to point to git.ffmpeg.org for pushing and turn git.videolan into a mirror, i think this would make sense and clean this up and also maybe make forgejo less complex
<michaelni>
because as is forgejo will need to deal with the mix of where currently pushes go to, that is git@source.ffmpeg.org:ffmpeg for ffmpeg and git.ffmpeg.org for everything else
HarshK23 has quit [Quit: Connection closed for inactivity]
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Ping timeout: 272 seconds]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Ping timeout: 272 seconds]
mkver has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
jamrial has quit []
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
secondcreek has joined #ffmpeg-devel
mkver has quit [Ping timeout: 248 seconds]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
mkver has quit [Ping timeout: 276 seconds]
mkver has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
<steven-netint>
I noticed that `ofp->fps.last_frame` can hold-up a ref to a frame even after filtergraph sends EOF to encoder. So, I want to call `av_frame_unref(ofp->fps.last_frame)` somewhere around the end-of or after `ffmpeg_filter.c:close_output()`. Does anyone think this is a bad idea or has suggestions on where specifically to put it?
mkver has joined #ffmpeg-devel
mkver has quit [Ping timeout: 248 seconds]
TheVibeCoder has joined #ffmpeg-devel
TheVibeCoder has quit [Changing host]
TheVibeCoder has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
jarthur has quit [Quit: jarthur]
Marth64[m] has quit [Remote host closed the connection]
MisterMinister has quit [Remote host closed the connection]
Marth64[m] has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
acryo has quit [Ping timeout: 252 seconds]
acryo has joined #ffmpeg-devel
acryo has joined #ffmpeg-devel
acryo has quit [Changing host]
derpydoo has joined #ffmpeg-devel
derpydoo has quit [Remote host closed the connection]
<thardin>
do I understand correctly that fragmented mp4 does not have stts or ctts boxes? or rather, that they are at best empty?
<thardin>
trex, tfhd and trun instead fulfill the same purpose
<thardin>
the sample I'm looking at has stts, but it's empty. and it has no ctts
<TheVibeCoder>
speak in simple english please
<thardin>
fragmented mp4 indexes each fragment separately
<thardin>
if I'm not mistaken, this means that one is free to assume there isn't actually any indexing data in the header (moov box)
<thardin>
meaning I don't have to attempt to merge any stts+ctts data with trun data
<wbs>
thardin: a fragmened mp4 has a moov box at the start. the moov box _may_ have some samples in stts/ctts, or it may be entirely empty
<thardin>
gah
<wbs>
in early specs, it wasn't allowed to have an entirely empty moov
<wbs>
or perhaps it wasn't in the specs. but old QuickTime Player didn't play it unless the moov described some samples
<thardin>
perhaps it isn't so bad though. one could interpret moov in fragmented mp4 as the first fragment of the file
<wbs>
yes, pretty much
<wbs>
what are you working towards?
<thardin>
not having to parse the entire file when opening a fragmented file
<wbs>
I see
<thardin>
there's a bunch of stuff in mov.c to make that almost possible. indexing is the main obstacle
<thardin>
to support this sanely, mov.c has to be made more idempotent
<thardin>
which the elst stuff most definitely is not
<thardin>
the things in mov.c about overlapping fragment has me worried
<wbs>
ah; with tfdt that is technically possible I guess
j45 has quit [Ping timeout: 248 seconds]
j45_ has joined #ffmpeg-devel
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<thardin>
not quite. it allows stretching the duration of the last sample in the previous fragment
<thardin>
it says nothing of the opposite case. which to me sounds like a good reason to reject such files
<wbs>
having tfdt be >= start of last sample of previous fragment, but < end of last sample of previous fragment sounds like a case worth tolerating too
<wbs>
as the duration of the last sample of a fragment can, at times, be a heuristic guess
<thardin>
hm. perhaps
<thardin>
4a9d32baca3 is the commit that introduces support for that case. it's for DASH
<thardin>
fate-mov-frag-overlap tests it
<thardin>
but it doesn't just adjust the duration - it drops frames
j45_ has joined #ffmpeg-devel
<thardin>
said frames appear to be duplicates. I guess that's kind of sensible. sort of.
<thardin>
michaelni even correctly identifies the problem with not having read the previous trun
<thardin>
yet the patchset was accepted anyway, rather than the offending tools being fixed
derpydoo has joined #ffmpeg-devel
<thardin>
perhaps it's possible to detect when the resulting pts is outside the composition interval of the relevant fragment
<thardin>
else the resulting decoded essence will be different depending on where decoding starts
<thardin>
"IsoMedia File Produced with GPAC 0.7.1-revrelease" do we really need to support ancient versions of mp4box?
<thardin>
it's at 2.4 now
derpydoo has quit [Quit: derpydoo]
jamrial has joined #ffmpeg-devel
BradleyS has quit [Quit: quit]
BradleyS has joined #ffmpeg-devel
ffsteve has joined #ffmpeg-devel
<BtbN>
It's just not the reality that git.ffmpeg.org is the main repo. All pushes have to go to git.videolan.org, or source.ffmpeg.org, which is an alias for g.v.o. git.ffmpeg.org is simply a mirror.
<BtbN>
Changing that is also not super trivial, since pointing source.ffmpeg.org anywhere else would lead to ssh key errors for everyone.
<BtbN>
And would also break everyones setup who pushes to g.v.o, which is plenty of people.
microlappy has joined #ffmpeg-devel
microlappy has quit [Quit: Konversation terminated!]
<haasn>
ramiro: I found a case where plane splitting is substantially slower than not plane splitting, and I'm not entirely sure why
<haasn>
I'm starting to feel like we shouldn't plane split always, but only do it when the flags are different per plane, e.g
<haasn>
it also presents a number of other complications
<haasn>
so I think I don't want to plane split in general, if we can avoid it
System_Error has quit [Remote host closed the connection]
<kierank>
FFmpeg needs to play the waveform from the voyager probe
<thardin>
As iOS represents permissions in XML, these differences were quite useful to an attacker. These attacks were possible because the parser was more permissive in accepting an input than required by the specification.
<compn>
h26forge was a neat read. yeah ffmpeg isnt good as a fuzzer :D
<thardin>
fuzzing is still useful, but it's only a heuristic
<thardin>
I wonder to what extent ffmpeg is vulnerable to percent encoded NULLs (%00). probably quite a bit
<thardin>
or invalid unicode bytes
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
LaserEyess has quit [Quit: fugg]
LaserEyess has joined #ffmpeg-devel
LaserEyess has quit [Changing host]
LaserEyess has joined #ffmpeg-devel
<compn>
i like h26forge as a fuzzer. its too bad a fuzzer for each popular format/codec cannot be made easily like that
<compn>
e.g. they talked about h265.
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]
mkver has joined #ffmpeg-devel
mkver has quit [Read error: Connection reset by peer]