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
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 260 seconds]
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
Marth64 has quit [Quit: Leaving]
iive has quit [Quit: They came for me...]
mkver has quit [Ping timeout: 246 seconds]
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
arch1t3cht5 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 244 seconds]
arch1t3cht5 is now known as arch1t3cht
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
thilo has quit [Ping timeout: 265 seconds]
thilo has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
IndecisiveTurtle has quit [Quit: IndecisiveTurtle]
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
sunyuechi has joined #ffmpeg-devel
sunyuechi has quit [Remote host closed the connection]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 246 seconds]
<fflogger> [newticket] MasterQuestionable: Ticket #11334 ([trac] [Trac] Wiki content format regression) created https://trac.ffmpeg.org/ticket/11334
<fflogger> [editedticket] MasterQuestionable: Ticket #11334 ([trac] [Trac] Wiki content format regression) updated https://trac.ffmpeg.org/ticket/11334#comment:1
Teukka has quit [*.net *.split]
ocrete has quit [*.net *.split]
kasper93 has quit [*.net *.split]
acryo has quit [*.net *.split]
rajivharlalka1 has quit [*.net *.split]
uau has quit [*.net *.split]
bencoh has quit [*.net *.split]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 276 seconds]
^Neo has quit [Ping timeout: 248 seconds]
bencoh has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
Teukka has joined #ffmpeg-devel
kasper93 has joined #ffmpeg-devel
uau has joined #ffmpeg-devel
ocrete has joined #ffmpeg-devel
rajivharlalka1 has joined #ffmpeg-devel
acryo has joined #ffmpeg-devel
acryo has joined #ffmpeg-devel
jamrial has quit []
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 246 seconds]
aaabbb has quit [Changing host]
aaabbb has joined #ffmpeg-devel
cone-513 has joined #ffmpeg-devel
<cone-513> ffmpeg Zhao Zhili master:018ec4fe5f25: tests/checkasm: Simplify logic for WASI signal handling
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Read error: Connection reset by peer]
<fflogger> [editedticket] Balling: Ticket #11316 ([ffmpeg] DASH manifest generator: hevc codecstring is invalid) updated https://trac.ffmpeg.org/ticket/11316#comment:3
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 248 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
cone-513 has quit [Quit: transmission timeout]
zsoltiv_ has quit [Ping timeout: 252 seconds]
arbitercoin has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 264 seconds]
bilboed has quit [Quit: The Lounge - https://thelounge.chat]
bilboed has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 246 seconds]
Martchus_ has joined #ffmpeg-devel
<fflogger> [editedticket] lanczos-algorithm: Ticket #11317 ([avcodec] Can AVCodec provide more crop information when decoding via MediaCodec?) updated https://trac.ffmpeg.org/ticket/11317#comment:4
haihao has quit [Ping timeout: 260 seconds]
<Lynne> elenril: still trying to figure out why calling frame_params early causes a failure allocating after porting everything properly
haihao has joined #ffmpeg-devel
<Lynne> there should be no state at all being transferred over between params and init
mkver has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 248 seconds]
ngaullier has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<haasn> ramiro: yes, after discussion on IRC
<haasn> BBB: which patch?
ccawley2011_ has joined #ffmpeg-devel
Sean_McG has quit [Ping timeout: 260 seconds]
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 246 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 252 seconds]
ccawley2011 has quit [Ping timeout: 252 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 248 seconds]
jamrial has joined #ffmpeg-devel
<haasn> JEEB: derp, I did my previous benchmarks on a build with asm disabled
<haasn> frame= 2000 fps= 51 q=-0.0 Lsize=N/A time=00:00:46.04 bitrate=N/A speed=1.17x
<haasn> actual perf of 4K HLG -> SDR
<haasn> still way too slow on account of the unnecessary round trips
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 246 seconds]
<BBB> haasn: [PATCH v3 2/2] lavc/rv40dsp: fix RISC-V chroma_mc
<BBB> haasn: courmisch suggested there were pre-existing macros to make that less messy
s55 has quit [Quit: ZNC 1.9.0 - https://znc.in]
s55 has joined #ffmpeg-devel
<jamrial> haasn: fate-color_utils seems failing on aarch64 and win x86_32 with clang and gcc (curiously, not msvc)
<haasn> BBB: well what I can see is that we could use a macro like sx/lx to load the appropriate register size
<haasn> but I don't see them in lavu
<haasn> I think I added them only for dav1d
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
<haasn> oh they're defined in libavcodec/riscv/h264qpel_rvv.S
<haasn> should move them to avutil asm.S
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 260 seconds]
<haasn> jamrial: there's a patch on the ML that should hopefully fix this one as well
<haasn> seems my limits were not generous enough
<haasn> just floating point things
<BBB> haasn: tnx
<haasn> jamrial: you don't want to run for TC?
<fflogger> [editedticket] gegege: Ticket #11333 ([undetermined] Incomplete conversion of certain Apple H.265 MOV "hstack") updated https://trac.ffmpeg.org/ticket/11333#comment:6
<jamrial> haasn: no
<haasn> sad
ccawley2011 has joined #ffmpeg-devel
MyNetAz has quit [Read error: Connection reset by peer]
ccawley2011__ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
MyNetAz has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
Martchus_ has quit [Ping timeout: 248 seconds]
Sean_McG has joined #ffmpeg-devel
<thardin> there we go, finally got my avio wrapping thing to clean up nicely. but I needed to add a dummy URLProtocol that opens /dev/null. guess I should add a null protocol=
<thardin> no, better idea: add a way to specify a different close function for pb->opaque than ffurl_close()
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 248 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
<thardin> there we go, sanity
Martchus has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
Martchus_ has quit [Ping timeout: 248 seconds]
Martchus has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 260 seconds]
ccawley2011 has quit [Ping timeout: 252 seconds]
Martchus has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 276 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 265 seconds]
<Traneptora> haasn: do you have any plans for vf_colorspace
<Traneptora> which is a filter that does a lot of this stuff. possibly strip it and have it call swscale?
Marth64 has quit [Quit: Leaving]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 265 seconds]
<fflogger> [editedticket] MasterQuestionable: Ticket #11333 ([undetermined] Incomplete conversion of certain Apple H.265 MOV "hstack") updated https://trac.ffmpeg.org/ticket/11333#comment:7
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 246 seconds]
Marth64 has joined #ffmpeg-devel
<haasn> Traneptora: obsoleting it?
<haasn> Yeah
<haasn> Well we still need a dynamic peak detection shader
<haasn> Filter, rather
Traneptora has quit [Remote host closed the connection]
ngaullie has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
<Traneptora> haasn: probably should document that it's obsolete. can't just remove it cause spacebar heating but you can add deprecation warnings
<Traneptora> in offtopic news my X server crashed which I've never had happen before
<haasn> One step at a time
<haasn> But yeah I agree on principle
<haasn> Let’s let the new code settle a bit
<Traneptora> true, just wanted to point out the issue
<haasn> Probably it’s also way faster
<haasn> Technically you can’t replicate vf_colorspace using vf_scale
<haasn> Because it contains a very old algo
Traneptora has quit [Remote host closed the connection]
<haasn> 17:47 <haasn> Probably it’s also way faster <- to be clear, vf_scale is way faster
ngaullier has quit [Ping timeout: 248 seconds]
Traneptora has joined #ffmpeg-devel
Martchus has joined #ffmpeg-devel
<Traneptora> apparently if you run a parallel job on a batch image process thing that eats a ton of RAM, and oomkiller kicks in, instead of killing parallel, it'll kill Xorg
<Traneptora> for some reason
Martchus_ has quit [Ping timeout: 265 seconds]
<Traneptora> haasn: also question (I put this in the review email) but why von kries? the page you linked cites bradford as being the "best"
<Traneptora> that said, if you're starting in a D65 space and going to a different D65 space, does it matter if you roundtrip to D50
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 244 seconds]
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
ccawley2011_ has quit [Ping timeout: 248 seconds]
DEATH has quit [Ping timeout: 265 seconds]
DEATH has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 248 seconds]
Martchus_ has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 244 seconds]
ccawley2011 has quit [Ping timeout: 276 seconds]
Martchus_ has quit [Ping timeout: 244 seconds]
<haasn> Traneptora: it's a different one
<haasn> there are multiple "von Kries" methods
<haasn> iirc that's the general term for using a single 3x3 linear transform to get from XYZ to RGB
<haasn> (as opposed to a nonlinear transform like e.g. CIECAM02 uses)
<haasn> the matrix we use is taken from CAT16 and I recommend reading that document if you want to learn more
Martchus has joined #ffmpeg-devel
<Traneptora> I've read that page about white point adaptation a few months ago
<Traneptora> though I don't remember specifically all the details
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
ccawley2011_ has quit [Ping timeout: 244 seconds]
ngaullie has quit [Ping timeout: 244 seconds]
Martchus has joined #ffmpeg-devel
<haasn> Traneptora: we actually use d65 as standard
<haasn> not d50
<haasn> so most of the time this does not matter
<haasn> check the definition of rgb2lms
<haasn> IPT is defined on d65
ccawley2011 has quit [Ping timeout: 244 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 246 seconds]
<haasn> though apparently according to https://ntnuopen.ntnu.no/ntnu-xmlui/bitstream/handle/11250/2626317/CCIW-23.pdf?sequence=1 linearized Bradford outperforms CAT16
<haasn> hrm
<haasn> I just picked it because it was the newest CIE standard
<Traneptora> also as far as I understand this linear transform from gamut to gamut has to happen in linear light right
<haasn> then it backtracks and shows a table where CAT16 is the one with the best match to the perceptual data set
<haasn> yes
<haasn> anyway I'm sure it's fine and the differences are subtle
<Traneptora> how do we handle gamut mapping mode? as far as I understand the linear transform maps just treats out of gamut colors as-is (i.e. with float values out of [0.0, 1.0])
<Traneptora> or is that handled later on in the patch (I haven't reviewed the whole set yet)
<haasn> I decided to tie both tone and gamut mapping to a single ICC intent specification
<haasn> not sure what you mean by gamut mapping mode
<haasn> you mean the question of whether to gamut map in RGB or luma or whatever?
<BBB> "I'm told the FFMPEG nightly was the reason martial law was declared this week, how do you respond to these allegations?" omg twitter what
Martchus_ has quit [Ping timeout: 246 seconds]
Martchus has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 252 seconds]
ngaullie has joined #ffmpeg-devel
ngaullie has quit [Ping timeout: 248 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 265 seconds]
<welder> Hi, is there a guide on how to write a filter? I'd like to write an audio source reading from pipewire stream.
fflogger has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 248 seconds]
<another|> filter?
<welder> There's a patch, year old or so, where the reviewer suggested that instead of -f pipewire
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 244 seconds]
<another|> huh. TIL
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
<BtbN> What would the advantage of that be, over just interfacing with it via the PA api?
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
fflogger has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
<BtbN> jamrial: I have a super silly idea how to work around the alpha-encoding issue until Nvidia fixes it! call nvEncGetSequenceParam
<BtbN> Ex with a context for AVUY
<BtbN> But encode with one with ARGB
fflogger has quit [Ping timeout: 244 seconds]
Mirarora has joined #ffmpeg-devel
<welder> BtbN: when I'm using -f pulse last 2-3 seconds of audio are cut on every recording
<BtbN> Sounds like a bug somewhere, or just a config issue.
<jamrial> BtbN: devilish idea
<BtbN> I'm currently writing an E-Mail to the most recently active Nvidia people to ask about the situation
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 244 seconds]
rvalue- is now known as rvalue
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
Mirarora has joined #ffmpeg-devel
<BtbN> jamrial: for me, the trace headers output for rgb vs. vuya looks completely identical, minus matrix_coefficients being slightly different
<jamrial> BtbN: slice nalus with nuh_layer_id > 0 are skipped by cbs
<jamrial> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cbs_h2645.c;h=2de74691cb55657cdb1775905188c54247cf277d;hb=HEAD#l502
<jamrial> comment that out
<jamrial> you may get parsing errors, but at least see them printed
<BtbN> As in, the whole if? Or just remove the layer id check from it?
<jamrial> the whole if that can trigger the continue
arbitercoin has quit [Ping timeout: 252 seconds]
<BtbN> Even with that removed, I get 200 extra lines of stuff, but they're also 100% identical minus matrix_coefficients
<BtbN> And packet sizes
<jamrial> you don't see slices headers with nuh_layer_id 1?
<jamrial> depending on the input, you may only see one in the first packet
<BtbN> I do. But in both.
<jamrial> oh, huh
<jamrial> i was sure last night that i only saw them if i used rgba but not vuya
<BtbN> I just installed a driver update from yesterday
<BtbN> Would be ironic if that happened to fix it lol
<jamrial> oh, i saw it but didn't bother to install it
<BtbN> Nothing about it in the changelog at least. So I doubt it
<BtbN> I do see an "Alpha Channel Information" section in both as well
<jamrial> yeah, the sei
<jamrial> ok, tried again, with vuya i don't see slices for the alpha channel, only the sps/pps and the sei
<BtbN> That's the trace header output I get
<BtbN> There is sps/pps for both layers, and a bunch of Slice Segment Headers for either ids as well
<BtbN> https://btbn.de/files/out3.mp4 that's the resulting file
fflogger has joined #ffmpeg-devel
<jamrial> BtbN: fwiw, after the nvEncGetSequenceParams() issue is fixed, the mov muxer needs to be updated to actually include the layer > 0 parameter set nalus in hvcC
<BtbN> oh, that strips those too?
<BtbN> There's people who reported successfully remuxing the apple provided hevc alpha sample with ffmpeg
<jamrial> it's a bit annoying because the L-HEVC in ISOBMFF spec expects all nuh_layer_id > 0 NALUs to be in a separate box called lhvC
<jamrial> for things like multivier/stereo
<jamrial> but apple's alpha spec just puts them in hvcC
<BtbN> so the muxer would somehow need to differentiate those, hm
<jamrial> right now it looks for the MULTIVIEW stream disposition
<BtbN> libx265 alpha channel support also looks like a hot mess to add
<BtbN> mostly for lack of documentation on how to actually use it
<BtbN> hm, at least from a quick looks, it should be fine? Nothing would set AV_DISPOSITION_MULTILAYER, so it should just write it with mov_write_hvcc_tag
<jamrial> yes, which skips the higher layer nalus
<jamrial> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/hevc.c;h=7cf0b0ffb214c1dadc432653ce30669c45534584;hb=HEAD#l765
<BtbN> So it would _somehow_ need to keep trac of the layer 1 being an Alpha layer, and if so, don't stop there. Hm
<jamrial> BtbN: if the sps/pps have no actual information about them being for an alpha layer (which we could parse in lavf), then i guess we'll need something like the multiview disposition to signal this
<BtbN> The main sps/pps set has information that other set is for an alpha layer
<BtbN> But I don't immediately see anything in the sps/pps itself indicating that it itself is for an alpha layer
<fflogger> [newticket] mibby: Ticket #11335 ([avutil] av_log callback called with bad parameters (NULL AVClass)) created https://trac.ffmpeg.org/ticket/11335
<fflogger> [editedticket] Mista_D: Ticket #11331 ([avcodec] X265 HEVC Alpha transparency support) updated https://trac.ffmpeg.org/ticket/11331#comment:5
Everything has joined #ffmpeg-devel
wyatt8740 has joined #ffmpeg-devel
wyatt8750 has quit [Ping timeout: 276 seconds]
<jamrial> BtbN: ok so, we can know if a layer is alpha by looking at the VPS. it should report scalabilityid 3 (auxiliary) and auxid[layer 1] = 1 (AUX_ALPHA)
<jamrial> or so
<BtbN> Yeah, I'm looking at it right now. It's a bit annoying, since A TON of vps parsing needs to be added to hevc.c in avformat
<BtbN> And I can't look at the spec, since it's unavailable
<BtbN> so need to convert the cbs syntax template
<jamrial> h265 is public
<BtbN> Then google sucks at finding it
<BtbN> The cbs template would be fine, if I'd know what all the abbreviations mean
<BtbN> like, what's the difference between ue() and ues()?
<jamrial> cbs doesn't parse the VPS extension, though
<BtbN> It doesn't, but it parses everything up to it
<BtbN> And that needs to be all skipped first
<jamrial> ue() is a single unsigned golomb value, ues() is several indexed ones
<BtbN> So that's just syntactical sugar for the template, and I can just use get_ue_golomb() to skip both kinds?
<jamrial> yeah
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
Mirarora has joined #ffmpeg-devel
Everything has quit [Quit: Lost terminal]
<BtbN> my god, why is this burried behind so much shit
<sfan5> when will ffmpeg switch to gitlab
<BtbN> probably never
<BtbN> forgejo looks more likely at the moment
ccawley2011 has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
iive has joined #ffmpeg-devel
mkver has quit [Ping timeout: 248 seconds]
<fflogger> [editedticket] Balling: Ticket #11307 ([avcodec] [truehd_core] Application provided invalid, non monotonically increasing dts to muxer in stream 0) updated https://trac.ffmpeg.org/ticket/11307#comment:7
<sfan5> BtbN: I'm happy as long as I don't need to send an email with a patch anymore
<BtbN> Start a vote on the ML then
<jamrial> BtbN: why does forgejo look more likely?
<BtbN> With Fedora having evaluated Gitlab vs. Forgejo lately, and the entire paper they wrote about it, it has one very strong Argument on its side
<BtbN> Well, tons of arguments rather, all neatly written up
<jamrial> sad, because there's a gitlab instance in videolan already we can reliably use with very little work
<BtbN> It seems less likely for that to happen
<BtbN> The vote would basically be Forgejo, Gitlab, Videolan-Gitlab and keep things as they are.
<fflogger> [editedticket] Balling: Ticket #11014 ([undetermined] ac3 demux and/or decode problem) updated https://trac.ffmpeg.org/ticket/11014#comment:3
<BBB> I've never heard of forgejo
<fflogger> [editedticket] Balling: Ticket #6207 ([avformat] Wrong mkv codec ID for ac3 with bitstream_id > 8) updated https://trac.ffmpeg.org/ticket/6207#comment:3
Marth64 has quit [Quit: Leaving]
<BtbN> no, there was a whole analysis they posted somewhere
<BtbN> hmm, I'm getting data that seems sensible but also does not make sense for my attempt at parsing the vps extension
<BtbN> https://bpa.st/65MQ Why is there a flag 11? That's listed as reserved.
<BtbN> Makes me think the bitreader is misaligned. But everything else seems to reasonably align
<jamrial> BtbN: scalability_mask_flag should be read one bit at a time
<BtbN> It is, I just transformed it into a more useable array