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.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Warcop has quit [Ping timeout: 260 seconds]
SystemError has quit [Ping timeout: 260 seconds]
SystemError has joined #ffmpeg-devel
Livio has quit [Ping timeout: 272 seconds]
Wenbin_Chen_ has joined #ffmpeg-devel
Wenbin_Chen__ has quit [Read error: Connection reset by peer]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
lexano has quit [Ping timeout: 260 seconds]
<Oneric>
you’ll have to give some instructions here, the file has two subtitle tracks (i’m guessing it’s the second?) and just recoding the file yields seemingly equally broken results with or without what i understood to be the proposed patch
<Oneric>
as i said i have no knoweldge of this format, so if you want me to fix it, i’ll need a simple to use testcase where success/failure is easy to tell apart
<Oneric>
though apparently you already have a working fix, so i’m not sure why you’re not just sending this
<Oneric>
(and if you care about this format you really should add a test to FATE so that issues are discovered pre-merge and everyone has access to an easy to use, minimal testcase)
<Oneric>
> equally broken results with or without what i understood to be the proposed patch
<Oneric>
in fact testing a commit before 57c5450 is broken the same way
<Oneric>
probably this is just not the right way to test it, but idk how to test it then
<kasper93>
not sure what you mean by broken output
<kasper93>
but with current version decoder just return AVERROR_BUG;
<kasper93>
so it does nothing
<kasper93>
anyway I can send a patch
<kasper93>
but in the same time I don't agree with idea of changing line endings in 6+ years code, just for the sake of it
<Oneric>
running ./ffmpeg -i sub.ts sub.mkv will (attempt to) transcode (dvb_teletext (libzvbi_teletextdec) -> ass (ssa)) but in all cases prints some errors and at the end “Conmversion failed” and the ASS sub track in the output is missing codec private
iive has quit [Quit: They came for me...]
<Oneric>
> just for the sake of it
<Oneric>
the old CRLF line endings are (a) not require by ASS and (b) caused massive (growing, due to accumulating bugs) pain with the ML and patchwork
<Oneric>
that already happened before my commits, i just removed a few leftover \r\n (see commit message)
<kasper93>
> with txt_format set to 2
<Oneric>
yeah, but how ? i still have no idea about this format or how to use its ffmpeg options
<JEEB>
I thought bools only had issues with the definition on some powerpc headers?
<JEEB>
oh wait, in the sense that all the compilers we want to support should support stdbool
<JEEB>
(as third parties using our headers)
dykai has quit [Ping timeout: 255 seconds]
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
dykai has joined #ffmpeg-devel
dykai has quit [Quit: dykai]
jamrial has joined #ffmpeg-devel
Raz- has joined #ffmpeg-devel
razor_ has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
Raz- has quit [Ping timeout: 252 seconds]
Livio has quit [Ping timeout: 256 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]
Guest16 has joined #ffmpeg-devel
Guest16 has quit [Quit: Client closed]
kurosu has quit [Quit: Connection closed for inactivity]
<frankplow>
jamrial: Re. ctb_size_y patch, would throwing an error if ctb_size_y == 3 in libavcodec/vvc/ps.c be better? Would skip pictures which have the large CTUs without stopping decoding altogether
<jamrial>
i guess. that would fit the "ignore" clause
Marth64 has joined #ffmpeg-devel
lexano has joined #ffmpeg-devel
<Lynne>
jkqxz: ping, do you have time to merge the patches today?
<JEEB>
the idea of sanity checking the values parsed makes sense, just needs to be checked against the mentioned spec as well as H.274 SEI definitions
Sean_McG has quit [Remote host closed the connection]
<BtbN>
If nobody objects for long enough, and you think it's an improvement and correct, eventually it's just an auto-accept
<BtbN>
re-sending/pinging five times definitely qualifies it for that
<haasn>
I remember already looking at this
<JEEB>
yea, you reviewed it in its earlier iterations
<JEEB>
let me check if there is another parser in CBS, that's what VVC uses IIRC
<haasn>
yeah I sent a review comment
<haasn>
assuming that was addressed the rest LGTM
<haasn>
yeah seems fixed
<haasn>
kasper93: do need me to push?
<kasper93>
I don't have push rights, so I kinda expect someone to pick it up.
<kasper93>
anyhow I didn't want to bump it 5 times, it was just that this code was changes recently multiple times, so I resended rebased version
<JEEB>
so yea, that will affect H.264/5. AV1 has its own code using ff_decode_mastering_display_new, and I have no idea if those bits of CBS are being utilized in VVC decoder. I think that's more or less it?
<kasper93>
indeed, I checked spec for 264/5 because this was the problematic smaple file we got
<kasper93>
I don't know if the same restriction apply to av1 and others, but this code is specific to 264/5 only
<haasn>
JEEB: any objections to me pushing it as-is?
<haasn>
not sure if you meant for me to wait or not
<JEEB>
VVC is the same, but I can't grasp whether its CBS usage utilizes it or not
<JEEB>
AV1 I think just changed the numeric base
<JEEB>
haasn: I'd prefer us to have central handling of invalid values for this stuff, but since the person is already annoyed by the amount of bumps I'm not really wanting to make it even more annoying to him to contribute :P
<JEEB>
in other words, I'm not blocking pushing this in if it seems correct according to ST 2086 and H.274 (SEI)
<haasn>
strictly speaking I don't see any validity requirements in the AV1 spec
<kasper93>
I'm not anoyed, it is just -v5 was silly to write
<BtbN>
If nobody actively maintains a certain area, that's sadly what happens
<JEEB>
right, H.274 contains that x 5/37000 , y 5/42000, and for luminane 50k to 1 million for max, 1 to 50000 (except when max is 50000, min needs to be not 50000)
<kasper93>
thank you
<JEEB>
and those are based on the numeric base of the SEI
<JEEB>
I think AV1 has a different base (mediainfo IIRC had a bug there assuming the same)
<JEEB>
so the validation would be similar but with a different value for those things where the y in x/y is different
<JEEB>
if anyone has tested the VVC decoder, please tell if it currently handles HDR10 metadata? as it apparently utilizes CBS which in theory has support for it
<JEEB>
at least vvcdec doesn't seem to refer to SEIRawMasteringDisplayColourVolume
<jamrial>
JEEB: it also doesn't call ff_h2645_sei_to_frame or similar
<JEEB>
yea, and that would utilize the decoder code that was just poked, not CBS.
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
<cone-068>
ffmpeg Diego Felix de Souza master:1f265aa91d6c: avcodec/nvenc: Multi NVENC Split Frame Encoding in HEVC and AV1
<JEEB>
wasn't this just slices? ^
<JEEB>
or is this the other way (vertical vs horizontal or so)
razor_ has quit [Ping timeout: 256 seconds]
tufei__ has quit [Remote host closed the connection]
tufei__ has joined #ffmpeg-devel
<jkqxz>
I think it's more than just slices. The two halves don't have any interaction so that they can be encoded entirely independently.
<jkqxz>
So MVs and intra prediction don't cross the boundary, and filtering is disabled over it. That's why it has to be opt-in, because the seam starts being visible at lower quality levels.
<jkqxz>
Lynne: Yes.
tufei__ has quit [Remote host closed the connection]
<Lynne>
cheers
Sean_McG has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
tufei has joined #ffmpeg-devel
<BtbN>
it's in fact not opt in, it's default-enabled
<BtbN>
Though I have no access to hardware to see it in action
<BtbN>
all my cards have one singular nvenc unit
rvalue has quit [Read error: Connection reset by peer]
razor_ has joined #ffmpeg-devel
<Sean_McG>
anyone here use KDE on Debian stable? I just bought a new GPU and there is some visual corruption
<Sean_McG>
it doesn't happen in GNOME on the same machine
rvalue has joined #ffmpeg-devel
<Marth64>
xfce here :(
<Sean_McG>
hmmm OK I will try that in a moment
<BtbN>
Welcome to Wayland I guess?
<Sean_McG>
yeah, what's to bet it is totally a Wayland bug
<frankplow>
Is that split frame thing just for parallelism? In VVC there is subpictures which is a similar concept but there is emphasis on the fact you can extract a single subpicture
<Marth64>
i had to actually get rid of the deb machine few days back due to other issues but i am running xfce on still on my desktop. i didn't have corruption on wayland but aggrevating sleep/wake problems with hybrid graphics
<Sean_McG>
how are you liking your new laptop, Marth?
<BtbN>
it's to speed up single-stream encoding if your GPU has multiple nvenc units
<Marth64>
returned it :(
<Sean_McG>
oh, that's a shame
razor_ has quit [Ping timeout: 246 seconds]
<Marth64>
yeah, the major issue for me was sleep/wake problems
<Marth64>
which GPU you get?
<Marth64>
(if you dont mind me asking)
<Sean_McG>
Sapphire Pulse Radeon RX7600 8GB
<Sean_McG>
replaced a Vega 64 I bought in 2018
<Marth64>
neat. i'll bet it looks cool
<Lynne>
BtbN: the slicing patch?
<Sean_McG>
it's a lot quieter than the old one
<BtbN>
Lynne: the multi slice toggle for nvenc one
<Marth64>
hope it works out in the end on kde. xfce is a good wm but there are some quirks in time you get used to em. sleep/wake issues were due to hybrid graphics and i gave up debugging them at some point
<Marth64>
(>Sean_McG)
<Sean_McG>
I've never had a machine with hybrid graphics, I don't imagine it is fun to figure out the quirks
<BtbN>
Wayland is all nice and flashy, until you realize that now a dozen developers re-invent the wheel and will re-produce issues that got fixed in X over the decades
<Sean_McG>
ouch
<Sean_McG>
I'll tasksel XFCE and see if that works
<haasn>
BtbN: or until you try using it on a laptop
<BtbN>
It's almost like centralizing this kind of highly quirky stuff was a _good_ thing
* JEEB
has been rolling on GNOME with wayland for years and it has worked JustFine for basic working. except when I moved to an amdgpu laptop, then I started seeing how every Nth kernel "stable" broke something (thankfully the past year+ or so has been stable for renoir)
<BtbN>
I know it's controversial, but imo Wayland was the worst that happened to Desktop-Linux
<Marth64>
i used wayland once for 4k scaling issues on an old build but in the end my eyes struggle beyond 1080p so now back to x anyway...more than enough for xfce
<jkqxz>
But think of all the innovation in exciting different kinds of wheel! You can have square wheels, triangular wheels, whatever you can think of!
<BtbN>
like, I wouldn't ever consider using a Desktop Linux these days, as much as I'd love to retire Windows
kurosu has joined #ffmpeg-devel
<JEEB>
by now even nvidia went away from EGLStreams
<psykose>
i had the opposite experience
<psykose>
if X was still the only option i would use windows instead
<BtbN>
I never had major issues with a Desktop on X. Yes, there were signs of age, but they weren't unfixable. Stuff like multi-screen DPI handling
Sean_McG has quit [Remote host closed the connection]
<BtbN>
But on Wayland? On every desktop env rolling their own display server, something else is broken
<Marth64>
i can't use anything but linux desktop sinc probably 2013. with the exception of laptop macOS (which i am struggling with more and more over time)
<BtbN>
And some very basic features are simply not implemented cause on some ML, some people are bickering about it since years
<haasn>
I love how my screenshot tool doesn't work on KDE because it doesn't implement whatever wlroots custom protocol makes it work
Sean_McG has joined #ffmpeg-devel
<haasn>
that reminds me, I need to fork libinput and make its touchpad acceleration settings configurable; for some reason they are hard-coded
<Sean_McG>
hmmmm, switching clobbered my tmux session, that's kind of lame
<Sean_McG>
not seeing any corruption yet -- so I guess this is only on KDE that I have issues
<Marth64>
if you end up liking xfce. 2 unsolicited suggestions, (1) get whisker menu plugin (2) window resize handles are a nightmare, use alt+right click shortcut
<Marth64>
sorry to hear bout kde hope theres a quick fix
<haasn>
Sean_McG: tmux sessions being clobbered is a systemd "feature"
<Marth64>
maybe use newer kernel from backports?
<Sean_McG>
haasn: oh, cute
<haasn>
you're supposed to use `systemd-run --scope --user tmux` or something now
<haasn>
and maybe disable KillUserProcesses=no
<haasn>
s/disable/set/
<JEEB>
I absolutely love amdgpu but on the other hand each time something breaks it makes me hurt filled animals
<Lynne>
never run badly written code on amd
<BtbN>
Yeah, AMD drivers are a trouble magnet
<BtbN>
On Windows as well
<Sean_McG>
colour me unsurprised
<Lynne>
the issue isn't drivers
<JEEB>
less affects LTS distros or those staying on LTS kernels of course (of course given you have support for your GPU on the LTS kernel)
<Marth64>
+1 with hybrid graphics they did not play along
<Lynne>
it's that hardware has zero error recovery capability
<JEEB>
Lynne: for me it was specifically drivers :D since stable kernels would regress and then get fixed in like a month or two or three
<JEEB>
thankfully the last 1-1.5 years has been stable for renoir
<BtbN>
the Hardware is dumb as bread, all the fault tolerancy is in the driver
<BtbN>
and AMD historically had very little of it
<Marth64>
didn't nvidia recently oss their driver?
<Marth64>
ok like a year+ ago, i am behind the times
<JEEB>
yea they have an OSS driver for hardware where most of the stuff is done in firmware
<Marth64>
ahhh, thats the trick
<BtbN>
No, in userspace
<BtbN>
They open sourced the kernel module, after thinning it down enough to contain nearly no code
<JEEB>
then you would require some closed source user space, no? if they just moved the code there.
<BtbN>
some moved into the GSP firmware, some always was in userspace anyway
<Marth64>
as long as i have nvenc i'm happy
<Marth64>
and as long as i don't have to run dkms ever again
<BtbN>
hm? It's an out of tree kernel module nevertheless.
<JEEB>
yup
<Marth64>
i am thinking back to 2016-2017 days when it was a nightmare to install
<Marth64>
holding edge of my seat after rebooting from picking at dkms manually
<BtbN>
It only ever was a nightmare to install if you use bleeding edge kernels
<Lynne>
nouveau has feature-parity these days if you don't care about nvk or tensors
<Marth64>
its a breeze now
<BtbN>
Or performance, or 3d acceleration in general
<Lynne>
BtbN: I'm talking about vulkan, not some 3d api from 1995
<Lynne>
performance is on par, it's all done by the GSP
<BtbN>
Last I checked, the 3000 and 4000 series cards still don't work at all beyond a simple 2d desktop
<Marth64>
on nouveau?
<BtbN>
Yeah
<Marth64>
i sort of recall this but i have not switched back to nouveau in a long time
<Marth64>
i remember being stuck in 640x480
<Marth64>
if i can do vulkan encode with it i'm not opposed to nouveau i will try it again sometime
<Lynne>
BtbN: err, they've worked since june last year
<Lynne>
3D with enough vulkan features to run vkd3d
<Lynne>
(that's more recent, but they did have vulkan 1.1 back then, which is enough to run most vulkan games)
<Lynne>
(nevermind that this is because vulkan is so unpopular that game studios don't bother these days)
Livio has quit [Ping timeout: 256 seconds]
Sean_McG has quit [Quit: brb, another reboot]
Sean_McG has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
sh4 has joined #ffmpeg-devel
<sh4>
https://0x0.st/X-fH.diff patch for my issue reported in the other chan: the command line parser doesnt detect -q -1.0 as a valid input for libvorbis
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<sh4>
i guess the better fix would be to set qscale to NaN and test for that
<Lynne>
so I guess they do have an off by one there too
<jkqxz>
The spec is clear that "OrderHint, OrderHints, and expectedFrameId are interpreted as defined in section 6.8.2 of the AV1 Specification;" so they need to fix that too.
<jkqxz>
I'll answer with that.
<jkqxz>
Shall I send those patches to the ML? You said you would work out the driver version check to apply the offset for the incorrect nvidia drivers.
<Lynne>
they're not fixing the spec, just the cts and drivers
<Lynne>
no need, just do the int -> const uint8_t and they lgtm, feel free to push them
<Lynne>
I'll write the hack tomorrow, barely awake enough to review this
<jkqxz>
The only change you had on top of my patches for it to work on nvidia were the +1 in SavedOrderHints and OrderHints?
<jkqxz>
I need to fix the length of the OrderHints loop as well. I'll send this to the ML and you can apply tomorrow once you have the hack working on it as well.
<Lynne>
what did you change between the current version and the previous version btw?
<jkqxz>
Redid OrderHints and added more comments on what the fields actually mean.
<Lynne>
ah, orderhints was still not correct in the previous version, or just cleanups?
<jkqxz>
OrderHints was being indexed by slot number rather than reference name, that's the real fix.
kurosu has quit [Quit: Connection closed for inactivity]
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
<jkqxz>
Um. I am looking at GmType/gm_params right next to OrderHints. They are also meant to be indexed by reference name, but the code has a loop 0..6 when it should probably be 1..7.
marcj has joined #ffmpeg-devel
<Lynne>
STD_VIDEO_AV1_NUM_REF_FRAMES is 8 though
<jkqxz>
Oh, no, it's a loop 0..7 because it uses the "number of slots" value rather than the "number of reference names" value. This is not confusing at all.
<jkqxz>
It should be TOTAL_REFS_PER_FRAME to match the type. (Would be nice if we could have differently-typed integers to prevent this sort of problem.)
Krowl has quit [Read error: Connection reset by peer]
<Lynne>
I'll split them up
<jkqxz>
I was already moving OrderHints to the loop above, I'll move all of them.
Marth64 has quit [Ping timeout: 255 seconds]
Marth64 has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
cone-068 has quit [Quit: transmission timeout]
marcj has quit [Ping timeout: 252 seconds]
iive has quit [Ping timeout: 272 seconds]
kurosu has joined #ffmpeg-devel
qeed has joined #ffmpeg-devel
iive has joined #ffmpeg-devel
qeed_ has quit [Ping timeout: 255 seconds]
Marth64 has quit [Ping timeout: 272 seconds]
Marth64 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
mkver has quit [Ping timeout: 246 seconds]
razor_ has quit [Ping timeout: 268 seconds]
<sdc>
are there recommended resources for learning about things like high level syntax, ctu/ctb etc?
<sdc>
I was look at some textbooks on hevc
Sean_McG has quit [Remote host closed the connection]
Marth64 has quit [Remote host closed the connection]
Sean_McG has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
qeed_ has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
qeed has quit [Ping timeout: 252 seconds]
Traneptora has quit [Quit: Quit]
<frankplow>
sdc: Iain E. Richardson "The H.264 Advanced Video Compression Standard" is a good intro to MPEG standards. It doesn't cover the coding tree though as that's an HEVC addition.
<frankplow>
"HEVC Algorithms and Architectures" covers the HEVC additions in a lot of detail