<cone-241>
ffmpeg Michael Niedermayer release/5.1:8abcd8b124bc: libavcodec/lcldec: width and height should not be unsigned
<cone-241>
ffmpeg Michael Niedermayer release/5.1:002471255d33: avcodec/lcldec: Support 4:1:1 and 4:2:2 with odd width
<cone-241>
ffmpeg Michael Niedermayer release/5.1:1480cc1d9c8c: avcodec/lcldec: More space for rgb24
<cone-241>
ffmpeg Michael Niedermayer release/5.1:66192786e7ab: avutil/tx_priv: Use unsigned in BF() to avoid signed overflows
<cone-241>
ffmpeg Michael Niedermayer release/5.1:c2b46db3f439: avcodec/g2meet: Replace fake allocation avoidance for framebuf
<cone-241>
ffmpeg Michael Niedermayer release/5.1:efcb8211577b: avcodec/vorbisdec: Check codebook float values to be finite
<cone-241>
ffmpeg Michael Niedermayer release/5.1:ac015347a803: avcodec/pngdec: remove AVFrame argument from decode_iccp_chunk()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:13644a75d831: avcodec/pngdec: Do not pass AVFrame into global header decode
<cone-241>
ffmpeg Michael Niedermayer release/5.1:b9c79be72639: avcodec/exr: Cleanup befor return
<cone-241>
ffmpeg Michael Niedermayer release/5.1:0c2b08227ef5: avcodec/utils: the IFF_ILBM implementation assumes that there are a multiple of 16 allocated
<cone-241>
ffmpeg Michael Niedermayer release/5.1:2878299b730e: avcodec/sonic: Fix two undefined integer overflows
<cone-241>
ffmpeg Michael Niedermayer release/5.1:f174aa713455: avcodec/tak: Check remaining bits in ff_tak_decode_frame_header()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:7337f2e8e36b: avcodec/tiff: add a zero DNG_LINEARIZATION_TABLE check
<cone-241>
ffmpeg Michael Niedermayer release/5.1:50e2f8ef3385: avformat/wavdec: Check that smv block fits in available space
<cone-241>
ffmpeg Michael Niedermayer release/5.1:1892181787dd: avformat/oggparsetheora: clip duration within 64bit
<cone-241>
ffmpeg Michael Niedermayer release/5.1:2cb93e863fac: avcodec/noise_bsf: Check for wrapped frames
<cone-241>
ffmpeg Michael Niedermayer release/5.1:4e68048151a4: avformat/jpegxl_probe: Remove intermediate macro obfuscation around get_bits*()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:55de397fe048: avformat/jpegxl_probe: check length instead of blindly reading
<cone-241>
ffmpeg Michael Niedermayer release/5.1:537600e78506: avformat/jpegxl_probe: Forward error codes
<cone-241>
ffmpeg Michael Niedermayer release/5.1:74d3c9261a66: avcodec: Ignoring errors is only possible before the input end
<cone-241>
ffmpeg Michael Niedermayer release/5.1:df4170b2bcad: avcodec/takdsp: Fix integer overflows
<cone-241>
ffmpeg Michael Niedermayer release/5.1:9b10b9b8cb49: avcodec/hevcdec: Avoid null pointer dereferences in MC
<cone-241>
ffmpeg Michael Niedermayer release/5.1:515c7b21f47d: avcodec/utils: fix 2 integer overflows in get_audio_frame_duration()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:cde6758306e4: tools/target_dec_fuzzer: Adjust threshold for speex
<cone-241>
ffmpeg Michael Niedermayer release/5.1:706c44541ed6: avutil/softfloat: fix av_sincos_sf()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:18bf4e4ff788: avutil/softfloat: Basic documentation for av_sincos_sf()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:fc94130cd6f3: avcodec/jpeg2000dec: Check for reduction factor and image offset
<cone-241>
ffmpeg Michael Niedermayer release/5.1:1759fd0d82c4: avcodec/pcm: allow Changing parameters
<cone-241>
ffmpeg Michael Niedermayer release/5.1:c09250be43d8: avformat/imf_cpl: xmlNodeListGetString() can return NULL
<cone-241>
ffmpeg Michael Niedermayer release/5.1:9b5a8aa16d99: avformat/imf_cpl: Replace NULL content_title_utf8 by ""
<cone-241>
ffmpeg Michael Niedermayer release/5.1:cfa3ae418156: avformat/avr: Check sample rate
<cone-241>
ffmpeg Michael Niedermayer release/5.1:7c646d22cf26: avcodec/xvididct: Fix integer overflow in idct_row()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:d548c94bfaf9: avcodec/apedec: Fix CRC for 24bps and bigendian
<cone-241>
ffmpeg Michael Niedermayer release/5.1:b91b26813c62: avcodec/tta: fix signed overflow in decorrelate
<cone-241>
ffmpeg Michael Niedermayer release/5.1:06ff2bfe0f29: avcodec/mpeg4videodec: more unsigned in amv computation
<cone-241>
ffmpeg Michael Niedermayer release/5.1:54d87e4b2837: avcodec/hevcdec: Fix undefined memcpy()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:10dfb498ea42: avcodec/mpeg4videodec: consider lowres in dest_pcm[]
<cone-241>
ffmpeg Michael Niedermayer release/5.1:fccc3130c74e: avcodec/cscd: Check for CamStudio Lossless Codec 1.0 behavior in end check of LZO files
<cone-241>
ffmpeg Michael Niedermayer release/5.1:55a00e464c4c: avcodec/huffyuvdec: avoid undefined behavior with get_vlc2() failure
<cone-241>
ffmpeg Michael Niedermayer release/5.1:3c56b5c3df4d: avcodec/jpeg2000dec: jpeg2000 has its own lowres option
<cone-241>
ffmpeg Michael Niedermayer release/5.1:ee90868c6778: avformat/format: Stop reading data at EOF during probing
<cone-241>
ffmpeg Michael Niedermayer release/5.1:6c176df7e969: avformat/hls: reduce default max reload to 3
<cone-241>
ffmpeg Michael Niedermayer release/5.1:7be649290e9c: tools/target_dec_fuzzer: Adjust threshold for rtv1
<cone-241>
ffmpeg Michael Niedermayer release/5.1:0224effb524c: avcodec/celp_math: avoid overflow in shift
<cone-241>
ffmpeg Michael Niedermayer release/5.1:d5f1ecbe247d: avcodec/xvididct: Fix integer overflow in idct_row()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:b358b080a146: avformat/mxfdec: Remove this_partition
<cone-241>
ffmpeg Michael Niedermayer release/5.1:d49105333481: avformat/concatdec: Check in/outpoint for overflow
<cone-241>
ffmpeg Michael Niedermayer release/5.1:f43562c38a78: avformat/sbgdec: Check for period overflow
<cone-241>
ffmpeg Michael Niedermayer release/5.1:87f556a10c1c: avformat/westwood_vqa: Check chunk size
<cone-241>
ffmpeg Michael Niedermayer release/5.1:6e4690ede0fa: avcodec/lcldec: Make PNG filter addressing match the code afterwards
<cone-241>
ffmpeg Michael Niedermayer release/5.1:3817209b6d37: avformat/avs: Check if return code is representable
<cone-241>
ffmpeg Michael Niedermayer release/5.1:43c6fabb63e6: tools/target_dec_fuzzer: Adjust wmapro threshold
<cone-241>
ffmpeg Michael Niedermayer release/5.1:95b2569427d8: avcodec/apedec: Fix an integer overflow in predictor_update_filter()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:44978c5b8333: avcodec/escape124: Do not return random numbers
<cone-241>
ffmpeg Michael Niedermayer release/5.1:30b3f2712d58: avformat/sbgdec: Check for negative duration or un-representable end pts
<cone-241>
ffmpeg Michael Niedermayer release/5.1:d35579c12b60: avformat/jacosubdec: Factorize code in get_shift() a bit
<cone-241>
ffmpeg Michael Niedermayer release/5.1:441d5eca4b65: avformat/jacosubdec: avoid signed integer overflows in get_shift()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:283baa733661: avformat/jacosubdec: Check timeres
<cone-241>
ffmpeg Michael Niedermayer release/5.1:1e239a8b88ed: avformat/mov: compute absolute dts difference without overflow in mov_find_next_sample()
<cone-241>
ffmpeg Michael Niedermayer release/5.1:0c1babaa6194: avformat/rpl: Check for number_of_chunks overflow
<cone-241>
ffmpeg Michael Niedermayer release/5.1:c01d304a6bf1: avformat/tta: Better totalframes check
<cone-241>
ffmpeg Michael Niedermayer release/5.1:1718baf61c11: avformat/wavdec: Check left avio_tell for overflow
<cone-241>
ffmpeg Michael Niedermayer release/5.1:f15a1d79280b: avformat/matroskadec: Check prebuffered_ns for overflow
<cone-241>
ffmpeg Michael Niedermayer release/5.1:29788ba10ec4: avformat/xwma: sanity check bits_per_coded_sample
<cone-241>
ffmpeg Michael Niedermayer release/5.1:a563efcfda67: avformat/asfdec_f: Saturate presentation time in marker
<cone-241>
ffmpeg Michael Niedermayer release/5.1:76ee7c771568: avcodec/h264_parser: saturate dts a bit
<cone-241>
ffmpeg Michael Niedermayer release/5.1:d7f64a78e0d4: avformat/tmv: Check video chunk size
<cone-241>
ffmpeg Michael Niedermayer release/5.1:566e0aa8e220: avcodec/xvididct: Make c* unsigned to avoid undefined overflows
<cone-241>
ffmpeg Michael Niedermayer release/5.1:181d6e17e07b: avcodec/h2645_parse: Avoid EAGAIN
<cone-241>
ffmpeg Sean McGovern release/5.1:f861a1602529: libavutil/ppc/cpu.c: check that AT_HWCAP2 is defined
<cone-241>
ffmpeg Michael Niedermayer release/5.1:905819d18a93: avformat/mxfdec: Check klv offset
<cone-241>
ffmpeg Michael Niedermayer release/5.1:4bd4b178bfa4: avcodec/jpeg2000dec: Check image offset
<cone-241>
ffmpeg Michael Niedermayer release/5.1:5e71da4ef963: avformat/rtsp: Use rtsp_st->stream_index
<cone-241>
ffmpeg Andreas Rheinhardt release/5.1:7739dabb89ee: avformat/matroskadec: Fix declaration-after-statement warnings
dellas has quit [Remote host closed the connection]
mkver has quit [Ping timeout: 255 seconds]
thilo has quit [Ping timeout: 240 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
MrZeus has quit [Ping timeout: 240 seconds]
wangbin has joined #ffmpeg-devel
wangbin29 has joined #ffmpeg-devel
wangbin has quit [Ping timeout: 248 seconds]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg-devel
jamrial has quit []
cone-241 has quit [Quit: transmission timeout]
<Lynne>
elenril: submitted a new version of the aac patchset, using a single function to skip samples
<Lynne>
will fix fate if you think it's in the right direction
MisterMinister has quit [Ping timeout: 258 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg-devel
stevenliu has joined #ffmpeg-devel
stevenliu has quit [Changing host]
stevenliu has joined #ffmpeg-devel
stevenliu has quit [Client Quit]
<j-b>
good morning
<another|>
already? damn
<another|>
guess I'm staying up then
<galad>
regarding the priming delay, why sometimes the demuxer set the codecpar initial_padding, and sometimes not? For example mov.c only set it for opus, never for aac even if the priming delay is explicitely signaled
<wbs>
Lynne: re the aac trimming; I presume the timestamps get adjusted accordingly? e.g. for streams that have this compensated by starting at pts=-<delay>, if you trim things off, you'd start at pts=0 right?
Krowl has joined #ffmpeg-devel
<j-b>
JEEB: ping
<galad>
sgpd grouping type "roll" is never read, hmmm
<JEEB>
j-b: pong
<j-b>
JEEB: do you need help for mailmap?
<JEEB>
I think elenril noted the actual issue, which is just that there is no mailmap entry for that e-mail
<JEEB>
so I'll be able to post a patch today after $dayjob most likely
mkver has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
mkver has quit [Remote host closed the connection]
mkver has joined #ffmpeg-devel
HarshK23 has quit [Quit: Connection closed for inactivity]
Ytsejammer has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<wbs>
j-b: fyi re the voting mails; I got two copies of an otherwise seemingly identical mail (same voting link), sent 30 seconds apart, with different message-id
MrZeus has joined #ffmpeg-devel
<JEEB>
same here :)
<elenril>
known issue
HarshK23 has joined #ffmpeg-devel
<JEEB>
alrighty
<JEEB>
so if I check the content it shoudl be the same?
<JEEB>
or othrewise the first one got disabled so I just utilize the second one
<j-b>
wbs: I don't control the voting stack
<j-b>
wbs: but it should only allow you to vote once.
<j-b>
So we're good, I think.
<JEEB>
( ^_^)b
<wbs>
j-b: yeah, and it was the same voting ID (the same url to the vote) in both of them so it's harmless
<j-b>
wbs: when launching the vote, I got a 500 error and I refreshed, so I expect this is the issue.
<wbs>
lovely stable SW
<JEEB>
probably synchronously starting the sending
<elenril>
everyone knows perl is the best language ever
<wbs>
it's surprisingly decent, up until it isn't
<elenril>
eh
<elenril>
my terminal emulator uses perl for extensions, which is so far my only concact with it
<elenril>
it's like bash on steroids
<elenril>
it tries so hard to be helpful you need to keep a million special cases in your head
<elenril>
i'll take python over perl any day
<wbs>
I semi-regularly touch (and write) some small scripts in it, including but not limited to gas-preprocessor
<wbs>
it's great for text processing and such
<wbs>
but yeah, for actually running it somewhere exotic, python is much nicer
<wbs>
perl on windows is a huge trash fire
<wbs>
it used to be the case that activestate's builds were the nice ones to use, free for normal use and all such. but at some point they've obfuscated their downloads so there's no single url you can download it from, so package managers like chocolatey can't ship it any longer
<wbs>
then there's strawberry perl, which is shipped with its own copy of gcc, which does get added to the path. which clearly is what you'd want to use...
<elenril>
I hear you can do apt install perl on windows these days
<elenril>
if you want to be pedantic, you should add (inclusive) at the end
<JEEB>
haasn: yea the new threadrippers were just announced and they are not AM5 so one has to wait for actual mobos
<haasn>
ah I see
<haasn>
then I'll wait
cone-959 has joined #ffmpeg-devel
<cone-959>
ffmpeg James Almer master:4cba3e0f0710: avutil/video_enc_params: fix doxy for av_video_enc_params_block()
<haasn>
it's really surprising that intel doesn't seem to target HEDT market at all, unless I'm missing something
<haasn>
you either get the ridiculously overspecced/overpriced xeon server/workstation CPUs or the ridiculously underspecced desktop CPUs
Krowl has joined #ffmpeg-devel
<JEEB>
well intel doesn't even unofficially give ECC in desktop systems so what'd you expect
<haasn>
ah I guess the xeon w5 series is this
<haasn>
e.g. Intel Xeon w7-2475X seems like a direct competitor
Ytsejammer has quit [Ping timeout: 258 seconds]
<haasn>
yikes, cheapest W790 mainboard is 870 EUR
<haasn>
things really have gotten more expensive since the last time I purchased hw
<JEEB>
yea
<JEEB>
even more in the less-utilized segments
<haasn>
I bought my system for.. let's see, 339 EUR mainboard, 819 EUR cpu, 315 EUR RAM
<haasn>
total price less than cost of just CPU now?
<JEEB>
yea AMD completely killed off the hobbyist threadripper side
<JEEB>
in late 2020 I bought my AMD setup that finally arrived in like April (?) of 2021
<haasn>
oof
<JEEB>
I think like 200€ for mobo, whatever the price was for 5900X and then 230€ for RAM
<durandal_1707>
you sallary is bigger than that
<elenril>
500€ for an AM5 mobo
<elenril>
500€ for an AM5 CPU
<haasn>
"€1,473 in 2018 is equivalent in purchasing power to about €1,869.58 today"
<haasn>
so it's not just inflation
<haasn>
elenril: maybe I should just stop caring about nvidia again
<haasn>
if the cost of plugging in a second gpu into my workstation is a kidney and a half
<JEEB>
ah, here we go: 589€ for 5900X, 294.90€ for AM4, 141.80+216€ for RAM (yes, it went up that much between my original order and the second time I went for the same)
<elenril>
haasn: do you need it to be the same machine?
<haasn>
not really, I just run my test suite locally before committing anything
<haasn>
but I could easily find some way to do that via SSH instead or w/e
<haasn>
so the bare minimum requirement for my system would be one x16 GPU and two M.2 NVMe SSDs, however many PCIe lanes that requires
<haasn>
plus chipset
<elenril>
an AM4 system should be quite cheap these days
Ytsejammer has joined #ffmpeg-devel
<haasn>
yeah, even 7950X is super affordable
<JEEB>
that's AM5, but even that shouldn't be too bad
<JEEB>
also I would probably next test one of those X3D systems
<haasn>
they seem to have more cache but locked multiplier
<JEEB>
or well, technically I think they're by default configured to utilize lower clocks
<JEEB>
since the 3-D thing is not as nicely handling higher voltages/heat
<JEEB>
it seems like the way to do higher clocks or use less electricity is to just undervolt, although I haven't tested it yet
<JEEB>
with AMD, that is
<haasn>
Meanwhile the Intel Core i9-13900K seems like a joke
<JEEB>
since undervolting apparently gives headroom to the scaling logic
<JEEB>
the 14900K is even more so I think?
<haasn>
20 PCIe lanes is :sadface:
<haasn>
7950X has at least 28
<nevcairiel>
note that the 28 is a lie
<nevcairiel>
because it steals some from you for the chipset
<haasn>
right, so it's actually 24+4
<haasn>
meaning you get 16 for GPU, and two M.2 slots wired directly to the CPU
<haasn>
(4 lanes per)
<haasn>
that's.. enough for my use case
<cone-959>
ffmpeg Paul B Mahol master:2f268505b9df: doc/filters: add one more example for feedback filter
<haasn>
seems like what the intel mainboards do is share the remaining lanes between the M.2 SSDs
<haasn>
I mean realistically 2 lanes of PCIe 5.0 are enough for any consumer M.2 SSD
<nevcairiel>
most boards connect the other m.2 slots through the chipset
<jamrial>
my alder lake board has one m.2 using cpu lanes and three using chipset
<nevcairiel>
intel has 8 lanes to the chipset these days, its plenty to not worry about m2 drives connected through there
<jamrial>
haasn: at least on alder lake, the cpu has 16 pcie 5 lanes and 4 pcie 4 lanes
<jamrial>
so limited to one m.2 no matter what
MrZeus has joined #ffmpeg-devel
<haasn>
having an i9 would let me test on intel iGPUs as well
<haasn>
that is a definite plus
MrZeus__ has quit [Ping timeout: 240 seconds]
<haasn>
performance difference seems to be 5%-10% slower on chipset vs direct to cpu
<haasn>
(on X570)
user23 has joined #ffmpeg-devel
qeed_ has quit [Quit: qeed_]
<cone-959>
ffmpeg Paul B Mahol master:6323ca590283: avfilter/vf_feedback: add timeline support
Krowl has quit [Read error: Connection reset by peer]
<Daemon404>
wbs, [FFmpeg-devel] [PATCH 1/3] lavc/jpeg2000dsp: make coefficients extern <-- did this have issues in msvc
<Daemon404>
or was it only cross-library externs
<wbs>
only cross-library externs
<Daemon404>
cool
paulk has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
AbleBacon has joined #ffmpeg-devel
derpydoo has quit [Read error: No route to host]
derpydoo has joined #ffmpeg-devel
dellas has quit [Remote host closed the connection]
HarshK23 has quit [Quit: Connection closed for inactivity]
Krowl has quit [Read error: Connection reset by peer]
<courmisch>
Lynne: Kendryte K230 has reached the customs
kurosu has joined #ffmpeg-devel
<Daemon404>
Lynne, am i understanding your set - it will use side data if present, but otherwise base (1024/960 for aac)?
<Daemon404>
that is 1024/960 only get used if side data is missing
<galad>
where does the codedpar initial_padding stand in all this priming delay thing? sometimes it's set, sometimes it's not
<Daemon404>
that will break the case where we have files which do not have any priming
<Daemon404>
which is not uncommon.
<Lynne>
Daemon404: correct
<Daemon404>
NAK then
<Daemon404>
unacceptabl breakage
<Lynne>
why?
<Daemon404>
tons of correct MP4s like his xst
<Lynne>
xst?
<Daemon404>
youre incorrectl handlng them
<Daemon404>
exist
<Daemon404>
10+ years at dayjob for one.
<Lynne>
well how am I supposed to know?
<Daemon404>
it is more correct to NOT hardcode some ass-pull value
<Lynne>
oi, watch your language
<Daemon404>
because plenty of correct files exist with no priming samples present
<Lynne>
1024 is the *correct* delay
<Daemon404>
wit is NT
<Daemon404>
NOT*
<Daemon404>
it's made up
<Lynne>
it's how an mdct codec works and you know it, it is delay introduced by the decoder
<Daemon404>
the correct delay for an mp4 with with no edit list or itunes metadata is 0
<Lynne>
so opus in mp4 with no edit list means our current decoder is broken for opus too?
<Daemon404>
youre not overwriting the decoder dela
<Daemon404>
youre overwrting the encoder delay
<Daemon404>
opus with no edit list isnt a valid mp4 per spec
<Daemon404>
aac s.
<Lynne>
decoder delay, it is a decoder delay, not an encoder delay
<Daemon404>
is*
<Daemon404>
skip_samples is for encoder delay
<Lynne>
no, it isn't
<Lynne>
I'd be perfectly happy to remove the base delay
<Lynne>
but I'd like to get the facts straight - this is algorithmic delay
<Lynne>
inherently present that shouldn't be there
<Daemon404>
youre confusing skip samples with pre-roll
<Lynne>
we remove pre-roll via skip samples
<Daemon404>
pre-roll (decode delay) has to be done on any seek
<Daemon404>
skip smples is only applie to packets with it
<Daemon404>
(usually the first packet)
<Daemon404>
(or well also subsequent packets if it overlaps)
<Lynne>
we do apply the pre-roll skip on every seek with my patch
<Daemon404>
this is not how the codebase works atm
<Daemon404>
thats not what the side data was intende for
<Lynne>
take it up with elenril, he asked me to use side data
<Daemon404>
you would need side data on every packet
<Daemon404>
that makes no sense
<Lynne>
we only put side data if there's a need to remove samples from a frame
<Daemon404>
pre-roll is not sent via side data from demuxers
<galad>
initial_padding and friend is not set for aac or others
<Daemon404>
because we dont handle pre-roll for aac in mp4.
<Lynne>
if I remove both the algorithmic delay of 1024 samples, and apply the edit list, I cut off too many samples
<Lynne>
if I only apply the edit list, it is correct
<galad>
then should it handle pre-roll for aac in mp4 too?
<Daemon404>
[18:01] <@Lynne> if I only apply the edit list, it is correct <-- yes
<Daemon404>
mp4 *does not* use edit lists to store pre-roll or aac
<Daemon404>
the edit list is *solely* for priming and end padding
<Lynne>
but it includes pre-roll for aac!
<Daemon404>
only for the first packet
<Lynne>
exactly
<Daemon404>
this is how edit lists work
<Daemon404>
you cannot extrapolate anything else from them
<Lynne>
yes, we only apply the edit list
<Lynne>
what's the problem?
<Daemon404>
the problem is an edit list of 0 (or missing) in mp4 means you *have* to decode and output the first 1024 samples
<Daemon404>
pre-roll is stored elsewhere
<Daemon404>
and is applied ifferently
<Daemon404>
this is by definition
<Daemon404>
you will find all players behave this way
<Daemon404>
so you cant just whack on 1024 in the case an edit list is missing
<Lynne>
okay, I can add a flag to indicate that missing side data means that nothing should be added, and set it via the demuxer
<Daemon404>
this only applies to the first packet btw (where the edit list would be)
<Daemon404>
seeking pre-roll is a different story
<JEEB>
yea, seeking preroll is something you can't export via edit list
<JEEB>
since edit list is a virtual time line
<Lynne>
during seeking, we remove the algorithmic delay
<Daemon404>
mp4 has facilities to store pre-roll
<galad>
I think I am missing something, what's the initial_padding in codecpar supposed to be? the priming delay?
<Daemon404>
not sure if files make use of it for aac
<Lynne>
it's a decoder delay
<Lynne>
not something that the encoder or muxer shold have knowledge or control over
<Daemon404>
galad, yes.
<galad>
then why mov.c is not setting it, while matroskadec.c is setting it from matroska codec_delay
<Lynne>
could we instead just unconditionally add side data for mov for the first frame only?
<Daemon404>
with 0 set?
<Lynne>
yes
<Daemon404>
no strong opinon
<Daemon404>
galad, diff containers, but also our mp4 opus is technically wrong :P
<Lynne>
I'll send a patch
<Daemon404>
>
<Daemon404>
The PreSkip field is not used for discarding the priming samples at the whole playback at all since it is informative only, and that task falls on the Edit List Box.
<Daemon404>
from opus mp4 spec
<Daemon404>
but we use the preskip for initial padding
<Daemon404>
it works, but is /techncally/ wrong ;)
<Daemon404>
i agree we have too many fields to do similar/same stuff
<Daemon404>
and how they interact is poorly understood
<galad>
Daemon404: I mean for aac in mp4, with an edit list and sgpd you are sgpd it should be possible to explicitely set the priming delay I guess
mkver has quit [Ping timeout: 255 seconds]
<Daemon404>
galad, edit list for priming, sgpd for pre-roll
<Daemon404>
but the edit list also includes the pre-roll.
<Daemon404>
but *only* for the start
<Daemon404>
mp4 brain damage :)
<galad>
right, but then initial_padding is never set in mov.c for aac
<galad>
anyway, it seems a mess
<Daemon404>
it is
<galad>
it is as "it's a mess" or "initial_padding is set for aac"?
<Lynne>
earlier you were talking about ass-pull values, there's one
<Daemon404>
4.3.6.2 Pre-roll Opus bitstream requires at least 80 millisecond pre-roll after each random access to get correct output.
<Daemon404>
from opus mp4 spec
<Lynne>
it's wrong
<Daemon404>
derf reviewed it...
<Lynne>
he skimmed through it at most
<Lynne>
because opus can have megaframes with 120ms of audio
<Daemon404>
i pinged derf
<Daemon404>
maybe we can get the spec fixed
<Daemon404>
(well 120ms works with 'at least' 80ms)
<Daemon404>
mov.c is wrong even by the spec
<Daemon404>
because it hardcodes it
<Daemon404>
this is such a weird part of the codebase
<Daemon404>
like half implemented
<Lynne>
technically, opus has energy values that are reset to zero while seeking
<Lynne>
they're signalled as deltas over the last frame
<Lynne>
though it's optional
<Lynne>
we reset them to zero during seeks
<Lynne>
which means that it takes time to sync back up to the encoder's values if the encoder signalled only deltas
<Daemon404>
just to avoid writing facilities for signalling pre-roll?
<Lynne>
it may take 80ms, but it could take less or more, but during this time, the audio data will still be valid, just with lesser amplitude
<Daemon404>
well yes, normal audio codec things
<Lynne>
that ramps up, so I think it's acceptable not to skip anything but the mdct algorithmic delay
<Daemon404>
the idea is youre suppose take the pre-roll into account when seeking
<Daemon404>
like choosing what packets to use
<Daemon404>
obv we do not...
<Lynne>
it's not like he-aac where you get +99999db white noise
iive has joined #ffmpeg-devel
<Daemon404>
if i had known all this at vdd i would have added it as a topic
<Daemon404>
what a mess
<Lynne>
I would not object to wiring up the algorithmic delay (no, I will never call it preroll, it's called algorithmic delay) from the container to use during seeks
<Lynne>
in fact, I would welcome it, because avtransport also has signals this
<JEEB>
mov(enc) are full of half-implemented stuff or stuff that is close enough but incorrect
<JEEB>
like the person who I commented to regarding raw PCM in mp4 not listening to my comments regarding why mp4 hard-codes certain values for the base audio sample definition
<Lynne>
it's an insane container, which has ruined and actively ruins hundreds of hours a video a day
<JEEB>
the container is at this point IMO pretty alright. it's people getting used to not following the spec for wahtever reason in our diety's year 2023
<Daemon404>
every time you say algorithmic delay i think of a song i know called Algorithmic Salvation
<Daemon404>
Lynne, at least it has a way to signal it
<Daemon404>
most containers do not
Ytsejammer has quit [Quit: Connection closed]
<Daemon404>
the problem is it has multiple ways.
<Daemon404>
for everything
<Lynne>
it's got as many names too
<Lynne>
using edit lists to trim both algorithmic delay and any additional samples is particularly deserving of a sentence to writing thounsands of lines of assembly
<Lynne>
something pointless, like h264 decoding on a z80
SystemError has quit [Ping timeout: 256 seconds]
<Daemon404>
Lynne, it make sense when you understand the whole presentation level bit of mp4
<Daemon404>
in a brain damaged way
<Daemon404>
it is self-consistent at least
b50d has joined #ffmpeg-devel
<Lynne>
a container should contain a continuous stream of data, meant to be presented sequentially
SystemError has joined #ffmpeg-devel
<Lynne>
patch sent for mov with no edit lists
<galad>
not in 1995, a video editing app could simply use mov and edit lists as its own file format. fun times.
<Daemon404>
lots of stuff in mov was nle stuff
<JEEB>
which is why edit lists technically might not be best handled on demux level but rather just exposed
<Daemon404>
embedded effects, transform matrices
<JEEB>
so presentation layer would handle them
<JEEB>
playback speed etc
<galad>
qtvr was cool
justache is now known as justHaunted
<Lynne>
edit lists should not even be present in the same file, they should be a separate cursed .xml file that some program takes as input to output a continuous stream of data meant to be presented sequentially, in real-time
<Lynne>
we could call it, I don't know, an editor
<Lynne>
a non-linear editor, if you will
<JEEB>
I don't consider edit lists any worse than virtual time lines in matroska
<Lynne>
obviously not, they're just as bad
mkver has joined #ffmpeg-devel
<Lynne>
Daemon404: are you also going to wire up seek_preroll?
<Daemon404>
i *was* ... but who will use it?
<Lynne>
such that it does something?
<Daemon404>
oh
<Daemon404>
yeah that part sounds tricky
<Lynne>
just insert it as side data
<Daemon404>
well ideally the avformat seek code takes it into account
<Daemon404>
but that seems like a huge amount of pain to wire up
<Lynne>
it's an avcodec field, though, so it should be decode.c adding it
<Lynne>
my patch will still do the correct thing if it's side data, if it's not set, it'll remove the algorithmic delay, otherwise it'll use the side data
aljazmc has joined #ffmpeg-devel
<Daemon404>
we should all go back to 2003 when aegisub would linearly decode audio tracks in memory/disk and seek in those
<Daemon404>
pcmlyfe
dellas has quit [Remote host closed the connection]
<Daemon404>
ill peer at it tonight tomorrow
<Daemon404>
as long as i dont degrade. seems i got rona in SF.
dellas has joined #ffmpeg-devel
aljazmc has quit [Remote host closed the connection]
<Lynne>
by the way, in the link you posted where initial_padding is set
<Lynne>
yeah, that field is encode-only :)
<Lynne>
oh, actually it is correct for -c:v copy, I think
<elenril>
>We are pleased to inform you that your article, "Critical phenomena in the collapse of gravitational waves" has been published online today, 30 October 2023, in the 3 November 2023 issue of Physical Review Letters (Vol. 131, No. 18)
<JEEB>
'grats
<Lynne>
did they send you a paper copy?
<elenril>
nah
<elenril>
not sure they even print them anymore
<elenril>
everybody reads it on arxiv anyway
<durandal_1707>
>We are pleased to inform you that your FFmpeg CLI patches have been rejected.
noonien has quit [Ping timeout: 255 seconds]
* elenril
throws EPERM at durandal_1707
noonien has joined #ffmpeg-devel
aljazmc has joined #ffmpeg-devel
aljazmc has quit [Remote host closed the connection]
<Daemon404>
how can it be published before the ate of the journal
<Daemon404>
time travel?
<elenril>
it's relativity, i don't have to explain shit
<elenril>
.nut
<Daemon404>
shit.nut, got it
<elenril>
explaining jokes is not cool
<Daemon404>
i am not cool
<elenril>
so anyway, did mpeg4 asp people go on to design mov?
<elenril>
or was it the other way around?
<Daemon404>
mov is early 90s
<Daemon404>
92 was it?
<JEEB>
no, apple designed mov aka qtff first, and then it was taken as a base for isobmff aka mp4
<elenril>
wow
<elenril>
that old?
<JEEB>
yea
<JEEB>
QTFF is oold
<elenril>
is avi that old even?
<elenril>
>introduced by Microsoft in November 1992
<elenril>
oh, I get it
<elenril>
they saw mov and concluded it had a fatal flaw
<JEEB>
lol
<Lynne>
in a slightly different alternate world, we'd have fragmented avi for dash
<elenril>
do we also subsist on cocroaches and recycled machine oil in that world?
HarshK23 has joined #ffmpeg-devel
<Lynne>
no, we invent different avi formats for each new codec
kmango has quit [Ping timeout: 255 seconds]
<Lynne>
but for backward compatibility, we encapsulate them as the previously standardized codec's data
<elenril>
i can live with that, there's no need for codecs after h264 and opus anyway
<Daemon404>
bring back ogm
<Lynne>
so avi (mpeg) encapsulates avi (h264) encapsulates avi (hevc) encapsulates avi (vvc or av1, history is getting blurry here)
<elenril>
i remember ogm fansubs
<elenril>
those were the days
<elenril>
anime was still good
noonien8 has joined #ffmpeg-devel
<durandal_1707>
anime is evil
<Lynne>
anime back then was just telecined bilinear blur
<Lynne>
with sometimes intentionally added scanlines
kmango has joined #ffmpeg-devel
<elenril>
what good is high image quality when it's all isekai moe trash
noonien has quit [Ping timeout: 260 seconds]
noonien8 is now known as noonien
dellas has quit [Remote host closed the connection]
<Lynne>
or 3dcg at 12/8/4fps
<Daemon404>
elenril, fansubs never did ogm
<Daemon404>
those were dvd rips in ogm
<Daemon404>
because it had dual audio tracks
dellas has joined #ffmpeg-devel
b50d has quit [Remote host closed the connection]
user23 has quit [Remote host closed the connection]
user23 has joined #ffmpeg-devel
MisterMinister has quit [Ping timeout: 246 seconds]
derpydoo has quit [Quit: derpydoo]
<courmisch>
sigh
<courmisch>
when do we get git AIrebase that automatically resolves conflicts
<Daemon404>
sounds safe
<courmisch>
come on, WhatCouldPossiblyGoWrong
Krowl has joined #ffmpeg-devel
<courmisch>
/* First eight entries repeated at end to simplify SIMD implementations. */
<courmisch>
Hmm... so for variable vector length, we should repeat all entries except the last one, to be sure that we can read the circular table at any offset