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
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #ffmpeg-devel
aaabbb has quit [Remote host closed the connection]
thilo has quit [Ping timeout: 264 seconds]
thilo has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
cone-331 has joined #ffmpeg-devel
<cone-331>
ffmpeg Haihao Xiang master:d296c8689d48: lavu/hwcontext_vulkan: check PCI ID if possible
elenril has quit [Ping timeout: 255 seconds]
mkver has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
aaabbb_ has joined #ffmpeg-devel
aaabbb_ has quit [Quit: leaving]
SystemError has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
elenril has joined #ffmpeg-devel
SystemError has joined #ffmpeg-devel
<cone-331>
ffmpeg Andreas Rheinhardt master:103965053bb7: avformat/aeadec: Export title
<cone-331>
ffmpeg Andreas Rheinhardt master:7e41a658f531: avformat/aeadec: Use sample rate as time base
SystemError has quit [Remote host closed the connection]
<rajivharlalka>
AH GEN=1 solved the issue
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
cone-184 has joined #ffmpeg-devel
<cone-184>
ffmpeg Wenbin Chen master:f4e0664fd1bc: libavfi/dnn: add LibTorch as one of DNN backend
pmozil has joined #ffmpeg-devel
pmozil has quit [Client Quit]
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
devinheitmueller has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 255 seconds]
Marth64 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<Traneptora>
TIL about GEN=1, I've been doing things the hard way
<JEEB>
glad that brings ease to people :)
<jamrial>
Traneptora: you're not the first. someone once wrote a patch to do the same thing as GEN=1 but for a single module :p
microchip__ has joined #ffmpeg-devel
pmozil has joined #ffmpeg-devel
pmozil has quit [Client Quit]
microchip_ has quit [Ping timeout: 260 seconds]
Marth64 has quit [Ping timeout: 260 seconds]
microchip__ is now known as microchip_
MrZeus has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
cone-184 has quit [Quit: transmission timeout]
jamrial has quit [Ping timeout: 240 seconds]
<Traneptora>
haha
jamrial has joined #ffmpeg-devel
<jamrial>
elenril: looks like "./ffmpeg -autorotate 0 -i INPUT" is broken
<jamrial>
works on 6.1
<JEEB>
I think it was made specifically now to only work with -no prefix?
<haasn>
do we have a policy or precedent for changing the semantics of frame side data?
<JEEB>
since it was the only option supporting the 0 syntax or something
<jamrial>
oh, could be
<haasn>
I want to refactor the way DOVI_RPU_BUFFER works
<jamrial>
so no more 0or 1 bool argument?
<jamrial>
haasn: you probably need to introduce a side data type and deprecate the old one (if it's no longer useful)
<JEEB>
regarding that buffer thing you probably want to discuss it with Daemon404 since IIRC he added it originally?
<JEEB>
and thus he probably has code utilizing it atm
<JEEB>
(I have a hunch what you want to do and I'm pretty sure he's interested in something like that, too)
<haasn>
heh
<jamrial>
JEEB: haasn added it, afaik
<JEEB>
I recall dae writing some of the parsing code to get the buffer from after the VCL NAL
<JEEB>
since for whatever awful reason it's there beyond the VCL
<haasn>
jamrial: no, I added the parsed version (DOVI_METADATA)
<JEEB>
yea
<jamrial>
ah
<haasn>
what I want to do is change it from storing the raw NAL (with emulation bytes intact) and instead store just the dovi RPU payload
<haasn>
because AV1 doesn't use NALs, it wraps the RPU inside an EMDF container
<JEEB>
yea since that way it can be reused between AV1 and HEVC/H.264
<haasn>
exactly
<haasn>
alternatively
<haasn>
the first byte unambiguously identifies it as either NAL-type or OBU-type
<haasn>
so we could just say that this can either be a raw NAL (with emulation bytes intact) or an AV1 OBU, but then conversion would still be awkward
<JEEB>
doesn't sound too great
<JEEB>
did the side data type only have the pointer?
<haasn>
yeah, it's just raw byte data
<haasn>
hrm
<haasn>
in any case, we might need to also move it from frame-level to packet level so we can inject it at the bitstream filter level
cone-655 has joined #ffmpeg-devel
<cone-655>
ffmpeg James Almer master:61519cc6546d: avcodec/libdav1d: use named constants for ITU-T T.35 metadata
<cone-655>
ffmpeg James Almer master:4ca5d451933f: avcodec/av1dec: use named constants for ITU-T T.35 metadata
<cone-655>
ffmpeg James Almer master:53dd31497b45: avformat/matroska: use named constants for ITU-T T.35 metadata
<cone-655>
ffmpeg James Almer master:a1f714d197bf: avcodec/h2645_sei: use named constants for ITU-T T.35 metadata
<jamrial>
in that case it should not have codec specific encapsulation
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
<Daemon404>
haasn, apis expect emulation bytes for hevc rpus
<Daemon404>
all of them o
<Daemon404>
do*
<haasn>
which APIs?
<Daemon404>
x265 for one
<haasn>
ah
<Daemon404>
also i need it at frame level
<Daemon404>
be because encoder apis expect rpus to be attached to input frames
<Daemon404>
(read: non-reordered)
<haasn>
right
<haasn>
I was just thinking that we could somehow inject them in a bsf but I guess bitstream filters may see multiple frames (and out of order)
<Daemon404>
yeah
<haasn>
so probably it needs to be done in the encoder directly
<Daemon404>
likely
<Daemon404>
time to add dv to aom?
* Daemon404
runs
<haasn>
I mean it's just T.35 metadata
<Daemon404>
i know
<haasn>
if aom doesn't have the ability to attach arbitrary T.35 metadata I'd be shocked
<Daemon404>
rav1e can already do it
<Daemon404>
not sure about aom
<Daemon404>
it must..because hdr10+
<haasn>
Daemon404: would you say we should, when decoding AV1, rewrap the T.35 into HEVC form? (and then unwrap back into AV1 when encoding to AV1)
<haasn>
IMO it seems more elegant to have the frame side data live in codec agnostic (decoded) form, and transfer between it and NAL encoded form when encoding/decoding from HEVC
<haasn>
(ditto T.35 OBU form for AV1)
<Daemon404>
hmm
<Daemon404>
wed have to inspectt all t35 and determine when it is na rpu
<haasn>
actually my initial idea was to directly synthesize the dovi rpu from the decoded dovi_metadata, but our current lack of knowledge about extension blocks kills this idea
<Daemon404>
kinda gross
<Daemon404>
(lso brb Work Meetin :()
<haasn>
we already inspect all t35 on decode, av1dec.c/libdav1d.c currently just pass this metadata to ff_dovi_rpu_parse
<haasn>
I'm suggesting we also attach it as DOVI_RPU_BUFFER side data but that would require conversion to NAL form
<jamrial>
why did dolby hijack a nal value if ultimately they'd end up doing it the right way through t35 metadata for av1?
<jamrial>
same with truehd in mp4. come up with a hack for 32 bits sample rate when the mp4 spec already had a box for it
rajivharlalka has quit [Quit: Connection closed for inactivity]
<Daemon404>
jamrial, because fuck you
<Daemon404>
no really
<Daemon404>
thats why
<jamrial>
the multimedia way
<Daemon404>
(i am not joking)
<Daemon404>
lterally to make it hard
<JEEB>
re: MLP in MP4, I wonder which 3rd party demuxers could be used to verify that to finally get it out of the whole flag being required for it
<haasn>
Daemon404: how do you preserve the dovi configuration record? it doesn't survive decode->encode since it's attached to the packet level only; I was thinking that we could maybe move AVDOVIDecoderConfigurationRecord to AVCodecContext
<haasn>
oh, we already have coded_side_data, right
<haasn>
that would be the perfect place to preserve it
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
ryanmcc has quit [Ping timeout: 252 seconds]
qeed has joined #ffmpeg-devel
qeed has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
ryanmcc has joined #ffmpeg-devel
ryanmcc has quit [Remote host closed the connection]
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
<jamrial>
haasn: demuxers already put it there
<jamrial>
and not in packets
rajivharlalka has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
MrZeus_ has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 272 seconds]
MrZeus__ has joined #ffmpeg-devel
MrZeus__ has quit [Read error: Connection reset by peer]
MrZeus_ has quit [Ping timeout: 272 seconds]
MrZeus has joined #ffmpeg-devel
<kierank>
jamrial: why are you including a closed source library in ffmpeg
<kierank>
This software is protected by copyrights and other intellectual property rights and no license is granted to any such rights. If you would like to obtain a license to compile, distribute, or make any other use of this software, please contact V-Nova Limited info@v-nova.com.
<JEEB>
lul
<jamrial>
kierank: so it's not ok for upstream even with nonfree?
<kierank>
do we really want this nonfree crap
<JEEB>
we are trying to not include nonfree stuff
<kierank>
do we do dolby blob next?
<jamrial>
this is not a blob
<JEEB>
we already see how messy it gets with stuff like fdk-aac
<kierank>
jamrial: it has no licence
<kierank>
"no license is granted to any such rights"
<kierank>
it is a de facto blob
<JEEB>
people will end up doing enable-nonfree builds or just blindly learning that it's an option that you "need" to enable
<JEEB>
yea
<JEEB>
that license giving you no rights to compile, distribute or make any other use
devinheitmueller has quit [Ping timeout: 256 seconds]
<JEEB>
it's one of those "you can look but you can't use" github repos
<Daemon404>
nonfree is one thing
<Daemon404>
you cant even compile this without a license
<JEEB>
yea
<Daemon404>
that shouldnt be in ffmpeg
<Daemon404>
guido can fuck himself
<Daemon404>
if you pardon my french
<jamrial>
guido?
<Daemon404>
vnova asshole
<jamrial>
oh
<Daemon404>
i hope you had a license when developing it ;)
<Daemon404>
otherwise you can be sued
<Daemon404>
anything ffmpeg supports should, at a bare minimum, be /usable/ without a license
<Daemon404>
nonfree refers to distribution only
<JEEB>
yea
<JEEB>
as I said, it's a look-only thing looking at that documentation
<JEEB>
that kierank quoted
<JEEB>
given that even video coding stuff is standard BSD now, that stuff is quite something :)
<jamrial>
then what's the point making it public?
<JEEB>
PR
<JEEB>
"it's on github"
<Sean_McG>
what JEEB said
<Daemon404>
yep
<JEEB>
and people who don't check can get told that hey, we open sourced it
<Daemon404>
markeing bs
<Daemon404>
vnova == marketing company
<kierank>
JEEB: exactly
j45_ has joined #ffmpeg-devel
<JEEB>
thankfully LC-EVC has a spec so if someone really cares about it, they could just have an implementation written
AbleBacon has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
j45_ is now known as j45
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
<nevcairiel>
and get sued for patent infringement? :D
<JEEB>
I only considered the open source licensing bits :P
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
<Daemon404>
luckily noone cares about lcevc
<Daemon404>
other than who guido has sold to
<Daemon404>
"looks it is in ffmpeg" is very appealing to vnova
<JEEB>
but honestly you don't even have to go that far. just the crap licensing situation means that it's a no-go.
<jkqxz>
I'm hopeful that vnova will collapse at some point soon so that they shut up about LCEVC. Their company accounts do rather suggest that they are fucked, but equally someone has kept putting more money into it for years despite no revenue.
<JEEB>
:D
Krowl has joined #ffmpeg-devel
<kurosu>
Daemon404: correction, other than who guido has paid to care about lcevc
<Daemon404>
kurosu, haha
<kurosu>
example: companies whose software would output it
<kurosu>
there are more than 2 of them
<kurosu>
I can't get over how the justification (RfE) for making it an ISO standard has been, by exaggeration, the Mafia
kasper93_ has joined #ffmpeg-devel
<kierank>
how
<kurosu>
I'll just try to find again the RfE
Traneptora has quit [Quit: Quit]
kasper93 has quit [Ping timeout: 268 seconds]
<Daemon404>
kurosu, iso stooped to smpte levels of dignity
<Lynne>
mips access received, just needed to wait a few more hours, now I can test if it runs
<JEEB>
has smpte finally published the IPTv2 spec yet? :D
<JEEB>
Lynne: nice. hopefully it's some better hardware than my router that is locked down
<haasn>
do we have an equivalent of memcpy for non-byte-aligned data?
<haasn>
specifically, I need to copy ~300 bytes of byte-aligned data into a non-byte-aligned position in another buffer (or PutBitContext)
<haasn>
oh, I'm blind, ff_copy_bits
MrZeus has quit [Read error: Connection reset by peer]
<j-b>
I thought that LC-EVC fixed their license. I'll ping them for this
<JEEB>
yea if you care about it, it's still a no-go :)
<JEEB>
both readme and copying have the lulzy license
<j-b>
I do care about all formats, as usual.
<j-b>
Like EVC which is DoA or others
<JEEB>
sure.
<j-b>
but I'd prefer a native implem.
<JEEB>
I think it was more towards their specific implementation than the format itself - after all, it's a spec so one could implement it
<Daemon404>
nobody is going to do a native impl
<JEEB>
(and thus you don't have to care whether that company does proper open source or not)
<Marth64>
i tested ~170 samples the past few days from my dvr and all were ok. fingers crossed
<Marth64>
(via script, i admit. but i did not observe any warnings and spot checked bunch of outputs, all looked sane)
<Marth64>
i will focus next week to add tests on cc stuff
Traneptora has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 256 seconds]
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
<haasn>
Daemon404: do you have code you can share for how to attach the dovi rpu nal to libx265?
<haasn>
I imagine it's not more than one or two lines?
<JEEB>
see x265.h
<JEEB>
there's a x265_dolby_vision_rpu rpu;
<JEEB>
in a struct of the frame, most likely
<JEEB>
yea, x265_picture has rpu member
<haasn>
oh indeed
<JEEB>
and rpu has size and payload pointer
<haasn>
how nice of them
<galad>
yes, just set the rpu in x265_picture
<Daemon404>
haasn, set pic.rpu.{payload,payloadSize}
<Daemon404>
you also need to set the dolby vision version
<Daemon404>
(dolby-vision-profile x265 param)
<Daemon404>
and color props obv
<galad>
and hope the following rpu are not larger than the first, because x265 won't resize its internal buffer
<Daemon404>
x265 being bad at memory?
<Daemon404>
shocking news
<JEEB>
I ran it under valgrind, that was fun
<Daemon404>
we have x265.supp for valgrind in CI
<galad>
I even sent a patch to fix a bunch of things to x265-devel some time ago, no one replied, oh well
<Daemon404>
its dead more or less
<Daemon404>
luckily so is hevc
<JEEB>
elenril, jamrial - at this point I think the only question left is whether the counter should be unsigned or signed. :P (looking at nb_side_data_prefer_packet probably unsigned?) otherwise I hope v10 is good enough for both of you (the function that jamrial requested can be skipped - just wanted to make sure it was still part of the branch in case jamrial wants to further proceed with it later)
<JEEB>
galad: it seems like they do take in merge requests since I saw merge commits in the history
<Daemon404>
it took them months to merge my dv 8.4 patch
<galad>
they post their own patch on the mailing list before merging them, but I think you either have to know someone directly to ping, or you will be ignored
<Daemon404>
i just kept replying and pinging
<Sean_McG>
heh, merging patches -- I sent a patch to libsmb2 that took them 2 years to even look at
<Daemon404>
i have been trained to ping by GNU mailing lists in my past
<Daemon404>
x265 list looks active by comparison
<JEEB>
yea
<another|>
jkqxz: where are you grepping that account info from? companies house?
<haasn>
Daemon404: huh, even without setting that property I still seem to generate working dovi streams by just attaching the RPU to frames
<JEEB>
good
<Daemon404>
haasn, it just enforces some stuff like color props iirc
<JEEB>
esp. since I think in the future the color props stuff will change as the best practice will probably switch to IPTv2 flag
<JEEB>
(why would they otherwise standardize it)
<another|>
jeeebus! How much money do they have to be bleeding 7 digits per year?
<Marth64>
(ideally) would be nice if rcwt demuxer can get in too, since the muxer is already there, they can go together...it's quite small and got 1 lgtm
<Marth64>
only feedback from last review was documentatino updates
<Marth64>
but this is in the grand scheme a small/irrelevant demuxer probably
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
<cone-735>
ffmpeg Marton Balint release/5.1:b0c647d1d921: avformat/mxfdec: move resolving Descriptors to the multi descriptor resolve function
<cone-735>
ffmpeg Marton Balint release/5.1:68f0e9645d68: avformat/mxfdec: do not use AnyType when resolving Descriptors and MultipleDescriptors
<cone-735>
ffmpeg Marton Balint release/5.1:995e7f43a7a2: avformat/libsrt: use SRT_EPOLL_IN for waiting for an incoming connection
<michaelni>
haasn, is it still blocking ? if not why is the ticket saying its still blocking ?
<j-b>
"Sent a patch to the ML that switches this filter to ff_framesync_activate, solving this and related issues concerning this filter." What this merge?
<j-b>
+D
derpydoo has quit [Ping timeout: 260 seconds]
<Marth64>
michaelni: how to build probetest? (thanks for the review--working on it now and have a solution in mind)
<michaelni>
Marth64, make tools/probetest
<Marth64>
thank you
<michaelni>
np
<JEEB>
trying to look if I should int -> unsigned int the new nb_side_data since the last nb_xyz added was unsigned, and if you have something using another structure which still has int counter and underneath you're now using uint, should you just add a av_assert0(nb_xyz >= 0); ?
<JEEB>
(example being that AVFrame has a signed counter, while now the underlying logic would be dealing with unsigneds in this case)
<JEEB>
previously for (i = 0; i < -1337; i++) would have just done the same as nb_xyz being 0
<JEEB>
so should I emulate that with nb_xyz >= 0 ? nb_xyz : 0, or assert?
<JEEB>
I would myself probably prefer asserting since the negative number is most likely a boog somewhere
___nick___ has quit [Ping timeout: 240 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 272 seconds]
<Marth64>
michaelni: should be ok now in v6. thanks
<Marth64>
neat tool
<haasn>
j-b: no, not yet; I'm not happy with the patch as-is
<jamrial>
JEEB: imo leave it signed. same as frame side data, packet side data, and avctx->coded_side_data
<haasn>
michaelni: it probably shouldn't be blocking anymore
<Lynne>
oh no... mips float code doesn't even compile!
<haasn>
cc elenril
<JEEB>
jamrial: yea that seems to be the less problematic thing. since you *will* be feeding the AVFrame values into the functions
<JEEB>
even if it feels more correc to have all new nb_xyzs as uint
<JEEB>
*correct
qeed has quit [Quit: Leaving]
<JEEB>
because when you internally go from AVFrame to plain arrays, you can attempt to av_assert0 the count. buuut if your interface is just the counter :D
<JEEB>
also unsigned means that if you iterate from end I guess `i = nb_xyz -1; i < UINT_MAX; i--` ends up being the for loop logic :D
<JEEB>
so yea, that was an attempt but I do tend to agree. we have signeds in other AVFrameSideData arrays
<JEEB>
like in AVFrames
<JEEB>
so it becomes awkward to handle that signed -> unsigned function border when it's in the API user's side
<JEEB>
when it's you -> you, there's no problemo, you assert or silently set to zero
<BtbN>
Does someone have access to a windows-on-arm thingy?
<jamrial>
BtbN: maybe wbs
qeed has joined #ffmpeg-devel
<JEEB>
I think wbs has those, you'll probably catch him during better EU hours :)
<jamrial>
it's always morning on IRC
<JEEB>
8)
<JEEB>
jamrial: anyways, then nothing from my side wrt v10 of that set
<Marth64>
missed by 2 days, I was repairing an arm surface few days ago ;-;
<JEEB>
I think aarch64 win10/11 does run on various boards
<BtbN>
Yeah, any of them. Just would like something to test on
<JEEB>
officially they only support specific ones, but people have poked into it methinks?
<JEEB>
anyways ya, I think that would be fundable
<JEEB>
unless j-b or someone already has something like that in their closet
<JEEB>
I know we have FATE running on some of wbs's boxes
<BtbN>
In theory also an Azure VM, but that'd be a recurring cost, not sure how to fund that
<Marth64>
I am planning to go to a second-hand store this week to donate all the DVD players and junk I picked up last year writing the demuxer, I used to see surfaces there all the time. I'll let you know if I see one. Could be the difference between $20 and $x00
<Marth64>
ARM surfaces aplenty here from people that moved on
<BtbN>
Not sure if shipping that from the US(?) is worth it
<Marth64>
Is it a node I can run here?
<BtbN>
I mean the surfaces
<BtbN>
I guess you could use a Surface as Fate node, hm
<Marth64>
yeah if I find one I don't mind
<Marth64>
but I understand wanting a dedicated one for your work
<BtbN>
It's a lot more annoying to share a Windows-Box than Linux
<Marth64>
just realized it won't work anyway, the surface I'm thinking of is 32-bit arm from 2015
<BtbN>
The annoying thing is, searching for that stuff is hard
<BtbN>
Amazon and google just keep showing me literal arms to put a laptop on
<jkqxz>
IMO ffmpeg funding a WoA dev kit box would be a good idea if someone could host it.
<jkqxz>
Though apparently the WoA qualcomm exclusive expires at some point about now, so maybe there will be good replacements for cheap soon (with your favourite mediatek soc).
<jkqxz>
Yeah, you do want "proper" windows here, not IoT.
<JEEB>
yup
<BtbN>
People have gotten Win 11 to run on a RPi5
<BtbN>
that would be an interesting option
<Marth64>
can it be installed on a chromebook? (half joking but half serious)
<JEEB>
yea, that is why I expected there to be similar stuff for pine64
<JEEB>
or other mediatek etc things
<Marth64>
I can imagine lot of licensing headaches unless it comes pre-installed on the machine unfortunately
<JEEB>
you can run without a license within certain limitations
<JEEB>
even with normal windows; just don't input a serial
<Marth64>
hmmm yeah you get like 30 days or something I guess
<BtbN>
You can use Windows without activation virtually forever
<BtbN>
If you are fine with the watermark
<JEEB>
yea
<jkqxz>
Marth64: ARM chromebooks are all mediatek, I think.
<JEEB>
I guess it was rockchip and mediatek which are the non-broadcom, non-qualcomm things
<jkqxz>
Oh, there have been qualcomm ones, so maybe?
<Marth64>
BtbN/JEEB: wow I am behind the times on that, good to know :D
<jkqxz>
SavedOrderHints is a two-dimensional array which you would need cbs to fill in.
<jkqxz>
The per-reference part would take one row of that array.
qeed has quit [Quit: Leaving]
<jkqxz>
And you do need it, it gets used in the MV projection for TMVP.
<jkqxz>
A driver could maintain that state internally to not take it from the user (and I bet some will), but the intent of Vulkan is that it shouldn't need to do that.
Marth64 has quit [Remote host closed the connection]
<jkqxz>
(For frame A with a reference frame B you need to know the offset from B to each possible reference C in order to project each block reference C->B to how it would look on B->A.)
jarthur has quit [Ping timeout: 240 seconds]
jamrial_ has joined #ffmpeg-devel
<Lynne>
jkqxz: do you think you could write that bit?
<Lynne>
according to nvidia, savedorderhints for each reference (they're only used for references) is the order hints from when the reference was decoded