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
System_Error has joined #ffmpeg-devel
thilo_ has quit [Ping timeout: 252 seconds]
Traneptora has joined #ffmpeg-devel
thilo_ has joined #ffmpeg-devel
deus0ww has quit [Ping timeout: 246 seconds]
markh has quit [Read error: Connection reset by peer]
deus0ww has joined #ffmpeg-devel
markh has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
^Neo has joined #ffmpeg-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #ffmpeg-devel
^Neo has quit [Quit: Client closed]
arch1t3cht9 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht9 is now known as arch1t3cht
witchymary has joined #ffmpeg-devel
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 246 seconds]
pal_ has quit [Ping timeout: 246 seconds]
pal has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
cone-715 has joined #ffmpeg-devel
<cone-715>
ffmpeg Lynne master:9eb7e8d2a4da: vulkan: move alignment of host-visible allocations outside of ff_vk_alloc_mem
Krowl has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
StevenLiu has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
arbitercoin has joined #ffmpeg-devel
cone-715 has quit [Quit: transmission timeout]
cubicibo has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 276 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
cubicibo has quit [Ping timeout: 256 seconds]
ccawley2011 has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 265 seconds]
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
Cheetahze has joined #ffmpeg-devel
em___ has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
ccawley2011__ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 244 seconds]
ccawley2011_ has quit [Ping timeout: 255 seconds]
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
psilokos has joined #ffmpeg-devel
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
ccawley2011 has joined #ffmpeg-devel
ccawley2011__ has quit [Ping timeout: 252 seconds]
* JEEB
thinks if it makes sense to implement min_fragment_duration|max_fragment_duration and all the other module-internal fragment options for subtitle-only TTML mp4
<JEEB>
my initial opinion is: due to its spec and requiring a separate queue of packets until the final packet is written out - no
<JEEB>
but I recall a lot of people wanted subtitle only fragment files since single-track muxes are how CMAF is envisioned to be utilized.
<JEEB>
such completely separate muxes would be better fit to all just be controlled by a single mux controller (in other words, API client)
<JEEB>
its issues are just less visible when you have continually incoming set of packets like with video or audio
<JEEB>
I guess I will post a rebased version for now and try to get some opinion on how much functionality would be required for the set to be merge'able upstream
Lypheo has quit [Quit: Ping timeout (120 seconds)]
Lypheo has joined #ffmpeg-devel
<JEEB>
given that the feature seems to work and seems to be useful to some people (while I really dislike how some things in TTML in mp4 mapping got specified :D)
witchymary has quit [Remote host closed the connection]
witchymary has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
ccawley2011 has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 264 seconds]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 255 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
Cheetahze has quit [Quit: Connection closed for inactivity]
MikhailAMD has joined #ffmpeg-devel
MikhailAMD has quit [Client Quit]
ccawley2011_ has joined #ffmpeg-devel
ccawley2011 has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
ccawley2011_ has quit [Ping timeout: 252 seconds]
Marth64 has quit [Quit: Leaving]
iive has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<cone-793>
ffmpeg James Almer master:7756cd98acef: swscale/input: add Y216LE input support
<cone-793>
ffmpeg James Almer master:f462ba05f54d: avutil/pixfmt: add Y216 pixel format
<cone-793>
ffmpeg James Almer master:b520d95467bc: swscale/output: add Y216LE output support
MisterMinister has quit [Ping timeout: 252 seconds]
MisterMinister has joined #ffmpeg-devel
<BBB>
if I set FFCodec.p.capabilities |= AV_CODEC_CAP_SLICE_THREADS (or, I'm guessing, FRAME), AVCodecContext.thread_count is set (either to the value from -threads, or to the auto-detected value). However, if I set AV_CODEC_CAP_OTHER_THREADS, AVCodecContext.thread_count is always 1, unless FFCodec.caps_internal |= FF_CODEC_CAP_AUTO_THREADS, in which case it might also be 0 (if -threads is not set). is this behavour intentional?
<BBB>
there might be a used case for AV_CODEC_CAP_OTHER_THREADS being set without FF_CODEC_CAP_AUTO_THREADS being set also
System_Error has quit [Write error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
em___ has quit [Ping timeout: 246 seconds]
Krowl has quit [Read error: Connection reset by peer]
arbitercoin has quit [Ping timeout: 255 seconds]
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 260 seconds]
ngaullier has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
___nick___ has quit [Ping timeout: 276 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
cone-793 has quit [Quit: transmission timeout]
<ramiro>
wbs: I haven't checked the patch itself (only the title), but does your "checkasm: Print benchmarks of C-only functions" unconditionally print the c only functions every time?
<ramiro>
I did hack checkasm a couple of times to print the c functions, but I don't want it every time. perhaps a command line switch would be better.
<wbs>
we used to have that in dav1d, but we went with just always printing the c functions as well. you can filter the names of what functions you actually benchmark with a wildcard pattern anyway
<wbs>
so as long as you're tuning one single function, you usually want to have a tight enough wildcard pattern anyway
<ramiro>
wbs: you mean a wildcard for --test?
<wbs>
ramiro: no, "checkasm --test=<group> --bench='function_name*'"
<ramiro>
wbs: ah, I didn't even know that was possible. I learn something new every day :)
<wbs>
ramiro: it has always been possible; previously you were supposed to pass a prefix of the function names to prefix, i.e. "--bench=start_of_func_name", but since some time ago, it instead wants a proper wildcard pattern
<wbs>
without that, tuning an individual function probably is annoying, unless the --test group is very small :-)
<ramiro>
I usually resort to grepping the output :P
<wbs>
yeah, you probably want that too, but even then, if it runs benchmarks of too many functions, it takes annoyingly long
<wbs>
(on low-end hw)
<wbs>
ramiro: are you coming to VDD?
<ramiro>
I did indeed hit that problem of benchmarks taking too long... usually I just alt+tab to instagram, watch a couple of stories, and alt+tab back.
<wbs>
lol
<wbs>
yeah, that works, but is annoying when you want to test and tweak and compare a dozen of minor variations
<ramiro>
wbs: yes I am. I arrive on thursday a bit before noon.
<wbs>
ramiro: awesome, I'll see you there, then!
<JEEB>
:)
<ramiro>
JEEB: you're going as well, right?
<JEEB>
aye
<ramiro>
cool!
<ramiro>
I'm preparing a lightning talk about ffglitch, my glitch art fork of ffmpeg.
<JEEB>
nice
lemourin has joined #ffmpeg-devel
lemourin is now known as Guest6935
Guest6935 has quit [Killed (lead.libera.chat (Nickname regained by services))]
System_Error has quit [Remote host closed the connection]
<cone-142>
ffmpeg Niklas Haas master:f1f54d2f8265: swscale/x86: use dedicated int for self-modifying MMX dstW
<haasn>
michaelni: did "[PATCH v3 02/18] swscale: rename SwsContext to SwsInternal" look good to you as well?
ccawley2011_ has quit [Ping timeout: 252 seconds]
ngaullier has quit [Ping timeout: 255 seconds]
<michaelni>
haasn, on its own the commit isnt really doing anything / showing how the two structs will look. So i cannot comment. I have no objections to this change if i like the future change that builds on it
<michaelni>
do you have some branch or something that shows how this will look with the 2 structs not being the same ?
<ePirat>
is trac down?
<ePirat>
getting a Gateway Timeout
<cbsrobot>
trac works for me
<ePirat>
cbsrobot, tried looking at the wiki page you mentioned and all I get is gateway timeouts
<ePirat>
what a fantastic piece of software
<cbsrobot>
lol - not sure what happened but I just tested another browser and it works too
<cbsrobot>
but yes - thanks for having a look
<ePirat>
works again, weird
<ePirat>
seems to be related to my account…
<ePirat>
so yeah sorry cant really look into it
<ePirat>
michaelni, can you check maybe whats wrong with trac?
<ePirat>
tried to login, just getting gateway timeout again from Apache
<ePirat>
so clearly does not seem to be my connection
<BtbN>
ePirat: login on trac works fine for me and without any waiting time
<ePirat>
haasn, now that you mention it… but its not his account at least and he did wrote somewhat useful and coherent stuff in other places
<haasn>
well
<haasn>
I double checked the code and it seems SWS_FULL_CHR_H_INT can also happen when going to packed yuyv 422
<haasn>
so indeed not just rgb, although that's the typical case
<haasn>
so I guess I can amend it to RGB/YUYV
<haasn>
"WS_FULL_CHR_H_INT may involve down-scaling too" I don't see this case anywhere
<haasn>
it only affects the yuv2rgb output functions
<michaelni>
BtbN, yes not sure if that was the issue, maybe it was, anyway i just restarted apache, as in the past that fixed trac issues (if it helped thats a bug that will get fixed when the box is upgraded)
<haasn>
"SWS_FULL_CHR_H_INP asserts full-chroma input" uhh the flag literally only does anything for RGB inputs
<BtbN>
I also don't think I have access to the trac box btw.
<haasn>
and dropping any other pixel for chroma input is definitely *not* "sensible"
<haasn>
though ofc ymmv
<haasn>
i mean
<haasn>
why not just nearest neighbour sample everything
<haasn>
ePirat: so tl;dr I stand by my description
<haasn>
and I think whoever wrote this is not making much sense
<ePirat>
I am tempted to just revert most of the changes as it just utterly messed up the formatting and introduced a lot of weird rambling
<haasn>
actually, I need to double check how the dropping of every other pixel is done
<ePirat>
actually seems I can not easily revert parts of the change without a ton of manual effort so…
<ePirat>
I will not bother and leave it to someone who understand more about the topic at hand
<haasn>
yeah, maybe the default handling *is* fine, if perhaps a bit lower quality
<haasn>
yeah the description needs to be amended a bit
<haasn>
the pixels are bilinear downscaled
<haasn>
so the only time it lowers quality is if you're using a higher quality chroma sampler
<haasn>
the description makes it seem like they're point sampled
<michaelni>
haasn, future sws internal design/direction looks ok, thanks for pointing me to it
<michaelni>
for the record, BtbN has successfully accessed trac now, so he can look into the issue when it happens next time. But i suspect its that ubuntu apache bug. But yes theres alot of odd traffic too and that could have been the cause too
<BtbN>
I'm sure I had logged in there successfully in the past. I already took note of the mod_wsgi situation on there, and even fixed apache settings.
<BtbN>
Was just confused when it didn't let me in, but figured out what caused it :D
<Lynne>
jamrial: AV_PIX_FMT_Y216 maps to VK_FORMAT_G16B16G16R16_422_UNORM in case you want to add support for it in vulkan
<jamrial>
Lynne: ok
<cone-142>
ffmpeg James Almer master:e46a506ae0ef: avcodec/vulkan_video: add proper maps for XV3{0,6}
<cone-142>
ffmpeg James Almer master:5c622d4cc1b4: avutil/hwcontext_vulkan: add support for AV_PIX_FMT_Y216
<cone-142>
ffmpeg James Almer master:ae0ab5b7cec2: avcodec/vulkan_video: add mapping for AV_PIX_FMT_Y216
osvein has quit [Ping timeout: 252 seconds]
ccawley2011 has quit [Read error: Connection reset by peer]
<IndecisiveTurtle>
Hi, sent a patch to the ML with the vulkan vc2 encoder I've been working for a bit. Open to any reviews or optimizations!
kasper93_ has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 246 seconds]
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
cbsrobot has quit [Ping timeout: 246 seconds]
HarshK23 has quit [Quit: Connection closed for inactivity]