michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.0.2 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
wyatt8740 has quit [Ping timeout: 276 seconds]
<Traneptora>
did it get improved to the point where it was actually ok
wyatt8740 has joined #ffmpeg-devel
thilo_ has quit [Ping timeout: 248 seconds]
thilo_ has joined #ffmpeg-devel
<aaabbb>
Traneptora: at higher bitrates it's ok, it's much better than it was pre-twoloop
<Lynne>
its okay, but there's no avenue for improving it IMO, this design is as good as it'll get
<Lynne>
the current coder is a nightmare of heuristics that try to improve each situation individually
<aaabbb>
Lynne: no aveue for improving? what about that trellis thing? average noise whatever that is experimental?
<aaabbb>
anmr
<Lynne>
exactly that
<Lynne>
it was the cutting edge... 10 years ago
<aaabbb>
the manpage still marks it as experimental and having potential. is twoloop better than anmr could be now?
<Lynne>
yes
<Lynne>
err, no
<Lynne>
these days I actually think a small RNN would do a better and faster job
<aaabbb>
iirc libopus does that for speech/voice classification, and has found that small rnn can be extremely fast and useful in that area
<Lynne>
yup, exactly, you wouldn't need to manually listen to hundreds of hours of various content
<Lynne>
but train a small NN on a few thousand hours with a quasi-dubious metric to have it decide what parameters to use
<aaabbb>
any considerations on rework or improvement on that aspect of aac? it is a serious problem in the adult video streaming industry where ffmpeg is stupidly used with default settings for encoding and often with 64k-96k aac
<aaabbb>
which increases streaming costs for the companies
<Lynne>
the current encoder is extremely afraid of leaving any spectral holes (i.e. frequency regions which quantize to 0), but that's not always the best choice
<Lynne>
pretty sure twitter still uses ffmpeg's aac encoder too
<aaabbb>
ouch...
<Lynne>
twitch would benefit a lot from a better aac encoder since the default windows one isn't great either
<Lynne>
but they didn't seem interested some years ago in helping us
<aaabbb>
many do not understand or realise the issue, and aac is the most popular audio codec that ffmpeg is used to encode, for better or worse, and in almost all cases the native is used
<BtbN>
The most common AAC Encoder for Streaming to Twitch is Apple CoreAudio
<Lynne>
don't users need to jump through hoops to install it?
<aaabbb>
well that's actually a good encoder
<aaabbb>
Lynne: not on macos
<BtbN>
No, the instructions just say "Install iTunes"
<BtbN>
And then OBS uses it
<aaabbb>
oh
<aaabbb>
if the licensing situation on fdk-aac was better, it would be just perfect
<Lynne>
sounds fragile
<Lynne>
god no
<BtbN>
Not really, you just try to dlopen the dll, and if it opens, you can use it
<BtbN>
iTunes puts it on PATH
<Lynne>
if our native aac encoder is currently not easy to improve, fdk-aac faces a granite wall in terms of improvement avenue
<BtbN>
People on my builds are pestering me to "please enable CoreAudio on Windows", not understanding the situation
<aaabbb>
Lynne: but it's still better than current twoloop encoder
<aaabbb>
in their current state
<Lynne>
what good is something you can't improve?
<BtbN>
Why does an encoder for some old codec need to be infinitely improved?
<aaabbb>
if it lasts long enough that aac-lc goes the way of mp3...
<BtbN>
Of course you'll eventually hit some kind of wall, or a steeper and steeper cliff
<Lynne>
I'm on the opus side, wouldn't use aac myself, so the only good aac code is a toy I can play with
<aaabbb>
all it has to do is survive long enough that most people move to usac or opus
<Lynne>
usac lol
<Lynne>
how many levels of 4D audio are you on?
<aaabbb>
i'm not a fan of usac but it's better than aac-lc at least
<Lynne>
its the same thing
<aaabbb>
huh? usac is xhe-aac, aac-lc is a totally different thing
<Lynne>
its the same underlying codec
<Lynne>
same issues as aac-lc
<aaabbb>
i thought usac was something completely different that just got blessed with the aac name
<Lynne>
its got a little better quantization and some stereo prediction mode which is placebo 50% of the time, but it still uses scalefactors like aac-lc, with the same exact way of quantizing and coding them
<aaabbb>
how does it get away with transparency at such a low bitrate vs aac-lc?
<aaabbb>
admittedly i know much more about opus than aac-lc or usac, which i know very small amount
<Lynne>
same way as he-aac, with SBR (uses the same SBR system)
<aaabbb>
usac uses sbr? ew
<aaabbb>
is usac just a hybrid of he-aac an aac-lc like opus is of silk and celt?
<Lynne>
only for speech
<Lynne>
unified speech and audio codec
<aaabbb>
i always thought that usac was nothing at all like aac-lc, i guess i need to read more about it
<Lynne>
read the source code in ffmpeg
<Lynne>
you can see how much of it is reused
<aaabbb>
will do
<aaabbb>
i only hope that more companies will choose opus over usac
<Lynne>
re: the adult film industry using our aac encoder
<Lynne>
its a step up, they used to use realaudio 5.0 up until 2 years ago, didn't they?
<aaabbb>
no, most used aac-lc for quite a while. but i guess it depends on what kind. i am thinking about streaming sites. most physical distribution uses eac3
<Lynne>
its a joke
<ePirat>
whats the deal with AVInteger? it seems its only used in one place throughout the codebase?
<aaabbb>
o
<Marth64>
AVInteger wut
<ePirat>
it seems overkill to me to have that as public API when its used only in a single place
feiw1 has quit [Ping timeout: 246 seconds]
feiw1 has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
feiw1 has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
feiw1 has quit [Remote host closed the connection]
witchymary has quit [Remote host closed the connection]
feiw1 has joined #ffmpeg-devel
witchymary has joined #ffmpeg-devel
darkapex_ is now known as darkapex
nitroxis has joined #ffmpeg-devel
jarthur_ has joined #ffmpeg-devel
jarthur has quit [Ping timeout: 260 seconds]
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 252 seconds]
jamrial has quit []
cone-976 has joined #ffmpeg-devel
<cone-976>
ffmpeg jiangjie master:f606872ed0e2: avformat/dashdec: The segments in dash file doesn't read completely when segment's size and duration is very small.
arch1t3cht4 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 260 seconds]
arch1t3cht4 is now known as arch1t3cht
Traneptora has quit [Quit: Quit]
<Lynne>
elenril: was AVFilterLink.frame_rate meant to be something the users weren't meant to ever use?
<Lynne>
I was using it and a23d565ea7d41e61f160578f9714a23e695f3bfd broke my code
<Lynne>
as an API-user
<Lynne>
this looks like an ABI/API break to me
<aaabbb>
7
av500 has quit [Ping timeout: 260 seconds]
av500 has joined #ffmpeg-devel
<ePirat>
Lynne, someone complained about this on the ML too I think
<nevcairiel>
it was technically below the comment line that indicates not public API
<nevcairiel>
although that kind of design is of course very easy to miss
<nevcairiel>
which is why we stopped using it on other contexts
<wbs>
Sean_McG: dunno, it may have been IA64, or possibly both, but it has moved to x86 now, which afaik required adding the big endian mode to x86
<Sean_McG>
I didn't even know x86 was capable of bi-endian... I know PowerPC did ever since the 601
<wbs>
not sure if it is in all x86s or if it is something custom for those HP envs
Krowl has quit [Read error: Connection reset by peer]
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
elvis_a_presley has joined #ffmpeg-devel
<jamrial>
elenril: https://pastebin.com/raw/dnQBYxHH two stereo 3d side data entries despite av_frame_remove_side_data() called in hevc/refs.c alloc_frame()
<jamrial>
guess ff_decode_frame_decode_props() is called later?
Traneptora has joined #ffmpeg-devel
feiw2 has quit [Ping timeout: 264 seconds]
feiw2 has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
jamrial_ has joined #ffmpeg-devel
jamrial has quit [Read error: Connection reset by peer]
<haasn>
grr
<haasn>
the fact that I didn't already add avfilter negotiation for chroma sample location is coming back to haunt me
<haasn>
because it means simply making swscale respect the tagged chroma location regresses some tests as a result of incorrect conversions to codecs that require certain chroma locs
<haasn>
e.g. when converting to `dv` (topleft only) we would need to resample the incoming pixel data to topleft
<haasn>
I guess I don't need to add full negotiation for it, just codec configuration
mkver has joined #ffmpeg-devel
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
Krowl has quit [Read error: Connection reset by peer]
Sean_McG has quit [Quit: leaving]
HarshK23 has quit [Quit: Connection closed for inactivity]