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
<Sean_McG>
mkver: thanks again for the PPC/AltiVec changes
<Sean_McG>
they should help clean up some of the s390x tests as well.
<Sean_McG>
I notice on s390x fate-autorotate is failing but I am going to be honest it looks like that is the only platform where that is happening -- does any of that test using floating point math? I know FP representation is very different on S/390 than other architectures...
<cone-022>
ffmpeg James Almer master:f492f1ac239d: avformat/mov: ensure all items id referenced by a grid are valid
<cone-022>
ffmpeg James Almer release/7.0:2ecaef745556: avformat/mov: ensure all items id referenced by a grid are valid
IndecisiveTurtle has quit [Ping timeout: 256 seconds]
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<JEEB>
unless that depended on something else, probably yes
cone-416 has joined #ffmpeg-devel
<cone-416>
ffmpeg James Almer master:3d12ba77d9a4: avformat/mov: take into account the first eight bytes in the keys atom
<cone-416>
ffmpeg James Almer master:8e294abd9d21: avformat/mov: simplify the entry count overflow check in the keys atom
<cone-416>
ffmpeg James Almer master:5a06d3810e41: avformat/mov: don't read key_size bytes twice in the keys atom
<cone-416>
ffmpeg Eugene Zemtsov release/6.1:5e45c27ba9ba: avformat/mov: Check if a key is longer than the atom containing it
<cone-416>
ffmpeg Eugene Zemtsov release/6.0:f9821fd9079e: avformat/mov: Check if a key is longer than the atom containing it
<cone-416>
ffmpeg Eugene Zemtsov release/5.1:36cf037fb8cf: avformat/mov: Check if a key is longer than the atom containing it
<cone-416>
ffmpeg Eugene Zemtsov release/5.0:60df6aad93ff: avformat/mov: Check if a key is longer than the atom containing it
<cone-416>
ffmpeg Eugene Zemtsov release/4.4:b6fa0f9d086b: avformat/mov: Check if a key is longer than the atom containing it
<cone-416>
ffmpeg Eugene Zemtsov release/4.3:cda5d4698c66: avformat/mov: Check if a key is longer than the atom containing it
<cone-416>
ffmpeg Eugene Zemtsov release/4.2:f3ed17ef4f45: avformat/mov: Check if a key is longer than the atom containing it
<cone-416>
ffmpeg Eugene Zemtsov release/4.1:cdd355e08734: avformat/mov: Check if a key is longer than the atom containing it
geoffhill has quit [Quit: geoffhill]
geoffhill has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
<j-b>
galad: JEEB: who is the owner to BP?
<JEEB>
by default haasn since he is the author, but if he doesn't have the time to check if anything else needs to be backported or if it's feasible or not, someone else might have to take over
<cone-416>
ffmpeg Nuo Mi master:cd540a333e48: avcodec/vvcdec: NoBackwardPredFlag, only check active pictures
<cone-416>
ffmpeg Nuo Mi master:191fbd7ddc1a: avcodec/cbs_h266: fix sh_collocated_from_l0_flag and sh_collocated_ref_idx infer
<cone-416>
ffmpeg Nuo Mi master:64d5cc67cd77: avcodec/vvcdec: misc, add specification name for pps members
<cone-416>
ffmpeg Frank Plowman master:9c845e90872f: avcodec/vvcdec: fix uninitialized last element of xxx_bd and ctb_to_xxx_bd arrays
<cone-416>
ffmpeg Frank Plowman master:8078a0b0fa72: avcodec/vvcdec: support rectangular single-slice subpics
<cone-416>
ffmpeg Nuo Mi master:4e47847119ce: avcodec/vvcdec: derive subpic position for PPS
<cone-416>
ffmpeg Nuo Mi master:260130aae86b: avcodec/vvcdec: ff_vvc_decode_neighbour, support subpicture
<cone-416>
ffmpeg Nuo Mi master:4020e68d7356: avcodec/vvcdec: misc, rename x_ctb, y_ctb, ctu_x, ctu_y to rx, ry to avoid misleading
<cone-416>
ffmpeg Nuo Mi master:0d12e9c3c852: avcodec/vvcdec: refact out deblock_is_boundary
<cone-416>
ffmpeg Nuo Mi master:8b7304247af6: avcodec/vvcdec: deblock, support subpicture
<cone-416>
ffmpeg Nuo Mi master:c9e75393edc9: avcodec/vvcdec: refact, movie the lc->sc assignment to task_run_stage to simplify the code
<cone-416>
ffmpeg Nuo Mi master:0c3018b30a23: avcodec/vvcdec: sao, refact out tile_edge arrays
<cone-416>
ffmpeg Nuo Mi master:bbf0ccb8e7e4: avcodec/vvcdec: sao, support subpicture
<cone-416>
ffmpeg Nuo Mi master:adeb51c30fa6: avcodec/vvcdec: alf, support subpicture
<cone-416>
ffmpeg Nuo Mi master:9bc3f3e5fc39: avcodec/vvcdec: mvs, support subpicture
<cone-416>
ffmpeg Nuo Mi master:238bb653e7ea: avcodec/vvcdec: inter prediction, support subpicture
ngaullier has joined #ffmpeg-devel
<cone-416>
ffmpeg Andreas Rheinhardt release/7.0:efa0670048dd: avformat/mov: Don't add attached pic if one is already present
<cone-416>
ffmpeg Andreas Rheinhardt release/7.0:dcbc1fdb3b9c: avcodec/vlc, bitstream: Fix multi VLC with uint8_t syms on BE
Poorva_ has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
rvalue has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
<Sean_McG>
mkver: awesome!
AbleBacon has joined #ffmpeg-devel
<kurosu>
"we have paid significant amounts to various open-source initiatives, including bento4, x264 (part of Videolan afaik), x265, *AOMedia, DASH-IF* [missing the subtitle: because we have to anyway, if we want to attend/get info from these bodies], [...], finance currently 8 PhD positions at a university [actually, where our CTO holds a chair]"
<kurosu>
that was massively in bad faith
<kierank>
I agree but we shouldn't give him oxygen
<kierank>
just let him keep diggng
<nevcairiel>
x265 is also a company =P
<kurosu>
yeah, forgot about mcw, thought they were dead
<kierank>
doing AI now ofc
<nevcairiel>
they promised everyone x266 but nothing ever came out yet
<wbs>
who/what/where was that quote from?
<kierank>
wbs: the bitmovin ceo after april fools
<kurosu>
anyway, the people knowing the subtitles are likely people that are not signing cheques to his company, so ENOCARE
Poorva_ has quit [Ping timeout: 260 seconds]
<kurosu>
wbs: besides what Kieran said, scroll a day or so for the "X, formerly known as Twitter" link
<cone-416>
ffmpeg James Almer master:45b56455ad03: avcodec/vvc_refs: don't ask for a "Inter layer ref" sample
<cone-416>
ffmpeg James Almer master:e9778d20a434: fate/vvc: disable vvc-conformance-OPI_B_3 and vvc-conformance-VPS_A_3
<BBB>
next quote for kierank: "The lesson from the xz fiasco is that sustainability investments are unsexy, but pay off a thousandfold over many years. But try selling that to a bean counter."
<kierank>
BBB: unlord told me to say everyone at xiph is gone
<kierank>
and I mentioned that
<kierank>
BBB: well...tbh I might as well drop the whole microsoft ticket nuke
<BBB>
go go go
<BBB>
so much fun to be had here
<BBB>
what *are* you waiting for
<kierank>
the right moment
<BBB>
o_O
<BBB>
we create moments, we don't wait for them
<kierank>
I dunno, demuxed was a moment
<kierank>
and dropping that on twitter needs one
<kierank>
I was thinking of doing it with one of the big linux twitter accounts
<BBB>
you have a big linux twitter account?
<kierank>
there are some
<cone-416>
ffmpeg James Almer release/7.0:112fdae9f99a: avcodec/vvc_refs: don't ask for a "Inter layer ref" sample
<cone-416>
ffmpeg James Almer release/7.0:4bb04c52fbd6: fate/vvc: disable vvc-conformance-OPI_B_3 and vvc-conformance-VPS_A_3
<BBB>
kierank: if you want a moment: use the xz fiasco as your moment
<BBB>
that's a good wave to ride on. people are paying attention to anything containing the words "xz" right now
<BBB>
characters*
<kierank>
potentially yes
<BBB>
you are so british right now :D
<BBB>
"let me just sit on that for a few months while the moment flies by"
<BBB>
daemon404 would be proud of you
<kierank>
Ok, I will ask the nixcraft account if they can reshare
<kierank>
in a coordinated post
<kierank>
tomorrow europe is always good as it reverberates
<BBB>
or is the ffmpeg twitter account too big to use for stuff like this?
<BBB>
ok then <3
<BBB>
hey I succeeded in trolling kierank, who knew I was capable of that
<kierank>
I guess I should just link to the ticket
<kierank>
16:52:20 <•BBB> next quote for kierank: "The lesson from the xz fiasco is that sustainability investments are unsexy, but pay off a thousandfold over many years. But try selling that to a bean counter."
<BBB>
I'm waiting for daemon404 to outdo you now
<kierank>
mostly ronald's words
<Daemon404>
BBB, cant, no access ;)
<BBB>
if I can make suggestions on IRC, so can you
<BBB>
come on, master troll. outdo me. I beg you
<Daemon404>
that sounds somehow kinky
<Daemon404>
tweet 'if you wish to discuss irl with us, come visit our booth at NAB'
<Daemon404>
i am sure it wont be a trainwreck
<Daemon404>
(do not do this)
<BBB>
:)
<BBB>
so the issue with the nab booth is ... that it's a corporation that did not get community permission to use our project name/fame for (presumably) their own corporate benefit?
<BBB>
or is it something else?
<BBB>
(I didn't follow exactly.)
<j-b>
good morning
pmozil has quit [Remote host closed the connection]
<kierank>
there is no transparency about who is paying for additional booth costs which are more than the floorspace, why there are other vendors on the booth
<kierank>
who is staffing the booth
<Marth64>
i considered going but couldn't tell if it was actually legitimate
<Sean_McG>
j-b \o
<Marth64>
i do want to introduce myself properly especially after the whole xz shady contributor thing
<cone-416>
ffmpeg James Almer master:6e52223f3a03: fate/vvc: add vvc-conformance-IBC_B_Tencent_2
<BBB>
Marth64: come to VDD this year, if you can
<JEEB>
^
<Sean_McG>
^
<Marth64>
i will check
<BBB>
Marth64: I feel the xz fiasco can be abused for so many bad political messages (xenophobia, etc.) but let's not go there
<BBB>
we've always had new contributors and we should be proud and welcoming
<JEEB>
yea
<BBB>
new people are great
<Sean_McG>
110%
<Marth64>
yeah, thanks for being friendly and guiding me over the past 1.5yr
<JEEB>
of course it's great to see physically in general, it can sometimes help with comms
<BBB>
we should be healthily suspicious of all contributions, and I think we try to deal with that using review
<JEEB>
yup
<BBB>
but let's not go to any place where new people or people with particular names or from particular places are more suspicious than others
<BBB>
that just sucks
<Marth64>
yeah i'm not wired that way myself
<JEEB>
BBB: everyone sane enough understands that the ethnicities aren't really relevant in such things
<BBB>
Marth64: if $$ is a concern, there is travel funding for VDD attendance
<JEEB>
yea, and active contributors are considered welcome in such manner
<Marth64>
BBB: ty. no concern fortunately, just the dates/long flight which are on me to sort out
<BBB>
right
<Marth64>
i ended up with new laptop. it is hot, noisy, and a tank. but i feel like i can do more now without awkward remote session to my workstation shenanigans
<Sean_McG>
what did you buy? </curious>
<Marth64>
ThinkPad P15v Gen 3 - by absolute luck. it was the last unit in the store and marked $700 less than MSRP
<Marth64>
AMD edition
<Sean_McG>
*googles it*
<Sean_McG>
hmmmm... seems decent
<Marth64>
we're getting used to eachother. coming from a Mac, i had to made concessions on the screen unfortunately but so worth it
<Marth64>
must commute to office now, you all have a fantastic rest of your day/night
<Sean_McG>
\o
<Rodn3y>
Since somebody mentioned VDD, has a location/timeframe been decided yet? Couldn't make it last year unfortunately.
<Sean_McG>
I noticed that the RELEASE file still refers to 5.1 on git master -- surely this is not correct
okx has joined #ffmpeg-devel
<jamrial>
Sean_McG: good catch
<cone-416>
ffmpeg James Almer master:8f85f657d70a: RELEASE: update after 7.0 branch
<Daemon404>
does that mean i was wrong for all of 6
<Daemon404>
it*
<jamrial>
yes
<jamrial>
does something use that file?
<jamrial>
i think everything uses git describe or similar
<nevcairiel>
only on master, the release branch is updated independently
Krowl has quit [Read error: Connection reset by peer]
<Sean_McG>
I would imagine the only things using it would be people building from the tarballs
raven4Get has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
jess has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
<Marth64>
the subtitle filtering patchset person did respond to me, they said they plan to revive and update their set!
<Marth64>
and with that...i will start the bdmv demuxer. hoping to have a result within a few months. (will keep picking at DVD muxing and closed captions intermittently)
<Marth64>
DVD seeking*
<Marth64>
thankfully we have some work already done in bluray.c protocol handler, but lots of work still needed for a proper demux
<nevcairiel>
the subtitle filtering person did never understood our criticism though and without that will just end up in the same discussion circle again
<Lynne>
Marth64: oh no
<Lynne>
^^that
<Daemon404>
rip
<Marth64>
i offered to help, if they take the offer i can try to mediate
<Lynne>
very little chance that leads to anything but frustration
<Lynne>
the developer refused over and over again to change the design
<Lynne>
don't agree on anything unless subtitles use the same avframe pts, duration and data and buffer fields as regular avframes
<cone-416>
ffmpeg Michael Niedermayer master:aeb13b03beca: tools/target_dec_fuzzer: Adjust threshold for RV30
<cone-416>
ffmpeg Michael Niedermayer master:d58037c18e54: avcodec/hevc_ps: --typo
<cone-416>
ffmpeg Michael Niedermayer master:1887ff250cfd: avcodec/apedec: Use NABS to avoid undefined negation
<cone-416>
ffmpeg Michael Niedermayer master:589fa8a027f3: avcodec/exr: Check for remaining bits in huf_unpack_enc_table()
<cone-416>
ffmpeg Michael Niedermayer master:e3984de6ffd6: avcodec/exr: Dont use 64bits to hold 6bits
<Lynne>
anything else and it's not subtitles in avframes, it's avframes masquerading as avsubtitles masquerading as avframes
<Marth64>
noted
<JEEB>
well, since Marth64 was originally planning on taking that set over... if there's no budge, then he just takes over
<Marth64>
and makes sense
<Marth64>
i originally planned to do it from scratch before i found this
<JEEB>
the original author gets to enjoy something else
<BtbN>
It might be better to start over from scratch in general
<JEEB>
instead of fighting over something he doesn't understand or want
<BtbN>
Might end up with a cleaner design then reworking something very misguided
<BtbN>
And be less work
<Marth64>
my plan was to have a more limited focus on introductury filters (i.e. simple replace/regex transforms), and focus on getting correct architecture instead
<JEEB>
possibly
<JEEB>
yea
<JEEB>
that sounds like a GoodIdea
<JEEB>
KISS
<Marth64>
yes
<Marth64>
filters can be added later
<Marth64>
design is hard to change
<BtbN>
The problem with subtitles is... there is no obvious "decoded" format
<Marth64>
i broke it down to 3 types
<Marth64>
you have bitmap, binary (closed captions), and rich text (normalized to either ASS or TTML for internal format)
<BtbN>
I guess we'll need something PIX_FMT alike for subtitles
<nevcairiel>
decoded, i would argue CC should be bitmap or text
<Marth64>
yes, the bitmap ones need palette and palette needs pixfmt
<BtbN>
no, as in SUBTITLE_PIX_FMT_ASS
<BtbN>
and so on
<BtbN>
Cause there just is no one decoded format that covers everything
<BtbN>
Obviously not a "pixel" format, but akin to it if it were a video frame
<JEEB>
wasn't the format utilized for pix and sample formats? so it's already not just a single thing
<JEEB>
thus AV_SUB_FMT_XYZ ?
<BtbN>
Yeah
<BtbN>
Did the original patch set have ANYTHING like that?
<BtbN>
Cause it seems essential to me
<JEEB>
probably not, if it moved the original AVSubtitle fields in AVFrame
<JEEB>
*into
<BtbN>
Cause a subtitle-filter needs to be able to negotiate to unly understand text, or convert text to bitmap, and so on
<BtbN>
*only
<BtbN>
So AV_SUB_FMT_ASS, _BITMAP, _WHATEVER does make perfect sense to have
<Marth64>
(sry stepped out for a sce). it had a enum for that yes
mkver has quit [Ping timeout: 252 seconds]
<Marth64>
s/sce/sec. will find the link now
<andrewrk>
enabling libchromaprint integration makes ffmpeg depend on libc++ right? that's unfortunate
<andrewrk>
it seems like libchromaprint reimplements a lot of ffmpeg internally
<Marth64>
nevcairiel: decoded yes but we can also do filtering on the raw bytes in theory if someone wanted and i think with the cc FIFO added a while back that could be a good fit. eg. trim padding bytes, or "filter out" unwanted CC services
<Marth64>
so basically can text or binary was my thought
<Marth64>
rich text* with positioning, etc., and only when decoded
<Marth64>
anyways i will give this author some time to come with a newer set, otherwise i'll go at it myself, meantime will do bdmv
<Lynne>
I never thought we could do bitmapped versions of text subtitles, this is amazing
<Marth64>
yeah they had made some cool filters
<Marth64>
but unfortunately i think thats also what may have caused it to be hard to get a proper change in, too big at once and i can see the lack of focus on the architectural detail brought via feedback
<Lynne>
treating subtitles in avframes as a new implementation and building it up rather than exactly replicating all the functionality and mechanisms of avsubtitles is the best way
<Lynne>
if we have to introduce fields or new mechanisms, it would be cleaner
<Marth64>
yes, i like that view. it becomes simple and you benefit from plumbing around avframe itself
<Marth64>
that is already there
<Marth64>
but i need to also learn in practice what is the challenges of doing that
<Marth64>
subtitles will become a problem with bluray so i will have to dig into it anyway
<Marth64>
forced subtitles in particular
<Marth64>
in ffmpeg we disposition the whole stream as forced/not-forced. in bluray its by frame. so how do you present this to the user is something i have to consider
<Marth64>
probably bsf
<JEEB>
for raw bit stream packet modification before decoding or whatever, it's bsf
<JEEB>
for forced subtitles you add a disposition flag or so
<JEEB>
(alternatively a side data entry but since we already have AVDispositions and forced etc there
<JEEB>
anyways lolsleep
<Lynne>
hypothetically, you'd have one sub2pix decoder for each stream
<Marth64>
ya probably one or more of those options since in bluray given subtitle stream X cannot be dispositioned upfront forced/not because the forced are a subset of the stream X tagged by frame
<Lynne>
and a hypothetical sub2video filter which takes in multiple subtitle video streams
<Marth64>
hmm
<Lynne>
and if any of the frames incoming have a forced flag, it overlays them unconditionally
<Marth64>
sorry Lynne, do you mean for burning them into the video via filter?
<Lynne>
yes
<Lynne>
well, no, actually
<Lynne>
the filter would output a constant video stream that you can overlay onto video
<Marth64>
got it. in demuxer I wouldn't have to decode them, but to have a better support for the bdsub format itself i get what you mean
<Lynne>
this can be done in the filter too, I don't mind either way
<Marth64>
in demuxer i would just expose them for what they are (hdmv_pgs_sub)
<Lynne>
I have no preference whether there's a decoder or a filter that does a sub2pix conversion
<Marth64>
hmm, the more we discuss, the more i think the support is already there
<Lynne>
just as long as at the end, API users can get three different versions they choose to do - text subtitles, picture subtitles (that would be just text subtitles converted to pictures), and a video stream
System_Error has quit [Remote host closed the connection]
<Marth64>
ah. you are talking about the subtitle filtering! my bad, i mixed up topics with bluray demuxer.
<Marth64>
understood
<Lynne>
the demuxer should always output what's natively supported
<Lynne>
*natively present in the stream
<Marth64>
yes, bluray demuxer i will do that. i will have to figure out a challenge with forced subtitles but i will deal with that in finishing touches phase
System_Error has joined #ffmpeg-devel
<Marth64>
which somehow ends up being the longest phase
<cone-416>
ffmpeg Michael Niedermayer master:d157725cf726: avformat/isom: Uninit layout in ff_mp4_read_dec_config_descr()
<cone-416>
ffmpeg James Almer master:50458b7fa1fc: avformat/isom: don't drop the known layout when parsing AAC decSpecificInfo
kurosu has quit [Quit: Connection closed for inactivity]