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
BradleyS_ has joined #ffmpeg-devel
BradleyS has quit [Ping timeout: 268 seconds]
BradleyS_ is now known as BradleyS
<kierank>
Trac doesn't load any more
<kasper93>
BtbN: would it be possible to map <20000 to trac now?
<BtbN>
trac is doing something expensive again, all workers busy...
<BtbN>
kasper93: not with Forgejo, no
<BtbN>
I could hack something like that into the reverse proxy
<BtbN>
I also thought about importing the trac issues into Forgejo, but that'd get very messy. Should it create a user for every e-mail on trac?
<BtbN>
Or just dump the entire conversation into the initial issue?
<BtbN>
Post from a generic user, mentioning the original poster in the post?
<BtbN>
All pretty ugly
<kasper93>
yeah, it get's ugly fast
iive has quit [Quit: They came for me...]
<kasper93>
most complete way would be to transition everything, but I also like "start fresh" approach to avoid importing 10k of issues
<BtbN>
the approach of redirecting issues <20k via reverse proxy to trac, and keeping it read-only is the nicest for sure
<BtbN>
And then making the new issue page there redirect to Forgejo
<BtbN>
Can someone reply something to any PR or issue on the FFmpeg repo? I want to test incoming mail.
<jamrial>
BtbN: just did
<BtbN>
yep, works. Can just reply to the mail
<BtbN>
Just need to make sure to hit the right reply button, depending on the mail client
<BtbN>
On Thunderbird it's "Reply List"
<jamrial>
wonder why that's needed if there's a reply-to header
<BtbN>
yeah, imo Thunderbird picks the wrong address when I hit just "Reply"
<BtbN>
It wants to send to code@ffmpeg.org by default
<BtbN>
With the name of whoever caused the mail in front
indecisiveturtle has quit [Ping timeout: 276 seconds]
mkver has joined #ffmpeg-devel
s55 has quit [Quit: Bye]
s55 has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Read error: Connection reset by peer]
MisterMinister has quit [Ping timeout: 260 seconds]
<fflogger>
[newticket] bl1nch: Ticket #11676 ([ffmpeg] Broken video decoding on Android TV boxes with MediaCodec) created https://trac.ffmpeg.org/ticket/11676
<Traneptora>
how do I turn off the forejo emails for issues and patches I have nothing to do with
<Traneptora>
it looks like I'm autosubscribed to new PRs and stuff
cone-068 has joined #ffmpeg-devel
<cone-068>
ffmpeg Leo Izen master:829680f96a7a: avcodec/jpegxl_parser: add sanity check for frame size
<kierank>
TheVibeCoder: do you have this masterpiece in librempeg?
<TheVibeCoder>
yes
indecisiveturtle has joined #ffmpeg-devel
<haasn>
so can I start submitting my PRs to forgejo without also duplicating them to the ML?
minimal has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
<BtbN>
That's the idea, yeah, haasn
<BtbN>
Can't merge them there yet, but working on that
<BtbN>
And yeah, every org member is auto subscribed
<BtbN>
You can unsubscribe on the repo page
<BtbN>
Though you also get every activity on the ML, so it makes some sense
<BtbN>
I've filtered them all into their own folder
<nevcairiel>
I was going to ask if we should confirm our identities or something, but seems like you already added me to the org anyway =P
mark4o has joined #ffmpeg-devel
markh has quit [Ping timeout: 248 seconds]
mark4o is now known as markh
<haasn>
`ffmpeg -f lavfi -i smptehdbars -vf showinfo -color_range pc -colorspace bt709 -chroma_sample_location topleft -vframes 1 -y test.h264` is it expected that `color_range` and `colorspace` are tagged correctly, but `chroma_sample_location` gets ignored (overridden by the frame properties)?
<haasn>
maybe we should override these properties only if they are set to `unspecified` on the enc_ctx
<JEEB>
I don't recall that was an issue when I added support for frame values to be utilized, but then I think when elenril reworked it, he made settings be set first, and then frame stuff
<haasn>
as for why color_range etc work, it's because it's overriden also on the frame via the frame filter graph in ffmpeg_filter.c
<haasn>
but the filter graph doesn't have signalling/negotiation for the chroma location
<JEEB>
in theory setting it before the input would work, but I think we prefer frame values to context values as the frame values can update
<JEEB>
the whole "was this set by the component or was this a user override?" thing
<haasn>
right
<JEEB>
I think I just utilize the setparams or whatever video filter
<JEEB>
to set specific stuff so it then comes out of the filter chain correctly
<haasn>
maybe that's what we should do in this case also
<haasn>
i.e. insert a setparams filter in ffmpeg_filter.c
<haasn>
JEEB: well, this is enc_open()
<haasn>
I don't think midstream changing parameters are a consideration
<haasn>
it's only ever called on initial stream init
<haasn>
I think I will make it override by the frame properties only if the user left it unspecified
<haasn>
at least for the properties which are not negotiated anyway
<JEEB>
haasn: yea I was just noting that with regards to what probably happens if you try to override on input side
<JEEB>
since in theory if you want to override input's values the correct location would be at the start, not the end
<JEEB>
haasn: yea too bad we don't have a system where we could check whether the value was set by a user or not. because otherwise you cannot explicitly override to unspec :D
<haasn>
true
<JEEB>
(which is a minor case of course, but just highlights the issues of "just applying the AVOptions and calling it a day"
<haasn>
but probably not a case worth losing sleep over
<haasn>
you can still use setparams for that
<JEEB>
yea
<JEEB>
I think I somewhere abused AVOptions by initiating the struct value to something outside of the official range
<JEEB>
and then if it was within the official range, that was then set by a user :P
<haasn>
the strange thing is, I can never actually get frame->chroma_location to be anything other than UNSPECIFIED here
<haasn>
I.. huh
<haasn>
there are so many things wrong here
<haasn>
buffersrc universally ignores chroma location tagging on its input also
<haasn>
so chroma location is just literally never propagated through `ffmpeg` ever
<haasn>
vf_scale rather
<haasn>
JEEB: vf_scale also has the issue where you can't distinguish between auto and unspecified
<haasn>
though fortunately that one would be easier to fix by just making auto = -1
<JEEB>
yea
<haasn>
there we go
<haasn>
[vost#0:0/libx264 @ 0x297a6a40] [enc:libx264 @ 0x2970c940] Requested chroma sample location 'center' does not match the frame tagged sample location 'left'; result may be incorrect.
<haasn>
ffmpeg -i foo.mp4 -chroma_sample_location center out.h264
<haasn>
seem good?
devinheitmueller has joined #ffmpeg-devel
cone-068 has quit [Quit: transmission timeout]
paulk has quit [Ping timeout: 260 seconds]
paulk has joined #ffmpeg-devel
Kei_N has joined #ffmpeg-devel
Kei_N_ has quit [Ping timeout: 268 seconds]
leo60228 has joined #ffmpeg-devel
vriska has quit [Ping timeout: 272 seconds]
LainIwakura has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
devinheitmueller has quit [Quit: devinheitmueller]
<kasper93>
what is the difference between color_primaries=unknown and chroma_location=unspecified ? Is there distinction between `unknown` and `unspecified`?
<deeyes>
hitting “static surface pool size exceeded” during avcodec_send_packet with D3D11VA decode — can’t bump extra_hw_frames any further due to hardware limits. tried a retry loop (50 max) in get_buffer, works well, but upstream says it’s the wrong place — should be handled at user level. is there a way to handle it in a better way? since the error is being triggered from within avcodec_send_packet, not sure how else to
<kierank>
17:01:47 <kasper93> what is the difference between color_primaries=unknown and chroma_location=unspecified ? Is there distinction between `unknown` and `unspecified`?
<kierank>
it's some smpte spec lawyer BS
<Lynne>
on a related topic, I still don't know what to tag the output of the prores raw decoder
<TheVibeCoder>
RESERVED
<Lynne>
I leave it unspecified since you really need to use vendor-provided LUTs to make sense of the data
<Lynne>
TheVibeCoder: btw, have you figured out what the very first function call in decode_components in the decompiled version does?
<Lynne>
I see its responsible for setting the scale
<fflogger>
[newticket] gbr: Ticket #11677 ([undetermined] ffplay does not properly sync LRC subtitles with 3-digit milliseconds) created https://trac.ffmpeg.org/ticket/11677
<Lynne>
and reads at offset 0x10 (16) in the bitstream of each slice
<Lynne>
but that's DC territorry, the slice header is only 10 bytes long (total size, qscale, comp1, comp2, comp3, each 2 bytes)
<nevcairiel>
deeyes: best place from my point of view would probably be the actual ffmpeg cli tool, because that can guarantee a certain threading model that can actually result in surfaces being free'ed over time and make waiting meaningful - which means, get_buffer in ffmpeg_dec.c
<TheVibeCoder>
Lynne: dunno, never bothered
<Lynne>
I'll figure it out
LainIwakura has quit [Ping timeout: 272 seconds]
deeyes has quit [Read error: Connection reset by peer]
dliu has joined #ffmpeg-devel
dliu is now known as desmond-netint
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
averne has quit [Quit: quit]
___nick___ has joined #ffmpeg-devel
averne has joined #ffmpeg-devel
averne has quit [Quit: quit]
averne has joined #ffmpeg-devel
<fflogger>
[editedticket] kasper93: Ticket #11677 ([undetermined] ffplay does not properly sync LRC subtitles with 3-digit milliseconds) updated https://trac.ffmpeg.org/ticket/11677#comment:1
<fflogger>
[editedticket] Cigaes: Ticket #11677 ([undetermined] ffplay does not properly sync LRC subtitles with 3-digit milliseconds) updated https://trac.ffmpeg.org/ticket/11677#comment:2
<JEEB>
would not be surprised if you could configure a web hook for events and then use a generic IRC thing to interpret those hooks. but if a simpler directly integrating thing exists, that sounds good too
<BtbN>
That thing is written in _D_ oO
<BtbN>
I could probably just extend fflogger to properly parse webhooks
<BtbN>
Right now it has an ultra crude "HTTP API" where it just echoes anything POSTed to it to the channel
<JEEB>
:)
<Lynne>
you could also create an account, subscribe to a repo, and just echo out each email that arrives on the channel
<Lynne>
just not the ones it gets if someone resets the password :)
<fflogger>
[editedticket] gbr: Ticket #11677 ([undetermined] ffplay does not properly sync LRC subtitles with 3-digit milliseconds) updated https://trac.ffmpeg.org/ticket/11677#comment:6
<BtbN>
Lynne: that seems already over-engineered
<BtbN>
webhook that sends the bot JSON with the events seems much better
<toots5446>
Hi all! Happy to read that the project is moving forward with code.f.o! I've created a PR with that one missing patch from the ogg parsing series. @mkver: do you still intent to review it? Would that help? It's been lingering for almost two months now, it would be great to see if it could be merged in time for the release. Otherwise the ogg parsing patchset would be incomplete for this
<toots5446>
release.
<toots5446>
I've incorporated most of the your feedback in it, in particular the use of `avpriv_split_xiph_headers` for storing the extradata. I was hoping this would be a straight shot given that it's been done in close coordination.
indecisiveturtle has quit [Ping timeout: 260 seconds]
indecisiveturtle has joined #ffmpeg-devel
<kasper93>
if I set avpriv_set_pts_info() in write_header(), do I need to care about pkt->time_base in write_packet()? Or it nothing will override this?
<kasper93>
looking at the existing code, nothing touches it
<BtbN>
hm, I'd have hoped it does not post every PR run
<kasper93>
maybe only failures, but still probably too verbose
<BtbN>
it is only failures and recoveries
<kasper93>
and sure I can add manually a step, but we probably should have some standarized pipeline for that, it will be common that new fate sampels are missing
<BtbN>
I only want it to post for the master branch