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
\\Mr_C\\ has quit [Remote host closed the connection]
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
srikanth has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<fflogger>
[editedticket] idest: Ticket #11433 ([undetermined] "Error parsing Opus packet header" when extracting Opus audio stream) updated https://trac.ffmpeg.org/ticket/11433#comment:2
stupidoo has joined #ffmpeg-devel
zsoltiv has quit [Ping timeout: 252 seconds]
stupidoo62 has joined #ffmpeg-devel
stupidoo62 has quit [Client Quit]
zsoltiv_ has quit [Ping timeout: 272 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
stupidoo has quit [Quit: Client closed]
stupidoo has joined #ffmpeg-devel
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
^Neo has quit [Ping timeout: 260 seconds]
tufei_ has joined #ffmpeg-devel
<fflogger>
[editedticket] MasterQuestionable: Ticket #11436 ([ffmpeg] swscale rejects files with reserved colorspace tags after filter reinit) updated https://trac.ffmpeg.org/ticket/11436#comment:8
mkver has quit [Ping timeout: 248 seconds]
jamrial has quit []
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<fflogger>
[editedticket] MasterQuestionable: Ticket #11433 ([avcodec] Innocuous "Error parsing Opus packet header" on YouTube sources?) updated https://trac.ffmpeg.org/ticket/11433#comment:3
<Marth64>
apologies for the html mail, was migrating clients
kierank has quit [Ping timeout: 245 seconds]
kierank has joined #ffmpeg-devel
<Compn>
Marth64, are you able to set -r on #ffmpeg ?
<Compn>
in general its to keep out the spammers
<Marth64>
Hi Compn, I think I can, I don't think its a good idea tbh...probably better to put +r here, keep it consistent, and add (need registered nick) to the doc is my take
<Marth64>
as in, I think +r is good thing
<Compn>
i understand :)
<Compn>
i dont like those web irc interfaces because they timeout and people have about 0.3 seconds to respond or "no one talked to me so i left"
System_Error has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
abdu has quit [Quit: Client closed]
abdu has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
mcfrdy has quit [Quit: quit]
MyNetAz has quit [Remote host closed the connection]
<another|>
thilo: Will you be at FOSDEM?
MyNetAz has joined #ffmpeg-devel
ngaullier has quit [Remote host closed the connection]
ngaullier has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has joined #ffmpeg-devel
^Neo has quit [Changing host]
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 245 seconds]
rvalue- is now known as rvalue
JavascriptLeader has joined #ffmpeg-devel
abdu21 has joined #ffmpeg-devel
abdu has quit [Ping timeout: 240 seconds]
jamrial has joined #ffmpeg-devel
ccawley2011_ has joined #ffmpeg-devel
abdu60 has joined #ffmpeg-devel
<JavascriptLeader>
does anyone here use cedocida DV/DVCPRO25/50 encoding via virtualdub(2) ?
<JavascriptLeader>
i cant encode anything with it, it errors out all the time
abdu21 has quit [Ping timeout: 240 seconds]
ccawley2011_ has quit [Ping timeout: 272 seconds]
cone-908 has quit [Quit: transmission timeout]
<jamrial>
mkver: are you ok with the frame side data patchset outside of the param change commit?
<jamrial>
as in, the changes that make the buffer backing opaque so we can start adding side data types that are not just flat arrays
<mkver>
jamrial: It seems like it wants to increase .data.rel.ro.
<jamrial>
well yes, the extra fields in the props struct and the callbacks are needed
<mkver>
I don't really see the need for "not just flat arrays" atm.
<jamrial>
we don't need it now, but we will eventually, and it's IMO better to have it in place now than trying to rebase this set down the line
<mkver>
I am not so sure on that.
<jamrial>
why?
<mkver>
Because we managed to do without it for so long?
<jamrial>
"we didn't need it until now" is a weird argument against the statement that we may need it in the future...
<jamrial>
we had to workaround this limitation in types like video_enc_params and others, were we allocate space for a variable number of extra structs past the end of the "main" struct
<jamrial>
so it's not like it has never been an issue people had to deal with somehow
<jamrial>
and look at the type i tried to add. you can't add a dictionary to a struct meant to be stored as a flat array, even if you serialize it as a string
<mkver>
We can. All you need is a length field; or an offset field.
Marth64 has joined #ffmpeg-devel
<mkver>
(Btw: AVFrameSideData already contains an AVDictionary. I am actually surprised that you didn't use it.)
ccawley2011_ has joined #ffmpeg-devel
<jamrial>
"metadata" is not a type-specific defined field, afaik
<jamrial>
i can't just use it to pass encoder configuration parameters in one type
cone-161 has joined #ffmpeg-devel
<cone-161>
ffmpeg James Almer master:02958ab7156b: avformat/mov: fix overflow in drift timestamp calculation
<ePirat>
this comes from ffmpeg git but I suspect it does not actually use the files from the git repo to generate all of it…
<BtbN>
hm, that part I never looked at
<BtbN>
But also nothing looks immediately wrong to me? What exactly is missing
<ePirat>
at least I am not sure why it would not match what I get locally else…
<ePirat>
BtbN, if you look at doc/developer.texi in the Examples section you see for example `@example c, good`
<ePirat>
but those do not end up in the generated html code as classes
<fflogger>
[editedticket] Gyan: Ticket #11439 ([ffmpeg] Please add a byte offset option (like -sb in mplayer) in ffmpeg, ffplay, ffprobe.) updated https://trac.ffmpeg.org/ticket/11439#comment:2
<ePirat>
BtbN, also the CSS changes do not actually seem to be on the server
<ePirat>
so I guess those needs to be manually synced somehow
<fflogger>
[editedticket] sha8: Ticket #11439 ([ffmpeg] Please add a byte offset option (like -sb in mplayer) in ffmpeg, ffplay, ffprobe.) updated https://trac.ffmpeg.org/ticket/11439#comment:3
<fflogger>
[editedticket] Gyan: Ticket #11439 ([ffmpeg] Please add a byte offset option (like -sb in mplayer) in ffmpeg, ffplay, ffprobe.) updated https://trac.ffmpeg.org/ticket/11439#comment:4
<galad>
ePirat: is setting a CGColorSpace in vt_pixbuf_set_colorspace like it was added in cd9ceae needed for something? It shouldn't be needed for the other videotoolbox filters. I've got HandBrake running hw dec -> 10 Metal filters -> hw enc, and 25% of the cpu time is spent in vt_pixbuf_set_attachments() doing nothing useful :|
<ePirat>
galad, yes
<ePirat>
without it the frame lacks proper metadata and you get wrong processing/encoding when you have a VT-only pipeline
<galad>
Isn't the color tag enough?
<ePirat>
which color tag do you mean?
<galad>
primaries/transfer/matrix
<ePirat>
from my testing, no
DauntlessOne4 has joined #ffmpeg-devel
<ePirat>
galad, whats taking so long in vt_pixbuf_set_attachments?
rvalue has quit [Remote host closed the connection]
<galad>
mostly the creation of a CGColorSpaceRef from primaries/transfer/matrix
rvalue has joined #ffmpeg-devel
<galad>
but the whole attachments implementation of CoreMedia/VideoToolbox/etc is soooo slow
<ePirat>
galad, but also it should only be happening one for each frame, no?
<ePirat>
*once
<galad>
right, but once is still slow enough when you are decoding and encoding 300 frames each second
<ePirat>
actually maybe its fine to have the CGColorSpaceRef unset, I dont fully remember. IIRC VT returned frames with it set incorrectly so I set it to the right one but maybe unsetting it and just setting primaries/transfer/matrix is fine…
<ePirat>
I can try to have another look during FOSDEM
<galad>
I've got my own implementation of the VT filters in HandBrake, and they seem to work even without CGColorSpaceRef
<ePirat>
are you using CIFilters?
<galad>
well, VTPixelTransferSession is horrible broken, and can't scale chroma correctly, but that's another issue
<ePirat>
galad, have an upstream bug for that?
<galad>
yes, Apple knows, the first answer was something like: "it has been broken for so long and apps might depend on it being broken so we won't fix it", the second was "hopefully we will fix it soner than later"
abdu60 has quit [Ping timeout: 240 seconds]
<galad>
ePirat: mainly some Metal filters ported from FFmpeg OpenCL/CUDA filters, some custom made, and VTPixelTransferSession /VTPixelRotationSession
abdu60 has joined #ffmpeg-devel
<ePirat>
galad, I will check again if we can just not set it, and if not, it probably makes sense to cache the CGColorSpaceRef and not make one per frame
<jamrial>
Lynne: ffv1 multithreaded decoding is broken
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
<michaelni>
BtbN, look at ffcrontexi on the server, that builds the parts from texi files. we generally dont run anything excutable from git to limit the impact of a potential security issue.
srikanth has joined #ffmpeg-devel
abdu60 has quit [Quit: Client closed]
srikanth has quit [Ping timeout: 265 seconds]
abdu60 has joined #ffmpeg-devel
srikanth has joined #ffmpeg-devel
JavascriptLeader has quit [Quit: Client closed]
System_Error has quit [Remote host closed the connection]
cone-161 has quit [Quit: transmission timeout]
ngaullier has quit [Remote host closed the connection]
JavascriptLeader has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
srikanth has joined #ffmpeg-devel
<ePirat>
michaelni, it seems recently coverity has issues figuring out what av_frame_unref is doing? It claims opaque_ref is not freed even tho I don't see a way how that would be the case
<haasn>
I plan on adding fast paths only for speed regressions for now
<haasn>
this is going through the generic path
<haasn>
and still faster than swscale
MyNetAz has quit [Remote host closed the connection]
System_Error has quit [Remote host closed the connection]
MyNetAz has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
<ePirat>
michaelni, I'll check
<ePirat>
michaelni, is there a way to test this other than building and submitting to coverity?
srikanth has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<michaelni>
ePirat, thats a good question. I generally just uploaded it and checked what happened. But i guess theres probably some way
<ePirat>
I think I would have to build with the coverity tool thing and upload that
<jamrial>
BtbN: did they fix the alpha parameter sets missing from extradata?
<BtbN>
no, but they said it's on their list for after the rush for SDK 13
<michaelni>
ePirat, if you post some changed version to the ML and ping me, i can upload it to coverity before its pushed to git so the next automated coverity build would use it
<ePirat>
michaelni, ok I will see if I have time to look into it during fosdem at some point
<JavascriptLeader>
haasn: i cant make bilinear scaling fast with pure C and clang, its >4x times slower
<BtbN>
Just tell the clang devs, they are usually very interested in fixing stuff like that
<haasn>
JavascriptLeader: I can try that next
<haasn>
was planning on doing bit depth conversions next
<JavascriptLeader>
BtbN: is this a joke?
<BtbN>
no, why would it be?
<BtbN>
clang being drastically slower than gcc for the same code screams bug
<BtbN>
assuming gcc disn't miscompile it
<JavascriptLeader>
let me check how gcc behaves
<JavascriptLeader>
188x clang - 161x gcc
<haasn>
JavascriptLeader: is this for 2x2 upscaling or just h/v?
<JavascriptLeader>
831x current sws
<JavascriptLeader>
generic scaling, no fixed offsets
<JavascriptLeader>
i bet hardcoded 2x2 would be supported by clang
<haasn>
generic scaling with arbitrary filter weights?
<JavascriptLeader>
yes, weights are dynamic, sort of, even if there are repeated patterns/calculations
<JavascriptLeader>
but this results are normal as i do not see SIMD used at all
<JavascriptLeader>
perhaps better way to write bilinear scaler is to first pick/collect all component source pixels in 8x8 block and than do interpolation
<jamrial>
BtbN: you should probably look for AV_FRAME_DATA_VIEW_ID too
<BtbN>
I'm not the author of those patches mostly, so best reply on the ML
<BtbN>
I actually prefer to ignore that "no brackets for single line block" rule when the block has other blocks attached to it. It just looks super wonky when you have if() something(); else { somethingelse(); }
<JavascriptLeader>
using block[4*4] to collect pixels, goes from 188x to 225x
<JavascriptLeader>
still >3 slower
<JavascriptLeader>
the fixed weight s could be probably generated in smarter way
<haasn>
you are comparing against swscale generic weight code or against swscale fixed bilinear pattern?
<JavascriptLeader>
the sws_flags=bilinear/fast_bilinear are > 10x faster
<JavascriptLeader>
same with bilinear, rescale=2k:linear goes bellow 100, barelely reaches 93 fps
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #ffmpeg-devel
paulk has joined #ffmpeg-devel
paulk has quit [Changing host]
abdu60 has quit [Quit: Client closed]
abdu60 has joined #ffmpeg-devel
srikanth has joined #ffmpeg-devel
abdu26 has joined #ffmpeg-devel
abdu60 has quit [Ping timeout: 240 seconds]
<BtbN>
jamrial: which of the two should win, if both are there?
JavascriptLeader has quit [Quit: Client closed]
System_Error has quit [Remote host closed the connection]
<jamrial>
BtbN: one reports a number, the other reports what eye that number represents, so they don't contradict each other (or shouldn't)
abdu75 has joined #ffmpeg-devel
<BtbN>
oh, it's to fill in specifically those two fields
abdu26 has quit [Ping timeout: 240 seconds]
System_Error has joined #ffmpeg-devel
cone-842 has quit [Quit: transmission timeout]
<BtbN>
jamrial: something I was wondering about that patch is how the display_sei is default-disabled. It seems relatively essential?
<jamrial>
yeah, i mentioned as much
<jamrial>
the apple spec says that sei is mandatory
<BtbN>
Yeah, I'm gonna remove the option for it
<BtbN>
I'm still not super sure how AV_FRAME_DATA_VIEW_ID and AV_FRAME_DATA_STEREO3D interact. By the looks of it, both have to be present to be able to deduce all the required info?
abdu77 has joined #ffmpeg-devel
abdu75 has quit [Ping timeout: 240 seconds]
<BtbN>
jamrial: I don't see how to possibly make use of AV_PROFILE_HEVC_MULTIVIEW_MAIN though. nvencs profile is set via the NV_ENC_HEVC_PROFILE_*, and they don't have one for multiview
<BtbN>
Though I could invent one I guess. But is that better than just a toggle?
<jamrial>
BtbN: but you can set profile in avctx, right? so even if we don't map it, it can check for it
<jamrial>
i just rather not add more bool options
<BtbN>
it sets the profile in avctx based on what NV_ENC_HEVC_PROFILE was set
<BtbN>
not the other way around
<jamrial>
ah
<BtbN>
Though we define the enum in nvenc.h, since it uses GUIDs
<JEEB>
the first AVFrame's side data is available for encoders to utilize at init
<BtbN>
so we could invent a NV_ENC_HEVC_PROFILE_MULTIVIEW_MAIN
<JEEB>
if that helps figuring out how to init
<BtbN>
not sure if I'd want it to auto-detect that
<BtbN>
I'd prefer it to be some form of manual toggle
<JEEB>
is it that you're opting to not trust any side data or?
<BtbN>
More to avoid surprises
<JEEB>
because I kinda consider bugs in filters that don't strip side data bugs there
<JEEB>
and if the content tells me it has f.ex. HDR metadata at the point of encoder init, then that gets passed on
<BtbN>
As in, I wouldn't want nvenc to produce mvhevc without being explicitly told to do so
<JEEB>
just trying to think what the possible bad things from that would be... I think multiview extensions are backwards compatible, right?
<JEEB>
or is it more about "this information could be bollocks, so require the user to opt-in"
<JEEB>
but yea, this all of course depends on how well you can infer from the init point what sort of input you're getting
<BtbN>
If it's safe to add it, i.e. unaware decoders don't break, so it suddenly appearing isn't an ABI break, it's probably fine
<JEEB>
since IIRC it utilizes a separate layer id, and decoders should by default ignore those that they don't know of I would expect that to be the case
<JEEB>
will have to quickly ddg a sample to just stick it at d3d11
* JEEB
has a GTX 1080 which most definitely has no idea about alternative layer ids
stupidoo has quit [Quit: Client closed]
stupidoo has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
<BtbN>
So multiview only works for simple 8bit content?
System_Error has joined #ffmpeg-devel
<JEEB>
lol, I no longer can browse fate-suite.ffmpeg.org because HSTS is on and the TLS cert doesn't have the fate-suite subdomain in it
<kierank>
lol
<JEEB>
BtbN: I think the 8bit thing with apple is due to them having to repurpose some 8bit only capable coding logic somewhere
<JEEB>
it is not inherent limitation of the multi-layer stuff
<JEEB>
and yea, even apple's own doc on it (possibly before it was published as the final edition in H.265) mentions both main and main 10 profiles and 8 and 10 bit depths
<JEEB>
so I would not be surprised if they can decode 10bit, but iphones can only encode 1080p 8bit
stupidoo has quit [Quit: Client closed]
<BtbN>
wtf is this letsencrypt setup on ffmpeg.org. It's some semi home-cooked shell script in someones homedir, and I added the domain to the list, but it's ignored. I grepped what reads that list, and the result is nothing. The domains aren't mentioned anywhere else tho. What.
<BtbN>
entirely not sure how to properly assign leftViewId/rightViewId, so I took a guess
fflogger has quit [Remote host closed the connection]
fflogger has joined #ffmpeg-devel
Compn has quit [Ping timeout: 244 seconds]
mkver has quit [Ping timeout: 265 seconds]
<jamrial>
BtbN: the 3drefdisplayinfo stuff is supposed to show up once, alongside the parameter sets
<jamrial>
weird that you need to set it up on every frame
<BtbN>
It's a parameter on the frame in nvenc, yeah, not on the encoder
<jamrial>
it's meant to be constant for the coded video, since it tells you which view is left and right
<BtbN>
I'm still curious where to get that info from from the side data
<BtbN>
Cause AVStereo3D is very much per-frame
<jamrial>
yeah. the frame should have stereo side data saying view left or right, and view side data with an int. so you look at both and map it
<BtbN>
I guess that's essentially what I did?
<jamrial>
i see you look for the view id side data and set ctx->next_view_id to it, but then hardcode ref_disp_info.{left,right}ViewId to either 0 or 1
<jamrial>
the view id could be anything, really
<BtbN>
Well, but I have no idea to know any other view id but the one of the current frame
<jamrial>
yeah, that's a problem
<jamrial>
you'd need two frames to know the ids for both views
<BtbN>
There really should be some kind of per-stream side data for this stuff, that contains that info
<jamrial>
we may need to actually export the 3drefdisplayinfo stuff as global side data
<jamrial>
yeah
<BtbN>
I also feel like we'll have to add logic to nvenc to only send that display sei on the first frame
<BtbN>
My non-blackwell card actually says it support the MV HEVC stuff