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
vipyne has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
thilo_ has quit [Ping timeout: 265 seconds]
thilo_ has joined #ffmpeg-devel
thilo_ has joined #ffmpeg-devel
thilo_ has quit [Changing host]
feiw has quit [Ping timeout: 252 seconds]
feiw1 has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
vipyne has joined #ffmpeg-devel
vipyne has quit [Client Quit]
vipyne has joined #ffmpeg-devel
vipyne has quit [Quit: Leaving.]
arch1t3cht5 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 260 seconds]
arch1t3cht5 is now known as arch1t3cht
jamrial has quit []
MisterMinister has quit [Ping timeout: 265 seconds]
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 252 seconds]
feiw1 has quit [Ping timeout: 252 seconds]
feiw1 has joined #ffmpeg-devel
tufei__ has joined #ffmpeg-devel
tufei_ has quit [Remote host closed the connection]
feiw1 has quit [Ping timeout: 252 seconds]
feiw1 has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
haihao has quit [Ping timeout: 276 seconds]
haihao has joined #ffmpeg-devel
tufei__ has quit [Ping timeout: 260 seconds]
haihao has quit [Ping timeout: 244 seconds]
haihao has joined #ffmpeg-devel
cone-543 has joined #ffmpeg-devel
<cone-543>
ffmpeg Anton Khirnov master:840b95bcc229: fftools/cmdutils: do not treat single '-' as an option in locate_option()
<cone-543>
ffmpeg Anton Khirnov master:e56d676050d3: fftools/cmdutils: group related calls together
<cone-543>
ffmpeg Anton Khirnov master:181c20414538: fftools/ffmpeg_opt: add a struct to be passed as opaque to global-option handlers
<cone-543>
ffmpeg Anton Khirnov master:84c2ca6fa07e: fftools/ffmpeg_filter: do not leak graph_desc on fg_create() failure
<cone-543>
ffmpeg Anton Khirnov master:0f5592cfc737: fftools/ffmpeg: supply hw device context to probe-filtergraphs
ngaullier has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
System_Error has quit [Read error: Connection reset by peer]
System_Error has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
sgm has quit [Remote host closed the connection]
sgm has joined #ffmpeg-devel
elenril has quit [Ping timeout: 272 seconds]
zsoltiv_ has quit [Ping timeout: 246 seconds]
elenril has joined #ffmpeg-devel
<haasn>
michaelni: why is `int gamma_flag;` not just a member of sws_flags?
<haasn>
it defaults to 0
zsoltiv_ has joined #ffmpeg-devel
zsoltiv_ has quit [Ping timeout: 244 seconds]
zsoltiv_ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
cone-543 has quit [Quit: transmission timeout]
<michaelni>
haasn, i forgot that this code existed, there was also a redundant SWS_GAMMA_CORRECT that was removed in favor of the seperate flag. I guess with the space in the main flags being limited the idea was to split everything out over time. Or maybe to allow more than on/off like specifying a gamma value or maybe different algorithms or differenr precission, i dont remember
<michaelni>
also this implementation maybe is ok for 8bit and 10bit but for 16bit input theres a loss of precission
Krowl has quit [Read error: Connection reset by peer]
kasper93_ has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 276 seconds]
<haasn>
fair
<haasn>
I think I also prefer separate fielt
<haasn>
fields*
<haasn>
well, separate fields is more work for something like vf_scale or even cmdline options
<haasn>
otoh, I think that after we split scaler selection (which should have been an enum) out of sws_flags
<haasn>
suddenly space will no longer be limited
<haasn>
we are wasting most bits on mutually exclusive flags
kasper93_ is now known as kasper93
<haasn>
in libplacebo we name this flag something like "linear downscaling"
<haasn>
and it's a simple toggle
<haasn>
for upscaling we have a separate flag to enable optional sigmoidization
<haasn>
but both of these are booleans
<haasn>
there is the slight complication that for HDR, combining linear downscaling with a ringing kernel can produce very nasty side effects
<haasn>
there is also the question of whether or not this flag is supposed to apply to dithering also
<haasn>
gamma correct dithering is a pretty big deal at lower depths, but irrelevant otherwite
<haasn>
so in libplacebo I just have it force enabled for anything below 4 bits iirc
<haasn>
I'll leave the field untouched for now
<haasn>
until we decide how we want to handle these cases
jamrial has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<haasn>
michaelni: regarding the semantics change on SwsContext
<haasn>
I found a solution that I think is pretty elegant
<haasn>
basically, we deprecate sws_init_context(), and make sws_scale_frame() do the right thing when using it on an uninitialized context
<haasn>
if you call sws_init_context(), everything continues behaving as normal
<haasn>
that way we get backcompat for free while also reducing the overhead to just a bit of extra memory usage
<haasn>
since in the "dynamic" usage, you would just call sws_context_alloc(), set options, sws_scale_frame() and then sws_free_context()
<haasn>
sounds agreeable?
<michaelni>
for low depth, dither needs to consider gamma, mono looks very noticably wrong for example otherwise.
<michaelni>
using uninited context to switch sound good, yes
Krowl has quit [Read error: Connection reset by peer]
Krowl has joined #ffmpeg-devel
Kei_N_ has joined #ffmpeg-devel
Kei_N has quit [Ping timeout: 248 seconds]
ccawley2011 has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Workl5 has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 248 seconds]
Workl has quit [Ping timeout: 252 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
thilo_ has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg-devel
Workl5 has quit [Read error: Connection reset by peer]
vipyne has joined #ffmpeg-devel
<Marth64>
suppose I have a demuxer thats goal is to play DVD with full menu support. user navigates and selects a menu option (hack for now), and segment changes. i will throw AVERROR_INPUT_CHANGED. how is user application expected to react? should it call read_headers() again?
<Marth64>
at the end of day DVDs are navigated by remote with few simple commands (up/down/left/right/enter/angle/home)
<elenril>
there is a slight possibility avformat APIs are not the best for such a use-case
<Marth64>
understood
<elenril>
what actually changes in the header?
<Marth64>
streams, that is it
<elenril>
completely?
<Marth64>
duration i suppose
<Marth64>
yes
<elenril>
that is, old streams gone?
<Marth64>
yep
<elenril>
we don't have a mechanism for removing streams, or even marking them as finished
<elenril>
could add one I suppose
<Marth64>
got it. will ponder on this
<elenril>
I imagine outright removing streams will be very nasty
<Marth64>
marking as finished sounds nicer
<elenril>
then you have a potentially-ever-growing number of streams
<Marth64>
hmm
<elenril>
unless your demuxer is smart enough to revive previously-finished streams
<elenril>
which is not out of question, since it's kinda like a seek
<Marth64>
then i enter hack territory because new streams can be anything
<elenril>
isn't there a bounded number of streams within all possible menus?
<elenril>
>enter
<elenril>
heh
<Marth64>
there is bounded number of streams for both menu and video segments. params may change though
<Marth64>
however if i future extrapolate the principle to bluray it breaks down a bit in my head
<Lynne>
avtransport has a mechanism for removing old streams, so it would help to have this implemented
<Marth64>
i feel hls would benefit from this too
<Marth64>
dvd menu selection itself is a facade, its just a subtitle stream that activates whenever you navigate. so given a way to provide input (maybe a socket you can bind to with a limited command set) the only large outstanding puzzle piece is a way to dynamically change stream set
<Marth64>
i would consider selection with a mouse as out of scope/hack
<Marth64>
is AVTransport proof of concept / theory only right now?
Krowl has joined #ffmpeg-devel
<Lynne>
no, there's code
<Lynne>
its pretty much finished, spec and implementation wise, I just need to settle on LDPC tables to burn into the spec
rvalue- has joined #ffmpeg-devel
<Marth64>
neat
<Lynne>
the only part which I'm not comfortable with currently is the FEC implementation, its experimental and no one has done anything similar
rvalue has quit [Ping timeout: 252 seconds]
<Lynne>
its not completely radical and there's no reason for it to not work at least as efficiently as other FEC systems
<Lynne>
but its still new
___nick___ has quit [Ping timeout: 252 seconds]
<Marth64>
fec algorithms are not my area of expertise but if you want a pilot use case with dvd i'm game to try it out
<Marth64>
are chapter markers supported?
rvalue- is now known as rvalue
<Lynne>
yes, but I haven't hooked up the library to lavf yet
<Marth64>
got it
<Marth64>
happy to test for you down the road if anything needed
___nick___ has joined #ffmpeg-devel
<Lynne>
thanks
ngaullier has quit [Ping timeout: 276 seconds]
cone-250 has joined #ffmpeg-devel
<cone-250>
ffmpeg Michael Niedermayer master:b7ff66a35804: avcodec/ffv1enc: Prevent generation of files with broken slices
<cone-250>
ffmpeg Michael Niedermayer master:7bb283aa7bdc: avcodec/ffv1: Implement CRC with non zero initial and final value
Traneptora has quit [Quit: Quit]
kasper93_ has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 265 seconds]
Traneptora has joined #ffmpeg-devel
jamrial has quit [Read error: Connection reset by peer]