<JEEB>
sounds like zimg, requires explicitness. so if there needs to be some sort of auto-guessing then there should be a warning message or so that it then is doing auto-guessing
<nevcairiel>
it kind of makes sense for the filter to desire specific input, especially if you request anything but primary pass-though
sepro has quit [Quit: Bye!]
<haasn>
in this case using just -vf colorspace:range=pc
<nevcairiel>
pass-through should probably be allowed if its not modifying it, assuming the algorithm doesnt need the value for something
<JEEB>
ah, range related. yea if nothing else is to be done there then it shouldn't need all the parameters
<nevcairiel>
we can bikeshed for a couple weeks after if it should do guessing
<JEEB>
if it isn't touching primaries/matrix/trc
<JEEB>
(or chroma sample location)
<JEEB>
then it wouldn't require any of those
<JEEB>
but yea, in test cases you can also use the set-whatever filter
<JEEB>
to define specifics if they need to be overridden
<nevcairiel>
looking at the code, it specifically even has a passthrough setting it sets internally, but only after determining the primaries - it should probably just also do that if both in/out are unspecified
<JEEB>
vf_setparams I think?
<JEEB>
nevcairiel: yea I guessed it wasn't checking what was actually required to be defined for the specified conversion
<nevcairiel>
actually looking at the code it seems overall to require rather specific instructions
<nevcairiel>
modify one and pass-through all others seems to not really be a thing, unless i misread it
<JEEB>
right. so I would guess input==output would have to be defined
<JEEB>
doing the processing but leading to the same thing :D
<JEEB>
otherwise if it's just range, vf_scale with arguments should be capable of doing that, no? or are we specifically attempting to work around that not working
<JEEB>
?
<durandal_1707>
hacks
<durandal_1707>
lazy
<durandal_1707>
dev
<haasn>
lrgb2lrgb_passthrough at the very least seems easy to just set to 1 if both are unspecified
<nevcairiel>
if swscale was capable of doing range adjustment between yuv and yuvj, then it should also be capable of doing that with explicit range flags - and if not, thats a bug the set should address (and likely a simple one with some missing condition somewhere), otherwise its going to trip up users as well
<durandal_1707>
i think rgb limited is not supported at all
<j-b>
good morning the best of the best
<JEEB>
g'morning
<durandal_1707>
good morning the president, the grand knight!
<haasn>
nevcairiel: swscale can do it, vf_colorspace can't
<haasn>
I figured I could try and consolidate range changes in the same filter as the other colorspace changes
<haasn>
but this has the potential downside anyway of not being bitexact (sws has a lot of flags to enable bit exactness and so forth)
<haasn>
yuv2rgb anyhow seems not appropriate for range expansion
<haasn>
so probably vf_colorspace is best kept for just primaries/transfers
<haasn>
:shrug:
kekePower has joined #ffmpeg-devel
sepro has joined #ffmpeg-devel
<haasn>
annoyingly vf_colorspace also can't actually do range conversion unless yuv colorspace is known
<haasn>
fixing this filter will be a more in-depth method, I think for now I need to defer chroma and range conversions to the scale filter
clarkh has joined #ffmpeg-devel
navi has joined #ffmpeg-devel
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
<haasn>
Is there a way to get ffmpeg to dump the entire filter graph that is actually in use, including all auto filters?
<durandal_1707>
(a)graphmonitor filter
<JEEB>
also there was a cli option for something like that in ffmpeg.c, although I'm not sure if that got ever merged
<Lynne>
there's an api call
<BtbN>
Is the formula to do rgb/yuv conversion written up or implemented in an understandable way (i.e. not sws) somewhere? As in, the formula that takes all the color information into account.
jamrial has joined #ffmpeg-devel
<haasn>
there's not just one formula
<haasn>
there are too many colorspaces for there to be a one-size fits all formula like that
<BtbN>
Even if it pulls all the info from the matrix and coefs provided?
<haasn>
yes, because of things like ICtCp, IPTPQc2, BT.2020-CL
<haasn>
XYZ (J2K)
<BtbN>
hm, I wonder if I should just do a quick and dirty implementation for scale_cuda then
<haasn>
at the very least all of these require special handling that isn't just an application of a matrix
<BtbN>
That's at least better than it not being possible at all
<BtbN>
Though RGB CUDA-Frames are rare anyway, it's mostly d3d11 ones
<haasn>
generate megashader and #define to choose the branch?
<BtbN>
so ideally there'd be a kernel for every individual combination, but that would snowball into potentially thousands of kernels
<BtbN>
it already kinda is a megashader, using C++ templates and macros to expand into one kernel for every permutation of possible two pixel formats
<BtbN>
the kernel takes 20 seconds to compile :D
<haasn>
you can simplify it into optional xyz linearization + 3x3 matrix + optional trc application
<haasn>
a uniform branch is pretty cheap
<BtbN>
So I'm a bit reluctant to add _another_ layer of kernel-multiplication
<haasn>
oh not quite true
<haasn>
the full formula is: xyz linearization (optional) -> 3x3 matrix -> nonlinear 2x2 matrix (optional) -> trc application (optional) -> 3x1 matrix (optional)
<haasn>
and depending on the colorspace you may get linear or gamma light out, which is why in libplacebo I recompress back to gamma light always to get a consistent code path
<BtbN>
I wonder if I should do something like "rgb to yuv420" and inverse in a separate .cu file
<haasn>
it may be cheaper to just set the weights for the optional steps to 1 instead of branching over them, to be tested
<BtbN>
And then just chain that to the existing set of kernels that convert between all the various yuv formats
<haasn>
or just glue together kernels at runtime :D
<nevcairiel>
can we not invent new things that drop most chroma just for fun? :p
<BtbN>
I don't think we have much flexibility with CUDA kernels. Given we can only use the driver API, not the fun stuff from cudart
lemourin has joined #ffmpeg-devel
<BtbN>
Like, ideally I'd just generate those kernels on the fly, but runtime .cu compilation is not part of the driver API, but cudart
<haasn>
ah
<haasn>
can I interest you in vulkan?
<BtbN>
Every time I messed with Vulkan so far, it was broken in some way
<BtbN>
CUDA is proprietary shit, but at least works super reliably
<haasn>
mirrors my experience testing CUDA
<haasn>
and not working
<nevcairiel>
licensing why you cant use cudart?
<BtbN>
Yeah, it's not part of the driver, so does not fall under sys lib exception
<BtbN>
You're supposed to bundle the closed source .dll with your app
<BtbN>
I could in theory auto-generate PTX code at runtime, but oh boy, I'm not sure I want to write color conversion in CUDA assembly
<haasn>
does anybody know what chroma siting AMV video expects?
<haasn>
seems like mjpegdec sets avctx->chroma_sample_location = AVCHROMA_LOC_CENTER;
<haasn>
unconditionally
ccawley2011 has quit [Ping timeout: 255 seconds]
gust82 has quit [Remote host closed the connection]
<haasn>
kierank: do you remember the motivation behind 1515bfb3132d9e040f856bc48fbe8a4f26b14c14 and if it's still needed? and if yes, I assume it should apply to mpeg range yuv420p only, not jpeg range? (which was previously not hit due to the existence of yuvj)
gust82 has joined #ffmpeg-devel
<JEEB>
I would guess that's just because new code added attempted to ignore the existence of YUVJ
<haasn>
it's code from 2014 :D
<JEEB>
since that sounds like mpeg-2 | h.264 | hevc | vvc default chroma location setting
<JEEB>
yes, YUVJ has been a "outgoing thing" for that long I think
<haasn>
I would really rather we delete this override and just ensure all sources set chroma location correctly
<haasn>
simply removing it doesn't break FATE, at least
derpydoo has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
<haasn>
great, in_v_chr_pos et al aren't even documented
<haasn>
and this filter just completely ignores all chroma siting metadata in the frame
<haasn>
can we just delete vf_scale, honestly, it has so many broken edge cases and bugs that I don't even know where to begin fixing
<durandal_1707>
vf_ascale
<JEEB>
during development make a new filter doing what vf_scale should be doing, then when it's forming up you rename vf_scale's filter name to scale_old and change the identifier for your new filter to scale. then testing starts. alternatively the auto-scaling filter call could be switched to the new filter if just auto-scaling behavior is wanted to be tested
<JEEB>
and then as the new filter passes testing -> rm old scale
<durandal_1707>
so easy....
<JEEB>
also mostly noting it like this since you don't break the world while you're hacking on your new filter
<JEEB>
you only start breaking the world when you switcharoo the names or switch the auto-scaler definition
<BtbN>
Is videolan git stuff completely down now? Trying to push something, and it's just sitting there, doing nothing.
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
<elenril>
mkver: is this whole business with dynamic opaques really just to get the correct avctx into the av_log() in ff_thread_release_buffer()?
<mkver>
In this version, yes.
<elenril>
seems way overcomplicated for such a small reason
<mkver>
In earlier versions it was to support non-threadsafe callbacks.
<elenril>
i'd rather drop the log
<mkver>
I wanted to do this, but it felt a bit like cheating. Furthermore, I thought that people would object to this on the grounds of the lack of flexibility (after all, if it can't handle ff_thread_release_buffer() as-is, but needs to modify it, then...).
<elenril>
as I see it, the fact that ff_thread_release_buffer() needs any state beyond the frame being released, is in itself ugly
<mkver>
Ok, I will change this.
dellas has joined #ffmpeg-devel
<elenril>
can you then push the new branch to your repo and poke me
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<haasn>
[yuv4mpegpipe @ 0x4516d00] 'yuv420p' is not an official yuv4mpegpipe pixel format. Use '-strict -1' to encode to this pixel format.
<haasn>
wait what
<haasn>
oh
<haasn>
I messed up
AbleBacon has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
dellas has quit [Remote host closed the connection]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
bilboed has quit [Quit: Ping timeout (120 seconds)]
adema has quit [Remote host closed the connection]
rom1v has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<JEEB>
so if a wrapper module is fresh enough that it hasn't been yet in any release and there has been a change in the library that's being utilized that means an option should be renamed as part of adding a few new ones, would it be acceptable to just do the option rename instead of deprecating the old name first? I recall there being some no-deprecation changes being done in libsvtav1 wrapper, but I just
<JEEB>
wanted to figure out if such a thing would be acceptable for libaribcaption wrapper
<durandal_1707>
add alias name, and add deprecated flag to other one
<JEEB>
yea but this wrapper has not been a part of a release yet
<durandal_1707>
it less than several months already passed then yes
dellas has quit [Remote host closed the connection]
gust82 has quit [Remote host closed the connection]
gust82 has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
<mkver>
durandal_1707: It was never exponentially.
graphitemaster has quit [Ping timeout: 272 seconds]
ubitux has quit [Ping timeout: 260 seconds]
ubitux has joined #ffmpeg-devel
graphitemaster has joined #ffmpeg-devel
ccawley2011 has quit [Read error: Connection reset by peer]
kurosu has quit [Quit: Connection closed for inactivity]
vigneshv has joined #ffmpeg-devel
vigneshv has quit [Client Quit]
vigneshv has joined #ffmpeg-devel
<cone-669>
ffmpeg Andreas Rheinhardt master:a7663c96044e: avcodec/error_resilience: Constify ThreadFrame*
<vigneshv>
hi, i am looking to upload some test files to the fate server. i have sent the files to samples-request@ffmpeg.org a while ago. could somebody please help me upload those files to the fate server?
<mkver>
Reminds me that I wanted to look at this.
<mkver>
vigneshv: Have you checked whether none of the smaller files work?
<vigneshv>
@mkver, yeah unfortunately the smaller files have features that are not yet supported by ffmpeg's heic/mov parser. so if we are choosing files from the heif conformance repository the ones i chose are the ones that are known to work.
<mkver>
What happens if one uses one of the other files?
<vigneshv>
it will likely fail to parse
<vigneshv>
as they have features like grid, multiple layers, etc.
<mkver>
Likely? So you have not checked?
<vigneshv>
i checked the grid ones and they failed
<vigneshv>
if file size is the only concern, i can always create a random small heic image
<vigneshv>
couple of multi-layer images i just tried also fails to parse
<vigneshv>
the problem is that even if any of those files pass, i think it is not the right test to add since they pass by accident. we don't have code to parse/decode multiple layers from a heic image. so i think the test should only contain files that we know works as intended with the current code. what do you think?
<mkver>
MIAF002.heic works
<mkver>
Or seems to work.
<vigneshv>
let me check what's in that file
<mkver>
We seem to ignore the thumbnail, but as long as the main image is correctly demuxed.
<mkver>
We can always add support for the thumbnail later.
<vigneshv>
yeah that file contains a thumbnail and we ignore it since it is not the primary item. the test we add now might fail if we decide to support thumbnails in the future. is that okay?
<vigneshv>
i think that is probably okay since we can just update the expected output if we decide to process the thumbnail item as well.
<mkver>
If support for thumbnails were to be added, the test reference would need to be changed accordingly.
<mkver>
This is not a real "failure".
<vigneshv>
right
<vigneshv>
but i still think there should be a simple HEIC image without anything extra
<vigneshv>
so are you ok including C002 and MIAF002 ?
<mkver>
Or at least seems to work.
<mkver>
C025.heic works, too.
<vigneshv>
C025 is a grid
<vigneshv>
so that is definitely not working as intended
<mkver>
And?
<vigneshv>
instead of demuxing all the images and arranging them as a grid, we would end up demuxing only one of those images
<vigneshv>
while that is the behavior today, it is not the right one and i don't think we should add a test with that as the expected behavior
<mkver>
Then it shows our limitations. That's actually a good thing.
<mkver>
FATE tests are intended to catch unintended changes (often regressions); it is not necessary for the current behaviour to be correct to be tested.
<vigneshv>
i see, if that is the intent then it is fine to add C025
<mkver>
C053.heic also works, but it does not export stereo side data.
<vigneshv>
in that case, most images are likely to work with the current code. so we could just pick any of the small'ish ones that work.
<mkver>
I'd use MIAF002.heic, C025.heic and C053.heic.
<vigneshv>
i was hoping to include at least one simple HEIC image whose output is not likely to change in the future
<mkver>
That would be MIAF002.heic.
<vigneshv>
yes, using MIAF002.heic, C025.heic and C053.heic is fine by me
<vigneshv>
can you please upload them to the fate-server and i will update my patch ?
<mkver>
jamrial
<jamrial>
mkver: i need to rebuild the vm where i used rsync, so i can't upload anything until then
<mkver>
Ok.
<vigneshv>
ok, thank you
kurosu has joined #ffmpeg-devel
mark4o has joined #ffmpeg-devel
markh has quit [Ping timeout: 258 seconds]
mark4o is now known as markh
derpydoo has quit [Read error: Connection reset by peer]
navi has quit [Quit: WeeChat 4.0.4]
stevenliu has joined #ffmpeg-devel
\\Mr_C\\ has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
kurosu has quit [Quit: Connection closed for inactivity]