tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
<elenril>
sure
<wbs>
thanks!
<cone-109>
ffmpeg Martin Storsjö master:ff5a3575fec2: fftools: Check HAVE_GETSTDHANDLE before using GetStdHandle
<durandal_1707>
thardin: once there are eigenvectors, how to get actual coefficients to transform input channel(s)?
mkver has joined #ffmpeg-devel
dellas has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
<BBB>
elenril: maybe because some of the values are constant, like sps/pps, so signaling them as part of bitstream is a bit weird since it suggests they could change, which they can't?
<elenril>
not what we're talking about
Krowl has quit [Read error: Connection reset by peer]
<elenril>
also, sps/pps are very much non-constant
<JEEB>
yea, in a live stream they can change
navi has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
Traneptora has joined #ffmpeg-devel
wangbin has quit [Quit: Connection closed]
Krowl has joined #ffmpeg-devel
psilokos__ is now known as psilokos_
dellas has quit [Read error: Connection reset by peer]
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
dellas has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
Traneptora has quit [Remote host closed the connection]
Traneptora has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
<Lynne>
elenril: it's not exactly the same thing, you need all of them to be able to express how many samples to skip
Traneptora has joined #ffmpeg-devel
<Lynne>
toggle two of them for container/raw container, another one for any latency the decoder adds itself and a custom one by the user, all 3 added together
Traneptora has quit [Remote host closed the connection]
Traneptora has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Traneptora has quit [Remote host closed the connection]
<elenril>
why would the decoder layer care about the difference
Traneptora has joined #ffmpeg-devel
Traneptora has quit [Remote host closed the connection]
Traneptora has joined #ffmpeg-devel
<Lynne>
decode.c or the decoder itself?
<elenril>
anything in lavc
SystemError has quit [Remote host closed the connection]
<Lynne>
err, I don't get the question?
<elenril>
from a decoder PoV, there is zero difference between container and "user" skipped samples
SystemError has joined #ffmpeg-devel
<elenril>
the decoder can just choose to add its own value to what the caller sends in
<BtbN>
Is BGR0 actually cool with the Alpha-Channel not actually being 0?
<BtbN>
That's the main reason it's BGRA right now
cone-109 has quit [Quit: transmission timeout]
Krowl has joined #ffmpeg-devel
<Lynne>
elenril: I'm not seeing the avframe contain side data in decoders though, it's only there if there's container side data
<elenril>
so?
user23 has joined #ffmpeg-devel
<Lynne>
to modify side data there has to be side data
dionisis has quit [Quit: WeeChat 3.8]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
<elenril>
create it if it does not exist
<Lynne>
how would it interact with skip_samples? override it?
<elenril>
kill skip_samples entirely
<elenril>
my point is that it does not need to exist
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
<Lynne>
fair enough
<Lynne>
I can get behind that
<Lynne>
how would global side data fit into all of this?
<Lynne>
it doesn't sound very robust or elegant to have decoders only insert data after seeks/init, nor efficient to allocate side data on every frame
<elenril>
why would you need to skip samples after every frame
dellas has quit [Remote host closed the connection]
<Lynne>
you wouldn't
<Lynne>
which is why I wouldn't want to use the frame side data, but the global side data
<elenril>
I don't follow
<elenril>
no samples to skip -> don't set side data
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
that would mean the decoder would need to decide when to skip
<Lynne>
so you'd need state to check if it gets flushed/init'd
<Lynne>
I think it would be better for the shared decoder wrapper code to do that, rather than having that in each decoder
<elenril>
i still don't see what the problem is
<elenril>
before: you fiddle with AVCodecInternal.skip_samples
<elenril>
after: you call a decode.c function and give it the number you'd previously put in skip_samples
<elenril>
this function looks at side data - if it exists it increments it by the sample count you gave it
<elenril>
otherwise it creates new side data
<Lynne>
right, but that function would change the side data in the avframe, so it needs to be called on a per-frame basis
<Lynne>
if there isn't side data, it would put it on every frame, so it needs to know when to put side data
<Lynne>
so it would need some state to track flushing
dellas has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
TheSashmo has joined #ffmpeg-devel
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
<elenril>
how does the decoder know now?
<elenril>
skip_samples is also per-frame
<Lynne>
the decoder doesn't deal with it, it sets skip_samples on init and lets decode.c handle it
<elenril>
that does not handle flushing though, does it?
<Lynne>
it doesn't?
<Lynne>
if so, worse than I thought
<elenril>
IIRC the code in decode.c substracts what it drops from skip_samples
<elenril>
once it reaches zero it's done, if nothing sets it again
<thardin>
durandal_1707: the eigenvectors are your transform
<durandal_1707>
thardin: but they are 0.707 .. not very useful
<durandal_1707>
when i expect 1 -1 0.5 0.5
AbleBacon has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 245 seconds]
SystemError has quit [Ping timeout: 256 seconds]
MrZeus_ has joined #ffmpeg-devel
<thardin>
just scale them
<durandal_1707>
scaling with scalar can not give correct results
MrZeus__ has joined #ffmpeg-devel
SystemError has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 245 seconds]
<durandal_1707>
michaelni: if your hacks cause regression i will revert them
thilo has quit [Ping timeout: 260 seconds]
<jamrial>
durandal_1707: could start by fixing the issues you introduce first :p
Krowl has quit [Read error: Connection reset by peer]
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
<durandal_1707>
jamrial: could start fixing posproc/sws/swr/sonic/etc
<durandal_1707>
i introduced no bugs
<durandal_1707>
coode iis bug free
<jamrial>
no code is bug free
<jamrial>
but code sent for reviewing instead of being pushed with no warning is bug free-er
<durandal_1707>
not true
user23 has quit [Ping timeout: 248 seconds]
user23 has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 255 seconds]
MrZeus_ has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 255 seconds]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
<Lynne>
elenril: opinion on having a function in decode.c that decoders call when they need to skip something?
<Lynne>
so they'll call it at init and during flush
<Lynne>
the next frame to be output will be trimmed
* microchip_
farts at durandal_1707
<Lynne>
it gets ugly with frame threaded audio decoders, but they'll never want to skip anything
* durandal_1707
stabs microchip_
<microchip_>
oi
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
<kurosu>
michaelni: durandal_1707: iirc, the jitter thing is because symbol 255 can effectively be -1, and you'd do only half the shorter codes. Building these tables is slow (up to 6 levels), and I think that helped. Not sure this rationale was in a separate commit for that particular point
<michaelni>
kurosu, do you have a testcase where the jitter loop made a difference ? and or a testcase where building the table is slow ?
<kurosu>
The commit is from 3 years ago, but more like 7 in fact, so no. Maybe huffyuvdec in both cases
<kurosu>
At least in the history of that branch, I was porting that decoder to the API of that branch
<kurosu>
I think I used a clean video, then the same with some noise to have a slightly "flatter" bitlength distribution
<michaelni>
i didnt look at your branch before (or dont remember) just the code that was pushed and in that code i dodnt understand the jitter loops purpose and dont expect the code to be slow
dellas has quit [Remote host closed the connection]
<kurosu>
I'm basically saying 6 symbols doesn't help much for 8bit content, but that allows up to 3 for 10-16 bits, and that should be a lot more useful
<kurosu>
That branch I never submitted for very different reasons at different times, so it bitrot a lot and I had no time to fix that. Meant as experimental too albeit I did ran on occasion fate+valgrind at the time
<michaelni>
kurosu, the "jitter" code in your branch is not the same as in master "t = j ? num-1-i : i;" vs. "int t = j ? i-1 : i;"
<michaelni>
i can see the idea behind your code, i cannot see the idea behind the code in master
<durandal_1707>
stop hacking until you get all >8 bit utvideo and magicyuv samples
<jamrial>
JEEB: yes. afaik we don't really use bool anyway
<JEEB>
yes
<JEEB>
AV_OPT_TYPE_BOOL is expected to be sizeof(int) in various spots
<JEEB>
anyways, will reword the commit messages a bit (removing ".c" and rewording some paragraphs) and take a final look through and LGTM this set then
MrZeus__ has joined #ffmpeg-devel
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 272 seconds]
<JEEB>
thanks for giving a second look :)
Mikhail_AMD has quit [Quit: Konversation terminated!]
dellas has joined #ffmpeg-devel
Mikhail_AMD has joined #ffmpeg-devel
devinheitmueller has quit [Quit: devinheitmueller]
<jamrial>
JEEB: question about channel layouts. someone sent an patch to add a new layout that's basically 5.1 plus four top channels
<jamrial>
this would be "Sound System D" from ITU BS.2051-3, or channel configuration 16 from AAC
<jamrial>
thing is, he wants to name it 5.1.4
<jamrial>
which doesn't match what we have been using
<JEEB>
yea that is the NORMAL.LFE.TOP naming
<JEEB>
which f.ex. 22.2 doesn't follow
<jamrial>
For "Sound System C", or channel config 14 we used 7.1(top)
<JEEB>
since it just includes top ones in that 22
<jamrial>
and yeah, 22.1 for that one
<jamrial>
the latter excluding lfe
_whitelogger has joined #ffmpeg-devel
ubitux has quit [Ping timeout: 255 seconds]
ubitux has joined #ffmpeg-devel
<JEEB>
jamrial: if it's the `L R C LFE Ls Rs Vhl Vhr Ltr Rtr` one, that is called "kAudioChannelLayoutTag_Atmos_5_1_4" as far as I can tell
<JEEB>
which hints at the NORMAL.LFE.TOP naming coming from D
<JEEB>
CICP 16 is `L R C LFE Ls Rs Vhl Vhr Lts Rts`
<JEEB>
looking at kAudioChannelLayoutTag_CICP_16's definition, so apparently different?
<JEEB>
and this seems like a "rear vs surround" kind of case again ^^;
<jamrial>
yeah
<jamrial>
how is 'L R C LFE Ls Rs Vhl Vhr' called there?
<jamrial>
kAudioChannelLayoutTag_Atmos_5_1_2?
<JEEB>
apparently just kAudioChannelLayoutTag_CICP_14 ? since kAudioChannelLayoutTag_Atmos_5_1_2 is `L R C LFE Ls Rs Ltm Rtm`
mkver has joined #ffmpeg-devel
<jamrial>
JEEB: so what do we do? rename 7.1(top) to 5.1.2, and add System D (or channel config 16) as 5.1.4?
<jamrial>
and System J as 7.1.4
<JEEB>
which to utilize I guess depends on which definition you're going after, since 5_1_4 and CICP 16 and CICP 14 and 5_1_2 are slightly different
<jamrial>
the CICP ones look more correct and match System C/D and Channel config 14/16
<JEEB>
yea the problem is that D's and CICP's definitions slightly differ it seems
<JEEB>
so if someone says 5.1.4 they probably mean D's
dellas has quit [Read error: Connection reset by peer]
<JEEB>
yea those two do.
<JEEB>
anyways, posted the full header so you can see the slight differences in their definitions which probably come from the source (D or ISO/ITU, respectively)
MrZeus_ has joined #ffmpeg-devel
MrZeus__ has quit [Ping timeout: 252 seconds]
user23 has quit [Remote host closed the connection]
MrZeus__ has joined #ffmpeg-devel
user23 has joined #ffmpeg-devel
MrZeus_ has quit [Ping timeout: 255 seconds]
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
deus0ww has joined #ffmpeg-devel
deus0ww_ has quit [Ping timeout: 258 seconds]
user23 has quit [Remote host closed the connection]
navi has quit [Quit: WeeChat 4.0.4]
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 260 seconds]
aljazmc_ has joined #ffmpeg-devel
aljazmc has quit [Remote host closed the connection]
SystemError has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<jamrial>
JEEB: there, feel free to shed the bike :p
averne has quit [Quit: quit]
<BtbN>
https://bpa.st/YRYA I'm very confused. What's going on here? Why do the correct linker-flags vanish from test_ld to test_cc, which subsequentially fails the test?
averne has joined #ffmpeg-devel
<Lynne>
pkgconfig file looks fine?
<BtbN>
well, it's a mess, but not incorrect
<BtbN>
As you can see in the log, the invocation of test_ld has the libraries
<BtbN>
test_cc is not supposed to link
<BtbN>
That dangling -L there is likely what causes that, it eats the -c
<BtbN>
But I don't see where it's coming from
<BtbN>
found it... libjxl_cms.pc specifically has an empty libdir and includedir