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
Traneptora has joined #ffmpeg-devel
Traneptora has quit [Remote host closed the connection]
epony has quit [Remote host closed the connection]
Traneptora has joined #ffmpeg-devel
durandal_1707 has quit [Ping timeout: 260 seconds]
durandal_1707 has joined #ffmpeg-devel
epony has joined #ffmpeg-devel
navi has quit [Quit: WeeChat 4.0.4]
cone-564 has quit [Quit: transmission timeout]
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
mkver has quit [Ping timeout: 245 seconds]
qeed has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
epony has quit [Ping timeout: 264 seconds]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
jamrial has quit []
<Marth64>
Any known issues with AVFMT_FLAG_CUSTOM_IO `fftools/ffmpeg: convert to a threaded architecture`?
<Marth64>
after that commit*
<Marth64>
probably bug in my code but I can't reproduce it just prior to that commit
<Marth64>
The output file is comes out just fine, but ffmpeg cli prints progress in a strange way and prints the wrong output duration
ramiro has quit [Ping timeout: 255 seconds]
ramiro has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 240 seconds]
cone-038 has joined #ffmpeg-devel
<cone-038>
ffmpeg Leo Izen master:40bd65a72aa3: MAINTAINERS: add my new PGP key
MisterMinister has joined #ffmpeg-devel
epony has joined #ffmpeg-devel
tufei__ has joined #ffmpeg-devel
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Ping timeout: 240 seconds]
<Traneptora>
Marth64: how? elaborate plz
<Marth64>
will work on articulating it and write here
staceee has quit [Ping timeout: 256 seconds]
sm2n has quit [Ping timeout: 276 seconds]
HarshK23 has joined #ffmpeg-devel
<Marth64>
Traneptora: Will DM a link to 2min screen capture visually showing the symptoms. When running same demuxer in tree prior to parallel change, output status reporting is smooth and times correct.
<Traneptora>
why not just post the final result
<Traneptora>
I don't really want to watch a video of your console
<Marth64>
Sure
epony has quit [Remote host closed the connection]
<Marth64>
TLDR: Command is simple. DVD in, -map 0 -c copy to an MKV. Status line shows time as N/A for few seconds, then gets stuck on 2 timestamps mid-conversion. Meantime, file size is growing while bitrate reported exceeds 20000000.0kbits/s . Finally, job finishes. Output duration is reported wrong (less than actual). I go inspect the output file with ffprobe, and duration is correct. I run it through some encodes to /dev/null, and no non-monotonous
<Marth64>
timestamps show
<Marth64>
and it is visually coherent when played back
<cone-038>
ffmpeg Niklas Haas master:3a061facff61: doc/APIchanges: fix wrong version number
<Daemon404>
on files with both stream/packet level hdr mastering metadata, and container level, the outputted frame now has both the container level metadata (which was previously attached only to the avstream) and packet level metadaa attached
<Daemon404>
and no way to tell which is which
<Daemon404>
my existing code tries to prefer the packet level metadata over stream level
<Daemon404>
and it broke silently when i updated
<durandal_1707>
fun
<jamrial>
ugh, frame side data can have more than one entry of each type
<Daemon404>
i mean it also shouldnt clobber it if thats what youre thinking.
<jamrial>
packet should have priority, i'd say
<jamrial>
over global
<Daemon404>
yes that was what my code was doing :P
<jamrial>
ok so, global is first, then packet
<jamrial>
in the output frame for your scenario
<Daemon404>
yep
<jamrial>
the lavu helpers only fetch the first entry
<Daemon404>
so i end up with global
<jamrial>
so you'd have to manually get the latter
<Daemon404>
yea
<jamrial>
what do you suggest?
<jamrial>
i think at first i tried to replace global with packet, but someone asked me not to, hence both being attached
<jamrial>
maybe i can swap the order
<Daemon404>
that would fix my code at least
<Daemon404>
but going fwd, isnt it impossible to tell which came from which?
<Daemon404>
aside from order
<jamrial>
mmh, there's a metadata field in avframesidedata
<jamrial>
maybe it can be used for this in some form
<Daemon404>
a new field seems better than using a dict, but im not really sure which is better
<Daemon404>
maybe elenril should be summone to opine
<jamrial>
i'd rather avoid new fields
<Daemon404>
but this seems like a fundemental property of side data if were propagating i
<Daemon404>
it*
<jamrial>
i'll send a patch to swap the order for now, to recover the old behavior
<jamrial>
packet side data should have priority over global if you naively read the first entry of a given type in the output frame
<Daemon404>
agreed
<jamrial>
then we can see how to signal origin
<elenril>
I opine that using the dict for anything is blasphemy
<elenril>
it should die in a fire
<jamrial>
you really don't like dicts :p
<jamrial>
lets add an avtree as replacement
<elenril>
I don't like submarine APIs
dellas has joined #ffmpeg-devel
<durandal_1707>
you do not like O2
<elenril>
it also seems like a bad idea to have duplicate side data entries
<jamrial>
that was my intention, but someone requested both to be exported if present
<jamrial>
i think it was mkver
<durandal_1707>
ffmpeg is becoming more and more mess
<Daemon404>
why are we propagating global side data to frames at all again?
<Daemon404>
(i do actually forget)
<elenril>
because global side data, by definition, applies to the entire stream
<elenril>
i.e. all the frames
<Daemon404>
is it intended to be the sole source of this data going forward?
<elenril>
don't understand the question
<elenril>
there can still be per-frame information
<elenril>
or per-packet
<Daemon404>
yes but now we are *also* attaching avstream side data to frames
<Daemon404>
is the intent to remove avstreams side data and only put it on frames?
<elenril>
still don't understand the question
<jamrial>
no, the intent is to have frames contain all the relevant metadata available at the container and bitstream level
<elenril>
demuxer reads global side data from the container global header
<Daemon404>
its a pretty basic questio
<Daemon404>
n
<elenril>
the caller may or may not give this global side data to lavc
<elenril>
then lavc will copy this global side data to frames
<Daemon404>
my question was simply if we intend to stop exposing e.g. container level side data in avstrem at all
<elenril>
no, there's nothing to replace it with
<Daemon404>
i.e. only expose it in *one* place vs 2
<Daemon404>
yes that was going to be my point
<Daemon404>
in this case IMO we should just not attach conatainer level hdr metadata if frame level data aleady exists
<elenril>
that sounds reasonable ot me
<elenril>
but beyond that we might consider
<elenril>
1) not attaching global side data to frames at all (more hassle for the user, but also more control)
<elenril>
2) having a flag that enables 1)
<elenril>
in general the intent could also be that container overrides codec layer
<haasn>
Daemon404: having stream-level metadata in frames is immensely useful downstream where you often have APIs that only take an AVFrame and don't particularly care what stream it came from, if any
<Daemon404>
if you really want it then we need a field to indicate the origin then
<Daemon404>
otherwise you just get 2 metadata attached and no idea which is whih
<Daemon404>
(in the case you have both)
<durandal_1707>
and double standards everywhere, it just become corporate code-dumpster
<elenril>
i think we should avoid having duplicate side data
<Daemon404>
well its not duplicate so to speak
<elenril>
duplicate meaning multiple entries of the same type
<Daemon404>
ok
<haasn>
it makes sense to have frame-level metadata override container-level metadata when both are available, because the user can still recover container-level metadata from the avstream
<haasn>
that would be a justification to have metadata in both places; since the frame would just effectively contain a shadow of the stream-level metadata
<haasn>
though I think the common practice is to have container-level metadata override the frame-level metadata
<haasn>
in e.g. mpv
<Daemon404>
that would leave frame level totally unexposed in the api
<Daemon404>
which is not ok
<Daemon404>
(if it did what mpv id)
<elenril>
haasn: what do you mean by both places
<haasn>
elenril: attached to avstream and avframe
<elenril>
well, global side data will always be exported in avstream, that's not in question
<haasn>
in plplay I also have stream-level props override frame-level props
<haasn>
right
<elenril>
I'd say lavc should not make policy on this
<haasn>
probably for the better
<elenril>
it should be the caller's decision which one takes priority
<haasn>
generally the intent of the decoding api should be to expose what is actually encoded in the file
<elenril>
if the caller wants that, they could simply copy stream side data to the decoder
<elenril>
then they get pure codec-layer side data
<elenril>
and can then decide whether to replace it with the stream one or not
<elenril>
err I mean >they could simply NOT copy
<haasn>
intuitively, I'd have two lists in AVFrame, and a helper function to do a cascading lookup
<haasn>
simply because that allows us to preserve the existing data type
<jamrial>
yeah, we need helpers that fetch entries beyond the first of each type
<Lynne>
I think frames should be self-contained and have everything needed to correctly present them
<haasn>
but if the intent is to replace AVPacketSideData by something refcounted then it makes more sense to introduce AVSideData with an enum about the side data source
<elenril>
I don't think any such enums are a good idea
<elenril>
AVFrame should not make assumptions on where the data comes from
<elenril>
it does not need to be lavf
<elenril>
or lavc for that matter
<haasn>
then I guess the preferred alternative would be to enshrine a preferred order that preserves the order in which they were effectively decoded (i.e. list stream-level side data before frame-level side data)
<haasn>
and then it can be the user's decision to use the first (most high-level) vs last (most low-level) instance of a side data struct
<elenril>
I prefer to not have side data entries with duplicate types in the first place
<elenril>
decoders should prefer codec-layer side data over global when both are present
<elenril>
if the caller prefers container, they can override it manually on output
<Lynne>
sadly duplicate side data is already hardcoded in the API, as that's how region of interest side data is covered, as well as possibly some other side data
<elenril>
Lynne: regions of interest is itself an array
<haasn>
it is my impression that container side data tends to be more accurate, at least I remember this being the case for youtube et al. which is why mpv prefers container-level
<haasn>
though there is the argument that putting container after frame data preserves status quo of av_frame_get_side_data
<haasn>
(fwiw, as a motivating example, having stream-level metadata in frames would fix some annoying mpv bugs w.r.t dolby vision, because half of the dv RPU is stream-level and nobody has bothered plumbing that metadata all the way through the internal state)
<Daemon404>
differentiatig by order is an insane api...
<jamrial>
haasn: i thought strema level dv was only the config stuff?
<jamrial>
and rpus are bitstream
Krowl has quit [Read error: Connection reset by peer]
<jamrial>
elenril: wouldn't a new flag for export_side_data be better?
<elenril>
per side data type?
<jamrial>
no, just a flag to switch behavior in general
<elenril>
it's simpler, but is it better?
<BBB>
why as a string?
<elenril>
the other option is an array of enum AVPacketSideDataType
<elenril>
which seems more annoying to work with for most users
<elenril>
yes, ideally we'd have list-type options
<elenril>
watches=pelcome
lemourin has quit [Read error: Connection reset by peer]
<jamrial>
against string, the side data names as returned by av_packet_side_data_name() are way too long
lemourin has joined #ffmpeg-devel
<elenril>
too long for what?
<jamrial>
to use them in the field you propose
<elenril>
not really
<elenril>
the longest one is like 40 bytes
<elenril>
and there's 35 of them
<elenril>
I don't think 1.5kB per codec context (that can be freed after codec open) will kill anyone
<elenril>
a bigger problem is that they seem quite free-form and so someone could put a comma in there
ngaullier has quit [Quit: Leaving.]
<jamrial>
and yes, a single flag is simpler but not better. no finetunning per type
<jamrial>
if that finetunning is important, then i'd prefer to use enum values rather than a string
<elenril>
that won't be easily settable as an avoption then
MisterMinister has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<Lynne>
avoption does support named flags
<jamrial>
yes, but then you're limited to 64 different values at most, right?
Mista_D has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 252 seconds]
<Lynne>
right...
<Lynne>
maybe avoption can be hacked to add support for a flag in a 32-bit int array, like how it handles dimensions
AbleBacon has joined #ffmpeg-devel
cone-233 has quit [Quit: transmission timeout]
<elenril>
19:30:50 @elenril | yes, ideally we'd have list-type options
Katherine has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
tufei__ has quit [Remote host closed the connection]
<durandal_1707>
did you get back that paycheck so to keep FFmpeg alive?
<elenril>
are you having a psychotic episode again?
<elenril>
let your therapist know
<durandal_1707>
aha, business still going well?
<durandal_1707>
no layoffs in FFland?
<jamrial>
please, no more drama
<durandal_1707>
code quality crumbles down drastically with each new committ
<durandal_1707>
and ffmpeg is in each release slower with small packet demuxing/decoding
<durandal_1707>
i have a dream, FFlabs and FFmpeg dies off
<Katherine>
How about a no drama development question?
<Katherine>
Looking at the latest code, ffmpeg is still only supporting -encryption_scheme of [none | cenc-aes-ctr]. While a few years ago support for decrypting schemes of [cenc | cbc1 | cens | cbcs ] was added.
<Katherine>
I'm curious why support for encrypting cbcs hasn't been added? Nobody has wanted to do it yet? Or is there a technical reason? It's the only encryption that Apple platforms support as I understand.
<elenril>
that's kind of a backwards question
<elenril>
things get added because someone spends effort on adding them
<elenril>
and I guess nobody did that in this case
Krowl has quit [Quit: Krowl]
<Katherine>
That's what I was asking.
<elenril>
I see no mention of anyone talking about muxing support for it
<Marth64>
are there any small tasks I can help with? dvd is making me sick
<Marth64>
i've watched the same cartoon 50 times
Krowl has joined #ffmpeg-devel
<Marth64>
small/easy-ish*
<elenril>
add tests for filters, demuxers, and decoders that don't have them
<Katherine>
Thx elenril. What I wanted to know before I spend effort.
<Marth64>
ok. I picked the one to start. adxenc ... gotta dig up my old dreamcast tools
<Marth64>
adxdec*
<durandal_1707>
i have a dream
<Marth64>
25th anniversary this year
<Marth64>
feeling old
<Marth64>
literally have some ancient tools for it on a ZIP disk
<elenril>
don't think I ever even saw a zip disk
<Marth64>
run for the hills if you do :D
<Katherine>
I've seen a few. (Have boxes of them.) I worked for Iomega.
<elenril>
still have some floppies though
<jamrial>
i had a few of those too. 100mb was nice before cd burners were commonplace for backups
<Marth64>
ZIP disks were awesome but I think some variants were plagued with clicking
<Marth64>
1998 lyfe
<elenril>
speaking of retro tech, I am using a CRT screen at this very moment
<Marth64>
i bet interlace material looks great on it
<Marth64>
haha
<elenril>
it looks pretty good in general
<elenril>
I'd say better than most current LCDs
<elenril>
e.g. it can display black
<Marth64>
quality control was better back then
<elenril>
made in japan
<jamrial>
elenril: play a twitch shooter. make use of that low latency
<elenril>
lol
<Marth64>
omg is it a sony
<elenril>
NEC
<elenril>
manufactured in august 2002
<Marth64>
amazing.
Krowl has quit [Read error: Connection reset by peer]
epony has joined #ffmpeg-devel
<Marth64>
chorusnoise_2ch_44kHz_s16.wav blow my ears out
kurosu has quit [Quit: Connection closed for inactivity]
<Marth64>
Attach sample in email to samples-request?
<Marth64>
Encoded PCM file already in FATE, as I don't have non-copyrighted sample
<durandal_1707>
SARS-CoV-2-related pangolin coronavirus GX_P2V can cause 100% mortality in human ACE2-transgenic mice.
<Marth64>
scary
<microchip_>
oi
Katherine has quit [Quit: Client closed]
mkver has quit [Ping timeout: 260 seconds]
blb has quit [Ping timeout: 276 seconds]
blb has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
ccawley2011 has quit [Read error: Connection reset by peer]