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
hbbs has joined #ffmpeg-devel
hbbs has quit [Changing host]
hbbs has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 268 seconds]
Flat has quit [Quit: Rip internet]
rvalue has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
Flat has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
Gramner has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
mkver has quit [Ping timeout: 264 seconds]
dellas has joined #ffmpeg-devel
hbbs has quit [Quit: bye]
hbbs has joined #ffmpeg-devel
hbbs has quit [Changing host]
hbbs has joined #ffmpeg-devel
Gramner has quit [Ping timeout: 256 seconds]
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest9661
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
Guest9661 has quit [Ping timeout: 276 seconds]
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest937
lemourin has joined #ffmpeg-devel
lemourin has quit [Killed (erbium.libera.chat (Nickname regained by services))]
Guest937 has quit [Ping timeout: 276 seconds]
lemourin is now known as Guest1276
lemourin has joined #ffmpeg-devel
Guest1276 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
navi has quit [Quit: WeeChat 4.1.2]
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest1065
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest6187
Guest6187 has quit [Ping timeout: 256 seconds]
dellas has quit [Remote host closed the connection]
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
Gramner has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 276 seconds]
qeed_ has quit [Remote host closed the connection]
<Marth64>
some discs mux meaningful video segments in with their menu structure
<Marth64>
PgcDemux, another lgpl software, can do this
<Marth64>
i actually have it mostly working, but wanted to delete some validation code if i had the opportunity
<Marth64>
(as a next phase enhancement to my dvd patch on ml)
<compn>
neat.
<Marth64>
thx
<Marth64>
yeah playing them interactively is a red line i will not cross
<Marth64>
too much work
<compn>
well dont get discouraged if someone says they dont like your patch :)
<Marth64>
it doesn't bother me
<Marth64>
anyone can apply it, i hope somebody finds it useful someday, the alternatives aren't that great
<Marth64>
but it's there for all
<Marth64>
and i'm lucky enough to have gotten some reviews
<Marth64>
all previous dvd patches have died too
<compn>
used to be anti-dvd years ago
<compn>
maybe its changed since ffmpeg now has a lot more image and other weird formats
<Marth64>
i'm riding off the shoulders of dvdnav so it's contained in one file, except for some subtitle color conversion which is already used in other places
<Marth64>
nothing wild
<Marth64>
there is bluray support already even in libavformat (i do not plan on touching bluray though)
AbleBacon has quit [Read error: Connection reset by peer]
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
stevenliu has joined #ffmpeg-devel
stevenliu_ has quit [Ping timeout: 264 seconds]
Marth64 has quit [Ping timeout: 255 seconds]
Marth64 has joined #ffmpeg-devel
<Marth64>
i got it working
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<elenril>
Marth64: didn't you say you're done with dvd =p
<elenril>
and yes, demuxers can use parsers
<elenril>
haasn: how long does the train to brussels take?
<Marth64>
elenril: greatest version (after 3.5 reviews) is on ML. outside of a unused context var i found yesterday, it's basically perfect for actual video parts and very mature
<Marth64>
but then i got the crazy idea to demux menus too, because i want to be complete
<Marth64>
i have a sad imagination lol
<elenril>
a noble goal
<Marth64>
:D
<elenril>
next you'll do blurays I assume
<Marth64>
no unfortunately, too scared of patents there
<Marth64>
bluray i won't touch and there are good alternatives
<Marth64>
dvd is dying and someday the knowledge will be lost
<Marth64>
i want to do closed caption improvements next
<Marth64>
(eia608)
<Marth64>
little minor things. ffmpeg's decoder is actually quite good
mkver has joined #ffmpeg-devel
<Marth64>
but i have found some fixable flaws with positioning in assa
<Marth64>
when going eia608->ass
<Marth64>
if i didn't have a day job this is all i would do literally just tinker with ffmpeg
<elenril>
:)
<elenril>
be careful when staring into abyss
Marth64[m] has joined #ffmpeg-devel
Marth64 has quit [Killed (NickServ (GHOST command used by Marth64[m]))]
Marth64[m] is now known as Marth64
<Marth64>
never a dull moment in this code base
<Marth64>
:)
<purva>
Hello everyone,
<purva>
I'm Purva Yeshi, a pre-final year Electronics and Telecommunication undergraduate from VJTI, Mumbai. I did assembly coding for 8051 microcontroller and 8085 microprocessor. I've decent exposure to working with system software, especially C language.
<purva>
I'm very interested in the project "ARM assembly code for the VVC decoder" for GSOC 2024. I'm interested in working on a qualification task.
<elenril>
ffs
<elenril>
most AVOption definitions do not set unit through a designated initializer
<elenril>
which means adding things before it breaks everything
<elenril>
fun
<elenril>
maybe i should finally learn coccinelle
<Marth64>
meta code written to fix code?
<elenril>
yes
<Marth64>
looks cool
<elenril>
i wish it had better beginner docs
<Marth64>
it looks dead on github
<Marth64>
nvm, some random stranger's fork
<elenril>
reportedly people use it for linux
Marth64[m] has joined #ffmpeg-devel
Marth64 has quit [Killed (NickServ (GHOST command used by Marth64[m]!~Marth64@64.64.116.41))]
<elenril>
ah yes, ocaml
<elenril>
of course it is
<Marth64[m]>
as long as its not PHP
qeed has quit [Remote host closed the connection]
ravenJPL has quit [Quit: Leaving]
jarthur has quit [Quit: jarthur]
dellas has joined #ffmpeg-devel
<mkver>
elenril: Adding macros for AVOption definitions would also simplify the migration to using unions for min/max and using saner default values in the future.
Marth64 has joined #ffmpeg-devel
Marth64[m] has quit [Ping timeout: 272 seconds]
lemourin has quit [Ping timeout: 276 seconds]
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
lemourin is now known as Guest4339
lemourin7 has joined #ffmpeg-devel
Guest4339 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
<mkver>
dst_fc->device_ctx->internal->priv is the OpenCLDeviceContext*.
<mkver>
Same thing in line 2514 with d3d11.
<mkver>
Both OpenCLFramesContext and OpenCLDeviceContext have a cl_command_queue at the start.
crm has joined #ffmpeg-devel
<jkqxz>
Yes, I agree.
<mkver>
I will send a patch for you to test.
<mkver>
(I can't test this.)
<jkqxz>
Is there some static analysis tool which is catching that?
orthoplex64 has quit [Ping timeout: 268 seconds]
<mkver>
No, a dev looking at the code.
<mkver>
I am currently rewriting access to all hwcontext internals.
<mkver>
Need to finish this before the bump.
qeed has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
<mkver>
Patch sent.
<jkqxz>
The error will have no effect on default setups, because the frames command queue is just a reference to the device one. It would need the user to have created a custom command queue on the frames context.
<mkver>
Yeah, I saw that. It won't work any longer with my changes.
<jkqxz>
Fair.
<jkqxz>
I do not have a Windows device on to test this at the moment, maybe tomorrow.
<mkver>
Ok, I can wait.
<jkqxz>
Seems like static analysis should be able to catch that. "You only ever assign pointers to types A and B to this pointer to void, but on this line you read it as as pointer to type C."
<jkqxz>
Do we have any way to make feature requests to Coverity?
Marth64 has quit [Ping timeout: 246 seconds]
Marth64 has joined #ffmpeg-devel
<mkver>
Does Coverity even analyze this code?
<jkqxz>
Lynne: The text in the Vulkan spec clearly says that { VulkanFeatureEnabled[j] |= AV1SpecFeatureEnabled[i][j] << i; }, right?
<jkqxz>
Lynne: And our feature_enabled[i][j] is the same as AV1SpecFeatureEnabled[i][j].
<mkver>
BtbN: Are HAVE_OPENCL_D3D11 and HAVE_OPENCL_DXVA2 true for Coverity?
<BtbN>
no, it's building for Linux
<mkver>
Yeah, as expected.
<mkver>
(I also found out that one can actually query the value of defines as seen by Coverity by clicking on them.)
<jkqxz>
It would still be a useful feature, not just for this code.
<BtbN>
It could in theory alternate between Windows and Linux builds, but I have not figured out how to make their compiler wrapper cooperate with a cross compiler
<BtbN>
It's not exactly well documented
<mkver>
But before we complain to Coverity we should be sure that it would actually fail if passed the code.
<mkver>
Anyway, pal has experience with Coverity's support.
<mkver>
IIRC that experience was not successful.
<Lynne>
jkqxz: a human wrote that part of the spec, so the spec could be wrong
<Lynne>
using the array size macros the current version should be correct
<Lynne>
I'll raise an issue to fix the spec wording
<jkqxz>
Is there official example code to compare with?
<jkqxz>
Note that the array sizes for the two dimensions (number of segments and number of features) are both eight, so an inconsistency is hard to detect there.
<pal>
re: coverity, I have a reminder to ping them on Feb 27 after they indicated to me last year that a bug might be fixed "within the year"
<pal>
... my sense is that coverity is not a priority and perhaps on life support
<pal>
... still useful to catch stuff
<jkqxz>
Lynne: How many different implementations has this been tested against?
<Lynne>
jkqxz: nope, the nvsamples repo is still lagging behind, it's just us
<pal>
... many false positive
<Lynne>
one, mesa's
<Lynne>
nvidia should be releasing a driver "soon"
<jkqxz>
pal: Don't they sell this product for lots of monies?
<mkver>
Not to us.
<BtbN>
We could probably "replace" coverity with just clangs static analyzer? That'd also support more platforms.
<jkqxz>
Lynne: ... it is not a very convincing argument that the spec is definitely wrong when it is based on exactly one implementation which you also wrote.
<Lynne>
it isn't a very convincing argument picking a sentence someone wrote that was not looked at either
<Lynne>
we can fix it if problems arise
<Lynne>
jkqxz: if you insist, I can change it, it's not a problem
<jkqxz>
I want to find the right answer. If every other implementation has done the same thing then it's better to update the spec. If others all followed the spec then you want to change.
klaxa has quit [Quit: Quit.]
<jkqxz>
Have you run the argon streams through this with Mesa to check all the edge cases, btw?
<elenril>
>Your message to ffmpeg-devel awaits moderator approval
<elenril>
sadness and misery
<BtbN>
But this should work for almost all compilers now
<Lynne>
jkqxz: the issue is that there are no user clients for driver devs to write for, so I'd prefer to have it merged one way or another so it makes it into 7.0
courmisch has quit [Killed (NickServ (GHOST command used by courmisch_!~remi@vps-a2bccee9.vps.ovh.net))]
courmisch_ has joined #ffmpeg-devel
courmisch_ has quit [Client Quit]
courmisch has joined #ffmpeg-devel
<BtbN>
Works with msvc at least
another| has quit [Remote host closed the connection]
<BtbN>
mkver: Is there any specific reason you suggested going back to the original approach of just bumping the allocation alignment unconditionally? You suggested the more complex approach initially after all.
<BtbN>
Like, it being used for some static allocations as well?
<mkver>
The reason is that I am uncomfortable with reducing the alignment for e.g. static objects.
<BtbN>
I still don't think that's a huge issue, all those static allocations are aligned cause of SIMD as well
<mkver>
If you think it is fine, then go ahead and send it to the ML.
<mkver>
I will not object to it.
<BtbN>
I've given it a quick glance via grepping the codebase, and I'm pretty sure it's exclusively used for SIMD, not for any crazy page alignment.
<BtbN>
That would be MUCH bigger aligns anyway
<BtbN>
4kB or something
<BtbN>
I'm pretty confident it's fine
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<Marth64>
greetings
another has joined #ffmpeg-devel
<BtbN>
hm, there's a fate test failing, but I somehow doubt it's caused by the patch.
<elenril>
does it happen to be fate-ffmpeg-fix_sub_duration_heartbeat?
Marth64 has quit [Killed (NickServ (GHOST command used by Marth128!~Marth64@192.101.67.63))]
Marth128 is now known as marth64
<elenril>
jamrial: can you please unblock my patch from moderation?
<courmisch>
clearly patches too big to post without moderation should be forbidden
<courmisch>
think of the childr^Wreviewers
<BtbN>
How did it even end up in there? Accidental wrong sender address?
<jamrial>
elenril: 1600k?
rvalue has joined #ffmpeg-devel
<elenril>
??
<mkver>
You are not porting all AVOptions to designated initializers?
<jamrial>
Subject: [PATCH] all: use designated initializers for AVOption.unit
<jamrial>
Size: 1630612 bytes
<elenril>
mkver: just for unit, not everything
<elenril>
the patch would have been WAY bigger then
<mkver>
Even worse. It will mean that all AVOptions will have to be touched again when min and max are converted to unions.
<courmisch>
this clearly needs to be split in one patch per module
<courmisch>
and remember to assign them to elenril1, elenril2, ...elenril100
<courmisch>
so you get many votes on the next GA
<mkver>
lol
<jamrial>
it got base64'd, so that adds a bit
<courmisch>
thats' only 33.333333333333333333333333% more
cone-765 has quit [Quit: transmission timeout]
<elenril>
mkver: too bad, I can't fix everything at once
<elenril>
I need this for adding array-type options
<courmisch>
wasn't SMTP supposed to negotiate 8-bit cleanliness?
<elenril>
which are needed to fix some breakage for the release
<courmisch>
would be fun to see that patch crash the gitlab code review tab
<mkver>
What breakage?
<elenril>
jamrial: that's ML, not me
<elenril>
mkver: whether global or bitstream side data should be preferred
<mkver>
And when did this break?
<jamrial>
it's not a break as much as a change in behavior
<mkver>
And when did it change?
<jamrial>
ae22271620 i think
<jamrial>
global side data has priority over frame side data of the same type since then
<jamrial>
and it broke assumptions some library users had
Marth256 has joined #ffmpeg-devel
marth64 has quit [Killed (NickServ (GHOST command used by Marth256!~Marth64@98.159.224.180))]
Marth256 is now known as Marth64
another is now known as another|
zsoltiv_ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
qeed has quit [Ping timeout: 268 seconds]
Krowl has quit [Read error: Connection reset by peer]
rvalue has quit [Ping timeout: 272 seconds]
<mkver>
jamrial: Can't you find smaller files for this feature?
rvalue has joined #ffmpeg-devel
<jamrial>
mkver: there are none in the conformance suite
<mkver>
And? How have these files in the conformance suite been created?
<jamrial>
i have no idea
<mkver>
Is there no muxer for this?
<jamrial>
maybe libheif?
<jamrial>
new phones take photos in heic format, using grid (but not iovl)
<jamrial>
and said photos are going to be bigger anyway
<Marth64>
need/want samples from an iDevice?
<Marth64>
or pixel 7a
<mkver>
I don't know if you can make a file exhibiting this behaviour; or whether your files would be smaller than the ones already pushed to the fate-suite.
<APic>
♥
<Marth64>
I am not educated on heif at all but iovl - from a quick web search - sounds like it could be what the new phones use for their Live Mode photo overlays?
<Marth64>
if so happy to provide some, maybe of a really dark scene to keep it small
<Marth64>
Live Mode is some feature where they overlay a few photo frames together so you can pick the best shot
<JEEB>
what on iphone seemed to be live mode is where they capture like a second before the photo moment as HEVC video, and then when you show the image it will first play that short video
<Lynne>
heif was primarily invented because hardware encoders didn't support 200 megapixel images directly
<Lynne>
but yeah, they kept extending it with animation too
<JEEB>
and now they are specifying > Low-overhead HEIF
<Marth64>
ahh, bummer. I'll see if I have any androids that do heif
<Marth64>
probably none
Oneric has quit [Quit: Connection lost]
<Traneptora>
iirc iOS HEIC photos use the hwenc for tiling but they have visible seams on tile boundaries
<JEEB>
at least in the image viewer that doesn't show up
* JEEB
recently got an iphone for AV1 testing
Oneric has joined #ffmpeg-devel
<Lynne>
yup, no loop filtering across tiles is supported
<kierank>
I have pixel 7 if you need samples
<kierank>
No clue how to make it do heif
<Lynne>
it's like they reinvented jpeg 20 years later
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<BtbN>
My phone does the same nonsense, where every photo is a video now
j45_ has joined #ffmpeg-devel
<Marth64>
it's annoying honestly
j45 has quit [Ping timeout: 268 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<Marth64>
I miss HTC
Krowl has joined #ffmpeg-devel
Marth32 has joined #ffmpeg-devel
<Marth32>
ugh...sorry for the join/part spam....connection is bad
<BtbN>
I just manually submitted a mingw64 built to coverity
<mkver>
There are also a few more occurences if this.
<kierank>
mkver: ok that's a shame, apparently some real world compilers still need it
<mkver>
Maybe they will be unsupported if we have C11.
<kierank>
mkver: have we decided if we want "mmxext"
<kierank>
ssse3 came out in 2006
<kierank>
for something like ff_pred16x16_horizontal_8
<mkver>
The thing I dislike about our mmx(ext) code is that it does not abide by the ABI (and therefore requires emms_c) and not that it is old.
<mkver>
Would SSSE3 be faster? Would codesize increase?
<kierank>
there is already ssse3 in ff_pred16x16_horizontal_8 for example
<Traneptora>
does MMX do anything that SSE2 doesn't do?
<jamrial>
have shorter encoded instructions, i think
<kierank>
sse2 would need to emulate pshufb mainly
<mkver>
When I nuked old mmx code, my baseline was SSE2, because every x64 has that. I am not against raising the baseline and removing every MMX function that is superseded by say SSSE3.
<Traneptora>
ye x86_64 includes SSE2 by spec. tho i686 doesn't always
<jamrial>
kierank: also pmulhrsw and pmaddubsw
<kierank>
I didn't realise we do pshufw with mmx registers
<kierank>
wild
<Gramner>
mmx pshufw is the same as sse2 pshuflw
<Gramner>
and yes, the goal should be to get rid of all mmx code to avoid the whole emms mess
<haasn>
apparently trac has notifications off by default
<haasn>
no wonder I was missing being cc'd on issues
<haasn>
that really ought to be changed
<mkver>
Gramner: That could also be achieved by adding emms to the mmx functions.
<kierank>
Gramner: I would like to do it for h264 at least
<mkver>
Of course, some functions might then no longer worth it.
<Gramner>
that would be very slow
<kierank>
maybe not for swscale and others
<Gramner>
note that on modern intel cpus you get better performance by using sse2 over mmx, even if you only care about the lower 64 bits
<Gramner>
as many mmx instructions can't execute on all ports, and there's no register move elimination for mmx regs
<Lynne>
what about the async nature of x87? are those instructions noops?
Krowl has quit [Read error: Connection reset by peer]
<kierank>
I don't understand where pred16x16_horizontal_8_mmxext comes from
<kierank>
it's not in the code
<mkver>
kierank: h264_intrapred.o
<kierank>
ah it's a macro
<kierank>
but I dunno how checkasm runs code that doesn't exist
<mkver>
All you need to do is grep the output of nm -s libavcodec/libavcodec.a.
<kierank>
seems checkasm is not rebuilt automatically
<kierank>
when you edit code
<mkver>
Sure? I thought it is. It has a dependency on libavcodec.a and this has a dependency on all the files included in it.
<jamrial>
kierank: that function is trivial to turn into sse2
<jamrial>
no need to remove it
<kierank>
there is already ssse3 code
<mkver>
kierank: There are more h264_intrapred mmx functions overwritten by ssse3 versions.
<kierank>
that was my question, do we care about sse2 only cpus
<kierank>
or is ssse3 enough
<jamrial>
baseline is sse2, so if it can be done, it should be done
<jamrial>
if it's too much work, then no
<mkver>
How old would a cpu need to be not have ssse3?
<Gramner>
for h264 decode? probably yes unfortunately
<kierank>
sse2 is from 2003
<kierank>
ssse3 is from 2006
<Gramner>
ssse3 was added for intel in 2006, maybe 2 years later on amd
<jamrial>
amd didn't add ssse3 until bulldozer
<jamrial>
in like 2011 i think?
<kierank>
jamrial: no opinion either way, just want to start a discussion so we have an answer