<JEEB>
that should tell whether it is in extradata or not
<JEEB>
also for the record, I don't understand removing that SEI since it also completely removes the possibility of doing workarounds based on broken encoder versions, like we've had with x264 and lossless coding.
<JEEB>
but it can be done technically :P
<furq>
i see a type 39 sei in extradata
<furq>
or type 39 nalu i mean
<furq>
and yeah i also don't know why you'd remove it
<furq>
filter_units will also potentially remove important seis if there are any mid-stream
<furq>
or rather it sounds like the only seis it can remove are important
jtgd has quit [Quit: WeeChat 4.1.1]
<furq>
but if these are videos you encoded yourself you probably don't have any
<furq>
extradata stuff is at the top before the first Packet: line
<furq>
and yes that is in extradata
ivanich has quit [Remote host closed the connection]
ivanich has joined #ffmpeg
Shine has joined #ffmpeg
Gunstick- has joined #ffmpeg
Gunstick-- has quit [Ping timeout: 240 seconds]
a0z has quit [Ping timeout: 255 seconds]
vlm has joined #ffmpeg
ZedHedTed has quit [Ping timeout: 264 seconds]
ZedHedTed has joined #ffmpeg
<aaabbb>
another question how do i remove the aspect ratio information from an hevc stream in an mp4 container?
<aaabbb>
so that it defaults to sar=1 and the dar is based only on the dimensions?
<aaabbb>
so that ffprobe does not show '854x480 [SAR 1280:1281 DAR 16:9]' and instead shows only '854x480'
<aaabbb>
when i have '-bsf:v hevc_metadata=sample_aspect_ratio=0/1' to leave the sar undefined so it defaults to 1, it shows a strange '854x480 [SAR 30811:30902 DAR 731204:412195]'
<aaabbb>
but when i change it to 1/1 it shows '854x480 [SAR 1:1 DAR 427:240], 232 kb/s, SAR 30811:30902 DAR 731204:412195'
sopparus has quit [Server closed connection]
sopparus has joined #ffmpeg
Friendship has joined #ffmpeg
<aaabbb>
basically i want ffprobe -show_streams to show N/A for both sample_aspect_ratio and display_aspect_ratio
stolen has joined #ffmpeg
<aaabbb>
oh great it looks like only direct264 can do that
<JEEB>
you should check the result with trace_headers :P
<aaabbb>
JEEB: yeah i did, sar_width and sar_height in the sps are still non-zero
<aaabbb>
but if i can set them to 0, then the sar should default to 1/1 and the aspect ratio should be determined entirely by the dimensions
<JEEB>
what you really want is aspect_ratio_info_present_flag = 0
<JEEB>
also do note that the container has aspect ratio info as well, which often (like with mp4/matroska) generally is considered higher than video's
<aaabbb>
i can remove the aspect ratio from the container more easily
<aaabbb>
but i can't find how to remove it from the bitstream without setsar=1 which of course requires reencode
<JEEB>
setting it to 1 should be possible, h264 and h265 metadata bsfs can update and add parts to VUI, but not remove them completely
<JEEB>
and if you don't want the SAR info at all, you want to remove it completely
<aaabbb>
when encoding with setsar=1, does it remove the sar info or set them to 1/1?
<JEEB>
depends on the encoder logic
<aaabbb>
x265
<JEEB>
that's why you can't make assumption
<JEEB>
libx265.c does set sar=1:1 in that case
<JEEB>
so then the question is how does x265 itself interpret that
<aaabbb>
doesn't that mean it would set width and height = 1 in the sps?
<JEEB>
no
<JEEB>
width and height is different from SAR
<aaabbb>
sar_Width, sar_height i meant
<JEEB>
as I said, depends on x265 itself does. FFmpeg's libx265.c wrapper passes it on
<JEEB>
but in any case
<JEEB>
what you want is the BSF to be modified to allow for removal of VUI entries in addition to just modifying or adding
<JEEB>
since right now it can either add it if it is not in the original, or update values
<JEEB>
but it does not set aspect_ratio_info_present_flag = 0 anywhere
lavaball has joined #ffmpeg
<aaabbb>
when i do '-bsf:v hevc_metadata=sample_aspect_ratio=1/1', it moves the odd 30811/30902 sar outside of the brackets, does that mean it's moved into the container or something? with trace_headers, it no longer has sar_width=30811 and sar_height=30902, although aspect_ratio_info_present_flag is still 1 (which is ok)
dallemon has quit [Server closed connection]
<aaabbb>
so that changes it to '854x480 [SAR 1:1 DAR 427:240], 232 kb/s, SAR 30811:30902 DAR 731204:412195'
dallemon has joined #ffmpeg
<aaabbb>
i found a workaround
<aaabbb>
a stream copy from the mp4 source to another mp4 with -bsf:v 'hevc_metadata=sample_aspect_ratio=1/1', then a stream copy to a raw .h265 file, then a stream copy back to an mp4
<aaabbb>
mp4box to the rescue! mp4box -par 1=w1:1 test.mp4
<aaabbb>
completely fixes it, although it changes hvc1 to hev1 but i can change that back with ffmpeg :)
zmt00 has joined #ffmpeg
zmt01 has quit [Ping timeout: 240 seconds]
dallemon has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
billchenchina has joined #ffmpeg
Blacker47 has joined #ffmpeg
dallemon has quit [Quit: Ping timeout (120 seconds)]
Jan\ has quit [Ping timeout: 255 seconds]
dallemon has joined #ffmpeg
JasonSilver has joined #ffmpeg
brianp has joined #ffmpeg
<brianp>
Is there a way to define a "style" for drawtext filters that I could apply to every use of drawtext. By style I mean font, color, fontsize etc. It would be neat to define it once, and apply it against any dratext filter needed.
<JEEB>
aaabbb: you should be able to just set the aspect ratio raw option (sar) and in theory that should then get passed to the codecpar. should be visible in the Input: and Output: things. try it on the input side first, and then output
<aaabbb>
JEEB: that won't work with stream copy right?
<JEEB>
if it still sets the parameter to the context, it should
<JEEB>
which is why I said first try on the input side, since those values should get copied. and if that doesn't work, try on the output side
rsx has joined #ffmpeg
<JEEB>
I just couldn't see an AVOption for the avformat sample aspect ratio
<aaabbb>
JEEB: what's the aspect ratio raw option? i only know how to use setsar which needs a reencode and hevc_metadata which didn't help
<aaabbb>
i also tried using -aspect but that didn't work either
<JEEB>
aspect and sar
<JEEB>
and try input side first, then output
<aaabbb>
Unrecognized option 'sar'.
<aaabbb>
probably because i'm on a version 4?
Jan\ has joined #ffmpeg
Friendship has quit [Read error: Connection reset by peer]
<aaabbb>
anyways mp4box fixed the issue, and from now on when i transcode i'll make sure to have -vf setsar=1
Friendship has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
elastic_dog has quit [Ping timeout: 252 seconds]
redeeman has joined #ffmpeg
<redeeman>
hello, when i use -c:v libx265 -crf 23, and then -preset fast/slow/veryslow, the files appear to become larger the slower the preset, wouldnt one expect it to be opposite?
<JEEB>
that depends, think of it as the encoder "seeing" more
<aaabbb>
redeeman: no, that's norma for x265
<JEEB>
it's the same for all encoders
<aaabbb>
>Due to x264 being much less complex, presets can pretty much maintain only a slight loss in quality as you encode faster. This gives an illusion that slower presets are slower due to spending more time compressing. The more correct way to see this is that slower presets are slower due to doing more motion calculations and finding the best scheme that best describes the frame, which in x264 just so happens
<JEEB>
for example if you check x264 with the slower presets you will see this
<aaabbb>
benefits compression too. However, x265 is waaay more complex with motion algorithms, meaning that accurately describing motion actually increases bitrate.
<JEEB>
so just ignore the x265-only'ness of the comments from aaabbb
elastic_dog has joined #ffmpeg
<aaabbb>
JEEB: right i wasjust saying that because he's using x265
<aaabbb>
however it's mroe apparent in x265 because with x264, a slower preset often happens to slightly reduce file size, enough that it's noticible and causes the misconception that slow preset = smaller file
<redeeman>
okay so if i were to for example use crf 28 with preset veryslow, and that filesize somehow matched preset fast at crf 23 (just example), the preset veryslow wins out in quality?
<aaabbb>
redeeman: generally yes
<aaabbb>
i'm sure there are a few pathological cases where you could find a strange input that looks worse at high preset, but you won't run into that naturally
<JEEB>
I would be surprised if not :) if you adjust CRF to match file size, the better preset should have better quality
<JEEB>
aaabbb: I mean, you were quoting it so that is why I'm telling explicitly to ignore that x265-only bit.
<redeeman>
i notice that when using the slower preset, the avg QP for I frames are almost similar to fast, but the avg QP for P frames is much lower, and more P frames exist
<aaabbb>
JEEB: ooh yes
<aaabbb>
redeeman: slower presets change a lot of settings, for example it'll try to use more B frames, it'll try to more accurately place B frames etc
<aaabbb>
a slower preset mostly improves motion estimation, which isn't relevant to I frames
navi has joined #ffmpeg
<JEEB>
I'd refrain from making such specific comments
<JEEB>
unless you really know the ins and outs of each encoder
<JEEB>
but the general gist is that since the default preset is supposed to be useful, most likely some of the fastest ones disable stuff that helps in all cases which then brings that expected file size reduction for the same rate factor value.
<JEEB>
as you raise the preset to something more attempting to compress
stolen has quit [Quit: Connection closed for inactivity]
Shine_ has joined #ffmpeg
ZedHedTed has quit [Remote host closed the connection]
ZedHedTed has joined #ffmpeg
<redeeman>
what about setting the profile to main10, i see many on forums that claims it improves encoding effeciency, I did a test: https://pastebin.com/NicQn0B5
<aaabbb>
redeeman: it can improve efficiency and reduce banding in some situations
<aaabbb>
especially with dark, flat scenes, so it's good for anime encodes, even if you have an 8-bit source
<redeeman>
this is an 8bit source
<redeeman>
but a real video
<aaabbb>
it can sometimes improve efficiency, it's one of those things you have to test (which you did)
<redeeman>
this seems to have provided an extreme difference in bitrate, and if i just watch the video, i see no difference, but i havent tried extracting frames and comparing
<aaabbb>
redeeman: are you just using -pix_fmt yuv420p10le?
<redeeman>
i did -c:v libx265 -crf 20 -preset fast -profile:v main10 -x265-params "level=5.1:high-tier=1:crf=20" -pix_fmt yuv420p10le
Shine_ has quit [Ping timeout: 255 seconds]
<redeeman>
and then vs -c:v libx265 -crf 20 -preset fast -profile:v main -x265-params "level=5.1:high-tier=1:crf=20"
<aaabbb>
you don't need to manually set main10 as the profile, try with just the 10 bit pix fmt
<redeeman>
wouldnt that just mean it autodetects main10?
<aaabbb>
i'm not sure, but you don't need to change the profile manually
<redeeman>
it doesnt work if i dont specify main10, it says: x265 [error]: main profile not supported, internal bit depth 10
<aaabbb>
ah
manwithluck has joined #ffmpeg
<aaabbb>
hm it works for me
noonien8 has joined #ffmpeg
<aaabbb>
for a 1080rce
<aaabbb>
for a 1080p 8 bit source*
<redeeman>
i have ffmpeg 6.0 x265--3.5
<aaabbb>
anyway maybe try 2 pass ABR to create two encodes, one with and one without yuv420p10le, and use vmaf to compare each to the original. and also manually look for banding in dark scenes
<aaabbb>
that way you can compare them at the same bitrate
<aaabbb>
i'm no expert so take my advice with grain of salt, but that's what i'd do
<redeeman>
i will try do many more comparisins, i just wanted to know if it was in general a stupid thing for some reason
mven has quit [Ping timeout: 255 seconds]
anticw has quit [Server closed connection]
anticw has joined #ffmpeg
MrZeus has joined #ffmpeg
colona has quit [Server closed connection]
colona has joined #ffmpeg
billchenchina has quit [Remote host closed the connection]
The_Blode has quit [Server closed connection]
The_Blode has joined #ffmpeg
markizano has quit [Quit: Poweroff]
ecapi has quit [Ping timeout: 252 seconds]
ecapi has joined #ffmpeg
markizano has joined #ffmpeg
ecapi_ has joined #ffmpeg
ecapi has quit [Ping timeout: 255 seconds]
minimal has joined #ffmpeg
iconoclasthero_ has joined #ffmpeg
iconoclasthero_ is now known as iconoclast_hero
AbleBacon has joined #ffmpeg
ivanich has quit [Ping timeout: 245 seconds]
kraftwerk28 has quit [Quit: *disconnects*]
kraftwerk28 has joined #ffmpeg
ecs has quit [Server closed connection]
ecs has joined #ffmpeg
waleee has joined #ffmpeg
<redeeman>
aaabbb: i just noticed, i got this: [swscaler @ 0x556c89700f00] deprecated pixel format used, make sure you did set range correctly
<redeeman>
when using yuv420p10le
waleee has quit [Client Quit]
iconoclast_hero has quit [Ping timeout: 245 seconds]
psykose has quit [Remote host closed the connection]
jarthur has joined #ffmpeg
psykose has joined #ffmpeg
foul_owl has quit [Read error: Connection reset by peer]
<catsoften>
Sorry to bother you with a different project but I tried asking over a month ago in #x264 and it's been completely silent. Figured someone here would know more about this than I do since ffmpeg supports/uses x264
Ischwitch has joined #ffmpeg
Ingvix has quit [Ping timeout: 252 seconds]
Ischwitch is now known as Ingvix
foul_owl has joined #ffmpeg
BetweenUs has joined #ffmpeg
rsx has quit [Quit: rsx]
paddymahoney has quit [Remote host closed the connection]
paddymahoney has joined #ffmpeg
BetweenUs has quit [Quit: Leaving]
Foxtop78 has joined #ffmpeg
Foxtop78 has quit [Client Quit]
lucasta has joined #ffmpeg
Blacker47 has quit [Ping timeout: 258 seconds]
lavaball has quit [Remote host closed the connection]
mven has joined #ffmpeg
iderik has joined #ffmpeg
FH_thecat has joined #ffmpeg
vampirefrog has joined #ffmpeg
bertieb_ is now known as bertieb
Muimi has joined #ffmpeg
nd has quit [Ping timeout: 240 seconds]
nd_ has joined #ffmpeg
nd_ is now known as nd
qqq has joined #ffmpeg
mven has quit [Ping timeout: 240 seconds]
Narrat has joined #ffmpeg
mven has joined #ffmpeg
mven has quit [Quit: Goodbye.]
mven has joined #ffmpeg
waleee has joined #ffmpeg
Gunstick- has quit [Ping timeout: 240 seconds]
b50d has joined #ffmpeg
Foxtop78 has joined #ffmpeg
<Foxtop78>
Hello, what could possible happen if i only use loudnorm filter for normalize my music with one pass instead of using two passes? I see in some forums that i should use ffmpeg-normalize script, but this doesn't work. Is it very bad for quality if i just use the loudnorm filter in one pass?
<durandal_1707>
yes, dynamic mode is very ad-hoc and amateur code
<durandal_1707>
i have some wip code to resolve this dynamic mess but that needs to be finished
<Foxtop78>
then what is the solution if ffmpeg-normalize doesn't work for me? (not able to install the script)
esc_ape has joined #ffmpeg
<Foxtop78>
is there a simple two line command i can use within a shell script to normalize all flac files in a folder?
esc--ape-- has quit [Ping timeout: 255 seconds]
Gunstick- has joined #ffmpeg
ZedHedTed has quit [Quit: leaving]
Foxtop78 has quit [Ping timeout: 250 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg
rv1sr has quit []
mven3 has joined #ffmpeg
mven has quit [Ping timeout: 255 seconds]
mven3 is now known as mven
whatever_nicknam has joined #ffmpeg
b50d has quit [Remote host closed the connection]
lucasta has quit [Quit: Leaving]
lavaball has joined #ffmpeg
lemourin5 has joined #ffmpeg
lemourin is now known as Guest2984
Guest2984 has quit [Killed (copper.libera.chat (Nickname regained by services))]
lemourin5 is now known as lemourin
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<ppw>
oh shucks I'm using fraunhofer's encoder, not ffmpeg's
<JEEB>
that also happens to utilize that option
<ppw>
does it? ooh
<JEEB>
too bad we don't yet have a system to tell user which global options are utilized by a specific module
vincento has joined #ffmpeg
anotheruser has joined #ffmpeg
someuser has joined #ffmpeg
whatever_nicknam has quit [Ping timeout: 250 seconds]
mrelcee has joined #ffmpeg
kron has quit [Ping timeout: 240 seconds]
kron has joined #ffmpeg
lusciouslover has joined #ffmpeg
mrelcee_ has joined #ffmpeg
mrelcee has quit [Ping timeout: 252 seconds]
mrelcee_ is now known as mrelcee
qaph has joined #ffmpeg
kron has quit [Ping timeout: 252 seconds]
Buster__ has joined #ffmpeg
ZedHedTed has joined #ffmpeg
<ppw>
oh that's weird. ffmpeg accepts 8m and 31s of stdin data, then ends the encoding
qaph has quit [Ping timeout: 252 seconds]
mrelcee has quit [Ping timeout: 240 seconds]
mrelcee has joined #ffmpeg
ivanich_ has joined #ffmpeg
ivanich has quit [Read error: Connection reset by peer]
kron has joined #ffmpeg
<brianp>
If i re-run the same command multiple times it fails about 1/5 times with "Cannot find a valid font for the family Abel" but the font file is always there, always in the same place.
MisterMinister has quit [Remote host closed the connection]
<brianp>
The filter looks like: `drawtext=text='brian':expansion=none:fontfile='/Users/brianp/Library/Developer/CoreSimulator/Devices/0919DC53-7B8F-4843-BAA5-77EF0B8BA738/data/Containers/Data/Application/CFF2866F-747C-4240-BB99-0C1BCECEC6E2/Library/Caches/Abel-Regular.ttf':fontcolor='ffffff':fontsize='65.21739130434783':font='Abel':shadowcolor='212121@0.698