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
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 260 seconds]
rvalue has joined #ffmpeg-devel
lexano has quit [Ping timeout: 255 seconds]
<cone-176>
ffmpeg Michael Niedermayer master:e83e8d443b5b: avformat/jacosubdec: clarify code
<cone-176>
ffmpeg Michael Niedermayer master:b54c9a9c8f44: avcodec/osq: avoid several signed integer overflows
<cone-176>
ffmpeg Michael Niedermayer master:dd733b2be472: avformat/concatdec: clip outpoint - inpoint overflow in get_best_effort_duration()
<lfiorini>
JEEB: I've read the link you've send, am I missing something or in the first asm example there is a missing reduction step at the end to get the sum of m0 (just after paddw m0, m1)
ananas427 has joined #ffmpeg-devel
<Lynne>
lfiorini: no, that happens at the end
<Lynne>
it sums up the differences into words, 8 words per 128bit register, so two different sum registers
<Gramner>
lfiorini: the psadbw instruction horizontally adds the results of 8 sads (psadbq would have been a better name), so there's only two sums in the register to add after the loop
<Lynne>
yup, the two sums are added at the end
<Gramner>
https://www.felixcloutier.com/x86/ has an overview of the available instructions with pseudo-code for what they do (it's the same info as in the official intel documentation, but those are in pdf format which is somewhat obtuse to use compared to a simple html page)
MisterMinister has quit [Ping timeout: 246 seconds]
cone-176 has quit [Quit: transmission timeout]
rajivharlalka has joined #ffmpeg-devel
rajivharlalka is now known as rajivharlalka009
rajivharlalka009 is now known as rajivharlalka
rajivharlalka5 has joined #ffmpeg-devel
rajivharlalka has quit [Client Quit]
rajivharlalka5 is now known as rajivharlalka
cone-146 has joined #ffmpeg-devel
<cone-146>
ffmpeg Andreas Rheinhardt master:5eda98f38210: avcodec/mpegutils: Avoid allocations when using AVBPrint
<cone-146>
ffmpeg Andreas Rheinhardt master:e95dd6f53e49: avformat/file: Combine all CONFIG_ANDROID_CONTENT_PROTOCOL blocks
<cone-146>
ffmpeg Andreas Rheinhardt master:a6189ba896b2: avcodec/mpegutils: Simplify indenting
<cone-146>
ffmpeg Andreas Rheinhardt master:ebe832640945: avformat/file: Constify android content protocol
<cone-146>
ffmpeg Andreas Rheinhardt master:8d8b5947c336: configure: Make hls demuxer select AAC, AC3 and EAC3 demuxers
<cone-146>
ffmpeg Andreas Rheinhardt master:a990e6fa01cb: avformat/mux: Remove check for AVFMT_ALLOW_FLUSH
<cone-146>
ffmpeg Andreas Rheinhardt master:5144455c2011: avformat/hls: Don't access FFInputFormat.raw_codec_id
<cone-146>
ffmpeg Andreas Rheinhardt master:b93ed5c28ecc: avformat/fitsdec: Don't use AVBPrint for temporary storage
<cone-146>
ffmpeg Andreas Rheinhardt master:8768188581b4: avformat/g722: Inline constants
<cone-146>
ffmpeg Andreas Rheinhardt master:88f803cf6451: avformat/wvedec: Inline constant
<cone-146>
ffmpeg Andreas Rheinhardt master:56ba83ff2d72: avformat/fsb: Don't set data_offset manually
<cone-146>
ffmpeg Andreas Rheinhardt master:cdff5a2c0cfa: avformat/avr: Combine skips
<cone-146>
ffmpeg Andreas Rheinhardt master:69b85a69bdf0: avformat/wady: Combine skips
<cone-146>
ffmpeg Andreas Rheinhardt master:aa8c7dc3d8d5: avformat/argo_cvg: Avoid relocations for ArgoCVGOverride
<cone-146>
ffmpeg Andreas Rheinhardt master:cee70b9f1b37: avformat/lafdec: Fix shadowing
<cone-146>
ffmpeg Andreas Rheinhardt master:29aa499fc965: avformat/cdg: Don't store avio_size() return value in int
<cone-146>
ffmpeg Andreas Rheinhardt master:27af88fb7fe6: avformat/vqf: Return 0 on success in read_packet
<cone-146>
ffmpeg Andreas Rheinhardt master:4a4dcde339b8: avformat/internal: Move FF_FMT_INIT_CLEANUP to demux.h
<cone-146>
ffmpeg Andreas Rheinhardt master:ced5c5fdb863: fftools/ffmpeg_mux_init: Fix double-free on error
mkver has quit [Ping timeout: 264 seconds]
geoffhill has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
uau_ is now known as uau
ngaullier has joined #ffmpeg-devel
<cone-146>
ffmpeg Martin Storsjö master:e66858fbab23: aarch64: hevc: Reorder a misplaced function init line
<cone-146>
ffmpeg Martin Storsjö master:78db8405c012: aarch64: hevc: Don't iterate with sp in ff_hevc_put_hevc_qpel_uni_w_hv32/64_8_neon_i8mm
<cone-146>
ffmpeg Martin Storsjö master:e3a54cabde5e: aarch64: hevc: Merge consecutive stores in put_hevc_\type\()_h16_8_neon
<cone-146>
ffmpeg Martin Storsjö master:717cc82d2811: aarch64: hevc: Specialize put_hevc_\type\()_h*_8_neon for horizontal looping
<cone-146>
ffmpeg Martin Storsjö master:8f03c30a17c9: aarch64: hevc: Use ld1r instead of ldr+dup in hevc_qpel_uni_w_h
<cone-146>
ffmpeg Martin Storsjö master:6d384298ece1: aarch64: hevc: Implement a neon version of put_hevc_epel_h*_8
<cone-146>
ffmpeg Martin Storsjö master:54af555bfaaf: aarch64: hevc: Implement a neon version of hevc_epel_uni_w_h*_8
<cone-146>
ffmpeg Martin Storsjö master:e6d4c0e117ed: aarch64: hevc: Split the epel_*_hv functions into two parts
<cone-146>
ffmpeg Martin Storsjö master:5b5666e5ab5c: aarch64: hevc: Reorder epel_hv functions to prepare for templating
<cone-146>
ffmpeg Martin Storsjö master:7bf3d147691d: aarch64: hevc: Produce epel_hv functions for both plain neon and i8mm
<cone-146>
ffmpeg Martin Storsjö master:d7294199ab32: aarch64: hevc: Produce epel_uni_hv functions for both neon and i8mm
<cone-146>
ffmpeg Martin Storsjö master:96e5adda9f32: aarch64: hevc: Produce epel_uni_w_hv functions for both neon and i8mm
<cone-146>
ffmpeg Martin Storsjö master:de23b384fd7c: aarch64: hevc: Produce epel_bi_hv functions for both neon and i8mm
<cone-146>
ffmpeg Martin Storsjö master:ad01d06f919f: aarch64: hevc: Implement a neon version of hevc_qpel_uni_w_h*_8
<cone-146>
ffmpeg Martin Storsjö master:4063e50eeca0: aarch64: hevc: Split the qpel_*_hv functions into two parts
<cone-146>
ffmpeg Martin Storsjö master:4f71e4ebf236: aarch64: hevc: Deduplicate the hevc_put_hevc_qpel_uni_w_hv*_8_end_neon functions
<cone-146>
ffmpeg Martin Storsjö master:20c38f4b8d3e: aarch64: hevc: Reorder qpel_hv functions to prepare for templating
<cone-146>
ffmpeg Martin Storsjö master:5cbeefc79eea: aarch64: hevc: Produce plain neon versions of qpel_hv
<cone-146>
ffmpeg Martin Storsjö master:5ab138673b63: aarch64: hevc: Produce plain neon versions of qpel_uni_hv
<cone-146>
ffmpeg Martin Storsjö master:d21b9a041136: aarch64: hevc: Produce plain neon versions of qpel_uni_w_hv
<cone-146>
ffmpeg Martin Storsjö master:f872b1971401: aarch64: hevc: Produce plain neon versions of qpel_bi_hv
kurosu has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 256 seconds]
quietvoid has quit [Quit: No Ping reply in 180 seconds.]
quietvoid has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
lesam has joined #ffmpeg-devel
<Lynne>
I think I may have figured out why USAC went with 786-sample optional frames
<Lynne>
it's horrible
<Lynne>
so by default SBR upsamples by a factor of two
Krowl has joined #ffmpeg-devel
<Lynne>
so you put in 1024 samples (at 1/2 the samplerate) and it outputs 2048 samples (at 2x the samplerate)
<Lynne>
but they have designed a hardware-optimal SBR implementation that also lets them vary the SBR ratio
<Lynne>
and 8:3 ratio gives you 768 samples in, 2048 samples out
<Lynne>
which also means that without SBR, you have even lower bandwidth than a half
<Lynne>
~12khz vs ~8khz bandwidth doesn't make a big difference as everything above is noise anyway, but still
<nevcairiel>
is SBR even any good at replicating actual detail?
<Lynne>
lol
<Lynne>
no
j-b has quit [Changing host]
j-b has joined #ffmpeg-devel
<Lynne>
it's the audio equivalent of dolby vision, though you can at least hear the changes
<Lynne>
also all major AAC implementations (including ffmpeg's, in most cases) lowpass the audio aggressively to 15khz or so
Krowl has quit [Read error: Connection reset by peer]
j45_ has joined #ffmpeg-devel
lesam has quit [Ping timeout: 256 seconds]
j45 has quit [Ping timeout: 268 seconds]
j45_ has quit [Ping timeout: 240 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
cone-146 has quit [Quit: transmission timeout]
ramiro has quit [Ping timeout: 272 seconds]
ramiro has joined #ffmpeg-devel
<Lynne>
they also have a 4:1 ratio so you can upsample 12khz to 48khz
<Lynne>
at least they don't allow to easily update this on a per-frame basis, but then what's the point, no audio encoder does a whole file lookup to know it's acceptable
<nevcairiel>
i'm sure that link was on HN before, its only been 7 years :P
<kierank>
it's because I have been tweeting about lack of C and asm skills on @ffmpeg
<elenril>
it's not even that, kids these days don't see why you should run anything outside of a browser
<kierank>
the rustbots are insufferable
<kierank>
extolling the virtues of rust's inline asm (which is ugly as hell)
<BBB>
oo I made it to hackernews, now I can retire
<BBB>
\o/
<BBB>
" It's funny reading comments here, Hackernews bros really think they're smarter than the guys who made ffmpeg/x264/x265 etc. Dunning–Kruger effect in action. "
<Lynne>
not one of them will know the joys of actually writing assembly, press F
<elenril>
>1801 - Joseph Marie Jacquard uses punch cards to instruct a loom to weave "hello, world" into a tapestry. Redditers of the time are not impressed due to the lack of tail call recursion, concurrency, or proper capitalization.
___nick___ has joined #ffmpeg-devel
<nevcairiel>
I love comments like "I've been doing this for 20+ years", because you know .. time does not necessarily grant you wisdom. I have worked with plenty developers doing the thing for their entire life .. and still have no clue
MisterMinister has joined #ffmpeg-devel
<wbs>
yes, that usually just makes them more ingrained in their beliefs without taking the time and effort to revise things
<thardin>
is pcj leaking?
<elenril>
I never understood the argument that intrinsics are simpler
<elenril>
they are ugly as hell
<elenril>
and you still need to learn assembly anyway
<thardin>
rollercoaster tycoon is written in asm and is played to this day, checkmate C shills
<kierank>
I think they ported it
<kierank>
line by line to C
<kierank>
for newer releases
<thardin>
should've ported it to go
<elenril>
[shitposting intensifies]
ananas427 has quit [Ping timeout: 260 seconds]
<kierank>
a lot of people on twitter saying we should use go
<kierank>
I really enjoy that garbage collector taking 5ms
* Sean_McG
giggles
<Gramner>
elenril: true, using intrinsics means you now need to memorize intrinsic mnemonics on top of - not instead of - instruction mnemonics becuase guess what, when developing low-level code you do need to be able to disassemble stuff and understand the output
<BBB>
I love how you can make claims on hackernews ("Compilers are much much better with SIMD code than they were then.") without substance ("how much better?") or evidence ("by 20%")
<BBB>
and it just becomes true
<BBB>
it's like American politics
<BBB>
everything just gets dumber
<BBB>
at VDD I go above and beyond to back up every claim with numbers and graphs
<BBB>
but on hackernews I can just make it up
<BBB>
...
<Gramner>
i mean, a significant portion of the hacker news user base seems to think running 7 javascript frameworks stacked on top of each other running under electron is the pinnacle of software engineering, so what can you expect
<BBB>
o_O
<JEEB>
at least some mention wasm
<kierank>
the one saying the error messages are cryptic because of macros is a fair point
<kierank>
but nasm is getting better at that
<Lynne>
can't remember the last time I didn't know where my mistake was
<Gramner>
like 99% of the time it points at the line containing the error, plus every line of macro invocation, when using a chain of nested macros
<wbs>
you guys make mistakes?
<Gramner>
there are some obscure edge cases where it's super confusing but those are really rare
<wbs>
:P
lexano has joined #ffmpeg-devel
<Gramner>
it's trivial compared to interpretating msan errors which sometimes just points at some function call and just tells you that something is unitialized here somewhere
jamrial has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
ngaullie has joined #ffmpeg-devel
Teukka has quit [Read error: Connection reset by peer]
ngaullier has quit [Ping timeout: 264 seconds]
<kierank>
wbs: "This patchset takes decoding of a 1080p HEVC clip from 402
<kierank>
fps to 649 fps on an Apple M1."
<kierank>
should that say M2?
<wbs>
no
<wbs>
M1
<kierank>
oh, I see I misunderstood the commit message
<wbs>
the thing is, we had I8MM HEVC asm since last year. But I8MM is only usable on M2 and newer
<kierank>
you're adding the older neon
<wbs>
yep
rvalue has joined #ffmpeg-devel
<wbs>
it's like you'd have avx512 simd only, for the bulk of a decoder's operations
<wbs>
very nice if you have that hw, but useless if there's no default implementation for a more reasonable baseline
Teukka has joined #ffmpeg-devel
Teukka has quit [Changing host]
Teukka has joined #ffmpeg-devel
<wbs>
on HW with I8MM support, I still can't benchmark almost any difference between my basic neon, compared to the shiny I8MM stuff
<wbs>
(in checkasm there's a small margin of difference, but not really measurable on real world decoding)
lesam has joined #ffmpeg-devel
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
Livio has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Livio has quit [Ping timeout: 260 seconds]
<BBB>
I got nerdsniped again. I hate you all
<jamrial>
what happened
<BBB>
I offer $10 for whoever can nerdsnipe me into writing a VVC assembly function. consider it a challenge
<BBB>
it's kieran's fault
<BBB>
<3
* JEEB
got nerdsniped to poke at OpenUtau last night, went to sleep way too late
<JEEB>
(computer voice generation stuff)
<wbs>
jamrial: to follow up on the issue with "check that host compiler supports c11", see https://github.com/mstorsjo/FFmpeg/actions/runs/8427389429/job/23077833389 - now it just fails on configure with "Host compiler lacks C11 support" (when I have no host compiler, and have a build configuration where I didn't use to need one)
<jamrial>
mmh
<wbs>
not entirely sure what the best way forward is either. the check makes sense, but I'd also like to leave the hole of "not having any host compiler at all"
<jamrial>
how does having no host compiler work anyway?
<wbs>
running things in a container where I only have a cross compiler installed
<wbs>
for a default build configuration, the host compiler isn't triggered afaik
<wbs>
it's used if you do hardcoded tables which builds some table generator tools at build time
<wbs>
hmm. but it does build the doc/print_options and ffbuild/bin2c executables normally... let me see why that doesn't fail
<jamrial>
wbs: you don't run fate either? the generators for vsynth%.yuv and asynth-%.wav use hostcc
<wbs>
jamrial: hmm, I don't run the full fate, no, only checkasm in this config. I guess it's possible that doc/print_options isn't needed if I just do "make fate-checkasm"
<wbs>
jamrial: so in that case, I guess I can agree that this is too small of an exceptional case that it's not worth catering for
<jamrial>
doc/print_options is probably to generate documentation, and yeah, fate-checkasm doesn't need the v/asynth input files
lfiorini has joined #ffmpeg-devel
<wbs>
yes, if I'd just do a plain "make" before "make checkasm", it would hit the same failure already in trying to build doc/print_options
<wbs>
i.e., nevermind, sorry for the noise, I'll buy myself a host compiler :P
<Daemon404>
BBB, just block HN in your hosts file
<BBB>
that's a good idea
<BBB>
Daemon404: do you guys still use av1-elevator?
<BBB>
use=maintain
<BBB>
mkver: ping about cbs_vp8 patches. can they be applied? (since you commented on them earlier)
<Daemon404>
BBB, no
<Daemon404>
because it doesnt work chunked (youd need to patch the resulting file)
<Daemon404>
maintain? yeah
<Daemon404>
not use
<mkver>
BBB: Yes
<BBB>
mkver: will you merge, or should I?
<mkver>
I don't care.
<BBB>
I'll do it today
Krowl has quit [Read error: Connection reset by peer]
System_Error has quit [Remote host closed the connection]
<cone-201>
ffmpeg Dai, Jianhui J master:63dea3c1e10a: avcodec/cbs_vp8: Use little endian in fixed()
System_Error has joined #ffmpeg-devel
<cone-201>
ffmpeg Dai, Jianhui J master:61afe4d98ce6: avcodec/cbs_vp8: Improve the bitstream position check
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg-devel
MikhailAMD has joined #ffmpeg-devel
MikhailAMD has quit [Client Quit]
TheSashmo has quit [Quit: Leaving...]
<cone-201>
ffmpeg James Almer master:1e7ba7656294: avformat/mov: free HEIFItem.name when cleaning items in mov_read_trak
<mkver>
This is actually intended; but it may nevertheless be a bug.
<mkver>
Are you running into multiple definition warnings from your linker?
<mkver>
(And I merely moved this line, I did not create it.)
<thilo>
no the file exists, then it should be ok
<thilo>
i don't, someone reported it to devel-owner
<thilo>
without any further info
<Marth64>
good old jni
<mkver>
I am aware that there are patches for this on the ML.
j45 has quit [Ping timeout: 260 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 240 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45 has quit [Ping timeout: 268 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
j45_ has joined #ffmpeg-devel
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45 has quit [Ping timeout: 240 seconds]
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
ananas1231 has joined #ffmpeg-devel
lfiorini has quit [Ping timeout: 256 seconds]
___nick___ has quit [Ping timeout: 256 seconds]
___nick___ has joined #ffmpeg-devel
ananas1231 has quit [Ping timeout: 252 seconds]
Guest52 has quit [Ping timeout: 250 seconds]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 260 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 268 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45_ is now known as j45
j45 has quit [Ping timeout: 268 seconds]
j45 has joined #ffmpeg-devel
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 268 seconds]
j45_ is now known as j45
j45 has joined #ffmpeg-devel
j45 has quit [Changing host]
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 268 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
<Traneptora>
Marth64: wrt ur patch I have no objections but you have me tagged, could you replace Traneptora with Leo Izen <leo.izen@gmail.com>
<Traneptora>
before you commit
<Traneptora>
wrt reported by. that's what I use
<Marth64>
Traneptora: /me doesn't have commit rights. I don't think I should have them either. I apologize, I will be more conscious of that next time when I write the commit message.
<Traneptora>
I can push that if you'd like then
<Marth64>
Please, thank you. I think it's a positive fix.
<cone-201>
ffmpeg Marth64 master:9df11820650b: avformat/dvdvideodec: add explicit inttypes.h include
<Marth64>
w00t
<Marth64>
I am still too prone to making mistakes. I will gladly maintain dvd but I'm not comfortable yet to have merge access.
<Marth64>
principle of least privs :D
<Traneptora>
that's how I was for a bit
<Daemon404>
this vote sure is something
<Daemon404>
can i write my vote
<Daemon404>
because i vote "go touch grass"
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<JEEB>
Daemon404: touching grass is good
<Daemon404>
indeed
<Gramner>
no grass here, only snow
<Daemon404>
do you wanna build a snowman?
xvaclav has quit [Quit: Ping timeout (120 seconds)]
xvaclav has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<elenril>
Daemon404: the time for proposals was a month ago
<Daemon404>
^ frozen if it was made in the EU
Lata has joined #ffmpeg-devel
<Lata>
Hi @ cosminaught, my name is Lata. I am interested in contributing in Update SITI filter to match with latest specification project. As a part of qualification task I have to solve a bug in an existing filter. Could you please provide me a bug that needs attention or share any reference where I can find the potential issue to solve in this area?
Guest52 has joined #ffmpeg-devel
<Marth64>
I'm making a roadmap for what I want to contribute in 2024... Besides investing in ccaption_dec, I was thinking of other subtitle quality of life improvements. Looks like in 2021 someone started a large subtitle filtering support patchset but due to various unaddressed feedback, etc. it didn't go through. I have many use cases myself where I'd prefer to just use ffmpeg for simple subtitle
<Marth64>
Are there any red flags or "hard NO" to try and reboot this work? It is a huge mountain to climb, but I would not mind to pursue the same effort more slowly over the course of a year, preferrably broken into smaller patches over time. I am not sold on the OCR stuff belonging in FFmpeg but at least the base idea of subtitle filtering seemes quite valuable.
<JEEB>
I think one of the most clear funky points was just the duplication of AVSubtitle fields in AVFrame
<JEEB>
it's understandable the person didn't want to go through the work of "just using AVFrame fields where applicable", as he had already verified his work in production
<JEEB>
but basically duplicated fields meant that you'd just have to deprecated those as things got moved into the existing AVFrame ones
<JEEB>
which would be sub-optimla
<JEEB>
*optimal
<JEEB>
but yea, I believe the work could be finished in steps.
<Marth64>
Makes sense. Since I don't have a production pressure using FFmpeg, I'm willing to ride it out in favor of doing the right thing.
<Marth64>
I'll reach out to the original author if they will allow to study/use their material with credit, where applicable.
<Marth64>
I would do Blu-ray demux instead of this, but I risk getting in trouble for that, I'm sorry. So I was hoping to carve a niche in the subtitles space :D
<kierank>
WARNING: Disabled drawtext_filter because not all dependencies are satisfied: libfreetype libharfbuzz
<kierank>
why does this need harfbuzz now
<JEEB>
Marth64: I don't think libbluray would be any worse than the DVD stuff. the project is pretty clearly aimed at just the non-decryption related things
<Marth64>
I guess it is libbluray doing the initialization of those libs, hmm...
<JEEB>
yea
<JEEB>
libbluray may attempt to load certain other libraries
<JEEB>
but that is outside of your scope
zsoltiv_ has quit [Client Quit]
<Marth64>
yes, that is libbluray's business
zsoltiv_ has joined #ffmpeg-devel
zsoltiv_ has quit [Ping timeout: 255 seconds]
<Marth64>
i emailed the 2021 subtitle filtering patchset's author to request permission to recycle parts of his/her work where applicable
<Marth64>
hoping for a yes
<Marth64>
i would love to throw away all these goofy python scripts and windows tools and just use ffmpeg for simple subtitle edits
Sean_McG has quit [Quit: leaving]
zsoltiv_ has joined #ffmpeg-devel
zsoltiv_ has quit [Client Quit]
zsoltiv_ has joined #ffmpeg-devel
<JEEB>
Marth64: well since the work was technically posted on the ML etc, that code should be under LGPL -> as long as authorship etc is kept it should be fine, even without asking
<JEEB>
of course it's a nice gesture to ask
zsoltiv_ has quit [Client Quit]
zsoltiv_ has joined #ffmpeg-devel
<Marth64>
fair point
Lata95 has joined #ffmpeg-devel
zsoltiv_ has quit [Ping timeout: 272 seconds]
rvalue has quit [Ping timeout: 252 seconds]
Lata95 has quit [Quit: Client closed]
rvalue has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
lesam has quit [Read error: Connection reset by peer]
cone-201 has quit [Quit: transmission timeout]
Marth64 has joined #ffmpeg-devel
Lata has quit [Quit: Client closed]
jafa has quit [Read error: Connection reset by peer]
jafa has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
jess has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
mkver has quit [Ping timeout: 264 seconds]
<elenril>
Marth64: subtitles are cursed
<Lynne>
any opinions of trying to export DRC handling out of decoders like we do with film grain?
<Lynne>
at the same time we can also support replaygain properly rather than random values in metadata
<jamrial>
i thought ac3 required the decoder to do it
<elenril>
Actual votes cast thus far: 10
___nick___ has quit [Ping timeout: 252 seconds]
___nick___ has joined #ffmpeg-devel
<JEEB>
Lynne: with regards to stuff like MPEG-D?
<Marth64>
elenril: i'm starting to think all a/v is cursed at this point lol
<elenril>
it is
<elenril>
but especially subtitles
<Marth64>
they are pretty awful
<Marth64>
Lynne: I've always envisioned a way where I could "render out" my AC3 presentations to FLAC and keep their dialnorm value as ReplayGain
<Marth64>
not sure I've seen a player support ReplayGain for movie files though
<Marth64>
or whatever <insert complex proprietary format here>
<kepstin>
fun fact: mpv does support replaygain in mp4 and mkv files when playing video
<Marth64>
o neat
<Marth64>
but you said DRC ... I guess that's different than loudness normalization
<Marth64>
technically
<kepstin>
iirc the ac3 drc stuff is basically metadata telling the decoder how to change the volume level over time to compress dynamic range without needing to do any real-time audio analysis?
<Marth64>
my understanding is there are 2 values
<Lynne>
kepstin: it supports them anywhere with metadata, it's neat
<Marth64>
(1) DRC profiles for "RF mode" (high compression) or "Line mode" (med compression) and (2) dialnorm / attenuation
<Marth64>
and somehow they are interdependent
<kepstin>
hmm. i would have assumed that the main thing that does is allow adjusting the center channel (where dialog is normally located) to have a different volume from the other channels.
Marth64 has quit [Ping timeout: 268 seconds]
___nick___ has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg-devel
<Marth64>
i think there was a public documentation on it... checking if i saved the link
<kepstin>
i guess it's the opposite of replaygain, where it communicates the absolute level of the loudness of dialog in the stream (in dBFS), rather than communicating the difference from a reference level.
<kepstin>
it's in the ETSI spec, section 6.6 and 6.7
<Marth64>
Dialnorm is, but not RF mode / Line mode
<Marth64>
which are High DRC / Medium DRC respectively, and then within those there are different compressor values (fixed in a set of "profiles")
<Marth64>
i am not an audio expert but i was studying this a while back in an effort to document ac3dec's -high_compr option
<kepstin>
ah, etsi just says "It is also permissible (again under listener control)
<kepstin>
for the decoder to use some fraction of the dynrng control value"
<Marth64>
yes and here in ATSC world we have TVs that have "Night mode" ( == RF mode == High DRC)
<Marth64>
and somehow the dialnorm value is related to that compression too
<Marth64>
if i recall
<kepstin>
an, interesting, the atsc adds a second control word for the "rf mode"
<Marth64>
its a neat feature. i took advantage of this big time in my personal library, by using AC3 tracks to render out "RF mode" compressed tracks == studio-tested TV night mode tracks
<kepstin>
i guess the trick with dialnorm is that you want the stream to play at the same loudness either with or without dynamic range compression
<Marth64>
no more fussing with janky built-in tv compressor or dynamic volume things
<Marth64>
ahh makes sense
<kepstin>
(specifically, "dialogue" should be at the same loudness, and with drc louder things might be attenuated, and quieter things might be amplified)
<kepstin>
it's not really specified in these documents, but if the drc values are set so that audio at dialog level is neither attenuated or amplified (i.e. dynrng and compr both say to adjust level by 0dB), then applying correction for dialog normalization after doing drc should be correct.
<Marth64>
that makes more sense, and i'll bet the DRC profiles are chosen/tuned to the dialnorm value
<ngaullie>
I don't know what is specified, I am not an audio expert, but what I can say is that a d***y certified decoder uses the dialnorm value as a target for the drc. I mean the dynamic, packet level 'compr' is used along with the static 'dialnorm' to control the drc.
<kepstin>
quote: All DRC calculations are relative to and based on the indicated loudness of content as represented by the dialnorm metadata parameter. In other words, the encoder needs to know how loud the content is intended to be so it can determine when the content is either “too loud” or “too quiet.” dialnorm effectively sets this target.
mkver has joined #ffmpeg-devel
<Marth64>
which brings me back to -high_compr option of ac3dec
<Marth64>
i theorize it is RF mode in disguise
<Marth64>
when combined with the dialnorm value which the decoder honors by default
<kepstin>
yeah, that probably just switches it to use the "compr" control words insteadof the "dynrng" control words
<kepstin>
the name sounds suspicious :)
<Marth64>
ohhhhhh so compression was abbreviated for a readpn
<Marth64>
reason*
<Marth64>
because compr actually means something in the context of ac3
<kepstin>
anyways, yeah, highly recommend reading A/85 for this topic. it clearly explains everything.
<JEEB>
:)
<Marth64>
knowing that mpv does replaygain on movie files is nice
<Marth64>
i will remember that
<kepstin>
AESTD1008 suggests that speech should be normalized at around 2LU quieter than music, and modern replaygain stuff targets -18LUFS, so i'd suggest converting AC3 dialnorm to replaygain adjustment values by subtracting -20.
<kepstin>
if you happen to want to do that for some reason
<Marth64>
i do
<Marth64>
if Kodi also supports replaygain on mkv, this is game changer for me
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
<Marth64>
i have a fascination with this idea of having night-time TV friendly tracks (heavy DRCd) pre-rendered to flac and passing a replaygain value with it to my player
<Marth64>
then i dont need to keep adjusting volume with the remote, and i don't have to rely on dynaudnorm filter which has mixed results for me
<Marth64>
eg. AC3 track -> RF mode compression -> "en-US (TV).flac"+replaygain -> TV at night in low volume
<Marth64>
that probably came out as jibberish but yeah
<kepstin>
dynaudnorm uses pure rms measurements rather than something perceptually weighted, so I could see it not doing great on different types of content.
<Marth64>
durandol_1707(?) i think once told me it was kind of a hack
<Marth64>
wasn't sure if it was that one or loudnorm
<kepstin>
loudnorm is the one that's kinda troublesome
<kepstin>
in theory it's really cool - uses ebu r.128 techniques to measure loudness and then applies dynamic range compression dynamically.
<kepstin>
but in live mode it can be kinda weirdly buggy at times.
<Marth64>
my only issue with loudnorm filter is that it can't read its own values between passes when using with cli. so if you run measurement pass, then want to feed the values to the next pass, you need to write a script to parse them and refeed them as filter options
<kepstin>
it mostly works, and I actually have an mpv profile set up to use loudnorm for watching livestreams on youtube by streamers who don't know how to set up audio compression properly.
<Marth64>
ideally i'd like the filter to save an output file with the parameters and be able to read that same file for the parameters and call it a day
<Marth64>
ha. nice
<JEEB>
Marth64: except filters aren't supposed to touch files themselves. I think that filter might already be attaching side data to frames it outputs, so you just need a tool that then writes the result in some format that a file reader can then parse in ffmpeg or otherwise (and attach to the relevant AVFrames as side data).
<Marth64>
ahh...that would work too.....so measure (pass 1)->serialized side data, then normalize (pass 2)->give filter serialized side data and it would do the rest?
<Marth64>
skipping file i/o entirely but at the same time letting loudnorm parse its own values
<kepstin>
(it's always kinda weird when you hit professionally produced live youtube streams like hololive studio stuff; it seems like they hired some sound engineers with live tv experience, the audio's almost always 1LU of -14LUFS when averaged over the whole stream)
<kepstin>
within 1LU*
<JEEB>
Marth64: if you can do it without file I/O, surefine.jpg. I just wanted to note that the filter wouldn't be the thing doing the file I/O
<kepstin>
yeah, it would have to be done with a tool using ffmpeg apis. dunno whether it would make sense to support that in ffmpeg.c?
<Marth64>
got it
<JEEB>
also I totally recalled it doing side data and mpv or something even reading that at one point, but somehow I don't find side data related hits in af_loudnorm
<Marth64>
no file i/o necessary. loudnorm has a print_format option which can produce the values in JSON. so maybe some way to just give that string back to it, is good enough, so it can deserialize it without the help of an external tool
<Marth64>
as it stands now i have to take that JSON, parse it in another script and rename the keys, then reconfigure the filter for the second pass
<kepstin>
i know the ebur128 filter produces side data.
<JEEB>
kepstin: right, that was the one!
<JEEB>
since that was the one utilized for 2pass usually
<JEEB>
not loudnorm
<kepstin>
yeah, the reason for using loudnorm is that it can _also_ do dynamic range compression.
<Marth64>
woah. there are 2 ebu r128 filters? :o
<Marth64>
til
<JEEB>
Marth64: I mean, from the filter it would get exposed as structured metadata (AVFrameSideData) which would get attached to the AVFrame
<JEEB>
then the logic receiving those AVFrames can do whatever it wants with that
<JEEB>
since you effectively receive a struct with stuff
<JEEB>
yea I think there's a few ebur128 things
<JEEB>
which is why the ff_ebur128 functions exists
<kepstin>
ebur128 is just a filter that calculates integrated and momentary values for loudness, loudness range, and peak (true peak) using the specified algorithm.
<kepstin>
the other filters might use the same algorithm, but actually _do_ something with it rather than simply expose the results.
<JEEB>
ok, it's just ebur128.c and af_loudnorm.c
<kepstin>
i wonder if af_loudnorm even needs to run the analysis itself, or if it would work fine chained after an ebur128 filter and reading the side data :)
<Marth64>
i was just going to say this
<Marth64>
seems some duplication there
<kepstin>
it's technically not duplication, since they've been refactored to share library code.
<Marth64>
good
<Marth64>
cool
<Marth64>
hey this was interesting. thanks JEEB&kepstin
<JEEB>
lol, don't tell me f_ebur128 doesn't utilize ebur128
<JEEB>
ayup, no results
<kepstin>
oh, lol.
<kepstin>
did that work just never get finished? :/
<Marth64>
it never did sound right for me, this is how i came to learn about AC3 RF mode to begin with
ngaullie has quit [Ping timeout: 264 seconds]
<kepstin>
well, loudness and dynamic range are _completely separate_ things :)
<Marth64>
ac3's RF mode compression + dialnorm sounded great almost always, whereas i had to play aorund too much with [dyn]loudnorm
<Marth64>
right, but together, achieve my desired effect for night-time viewing
<Marth64>
i sadly don't have an AVR, just stereo tin cans and headphones
Livio has joined #ffmpeg-devel
<kepstin>
in theory, with some tweaking of the thresholds / gain curves, it should be possible to make a filter like loudnorm work just as well as the dolby encoder's ac3 dynamic range normalization…
<kepstin>
but annoyingly it would always be a two-pass thing to work well, since the dynamic range normalization needs the program's integrated loudness (or dialogue loudness) as an input.
<Marth64>
yeah makes sense, hence my thought of wasting disk space and pre-rendering the tracks (which will not work for broadcast but for local viewing is ok)
<Marth64>
i cheat now by using -heavy_compr
<kepstin>
the A85 doc actually includes a picture of what the response curves in the dolby encoder's DRC profiles for speech, music, and film look like.
<kepstin>
(doesn't include the time constants for the attack and decay tho)
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg-devel
cone-972 has joined #ffmpeg-devel
<cone-972>
ffmpeg Michael Niedermayer master:0a114d7318ab: avformat/mov: Do not deallocate heif_item in a input dependant way
<cone-972>
ffmpeg Michael Niedermayer master:d188a867302f: avcodec/rtv1: fix undefined FFALIGN
<cone-972>
ffmpeg Michael Niedermayer master:48eeb198a558: avcodec/hcadec: do not allow code to continue after failed init
<cone-972>
ffmpeg Michael Niedermayer master:addb85ea3930: avcodec/hcadec: do not set hfr_group_count to invalid values
<cone-972>
ffmpeg Michael Niedermayer master:7eabe564365f: avcodec/qoadec: Fix undefined overflow in lms_predict
<cone-972>
ffmpeg Michael Niedermayer master:ebdcf9849905: avcodec/truemotion1: Height not being a multiple of 4 is unsupported
<cone-972>
ffmpeg Michael Niedermayer master:6009dd07bd2b: avcodec/wavarc: Avoid signed integer overflow in sample
<cone-972>
ffmpeg Michael Niedermayer master:1eb8cbd09c5f: avcodec/wavarc: avoid signed integer overflow in AC code
<Oneric>
Marth64: thanks for the review and ping btw :)
<mkver>
Crazy that so many people report this ffjni bug. lavu/vulkan.c is also duplicated into lavc and lavfi (even for static builds) and no one ever reported any problems with that.
<nevcairiel>
we do that intentionally for a few files - although we actually have a "proper" way to do that through the makefiles, rather then plain including .c files
<cone-972>
ffmpeg Michael Niedermayer master:007486058c2e: avformat/concatdec: Check user_duration sum
<cone-972>
ffmpeg Michael Niedermayer master:746203af3116: avformat/jacosubdec: Use 64bit for abs
<cone-972>
ffmpeg Michael Niedermayer master:f01a89c5a378: avformat/mov: use 64bit for intermediate for rounding
<cone-972>
ffmpeg Michael Niedermayer master:3d8d778a6853: avformat/timecode: use 64bit for intermediate for rounding in fps_from_frame_rate()
<cone-972>
ffmpeg Michael Niedermayer master:878625812f16: avformat/rpl: Use 64bit for total_audio_size and check it
<cone-972>
ffmpeg Michael Niedermayer master:0bed22d597b7: avformat/sbgdec: Check for negative duration
<cone-972>
ffmpeg Michael Niedermayer master:75317ec4420d: avformat/wavdec: sanity check channels and bps before using them for block_align
<cone-972>
ffmpeg Michael Niedermayer master:61dca9e150b7: avformat/wavdec: satuarte next_tag_ofs, data_end
<cone-972>
ffmpeg Michael Niedermayer master:e849eb23432e: avformat/matroskadec: Check timescale
<cone-972>
ffmpeg Michael Niedermayer master:86f73277bf01: avformat/westwood_vqa: Fix 2g packets
<Marth64>
Oneric: np the backslash one is imo a important fix
<Marth64>
i have seen backslashes in summarized or children's subs where they simplify the language spoken
Livio has quit [Ping timeout: 252 seconds]
IndecisiveTurtle has quit [Remote host closed the connection]
<Marth64>
one think i haven't thought if is how does ffmpeg's own ass demuxer react to the changes
<Marth64>
one thing i haven't thought of until now*. but libass reacted ok
IndecisiveTurtle has joined #ffmpeg-devel
<JEEB>
/41/45
<cone-972>
ffmpeg Michael Niedermayer master:4126a99d2b0f: doc/APIchange: Fill in some missing thingss
IndecisiveTurtle has quit [Remote host closed the connection]
<michaelni>
if someone wants to review my version bumping patches for 7.0 its on the ML
qeed_ has joined #ffmpeg-devel
IndecisiveTurtle has joined #ffmpeg-devel
qeed has quit [Ping timeout: 256 seconds]
<IndecisiveTurtle>
Lynne: I believe I have implemented the requested changes. Separated the haar transform to a function and added a configurable block size (tested 2, 4, 8 so far with 1 and 2 levels).
<IndecisiveTurtle>
Also sorry for the delay on this, couldn't access irc client on the weekend
<jamrial>
michaelni: the bump set looks good. I assume the branch happens on patch 3, right? so patch 4 is the first commit in master post branch
alien_lappy has joined #ffmpeg-devel
<alien_lappy>
could someone please look at https://trac.ffmpeg.org/ticket/10711 ? this is a big issue due to YT outputting these dash headers that are now "invalid". for projects like yt-dlp the livestream only output this audio.
<alien_lappy>
I have this issue at several samples (some with big headers )