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
iive has quit [Quit: They came for me...]
<johnjaye> hmm. i'm not a font expert. but why is font size different in the subtitles video filter than in the drawtext filter?
<johnjaye> i specified same font same size but it's bigger in the libass renderer
<johnjaye> i would have thought the number is related to pixels or something so it should be the same?
System_Error has quit [Remote host closed the connection]
xx has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg
lemourin7 has joined #ffmpeg
lemourin has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
lemourin7 is now known as lemourin
five61848033917 has quit [Remote host closed the connection]
five61848033917 has joined #ffmpeg
realies has joined #ffmpeg
lemourin is now known as Guest8647
lemourin has joined #ffmpeg
Guest8647 has quit [Killed (erbium.libera.chat (Nickname regained by services))]
nigetilly has joined #ffmpeg
realies has quit [Ping timeout: 244 seconds]
realies has joined #ffmpeg
rex has quit [Ping timeout: 244 seconds]
<mrelcee> i was in here crabbing about freebsd-update to 14.2-betas, RCs and RELEASE all left me with a system stuck at single user..
<mrelcee> well pkgbase worked great
rex has joined #ffmpeg
<mrelcee> oh whoop missed the channel by 1.
lemourin8 has joined #ffmpeg
lemourin has quit [Killed (lead.libera.chat (Nickname regained by services))]
lemourin8 is now known as lemourin
Traneptora has quit [Quit: Quit]
Marth64 has quit [Quit: Leaving]
minimal has quit [Quit: Leaving]
realies has quit [Quit: ~]
realies has joined #ffmpeg
Buliarous has quit [Remote host closed the connection]
Buliarous has joined #ffmpeg
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
Everything has quit [Quit: leaving]
linext has joined #ffmpeg
cmc_ has quit [Ping timeout: 260 seconds]
cmc_ has joined #ffmpeg
linext has quit [Quit: Client closed]
vincejv has quit [Ping timeout: 260 seconds]
phantomics has quit [Ping timeout: 276 seconds]
vincejv has joined #ffmpeg
BUSY has quit [Read error: Connection reset by peer]
<MisterMinister> https://trac.ffmpeg.org/ticket/11331 in case anyone's interested in a bounty for libx265 alpha channel patch
<realies> was wondering what parts of ffmpeg scale with avx512 supporting cpu
makidoll3 has joined #ffmpeg
makidoll has quit [Ping timeout: 260 seconds]
makidoll3 is now known as makidoll
wziko has joined #ffmpeg
wziko has quit [Ping timeout: 244 seconds]
StephenLynx has quit [Quit: Leaving]
luva has quit [Quit: Byebye]
luva has joined #ffmpeg
koolazer has joined #ffmpeg
ossifrage has quit [Read error: Connection reset by peer]
ossifrage_ has joined #ffmpeg
Dagger has quit [Ping timeout: 245 seconds]
Dagger has joined #ffmpeg
nigetilly has quit [Ping timeout: 252 seconds]
MrZeus__ has joined #ffmpeg
System_Error has quit [Ping timeout: 260 seconds]
billchenchina has joined #ffmpeg
MrZeus__ has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg
phantomics has joined #ffmpeg
Kei_N has joined #ffmpeg
Suchiman has quit [Quit: Connection closed for inactivity]
rv1sr has joined #ffmpeg
\\Mr_C\\ has quit [Remote host closed the connection]
wyatt8740 has quit [Ping timeout: 252 seconds]
wyatt8750 has joined #ffmpeg
Dagger has quit [Ping timeout: 252 seconds]
Dagger has joined #ffmpeg
cmc_ has quit [Remote host closed the connection]
cmc_ has joined #ffmpeg
Cheetahze has joined #ffmpeg
wziko has joined #ffmpeg
Krusher has joined #ffmpeg
wziko has quit [Ping timeout: 252 seconds]
SuRGeoNix has joined #ffmpeg
<SuRGeoNix> Hi, any reason that dhav demuxer has AVFMT_TS_NONSTRICT flag? this is suppose to be only for muxers?
trillion_exabyte has quit [Ping timeout: 252 seconds]
billchenchina- has joined #ffmpeg
billchenchina has quit [Ping timeout: 245 seconds]
MRiddickW has joined #ffmpeg
RobMeades has joined #ffmpeg
RobMeades has quit [Quit: Client closed]
RobMeades has joined #ffmpeg
billchenchina- has quit [Ping timeout: 255 seconds]
phantomics_ has joined #ffmpeg
phantomics has quit [Ping timeout: 245 seconds]
wziko has joined #ffmpeg
wziko has quit [Max SendQ exceeded]
SuRGeoNix has quit [Quit: Client closed]
xx has joined #ffmpeg
Suchiman has joined #ffmpeg
five618480339175 has joined #ffmpeg
five61848033917 has quit [Ping timeout: 260 seconds]
five618480339175 is now known as five61848033917
tokyovigilante has quit [Ping timeout: 272 seconds]
tokyovigilante has joined #ffmpeg
RobMeades has quit [Quit: Client closed]
sihloo has quit [Read error: Connection reset by peer]
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg
sihloo has joined #ffmpeg
Blacker47 has joined #ffmpeg
MRiddickW has quit [Ping timeout: 252 seconds]
Cheetahze has quit [Quit: Connection closed for inactivity]
xx has quit [*.net *.split]
cmc_ has quit [*.net *.split]
System_Error has quit [*.net *.split]
makidoll has quit [*.net *.split]
fling has quit [*.net *.split]
chiselfuse has quit [*.net *.split]
crossby1004 has joined #ffmpeg
j45 has quit [Ping timeout: 248 seconds]
j45 has joined #ffmpeg
lavaball has joined #ffmpeg
kasper93 has quit [Ping timeout: 272 seconds]
kasper93 has joined #ffmpeg
KillerWasp has left #ffmpeg [YOU KIDDING ME?? YOU KIDDING MEEE???? (PC drinking beer) *kernel panic!*]
wziko has joined #ffmpeg
wziko has quit [Max SendQ exceeded]
wziko has joined #ffmpeg
Dagger has quit [Ping timeout: 248 seconds]
Dagger has joined #ffmpeg
<frankplow> realies: If you grep for avx512 in the codebase, you can see which areas have hand-written AVX512 assembly. There's not very much: a couple of filters, v210 packing and some HEVC stuff.
wziko has quit [Ping timeout: 246 seconds]
Dagger has quit [Ping timeout: 260 seconds]
Dagger has joined #ffmpeg
rsx has joined #ffmpeg
<JEEB> and then of course libraries that can be utilized through FFmpeg, like x264 or SVT-AV1 etc have their own set of optimizations
<JEEB> or zimg
peac has quit [Quit: Ping timeout (120 seconds)]
peac has joined #ffmpeg
wziko has joined #ffmpeg
wziko has quit [Ping timeout: 244 seconds]
StephenLynx has joined #ffmpeg
five618480339179 has joined #ffmpeg
five61848033917 has quit [Ping timeout: 252 seconds]
five618480339179 is now known as five61848033917
evilscreww has joined #ffmpeg
fling has joined #ffmpeg
xx has joined #ffmpeg
Traneptora has joined #ffmpeg
chiselfuse has joined #ffmpeg
cmc_ has joined #ffmpeg
minimal has joined #ffmpeg
Muimi has joined #ffmpeg
pa has quit [Excess Flood]
pah has joined #ffmpeg
yans has quit [Ping timeout: 252 seconds]
<realies> thank you!
pah is now known as pa
DEATH has quit [Ping timeout: 265 seconds]
DEATH has joined #ffmpeg
DEATH has quit [Ping timeout: 246 seconds]
DEATH has joined #ffmpeg
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
crossby1004 has quit [Quit: leaving]
alexherbo2 has joined #ffmpeg
System_Error has joined #ffmpeg
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg
turlando has quit [Remote host closed the connection]
turlando has joined #ffmpeg
<JanC> in theory a compiler could decide to use AVX512 on its own too, of course...
<JEEB> yea, but generally that requires specific parameters
thomas_D88 has quit [Ping timeout: 265 seconds]
Marth64 has joined #ffmpeg
evilscreww has quit [Quit: Leaving]
DEATH has quit [Ping timeout: 265 seconds]
DEATH has joined #ffmpeg
DEATH has quit [Ping timeout: 255 seconds]
DEATH has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
<johnjaye> is vp9 decoding slow for some reason?
<johnjaye> no particular reason to ask, it just feels like it
<JEEB> it's one of the more optimized decoders within avcodec
<johnjaye> i had to transcode a clip to x264 to work with it faster
<JEEB> just make sure you're not utilizing the libvpx decoder wrapper for whatever reason, that one is slower
<JEEB> (you would have to specify it manually)
<JEEB> of course H.264 due to its age and thus lower complexity will be faster, but VP9 definitely is not a slouch
<another|> JEEB: the only reason to use libvpx for decoding is alpha
<JEEB> `ffmpeg -v verbose -i INPUT -map 0:v -f null pipe:`
<JEEB> another|: not sure why you felt noting that to me :D I was just doing the usual motions of trying to cover my bases. that just in case someone was setting the decoder explicitly that they would stop doing it
<JEEB> johnjaye: anyways that ffmpeg command I posted would let you get a number of pure decoding
<JEEB> read from input, decode, then just throw result to null
<johnjaye> meaning something else might be causing the slowdown than decoding?
<another|> I don't know either. need more coffee I guess
<JEEB> johnjaye: just noting that you should be able to that way get numbers without addition things in the process
stolen has joined #ffmpeg
Krusher has quit [Ping timeout: 245 seconds]
<johnjaye> oh i see the null filter avoids any reencoding
<JEEB> format (muxer as defined on the output side)
<another|> it's not a filter
<JEEB> technically it would be re-encoding but the default format for it just happens to be the wrapped avframe format which means that the raw decoded frames can be passed to it directly
<johnjaye> ah i see
<johnjaye> there is both a null filter and a null format
<JEEB> (the default video/audio/subtitle formats for a muxer can be listed with `ffmpeg -h muxer=null` and similar)
<johnjaye> it says wrapped_avframe and pcm_s16le
Krusher has joined #ffmpeg
<JEEB> yup, just noting that these details can be actually looked up :)
<johnjaye> well yes. the problem is i'm learning the ffmpeg syntax gradually and a lot of it is scattered over these various pages.
<johnjaye> e.g. in this case you said null i thought you meant the null filter at first
Sketch has quit [Ping timeout: 276 seconds]
<JEEB> :) `-filter_complex` or `-{a,v}f` versus just plain `-f`
DauntlessOne4 has quit [Ping timeout: 264 seconds]
rsx has quit [Quit: rsx]
rex has quit [Ping timeout: 252 seconds]
<JanC> it's of course possible that whatever tool you use to "work with it" is slow with VP9...
Sketch has joined #ffmpeg
<johnjaye> idk, i'm just using ffmpeg to convert some yt vids
<JEEB> anyways, you can get comparison numbers with the null cli to get a feel for the difference
<JEEB> you never posted numbers so we have no idea what your felt range is
<JEEB> because VP9 will most likely be slower than H.264, but faster than HEVC and friends (after all, it's 10 years newer than AVC/H.264 which was first released in 2003)
<johnjaye> i'm not sure i follow
<johnjaye> is the expectation that decoding a typical video clip would be faster if it was vp9 or slower? as opposed to x264?
<johnjaye> i'm saying in a test case i found it to be slower than the clips in x264
wziko has joined #ffmpeg
<JEEB> your initial comments were in the vein that VP9 was too slow for you
<JEEB> and that you had to re-encode to AVC/H.264 to get things to be decoded fast enough
<johnjaye> sorry that's not what i meant
<JEEB> that is why I am interested in the pure decoding performance numbers, as my feeling so far for VP9 is that it is probably a bit slower than H.264, but not *that* much slower
<johnjaye> i meant i had some clips in x264, some in vp9, i was converting everything to x264, and noticed a difference in the time it took
<JEEB> ok, so same thing. check if purely with just decoding to see what sort of numeric difference you get?
Muimi has joined #ffmpeg
<JEEB> if the numbers are closer than your full workflow was
<JEEB> then it means that your bottleneck was somewhere else
<another|> x264 is an encoder btw
Krusher has quit [Read error: Connection reset by peer]
wziko has quit [Ping timeout: 265 seconds]
alexherbo2 has quit [Remote host closed the connection]
<another|> also, you mentioned youtube dls. are the vp9 files higher resolution ?
alexherbo2 has joined #ffmpeg
<JEEB> he would see the resolution and pixel format etc in the command line output if he had just done the decoding speed run
<johnjaye> ok. let me see if i can do a test. i have a short vp9 clip here
<johnjaye> am i looking at the speed parameter?
<furq> fps
Everything has joined #ffmpeg
<johnjaye> what i did was take the clip, strip out audio, and convert it to x264. then compare the original to the x264 one
<furq> speed also works if the clips are the same framerate
<johnjaye> it's the same clip yes. fps for the vp9 was 2266, for the other was 2307
<johnjaye> very small difference i guess
<JEEB> yea, both *very* fast to decode
<johnjaye> hmm. ok makes sense. there must be some other reason for my feeling then
<JEEB> H.264 being a whopping 1.8% faster :)
<furq> is there a significant difference in cpu usage
<JEEB> johnjaye: btw this is why Firefox literally embeds a copy of the FFmpeg VP9 decoder :D the decoder was and is very well optimized given that you're decoding a format that is 10 years newer and thus much more likely to be more complex
<johnjaye> i don't see the cpu usage stat
<furq> i mean check in top or task manager or whatever
<johnjaye> oh. well i selected a 2 min clip so it finishes too quickly to check
<johnjaye> i think i have a longer one maybe
<johnjaye> this hour long clip is going at 6x on my old desktop here
<furq> at least here the vp9 decoder only uses about 45% cpu and h264 uses about 90%
<johnjaye> but you mean if i just look at task manager the cpu usage would be different maybe?
<furq> which is the opposite of what i thought
gchound has joined #ffmpeg
<johnjaye> codecs use different cpu power?
<furq> well yeah
<johnjaye> i guessed every encode would just max out cpu to 100%
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<JEEB> also do note that CPU % depends on the scaling :D
<JEEB> so if the CPU decides it can chill at 2.2GHz or something
<JEEB> you will have a higher % of CPU usage than when it decides to boost to 4.5GHz
<furq> i guess i should check if all cores are boosting
<johnjaye> like here i'm converting this vp9 clip to x264 and all 4 cores are at 100%
<furq> at least some of them are
<furq> encoding with a modern codec will usually max out the cpu
<JEEB> I would just recommend poking at something like `/usr/bin/time -v`, which gives you various statistics
<furq> unless it's libvpx
<JEEB> rather than trying to guesstimate with CPU usage graph
<furq> but decoding probably won't
<furq> i assume the vp9 decoder defaults to fewer threads
<johnjaye> well it's not important enough of an issue to investigate
<johnjaye> it's just a feeling of a few seconds i felt when decoding some vp9 vids
<furq> i was thinking maybe the vp9 decoder was using way more threads and it was clobbering your encoder
<furq> but i guess not
<johnjaye> i mean i'm also on windows idk if that affects the outcome
<johnjaye> but yes i'm literall 4 cores all at 100% for this vp9 video
<furq> not other than windows generally having wonky thread scheduling
<johnjaye> by the way is there a guide or tutorial on the site about color spaces?
<johnjaye> i see yuv420p is specified but you can also specify variants of this
<furq> those are pixel formats, not colourspaces
<furq> and you will generally never use anything but yuv420p
<furq> if you ever need to you'll know about it
<johnjaye> eh. ok
<johnjaye> i thought it was like the Y Cr Cb color space
<johnjaye> or whatever it's called
<JEEB> yes, it used to be colloquially (incorrectly) called YUV due to the whole analog video history
<furq> they're related
<furq> but e.g. yuv420p, yuv444p, yuv420p10le are all the same colourspace
<JEEB> and if you get 4:2:0 content if it's not flagged the default is to interpret it as if it has a matrix coeffients for YCbCr
<JEEB> (usually either the BT.601 matrix for SD or the BT.709 one for HD)
<JEEB> you can see a listing of these things from the ITU-T H.273 specification that is available for free
<johnjaye> ah. i see bt709 in the output. i'll look that up as well
<johnjaye> ah ok. i was going to say if you know any good textbooks on some of this stuff let me know
grufwub has quit [Remote host closed the connection]
<JEEB> you can think of interpreting a signal requiring the following parameters { matrix coefficients, primaries, transfer function, color range }
<johnjaye> i've looked at various DSP books but it's hard to know what is useful and what isn't
grufwub has joined #ffmpeg
<JEEB> for example sRGB would have: identity matrix, bt.709 primaries, sRGB transfer, full range
<JEEB> H.274 basically is where ISO and ITU decided that they don't want to duplicate the exact same list of signal type identifiers over all of the video coding specs :)
<JEEB> I think H.264 and H.265 still have the lists separately, but H.266 just points towards H.273
alexherbo2 has quit [Remote host closed the connection]
<johnjaye> knowing the exact version of a spec to download i concede is a valuable skill. thanks!
alexherbo2 has joined #ffmpeg
<JEEB> those are just separate specs, not versions :)
<JEEB> H.26x are the video compression series at ITU
<JEEB> H.27x has various signal identification related stuff
DauntlessOne4 has joined #ffmpeg
Everything has quit [Quit: leaving]
Arokh has quit [Ping timeout: 252 seconds]
cmc_ is now known as cmc
Arokh has joined #ffmpeg
HarshK23 has quit [Quit: Connection closed for inactivity]
memleak has joined #ffmpeg
KillerWasp has joined #ffmpeg
jpsollie has joined #ffmpeg
<jpsollie> hello everyone, can anybody please explain to me how to interprent the VMAF score? As far as I understood, it shows a score of 0-100 depending on quality ...
alexherbo2 has quit [Remote host closed the connection]
<jpsollie> I'm trying to recode a set of old movies to x264 (my smart TV has a MIPS CPU, and x264 is one of the few hardware accelerated codecs in this SoC)
<jpsollie> but whatever I do, Inever get a VMAF of >= 45
<jpsollie> even -q:v 16 (whereas the wiki says anything below 18 is almost lossless) doesn't get more than 43.5
<jpsollie> so what is wrong with my "compare" command?
<jpsollie> ffmpeg -i test2.mkv -i ./RC1_t04.mkv -filter_complex libvmaf -f null /dev/null
rex has joined #ffmpeg
<jpsollie> if anybody knows why 45 seems to be an upper limit, please let me know ...
<BtbN> What's the score for the source material?
<BtbN> It won't suddenly magically get better, only ever worse with every lossy re-encode
<BtbN> Also, x264 is an encoder, a pure software one. h264 is the codec.
<jpsollie> uhm ... isn't vmaf to say 'if you recoded file1 to file2, I can tell you file2 looks almost / somewhat / a bit ' like the original?
<jpsollie> so can I score the source file with no refence to compare against?
<BtbN> I don't think without the original, the score means much of anything
<jpsollie> so my idea was "I have a file (original.mkv) encoded in mpeg2, I'll transcode it to h264 (recoded.mkv) and use VMAF to get an idea of the quality loss caused by transcoding
<BtbN> It's odd that something can hwdecode h264, but not mpeg2
<jpsollie> is there something wrong with this logic?
<jpsollie> yes, indeed
<BtbN> mpeg2 should be almost completely contained in h264
<jpsollie> don't understand why
<BtbN> in terms of features the hardware needs
<jpsollie> but it looks like h264 can be hw decoded on the smart tv via vlc player, but not mpeg2
<jpsollie> anyhow, did I miss something in my logic?
<BtbN> And I guess it's too slow to just sw decode it?
<BtbN> mpeg2 isn't exactly complex
<memleak> i can personally tell the difference between 10 and 18
<BtbN> At which settings?
<memleak> 18 is terrible on a big screen
<BtbN> crf 18 in placebo mode is a whole different ballpark than crf 18 ultrafast
<memleak> placebo and ultrafast have no impact on video quality IIRC but file size, maybe i'm wrong
<BtbN> of course they do. Specially ultrafast turns of a ton of encoder features
<BtbN> The crf values have no absolute meaning
<BtbN> Their produced quality changes depending on all other encoder settings
<jpsollie> really?
<BtbN> the only absolute truth is that a lower value will produce better quality than a higher one, if everything else stays the same
<memleak> ffmpeg -i <file> -c:v libx264 -c:a aac -b:a 320k -ac 2 -preset medium, huge difference between -crf 10 and -crf 18
<jpsollie> so -q:v 16 -preset ultrafast has a worse quality compared to -q:v 15 -preset placebo?
<jpsollie> this sounds somewhat counter-intuitive
<BtbN> I'm not even sure if libx264 looks at -q
<BtbN> You want to use -crf
<memleak> yeah i don't use q
<BtbN> But yeah, there's absolutely nothing that can be said about the relation of two crf values on different presets
<BtbN> You can probably guess relatively safely that 5 will look better than 50, but that's about it
rvalue- has joined #ffmpeg
rvalue has quit [Ping timeout: 246 seconds]
<memleak> that's just not true.
<memleak> you can clearly see distortion in motion with -crf 18 same settings
<BtbN> Nobody claimed you can't?
<JEEB> people keep saying crf 18 is somehow magical, but it isn't :P
darkapex has quit [Remote host closed the connection]
<memleak> yeah it's dog water
<JEEB> if it looks good enough, you go up. if it looks bad, go down
<BtbN> crf 18 is pretty good already, but obviously still lossy
darkapex has joined #ffmpeg
<JEEB> find the highest that still looks Good Enough
<BtbN> Specially if you throw the right stresstest-videos at it
<JEEB> usually by encoding a few minutes of representative content for that specific type of source (frame rate, resolution, style)
<memleak> heh NHL stanley cup playoff game would be a good test IMO
<JEEB> -ss SECONDS and -t SECONDS can be utilized to seek into your source and then to encode a few minutes
<memleak> dark colors on white is most pronounced for that kind of thing
<JEEB> so that you get a representative'ish sample over which you can then iterate quickly
<JEEB> do note that you first want to set the preset (speed basically), and then after you get that set, then you find the CRF
<JEEB> since the result of a specific CRF value depends on how the encoder "sees" the content
<JEEB> and that depends on the amount of time the encoder utilizes to analyze frames
<jpsollie> the issue is also: I'm trying to find a way that I can say "this x264 output is fine, I can live with this quality loss", and then compare how much space I'd waste by using vaapi encoder instead and still get more or less equal VMAF, without watching every bunch of settings 4 times to see manually
<JEEB> right, so you trust that specific VMAF is "good enough" when iterating for crf
<jpsollie> no
<jpsollie> I see manually "this x264 transcode is OK"
<BtbN> I really don't think you can calculate a useful vmaf score without the lossless original
<JEEB> isn't the input file the original in this case?
rvalue- is now known as rvalue
<BtbN> no, it's an mpeg2 file
<jpsollie> then I calculate the VMAF of the x264 transcoded video against the original mpeg2
memleak has left #ffmpeg [Leaving]
<jpsollie> when it would say "xx", I know I need to generate a transcoded video with a score that's more or less "xx"
<JEEB> BtbN: yea but for any metric it's against your input
<JEEB> and if the input file for both x264 and vaapi encode is that mpeg2 file
<JEEB> that is the "sauce"
<BtbN> well, it never going above 45 indicated to me that it's not working properly
<jpsollie> what isn't working properly?
<JEEB> are these metrics being calculated with avfilter?
<JEEB> if yes, it's possibly frame times causing mismatched frames being compared
<JEEB> since it's trying to sync them by time and different time bases can cause it to do fun things
<JEEB> if not, then it's not that
<jpsollie> ffmpeg -i test2.mkv -i ./RC1_t04.mkv -filter_complex libvmaf -f null /dev/null --> can I see here if there is a timeframe issue?
<JEEB> btw you can utilize "pipe:" instead of /dev/null
<JEEB> with the null muxer
stolen has quit [Quit: Connection closed for inactivity]
<JEEB> since null muxer doesn't output anything, and thus nothing actually gets output into standard output
<JEEB> jpsollie: test against some non-ML metric, I think there's ssim or so in avfilter?
<JEEB> those should also output meh results
<jpsollie> true, tried ssim, but couldn't find what those numbers mean:
<jpsollie> SSIM Y:0.844006 (8.068933) U:0.927993 (11.426232) V:0.933495 (11.771470) All:0.872919 (8.959192)
<jpsollie> for libx264 vs original mpeg2 filter
<another|> IME different timebases are often a problem with vmaf
<another|> normalise them
<JEEB> the SSIM values don't look too bad I think
<JEEB> since I think it goes all the way to 1.0?
<JEEB> ssim filter actually attempts to warn you if they are different
<JEEB> > "not matching timebases found between first input: %d/%d and second input %d/%d, results may be incorrect!\n"
<jpsollie> can you explain to me how I should interprent those values? I mean, VMAF is a 0-100 similarity index, but how are things with SSIM?
<JEEB> same without the times 100
<JEEB> so 0.92 is 92
<jpsollie> so the Y colorspace is O.84 similar, U is 0.92, and V is 0.93 giving a total similarity of roughly 87%, it that what you're saying?
<JEEB> Y being luma and U,V (Cb,Cr in your case) being the chroma
<JEEB> if you want to double-check what sort of frame timestamps are being fed to the filter chain, `-v verbose -debug_ts` will do that, but I would recommend limiting to like `-frames:v 5` or so as it will log the state of packets or frames at each step of the way
<jpsollie> ok, let's try
ocrete has quit [Quit: The Lounge - https://thelounge.chat]
ndufresne has quit [Quit: The Lounge - https://thelounge.chat]
<jpsollie> JEEB: I ran "ffmpeg -v verbose -debug_ts -i test1.mkv -i ./RC1_t04.mkv -filter_complex libvmaf -frames:v 5 -f null /dev/null", so what should I check?
<JEEB> I think there's specific ones that log things going into the filter (chain)
<jpsollie> I do not see too much feedback from fc#0, but the VMAF score for only 5 frames is 97
ndufresne has joined #ffmpeg
<jpsollie> [fc#0 @ 0x55a49b31f180] filter_raw -> pts:203 pts_time:0.203 time_base:1/1000 --> this is (more or less) the only kind of thing fc#0 says
<JEEB> that's on the output side
jemius has joined #ffmpeg
<JEEB> not fully sure, but `decoder ->` might be the closest since that's the output from the decoder
<jpsollie> [fc#0 @ 0x55a49b31f180] filter_raw -> pts:43 pts_time:0.043 time_base:1/1000 filter -> pts:1 pts_time:0.04 exact:1.075005 time_base:1/25
<jpsollie> is this something useful to you?
<jpsollie> if not, I'll stick with SSIM then, it's not like it's HQ content anyway
<JEEB> that's the output of filter so not that relevant. so it's when ffmpeg the tool is poking at the filter chain and requesting if there's any frames available
<JEEB> as I said, the decoder thing is probably the one just before
<JEEB> I would have expected one at the feeding to filter
<JEEB> but it seems like there isn't one
<JEEB> the feeds usually are "thing <-" instead of "thing ->"
<jpsollie> [vist#1:0/mpeg2video @ 0x55a49b387080] [dec:mpeg2video @ 0x55a49b36d440] decoder -> pts:880 pts_time:0.88 pkt_dts:880 pkt_dts_time:0.88 duration:40 duration_time:0.04 keyframe:0 frame_type:3 time_base:1/1000
<JEEB> yup, so you get to compare that between the two inputs' video streams
<jpsollie> [vist#0:0/h264 @ 0x55a49b357d40] [dec:h264 @ 0x55a49b384840] decoder -> pts:243 pts_time:0.243 pkt_dts:243 pkt_dts_time:0.243 duration:40 duration_time:0.04 keyframe:0 frame_type:3 time_base:1/1000
<JEEB> that should tell you whether those frames you tested matched or not
<jpsollie> and I assume it isn't here?
<JEEB> ?
<JEEB> those are exactly the decoded results, so in that sense as there is no filter feeding debug_ts, those are the ones that should in theory be just before the filter chain
<JEEB> thus you should be able to compare between the two streams how the pts values grow
<jpsollie> the mpeg2 decoder stream shows many different 'time' things compared to the h264 decoder, like eg pts
<jpsollie> doesn't that tell us it's not normalized?
<JEEB> I mean, I do not know if you went all the way for example to the first case of decoder output
<JEEB> and compared those two
<JEEB> because if you just selected a random one around some point and then another point that doesn't really tell you much since each decoder is running in its own thread
<JEEB> same for inputs etc, so they are not in steplock
* jpsollie gives up ... SSIM for cartoon movies is fine
Sketch has quit [Ping timeout: 255 seconds]
<jpsollie> thank you for your time JEEB
<JEEB> not like VMAF is in any way or form somehow super special
<JEEB> I think it's a mix of some metric plus random ML stuff they came up with for very specific resolution
<JEEB> also it's funny how they SSIM implementation in avfilter actually takes into account chroma (color), most implementations IIRC just check luma. checking all of course is better since usually you want to know how badly your color is different as well as the light (grayscale)
<JEEB> for a listing of different metrics I recommend checking out AWCY (are we compressed yet)
<JEEB> it taught me CIEDE 2000 for example, which is a color accuracy specific metric :3
<jpsollie> I still got lots to learn about quality comparison, but if the target is "the loss of quality in transcoding attempt x should be more or less equal to transcoding attempt y", I don't think it's worth investigating a lot
<JEEB> so far for any serious use the main thing seems to have been "have many different metrics so you can see how many regress and how many don't with changes"
<JEEB> and in general otherwise I just know that "PSNR loves blur" :P
Sketch has joined #ffmpeg
ocrete has joined #ffmpeg
Sketch has quit [Ping timeout: 252 seconds]
Sketch has joined #ffmpeg
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
<johnjaye> is this book worth getting? the guy has a lot of articles too
wziko has joined #ffmpeg
Sl4yer has quit [Remote host closed the connection]
wziko has quit [Ping timeout: 248 seconds]
l4yer has joined #ffmpeg
RobMeades has joined #ffmpeg
jemius has quit [Quit: Leaving]
Dagger has quit [Ping timeout: 244 seconds]
<RobMeades> I'm using libav* in C++ on a PiZero2W with libcamera to stream video via HLS (AV_CODEC_ID_H264, 854x480 resolution) following this example: https://medium.com/@vladakuc/hls-video-streaming-from-opencv-and-ffmpeg-828ca80b4124.  I have a few questions that browsing/Google has not been able to answer:
<RobMeades> 1. All calls to av_interleaved_write_frame() cause the message "[hls @ 0x3678670] Stream 0 packet with pts x has duration 0. The segment duration may not be precise.", is this normal/ignorable or do I have a problem?
<RobMeades> 2. It takes 45 input frames (of a static view) before the codec returns the first output frame: is this normal?
<RobMeades> 3. At that 45-input-frame mark avcodec_send_frame() takes over a second to execute, more than 15 seconds if I increase the resolution to 1920 x 1080 (which is my target): is this just 'cos I'm on a weedy PiZero2W?
<RobMeades> 4. Lastly, only a single HLS segment file gets written, and that only when I close the file, and of course though it contains images none are timed properly: is there a better HLS video streaming example out there somewhere which might help me get HLS right?
<JEEB> this sounds like FFmpeg API usage, so technically if you look at the topic #ffmpeg would be the correct forum
<JEEB> oh wait you are here
<JEEB> goddamnit
<JEEB> sorry
<RobMeades> :-)
<JEEB> anyways, first of all zero duration packets should no longer be utilized. with new enough FFmpeg encoders should be passing durations through, so if your AVFrames have durations set, that should be passed to the AVPackets
<JEEB> also you most likely are utilizing whichever H.264 encoder is first in the list in your build if you are just specifying an encoder by codec id
<JEEB> I definitely recommend looking the encoder up with a name
<RobMeades> My build was "--enable-libx264 --enable-nonfree --enable-v4l2-m2m"
<JEEB> you should not utilize nonfree unless specifically required, as it makes the resulting binary non-distributable
<RobMeades> You say "AVFrames have durations set".  I set the PTS and expect that to imply a duration: do I also need to be setting a duration field in the AVFrame?
<JEEB> (also if you do not enable any libraries requiring the flag, you are not even gaining anything)
<JEEB> RobMeades: think of the last frame case. if you never set duration when does the presentation of that frame stop?
<JEEB> some containers don't support packet duration, but passing a duration if you know it through the workflow does not make anything worse
<RobMeades> Understood: the examples I've been working from only ever seemed to set pts.  Lemme go find the duration field...
<RobMeades> > you should not utilize nonfree unless specifically required, as it makes the resulting binary non-distributable
<RobMeades> Understood.
Dagger has joined #ffmpeg
<JEEB> RobMeades: the framework at certain points didn't pass that stuff too well or some struct lacked the duration field, but now it's all there
<JEEB> as for 2. , that is 100% depending on the encoder
Sketch has quit [Ping timeout: 252 seconds]
<JEEB> I expect you are ending up with libx264, and yes. its library defaults have a long analysis phase and other stuff which brings up latency
<RobMeades> Yes, I think that is probably right.  Are there any better encoder options I should be thinking of?
<JEEB> for software encoding x264 is basically best you have.
<RobMeades> OK.
<JEEB> it has presets which let you control how much CPU time it will utilize
<JEEB> `ffmpeg -h encoder=libx264`
<JEEB> and this is why I say that you should select the encoder by string (name), and not by codec id
<JEEB> since you may have multiple
<RobMeades> Oh, OK, I had not appreciated that.
<JEEB> that way you know exactly what you're dealing with
<JEEB> and if it is not available in the build, you get a failure
<RobMeades> (y)
<JEEB> for 3. that just sounds like it started actually processing things, and the default is -preset medium so I'd expect that on an ARM core that would take a while
<RobMeades> So I can find somewhere in a codec option a way to give it more CPU?
<RobMeades> [The CPU is not doing much else].
<JEEB> x264 should figure out how many cores you have and utilize all of them
<RobMeades> I looked at the code capabilities and it had no thread capability, so maybe I am somehow using the wrong codec.
<RobMeades> code -> codec.
<johnjaye> JEEB: did you see my textbook question? Also thanks for the ITU standards recs, are the ones before h26x also informative?
<JEEB> johnjaye: if you are just starting I'd just recommend xiph's monty's basics video
<JEEB> a lot of standards are informative but usually you want to focus on something specific that you want to look up with them
l4yer has quit [Ping timeout: 272 seconds]
<RobMeades> @JEEB: any thoughts on a better HLS example using the C API?  I have only found the one so far.
<JEEB> it's a normal muxer so it should work just the same as other muxers API-wise
<JEEB> not like the ffmpeg cli is doing something special for it either
<RobMeades> OK, so https://ffmpeg.org/doxygen/7.0/mux_8c-example.html would be the thing to follow?
<JEEB> I'd probably look at the full transcoding example as I think all of the separate examples focus a lot on just one thing (such as the encoding example not using avformat to write a container, but just barfing coded packets straight into a file)
<JEEB> also I always recommend the examples to be looked up in trunk (master) of the web docs
<RobMeades> (y)
<RobMeades> Thanks for the pointers, will go take a look and hopefully not come back with more stooped questions.
<JEEB> also one doc page I definitely recommend
<RobMeades> Thanks for the pointers, will go take a look and hopefully not come back with more stoopid questions.
<JEEB> this is probably my favourite out of the doxy docs
<RobMeades> Yes, I read that one a few times.
Sketch has joined #ffmpeg
<RobMeades> I found the duration field in AVFrame: it is an int64_t and says that it is "Duration of the frame, in the same units as pts."  The pts says it is in "time_base units", and I have time_base set to numerator 1, denominator 25.  So the duration field should be set to 1 to mean 1 frame.  Is that right?
<RobMeades> I found the duration field in AVFrame: it is an int64_t and says that it is "Duration of the frame, in the same units as pts."  The pts says it is in "time_base units", and I have time_base set to numerator 1, denominator 25.  So the duration field should be set to 1 to mean 1 frame (one unit of time_base, which is 1/25th).  Is
<RobMeades> that right?
<JEEB> for the record, when you modify your message it just gets re-sent fully :P
<RobMeades> Yeah, so I see...
<RobMeades> Used to Slack...
<JEEB> anyways, yes that sounds correct. if there is a known static frame rate then pts would for example start from 0 and the duration would be 1
<RobMeades> Good.  Unfortunately setting a duration of 1 doesn't seem to have removed the warning about there being no duration.  I will continue poking...
<JEEB> check the encoder output packet values
<RobMeades> Will do...
<JEEB> I do recall passthrough for duration being added in avcodec
<JEEB> ah, flags
<RobMeades> Oh, flags?
<JEEB> if AV_CODEC_FLAG_FRAME_DURATION is not set in the context, the framework unsets output packet duration
<RobMeades> Oh!
<JEEB> yeh, and the command line app is doing that
<JEEB> `enc_ctx->flags |= AV_CODEC_FLAG_FRAME_DURATION`
<RobMeades> (y)
wziko has joined #ffmpeg
wziko has quit [Max SendQ exceeded]
wziko has joined #ffmpeg
<RobMeades> Adding the flag has made the duration warning go away, one down!  Nothing has changed in the written output, but at least the irritating warning has gone away.
alexherbo2 has joined #ffmpeg
rv1sr has quit []
<JEEB> if you need to poke at the hls muxer, I'd first play with it through the command line app to get acquainted with it, whether you need any specific options or otherwise
<RobMeades> Understood.
<JEEB> since in general the HLS meta muxer *should* be just the same as any other basic muxer like mp4 or mpegts
<JEEB> you configure it, open it, feed it packets, then finalize it
<JEEB> but in case you get suspicious then testing with mp4 or mpegts would be a good way of seeing
<RobMeades> (y)
realies has quit [Ping timeout: 244 seconds]
realies has joined #ffmpeg
RobMeades has quit [Ping timeout: 240 seconds]
Marth64 has quit [Quit: Leaving]
lavaball has quit [Remote host closed the connection]
gchound has quit [Quit: WeeChat 4.1.1]
Sketch has quit [Read error: Connection reset by peer]
Marth64 has joined #ffmpeg
Sketch has joined #ffmpeg
<johnjaye> i'm struggling to set a duration on a clip
<johnjaye> i produce a video from a still image as various tutorials suggest. but it just plays forever and nothing I do can limit it.
<BtbN> Shouldn't be much more than -to
RobMeades has joined #ffmpeg
<johnjaye> length reports as 0. i guess i can add an audio track then remove the audio track
<johnjaye> -to doesn't seem to behave differently than -t
<johnjaye> ffmpeg -to 5 -i melon.jpg -framerate 1 -r 30000/1001 -pix_fmt yuv420p y.mp4
<johnjaye> this is what i have now.
<BtbN> Try it as an output options
<BtbN> -s
<BtbN> And you'll want to loop the input, otherwise the video will always just be one frame long
sihloo has quit [Quit: ZNC 1.9.1 - https://znc.in]
<johnjaye> yes of course I tried that first
<johnjaye> I tried that also
<johnjaye> meaning it's not actually playing multiple frames, it just shows 1 frame and freezes?
<johnjaye> ah ok both of those options in concert did the trick.
<RobMeades> @JEEB: FYI, in the transcoding example, I spotted that there's a mysterious line, after everything has been opened, that copies time_base into AVStream, which the sample code I have been looking at definitely didn't do; I hadn't even realised that AVStream had to be set up, since time_base is already there in AVCodecContext and AVFrame.
<RobMeades> Anyway, finding that magic line has made my output video at least follow time.  Thanks for pointing me at that example!  Now to find out why the segment files don't get written until I've finished...
Sketch has quit [Remote host closed the connection]
Sketch has joined #ffmpeg
<johnjaye> thanks that did it
SuicideShow has quit [Ping timeout: 260 seconds]
SuicideShow has joined #ffmpeg
wziko has quit [Ping timeout: 265 seconds]