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 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
rvalue has quit [Ping timeout: 272 seconds]
iive has quit [Quit: They came for me...]
jess has quit []
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
lexano has quit [Ping timeout: 255 seconds]
philipl has quit [Quit: leaving]
philipl has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
navi has quit [Quit: WeeChat 4.1.2]
epony has quit [Remote host closed the connection]
<Marth64>
hello good evening
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
jamrial has quit []
Kei_N has quit [Ping timeout: 255 seconds]
Kei_N has joined #ffmpeg-devel
<elenril>
>haasn | creating the hwdevice inside query_formats is established convention
<elenril>
that's a funny way to spell 'disgusting hack'
<elenril>
kierank: i didn't get any emails from paul, it's almost disappointing
<Lynne>
worse hacks exist in hwdevice land
Martchus has quit [Ping timeout: 264 seconds]
Martchus has joined #ffmpeg-devel
<elenril>
does not mean we should cement it in
AbleBacon has quit [Read error: Connection reset by peer]
zsoltiv_ has quit [Ping timeout: 268 seconds]
AntimaD has joined #ffmpeg-devel
qeed has joined #ffmpeg-devel
rvalue has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 272 seconds]
rvalue- is now known as rvalue
<Lynne>
jkqxz: ping on the vulkan av1 patchset
Martchus_ has joined #ffmpeg-devel
Martchus has quit [Ping timeout: 272 seconds]
AntimaD has quit [Ping timeout: 256 seconds]
<Marth64>
anyone around for a whitespace question? (really just need a quick peek what whitespace you all prefer)
<Marth64>
context: addressing feedback from reviewers, at the end now so doing a whhitespace formatting sweep
<Marth64>
i like option 1
<elenril>
Marth64: anything except 2 is disgusting
<elenril>
also consider aligning trailing ||s
<Marth64>
ok cool
<Marth64>
will take care of it - thx
<Marth64>
✔
<j-b>
good morning
<Marth64>
hello
stevenliu has quit [Remote host closed the connection]
stevenliu has joined #ffmpeg-devel
AntimaD has joined #ffmpeg-devel
<Traneptora>
Marth64: iirc option 2 is standard
<Traneptora>
tho I'd probably put the newline before the av_log instead of after it
<Traneptora>
separates it from the big if block more cleanly
<Marth64>
Traneptora: thank you... it ended up looking ok since i aligned the trailing || s (although I admit I just finished getting the patchset ready). happy to fix it if you think end result looks fugly
<Traneptora>
I prefer the newline before av_log if you're going to have one
<Traneptora>
if you have no blank lines that's fine too, but I wouldn't put one after the av_log
<Marth64>
np
<Marth64>
i will redo it
<Marth64>
last q
<Marth64>
100 char lines for email ok? (responding to feedback, etc.)
<Marth64>
or does it need to be 80
<Marth64>
nvm
<Marth64>
all fixed, gonna validate with some cartoons and send it off
AntimaD has quit [Ping timeout: 256 seconds]
<Traneptora>
for emails that aren't git-send-email I just don't limit paragraph line length, assuming the mail client will wrap long lines
<Traneptora>
but I also send my emails in plain text
<Marth64>
totally screwed up the subject line of my v9 patch, really sorry
<Marth64>
will resend
<Marth64>
one day i will get better at this
<cworley>
wbs: taking a look
epony has joined #ffmpeg-devel
Marth64[m] has joined #ffmpeg-devel
Marth64 has quit [Killed (NickServ (GHOST command used by Marth64[m]))]
Marth64[m] is now known as Marth64
<Marth64>
v10 is good to go
<Marth64>
enjoy
<Marth64>
and good night
<cworley>
i guess testsrc2 produces nondeterministic output?
<wbs>
no idea; I seem to be getting the same hash from most of my instances though. is there some filter involved that would need a bitexact flag somewhere?
dellas has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
Marth64 is now known as Marth64[zzz]
HarshK23 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<cworley>
i don't see anything obvious, and i can't repro on my mac/windows/linux machines
<wbs>
that's weird. on fate, I don't see a single instance, in the lsat 10 hours, where this test would be passing
<wbs>
so there's some input data which is otherwise uninitialized, but ends up mixed into the output? that sounds kinda suspicious to me, unless it's known and intentional
epony has quit [Remote host closed the connection]
<elenril>
cworley: "fix bug" is not a good commit message
<elenril>
you want something like "avoid reading uninitialized data" instead
<cworley>
ugh, i edited it but then git send-email failed, and i forgot to re-edit it
<cworley>
one moment
epony has joined #ffmpeg-devel
<elenril>
>Leading and trailing whitespaces are removed
<wbs>
I think the most relevant question is, from the implementaton/design of this encoder, are these uses of uninitialized areas of tex_data intentional and known, or are they an accident and surprise?
<cone-581>
ffmpeg Andreas Rheinhardt master:687a287e140e: avcodec/mmaldec: Avoid using AVCodec.pix_fmts
<cone-581>
ffmpeg Andreas Rheinhardt master:38f234c06ee0: avcodec/vc1dec: Set pointers for hwaccel even without hwaccel
<cone-581>
ffmpeg Andreas Rheinhardt master:89995cfda12e: avcodec: Remove redundant pix_fmts from decoders
<cone-581>
ffmpeg Andreas Rheinhardt master:39cfd30bf111: avcodec/vc1dec: Remove AVCodec.pix_fmts arrays
<cone-581>
ffmpeg Andreas Rheinhardt master:d30fe36b8898: avformat/rcwtenc: Fix potential out-of-bounds write
<cone-581>
ffmpeg Andreas Rheinhardt master:2b0e9e278a41: avcodec/h263dec: Remove AVCodec.pix_fmts arrays
<cone-581>
ffmpeg Andreas Rheinhardt master:ca9586375828: avcodec/vc1dec: Don't call ff_get_format() twice
<cone-581>
ffmpeg Andreas Rheinhardt master:a8e55cf11846: avformat/rcwtenc: Remove redundant zeroing of buffer
<cone-581>
ffmpeg Andreas Rheinhardt master:3371250c3288: avformat/rcwtenc: Pass RCWTContext directly in rcwt_init_cluster()
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 256 seconds]
<cworley>
hm, a better fix would be to not align the image dimensions to 16, which is for compatibility with the existing decoder that doesn't need to be aligning to 16 either
<wbs>
if either of these affects the output, it sounds like something really is broken in the encoder
<cworley>
i'll whip another patch for comparison
<cworley>
i think the encoder is a bit broken, to work around a bug in the old decoder that i didn't realize was a bug
<wbs>
ok, so did the previous align-up-to-16 mean that if the input was smaller than a multiple of 16, it was padded to 16 and the padding was encoded as part of the output?
<cworley>
exactly
<wbs>
ok, this is an explanation that makes sense
<cworley>
and if that align-up-to-16 wasn't there in the output, the decoder would hang trying to read it
ccawley2011 has joined #ffmpeg-devel
<cworley>
i'd prefer this one be merged since it comes with the benefit of smaller outputs as well
<cone-581>
ffmpeg Andreas Rheinhardt master:8c2e86ca2856: fftools/cmdutils: Don't cast const away
Daemon404 has joined #ffmpeg-devel
<haasn>
elenril: maybe you know, why does ffmpeg_filter.c need to check both ost->enc_ctx->strict_std_compliance *and* ost->encoder_opts? At what point does encoder_opts propagate to the enc_ctx and why does it happen sometimes but not always?
<haasn>
I see that it's used in avcodec_open2, so why do we look at enc_ctx->strict_std_compliance at all?
<elenril>
at that point, the enc_ctx value is the avcodec default
<elenril>
the user-specified value, if present, is always in encoder_opts
<elenril>
the logic in that code is that it takes the latter if present, the former otherwise
<haasn>
ah, I see
<haasn>
that's slightly awkward for any potential API to replace the mjpeg hack
<haasn>
because we can't use AVCodecContext values
<haasn>
unless we change the way this parsing happens to early-init the enc_ctx *options* before the actual avcodec_open2 call?
jamrial has joined #ffmpeg-devel
<elenril>
iirc last time this was discussed, people propose dropping the hack
<elenril>
or creating a separate AVCodec for it
llyyr has quit [Remote host closed the connection]
psilokos has quit [Remote host closed the connection]
llyyr has joined #ffmpeg-devel
psilokos has joined #ffmpeg-devel
<haasn>
in either case we should not design the AVCodec API with the needs of ffmpeg_filter.c in mind
<haasn>
we should design the API that is correct in principle and then refactor ffmpeg_filter to be able to use it
<haasn>
even if it means e.g. setting enc_ctx->strict_std_compliance earlier than avcodec_open2
Guest4622 has quit [Ping timeout: 276 seconds]
Arsen has quit [Ping timeout: 264 seconds]
root has joined #ffmpeg-devel
Arsen has joined #ffmpeg-devel
root is now known as Guest4514
<elenril>
yes, I agree
<elenril>
I wanted to switch to applying options manually (i.e. with av_opt_set_dict()) anyway
navi has joined #ffmpeg-devel
<haasn>
question
<haasn>
AVFilterContext.hw_device_ctx literally documents that it must be set before init()s
<haasn>
so why don't we init the hwdevice at init() time, again?
<haasn>
right, because it's not *actually* set at init() time
<haasn>
so that's a bug in libavfilter, which violates its own documentation
novaphoenix has quit [Quit: i quit]
novaphoenix has joined #ffmpeg-devel
<haasn>
elenril: so the problem is that ffmpeg_filter initializes the filter graph twice
<haasn>
once via init_simple_filtergraph() and once via configure_filtergraph()
<haasn>
the hwctx is not available in the former instance
<kierank>
how come you left mmsize == 8 code in there
MikhailAMD has joined #ffmpeg-devel
<ubitux>
Lynne: the legacy av rdft api seems to do an off by one now that it's relying on av tx
<ubitux>
previously the N/2+1 complex output was working inplace in a buffer of N samples bc the first and last complex were real (im=0 so they were in the first 2 floats)
<ubitux>
it seems we're getting invalid memory access bc of that now
<Lynne>
where?
<ubitux>
as a third party user of the api
<ubitux>
the rdft calc call causes the off by one with a N sized input buffer
<Lynne>
forward or inverse?
<ubitux>
DFT_R2C
<ubitux>
/* i=0 is a special case because of packing, the DC term is real, so we
<ubitux>
are going to throw the N/2 term (also real) in with it. */
<ubitux>
refering to that (rdft.c before removal)
<wbs>
mkver: I'm not planning on ripping out all MMX, just the inline bits for COPY64/ZERO64/SWAP64 for now
<wbs>
(I'm leaving some fun for others too) ;-)
<Lynne>
ubitux: that's not an off by one, by design, lavu/tx uses the standard convention of leaving the second DC value at the end of the array (N/2+1).re
<Lynne>
the compat layer simply moves it back, so it uses an extra element compared to before
<Lynne>
so I guess that's taking API users by surprise
<Lynne>
I can add a copy procedure to the compat layer
<Lynne>
(but you should use the new API)
<ubitux>
yeah it's ported to the new one but the legacy path got us spurious crashes
epony has joined #ffmpeg-devel
<elenril>
haasn: grmbl, looking at the ffmpeg CLI code it seems possible for different devices to be used
<elenril>
because new global devices may become available when decoders are initialized
<cone-580>
ffmpeg Lynne master:9af87828bd78: x86/tx_init: propely indicate the extended available transform sizes
<BtbN>
hm, I think I have to change the ddagrab logic
<BtbN>
if it gets a frame in the wrong format, it should not just give up permanently
<BtbN>
apparently the dda API just sometimes gives you random other formats
MikhailAMD has quit [Quit: Leaving]
AntimaD has joined #ffmpeg-devel
Marth64 has joined #ffmpeg-devel
Marth64[zzz] has quit [Ping timeout: 256 seconds]
<Lynne>
ubitux: patch to fix the overread is on the ML, can you test it?
<ubitux>
av_free(&w->tmp); ← av_freep? or no &?
<haasn>
elenril: then how about my other proposal to allow init without device iff you don’t call query formats
<Lynne>
ah, right
<Lynne>
ditching the explicit in-place flag does give a good 15% gain, so should've been done while writing the wrapper
<haasn>
That way we can have device init in init(), if that’s the only goal here
<haasn>
Or we could add a new device init callback but what’s the point
<elenril>
see my proposal on ml
<elenril>
>iff you don’t call query formats
<haasn>
But that still has the device mismatch issue no?
<elenril>
the filtergraph user has no control over this
<elenril>
why would there be any mismatch?
<courmisch>
av_freep() needs to die
<elenril>
av_freep() is love
<elenril>
av_freep() is life
<courmisch>
av_freep() is a repeat violator of aliases
<Lynne>
replaced it with av_free() because the context gets freed in the next line
ngaullie has quit [Ping timeout: 246 seconds]
<elenril>
so-called "aliasing" is a myth
<elenril>
no rigorous peer-reviewed studies have established its existence
<courmisch>
av_freep() needs to be added to the alias violation offender and banned from appearing within 300m of growing code bases
<courmisch>
atlernatively av_freep() needs to reincarnate as a C23 macro
<courmisch>
with typeof, it can be done safely
<elenril>
what is unsafe about the current version?
<courmisch>
in the first place, because it takes a void * instead of a void ** it breaks basic pointer compatibility diagnostics
<Lynne>
it would be kinda neat to use generics to detect double pointers and set the output to null
<elenril>
whataboutism
<courmisch>
and then it assumes that all pointer types have the same representation; this breaks some funky system with data flow integrity
<elenril>
generics are always more trouble then they are worth
<elenril>
ALWAYS
<courmisch>
LIES
<mkver>
elenril: The C standard does not require all pointers to use the same memory layout; conversions between pointers need not be no-ops.
<Lynne>
(c11's generics are really not generics at all by any standards of generics)
<courmisch>
Lynne: that's why I wrote C23 typeof, though it's obviously available on C11 LLVM and GCC too
<Lynne>
I don't really get the point of typeof, how would it be used in this case?
<mkver>
Think about the case in which a void*->int* conversion consists of shifting the address two bits to the right (for sizeof(int) == 4). Then reading the int** as if it was a void** will just blow up.
<mkver>
Actually, do we even need typeof? Wouldn't #define AV_FREE(ptr) {av_free(ptr); ptr = NULL;} do the job?
<kierank>
mkver: can I remove that mmsize == 8 code in vp6dsp or is there something I missed?
<ubitux>
Lynne: shouldn't you av_mallocz so that src[len+1] is 0 in the inverse case?
<haasn>
18:04 <@elenril> haasn: grmbl, looking at the ffmpeg CLI code it seems possible for different devices to be used <- this device mismatch issue, or are you just saying it's unsatisfying without claiming it's an issue?
<haasn>
(I mean I guess it means we will have a different device when probing the graph vs when actually using the graph to filter)
AntimaD has joined #ffmpeg-devel
<Lynne>
ubitux: I set src[1] = 0.0f; in the inverse case
<ubitux>
but what about src[len+1]?
<elenril>
haasn: I suggested on ML to cache the first device you see, and then always using it
<courmisch>
mkver: it works but it's not expansion-safe if `ptr` has side effects
<Lynne>
src[w->len+1] isn't used
<ubitux>
since it's always assumed to be 0 it's not even read?
<Lynne>
no, it's simply unused in the algorithm
<courmisch>
granted, av_freep() don't typically have an expression with side effects but...
<Lynne>
the new API specifies that the size required is N/2+1 complex values, but we just set the very last imaginary to 0 on output, and don't read it on the input
<elenril>
haasn: and yes, I can't think of anything that would actually break from using different devices, it just feels dirty and wrong
<elenril>
and of course there's the question of which one does the user actually want
<ubitux>
Lynne: even in some optimized overread of some sort? :3
<ubitux>
(even if unused)
<haasn>
elenril: hence my proposal to allow us to continue using no device in the probe case
<Lynne>
.im is not touched, and the loop beneath doesn't reach into that value
<ubitux>
ok :)
philipl has quit [Ping timeout: 276 seconds]
philipl has joined #ffmpeg-devel
<Lynne>
the asm code doesn't use it either, but it's there just in case
<BtbN>
ok, I finally understood the bug that's going on with ddagrab. I do believe it's a bug on Microsofts side, but it can be worked around by means of an entire extra copy
philipl has quit [Ping timeout: 246 seconds]
philipl has joined #ffmpeg-devel
AntimaD has quit [Ping timeout: 256 seconds]
Krowl has quit [Read error: Connection reset by peer]
AbleBacon has joined #ffmpeg-devel
<Lynne>
speaking of grabs, has anyone seen the pipewire grab submitted a month ago?
<Lynne>
800 lines of the ~1200 lines were just libdbus nonsense to start the capture
<Traneptora>
that's wayland tbh
<Lynne>
no, wayland is 400 lines tops
<Lynne>
that's gnome nonsense
<philipl>
But isn't the dbus crap standardised and how you need to beg the DE to let you record?
<Lynne>
correct, but the difficult part is launching the dbus request, for which you need a dbus library
<Lynne>
and you have to program it all by yourself, there isn't a simple give_me_a_pipewire_capture shortcut
<Lynne>
plus, some properties such as whether cursor capturing is supported are exported through dbus too, not pipewire
<Lynne>
and that wastes 400 lines of boilerplate since it's all done through callbacks and has multiple levels of organization that you have to go down through
<Lynne>
granted, systemd's dbus library probably cuts that all down to half or more, but there seem to be as many people who know how to use that library as there are systemd holdlouts :)
<psykose>
sd-bus is also a separate extracted impl as basu so you can totally use it if you want, it works outside systemd systems
<Lynne>
(just don't say anything about how HDR support is missing, that will add another 10 to 20 years)
<Traneptora>
ooo, 16 years later they add basic functionality to their nextgen protocols
<Traneptora>
impressively fast
<Lynne>
I know, right?
lexano has quit [Ping timeout: 276 seconds]
<cone-580>
ffmpeg Timo Rothenpieler master:6154137b1867: avutil/mem: limit alignment to maximum simd align
<cone-580>
ffmpeg Timo Rothenpieler master:21c6d12449a2: avfilter/ddagrab: only use acquired texture on valid updates
<BtbN>
a shit
<BtbN>
I did not intend to push that mem patch, I forgot I had been dragging that along since two months
<BtbN>
In any case, ddagrab with non-8bit stuff is FINALLY actually working now.
<Traneptora>
tbf we can always revert it if there ends up being a problem
<BtbN>
yes, it never caused me issues, and it _does_ fix a whole lot of UB
<BtbN>
The main issue with it is that I never had a chance to test it on ICC and those weird sunc things
<BtbN>
so they might have to be changed to work like MSVC if they turn out broken
lexano has joined #ffmpeg-devel
<jamrial>
elenril: so i found a heif sample with explicit offsets for all the items within the final canvas, and the images can overlap
<jamrial>
so i guess we can't really call this a grid anymore, or even the images tiles, if there are cases where that wont be the case
<jamrial>
so suggestions welcome
<jkqxz>
BtbN: I'm sorry, but the inappropriate incentives associated with "I accidentally pushed a patch; I think it's good so whatever" means that we should never accept that. Please revert it.
<BtbN>
I'm fine with reverting it, if that's preferred.
<BtbN>
But we really should do something about that UB before 7.0
<BtbN>
I just didn't have time to tend to the thread about it in the last couple months
<jkqxz>
That may be true, but it still must be reverted and discussed if so.
<BtbN>
I think the most simple approach until a proper solution is found would be the initial patch, of just setting the minimum align to 32?
<jkqxz>
Sure. Then revert the incorrectly pushed patch and resume the discussion on the ML.
<BtbN>
What baffled me about that discussion is, that a bunch of people seem to prefer leaving a lot of UB in the entire codebase, rather than avoiding it with a minimal tradeoff.
<cone-580>
ffmpeg Timo Rothenpieler master:4618b5ebb95d: Revert "avutil/mem: limit alignment to maximum simd align"
<jkqxz>
Thank you.
<BtbN>
Who even uses sunc and the like?
<jkqxz>
I weakly agree that the patch works as a hack to avoid UB for now, but the incorrect code causing it really should be fixed.
<BtbN>
I looked into fixing the code, but it's EXTREMELY impractical
<BtbN>
there is several hundred instances, and a lot of them stretch over dozens of files and assembly
<BtbN>
Fixing that is likely multiple weeks of fulltime work
<BtbN>
And potentially also comes with API breaks
<jkqxz>
Maybe we should ask STF for money to fund it, then!
<BtbN>
If someone wants to do that, be my guest. I simply don't have the time for it.
<jkqxz>
It isn't in any public headers, surely? If so that is very broken.
<BtbN>
I'm not 100% sure
<BtbN>
I think not, but I can't rule it out
<BtbN>
it's in basically ALL the lower level codec structs used by the various native decoders
<jkqxz>
And the solution for all of them is "align this structure to max of alignments inside it when you allocate", right?
<BtbN>
yeah
<jkqxz>
Is there a way to make ubsan or valgrind spot all of them?
<jkqxz>
(Like tell it that all allocations should have the minimal alignment that they are allowed to somehow.)
<BtbN>
If you make a build with the odd configuration that triggers the issue, I'd expect some of them to spot the issue
<BtbN>
i.e. hack the alignment of av_malloc and friends to only by 16 or even 8 bytes, and then run it through a sanitizer
<BtbN>
Problem is, that'll also produce a heck of a lot of false positives
<BtbN>
But given that such a broken configuration is basically ALWAYS the case on arm64 and the like, and nobody ever spotted it... I'm not so sure
<BtbN>
surely someone has run ffmpeg through all the sanitizers on arm?
<Lynne>
jkqxz: ping on vulkan_av1
<jkqxz>
Lynne: Still appears to have an off-by-one?
<jkqxz>
And doesn't look like the code in the specification.
<Lynne>
it doesn't have an off by one?
<Lynne>
per-spec it's a for loop with 7 iterations
<Lynne>
and the variables are all named and appear in the order in the spec
<jkqxz>
The loop writes entry LAST_FRAME + i on the ith iteration. LAST_FRAME == 1. Your code writes entry i in the ith iteration.
<jkqxz>
So you've made an array which is ref_frame_sign_bias_except_offset_by_one.
<BtbN>
hm, technically I _could_ have pushed this patch, since it's been on the ML for three weeks with no comments. But that's rather ugly given the former discussion it had.
<Traneptora>
If matrix_coefficients is equal to MC_IDENTITY, it is a requirement of bitstream conformance that subsampling_x is equal to 0 and subsampling_y is equal to 0.
<Traneptora>
looks like the way av1 signals rgb is by setting matrix_coefficients is via MC_IDENTITY
<jkqxz>
AV1ReferenceFrameState is in CodedBitstreamAV1Context - that's all the stuff set in 7.20 in the spec.
<Lynne>
so you want me to move both orderhints[] and the refframesignbias[] into AV1ReferenceFrameState?
<jkqxz>
No, because neither of those are per-reference-slot things.
<jkqxz>
SavedOrderHints would be in that, OrderHints is a current-context thing so yes to CodedBitstreamAV1Context.
<cone-580>
ffmpeg Andreas Rheinhardt master:ce7c90ff82af: avcodec/dca_core: Remove unneeded emms.h inclusion
<jkqxz>
Lynne: Yes. I'll look at the vulkan part tomorrow.
<ubitux>
Lynne: thanks for the quick fix btw
<cone-580>
ffmpeg Lynne master:90adef99cab4: avfft: avoid overreads with RDFT API users
<cone-580>
ffmpeg Lynne release/6.1:8815d7753225: avfft: avoid overreads with RDFT API users
dellas has quit [Remote host closed the connection]
<mkver>
Lynne: Did you actually intent to deprecate avdct?
<cone-580>
ffmpeg Marton Balint master:3d3cad748378: avformat/mov_chan: do not assume channels are in native order
<cone-580>
ffmpeg Marton Balint master:dc9d64f7941f: avformat/mov_chan: never override number of channels based on chan atom
<Lynne>
mkver: at least the DCT part of it, it calls the lavc mpeg-2 DCT currently, and I plan to implement 2D transforms in lavu/tx
<Lynne>
I did port our only user of the get_pixels API by copypasting lavc's immplementation without assembly into it
<Lynne>
but I never posted it on the ML, it wasn't complete without the DCT being replaced
<Lynne>
that whole header is peak 'I need this, I'm just going to expose it as a public API, and I need this too, I'll just put it in there, kthnxbye'-school of API design
ccawley2011 has quit [Read error: Connection reset by peer]
qeed has joined #ffmpeg-devel
qeed has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
deus0ww has quit [Ping timeout: 255 seconds]
jarthur has quit [Quit: jarthur]
deus0ww has joined #ffmpeg-devel
staceee has quit [Ping timeout: 256 seconds]
MisterMinister has quit [Ping timeout: 272 seconds]
staceee has joined #ffmpeg-devel
MisterMinister has joined #ffmpeg-devel
sdc has joined #ffmpeg-devel
jarthur has joined #ffmpeg-devel
sdc has quit [Quit: Client closed]
qeed has quit [Remote host closed the connection]
qeed has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]