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 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 265 seconds]
thilo has joined #ffmpeg-devel
<fflogger> [newticket] 0x20z: Ticket #11393 ([avcodec] SEGV on libavcodec/jpeg2000dec.c:1491:59) created https://trac.ffmpeg.org/ticket/11393
cone-456 has quit [Quit: transmission timeout]
mkver has quit [Ping timeout: 264 seconds]
bcoudurier has quit [Quit: Client closed]
jamrial has quit []
^Neo has quit [Ping timeout: 272 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 276 seconds]
<fflogger> [editedticket] nikomo: Ticket #11390 ([ffmpeg] av1_nvenc output frames sometimes cannot be decoded) updated https://trac.ffmpeg.org/ticket/11390#comment:1
kekePower has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 265 seconds]
wyatt8740 has joined #ffmpeg-devel
cone-755 has joined #ffmpeg-devel
<cone-755> ffmpeg Joe Schiffler master:0457aaf0d3a0: configure: Include quotes around pkg_version
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 246 seconds]
zenmov has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
cone-755 has quit [Quit: transmission timeout]
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
rossy has quit [Remote host closed the connection]
rossy has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 265 seconds]
___nick___ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 244 seconds]
ngaullier has quit [Remote host closed the connection]
ccawley2011 has joined #ffmpeg-devel
CounterPillow has joined #ffmpeg-devel
<JEEB> unfortunately it seems like it's not only youtube, there's at least two other services needing such stuff
<CounterPillow> it me
<kasper93> nice, thank you, lots of users will be happy about this
psilokos_ is now known as psilokos
zenmov has quit [Ping timeout: 252 seconds]
zenmov has joined #ffmpeg-devel
<fflogger> [editedticket] Balling: Ticket #3643 ([swscale] XYZ to RGB color space) updated https://trac.ffmpeg.org/ticket/3643#comment:7
cone-117 has joined #ffmpeg-devel
<cone-117> ffmpeg James Almer master:dd5696c19713: avfilter/buffersrc: make channel_layout a CHLAYOUT type AVOption
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #ffmpeg-devel
<fflogger> [newticket] mmis1000: Ticket #11394 ([undetermined] ffmpeg ignores -seekable 0 when requesting hls key) created https://trac.ffmpeg.org/ticket/11394
<fflogger> [editedticket] frankplow: Ticket #11367 ([undetermined] Chroma artefacts on decoded VVC streams) updated https://trac.ffmpeg.org/ticket/11367#comment:4
<fflogger> [editedticket] frankplow: Ticket #11367 ([undetermined] Chroma artefacts on decoded VVC streams) updated https://trac.ffmpeg.org/ticket/11367#comment:6
secondcreek has quit [Quit: secondcreek]
secondcreek has joined #ffmpeg-devel
cone-117 has quit [Quit: transmission timeout]
<beastd> wbs: will you take care about jannau asm patches or was sth still open? AFAICT jannau has currently no git access. Giving jannau git access should also be fine if jannau wants it.
<wbs> beastd: afaik there was some discussion open still on one of them, maybe. He did use to have git access long ago, but perhaps he doesn't have it any longer - I was kinda waiting for him to follow up on it in any case
<beastd> wbs: i think the 3rd patch was basically OK'd by BBB . I understood it as a pointer to maybe architecturally improve the situation mid/long term
<beastd> waiting a bit more is fine as well. just don't want it to get postponed for too long as it was from a real world use case IIUC.
<BBB> basically, yes
zenmov has quit [Ping timeout: 252 seconds]
<jamrial> there's way too many emails from people showing up as "via ffmpeg-devel"
<frankplow> jamrial: Do mine?
<jamrial> no
<frankplow> jamrial: Thanks.
<frankplow> kierank and Lynne are the two people I've noticed.
<thresh> blame dmarc policies of their respective mail services; there isnt much mailman can do about it
<jannau> jamrial: mailing list has modify from due to DMARC and the mailing list modifying the message
<jamrial> oh well
* JEEB finally got enough things to done to book his FOSDEM flights
<jannau> beastd: I probably shouldn't have commit message. If I still have commit access I need to restore the ssh key from backup and remember the passphrase
<jannau> I think the discussion was settled though with the v2 non-asm patch
<beastd> jannau: yeah, if you want git access, i think we can find a way. just say so. if you do not want it, one of us can push your changes.
cone-199 has joined #ffmpeg-devel
<cone-199> ffmpeg James Almer release/7.1:be26ee23abb4: avcodec/libdav1d: clear the buffered Dav1dData on decoding failure
<cone-199> ffmpeg James Almer release/7.1:4f5769e05262: avformat/iamf_writer: ensure the stream groups are not empty
<cone-199> ffmpeg James Almer release/7.1:145a3a84550a: avfilter/buffersrc: check for valid sample rate
<jannau> beastd: I don't foresee (many) more patches. this was drive by submission because a firefox dev mentioned that as one of the top 3 crashes they see on arm64. please push them
<BBB> and they don't want to pad the buffer?
<BBB> similar issues might exist in other (current or future) codecs or optimizations written for them...
<BBB> since the native impl has padding
<BBB> jannau: ^
<jannau> BBB: no idea. I mentioned that as potential fix but since it's not documented as required I did not press it
<jannau> initially I thought it was required and was surprised that's not mentioned in the doc
<beastd> thresh: do you by chance have experience with mailman3 ? and mailman2 to mailman3 migration?
<BBB> michaelni: any opinions? should we doc the padding requirement? or fix users (simd) so no padding is required?
<BBB> anyone else cares to weigh in? :)
<wbs> BBB: if arm/vp9 is the only case where firefox are hitting an error, it sounds like this generally isn't something we do assume - but perhaps they don't use much else than vp9 from us, who knows?
<beastd> BBB: you are more into it! only one small comment: regarding fixing docs in hindsight, not sure how good this will propagate to all affected users.
<BBB> doesn't dav1d over-allocate and over-read also?
<BBB> it's a different api so maybe they *do* over-allocate there
<wbs> I would expect this to be documented and clear wrt dav1d yes, I don't remember the specifics
<BBB> Number of bytes to align AND pad picture memory buffers by
<BBB> " so that SIMD implementations can over-read by a few bytes"
<BBB> so yeah... my preferred long-term fix would be to use that
<BBB> tricky :)
ccawley2011 has quit [Read error: Connection reset by peer]
ccawley2011 has joined #ffmpeg-devel
<thresh> beastd, no first-hand one; mm3 mostly works, although is quite a bit different to mm2; good news is that you can still use pipermail (archives) with mm3 if one dislikes web forums looks
<beastd> thresh: ok, thx for the info. sounds nice that it's possible to still use pipermail archives (not that they are particularly good, but i fear the alternatives are worse).
<thresh> exactly
<beastd> thresh: from what i have read mm3 look a bit over complex and over engineered to me. and from all i have read there is no out-of-the-box migration. you need to check a lot of details of your existing MLs.
<beastd> BBB: You take over completing/pushing the vp9 patches from jannau?
<BBB> beastd: I admire your approach to getting things done :)
<BBB> beastd: I think short-term you can just push what we have
<BBB> it might not be what we have 10 years from now but it gets the job done
ngaullier has joined #ffmpeg-devel
<michaelni> BBB, about padding, if theres no api from which we somewhere get buffers that cannot overalloc. i think padding makes sense
<BBB> wdym?
<BBB> "api from which we get buffers that cannot overalloc"
<michaelni> writing into a AVFrame that uses a buffer from some API of something wierd
<michaelni> not just writing
<michaelni> but this is probably not a real issue
<BBB> we can always memcpy from a padded AVFrame :]
* BBB runs
<jamrial> the doxy for AVFrame->data[] already says "keep in mind decoders may overread"
<BBB> get_buffer does not, though
<BBB> does the doxy for data[] say how much to over-allocate by?
<jamrial> no, it's outdated and still assumes AVX is not a thing
<BBB> gotta admit, avx was only proposed recently in 2008
<BBB> are we all onboard the c99 train nowadays?
<jamrial> AVX should be able to legally drink soon
<jamrial> BBB: we're c11 in fact! c17 enabled if present, too
<BBB> jannau: would you be willing to CC me on the firefox crash so I can try emailing the affected people? I knew one of the firefox media people but I think he left, as did the xiph folks
<michaelni> lol <jamrial> AVX should be able to legally drink soon
<BBB> depends on where you live, in the US you're still a couple of years off
<beastd> BBB: this is the bug linked in janne's commit message: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185 if that helps
<jannau> I stopped reading after "see avcodec_align_dimensions2()" in the AVFrame.data docs because the resolution in question is well aligned to page boundaries
<jannau> BBB: not much was discussed beyond linked ticket
<jannau> I think this needs to be documented in .get_buffer2 and not in AVFrame
<jamrial> avcodec_align_dimensions2() is documented in get_buffer2
<beastd> jannau: do you have [v2 3/3] around. somehow i can't find it in my mails nor in the list archives. or did i misunderstand that you did v2 and attempted to send it on the list?
<BBB> <jannau> I think this needs to be documented in .get_buffer2 and not in AVFrame << I agree
<beastd> sorry to interrupt. thank you all for getting the discussion going. need to leave for today if the discussion ends in pushing the short term patches, i will pick it up earliest this weekend
<BBB> tnx for poking us and keeping it going
<jannau> jamrial: avcodec_align_dimensions2() doesn't do anything for 1280x640 videos
<jannau> beastd: I'll push my branch to github
___nick___ has quit [Ping timeout: 252 seconds]
ngaullier has quit [Remote host closed the connection]
<BBB> jamrial: I think the problem is not so much alignment (for size or linesize), but rather that we intentionally overread at the end of any buffer anyway, at least in arm64's vp9mc simd
<jamrial> jannau: it can be updated to align dimensions in vp9's case. it does for h264 because of edge emulation
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
<BBB> I guess my point is that whatever the default get_buffer implementation does, should be documented as the expected behaviour in user-provided callbacks
<jannau> we removed over-aligning in align_dimensions in favour of edge emulation (edge emu was optional a long time ago)
<BBB> if we pad more than the api recommends, we will silently allow crashes like this to accumulate because "we can't reproduce"
<Lynne> jamrial: does the email I just sent also show up as "via..."?
<BBB> Lynne: yes
<jamrial> yeah
<Lynne> sad
<Lynne> I redid my mailserver's config and enabled dkim and arc sealing
<Lynne> before, I had absolutely nothing, not even spf
<Lynne> so I'm now pretty sure its like BtbN said, there's a list where well behaving servers are manually flagged in the ML to show up as via
<BtbN> no, there's a list of known bad ones
<Lynne> bad ones as in those that respect DMARC/DKIM and so on, or bad ones such as spam?
<BtbN> "bad" as in "there were enough bounces to the list from that server for DKIM/SPK/DMARC stuff that the list auto-unsubscribed people"
<Lynne> ah
<Lynne> well, no idea why it does that for my mails, like I said, I was running in the 90's with no modern security features except optional tls and ehlo, and now I do spf/dkim/dmarc/mta-sts/dane
<thresh> mailman has to rewrite the From: so your mails can be delivered
<BtbN> your server is actually not in there, so I'm honestly not sure
<BtbN> let me cross-check if it somehow matches one of the other regexps?!
<Lynne> the mails I get from the list have arc sealing, which should enable the list to insert its own header and modify my mail
<BtbN> There could just be two mechanisms at play, one in mailman, and one we do manually in postfix to deal with especially stubborn servers
<BtbN> The list is mailman2, so any such modern features are just not there
<Lynne> oh, I'm not familiar with how arc sealing works, maybe my mailserver signs incoming mail if unsigned and sends out arc signed content
<BtbN> The list would need upgraded desperately, but so far I didn't dare touch that
<Lynne> arc sealing dates back from 2019, so almost 6 years old now, its a new standard as far as mail goes, but almost 6 years nevertheless
<Lynne> did we not do any ML updates since then?
<BtbN> almost, server is Ubuntu 20.04, and I think that already was just a "just keep stuff running" OS upgrade
<BtbN> mailman 3 initially came out in 2015
<BtbN> From the looks of it, what mailman right now looks at is the SPF and DMARC policies for the domain. If it's set to reject or even quarantine, it will mangle the sender.
<Lynne> changed to none, will try again in a few hours once dns records catch up
ngaullier has quit [Remote host closed the connection]
iive has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
cone-199 has quit [Quit: transmission timeout]
HarshK23 has quit [Quit: Connection closed for inactivity]
<Lynne> dns records got updated, is it still "via..."?
<jamrial> Lynne: works now
<Lynne> yay
<BBB> beastd: jannau: I've sent an email with the current implementation of the default get_buffer callback as doxy update for get_buffer in avcodec.h. LMK what you think
<BBB> s/email/patch/
<BBB> I can provide additional reference if you want. the relevant code is https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/get_buffer.c;h=b391adf24f45723ef994b133513a7b49b2fa3981;hb=HEAD#l122 AFAICS
ccawley2011 has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
some02 is now known as sudden
michaelni has quit [Ping timeout: 276 seconds]
<BBB> jamrial: tnx for review, probably good to get a discussion started on this
<kierank> BBB: wow, I remember this issue like 10+ years ago :)
<kierank> glad you are resolving it
cone-932 has joined #ffmpeg-devel
<cone-932> ffmpeg Manuel Lauss master:b22ce90d4228: avcodec/sanm: SMUSH codec48 decoder
<BBB> thank jannau :)
<BBB> Lynne: same for you, tnx for review. I think the expected behaviour is poorly documented/understood, given even you two didn't know where I got the 15 from :)
<BBB> (it's not avcodec_align_dimensions2)
<Lynne> I thought its from wrapped avframes, which are contained in packets, which require 15 or so bytes of padding for the bitstream reader to overread?
michaelni has joined #ffmpeg-devel
<jamrial> BBB: i know it's from the default implementation of get_buffer
<jamrial> where it does stride_align + 16 - 1
<jamrial> my point is, that's something said implementation does but it's not documented as required. what is documented is the usage of avcodec_align_dimensions2()
<jamrial> if you don't use it, you'll most likely find crashes in a lot of scenarios even with those 15 + stride_align bytes
<jamrial> i'm not against adding the max_cpu_align padding requirement to get_buffer2(), but that's technically an api break as it was not strictly needed until now
<jamrial> wouldn't something like http://pastie.org/p/2WHyPkLYF0X4WcYv0dUqJ8 solve this? (not suggesting to use this in place of the aarch64 asm fixes)
<jannau> avcodec_align_dimensions2() is a bad fit for this since we don't want/need to add additional lines or increase the line size
<Lynne> its fine, a few lines and bytes won't OOM someone
witchymary has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]