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: 268 seconds]
System_Error has quit [Remote host closed the connection]
Sakura`Kinomoto has joined #ffmpeg
System_Error has joined #ffmpeg
iive has quit [Quit: They came for me...]
lexano has quit [Ping timeout: 252 seconds]
markizano has quit [Remote host closed the connection]
<iconoclast_hero>
This is proceeding at a glacial (for a stream copy) 3.25x. Why is this not moving significantly faster if it's just copying the flac? ( Stream #0:1: Audio: flac, 48000 Hz, stereo, s16 (default))
<furq>
presumably there is a non-audio stream that is being reencoded
<furq>
either use -c copy or -map 0:a
nillyhan has quit [Ping timeout: 272 seconds]
<iconoclast_hero>
i see.
<iconoclast_hero>
so what is this telling me? Stream mapping:
<iconoclast_hero>
ffmpeg is converting the entire video file to a png?
<iconoclast_hero>
because when I saw that ffmpeg was ignoring video stream #0 i thought that it was being discarded: [flac @ 0x642879730400] Video stream #0 is not an attached picture. Ignoring
<furq>
apparently it just encodes it anyway and then discards it
Tinos has joined #ffmpeg
<iconoclast_hero>
so i'm getting there, just the very long way 'round?
<JEEB>
yea there's a v2 at least visible in the listing
<Forza>
I see. But why wouldn't 2pass work with -svtav1-params if ffmpeg isn't sending the correct signals with the -pass option?
<JEEB>
depends on whether that is enough for the encoder
<Forza>
I suppose so. It segfaults on pass 2.
<Forza>
Is aom much different in quality or speed?
<JEEB>
also I wonder why the interest towards 2pass, since more or less the same results can be achieved by using CRF and just adjusting it (or just using the highest value that still looks good to you)
<JEEB>
there's a reason why libaom is considered the theoretical reference while SVT-AV1 was appointed the AOM production reference thing :P
<Forza>
Yes but I read they are switching to svt-av1 as reference st some point?
<JEEB>
I would be surprised
<JEEB>
or well, both *are* references
<JEEB>
as I said, one is the research and theory one
<JEEB>
the other is the "production" reference
<Forza>
I wanted to use a specific target size. Cbr has always been a little harder to get right i think
<JEEB>
oh man, so what does "CBR" mean to you
<JEEB>
just out of interest
<Forza>
Sorry I meant crf
<JEEB>
for local files you just first pick your slowness level with the other parameters, and then you just encode like 90 seconds of your possibly longer clip with different CRF values. starting at the default or even somewhat higher, and then just going higher if it looks bad, and going lower if it looks good. this leads to you finding the highest CRF that creates good enough quality for that set of { encoding
System_Error has quit [Remote host closed the connection]
<JEEB>
parameters, resolution, frame rate, dark/bright/general content type }
<JEEB>
because usually you don't care about attaining an exact file size
<JEEB>
you want to compress as much as possible that still looks good
<JEEB>
(for you)
<JEEB>
and basically CRF and average bit rate are usually the same thing but controlled from the "other side"
<JEEB>
so for a specific average bit rate it is some CRF
<JEEB>
while defining a CRF you are telling the encoder to not care about the average bit rate, but just use a specific value
<JEEB>
(this is from the grandaddy of CRF, x264. I would expect this to match with other encoders that actually took CRF into use)
<JEEB>
and then for streaming use cases you have maxrate+bufsize which attempts to make sure that over a bufsize rolling buffer, the average does not go over maxrate
System_Error has joined #ffmpeg
<Forza>
Hm I suppose. I always thought that in theory multiple passes can distribute the bitrate over a longer period than a single encode could, at least not without having to specify much longer look-ahead etc.
<JEEB>
when you are limiting to a specific bit rate the encoder has to do certain guessing with 1pass
<JEEB>
CRF is not really under such pressure
<Forza>
The sampling part that you suggest seems difficult if there are many different types of scenes in the video
<JEEB>
usually it's enough to feed it a cut that has two or more included, whatever are the primary things.
Tinos has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
theobjectivedad has quit [Ping timeout: 240 seconds]
<Forza>
Hm vlc on my android doesnt like av1. Just a black image
Livio has quit [Ping timeout: 256 seconds]
theobjectivedad has joined #ffmpeg
theobjectivedad has quit [Remote host closed the connection]
ttys000 has joined #ffmpeg
yeahitsme has quit [Ping timeout: 256 seconds]
theobjectivedad has joined #ffmpeg
Sakura`Kinomoto has quit [Remote host closed the connection]
iconoclast_hero has quit [Ping timeout: 272 seconds]
Disavowed has joined #ffmpeg
hightower3 has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
emmanuelux has joined #ffmpeg
hightower4 has quit [Ping timeout: 264 seconds]
dionisis has joined #ffmpeg
tM^caoX has joined #ffmpeg
<tM^caoX>
If I want to encode pic.jpg as video (with fps) I run 'ffmpeg -loop 1 -i pic.jpg -t <time> video.mp4', but is there such simple oneliner also if I want to encode pic1.jpg for say the first 5 seconds and then pic2.jpg for the 10 seconds, and perhaps pic3.jpg for a whole minute? I understand that I could do them one at a time and then use the -f concat thingie to concatenate the output .mp4s together, but
<tM^caoX>
is there a way to do it quick and easy in one command, I know ffmpeg has grown with many new options over the years so I try my luck! :)
SuicideShow has quit [Ping timeout: 260 seconds]
SuicideShow has joined #ffmpeg
mrelcee has quit [Ping timeout: 268 seconds]
<ePirat>
is it common to get "color_range:tv color_space:unknown color_primaries:unknown color_trc:unknown" for non-HDR h265 in mp4?