BtbN changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.0 is released
Sakura`Kinomoto has quit [Ping timeout: 255 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
memset_ has joined #ffmpeg
memset has quit [Ping timeout: 260 seconds]
Suchiman has quit [Quit: Connection closed for inactivity]
billchenchina- has joined #ffmpeg
memset_ has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg
psykose_ has joined #ffmpeg
psykose has quit [Ping timeout: 248 seconds]
psykose_ is now known as psykose
Tinos has quit [Remote host closed the connection]
rv1sr has joined #ffmpeg
Tinos has joined #ffmpeg
jagannatharjun has joined #ffmpeg
Sketch has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
Sketch has joined #ffmpeg
mven971 has joined #ffmpeg
AbleBacon has quit [Read error: Connection reset by peer]
mven97 has quit [Ping timeout: 276 seconds]
mven971 is now known as mven97
lavaball has joined #ffmpeg
KombuchaKip has quit [Ping timeout: 252 seconds]
Juest has quit [Read error: Connection reset by peer]
Juest has joined #ffmpeg
luc4 has joined #ffmpeg
NotWarcop has joined #ffmpeg
Warcop has quit [Ping timeout: 276 seconds]
Unit640 has joined #ffmpeg
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg
<Unit640>
Can FFMPEG re-encode video files without losing ANY quality and getting smaller file size? (I'm trying to save space and the various videos take up a huge amount.)
<psykose>
no
<Unit640>
:(
Livio has joined #ffmpeg
hightower2 has quit [Read error: Connection reset by peer]
hightower2 has joined #ffmpeg
xx has joined #ffmpeg
rv1sr has quit []
rv1sr has joined #ffmpeg
echelon has quit [Ping timeout: 260 seconds]
Yukkuri has joined #ffmpeg
<Yukkuri>
hi, can ffmpeg chunking of mp4 be controlled, by setting minimum number of samples, or minimum duration of individual chunks?
<JEEB>
yes, you can even have fully manual control with the API
<JEEB>
there are also multiple options if you want to attempt to have the writer control it but with some rules
<JEEB>
see `-h muxer=mp4`
<Yukkuri>
does the ffmpeg cli supports options for controling it?
<JEEB>
yes, the options that the writer exposes, which can be listed with the help option I posted
<JEEB>
you will not have full control, but there are various fragment related options
<JEEB>
(I expect you mean fragmented mp4 when you say "chunking")
<Yukkuri>
no, i mean unfragmented mp4 chunking, denoted by the stsc atom
beaver has quit [Quit: Undefined subroutine &Irssi::Script::test::debug_print called at line 358]
beaver has joined #ffmpeg
<Yukkuri>
I want to increase sample count per a chunk from single audio sample + 1/2 video samples to full keyframe interval worth of samples
hightower3 has joined #ffmpeg
echelon has joined #ffmpeg
hightower2 has quit [Ping timeout: 252 seconds]
<JEEB>
that might be related to overall avformat interleaving logic
<JEEB>
see `ffmpeg -h full |grep interleav` for various options that mention interleaving
<Yukkuri>
thanks
xx has quit [Remote host closed the connection]
<JEEB>
possibly the delta one? this goes deep enough that you might need to check what variables control the input/output buffering before it ends up in the writer (=muxer)
xx has joined #ffmpeg
<JEEB>
as well as probably checking the muxer itself (libavformat/movenc.c) whether it is hard-coded to whatever, or if it depends on some circuimstances
<JEEB>
AVPackets after all go into generic avformat logic first, where it will attempt to interleave packets so that they get pushed into output at similar times, and finally then avformat generic logic feeds a specific muxer with the packet when it seems to be appropriate
ghodawalaaman has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
lavaball has joined #ffmpeg
omegatron has joined #ffmpeg
Icedream has quit [Ping timeout: 264 seconds]
Tinos has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
Icedream has joined #ffmpeg
dionisis has quit [Ping timeout: 244 seconds]
Teraii has quit [Read error: Connection reset by peer]
Livio has quit [Ping timeout: 248 seconds]
Teraii has joined #ffmpeg
Icedream has quit [Ping timeout: 260 seconds]
Icedream has joined #ffmpeg
HerbY_NL has joined #ffmpeg
memset_ has quit [Ping timeout: 260 seconds]
Tinos has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
memset has joined #ffmpeg
Blacker47 has joined #ffmpeg
HerbY_NL has joined #ffmpeg
HerbY_NL has quit [Client Quit]
APic has joined #ffmpeg
Sakura`Kinomoto has quit [Ping timeout: 276 seconds]
acidbong has joined #ffmpeg
<acidbong>
hi there, hello
<acidbong>
I'm adjusting volume in some mp3 files with ffmpeg (v6.1.1), but it cuts out the date from the output file. how can i preserve it?
<acidbong>
the full command is `ffmpeg -i in.mp3 -filter:a loudnorm`
<acidbong>
and out.mp3, forgot to add
MetaNova has quit [Remote host closed the connection]
MetaNova has joined #ffmpeg
hightower3 has quit [Ping timeout: 264 seconds]
lavaball has quit [Remote host closed the connection]
lavaball has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
lavaball has quit [Remote host closed the connection]
luc4 has quit [Quit: Konversation terminated!]
iliv has quit [Ping timeout: 276 seconds]
luc4 has joined #ffmpeg
Tinos has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
<Unit640>
Any fancy new video format which makes videos 10x smaller with no loss of quality?
<Unit640>
Or is .mp4/H.264/whatever basically the optimal thing that can be done with today's hardware?
<JEEB>
lossy recompression will always be lossy compared to the thing you fed into it
<JEEB>
lossless coding exists, but generally lossy ends up smaller - so if your input is lossy and you encode it lossless you're just wasting bits :P
<Unit640>
JEEB: I don't understand any of that. :/
<Unit640>
JEEB: I mean that if I currently have a crappy .mp4, but I feel that it takes up too much space, is there any way with today's technology to make it much smaller yet not lose another "layer" of quality?
<Unit640>
That is, each frame of the new video must be played back looking identical as the current .mp4.
<Unit640>
Some fancy new format/encoder?
<JEEB>
technically lossy to lossy will never be lossless since the coding you will be applying on the decoded result is going to be lossy. (since I expect you are dealing with lossy input)
<JEEB>
but whether you can notice that loss visually is a separate thing
<Unit640>
Why do you speak of "lossy to lossy"? Forget "lossy". I have a .mp4 video file. I want it to be smaller but not lose any quality. Is there such a video format today? Even if proprietary.
<Unit640>
Compressed isn't the same as lossy-
<JEEB>
yea there's no magic like that, the lossy compression in your mp4 file is most likely higher than just throwing it through an archiver or so
<Unit640>
Magic?
<Unit640>
It would just have a more efficient way of compressing data losslessly.
<JEEB>
but your data is already heavily compressed
<Unit640>
Forget that it started lossy. I'm not talking about magically restoring it to some pre-.mp4 quality.
<JEEB>
it's not going to be as easy to compress as some random text data for a 7z archiver or so
<JEEB>
and I'm not either talking about pre-mp4 quality
<Unit640>
Are you misunderstanding on purpose?
<JEEB>
nope
<JEEB>
if you want to run that mp4 through zstd or 7z or something, please try. you can see how much you gain by trying to compress the whole file
<Unit640>
If I did that, even if it saved significant amount of data, I'd still have to extract it manually before playing it each time.
<JEEB>
or pipe, yes
phonemic has joined #ffmpeg
<Unit640>
But I don't think that an archive program would be able to "understand" that it's a video file.
<Unit640>
It would have to be some new video format.
<Unit640>
(For it to save any real amount of data)
<JEEB>
and I expect that since your data is already heavily compressed and does not have too many similarities, this compression will not work too well
<JEEB>
actually it is much easier to compress a whole document than something frame-by-frame
<JEEB>
since as long as your search radius is across the whole document, you can just consider it as if a single frame
acidbong has left #ffmpeg [#ffmpeg]
<Unit640>
In theory, would much faster computers be able to use some new kind of technology which is currently too slow to calculate in real time, similar to how a 486 PC in the mid-1990s would not be able to decode .mp4/H.264 videos?
<kepstin>
any new video format that's capable of making the video smaller would do so by doing a lossy transcode, resulting in lower quality than your previous file (although that quality loss might not be noticeable by eye).
<Unit640>
kepstin: Why is that a given?
<Unit640>
Remember how big video files were in the 1990s even though they were super low-res and crappy?
<kepstin>
because that's just how video codecs work
<kepstin>
(same is true of audio too)
<Unit640>
kepstin: That's like saying that you cannot possibly save a PNG image losslessly more than once.
<Unit640>
But of course you can.
<Unit640>
You can even convert a PNG losslessly to a different image format.
<JEEB>
you can, just try encoding your mp4 file as lossless H.264, then lossles HEVC, then lossless AV1
<JEEB>
everything is possible
<kepstin>
sure.. the problem is you're starting with a jpeg, not a png
<JEEB>
but since your MP4 file is not lossless, you are going to gain size, not lose it
<Unit640>
Again, I'm not talking about magically restoring quality that was not there from the start.
<JEEB>
we are not either
<Unit640>
If we start at JPEG quality, that is the "original" to us.
<JEEB>
yes, but that is alreay heavily compressed. so you are not comparing against the size of the raw decoded frame
<Unit640>
So to us, that picture's end result on the screen is "lossless" to *us*.
<JEEB>
or a large losslessly compressed image
<Unit640>
:/
<JEEB>
your input is already expected to be relatively heavily compressed
phonemic has quit [Read error: Connection reset by peer]
<Unit640>
The idea is that this new format would be revolutionary in the same way that PNG was compared to BMP.
<kepstin>
in order to encode with a different codec, you first have to decode the existing lossy encode, and then encode it again with a new lossy encoder. that process will lose data.
<JEEB>
we have lossless formats
<JEEB>
it's just that they are dealing with different requirements and their resulting sizes are different
<kepstin>
if your existing file was lossless, then you could compress smaller with a newer lossless encoder without losing anything, sure
<kepstin>
but it's not, so you can't.
<Unit640>
Hmmm...
HerbY_NL has joined #ffmpeg
<JEEB>
a lossless coding requires it to store everything. lossy coding has taken the liberty of kicking something out. thus if you take random decoded image X, most likely the lossy coded format will compress much better than the lossless one. thus if you then decode that lossy format and re-encode it with the latest gen lossy coding, you will most likely end up with a larger file size than your input
phonemic has joined #ffmpeg
<JEEB>
uhh, *re-encode it with the latest gen lossless coding
<JEEB>
sorry about that
<JEEB>
although it can often be the same lossy to lossy since now the lossy encoder is also attempting to compress the possible artifacts etc in the lossy input you are trying to feed it.
<JEEB>
(which were not there in the original, and thus the original lossy encoder had it "easier")
<Unit640>
The original .mp4 video clip looks in a certain way. It has been compressed/exported from some original video file, which we can forget about because we know nothing about it. All we have is the lossy .mp4. To us, that is the original. The way it looks on the screen (regardless of the method of compression, if any) is the "original" to us. I wish to put it through some process which first decodes it (like any media player would), thus gets the same data
<Unit640>
as our eyes see on the screen, then goes through the process of producing a new video file (not .mp4 but .whatevercoolnewformat), and this new file is lossless and thus identical visually to the .mp4, yet smaller in size. I can't explain what I mean in any other way.
<kepstin>
Unit640: that is not possible.
<kepstin>
best you can do is "visually almost the same"
<Unit640>
Not possible? Even if the new format is much smarter and makes use of the latest hardware to use all sorts of fancy and expensive compression tricks?
<Unit640>
Maybe there really is a lower limit for how much you can compress something losslessly.
<JEEB>
I wouldn't say impossible unless someone actually calculates the theoretical signal limit or whatever the word was, but losslessly recompressing in generic way is going to be really unlikely unless you do something like applying an archiver on the whole document
<JEEB>
in non-generic ways this can be done by f.ex. rewriting a CAVLC stream to a CABAC stream in H.264 for example
<JEEB>
since that is the lossless compression part of H.264 within the whole chain
<JEEB>
you have the <stuff> and you compress it with CAVLC or CABAC. if the encoder for whatever reason utilized CAVLC, you can gain something by rewriting the whole thing in CABAC
<JEEB>
but if your video is already CABAC, then yea. the data has already been heavily compressed
<JEEB>
(CABAC is what's then been utilized I think all the way to VVC so that's seemingly a pretty good compression scheme)
<Unit640>
I imagine something like, if the video has a lot of mostly black frames, it can just store a huge part of those as a single instance of "black circle of 150 pixels frames X-Y at position X,Y". I'm unsure if things like that are already done with current video compression, but I can vaguely imagine that faster CPU and more RAM could enable such "tricks".
<JEEB>
and in theory you could come up with a format which is "This other format, but we found a better way to compress the data", and have a custom thing that rewrites that bit like CAVLC<->CABAC conversion could be done.
<kepstin>
jpeg-xl has a neat trick where it can losslessly recompress a jpeg smaller by using a better entropy encoder... but that's only really possible because jpeg is a _really_ old format, and this was an explicit design goal of the codec.
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
<JEEB>
Unit640: they already utilize intra and inter prediction and then when they create the "do this, this and this" they essentially do the heavy lossless compression on that (like 7z or so)
<kepstin>
Unit640: your existing mp4 file is probably using h264, which _already_ is making heavy use of redundant video data like that.
<Unit640>
:[
<JEEB>
so each frame is something like [header][heavily compressed data]
hightower2 has joined #ffmpeg
<JEEB>
then that heavily compressed data is decompressed and the "do this, this and this" properly interpreted
<kepstin>
but if your existing file is lossy, that means the existing codec added some artifacts to the data, so later codecs seeing the decoded data don't see a "pure black circle" or whatever, but rather "a mostly black circle with some ringing or blocking here and there"
<JEEB>
but yea, to see how well the encoder did with this, just attempt to 7z or zstd the whole file and see if you gain anything. that will show you how losslessly compressable that data is (just configure a large enough window with more memory usage to make sure you can utilize the full file at once)
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kepstin>
there's some cases where the tradeoffs of doing a lossy transcode to reduce file size might be acceptable - for example if the original mp4 was generated by a phone camera or something, which have notoriously poor compression, you can sometimes do a lossy transcode even with the same codec and a better encoder that looks almost the same but is a lot smaller.
<kepstin>
but if you do that once, you wouldn't ever want to recompress the output of that again later.
KDDLB has joined #ffmpeg
iliv has joined #ffmpeg
rsx has joined #ffmpeg
Daniel26 has quit [Ping timeout: 260 seconds]
Daniel26 has joined #ffmpeg
rsx has quit [Quit: rsx]
lucasta has joined #ffmpeg
coldfeet has joined #ffmpeg
luc4 has quit [Ping timeout: 276 seconds]
<Marth64>
Sean_McG: as a fellow retro computing fan, willing to help if I can based on the parameters. feel free to ping me
<Marth64>
wrong chan sorry
coldfeet has quit [Remote host closed the connection]
coldfeet has joined #ffmpeg
Livio has joined #ffmpeg
quidnunc has quit [Ping timeout: 252 seconds]
Livio has quit [Ping timeout: 248 seconds]
quidnunc has joined #ffmpeg
beaver has quit [Remote host closed the connection]
coldfeet has quit [Quit: leaving]
Sakura`Kinomoto has joined #ffmpeg
coldfeet has joined #ffmpeg
Sakura`Kinomoto has quit [Remote host closed the connection]
lavaball has joined #ffmpeg
Sakura`Kinomoto has joined #ffmpeg
Traneptora has quit [Quit: Quit]
memset has quit [Ping timeout: 260 seconds]
AbleBacon has joined #ffmpeg
lucasta has quit [Quit: Leaving]
billchenchina- has joined #ffmpeg
dionisis has joined #ffmpeg
JanC has quit [Ping timeout: 260 seconds]
JanC has joined #ffmpeg
memset has joined #ffmpeg
minimal has joined #ffmpeg
intrac has quit [Quit: Konversation terminated!]
intrac has joined #ffmpeg
HerbY_NL has joined #ffmpeg
vincejv has quit [Ping timeout: 260 seconds]
vincejv has joined #ffmpeg
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Livio has joined #ffmpeg
coldfeet has quit [Remote host closed the connection]
rhollan has joined #ffmpeg
<rhollan>
can someone help me with hardware scaling with vaapi
<rhollan>
I can decode rtsp h.265 streams and reencode as h.264 all wuth hardware accelleration bug can't figure out how to scale the video, preferably using hardware.
<Curid>
put `-vf scale=1280x720` just before `-c:a`
<rhollan>
That does not work because I am using hardware decoders and encoders. I think I need to -vf clauses with hodownload and hwupload and use a software scaler.
<rhollan>
That also does not work. Apparently, with hardware decoding and encoding the video stays in GPU memory. And VAAPI does not support scaling there. So, one has to decode, transfer to CPU memory, use the software scaler scale_vpapi, and reupload for encoding. hwdownload and hwupload. But, getting the syntax right is proving to be a bear.
<furq>
scale_vaapi isn't in software
<rhollan>
That's what I thought. But it just doesn't work if I pass it as a -vf option
<rhollan>
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.3.1 ()
<rhollan>
vainfo: Supported profile and entrypoints
<rhollan>
sorry
diniboy has joined #ffmpeg
<rhollan>
now, if I prefix the scale_vaapi with hwdownload, I get a different message:
<rhollan>
Impossible to convert between the formats supported by the filter 'graph 0 input from stream 0:0' and the filter 'auto_scaler_0'
<rhollan>
That suggest to me two things:
<kepstin>
that makes sense, hwdownload is the opposite of what you want (that transfers from gpu ram to cpu ram)
<rhollan>
First, scale_vaapi IS a software scaler, for video aranged for vaapi
<rhollan>
Second, there is still a format mismatch
<kepstin>
the "Impossible to convert" message usually means that you have a software frame when the filter wants a hardware frame or vice-versa; if you have a software frame and the filter expected a software frame, it would have auto-inserted a scale filter.
<kepstin>
(the purpose of it is to allow scaling on a full-gpu pipeline, so you don't have to download to the cpu and re-upload)
<rhollan>
And, that is exactly what I want.
KDDLB has joined #ffmpeg
Livio has quit [Ping timeout: 260 seconds]
<kepstin>
huh, why are you using the 'iHD' vaapi driver; what cpu/igpu do you have?
<rhollan>
Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
Livio has joined #ffmpeg
<kepstin>
hmm, ok, that is the right one then.
<rhollan>
Intel® Iris® Plus Graphics 650
<kepstin>
lets see... that's kaby lake. that requires the "full feature" iHD driver (with non-free kernels enabled) in order to have scaling support via vaapi.
<another|>
what's the full output of `vainfo`? in a paste please
<kepstin>
i suspect the VAEntrypointVideoProc might be missing on that chip if the iHD driver is built with only the free kernels.
<kepstin>
This error is what's making me suspicious: "Failed to create processing pipeline config: 12 (the requested VAProfile is not supported)."
<kepstin>
if you're on ubuntu/debian, you can install the full version of the driver by installing the package "intel-media-va-driver-non-free"
<rhollan>
How can I tell if it installed properly?
<kepstin>
vainfo should print a line that says "VAProfileNone :VAEntrypointVideoProc"
<rhollan>
VAEntrypointVideoProc
<rhollan>
is now reported by vainfo
<kepstin>
ok, now scale_vaapi should work :)
<rhollan>
Woot! It does. I forgot to remove a hwdownload.
<rhollan>
Sweet mother of all hackers: under 10% CPU transcoding 4k H.265 to 1080p h.264
<rhollan>
Thanks a bunch!
<rhollan>
Now to get Shinobi to craft the right ffmpeg command line.
<rhollan>
Again, thanks much,
iliv has quit [Quit: "<paniq> you know when i walk out the door, there is plenty of stupid people. i open irc, there is plenty of intelligent people. so the choice comes easy."]
realies has quit [Quit: ~]
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
waleee has joined #ffmpeg
HerbY_NL has joined #ffmpeg
foul_owl has quit [Ping timeout: 272 seconds]
HerbY_NL has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
foul_owl has joined #ffmpeg
billchenchina- has quit [Ping timeout: 265 seconds]
jagannatharjun has quit [Quit: Connection closed for inactivity]
xx has quit [Ping timeout: 260 seconds]
xx has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
xx has quit [Remote host closed the connection]
xx has joined #ffmpeg
MrZeus has joined #ffmpeg
jtgd has quit [Quit: WeeChat 4.3.5]
jtgd has joined #ffmpeg
diniboy has quit [Ping timeout: 256 seconds]
memset has quit [Remote host closed the connection]
memset has joined #ffmpeg
archivist99 has quit [Ping timeout: 244 seconds]
memset has quit [Remote host closed the connection]
memset has joined #ffmpeg
foul_owl has quit [Ping timeout: 260 seconds]
archivist99 has joined #ffmpeg
martylake has quit [Ping timeout: 272 seconds]
martylake has joined #ffmpeg
foul_owl has joined #ffmpeg
rv1sr has quit []
Unit640 has quit [Quit: Leaving]
vampirefrog has quit [Quit: Leaving]
SuicideShow has quit [Ping timeout: 265 seconds]
SuicideShow has joined #ffmpeg
Livio has quit [Ping timeout: 260 seconds]
Tinos has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
Vonter has quit [Ping timeout: 272 seconds]
Vonter has joined #ffmpeg
Traneptora has quit [Quit: Quit]
xx has quit [Ping timeout: 260 seconds]
lexano has quit [Ping timeout: 272 seconds]
Juesto has joined #ffmpeg
Juest has quit [Ping timeout: 252 seconds]
Juesto is now known as Juest
waleee has quit [Ping timeout: 244 seconds]
<rhollan>
Hacked Shinobi to "do the right thing" and craft the right ffmpeg transcoder.