fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
evilscreww has joined #ffmpeg
evilscreww has quit [Remote host closed the connection]
evilscreww has joined #ffmpeg
<evilscreww>
aaabbb: yep thank you. sorry but i since read in the meantime that mp4 is fine on yt. i just dont wanna use a format where there is a risk they will re-encode it on their end
<aaabbb>
evilscreww: they will always transcode on their end
<evilscreww>
aaabbb: i did read something else interesting though that i wanted you to confirm for me...
<aaabbb>
that's why you give them the highest quality you can, even if it's overkill. btw you can actually upscale the video, and that tricks youtube into using a higher bitrate ;)
<evilscreww>
aaabbb: yeh but id rather the minimum of quality loss if feasible
<aaabbb>
there's no way to give them a file and them not transcode it
<evilscreww>
aaabbb: exactly- thats why i wanted to demux concatenate without any filters or other re-encoding. because i wanna overkill it on the quality
<aaabbb>
they will always transcode it to vp9 and h264, and if it gets popular enough, also to av1
<evilscreww>
is h.265 > h.264 - lossy?
<aaabbb>
yes
<evilscreww>
disregard filesize
<aaabbb>
unless you do h264 lossless mode
<evilscreww>
thats odd - my phone seems to let you change between h.264 and h.265 at youre own leisure without any loss
<aaabbb>
there will always be loss
<evilscreww>
and ffmpeg allows lossless h.265/4 conversions ?
<evilscreww>
really? !
<aaabbb>
yes, but the filesize will grow like 500x
<evilscreww>
seems to be only double for me
<evilscreww>
could be VFR
<aaabbb>
lossy -> lossless will always be a huge huge file increase
<evilscreww>
the only time you seem to lose quality is if you throw the clips into samsungs native video editor and export it
<aaabbb>
if you are doing lossy -> lossy then there will always be a quality loss, but it might be so little that you can't tell
<evilscreww>
i have to double check all this now.
<evilscreww>
because some of my clips ive changed between h.264 and h.265 just to experiment
<aaabbb>
there are some types of formats, called mezzanines, which are designed to be resistant to generation loss. they are meant to be able to be edited dozens of times without any noticible loss
<evilscreww>
clips i didnt want loss on
<aaabbb>
if you've changed from h264 to h265 then you've lost quality. if the h265 is bigger then not only have you lost quality, you also lost compression efficiency
<evilscreww>
mezzanine? i thought that was the second level of a theatre 😅
<evilscreww>
how certain are you of this?
<aaabbb>
yeah but that's also the name for a type of codec (also called "intermediate codec")
<aaabbb>
certain that h264 -> h265 is lossy? 100%
<evilscreww>
groan ok. i have to take another look at these
<evilscreww>
what i read all over google was wrong then. they said h.265 gives you the same quality if not better than h.264 but in a lower file-size
<evilscreww>
smaller* file-sze
<aaabbb>
evilscreww: that's true, from the perspective of "original lossless -> h264" is not going to be as good at the same file size as "original lossless -> h265"
<evilscreww>
you mean *if i filmed it in h265*
<evilscreww>
in the first instance
<aaabbb>
exactly
<evilscreww>
ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
<evilscreww>
kk ......................
<aaabbb>
or a mezzanine format (which is virtually lossless) -> h265
<aaabbb>
which is how it is done in professional situations
<evilscreww>
this begs the question, what if you took h.264 > converted it to some lossless format like .flac > then re-converted it back to h.265
<aaabbb>
flac is audio only
<evilscreww>
sorry i know flac is for audio but the video equivalent
<evilscreww>
i read about it the other day i forgot the name
<aaabbb>
h264 -> ffv1 (an example lossless video format) -> h265 is literally identical to h264 -> h265
<evilscreww>
yeh thats the one
<aaabbb>
because internally h264 -> h265 is, in reality, h264 -decoded-> raw video -encoded-> h265
<aaabbb>
the h264 -decoded-> raw part is lossless, but the raw -encoded-> h265 is what is lossy
<evilscreww>
for the time thats being i may just forget about mezzanine for now
<evilscreww>
and just look at what ive done here because samsung also allows you to revert clips back to normal
<evilscreww>
also ill just work with my h264 clips
<evilscreww>
and just change my camera settings for now
<evilscreww>
you can also download a lossless video recorder if im feeling really adventarous
<aaabbb>
"revert" might just be another lossy conversion...
<evilscreww>
it could be but im doubtfull but i can run a test clip
<aaabbb>
lossless recorder is pointless, the file size will be huuuuuge (probably so big that your phone is not able to physically save it fast enough)
<evilscreww>
it allows you to undo any changes you made
<evilscreww>
aaabbb: this is true but worth experimenting i feel
<evilscreww>
i may be able to get something that will give me more robust quality
<evilscreww>
even if its av1 or somthing
<evilscreww>
or do i need special hardware requirements
<aaabbb>
av1 is good for a distribution format, it is so slow to convert that (usually) it is better to use another format firt
<aaabbb>
what you usually want to do is use a format with a very fast preset, but a very low crf (very high bitrate), then convert that slowly into a distribution-ready file
<aaabbb>
the reason is simply that your phone won't be able to create a high-quality video at a reasonable bitrate in real time
<aaabbb>
so you have to go through a lossy step eventually, unless you want to distribute the unnecessarily huge files directly (which is fine if you are just uploading them to youtube)
Tinos has joined #ffmpeg
Juest has quit []
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
<evilscreww>
aaabbb: what time is it for you?
Juest has joined #ffmpeg
<aaabbb>
hammer time
AbleBacon has quit [Read error: Connection reset by peer]
<evilscreww>
aaabbb: how about h265 > h264 - that lossy?
<FlorianBad>
First, is "REALD 3D" the only 3d version or the two others are also 3D?
<evilscreww>
EDIT: Per /u/Exod124's comment, x265 does indeed have a lossless flag (explained here) but the resulting file size will be at least as large or larger than the source x264 file. I kind of skipped over that bit thinking you wanted smaller file size, not larger. But if you decide you don't care about getting larger files then yes there is a way to do lossless x265.
Marth64 has joined #ffmpeg
<Marth64>
Is only AVFMT_FLAG_SHORTEST (-fflags shortest) deprecated or is -shortest deprecated too?
<Marth64>
(are they the same?)
<Marth64>
nvm think I see now :)
<aaabbb>
evilscreww: yes, using lossless mode for x264 or x265 will maaaaassively blow up the file size
<aaabbb>
for something that is already lossy
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg
markizano has quit [Ping timeout: 264 seconds]
markizano has joined #ffmpeg
FH_thecat has quit [Quit: Leaving]
Mister_D has quit [Ping timeout: 252 seconds]
<evilscreww>
aaabbb: understood
evilscreww has quit [Remote host closed the connection]
ppw has joined #ffmpeg
FH_thecat has joined #ffmpeg
<ppw>
how important is NUMA support when encoding with x265?
Ox7C5_ has joined #ffmpeg
<ShaedS>
hey
<ShaedS>
how do I add a black boarder of 35px at the top of my video, shifting everything down and truncating the overflow?
<aaabbb>
ppw: /3
<aaabbb>
ppw: i don't think very if you don't have multiple nodes
<aaabbb>
there's some documentation of that on readthedocs lemme find it
<aaabbb>
so if you have multiple cpu sockets and want to use more than one at once with x265 then you will need numa support otherwise not
<ppw>
aaabbb: right, thanks
<psykose>
having multiple numa nodes and an x265 without numa awareness doesn't stop it from using all of them anyway, and you can always use numactl to the same effect too
<psykose>
the feature is not very meaningful
<aaabbb>
btw if you DO have multiple numa nodes (or a lot of threads), you don't get as much parallization benefit without hits in compression efficiency
<psykose>
the #1 use of it is to run multiple encodes on separate numa domains so they don't clash, but numactl lets you do that already so
<aaabbb>
it would be better to encode 8 videos with 2 threads each than 1 video at a time with 16 threads
<psykose>
yea
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg
Juest has quit []
e^pi-1 has quit [Ping timeout: 260 seconds]
Juest has joined #ffmpeg
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg
e^pi-1 has joined #ffmpeg
<ShaedS>
im struggling to figure outr the syntax of it i know ffmpeg vcan do this losslessly
Starz0r has quit [Ping timeout: 260 seconds]
Starz0r has joined #ffmpeg
Marth64 has quit [Ping timeout: 246 seconds]
Marth64 has joined #ffmpeg
fling has quit [Ping timeout: 260 seconds]
Tinos has quit [Remote host closed the connection]
fling has joined #ffmpeg
andrewrk has quit [Ping timeout: 256 seconds]
junaid_ has joined #ffmpeg
Marth64 has quit [Ping timeout: 252 seconds]
Marth64 has joined #ffmpeg
Muimi has joined #ffmpeg
SystemError has quit [Remote host closed the connection]
<ppw>
gosh, why do VOB files have to be such low-quality
<JEEB>
8 megabits per second, but average over 1.5 megabits :P
<JEEB>
1.5 / 8 is... ~0.1875 seconds :P
<JEEB>
in other words it just lacks the capability to distribute those bits
<ppw>
I keep wondering about the various tricks DVD players must employ to make it look good
<JEEB>
blu-ray of course bumped the bit rate to 40 mbps, but also the buffer is that amount, so you can distribute it over a whole second.
Haripesch has quit [Ping timeout: 250 seconds]
SystemError has quit [Remote host closed the connection]
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg
Ox7C5_ has quit [Ping timeout: 260 seconds]
Juest has quit []
Tinos has joined #ffmpeg
<ppw>
I think it also has to do something with the fact that it's in 720x480 and the SAR being 32:27
Ox7C5_ has joined #ffmpeg
five61848033 has quit [Remote host closed the connection]
five61848033 has joined #ffmpeg
Juest has joined #ffmpeg
Blacker47 has joined #ffmpeg
<JEEB>
ppw: I mean 8mbps with 1.5 megabit buffer is just enough for even a lot of 720x480 or 720x576 content
<noobaroo>
For a NSFW video when preserving the detail of the skin and private areas, is "-svtav1-params tune=0:enable-tf=0:film-grain-denoise=0:film-grain=0" better to use?
<JEEB>
better ask that from SVT-AV1 project itself
<noobaroo>
Do they have a channel on libera?
<JEEB>
#svt or so I think
<noobaroo>
Thanks
<noobaroo>
I didn't know there was an SVT-HEVC. It's not in ffmpeg by any chance?
<JEEB>
no, it's pretty much dead
<JEEB>
and they never really pushed that patch for it into FFmpeg
<JEEB>
they clearly did a source dropped of SVT-HEVC, and then only had interest in continuing with only SVT-AV1
<JEEB>
there also was a SVT-VP9 if I recall correctly
<noobaroo>
Is SVT-VP9 any good?
lavaball has joined #ffmpeg
<BtbN>
Everything that isn't SVT-AV1 is dead
vlm has joined #ffmpeg
<ppw>
JEEB: I'm trying to say that the fact that it's 720x480 that's artificially stretched out because of its metadata makes it look worse than it really is
<aaabbb>
anamorphic isn't necessarily worse
<aaabbb>
there are plenty of other reasons it looks like crap and beig 720x480 sar 32:27 isn't what makes it awful :p
<ppw>
but it looks so much blockier unless I set sar to 1:1 and resize it to 854:480
<aaabbb>
sounds like a scaling problem
<galad>
that depends on your player upscaling abilities
<aaabbb>
if your player is using nearest neighbor then it would look block as hell
<galad>
but sdr video is anamorphic because crt were anamorphic
<aaabbb>
ppw: in a sense, playing it back with sar 32:27 is basically the same as setting sar 1:1 and then scaling it to 854:480, except without reencoding
<aaabbb>
so if it looks better when you reencode it then that's because ffmpeg's default scaling algo bicubic is better than whatever your video player is using
<ppw>
have you forgotten already that I patched it to use lanczos as the default? :)
<aaabbb>
well lanczos and bicubic are both much better than whatever your player is using :p
<ppw>
yeah, I don't know what mpv's default is.
<aaabbb>
oh mpv? it shouldn't be using anything crappy that makes it look blocky
<aaabbb>
you can change what mpv uses tho
Marth64 has quit [Ping timeout: 256 seconds]
Marth64 has joined #ffmpeg
lexano has joined #ffmpeg
Haripesch has joined #ffmpeg
raccct has joined #ffmpeg
devinheitmueller has joined #ffmpeg
minimal has joined #ffmpeg
Juest has quit [Read error: Connection reset by peer]
Juest has joined #ffmpeg
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Marth64 has quit [Ping timeout: 268 seconds]
Marth64 has joined #ffmpeg
enyc has joined #ffmpeg
ppw has left #ffmpeg [#ffmpeg]
Marth64 has quit [Ping timeout: 255 seconds]
Marth64 has joined #ffmpeg
Tinos has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
vlm has quit [Quit: Leaving]
evilscreww has joined #ffmpeg
Hackerpcs has joined #ffmpeg
microchip__ has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
microchip_ has quit [Ping timeout: 260 seconds]
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
evilscreww has quit [Ping timeout: 250 seconds]
Marth64 has quit [Ping timeout: 260 seconds]
microchip__ is now known as microchip_
Hackerpcs has joined #ffmpeg
MrZeus has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
vlm has joined #ffmpeg
five61848033 has quit [Remote host closed the connection]
five61848033 has joined #ffmpeg
Hackerpcs has joined #ffmpeg
Haripesch has quit [Quit: Client closed]
Haripesch has joined #ffmpeg
<noobaroo>
I just uninstalled my ffmpeg and installed BtBn 6.1 shared LGPL build and now libsvtav1 is running 3-6x faster on the exact same settings?
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg
raccct has quit [Quit: Client closed]
ppw has joined #ffmpeg
MrZeus has quit [Read error: Connection reset by peer]
Haripesch has quit [Quit: Client closed]
MrZeus has joined #ffmpeg
Haripesch has joined #ffmpeg
Hackerpcs has quit [Quit: Hackerpcs]
yans has joined #ffmpeg
vlm has quit [Remote host closed the connection]
ZedHedTed has left #ffmpeg [#ffmpeg]
five61848033 has quit [Remote host closed the connection]
five61848033 has joined #ffmpeg
<noobaroo>
Does BtBN ffmpeg 6.1 LGPL shared not have a libx265 encoder?
<BtbN>
x264/5 are GPL-only
<noobaroo>
Oh
e^pi-1 has quit [Quit: WeeChat 4.2.1]
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
beaver has quit [Remote host closed the connection]
Hackerpcs has joined #ffmpeg
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg
MrZeus_ has joined #ffmpeg
rv1sr has joined #ffmpeg
MrZeus has quit [Ping timeout: 272 seconds]
MrZeus__ has joined #ffmpeg
MrZeus__ has quit [Read error: Connection reset by peer]
MrZeus_ has quit [Ping timeout: 272 seconds]
MrZeus has joined #ffmpeg
Tano has quit [Quit: WeeChat 4.1.2]
devinheitmueller has quit [Ping timeout: 256 seconds]
AbleBacon has joined #ffmpeg
j45 has quit [Ping timeout: 260 seconds]
j45 has joined #ffmpeg
MrZeus has quit [Read error: Connection reset by peer]
MrZeus has joined #ffmpeg
<kepstin>
note that libx264 and libx265 are external libraries used by ffmpeg, ffmpeg does not have a built-in encoder for h264 or h265.
Marth64 has joined #ffmpeg
<kepstin>
(ffmpeg can alternately encode using cisco's openh264, but that isn't nearly as good of an encoder as libx264; the only other option is to use hardware encoders)
kasper93_ has joined #ffmpeg
Traneptora has quit [Quit: Quit]
kasper93 has quit [Ping timeout: 268 seconds]
beaver has joined #ffmpeg
MrZeus has quit [Read error: Connection reset by peer]
junaid_ has quit [Quit: Lost terminal]
Tano has joined #ffmpeg
Juest has quit [Read error: Connection reset by peer]
lavaball has quit [Remote host closed the connection]
kasper93_ is now known as kasper93
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #ffmpeg
MrZeus has joined #ffmpeg
<realies>
is pan=stereo|FL=1*ch0|FR=1*ch1 going to clip if both ch0 and ch1 are at full amplitude but not clipping?
<realies>
or that has to be 0.5*
blb has quit [Ping timeout: 260 seconds]
blb has joined #ffmpeg
Traneptora has quit [Quit: Quit]
Narrat has joined #ffmpeg
Traneptora has joined #ffmpeg
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #ffmpeg
iive has joined #ffmpeg
s55 has quit [Ping timeout: 252 seconds]
s55 has joined #ffmpeg
lavaball has joined #ffmpeg
JanC_ has joined #ffmpeg
JanC has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
JanC_ is now known as JanC
MrZeus has quit [Read error: Connection reset by peer]
<Marth64>
is it a strange perception to see SEI as bloat/unnecessary? (except for HDR). I strip all of it out in my local library of sources due to some paranoia that its unnecessary for my needs and I don't like the idea that some decoder down the road can parse unregistered user data and go do nefarious things. am I overthinking it?
<Marth64>
or just curious to other opinions
<Marth64>
the only valuable things in it I can think of are closed captions (which can be extracted out into an actual subtitle stream of bytes) or HDR
<JEEB>
there's not enough of it usually to be offensive for me
rvalue has quit [Ping timeout: 252 seconds]
rvalue has joined #ffmpeg
<noobaroo>
My h264_vaapi encoder doesn't work anymore
<noobaroo>
The only thing I did is switch to BtBN build, could that be why?
fossdd has joined #ffmpeg
<CounterPillow>
Marth64: The H.264 decoder specifically applies some workarounds based on the SEI in one specific pixel format if I recall correctly. I would not strip it.
<Marth64>
hmm...thanks, CounterPillow. that's worrisome. I'll do some research
<CounterPillow>
Maybe JEEB remembers what I'm talking about, iirc it broke a bunch of fansub releases because they stripped their sooper secret x264 settings
<Marth64>
in a lot of my OTA records there comes a lot of junk in the sei like parental guidance rating and data i don't recognize which is what bothered me
<Marth64>
yes i'd love to hear the background on that
<JEEB>
the lossless H.264 spec changed during the years and the second iteration had a boog in x264
<Marth64>
ahhh, it was with lossless 264?
<JEEB>
thus it looks up the x264 version from the SEI
<Marth64>
ahh
<JEEB>
and the decoder actually has both old and new logic
<CounterPillow>
Right, --vd-lavc-assume-old-x264 was added for the x264 boog
<Marth64>
appreciate you both, i'll check this out and use it to weigh in on when to strip the data vs. not
<CounterPillow>
(in mpv)
<Marth64>
i am fortunately not using lossless 264 or 3d stereo either and most of my stuff is yuv420p
<CounterPillow>
If there's a way to strip everything but the used encoder and its settings, that would probably be my recommendation. Saves you from accidentally disclosing unintended personally identifiable information but still allows for future decoder hacks and general "provenance" of the files I guess
<CounterPillow>
(Though even the precise version of x264 used can be revealing who's behind a certain file :))
<JEEB>
the bsf I think has an int-based filtering thing
yans has quit [Ping timeout: 252 seconds]
<Marth64>
I don't participate in sharing or things like that so I'm ok there, and the encode settings don't have preservation meaning to me. I think I am just after consistency in my library and some semblance of cleanliness. I remux and tag everything I collect so the bsf gets applied during the remux
<Marth64>
Thanks for calling out that issue above, that's exactly the type of thing I was afraid of by stripping it (ensuring the video still plays right).
<Marth64>
One of the reasons I wrote RCWT (de)muxer was to get the closed captions out into their own archicable stream proper.
<Marth64>
I hate that they are nested in SEI
rv1sr has quit []
vulpine has quit [Quit: Connection reset by purr]
fossdd has quit [Ping timeout: 272 seconds]
vulpine has joined #ffmpeg
<noobaroo>
Well I switched back to the old ffmpeg I was using and vaapi works now, but is there a way to set the speed/quality tradeoff like "-speed slow"? I'm encoding at 9x and getting terrible quality, I'm using "-qp 23"
<noobaroo>
Also, on a different note, my TV box always stretches 2.35:1 videos to fit the 1.78:1 screen, I can't for the life of me figure out how to preserve aspect ratio when playing videos on my TV. Is there a way with ffmpeg to artificially add black bars on the top and bottom of the video?
<noobaroo>
What really sucks is I had some TV episodes where they had black bars on the top and bottom, and it annoyed me and I used ffmpeg to crop them away. Now I wish I had the original videos because they would play on my TV with the correct aspect ratio :/
Ox7C5_ has quit [Quit: Lost terminal]
beaver has quit [Remote host closed the connection]
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
Haripesch has quit [Ping timeout: 250 seconds]
MrZeus has quit [Read error: Connection reset by peer]
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
<Marth64>
noobaroo: for point (1) which codec is this? you are probably looking for -preset
<Marth64>
for point (2) if your TV box is always streching them despite you setting the correct aspect, that is a fault with the TV box. but most should have a Zoom setting or toggle to turn it off, unless your file does not have the correct aspect set
<Marth64>
you can always add the black bars back "artifically" but that would require an encode
<noobaroo>
Marth64 h264_vaapi -preset is not supported
<noobaroo>
Yeah, the TV box sucks.
<noobaroo>
"you can always add the black bars back "artifically" but that would require an encode"
<noobaroo>
That's what I want to do
<Marth64>
pad filter is what you need
<Marth64>
i have not used vaapi unfortunately but i assume you have seen all the options available in `ffmpeg -h encoder=h264_vaapi`
<Marth64>
also IIRC vaapi is wrapper to more configurable APIs, what type of GPU is it?
<JEEB>
vaapi is a wrapper to vaapi drivers :)
<JEEB>
intel and amd provide native vaapi drivers
<Marth64>
ahh
<Marth64>
if its intel maybe you can switch to h264_qsv , i know it has -preset
<Marth64>
am not sure about amd :(
<JEEB>
then you have some other things that attempt to map other APIs to vaapi (such as vdpau etc)
<noobaroo>
Yeah it's intel, do you use h264_qsv? I haven't got it to work at all for me
<noobaroo>
which is better, h264_vaapi or h264_qsv?
<noobaroo>
h264_vaapi works fine for me, I just wish there was a way to slow it down
<noobaroo>
There has to be a speed/quality tradeoff setting, no one knows what it is?
<Marth64>
it sounds like they fill different purpose .. vaapi wraps around so you don't have to deal with vendor headaches, qsv has intel-specific config options
<Marth64>
i have qsv it before but i remember it being very particular with the drivers
<Marth64>
i'm an nvenc guy, sorry i don't have a ez answer
<Marth64>
how i interpreting what JEEB is saying is that vaapi is more generic, so you can run the same command kinda portably across systems...so i'm not surprised if it doesn't have a lot of options
<Marth64>
if you're not going to be moving off intel anytime soon, qsv might be worth another go
five61848033 has quit [Remote host closed the connection]