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: 240 seconds]
sudden has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
derpydoo has joined #ffmpeg-devel
thilo has quit [Ping timeout: 276 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
lemourin8 has joined #ffmpeg-devel
lemourin has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
lemourin8 is now known as lemourin
dellas has quit [Remote host closed the connection]
jamrial has quit []
kurosu has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 255 seconds]
Martchus_ has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
Marth64 has quit [Ping timeout: 260 seconds]
Marth64 has joined #ffmpeg-devel
rooisnoek has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
jarthur has quit [Quit: jarthur]
Krowl has quit [Read error: Connection reset by peer]
ngaullier has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
ngaullier has quit [Client Quit]
Krowl has joined #ffmpeg-devel
derpydoo has quit [Ping timeout: 246 seconds]
Marth64[m] has joined #ffmpeg-devel
mcfrdy has quit [Ping timeout: 260 seconds]
Marth64 has quit [Ping timeout: 252 seconds]
mcfrdy has joined #ffmpeg-devel
<mkver>
Do we actually require to use av_opt_next() to iterate over an object's options?
ccawley2011 has joined #ffmpeg-devel
<elenril>
don't think so
<elenril>
sizeof(AVOption) is a part of the ABI
<elenril>
mkver: should I wait for more comments on the bsf/ patch?
<mkver>
I don't intend to change sizeof(AVOption); I intend to change traversing it.
<elenril>
the new version only adds -I for objects under bsf/
<elenril>
change how?
<elenril>
huh, what are these ranges
<elenril>
they seems entirely unused
elastic_dog has quit [Ping timeout: 256 seconds]
<mkver>
We often have the case that several components use nearly the same options. I intend to make it possible to share these common options. My change would change the sentinel: Currently name == NULL means end-of-options. But we could add a const AVOption* to default_val for the common options. If this is set, av_opt_next() would return it.
<mkver>
Btw: Currently our sentinels are all of type AV_OPT_TYPE_FLAGS. We should add a proper sentinel to that enum on the next bump.
<mkver>
Another thing that is not nice about AVOptions are that the AVRational is never used for the default value.
<mkver>
This could be fixed by adding a flag for compatibility or it could just be changed on the next bump if we presume there to be no definitions of AVOption out of our tree.
elastic_dog has joined #ffmpeg-devel
<mkver>
Seems like it is handled inconsistently whether AV_OPT_TYPE_CONST uses the int64 or the double default value.
<elenril>
there are multiple other things I'd like to fix about avoptions
<mkver>
Actually, min and max should be a union of double and int64_t and uint64_t. This would unfortunately be an API break.
<elenril>
* there is a need for list-type options
<elenril>
* possibly also for dynamically allocated options
<elenril>
my idea for the latter would be to add something like dynamic_options_offset to AVClass, and modify options traversal to also read them from there
<mkver>
Would these list-type options replace the lists of AV_OPT_TYPE_CONSTS?
<elenril>
no, they would be for options that write to list-of-foo
<elenril>
my idea so far is to make it an option flag
<elenril>
but I didn't get to actually writing any code yet
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
compnn has quit [Read error: Connection reset by peer]
compnn has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
<Traneptora>
do we have a specific Side Data field for EXIF?
<Traneptora>
it looks like mjpegdec.c parses the Exif buffer and copies the dictionary into AVFrame->metadata
<JEEB>
I don't think we do
<Traneptora>
how does an encoder know which AVFrame.metadata fields are Exif fields? if you wanted to write them on encode
<JEEB>
I think the current not-so-great state of affairs is that usually if that's a thing it just attempts to take all metadata entries and then loops through them or something
epony has quit [Remote host closed the connection]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
epony has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
tufei_ has quit [Remote host closed the connection]
tufei_ has joined #ffmpeg-devel
<mkver>
Can we make av_opt_set_defaults and av_opt_set_defaults2 return an int on the next major bump?
<mkver>
I presume we need proper_replacements, don't we?
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]
Krowl has quit [Read error: Connection reset by peer]
dellas has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
kurosu has joined #ffmpeg-devel
Marth64[m] has quit [Ping timeout: 264 seconds]
<elenril>
mkver: probably yes, someone could be storing a function pointer to them
<elenril>
and do we really need both?
derpydoo has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
Marth64[m] has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<jdek>
does anyone have access to a mips machine to run checkasm on?
<JEEB>
unfortunately I don't think I can upload binaries easily to my router
<JEEB>
:)
<courmisch>
I don't do necromancy
<courmisch>
oh yeah, my ubiquiti is probably Debian MIPS but no uploading exes
<jdek>
uhh maybe I can use qemu user
<courmisch>
MIPS is av_deprecated
<courmisch>
unleash the necrophages^Welenrils
<elenril>
I don't see a reason for anything besides x86 to exist
<courmisch>
I see 2000's elenril traveled in time to kill his future self
<courmisch>
I'm calling the time continuum police
<elenril>
you could say that about anyone
<courmisch>
x86 optimisations are useless. Just write WASM SIMD
<elenril>
yuck, disgusting
<elenril>
I'd rather write FORTRAN
<courmisch>
it can't be worse than x86
<elenril>
itanium?
<courmisch>
I mean WASM can't be worse than x86
<courmisch>
obviously you can make toy architectures worse than x86
<jdek>
I don't think I've ever seen FORTRAN code
<courmisch>
I think I have only seen FORTRAN code in slides about bad programming languages
<elenril>
it's still quite common in physics
<courmisch>
but I hear it's better than RPG and Cobol
<elenril>
mostly for hysterical raisins, but I know people who write new code in it
<courmisch>
why not, some OSS project still write C99 code afterall
<elenril>
some of them quite technically competent, which is rather baffling
<jdek>
'i learned it 40 years ago so i will continue using it'
rooisnoek has quit [Quit: Leaving]
<courmisch>
talking about C to them must feel like me talking about Rust to the greybeards here
<jdek>
or nevermind 40 years is even old enough for C to be quite a bit older still
<courmisch>
for some definition of C
<courmisch>
even ISO C89 is not 40 years old, though I don't know how similar ANSI C84 was
<courmisch>
because originalis C programmandi lingua does not look very much like what I'd call C
<elenril>
no, I think in many cases it's "there's tons and tons of highly tested and verified code for this problem in FORTRAN, so using anything else is a massive pain"
<courmisch>
Lille metro is still running Ada
<elenril>
what's wrong with ada
<courmisch>
the code does not scale up, and they are 10+ years late on doubling the train length
<courmisch>
what's wrong with Ada is nobody understands it anymore
<courmisch>
or maybe it was the data bus used for the trains to talk to each other that's too low bitrate
<Marth64[m]>
I have a MIPS router laying around somewhere it might take executables
<JEEB>
:D
<Marth64[m]>
or a PlayStation 1 haha
<JEEB>
oh right
<JEEB>
I have a PSP
<JEEB>
although that requires custom binary format
<Marth64[m]>
oh nice, I always thought it was arm. til
<courmisch>
were there any significant console in 32-bit Arm?
<JEEB>
nintendo things
<courmisch>
AFAIK, Switch is Armv8
<JEEB>
DS, 3DS etc
<JEEB>
and I think GBA as well
<courmisch>
and I think my Wii is PPC?
<JEEB>
Marth64[m]: it is something in the middle between PS1 and PS2
<JEEB>
yea, gamecube and wii are PPC
<JEEB>
Marth64[m]: this is also why the PS1 emulation on the PSP is great
<Marth64[m]>
it makes sense now....I had always wondered how they got it right on PSP so long ago too
<Marth64[m]>
courmisch: with all this said, in theory I can start up PS2 with linux, and I do have the NIC add-on. not sure if that would help at all
<Marth64[m]>
i'll hunt for any other MIPS i got
<Marth64[m]>
sorry, jdek*
<Marth64[m]>
probably too old
<courmisch>
meh, we should remove MIPS and 386, and keep x86-64, Armv7 and Armv8 for legacy devices
<Marth64[m]>
386 is still supported?!
<Marth64[m]>
also ecstatic to see CrystalHD go away. i used to have one of those cards, very hard to work with
<courmisch>
I don't know if 386, 486 and 586 are still supported specifically, but certainly 686 still is and I call that 386 as a whole
<courmisch>
even Linux distros are dropping 386 now
<jdek>
Marth64[m]: ill just use qemu user and binfmt i have to test a few archs anyway
<Marth64[m]>
i figured that's the better path. i think the excitement of tinkering with old consoles got the best of me
Krowl has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
<Marth64[m]>
I found 2 very small issues in latest DVD patch on the ML, but it's in otherwise pretty solid shape. I don't want to spam the ML so will wait for any review before pushing a new version with the minor update
<Marth64[m]>
(improvement for error handling, if on the happy path there shouldn't be any issues)
<elenril>
you need to come to fosdem and beat people with a large trout to get reviews
<elenril>
it is known
<Marth64[m]>
haha sounds fun actually. I am in no hurry, thankful for you all teaching me little bits and pieces over the past yr :)
<Marth64[m]>
i know there are bigger and more important things
<Marth64[m]>
than some random person's obsession with dvd don't even know how i got here to begin with
<elenril>
it happens
<JEEB>
indeed :)
<elenril>
I started trying to get matroska ordered chapters to work
<elenril>
and look where it got me
<elenril>
we STILL don't support them
<Marth64[m]>
it's neat in theory but sounds like nightmare in practice
<Marth64[m]>
can't blame you
<Marth64[m]>
I do have matroska IETF language tags on my eventual todo list (e.g. locales with country codes)
<elenril>
I had a working patch in 2008
<elenril>
it was just an unworkable hack
<Marth64[m]>
I had researched it briefly last year when studying DVD angles (the interleaved streams)
<Marth64[m]>
but seemed too much work or hack like you said
<Marth64[m]>
props for trying
<elenril>
I now believe it should be exported as a playlist
<JEEB>
virtual timelines~
<elenril>
except we don't support playlists
<elenril>
(it was my GSOC project in 2011, but...)
<Marth64[m]>
no protocol handler for m3u or edl?
<elenril>
no API to export such information more like
<Marth64[m]>
ahh
<JEEB>
yea since it is a single piece of media, but it has a virtual time line
<elenril>
parsing the formats themselves is easy
<elenril>
the hard part is settling on a good way of exporting this information
<elenril>
that covers all these weird cases
<JEEB>
funny enough the mov/mp4 reader already can do referenced files :D
<elenril>
Daemon404 keeps complaining how it's an atrocious hack
<elenril>
and mov.c sure is one special file
<JEEB>
yea
<JEEB>
given how the full edit list virtual time line stuff isn't properly exposed, it's a hack
<Marth64[m]>
touching mov makes me nervous, i'm only in there for DVD subs and feel like have to go very slow to make sure I don't cause side effects
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
<Marth64[m]>
i'm going to go back to the remove soft telecine in mpeg2 work now
<Marth64[m]>
i had gotten to the point of changing the headers but need to also duplicate frames which will be fun in a bsf
<Marth64[m]>
evil hacks to remove evil hacks
ngaullie has quit [Ping timeout: 256 seconds]
<elenril>
duplicating frames in a bsf should not be especially bad
<Traneptora>
JEEB> I think the current not-so-great state of affairs is that usually if that's a thing it just attempts to take all metadata entries and then loops through them or something
<Traneptora>
would there by any interest in creating AV_SIDE_DATA_EXIF
cone-297 has joined #ffmpeg-devel
<cone-297>
ffmpeg Anton Khirnov master:887a7817b667: lavc: move bitstream filters into bsf/ subdir
<elenril>
Traneptora: I'm not a big fan of AVFrame metadata tbh
<elenril>
i'd prefer this to be done in the demuxer, if possible
<Marth64[m]>
elenril: thx, I will do a pull on your move bsf push and work from there
Krowl has quit [Read error: Connection reset by peer]
<Traneptora>
elenril: in either case, the current state of affairs for decoders that support exif (e.g. mjpegdec) is to parse it into an AVDictionary and then assign all the tags to AVFrame.metadata
* JEEB
stabs vmware
<Traneptora>
which seems to me like a bad way to do it
<Traneptora>
I feel like if we just treat it like ICC profiles it is better than how it is currently handled
<Traneptora>
(i.e. just a buffer of side data)
<kepstin>
some of the stuff in exif definitely should be parsed out tho; things like rotation metadata should be exposed in ffmpeg's standard form
<Traneptora>
ye, sure
<Traneptora>
and that parsing code already exists in avcodec/exif.c
<Traneptora>
it's just the current way of doing things makes it nearly impossible to keep exif data self-contained
<Traneptora>
mjpegdec.c currently calls the parse code in exif.c, and then manually searches for Orientation and sets that metadata tag
<kepstin>
that's true of basically all container-level metadata in ffmpeg atm tho; it gets remapped to ffmpeg's internal metadata representation, and anything that's not representable like that gets lost.
<Traneptora>
however, every decoder has to do what mpegdec.c does
<kepstin>
(iirc there's issues with e.g. multivalue tags in id3v2 and such too)
<Traneptora>
I feel like it would be better if there was something like FF_CODEC_CAP_EXIFDATA, and decoders could declare that codec cap and then just attach AV_SIDE_DATA_EXIF
<Traneptora>
and then generic avcodec code would be responsible for calling the parser and extracting the orientation tag
<Traneptora>
it would make it much easier to add Exif support to other formats that support it without duplication, e.g. png's eXIf chunks
<elenril>
kepstin: >anything that's not representable like that gets lost.
<elenril>
that's not exactly true
<elenril>
we don't lose tags that don't have standard mappings, they are preserved as they ae
<elenril>
*are
<Traneptora>
is there anything wrong with the approach I described above
<kepstin>
except for things that can't be represented, like multi-value tags
<elenril>
we do lose multi-value tags, that could be fixed with AV_DICT_MULTIKEY
<elenril>
watches=pelcome
<Traneptora>
I mean before I start working on the above change, I want to know if it's fundamentally flawed
<Traneptora>
or if it sounds fine in theory
<kepstin>
that approach seems like it would work, i wonder how it would contrast against making the exif handling code basically shared library functions that could be called from multiple places?
<Traneptora>
atm exif.c exports ff_exif_something and also avpriv_exif_something
<Traneptora>
ideally this would be an avcodec-only change
<elenril>
avpriv is satan
<Traneptora>
ye I agree
<Traneptora>
it may make sense to change the code to av_exif_something
<Traneptora>
and then avformat can call it for realsies
rvalue has quit [Ping timeout: 276 seconds]
rvalue has joined #ffmpeg-devel
<frankplow>
wbs: Does http://0x0.st/HDqq.patch fix your stack overflow on ARMv7 for APSALF_A_Qualcomm_2?
zsoltiv_ has quit [Ping timeout: 264 seconds]
zsoltiv_ has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
Daemon404 has left #ffmpeg-devel [truly yall have lost the plot]
<Traneptora>
I'm getting an ABI version mismatch for libvpx's encoder
<Traneptora>
not entirely sure why
<Traneptora>
do we have metadata for content light level?
<Traneptora>
i.e. black point & white point
<elenril>
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL?
<Traneptora>
doi
<Traneptora>
ty
<elenril>
kierank: could you please try to be more constructive in the STF thread
<elenril>
I agree that it's all very problematic, but I don't see you suggesting what should be done instead
kurosu has quit [Quit: Connection closed for inactivity]
Marth64[m] has quit [Read error: Connection reset by peer]
beastd has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
<mkver>
Marth64[m]: Why would you need to duplicate frames/packets when removing soft telecine?
<mkver>
All you need to do is changing some flags.
<mkver>
(Very old, will probably lead to conflicts now.)
<Marth64>
mkver: I can't remember exactly why I thought that, most likely I misguided myself. Your link is really great, Do you have any issue if I try to revive and test it?
<mkver>
No.
<Marth64>
thanks, I'll let you know how it goes
epony has quit [Ping timeout: 264 seconds]
cone-297 has quit [Quit: transmission timeout]
<j-b>
Good morning people
___nick___ has quit [Ping timeout: 246 seconds]
<kierank>
elenril: I would propose something but you know perfectly well I'll get conspiracy laden rants at me
<kierank>
About your employer most likely
<elenril>
you get those anyway
<elenril>
(and technically fflabs is not my employer)
<Traneptora>
if this is german gov't money it's a hard sell to pay someone in North America with it
<Traneptora>
extra paperwork to prove to the german gov't that it's worth to send money to the US in order to do this
<wbs>
frankplow: yes, that seems to fix the issue as well
<kierank>
I think the answer is what remi proposes, IT companies or individuals make proposals, they have contracts with STF and GA decides.
<elenril>
I don't think STF wants to deal with individuals
<elenril>
and GA approving the project before it's started is still very tricky wrt review and merging
<kierank>
I agree
<kierank>
That is the most egregious part that will never fly in this project.
Daemon404 has joined #ffmpeg-devel
<Marth64>
I have managed many teams and project over the years few have produced accurate LoE estimates. It's literally a dark art
<Marth64>
Wishing you all good luck on that resolution
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
<j-b>
I know dark arts :)
<BBB>
LoE?
<Marth64>
Level of Effort
<BBB>
ah
<Marth64>
just another fun project management buzzword
<Marth64>
"Thou shall not block the critical path"
<Marth64>
I'm cringing just saying it
* Marth64
runs from my own reality
<Marth64>
j-b: as a good leader should. good managers unfortunately have to eat dirt from all sides and balance it out
<Marth64>
and sometimes that mean dark arts lol
dellas has quit [Remote host closed the connection]
Marth64 has quit [Quit: Leaving]
kasper93 has quit [Remote host closed the connection]
Marth64 has joined #ffmpeg-devel
compn has joined #ffmpeg-devel
compnn has quit [Read error: Connection reset by peer]
Marth64 has quit [Quit: Leaving]
<Traneptora>
for packed pixel formats like rgb24, is av_frame_get_plane_buffer(frame, 0)->data always going to point to frame->data[0]?
mkver has quit [Ping timeout: 246 seconds]
<Traneptora>
basically I'm trying to calculate the size of frame->data[0]
Marth64 has joined #ffmpeg-devel
<kierank>
Line size * height
<thardin>
can't line size be negative?
<thardin>
such as for fantastic formats like bmp
<jamrial>
negative strides are for flipping the image, i thought
<thardin>
yep
TheSashmo has quit [Quit: Leaving...]
TheSashmo has joined #ffmpeg-devel
TheSashmo has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
TheSashmo has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
<Marth64>
mkver: it does seem to work
<Marth64>
however.. with source 29.97(soft telecine)->23.96(bsf used to set framerate+progressive_sequence), unless I output to m2v container, framerate at the stream property level is still 29.97
<Marth64>
assuming this is limitation of BSF API probably. works great going to m2v
<Traneptora>
kierank: line size * height doesn't work if the linesize is negative, and also doesn't work if the linesize is larger than the size of a row
<Traneptora>
e.g. if you have a 8x8 gray8 image with a linesize of 100, you don't need 800 bytes. you need 708
<kierank>
You asked for the size of the buffer
<Traneptora>
is the buffer guaranteed to contain the trailing data?
<Traneptora>
i.e. if you have an 8x8 image with linesize=100, is it guaranteed to be 800 and not 708
<kierank>
Why 708?
<Traneptora>
700 for the first 7 rows, and then 8 for the last row. trailing data not needed
<kierank>
I believe guaranteed to be 800
<jamrial>
cd ..bu
<jamrial>
wow, fail
cone-342 has joined #ffmpeg-devel
<cone-342>
ffmpeg Frank Plowman master:85e031d5bfa8: lavc/vvc: Increase IntraEdgeParams buffer size
dellas has quit [Remote host closed the connection]
sudden has quit [Ping timeout: 255 seconds]
epony has joined #ffmpeg-devel
sudden has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
<cone-342>
ffmpeg James Almer master:66f028accbcc: avcodec/cbs_h266: fix logic setting num_layers_in_ols when vps_ols_mode_idc is 2