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
<Marth64> i always thoughtg about that as potential improvement
Marth64 has quit [Quit: Leaving]
s55 has quit [Ping timeout: 256 seconds]
rvalue has quit [Ping timeout: 252 seconds]
<Traneptora> how would you use AVOption for that? lol
<Traneptora> I feel like repurposing a struct for something it was not intended to be used for is asking for issues
<Traneptora> I almost feel like serializing as CBOR is better
rvalue has joined #ffmpeg-devel
qeed_ has joined #ffmpeg-devel
qeed has quit [Read error: Connection reset by peer]
chainik has quit [Read error: Connection reset by peer]
stazthebox has quit [Quit: Ping timeout (120 seconds)]
chainik1 has joined #ffmpeg-devel
stazthebox has joined #ffmpeg-devel
s55 has joined #ffmpeg-devel
haihao_ has quit [Ping timeout: 276 seconds]
haihao_ has joined #ffmpeg-devel
<Lynne> come to think of it I don't have a cbor writer for avtransport yet...
<Lynne> sure would like to pick one up, under a 2-clause bsd license...
Marth64 has joined #ffmpeg-devel
<Traneptora> well if you add one to FFmpeg it would be lgpl, like everything else
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
navi has quit [Quit: WeeChat 4.0.4]
MrZeus has quit [Ping timeout: 260 seconds]
Marth64 has quit [Remote host closed the connection]
MetaNova has quit [Ping timeout: 260 seconds]
Flat has quit [Ping timeout: 252 seconds]
Flat_ has joined #ffmpeg-devel
MetaNova has joined #ffmpeg-devel
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
durandal_1707 has quit [Ping timeout: 268 seconds]
durandal_1707 has joined #ffmpeg-devel
m__ has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
s55 has quit [Read error: Connection reset by peer]
m__ has quit [Quit: m__]
s55 has joined #ffmpeg-devel
jamrial has quit []
epony has quit [Remote host closed the connection]
epony has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 255 seconds]
Martchus has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
<Traneptora> where did https://ffmpeg.org/doxygen/5.1/ get moved to?
<Traneptora> if you replace 5.1 with 6.1 it 404s
m__ has joined #ffmpeg-devel
<Marth64> i know of trunk https://ffmpeg.org/doxygen/trunk/index.html not sure about 6.1
m__ has quit [Quit: m__]
Jaex has joined #ffmpeg-devel
thilo has quit [Ping timeout: 255 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
<Traneptora> > Generated on Tue Jan 30 2024
<Traneptora> probably git master
averne has quit [Quit: quit]
averne has joined #ffmpeg-devel
haihao_ has quit [Ping timeout: 252 seconds]
haihao_ has joined #ffmpeg-devel
epony has quit [Remote host closed the connection]
Jaex has quit [Quit: Connection closed for inactivity]
ocrete2 has quit [Quit: Ping timeout (120 seconds)]
ocrete2 has joined #ffmpeg-devel
haihao_ has quit [Ping timeout: 240 seconds]
haihao_ has joined #ffmpeg-devel
Marth64[m] has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
mark4o has joined #ffmpeg-devel
markh has quit [Ping timeout: 260 seconds]
mark4o is now known as markh
HarshK23 has joined #ffmpeg-devel
Sebastinas has quit [Quit: -]
Sebastinas has joined #ffmpeg-devel
<rodeo> https://ffmpeg.org/documentation.html API documentation available for 6.0 but not 6.1 yet, perhaps a manual process
mkver has joined #ffmpeg-devel
haihao_ has quit [Ping timeout: 264 seconds]
haihao_ has joined #ffmpeg-devel
lexano has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
odrling has quit [Remote host closed the connection]
odrling has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<elenril> >Move to Gitlab
<elenril> troll harder, live longer
<durandal_1707> ignore elenril
Krowl has joined #ffmpeg-devel
<durandal_1707> finally gives grant to SDR
jamrial has joined #ffmpeg-devel
<durandal_1707> fun
<durandal_1707> but without profit there
<durandal_1707> this project is doomed to fail
<kierank> elenril: join the club
<durandal_1707> so much hurt people
<elenril> durandal_1707: you should talk to duke abaddon about this
<elenril> I'm sure you'd find much in common
<elenril> kierank: gitea > gitlab
<elenril> and if it's supposed to be a serious project, it mainly needs a diplomat rather than a sysadmin
<kierank> I meant being ignored by Paul
<kierank> elenril: 50/50 on that
<elenril> nonsense, paul is my biggest fan
<kierank> We use gitea at work
<elenril> and what's wrong with it?
<elenril> also, BBB reportedly had tons of funding for moving to gitlab or similar
<elenril> so the problem is not funding
<elenril> the problem is someone being able to persuade people and organize and manage it without the community going critical
<kierank> True for all the projects imo
<kierank> In stf
<elenril> ossfuzz and coverity are not that controversial
<kierank> True, a lot of the coverity ones are false positives
<elenril> yes, that's something that also concerns me about that project
paulk has quit [Quit: WeeChat 3.0]
<Daemon404> is it a "project" if it is infinitely ongoing?
<elenril> it is, because it's limited to one year
<Daemon404> classic
<Daemon404> if i really wanted to troll i would propose a project to modernize our infra and bring it into gdpr conpliance
<Daemon404> compliance*
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
<elenril> do you volunteer?
kekePower has quit [Read error: Connection reset by peer]
<elenril> that seems to be the biggest practical problem here actually, so far that's only one person proposing to actually do any work
<Daemon404> in the past there were volunteers for infra
<Daemon404> vlc people
<Daemon404> but it was rejected
<Daemon404> for paraboia reasons
<nevcairiel> that nameless host noone knows is clearly better :)
kekePower has joined #ffmpeg-devel
<Daemon404> well yes cant replace infra without any access to cirrent j fra
mkver has quit [Ping timeout: 260 seconds]
mkver has joined #ffmpeg-devel
epony has joined #ffmpeg-devel
<haasn> is there a good way to "enable everything" when building ffmpeg?
<JEEB> I think that's the default, autodetect is on by default. then of course many external libraries are not under autodetect, so those will have to be enabled in any case.
<haasn> that's exactly what I find annoying, I have e.g. both harfbuzz and freetype installed but unless I specifically set --enable-libharfbuzz and --enable-libfreetype, e.g. vf_drawtext doesn't get built
Krowl has quit [Read error: Connection reset by peer]
<durandal_1707> elenril: i never sent spam mails to your inbox
dellas has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 268 seconds]
dellas has quit [Remote host closed the connection]
navi has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<elenril> jamrial: 98aea87b1a3a96b9d82deca09291aaec2f54399e
<jamrial> svn commit
Marth64[m] has quit [Ping timeout: 268 seconds]
cone-764 has joined #ffmpeg-devel
<cone-764> ffmpeg Lynne master:5860a966d2ff: lavfi/vsrc_testsrc_vulkan: fix -Wint-conversion
<Lynne> durandal_1707: thanks
Krowl has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
_whitelogger has joined #ffmpeg-devel
<durandal_1707> Lynne: ?
<Lynne> s/durandal_1707/elenril
<Lynne> it's an easy mistake to make
<elenril> so easy to confuse us
<elenril> one patch spammer like the other
<durandal_1707> that really hurts
<durandal_1707> Japan will no longer require floppy disks for submitting some official documents
<durandal_1707> Lynne: also what happened to your TX work?
<JEEB> durandal_1707: I think the faxing was even better
<JEEB> PC98 receivin' them faxes
<JEEB> <3
<durandal_1707> in my experience under multiple cases floppy data would get corrupt just because of various radiations outside (and that was decades ago, i imagine now would be even worse)
<JEEB> all that random magnetic stuff 8)
<durandal_1707> yea floppy is not propery shielded at all
<durandal_1707> ffmpeg lost all users?
<durandal_1707> the #ffmpeg irc logs are extremely silent lately
<elenril> maybe they all moved to #librempreg
<durandal_1707> you wish!
<jamrial> >mpreg
navi has quit [Quit: WeeChat 4.0.4]
<elenril> Motion PictuRe Experts Group
<elenril> duh
<durandal_1707> basically elenril single handely erased whole user-base
<elenril> >Explosions in Feodosia/Saki.
<elenril> maybe they were all from there
<durandal_1707> elenril: silence is already > 1 week
<durandal_1707> just look here: https://libera.irclog.whitequark.org/ffmpeg
<elenril> plot a graph of lines per day for 2023
<durandal_1707> sure
<durandal_1707> one moment
<jamrial> maybe people don't run into issues as often anymore
<durandal_1707> *doubt*
<kasper93> irc is really bad support channel though
<durandal_1707> discord is better!
<kasper93> you can discuss things, but if you need QA in comprehensive form only discussion boards like forum or stack overflow works
<kasper93> discord is just fancy irc, the same shit
<elenril> kasper93: QA in comprehensive form costs $$$
<nevcairiel> discord is slightly better as you can have more structure, but certainly not perfect
<jamrial> people will just spam stickers
<durandal_1707> you can always hire ffmpeg dev to come to your house in flesh.
<kasper93> nevcairiel: need moderators to enforce this structure
<kasper93> but there are tools indeed
<elenril> durandal_1707: can you come to my house in the flesh?
<elenril> I'll pay you 15 EUR
<durandal_1707> elenril: sure, send me address
<kasper93> I think they even added something mimicing forum threads now
<kasper93> elenril: 15 for every message?
<kasper93> I'm in
<elenril> for every visit
<durandal_1707> elenril: i will pay you to stop working on LibAV
<elenril> and offer valid for the real durandal_1707 only
<cone-764> ffmpeg Thomas Siedel master:aa3155e4c2b8: avformat/mp4: add muxer support for H266/VVC
<cone-764> ffmpeg Nuo Mi master:8559cce3c37b: avformat/mpegtsenc: refact mpegts_check_bitstream to loop up table
<cone-764> ffmpeg Nuo Mi master:d2c4f72016ba: avformat/mpegtsenc: refact, move h264, hevc startcode checking to check_h26x_startcode
<cone-764> ffmpeg Nuo Mi master:627dbc4e00d4: avformat/mpegtsenc: refact, remove h264, hevc magic numbers for nal_type
<cone-764> ffmpeg Nuo Mi master:11a57685cd4f: avformat/mpegtsenc: refact out h26x_prefix_aud
<cone-764> ffmpeg Thomas Siedel master:db6e360afb81: avformat/mpegts: add ts stream types for H266/VVC
<JEEB> yay, container support
<elenril> where's matroska
<jamrial> they pushed the change to ff_codec_movvideo_tags that was not supposed to go in
<JEEB> :<
<elenril> quick, get the flamethrower
<durandal_1707> elenril: what secret organisations do you visit frequently?
<jamrial> "mp4: reintroduce vvc back into ff_codec_movvideo_tags since the mp4 demuxer relies on it."
<elenril> lisbon numerical relativity group
<jamrial> wonder why
<durandal_1707> elenril: really? cool.
<Daemon404> 627dbc4e00d4 is doing the lords work
<JEEB> indeed
<JEEB> wololoo
kekePower has quit [Quit: The Lounge - https://thelounge.chat]
<JEEB> jamrial: I recall when looking into the TTML stuff that the MP4 demuxer looks into various stuff and there's shared identifier lists etc
<jamrial> JEEB: apparently, mov_codec_id() uses it
<jamrial> so yeah
<jamrial> it's properly split in the muxer, but not the demuxer
AbleBacon has joined #ffmpeg-devel
kekePower has joined #ffmpeg-devel
Marth64[m] has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
navi has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
<durandal_1707> please define "The FFmpeg Community"
<elenril> the paul fanclub
Oneric has quit [Quit: Connection lost]
<Daemon404> is it just me or is the spi guy weirdly aggessive
<Daemon404> do they stand to gain something?
Oneric has joined #ffmpeg-devel
<Lynne> durandal_1707: found an issue with the rdft, nptwo transforms are broken
<Lynne> I think it's a NIH-ABI issue, not setting a register right or similar
jarthur has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<Marth64[m]> lasagna and ravioli, key take away today from the email chain
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
jarthur has quit [Ping timeout: 268 seconds]
jarthur_ has joined #ffmpeg-devel
omegatron has joined #ffmpeg-devel
<jamrial> mkver: are you ok with "avcodec: move leb reading functions to its own header"?
<Lynne> Traneptora: no reason to NIH a cbor, there's libcbor, which is common enough and complete
<mkver> Well, why not?
<Lynne> I wouldn't object to having exif in cbor as side data
Marth64[m] has quit [Read error: Connection reset by peer]
<kierank> Daemon404: it's a very "i am an expert"
<kierank> and HN lawyer
BtbN has quit [Ping timeout: 256 seconds]
<jamrial> mkver: you asked for it, hence me wondering if that's how you wanted it
BtbN has joined #ffmpeg-devel
<elenril> thardin: are you familiar with our mxf muxer?
<elenril> does it expect to get a frame rate or a field rate?
<courmisch> I bring most dire news to all FOSDEM attendees. Against all odds, it is confirmed that a Courmisch will lurk in the event.
<psykose> try not to eat the floorboards this time
<courmisch> nothing to worry about. Humans taste much better
<elenril> surely cannibalism is against the CoC
<JEEB> itchy. tasty.
<courmisch> FOSDEM 2024 has no CoC
<courmisch> FOSDEM 2023 had one but it does not seem to preclude cannibalism, provided that you are respectful toward the meat
<Daemon404> see what i said in here yesterday
<elenril> Daemon404 | duke is nukem
<elenril> Daemon404 | should have it at pauls house
<elenril> Daemon404 | easy to get bitten
<Daemon404> yes of course.
<courmisch> I'm Courmisch and I'm coming to get the rest of you ... XXX
<elenril> i'm developer paul and this is my favorite channel on libera.chat
<courmisch> I read somewhere that human taste similar to pork, and I like pork
<courmisch> just sayin'
<courmisch> elenril: did you maybe miss the cultural reference? https://www.youtube.com/watch?v=kWL9JTfOnSg
<elenril> maybe you did
<elenril> >fosdem sending emails where the text/plain alternative has html tags
<elenril> me=disappoint
<Daemon404> why is fodem sending you emails
<Daemon404> fosdem even
<wbs> Daemon404: he's a speaker
<Daemon404> ah
<Daemon404> i thought it was up to the room organizers to do that stuff
<thardin> elenril: good question
<thardin> the STF thread is a trainwreck
iive has joined #ffmpeg-devel
<Daemon404> at least if youre in a trainwreck youd probably die istead of continuing to suffer
<thardin> oh yeah true
<elenril> thardin: I'm making a change that causes it to get field rate as timebase and it breaks fate-copy-trac4914
Marth64 has joined #ffmpeg-devel
<elenril> so I'm wondering how to proceed
<thardin> it takes st->time_base as EditRate
<thardin> the question though is what the Correct(tm) thing is to do
<elenril> the easy way out would be to try avg_frame_rate first, which happens to be set correctly for this test
<Marth64> mkver: Overall I was able to adapt and use your mpeg2_metadata changes with success. I am still testing with some different material, but (1) do you mind if I send it up as a patch when done? obviously with credit to you (2) my understanding that the BSF API does not allow to set avg_frame_rate (which the muxers I'm using expect), so framerate changes using the bsf cannot be reflected
<Marth64> at the container level. I can only set the deprecated one in codecpar. Just wanted to confirm if I'm seeing it correctly.
<cone-764> ffmpeg James Almer master:fa469545ba07: avcodec: move leb reading functions to its own header
<thardin> nope nope nope don't use avg_frame_rate
<thardin> go to dungeon
<courmisch> dungeon are deprecated
<courmisch> it's caleld high-security jail now
<Marth64> Matroska muxer looks for it first, then yields to r_frame_rate
<elenril> Marth64: AVCodecParameters.framerate exists
<elenril> bitstream filters can set it
<Marth64> yes but as per the doc "only as a last resort" and matroska muxer doesn't consider it
<thardin> the EditRate can be anything if I'm not mistaken. but if the essence is not editable in said units then you may or may not be committing an MXF sin
<Marth64> :(
<elenril> well yes, it's a last resort for computing timestamps
<thardin> in principle interlaced video is editable on field level, so I suspect it should be OK. index tables also play a role here
<elenril> if you want to set timestamps, you should set timestamps
<kierank> elenril: also check time on fosdem
<kierank> as everyone seems to be getting it in utc
<kierank> instead of cet
<elenril> thardin: what seems to be happening is audio is interleaved too fast
<elenril> kierank: email says 12:00-12:25
<kierank> yep they screwed up
<Daemon404> ...
<Daemon404> all the official schedules are wrong?
<durandal_1707> whole idea around FFmpeg is to break the laws
<thardin> elenril: that does not surprise me
<thardin> perhaps the muxer expects video dts to increase by 1 each packet
<Daemon404> the app says 1300 too
<Daemon404> so is 1200 or 1300 right
<durandal_1707> so 200k goes away because egos could not decide who will get more coins
<elenril> durandal_1707: where's your project proposal?
<durandal_1707> librempeg
<elenril> go and write one that converts all filters from dicts to side data
<courmisch> It wouldn't be a fair competition, so I won't apply!
<elenril> I thought you won't apply because you're employed and don't have the time
<Daemon404> i thought he needed puppy food money
<durandal_1707> still need it
<Marth64> elenril: use case: 29.97(soft telecine) -> 23.98(progressive) with modified mpeg2_metadata bsf. mpeg2_metadata allows to set mpeg2 header level framerate, but BSF API only allows to reflect this at codecpar level. The problem then is matroska muxer will write the stream as 29.97 because it doesn't care about codecpar->framerate. if I go to intermediate headerless format like
<Marth64> mpeg-ps(vob) this is not an issue but then going to ancient limited format
<Marth64> (also thank you for your time)
<thardin> I guess mxf_interleave() and mxf_interleave_get_packet() are related. those functions seem new
<elenril> Marth64: the caller should also propagate the updated framerate to the muxer, which I imagine does not happen properly
<thardin> 2021
<courmisch> Daemon404: I don't own any canine
<Marth64> elenril: yes exactly i had to hack it on into ffmpeg_mux as a proof of concept
<elenril> Marth64: I mean it's not a fundamental issue
<courmisch> all the monies should go to Kostya to port FFmpeg to Rust anyway
<elenril> but the code that does it is a bit insane
<Marth64> got it... i will study more what's going on based on your feedback. will articulate here what i find. thank you!
<elenril> thardin: 8360fd26105?
<Traneptora> Lynne: the problem here is the statement "side data must be flat"
<elenril> Marth64: definitely don't look at avformat_transfer_internal_stream_timing_info(), it will fry your brain
<durandal_1707> not round or sphere?
<Traneptora> linking in an external library to serialize it so we can work around our own restriction seems like a problem we created
<elenril> the thing I'm discussing with thardin is because I made a tiny change to it and now random things explode
<Marth64> elenril: brain fried just from the name of the function :D
<thardin> hum hum
<elenril> it should not exist, as far as I'm concerned
<elenril> but getting rid of it is...involved
<elenril> we're getting there though
<thardin> last time I looked at how interleaving is done I decided to stop looking at how interleaving is done
<elenril> that code offends me, because it's one of the only two users of .interleave_packet
<courmisch> elenril.interleave_packet()
<thardin> pkt->pts = pkt->dts = sc->pkt_cnt++; hmmmmmmmm
<Lynne> Traneptora: you would just assemble all exif data into a cbor data chunk, and provide that chunk as side data, which you would just ask the user to interpret
<elenril> self.stab(courmisch)
<thardin> that needs an av_rescale I suspect
<Traneptora> if the plan was to do that, then I'd just take the Exifdata out of the bitstream directly
<courmisch> elenril: borrow checker says you can't do that
<Traneptora> and not process it
<durandal_1707> how much elenril writes lines of code per hour?
<elenril> durandal_1707: preferably negative
<Traneptora> since Jpeg app1, png, and webp all use the same structure
<Traneptora> tiff is the only exception and it's only because it inherits the endianness from the parent tiff, which you could replicate
<durandal_1707> since when elenril wrote anything constructively new and useful?
<elenril> thardin: shouldn't mxf support pts!=dts?
<Traneptora> code maintenance is god's work
<thardin> elenril: it does
<thardin> try commenting out that line entirely. I don't see why it's modifying pts and dts at all
<elenril> [mxf @ 0x5627f1ac9a80] Received non-video packet before header has been written
<durandal_1707> bug
<thardin> I also suppose we don't have any mxf tests that write B-frames
<thardin> I know for sure I implemented the index table stuff for it and that it worked. but that was way before 2020
<Lynne> Traneptora: sure, that sounds fine
<elenril> actually nothing in there seems to read pkt->pts
<Lynne> are there libraries that can take a pointer with exif and deserialize it?
<thardin> yeah but doesn't the interleave stuff?
<durandal_1707> how to make showcwt filter usage popular?
<thardin> mxf_compare_timestamps()
<elenril> thardin: inteleaving is by dts
kurosu has quit [Quit: Connection closed for inactivity]
<thardin> right
<thardin> wait a minute
<elenril> usleep(60000000);
<thardin> oh yeah it does some on-the-fly index generation. it's in mxfdec that my stuff is
<Marth64> no av_usleep?
<courmisch> av_this av_that
<Marth64> haha
<courmisch> was somebody a glib developer or an Apache HTTPd's ?
<thardin> yeah it parses that info directly from the essence data
<durandal_1707> what is needed to make somebody code the fastest FFT/RDFT code in TX with SIMD for x86?
<Marth64> courmisch:a long time ago i did apache work but i am talking httpd 1.3 days
<thardin> hence why it doesn't need proper pts or dts. it just digs out the temporal_ref info directly from the mpeg2 headers (and similarly with h264 etc)
<courmisch> Marth64: so ap_this ap_that time
<elenril> disgusting
<Marth64> yes, definitely was a thing haha
<elenril> thardin: shouldn't there be a place in mxf structures to store timestamps?
<courmisch> I remember seeing it back when I was an edgy teenagers
<courmisch> s/s$//
<Marth64> CGI for all
<durandal_1707> what is needed to make somebody code the fastest FFT/RDFT code in TX with SIMD for x86?
<Traneptora> Marth64: av_usleep_now_goodnight
<thardin> elenril: there is
<Marth64> +_q
<thardin> it's similar to cts in mov
<elenril> but our muxer does not use it?
<thardin> it doesn't actually store the timestamps themselves, but pts - dts
<durandal_1707> nobody wants to write and do proposal for TX to make use of 200k
<thardin> see section 11.1.6 of S377m
<elenril> durandal_1707: speedups are not maintenance
<durandal_1707> :((((
<elenril> thardin: is it downloadable?
<thardin> I could email it to you
<thardin> and hey, the example there is with interlacing
<elenril> that would be nice
<thardin> temporal offsets like 0,0,+2,+2,+2,+2,-4,-4,+2
<durandal_1707> ban all the people
<thardin> elenril: sent
<durandal_1707> i got elenril's shelter address!
<thardin> either way seems we need to make sure we have a long-GOP MXF test. with open and closed GOPs
<elenril> thanks
<thardin> helpfully you can point the entries for both fields to the same body offset
<elenril> now the question still is how do i proceed
<thardin> based on what S377m says it seems the correct action is to write two entries per packet when the input is interlaced
<thardin> I'd add very stringent checks in mxf_init()
<elenril> I don't think it even is here
<elenril> it just might be, so ffmpeg.c decides to use the field rate as the framerate
<elenril> err as the timebase
<thardin> seems like you should get a "missing frames" warning if you mess up
<thardin> maybe.
<thardin> I bet mxf_parse_mpeg2_frame() is slower than it needs to be
<thardin> it parses the entire packet byte by byte
rvalue has quit [Ping timeout: 268 seconds]
<thardin> not a single test in mxf.mak uses -bf
derpydoo has joined #ffmpeg-devel
<elenril> thardin: not seeing any warnings
<elenril> my change is just https://up.khirnov.net/sf
<elenril> which causes muxer timebase to be 1001/60k instead of /30k
rvalue has joined #ffmpeg-devel
<thardin> shouldn't it be den *= ticks_per_frame ?
<elenril> it shouldn't be anything, because dec_ctx_tb is already the field rate
<elenril> multiplying num by ticks_per_frame turns it into framerate
___nick___ has joined #ffmpeg-devel
<thardin> ah
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<JEEB> alright, I can now also confirm I'll be at FOSDEM :)
* JEEB was able to get himself an OK place to sleep at
MajorBiscuit has joined #ffmpeg-devel
MajorBiscuit has quit [Client Quit]
bcheng has quit [Ping timeout: 260 seconds]
<durandal_1707> MiNi is The Great Boss
<durandal_1707> elenril is just a mini Boss
kurosu has joined #ffmpeg-devel
<JEEB> then who's the Big Boss?
<Marth64> avformat_transfer_internal_stream_timing_info()
<courmisch> in some games, the boss is actually much easier to beat than the bonus villain
<courmisch> e.g., Borderlands
<Marth64> yes, case study Zelda Tears of the Kingdom: https://www.youtube.com/watch?v=EGDR4AOIp3g (spoiler)
<courmisch> also that's the whole premise of Villainess Level 99
<another|> hey there, vaulthunter!
<courmisch> I never really tried. They are not supposed to beatable in single player mode
bcheng has joined #ffmpeg-devel
<courmisch> +be
<another|> you mean the special co-op missions?
<another|> that are designed for 4 players?
<courmisch> well those are where the superbosses spawn
<courmisch> at least in BD2
<courmisch> BL2*
<another|> yeah, you probably don't want to take them yourself
<thardin> will there be a jitsi meeting at fosdem? there was last time I think
<courmisch> BoFs cannot be arranged until the day of
Krowl has joined #ffmpeg-devel
<courmisch> I suppose there will be 1h VideoLAN and 1h FFmpeg meetings, in some order
<JEEB> yea FFmpeg apparently Saturday afternoon
<courmisch> Open media is on Sunday, so yes
cone-764 has quit [Quit: transmission timeout]
<durandal_1707> courmisch and JEEB are just NPC
<JEEB> I'm fine with mobs
<JEEB> vOv
<courmisch> durandal_1707 watched too much Solo leveling
<Daemon404> a cat is fine too
<JEEB> oh you
<courmisch> I see what you did there. I don't have a feline either
<courmisch> There would be nobody to take care of her whilst I travel
<courmisch> And spending your entire life in a 50 sqm apartment sounds depressing for a cat.
<durandal_1707> i live in 5000 sqm penthouse
<courmisch> I live under a 150 sqm penthouse
<Daemon404> weird way to describe a serve farm, paulAI
<JEEB> lol
<durandal_1707> courmisch: aka bridge
<courmisch> no, actual fancy overpriced penthouse roof-top apartment, 3 floors above
<durandal_1707> Daemon404: i have girlfriend and apartment on meta
<courmisch> I didn't know they made AI in Component Object Model
<courmisch> but that would explain the apartment thing
<courmisch> lets see... is it a single-thread apartment or the multithread apartment?
<durandal_1707> hero-wars.com
<durandal_1707> the ad-free content
<durandal_1707> courmisch: its FreeDOS
<Daemon404> i feel bad for any peple who join this channel for the first time and read this
<durandal_1707> rotfl
<durandal_1707> this or content written in alien language, like code stuff nobody cares about except some devs
<durandal_1707> bunch of people came here, with question help me how to start coding for FFmpeg....
<JEEB> start with building, dess
<JEEB> :3
<durandal_1707> they get MIA fast, because they cant handle uncommented complex code, reverse enginering and trac reports that are like climbing mount everest
<durandal_1707> toxic ML is just sugar on top
<Marth64> i survived
<JEEB> if they just want to hack something for themselves, they can get somewhere :)
<JEEB> like the DVD stuff with Marth64, yup
<durandal_1707> Marth64: you are not generation Z
<Marth64> yes and even if it just stays local for me that is ok
<Marth64> durandal_1707: no definitely not hahaha
<Marth64> generation iPad
<Marth64> *
<Marth64> few things i learned:
<durandal_1707> oh, i forgot to mention selfish people that take moneys for themself
<Marth64> 1) TRAC is slow. 2) genpts is evil. 3) ML dramas are worthy of their own show.
<Marth64> and of course 4) av_this av_that
<cworley> trac has good drama too :)
BradleyS has quit [Quit: quit]
<durandal_1707> 1) switch to gitlab 2) put PR on gitlab 3) move discussions to gitlab
<Marth64> gitlab is awesome
<Marth64> i will never forget one job i had
<Marth64> "Marth64, our GitHub license expires in 24 hours and we can't afford to rewnew it. migrate everything nao to GitHub"
<Marth64> GitLab*
<Daemon404> cworley, durandal_1707 is Elon Musk on trac, of course.
<cworley> i noticed that
<Daemon404> i guess it is hard to miss
BradleyS has joined #ffmpeg-devel
<Marth64> you all probably need a forum software or something
<Marth64> SMF
<JEEB> ah, SMF. what a classic
<Marth64> yes
<Marth64> i used to be on their team
<durandal_1707> Daemon404: you will pay for this!!!
<Marth64> 2004 era
<Marth64> maybe 2007. i dont even remember now
<Daemon404> durandal_1707, do you take card?
<cworley> one thing that is unclear as a newcomer is what it takes to get patches reviewed and merged, besides the whim of someone with write access
<Marth64> lots of time
<Marth64> and very kind people willing to take a chance with strangers
<JEEB> cworley: yea we don't exactly have much headroom with regards to reviews
<Daemon404> cworley, lots of pinging unfotunately
<JEEB> which is unfortunatel
<Daemon404> being active on irc helps
<Daemon404> dangerous as it is.
<durandal_1707> Daemon404: wait for taxes
<Marth64> also lots of fear
<durandal_1707> why LibAV still uses mailing lists?
<Marth64> fear of patents and such
<JEEB> Marth64: 24h migration sounds like a great experience
<Marth64> JEEB: it was awful but we did it with Bash and Groovy. GitLab had good APIs to work with.
<JEEB> nice :)
<durandal_1707> it was miracle that FFmpeg switched to git
<JEEB> also I probably have a SMF instance backed up somewhere here which I need to pull back up or switch to some other thing that has migrations from SMF
<Daemon404> it was done as part of the fork
<Daemon404> only way to force Certain People
<Marth64> JEEB: anything you need, let me know. i used to write the converters!!
<Marth64> it's been a long time, but i can give contacts or direction
<durandal_1707> Certain People are Very Influental and Powerful folks
<Daemon404> indeed
<jamrial> it would have happened sooner or later in any case
<jamrial> even gcc moved to git eventually
<JEEB> Marth64: cheers. will have to see when I get to that stuff :)
<Daemon404> jamrial, real git or idiotic GNU uses of git
<Daemon404> some gnu projects use git like vs
<Daemon404> cvs*
<Marth64> JEEB: i understand, cheers back. personal backlogs always miles long
<durandal_1707> Daemon404: how that even works?
<Daemon404> poorly
<Daemon404> squash everything in one giant commit with a cvs style changelog
<Daemon404> or per-file.
<durandal_1707> stop, i cant handle it more...
<Daemon404> thats not the safe word
<durandal_1707> there is more?
<Daemon404> always more in the savanah
<cworley> what's stopping gitlab for ffmpeg
<j-b> Good morning, good folks
<Daemon404> cworley, not everyone agrees to move
<cworley> ok, figures
<jamrial> not everyone likes it. supposedly it's not CLI friendly
<jamrial> or that used to be the case
<durandal_1707> Bad morning, bad folks
<Marth64> dunno about cli usability besides git itself (which works fine)
<j-b> durandal_1707: <3
<Daemon404> Marth64, people want to be able to handle PR review via TUI / CLI
<Daemon404> right now they use TUI mail clients
<Marth64> i see
<Marth64> surely a compatibility bridge or script can be come up with possibly?
<Marth64> but i don't know the workflow of those folks so that is probably easier said than done
<cworley> https://gitlab.com/gitlab-org/cli this doesn't look half bad
<Daemon404> if you think you an convince the holdouts, be my guest
<cworley> i don't know who they are, let alone think that
___nick___ has quit [Ping timeout: 252 seconds]
<Marth64> one angle to sell is to look at time spent just dealing with the quirks of email, maybe you redeem that time by letting go off that model
<Marth64> e.g. "patch isnt in right format", "one line is missing", "patch 1 caught by spam"
<Marth64> idk i have no stake in this but just wearing my business hat
<Lynne> cworley: elenril
<Lynne> pretty much just elenril
<durandal_1707> j-b: Dear Mr. President, During your administration, the Community Commiitee has worked tirelessly to protect the public from violent trolls; worked closely with leaders in LibAV to fight commits without reviews; defend competition in marketplace; and protected the men and the women of coding skills who risk their lives to keep this project relevant by their thanklessly contributions.
<Lynne> who implanted you with one of musk's chips?
Krowl has quit [Read error: Connection reset by peer]
* microchip_ farts
<jamrial> i want to move to gitlab or similar because it's really hard to keep track of patchset updates with an ML
<jamrial> one day it will happen, i'm sure, but probably not today
<JEEB> aye
<wbs> +1, it's a pain to dig up and review nontrivial patchsets unless you manage to respond to them right away
<durandal_1707> j-b: As discussed, I will spend the next week wrapping up a few remaining matters important to the CC and TC and depart on 02.01.2024. Wishing you, j-b, elenril, and your community a Happy New Year and godspeed!
<j-b> durandal_1707: <3
<cworley> automatic 3-way merge is also very nice to have
<Marth64> you maybe also get a fresh start on your bug tracking
<Marth64> or have some kind of trigger to transmit "real" bugs from trac to gitlab
<jamrial> once we move, we'll force rebase to git head
<jamrial> no merge commits
<cworley> yes, squash and rebase
<wbs> no, no squash, rebase and merge
<durandal_1707> what that means?
<durandal_1707> you merge all commmits into 1?
<jamrial> squash? yeah
<wbs> yes, each PR/MR becoms 1 commit afterwards
<wbs> so your branch is commit 1, "libavcodec: implement decoder x", commit 2 "fix bug", commit 3 "fix typo", etc
<durandal_1707> hack
<Marth64> git rebase -i HEAD~<how far back you wanna go>
<jamrial> yeah, some projects add new commits to the MR with fixes reported during review, and then that gets squashed into a single commit
<wbs> some projects do this, because github's UI for tracking what changed from one revision of a PR to the next, absolutely sucks
<jamrial> yeah, gitlab is great with that
<JEEB> I think github finally added links for those comparisons nowadays
<jamrial> you can see actual line changes between force push on the same MR
<wbs> which makes it much harder to merge a branch of intentionally-separate commits, as you'd need to do one PR per intended commit
<wbs> it's absolute madness
<JEEB> so you see have a link for each push
<JEEB> (at least force push)
<durandal_1707> "Fixed one lack"
<Marth64> i will say one annoyance with gitlab was server maintenance
<jamrial> it does however not filter commits added from a rebase to current git head
<Marth64> like it wasn't horrible but you need to pay attention on disk space, where things are blowing up due to logging/caching/whatever. you need also to deal with ruby
<Marth64> circa 2018 at least idk if ruby is out of the picture now
<JEEB> Marth64: videolan already does gitlab maintenance so I believe we could either share those resources/instance, or otherwise get someone to properly manage various bits of the infra
<wbs> Marth64: that would require a 100% rewrite of gitlab, that's not happening
<Marth64> JEEB: perfect good i think thats my only point, it needs a good admin or group of
<Marth64> gitlab ci/cd is nice too but you need docker skillz
<Marth64> wbs: ah well
<durandal_1707> "We love transparency in this project, right?" since when?
<Daemon404> swscale supported alpha for ages
<durandal_1707> lol
<j-b> Daemon404: gg
<wbs> Daemon404: alpha the architecture, or as in transparency? :P
<wbs> ah, now I see the reference to the line above, doh
<Daemon404> lol
<durandal_1707> rotfl
<Marth64> lasagna, ravioli, or spaghetti
<Daemon404> is this like the pasta version of bikeshedding?
<jamrial> wbs: i was about to say it supported both, but i just noticed that no, there's no alpha asm in sws
<durandal_1707> pasta version is irrelevant, the red thing that goes in is more important.
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
<Daemon404> pure red dye 40
<durandal_1707> patented
<Daemon404> expired
<Daemon404> i am pretty sure
<Marth64> Daemon404: i found the foods in the funding email thread itself
<Daemon404> oh lol
<Marth64> and it's been in my brain for hours now, 100% eating spaghetti for dinner
<Daemon404> will the german tax payer subsidize our pasta
<durandal_1707> According to clinical research, Red 40 can cause hypersensitivity reactions—exaggerated or inappropriate immunologic responses to an antigen or allergen. While these reactions vary in nature, one commonly reported hypersensitivity reaction is ADHD. Cancer-causing carcinogens like benzidine have also been identified as contaminants in Red Dye 40.
<kierank> Merge FFmpeg Forks
<kierank> what fork?
<kierank> 12 months work?
<durandal_1707> Librempeg is upstream of FFmpeg
<Daemon404> kierank, ... sdr
<kierank> durandal_1707: lol not this again
<durandal_1707> yes, ffmpeg can now merge SDR, but librempeg will not pick it.
<Daemon404> i am not joking here
<Daemon404> sdr is probably the fork they mean
<Daemon404> but didnt want to write sdr
<durandal_1707> i'm really serious
<jamrial> sdr is not being merged unless it's its own library and not a clone of libavdevice using lavf's API
<jamrial> lavd is already awful to have in its current state, we're not making that same mistake twice
<Daemon404> i know, im just referring to the trac wiki
<Daemon404> not reality
<durandal_1707> ugh, why libpostproc is still there?
<Daemon404> mpeg-1 vcds are important
<jamrial> durandal_1707: because nobody rewrote the two or so filters that use it
<jamrial> once that's done, it's gone
ccawley2011 has quit [Ping timeout: 268 seconds]
<kierank> Daemon404: added a comment as to what fork
<durandal_1707> jamrial: are you old? i proposed that last time, and MiNi was against it.
<Daemon404> i was hoping to hold out till the technical meeting
<jamrial> durandal_1707: how so?
<Daemon404> to put my foot back in the poo
<jamrial> if no filters use the library, then it can be removed
<durandal_1707> MiNi wrote something like people wanting use only libpostproc library and nothing else
<jamrial> [doubt]
<durandal_1707> there is whole transcript
<durandal_1707> it was on one of those video link meettings
<jamrial> people actually used libavresample, but we removed it anyway because we already had another resampling library
<durandal_1707> mainly no resolution came out so nothing happened
<jamrial> so libpostproc has no reason to be in git head if lavfi features its functinoality
<jamrial> simple as
<durandal_1707> jamrial: well, avresample had better looking source code, everything else was very similar.
ccawley2011 has joined #ffmpeg-devel
<durandal_1707> i need to check this again, because if similarity is soo huge, either one coder stole it from another; they coded it together; or both stole it from someone else...
<durandal_1707> lol, 50.000 eur to merge some commits from SDR or librempeg(i sincerely hope) into ffmpeg
dellas has quit [Ping timeout: 240 seconds]
dellas has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<kierank> durandal_1707: take the offer
<Marth64> at least you get to work remote
<kierank> CID seems 1591439 reasonable
<kierank> dunno how to fix
<kierank> set dec to NULL I guess
<kierank> coverity is like 10k maybe of work
<kierank> not 47k
<Marth64> the false positive is a very real problem with these types of tools
<Marth64> you have to absolutely tune them
<Marth64> one of my teams was bombarded with stupid asks from a similar tool after an update
<Marth64> "you are using variable with the word __xyz__ in it, rewrite all your code or die"
<Marth64> its worse when you have to argue it with actual people who have no idea how the static analyzers work and how the code works
<Marth64> but, is a neccessity for modern secure code
<Daemon404> semgrep by default will flag any C function call with alloc in the name
<Marth64> yes and they'll rack up the count of how many you have, which serves no purpose other than to make you look bad on reports to your stakeholders
<Marth64> a simple "hey, you're doing this, are you ok with it" would be fine for something like that
<Marth64> </ramble></scars-from-the-past>
<Marth64> gen z static analysis tooling
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
mkver has quit [Ping timeout: 268 seconds]
<j-b> kierank: Coverity is hard to get through. There are tons of false-positive.
<j-b> Configuring it is hard.
ccawley2011 has quit [Read error: Connection reset by peer]
MrZeus has quit [Ping timeout: 260 seconds]
Marth64 has quit [Remote host closed the connection]