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.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
cone-934 has quit [Quit: transmission timeout]
Mirarora has quit [Quit: Mirarora encountered a fatal error and needs to close]
HarshK23 has quit [Quit: Connection closed for inactivity]
<fflogger>
[editedticket] JackLau: Ticket #10775 ([ffmpeg] FFmpeg omitting the CODECS attribute again with hevc_nvenc and libx265) updated https://trac.ffmpeg.org/ticket/10775#comment:2
thardin has quit [Ping timeout: 252 seconds]
ukn_unknown has joined #ffmpeg-devel
thardin has joined #ffmpeg-devel
<ukn_unknown>
I am new with IRC so please pardon my newbie mistakes.
<ukn_unknown>
Goal:
<ukn_unknown>
I want to get an example of how to use ffmpeg for SW decoding + QSV encoding, in ffmpeg doc examples. --> ffmpeg/doc/examples/qsv_encode.c
<ukn_unknown>
Background:
<ukn_unknown>
ffmpeg has the following examples in ffmpeg/doc/examples:
<ukn_unknown>
SW decoding with VAAPI encoding: vaapi_encode.c
<ukn_unknown>
QSV decoding with software encoding: qsv_decode.c
<ukn_unknown>
QSV transcoding: qsv_transcoding.c
<ukn_unknown>
Using those example I improved vaapi transcoding in tvheadend, and I would like to add also QSV transcoding capability. I need an example to help me kick start the implementation.
<ukn_unknown>
I am not sure if this is the right procedure for this request or even if the right place to ask this question. Any help will be greatly appreciated. Thank you.
ukn_unknown55 has joined #ffmpeg-devel
ukn_unknown55 has quit [Client Quit]
Arcitec has quit [Ping timeout: 260 seconds]
jamrial has quit []
ukn_unknown has quit [Ping timeout: 240 seconds]
Guest54 has joined #ffmpeg-devel
Kei_N has quit [Quit: leaving]
Guest54 has quit [Ping timeout: 240 seconds]
ukn_unknown has joined #ffmpeg-devel
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 272 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
delewis has joined #ffmpeg-devel
delewis_ has quit [Remote host closed the connection]
Kei_N has joined #ffmpeg-devel
Anthony_ZO has joined #ffmpeg-devel
HarshK23 has joined #ffmpeg-devel
av500 has quit [Remote host closed the connection]
av500 has joined #ffmpeg-devel
cone-689 has joined #ffmpeg-devel
<cone-689>
ffmpeg Andreas Rheinhardt master:b0af32265430: avcodec/vc2enc: Use LUT to assemble interleaved golomb code
<cone-689>
ffmpeg Andreas Rheinhardt master:74412bd10815: avcodec/snow: Remove ff_snow_release_buffer()
ukn_unknown has quit [Quit: Client closed]
delewis has quit [Remote host closed the connection]
delewis_ has joined #ffmpeg-devel
<cone-689>
ffmpeg Zhao Zhili master:7b81676be4d4: tests: Add enhanced-flv-hevc-hdr10 for demux and mux HDR color info
<cone-689>
ffmpeg Zhao Zhili master:f34294897ff1: avformat/flvdec: Fix use sizeof(AVMasteringDisplayMetadata)
<cone-689>
ffmpeg Zhao Zhili master:0f7d77fc423d: avformat/flvdec: Use appropriate error code
putacho has joined #ffmpeg-devel
elChippo has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 248 seconds]
putacho has quit [Ping timeout: 245 seconds]
rvalue has quit [Ping timeout: 252 seconds]
elChippo has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
pross has quit [Ping timeout: 244 seconds]
pata has joined #ffmpeg-devel
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
pata has quit [Ping timeout: 240 seconds]
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
rvalue has joined #ffmpeg-devel
cone-689 has quit [Quit: transmission timeout]
Anthony_ZO has quit [Remote host closed the connection]
jamrial has joined #ffmpeg-devel
lemourin has joined #ffmpeg-devel
lemourin has quit [Killed (lead.libera.chat (Nickname regained by services))]
cone-896 has joined #ffmpeg-devel
<cone-896>
ffmpeg Zhao Zhili n4.3.9:HEAD: avformat/flvdec: Use appropriate error code
^Neo has quit [Ping timeout: 252 seconds]
DauntlessOne4 has joined #ffmpeg-devel
<ramiro>
haasn: what are your plans for subsampled unscaled converters? for example yuv444p to yuv420p. do you think there could be subsampling/upsampling SwsOpType?
<haasn>
ramiro: that was my best plan for now
<haasn>
I think that I want to define the general scale path as float only, but that means we can't really reuse it for subsampled conversions
<haasn>
also, subsampling cares a lot about chroma offsets
<haasn>
while the general purpose scaling path can be defined without any offsets
<JEEB>
yea
<haasn>
so really they should be two separate paths, even if it means duplicating some code
<haasn>
I imagine the filter kernel setup code can be shared in any case
<haasn>
also, the fixed 2x sizes simplifies a lot of things
<haasn>
and lastly, we might want to use a custom unsubsampling kernel
<haasn>
like that "ideal" subsampling filter from that one paper
<haasn>
rather than exposing it to a user choice
<haasn>
the one thing that's really annoying about this is the presence of big endian formats
<haasn>
where we would need to swap the bytes during the unsubsampling step
<ramiro>
haasn: what do you mean by the chroma offsets?
<JEEB>
chroma sampling location
<haasn>
that
<JEEB>
see H.273 for the generally common values (although I'm pretty sure there's like three in active use)
<JEEB>
central which is dvi
<JEEB>
left which is MPEG-2-> default
<JEEB>
and top left (?) which is the BT.2100 default
<JEEB>
I think I posted the way to demo this on the SVT-AV1 repo when I was implementing the signaling of it
<JEEB>
since the SVT-AV1 developers were unsure WTF this was :D
<ramiro>
JEEB: "FFmpeg's swscale also has support for chroma location, but I am not sure how it takes in the values :)" <= did you figure out how swscale deals with it?
<JEEB>
I think there were some floating point based offsets
<JEEB>
at this point haasn probably knows this much better
<JEEB>
and it might even pass that stuff into swscale from the scale filter, which would mean that if you just set the property in the filter chain before, it should affect the result?
<ramiro>
iirc, for yuv444p to yuv420p we just average 4 pixels. I don't think we do any different chroma offsets in this case
<ramiro>
haasn: what's the paper for the "ideal" subsampling filter?
<haasn>
I don't remember, just remember seeing it
<haasn>
maybe mindfreeze knows
<haasn>
ramiro: JEEB: chroma offsets in swscale are passed in via src_h_chr_pos etc
microchip_ has quit [Ping timeout: 244 seconds]
<haasn>
and then used as offsets when calculating the filter values in initFilter()
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
<haasn>
when using the new API, they are calculated by get_chroma_pos() in graph.c
microchip_ has joined #ffmpeg-devel
<Lynne>
IndecisiveTurtle: ping, was there anything more needed to the patches?
<Lynne>
if not, could you link me a branch so I can test and possibly merge if it works fine?
<ramiro>
haasn: thanks. in practice, for a yuv444 to yuv420 conversion, what does this change? swscale currently uses center (average 4 pixels), but if it were left, should it average the 2 pixels on the left and drop the 2 on the right?
<haasn>
it should still average 4 pixels but with different weights, I think
<haasn>
well it depends on the kernel you are using
<haasn>
for bilinear I think you are right
<haasn>
this deletes information
<haasn>
unless you widen the filter kernel to prevent that
<haasn>
I think for a 2x downsample you normally double the filter area
<ramiro>
haasn: I'm still thinking about the unscaled case :)
<haasn>
444 -> 420 is 2x downsampling though
<ramiro>
oh, oops. I misread it
<mindfreeze>
ramiro: I tend to refer to Charles polyton book, he did a good writeup explaining basics and I often go through that
<fflogger>
[newticket] bermond: Ticket #11505 ([avcodec] Cuvid decoders do not work with CUDA hwaccel anymore) created https://trac.ffmpeg.org/ticket/11505
<haasn>
using continuation passing style and GCC vectors we can skip the load/store
<haasn>
since the compiler is smart enough to pass vector arguments in vector registers
<haasn>
the big problem here is that GCC vectors are absolutely terrible in GCC (ironically)
<haasn>
as you can see from the completely degenerate from8() output
<haasn>
I'm pretty sure that continuation passing is faster than the trampoline code I have currently though
<haasn>
so we may wish to switch to an approach like that regardless
<haasn>
there is one consideration we need to think about though; when doing mixed size operations, how do we deal with the differing element sizes?
<haasn>
this approach does not scale (in GCC) beyond the register size, i.e. 256 bits for AVX2; unless we pass the high and low values separately
<haasn>
actually, we *could* do that.. /me thinking
<Traneptora>
valgrind reports that I'm leaking 1824 bytes, but leaksan (--toolchain=clang-lsan) is showing nothing. why would that be?
<haasn>
one thing we could do is have the conversion functions call their "tail" multiple times
<haasn>
although I'm not sure how that would work for writes
<haasn>
hmm
<ramiro>
haasn: I think the current approach is a good proof of concept. it's great that new formats are much faster than legacy swscale almost for free. continuation passing style could make things even faster. but in the end we are almost certain that the compilers will screw something up (no matter what technique we employ), where we can write manual assembly code that's faster.
<haasn>
right
<haasn>
Well, the idea right now is to use compiler output to develop a proof of concept for what the overall structure will look like
<haasn>
and then we can transition to asm code that does the same
<ramiro>
haasn: did you see the results from mingw-w64 using godbolt?
<haasn>
on my latest?
<ramiro>
haasn: I tested on the link you gave me above
<haasn>
yeah, I don't trust this approach at all
<haasn>
except to give us some performance figures as a baseline for what to expect from custom asm
Guest99 has joined #ffmpeg-devel
grillo_0 has quit [Quit: Ping timeout (120 seconds)]
grillo_0 has joined #ffmpeg-devel
cone-896 has quit [Quit: transmission timeout]
Guest99 has quit [Quit: Client closed]
cone-391 has joined #ffmpeg-devel
<cone-391>
ffmpeg Andreas Rheinhardt master:a6c58450da2a: all: Fix doxy comments wrongly designated as trailing ///<
<cone-391>
ffmpeg Andreas Rheinhardt master:fcd5df59047d: fftools/ffmpeg_opt: Remove unused alt_bsf
<cone-391>
ffmpeg Andreas Rheinhardt master:e99faf28d586: avcodec/vc2enc: Avoid excessive inlining
<cone-391>
ffmpeg Andreas Rheinhardt master:8abac5898ba5: avcodec/sbcdec_data: Merge data into header
<cone-391>
ffmpeg Andreas Rheinhardt master:34aa8449b816: avcodec/pthread*: Mark init, free, flush functions as av_cold
jamrial has quit [Read error: Connection reset by peer]
<JEEB>
ayup, that's a known issue with zlib-ng not being bitexact with zlib :D
<grillo_0>
:D
<JEEB>
you can see that the size of the result went up, basically. and that codec utilizes zlib to compress
<JEEB>
I recall there should still be the old zlib devel package around
<JEEB>
and the library I think
<JEEB>
meh, on 41 at least I can't find another zlib-something :/
<JEEB>
I work around it by more or less knowing which tests will have differences, and just always having GEN=1
<JEEB>
which is annoying
<JEEB>
but yea, unfortunately our tests have stuff which has quietly been ok for decades just because zlib was a static target with the way we used its API
<JEEB>
and nobody wants to reimplement the parts of zlib we require in FFmpeg itself
<JEEB>
but yea, GEN=1 will cause all the references that have changes be written into the repo, and thus you need to check `git diff --word-diff=color` to then check if those tests seem to match zlib specific stuff
<grillo_0>
on 40 it doesn't seem to exist either. What GEN=1 does?
<JEEB>
regenerate references :)
<grillo_0>
oh I see
<JEEB>
so it will not stop at the first difference in results
<fflogger>
[editedticket] Balling: Ticket #10775 ([ffmpeg] FFmpeg omitting the CODECS attribute again with hevc_nvenc and libx265) updated https://trac.ffmpeg.org/ticket/10775#comment:4
<ramiro>
JEEB: "nobody wants to reimplement the parts of zlib we require in FFmpeg itself" <- we could make this a gsoc qualification task.
<grillo_0>
Do I need to add the [FFmpeg-devel] tag to the email subject?
<another|>
no
vyasa has joined #ffmpeg-devel
vyasa has quit [Quit: vyasa]
vyasa has joined #ffmpeg-devel
vyasa has quit [Quit: leaving]
cone-391 has quit [Quit: transmission timeout]
<mkver>
grillo_0 JEEB: IGNORE_TESTS (or rather ./configure --ignore-tests) is much better than GEN=1.
<JEEB>
I should get used to that
<jamrial>
i just run make -k when i want a fate test failure to be ignored
<JEEB>
yea but you want to catch *your* failures
<JEEB>
but not the zlib vs zlib-ng induced ones
<jamrial>
oh right, we're still dealing with that
<JEEB>
yea
<mkver>
Why don't we just use zero-compression when the bitexact flag is set?
vyasa has joined #ffmpeg-devel
<JEEB>
someone tried that but there was something wonky with some version of zlib or something?
<jamrial>
mkver: we tried that, but an old version of zlib produces a different result
<mkver>
We could write our own zlib library for zero-compression. In fact, it already exists in flashsv2_prime() in flashsv.c.
<jamrial>
that was suggested, but nobody implemented it yet
<JEEB>
at least in the things I read the suggestion was to implement what FFmpeg needs
<JEEB>
also nice if we already have it
<mkver>
Another question: Is there a reason to prefer struct {int16_t foo; int16_t bar;} to struct {int16_t foo; int8_t bar;} when bar is known to be in the range of int8_t? Or in other words, are most arches better at int8_t->int than int16_t->int promotions?
<compnnn>
BtbN, are our mailing lists being used to spam a bunch of healthcare emails in florida ?
<compnnn>
i got a few mails to -owner on mplayer side
<compnnn>
is there some kind of 'you only get one confirm email' option ?
<compnnn>
because that needs to be enabled.
<JEEB>
mkver: unfortunately I'm not too knowledge'able in the exact performance. personally since C doesn't have a separate min/max value limitation thing, I'd just utilize the smallest variable type that fits all relevant value ranges.
vyasa has quit [Quit: leaving]
<compnnn>
BtbN : bonus points if you can enable it for all mailinglists too. :(
<compnnn>
i mean mplayer ones and all mailman lists
minimal has joined #ffmpeg-devel
<compnnn>
BtbN, also , theres a bunch of mplayer lists that can be disabled fully. no activity in years
<jkqxz>
mkver: It won't make any difference for that direction - the sign extension will typically be on the load, and the load will be from nearby cache.
<mkver>
But is sign-extending eight bits the same performance as sign extending 16 bits (not only for x86, but for all common arches)?
<BtbN>
compnnn: I don't know the mailman admin password, so I can only do what limited things the CLI can do, like add/remover members or entire lists
<jkqxz>
Yes.
<jkqxz>
For the other direction it could theoretically make a difference if there is a different-width access nearby (like a memcpy) which ends up needing to fetch the missed byte separately, but in practice I very much doubt it.
<compnnn>
BtbN, can you check subscription request logs for ffmpeg-devel ?
<mkver>
jkqxz: Thanks. Another question: clCreateProgramWithSource takes a const char**. I presume it does not modify the array of pointers at all, does it?
<BtbN>
compnnn: I'm not aware of there being such logs
<compnnn>
BtbN, likewise. no mailman activity log at all eh? :\
<BtbN>
Just postfix
<compnnn>
super annoying
* compnnn
temporarily enables approval of new subscribers
<compnnn>
not seeing the same activity as the mplayer lists yet at least
paulk has quit [Ping timeout: 252 seconds]
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
<compnnn>
BtbN, thanks for looking at it
<compnnn>
undid admin approve of subscriptions. i dont see anything wrong. why did they use mplayer lists like that really annoying
<BtbN>
It's just spammers... Even Paypal gets mass-abused for that nowadays...
<compnnn>
BtbN, : removing entire lists removes the archives too?
ccawley2011 has joined #ffmpeg-devel
<compnnn>
i'd guess yes. i didnt find anything about disabling a list in mailman googling
<BtbN>
Not sure if it deletes them, but they would at least get inaccessible
<compnnn>
only unfulfilled bugreports
<BtbN>
keep in mind, this is also mailman2
<BtbN>
super ancient
<jkqxz>
mkver: On clCreateProgramWithSource, no it does not. I don't know why it is missing the second const, maybe there is some compatibility reason. (But not the obvious one, since they made the opposite choice to execve.)
<mkver>
jkqxz: Thanks.
<jamrial>
BtbN: can it be upgraded? it might help fixing the mangling of signed mails sent by thunderbird
<BtbN>
jamrial: there is no upgrade path from mailman2 to 3
<compnnn>
mailman will be destroyed :D
<jamrial>
oh well
<BtbN>
it'd be a "recreate lists and resubscribe same members" kinda thing
<BtbN>
eventually we will HAVE to do that
<BtbN>
It's running on Ubuntu 20.04, and is written in python2...