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
Anthony_ZO has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 252 seconds]
minimal has quit [Quit: Leaving]
Mattcurts has joined #ffmpeg-devel
Mattcurts has quit [Client Quit]
cone-091 has joined #ffmpeg-devel
<cone-091> ffmpeg Jack Lau master:167e343bbe75: avformat/whip: Add WHIP muxer support for subsecond latency streaming
<compn> whip it good
jamrial has quit []
<mkver> Did someone even review this? It adds both a new protocol and a muxer in the same commit.
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
halloy5771 has joined #ffmpeg-devel
halloy5771 has quit [Read error: Connection reset by peer]
mkver has quit [Ping timeout: 248 seconds]
kode546 has joined #ffmpeg-devel
kepstin has quit [Ping timeout: 272 seconds]
kepstin has joined #ffmpeg-devel
kode54 has quit [Ping timeout: 272 seconds]
kode546 is now known as kode54
HarshK23 has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 245 seconds]
halloy5771 has joined #ffmpeg-devel
halloy5771 has quit [Read error: Connection reset by peer]
cone-091 has quit [Quit: transmission timeout]
<Lynne> softworkz-at-hotmail.com@ffmpeg.org?
<Lynne> is this some redirection feature the mailing list has?
<kode54> presumably to counter security bs barfing if a "softworkz@hotmail.com" mail comes from not-hotmail
<jannau> I assume it's necessary since the mailing list rewrites the mail body
<kode54> though I usually see it as moving the address to a reply-to: header and changing the actual from to something generic
<kode54> that particular user is getting on my nerves
<kode54> and I haven't even been interacting with them directly, just reading along the list
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 265 seconds]
microchip_ has joined #ffmpeg-devel
rvalue- is now known as rvalue
<fflogger> [editedticket] BlueWindy: Ticket #9996 ([ffmpeg] Write joc_complexity_index to dec3 (EAC3SpecificBox), Windows and Android need it to play atmos) updated https://trac.ffmpeg.org/ticket/9996#comment:16
Thulinma has quit [Ping timeout: 272 seconds]
System_Error has quit [Ping timeout: 264 seconds]
Everything has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<ramiro> I unsubscribed from the ml. it has become more energy draining than I can handle at the moment.
<ramiro> I'll refocus my work on swscale with haasn, which is actually fun and rewarding :)
<beastd> ramiro: ml :( good to know you are still working on sws :)
<JEEB> yea the stuff him and haasn have been hacking on is <3
TheVibeCoder has joined #ffmpeg-devel
<TheVibeCoder> Lynne: fixed/improved balance/joint A-SPX mode, was not copying some channel data to another channel
<kierank> 04:41:36 <mkver> Did someone even review this? It adds both a new protocol and a muxer in the same commit.
<kierank> No was not reviewed
<TheVibeCoder> Lynne: now, big thing rest to do is to improve A-SPX resolution (but how) and finish A-CPL (another convoluted mess)
<TheVibeCoder> kierank: even 2-14 days period of notice to push was not given ;-)
<kierank> It's normal in this project now
<kierank> People push what they want
<kierank> It's ffmpeg circa 2009
<kierank> Back to the future
<TheVibeCoder> but  whip is actual killer feature
<kierank> Lol
Thulinma has joined #ffmpeg-devel
<TheVibeCoder> for subtitle avframe changes,  cant those extra struct items that have been introduced be just put into ->data[X] ?
<TheVibeCoder> otherwise it looks data[X] is left unused
TheVibeCoder has quit [*.net *.split]
System_Error has quit [*.net *.split]
microlappy has joined #ffmpeg-devel
microlappy has quit [Client Quit]
cone-048 has joined #ffmpeg-devel
<cone-048> ffmpeg Niklas Haas master:6ad95be306d1: avfilter/vf_blackdetect_vulkan: fix black region reporting
Anthony_ZO has quit [Ping timeout: 248 seconds]
<fflogger> [editedticket] Artim: Ticket #11363 ([avcodec] MediaCodec ceased working in new Android for JVM cause) updated https://trac.ffmpeg.org/ticket/11363#comment:14
secondcreek has quit [Remote host closed the connection]
secondcreek has joined #ffmpeg-devel
<haasn> ramiro: I love how easy it is to add metadata to the component tracker, solving for plane dependencies was literally just adding it to enum SwsCompFlags and merge_comp_flags(), as well as setting it on SWS_OP_READ
<haasn> the rest propagates correctly
<haasn> ramiro: maybe you can help me answer this question though: is it sufficient to always split off planes starting from the highest index?
<haasn> for example if we have a yuva444p write (planar elems=4), we can split this into two chains like (planar elems=3) + (planar elems=1) with relative ease
<haasn> but it would be much harder to split out an "isolated" plane from the middle
<haasn> e.g. if we have something like ya8 -> yuva444p
<haasn> in theory the UV planes here are independent and should be split off from the main chain, which then turns into a pseudomemcpy (packed->planar)
<haasn> hmm
<haasn> it's difficult to find a good place to keep track of what order the plane pointers should be in when splitting planes
omegatron has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<fflogger> [newticket] jozefchutka: Ticket #11624 ([undetermined] Using audio filters throws Assertion best_input >= 0 failed) created https://trac.ffmpeg.org/ticket/11624
<fflogger> [editedticket] nacioss: Ticket #11619 ([avcodec] "libopus" downmix (5.1 -> 2ch) unintended volume clipping) updated https://trac.ffmpeg.org/ticket/11619#comment:5
mkver has joined #ffmpeg-devel
<haasn> ramiro: nvm, I think I found a good solution that lets us split out arbitrary planes
<haasn> I will add a flag to ff_sws_graph_add_pass to let it reuse the output buffer from a previous path
<haasn> so that we can just add subsequent passes on top of the first pass, to write different subset of planes
<haasn> plus adding a plane swizzle order on the read/write pointer setup
<haasn> also, maybe we should disable threading for the memcpy backend
BradleyS has quit [Quit: quit]
BradleyS has joined #ffmpeg-devel
stevenliu has joined #ffmpeg-devel
stevenliu has quit [Remote host closed the connection]
stevenliu has joined #ffmpeg-devel
<ramiro> haasn: maybe semiplanar formats might add a few extra conditions. so you'd have to check y and alpha normally, but then uv separately. but I haven't thought too much about it yet.
<haasn> I think the correct condition is to split off minimal group, where a minimal group is a subset of output planes that depend on a subset of input planes; we can use a greedy algorithm to find them
<haasn> that depend exclusively *
<ramiro> and why should we disable threading for the memcpy backend?
<haasn> Okay, I pretty much solved this problem now in my head
stevenliu has quit [Ping timeout: 268 seconds]
<haasn> If we’re bottlenecked by the memory copy speed won’t adding threads just potentially alow things down?
<haasn> I haven’t benchmarked it though
<ramiro> good point. but we will be working with one memory region at a time, even when multithreading.
<ramiro> I don't think this will be an issue with x86 though, since it can access much more different memory regions simultaneously than my aarch64 sbcs.
stevenliu has joined #ffmpeg-devel
stevenliu has quit [Ping timeout: 260 seconds]
stevenliu has joined #ffmpeg-devel
stevenliu has quit [Client Quit]
System_Error has joined #ffmpeg-devel
cone-048 has quit [Quit: transmission timeout]
TheVibeCoder has joined #ffmpeg-devel
<TheVibeCoder> this AC-4 is pure madness, bug in A-SPX can be almost anywhere...
cone-015 has joined #ffmpeg-devel
<cone-015> ffmpeg Andreas Rheinhardt master:7927ac63ef0f: avcodec/Makefile: Only compile hashtable.o when needed
<cone-015> ffmpeg Andreas Rheinhardt master:12a43975d1f4: avcodec/hashtable: Combine allocations
<cone-015> ffmpeg Andreas Rheinhardt master:140fc655f7ea: tests/fate/libavcodec: Run hashtable test
<cone-015> ffmpeg Andreas Rheinhardt master:2fc310b2f25f: avcodec/hashtable: Zero-initialize hashtable
<cone-015> ffmpeg Andreas Rheinhardt master:1e6fdafce07a: avcodec/hashtable: Only align complete entries
<cone-015> ffmpeg Andreas Rheinhardt master:06958c731e86: avcodec/hashtable: Mark alloc,free functions as av_cold
<cone-015> ffmpeg Andreas Rheinhardt master:2e45d2f7d38a: avcodec/hashtable: Check for overflow
<cone-015> ffmpeg Andreas Rheinhardt master:a2c3d9947858: avcodec/hashtable: Only free buffer if there is buffer to free
<cone-015> ffmpeg Andreas Rheinhardt master:3be9b3f156c7: avcodec/hashtable: Remove null statement
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
TheVibeCoder has quit [Quit: Client closed]
TheVibeCoder has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
TheVibeCoder has quit [Quit: Client closed]
TheVibeCoder has joined #ffmpeg-devel
<toots5446> mkver: Did you see my response to your email? Do you have any advice on how to store _two_ consequent header packets in a single contiguous memory chunk? W/o a struct I was thinking I'd just store everything in a platform-independent bitstream using the same layout (header type/length/data).
<mkver> Why don't you just use the already established layout for the extradata?
TheVibeCoder has quit [Quit: Client closed]
TheVibeCoder has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<toots5446> mkver: can you point me to an example?
<mkver> For what?
<toots5446> an established extradata layout
<TheVibeCoder> extradata content should not have C pointers
<toots5446> That's not what I'm talking about
<toots5446> Let me push some code I guess
<mkver> There are two variants of extradata for vorbis in use by FFmpeg: The Matroska way, which has three BE uint16_t containing the lengths of the three subarrays followed by these subarrays; and the xiph array, where the size field is 0xFF ... 0xFF 0xAB (with 0xAB != 0xFF); actual is number of 0xFF * 255 + 0xAB (0xAB is allowed to be zero).
<mkver> See lavc/xiph.c
<mkver> Given that you are emitting extradata from ogg, you should probably use the (more complicated) xiph version.
<mkver> Also the new extradata should be complete (all three arrays), not only the ones that have been updated (so that it can be used on its own).
<toots5446> That will work beautifully, thanks.
<toots5446> mkver: it's understood the packing function needs to be written right?
<toots5446> Oh I see it's inlined in lavc/vorbisenc.c:put_main_header
<mkver> You can't use that: It's in lavc and you also do not need to parse to get all the data; you can just copy bytes (not bits) around.
<toots5446> agreed
<toots5446> but the generic packing layout can be re-used. What to you mean it's in lavc? lavf code does call code from lavc right?
<mkver> If at all, you could reuse the header writing code from the muxer, but it does not seem reusable to me (unsurprising given that it does a different task).
<mkver> lavf and lavc are different libraries; you can not call the lavc internal functions in lavf.
<toots5446> yes yes of course but public ones yes
<toots5446> ok I think I have enough to do it now thanks
<compn> do we really need a configure check for a 2 year outdated openssl ? i cant imagine supporting a discontinued version like that.
<compn> with other libs, codec libs , compilers sure. but an internet security lib?
<devinheitmueller> There are plenty of people out there who are building on an OS that is older than two years.
<TheVibeCoder> just make lib is patched from security bugs
<compn> TheVibeCoder, openssl stopped patching 1.1.1
<devinheitmueller> Heck, I have cases where I still build against Centos 7. The security isn’t an issue because I only run on internal networks and never as a server.
<mkver> Dropping support for everything < 0x10100000L would allow to clean up tls_openssl.c.
<TheVibeCoder> patch welcome
<compn> master builds on centos 7?
<devinheitmueller> Sure, if you have devtoolset-9- installed.
<compn> well
<JEEB> yea, if someone needs to build against an old OS and its ancient glibc then either installing or building themselves a new enough toolchain and development tools is an expectation
<compn> yes ffmpeg dropped some old windows version support a while back
<compn> ffmpeg moves forwards, old os get dropped
<devinheitmueller> Nobody says that we should have to support everything forever, but for a project as popular as ffmpeg you can’t assume everybody is running the very latest operating systems.
<JEEB> yeh, I also deal with some old things. it just starts getting more and more annoying, and generally not due to FFmpeg
<compn> detecting old openssl and disabling the feature is useful though
<compn> in a configure check
<fflogger> [newticket] gamer191: Ticket #11625 ([undetermined] FFmpeg is unable to output .iamf files) created https://trac.ffmpeg.org/ticket/11625
<compn> devinheitmueller, those who want extra support on older systems can pay money to have devs support them as well. which is what openssl did for 1.1.1 , annual $50k support
<TheVibeCoder> $50k ?
* compn looks at michaelni doing releases for ffmpeg 4
<devinheitmueller> It’s all about where you draw the line, and how many people are effected. Two years feels too short, but ten years feels too long. Where that line is drawn is largely dependent on the project and the developers.
<compn> michaelni, should start charging for making new releases :D
<compn> TheVibeCoder, pay $50,000 , get custom openssl 1.1.1 updates
<devinheitmueller> I suspect you could easily argue to STF that release creation and backporting patches to stables releases could qualify as the sort of maintenance funds could be used for.
<devinheitmueller> (i.e. Perhaps michaelni should be paid some STF money for such work)
<TheVibeCoder> just give blank check to him for filling out numbers?
<compn> devinheitmueller, there are a lot of people who have been disagreeing with allocating any funds from our donations to any developers for any ideas
<compn> mainly from people who havent been contributing lately
<devinheitmueller> compn: I agree that any such allocation of funds should be the result of discussions and ultimately consensus, but I also feel like release management if probably something everybody could agree would be a good use of funds.
<devinheitmueller> TheVibeCoder: If you think release managment is just “filling out numbers”, I welcome you to volunteer to take it over. I think you’ll quickly find it isn’t so easy.
<TheVibeCoder> speaking of donations, i get 0$ for AC-4
<devinheitmueller> That’s a double edge sword. As soon as somebody gives you money, Dolby will have a better reason to sue you (i.e. commercial gain).
<devinheitmueller> :-)
<compn> the same people have been arguing over patches , features and suggestions non stop. i wonder if its some coordinated plan in an attempt to freeze all work on ffmpeg. an open source DDoS
<TheVibeCoder> speaking of funds, is morally right to give someone money to add some code from another project that got 0$ donations
<BBB> compn: but who would benefit from that?
<compn> TheVibeCoder, do you have a donation link? if not , your argument is invalid
<compn> BBB, people who would be attempting a takeover long term by annoying the current developers
<TheVibeCoder> compn: irrelevant and invalid
<compn> TheVibeCoder, heck you could put forward a stf request for your work, no one is stopping you
<wbs> compn: sorry to derail your aspirations here, but requesting a configure check for an openssl version that is not all that old shouldn't require funding discussions IMO
<wbs> there is literally nothing controversial about that
<compn> i agreed to the configure check
<wbs> many things are controversial, this isn't
<TheVibeCoder> compn: stf aproves ffmpeg because of its fame not merrit
<wbs> so can I get back to focusing on purely technical things without being derailed, thank you
<compn> pointing out an outdated library is a purely technical thing
<compn> i have not dragged you into anything else
<compn> discontinued library
<compn> vesion
<compn> version*
<TheVibeCoder> does abandoned openssl version have active security fatal flaws when used by current ffmpeg?
<wbs> pointing out that it should require a commercial contract to get support for such things does feel like derailing, but whatever
<compn> i was just discussing the article , unrelated
<compn> anyway have a good day wbs.
<wbs> thanks, same to you
<courmisch> waiiit, NG attended a VDD?
<TheVibeCoder> 2024th?
<compn> pretty sure i met him years ago at vdd
<courmisch> TheVibeCoder: don't think so
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
<kurosu> I did meet him at one
<kurosu> I think it was the one held at the proxad HQ
<mkver> toots5446: Why do you use two bits for the header sizes? This is not the ordinary format. Does this even work?
<toots5446> Whoops. My bad. Weird this was working. Updated ci: https://github.com/toots/FFmpeg/commit/a74dbbb65e99e8dd4951222276f46f50eb1f314f
<mkver> Why is there a PutBitContext although everything is byte-aligned?
<toots5446> I'm gonna do more testing but it is the approach you recommend?
<toots5446> mkver: what should be the correct API to pack the data then? You have an example?
<TheVibeCoder> 2024th VDD videos/presentations still not available?
<mkver> Just use memcpy and ordinary writes? Or use the bytestream API?
<kierank> TheVibeCoder: there was no recording
<kierank> courmisch: I think a few VDDs
<toots5446> mkver: and manually deal with endianess for the length bytes?
<mkver> We have intreadwrite for that; but actually I expected you to create the extradata in xiph format, not Matroska.
<mkver> This is the ogg demuxer after all.
<toots5446> ok got it
<TheVibeCoder> kierank: but I heard that it just need post-production and upload
<kierank> Potentially some of the talks
<kierank> I think day 2 maybe was not recorded
<kierank> you need to ask the vultures
<TheVibeCoder> yea, too close geographically to russia and china and north korea, gives bad examples how to behave
<fflogger> [editedticket] jamrial: Ticket #11625 ([undetermined] FFmpeg is unable to output .iamf files) updated https://trac.ffmpeg.org/ticket/11625#comment:1
<mkver> jamrial: libavformat/mov.c:1295:14: runtime error: -256 is outside the range of representable values of type 'unsigned long'
<mkver> This happens when parsing a clap box in heif-conformance/MIAF007.heic.
cone-015 has quit [Quit: transmission timeout]
<mkver> This clap box is currently considered invalid, but even then it should not lead to UB. Is it invalid though?
<jamrial> mkver: it is for the second stream (thumbnail)
<jamrial> for whatever reason, the same clap box references both streams, and it obviously doesn't apply to the smaller stream
<toots5446> mkver: I just confused metadata and extradata again. I'm kinda dyslexic with these, sorry. Also, byte order is BE.
<mkver> Then send it to ML.
<toots5446> Will do. looks good to you? Trying to make sure it's the right approach before sending.
<mkver> I didn't look.
<toots5446> There's one weird thing. The extradata needs 6 bytes of padding, is that expected?
<toots5446> new_extradata_size = priv->header_size + priv->comment_size + priv->setup_size + 6;
<toots5446> Otherwise the unpacking function fails
IndecisiveTurtle has quit [Ping timeout: 276 seconds]
<toots5446> ha wait my bad haha
<toots5446> 2 per length :-)
<toots5446> cool sending
cone-766 has joined #ffmpeg-devel
<cone-766> ffmpeg Emma Worley master:a4c1a5b08409: lavc/dxvenc: fix big-endian issues in dxv_compress_dxt1
<fflogger> [editedticket] gamer191: Ticket #11625 ([undetermined] FFmpeg is unable to output .iamf files) updated https://trac.ffmpeg.org/ticket/11625#comment:2
<fflogger> [newticket] gamer191: Ticket #11626 ([ffmpeg] Feature request: -ignore-unrecognized-option) created https://trac.ffmpeg.org/ticket/11626
secondcreek has quit [Remote host closed the connection]
secondcreek has joined #ffmpeg-devel
TheVibeCoder has quit [Quit: Client closed]
MisterMinister has joined #ffmpeg-devel
<thardin> oh boy license issues
jannau has quit [Quit: WeeChat 4.5.1]
jannau has joined #ffmpeg-devel
jannau has quit [Client Quit]
jannau has joined #ffmpeg-devel
<Traneptora> ramiro: there's a regression caused by your posix ioctl patch
<Traneptora> with --enable-libv4l2
<Traneptora> problem is, /usr/include/libv4l2.h has its posix ioctl guarded by #ifdef rather than #if. in a public header, yes
<Traneptora> so when we do #define HAVE_POSIX_IOCTL 0, it triggers it for the header anywya
jannau has quit [Quit: WeeChat 4.6.3]
<Traneptora> I'm sending a patch to linux-tv to see if they can fix it
<devinheitmueller> Traneptora: it’s probably been that way for at least fifteen years. Even if they accept it, you’ll still have to work with currently shipping kernels.
<Traneptora> devinheitmueller: I checked and it was introduced in the last version
<Traneptora> in September 2024
<devinheitmueller> Oh, really? Well never mind then.
<Traneptora> also this is v4l-utils userspace library
<Traneptora> so fortunately it's not kernel-dependent
<devinheitmueller> Yeah, but the libv4l2 stuff oten tracks the kernel version.
<devinheitmueller> Still, it’s a good idea to submit a patch.
<compn> BBB, could also just be pure spite
<compn> BBB, or i'm wrong and its honest disagreements and opinions
<BBB> seems a bit far-fetched if you're looking for my opinion
<BBB> these people that you're accusing use ffmpeg in their daily life for work and more. They need ffmpeg. I agree their motives might not be 100% in agreement with where others are standing, but I don't think anyone is that crazy either
jannau has joined #ffmpeg-devel
<compn> which is why i'm confused that a lot of new features and funding is being blocked by honest opinions of people who use ffmpeg that much
compn has quit [Read error: Connection reset by peer]
compn has joined #ffmpeg-devel
<compn> hit the wrong button
<devinheitmueller> AFAICT, most of the funding objections have been over stuff that doesn’t fall under maintenance, which is what the STF funding is intended for. New features don’t fall into that category. You could also argue that the people who use it for work may both simply not care about the proposed feature, as well as would rather see it used for maintenance that they will actually benefit from.
<devinheitmueller> … IMHO.
<compn> "Maintaining the sustainability, security, and innovation of a leading multimedia processing framework "
<compn> "How do these activities contribute to the overall security, enhancement, maintenance or sustainability of the technology?"
<devinheitmueller> Yeah, I think the debate/discussion lies in how those monies are applied, in terms of proportion for “sustainability”, “security” and “innovation”.
<compn> fair enough
IndecisiveTurtle has joined #ffmpeg-devel
putacho has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 252 seconds]
cone-766 has quit [Quit: transmission timeout]
snoriman has joined #ffmpeg-devel
<snoriman> hi, I'm trying to create an app that demuxes/decodes a rtsp stream however the decoded images look like this: https://imgur.com/a/DQ2kaEq
<snoriman> when I load a .mp4 file with the same code the image looks fine
<snoriman> so I'm trying to figure out if I'm missing when reading a rtsp stream?
<snoriman> in the logs I see "No start code found" and "no frame!" which is triggered here: https://github.com/FFmpeg/FFmpeg/blob/release/7.1/libavcodec/h264dec.c#L1080 but I don't know the code good enough to use that to figure out what the issue is. Someone around who can help a bit?
mkver has quit [Ping timeout: 276 seconds]
<snoriman> I've just set the log level to trace and noticed this: parser not found for codec h264, packets or times may be invalid. How do I enable the h264 parser for the h264 codec?
<jamrial> snoriman: --enable-parser=h264, but this and your previous question are for #ffmpeg, not here
Everything has quit [Quit: leaving]
<snoriman> Ah thanks jamrial I did asked there first but wasn't sure, but I'll go back to #ffmpeg, thanks.
putacho has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
<kierank> Oh god ffmpeg on HN
<another|> whip?
<another|> ah, yes. it's whip
<tmatth> kierank: and phoronix
IndecisiveTurtle has quit [Read error: Connection reset by peer]
IndecisiveTurtle has joined #ffmpeg-devel
<pross> slow news day?
mkver has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 260 seconds]