ChanServ 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.1.1 is released
nurupo has quit [Quit: nurupo.ga]
nurupo has joined #ffmpeg
JanC has joined #ffmpeg
JanC has quit [Killed (iridium.libera.chat (Nickname regained by services))]
DestinyB has joined #ffmpeg
someuser has joined #ffmpeg
anotheruser has joined #ffmpeg
someuser has quit [Read error: Connection reset by peer]
Ingvix has quit [Read error: Connection reset by peer]
derpydoo has joined #ffmpeg
Ingvix has joined #ffmpeg
CHR0N0S has joined #ffmpeg
foul_owl has quit [Read error: Connection reset by peer]
<CHR0N0S>
Does ffmpeg support CMake build systems?
f0x_3033691271 has quit [Read error: Connection reset by peer]
Shine_ has quit [Read error: Connection reset by peer]
cantelope has quit [Quit: Connection closed for inactivity]
f0x_3033691271 has joined #ffmpeg
foul_owl has joined #ffmpeg
<another|>
No.
<grib>
CHR0N0S: What do you mean by "support"? Do you want to use CMake to *build* ffmpeg? There are some forks that do that, but nothing official.
derpydoo has quit [Quit: derpydoo]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Remote host closed the connection]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Remote host closed the connection]
flotwig_ has joined #ffmpeg
flotwig has quit [Ping timeout: 248 seconds]
<grib>
Do you mean you have a CMake-based project of your own and you want to *build against* ffmpeg libraries? ffmpeg produces pkg-config files (.pc) that CMake can use (through FindPkgConfig).
xx has joined #ffmpeg
mark4o has joined #ffmpeg
markh has quit [Read error: Connection reset by peer]
mark4o is now known as markh
emmanuelux has quit [Read error: Connection reset by peer]
Guest53 has joined #ffmpeg
Guest53 has quit [Client Quit]
Starz0r has quit [Quit: It is now safe to turn off your computer.]
Starz0r has joined #ffmpeg
MyTDT_ has joined #ffmpeg
MyTDT_ has quit [Remote host closed the connection]
MyTDT_ has joined #ffmpeg
SuicideShow has quit [Ping timeout: 268 seconds]
Shine_ has joined #ffmpeg
SuicideShow has joined #ffmpeg
Sketch has quit [Remote host closed the connection]
Sketch has joined #ffmpeg
Blacker47 has joined #ffmpeg
olndrxyz has joined #ffmpeg
<ninjin>
Transcoding question as I am finding at times that my CBR to VBR transcodes ends up being larger than the original CBR. If I am transcoding from CBR to VBR with the same codec, can I reasonably set the max bitrate for the transcode to the same as what was used for the CBR? Yes, I know it most likely comes with caveats in that one also ideally should have the same buffer size.
<ninjin>
On a related note. Is there a book on video encoding and/or ffmpeg that is recommended? I find it hard to build a mental model just from the documentation and anything other than the ffmpeg documentation online is usually not great and web searchers tend to come up with utter rubbish most of the time.
<galad>
what's the advantages of reencoding a video at exactly the same bitrate?
<galad>
it doesn't make sense
<ninjin>
Agreed, but what I am doing is going from CBR to VBR. It is just that I am not setting the *max* bitrate for the VBR, so at times it goes into a higher bitrate than the original (I am not good enough at this to elaborate as to why).
<ninjin>
I am using H.264 and the YouTube guidelines as my settings if that is useful to know.
<galad>
by vbr do you mean you set an average bitrate, a a constant quality or constant rf?
<ninjin>
CRF, sorry, should have used that term from the start.
<galad>
then maybe try a lower RF
<galad>
woops
<galad>
I mean higher
<ninjin>
I can. But is it not possible to arrive at some sort of "set it and forget it" if you know the bitrate of the CBR? It takes a good 30 minutes to do a transcode and I am happy not to have optimal outcomes as I discard videos after a while, but I very much do not want to search for a different RF value depending on the source video.
<ninjin>
Do tell me if I am naive here, because although I am no longer a complete novice I do not have a deep technical understanding of all parts of the process.
duckworld has quit [Remote host closed the connection]
duckworld has joined #ffmpeg
rsx has joined #ffmpeg
<galad>
unfortunately there is no set and forget, if your setting gets you a bigger file than the source, it means you just lost quality and time
<galad>
and even if you set a max bitrate, you could still get a file with the same size and less quality
<ninjin>
Thanks, I *really* need to get a text book on this as I find it hard to build a mental model about what exactly one ends up decoding in a situation like that. It is fascinating as someone that thought they understood compression.
duckworld has quit [Remote host closed the connection]
duckworld has joined #ffmpeg
<ninjin>
I have a recording of a Doom playthrough for example that increases in size by 50%!
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
JanC has joined #ffmpeg
JanC is now known as Guest7149
Guest7149 has quit [Killed (mercury.libera.chat (Nickname regained by services))]
olndrxyz has quit [Remote host closed the connection]
olndrxyz has joined #ffmpeg
olndrxyz has quit [Read error: Connection reset by peer]
olndrxyz has joined #ffmpeg
Thulinma has joined #ffmpeg
coldfeet has joined #ffmpeg
user_oreloznog has quit [Ping timeout: 244 seconds]
user_oreloznog has joined #ffmpeg
xx has quit [Ping timeout: 264 seconds]
xx has joined #ffmpeg
coldfeet has quit [Quit: Lost terminal]
JanC has joined #ffmpeg
JanC is now known as Guest5413
Guest5413 has quit [Killed (copper.libera.chat (Nickname regained by services))]
le_patenteux has joined #ffmpeg
olndrxyz has quit [Quit: Quit]
lavaball has joined #ffmpeg
Shine_ has quit [Read error: Connection reset by peer]
^Neo has joined #ffmpeg
^Neo has joined #ffmpeg
^Neo has quit [Changing host]
JavaBean has quit [Ping timeout: 260 seconds]
JavaBean has joined #ffmpeg
stolen has quit [Quit: Connection closed for inactivity]
vlm has quit [Remote host closed the connection]
JavaBean has quit [Ping timeout: 276 seconds]
vlm has joined #ffmpeg
\\Mr_C\\ has joined #ffmpeg
vlm has quit [Ping timeout: 276 seconds]
JanC has joined #ffmpeg
JanC has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
Shine_ has joined #ffmpeg
Flat has quit [Ping timeout: 245 seconds]
fling has quit [Ping timeout: 264 seconds]
<kepstin>
ninjin: thus is the peculiarities of lossy compression.
<kepstin>
keep in mind that each time you re-compress a video, the new compressor has no idea about any of the properties of the previous compression. it's given the decoded result of the previous video, and has to make new decisions based on the video it was given and the settings you provided. This also means that if the previous compression added compression artifacts, the new compressor will try to preserve those as if they were important parts of the video.
<kepstin>
with x264 you can either use a 2-pass encode with a bitrate to get an output video with whatever size you like, but with unpredictable quality - or use crf mode to get an output video with whatever quality you like but unpredictable size.
<furq>
the title of and comment in that paste imply this is for youtube
<furq>
in which case you should just not do this at all
<furq>
unless you have terribly slow upload speeds
tranzistor has quit [Quit: Ping timeout (120 seconds)]
tranzistor has joined #ffmpeg
<kepstin>
ah, true. with youtube you generally just want to send them the best quality you have and avoid adding an extra generation loss when possible. They have two sets of guidelines for video encoding - the guidelines for livestreams are important, of course, but the guidelines for VOD uploads are there just to optimize their video processing speed.
<furq>
yeah those are mostly for your convenience and occasionally for their convenience
<furq>
but they'll accept almost anything
<kepstin>
iirc someone figured out what version of ffmpeg they were using for video ingest a while back based on the presence of a decoder bug on some obscure format.
<kepstin>
(that was many years ago, and youtube has probably changed things since then)
<kepstin>
the guidelines for uploading hdr content are kinda important, but that's mostly regarding the metadata so youtube correctly recognizes the hdr rather than details of video bitrate/encoder decisions.
<furq>
i hope this doom 2 playthrough isn't in hdr
JanC has joined #ffmpeg
JanC has quit [Killed (osmium.libera.chat (Nickname regained by services))]
FlorianBad has quit [Remote host closed the connection]
FlorianBad has joined #ffmpeg
JanC is now known as Guest7545
JanC has joined #ffmpeg
Guest7545 has quit [Killed (copper.libera.chat (Nickname regained by services))]
Flat has joined #ffmpeg
vulpine has quit [Quit: Connection reset by purr]
vulpine has joined #ffmpeg
stolen has joined #ffmpeg
hussein1 has quit [Remote host closed the connection]
hussein1 has joined #ffmpeg
hussein1 has quit [Remote host closed the connection]
compnn has quit [Read error: Connection reset by peer]
hussein1 has joined #ffmpeg
compnn has joined #ffmpeg
stolen has quit [Max SendQ exceeded]
Son_Goku has quit [Ping timeout: 276 seconds]
englishm has quit [Read error: Connection reset by peer]
englishm has joined #ffmpeg
Son_Goku has joined #ffmpeg
mindfreeze has quit [Read error: Connection reset by peer]
meinside has quit [Read error: Connection reset by peer]
mindfreeze has joined #ffmpeg
meinside has joined #ffmpeg
stolen has joined #ffmpeg
Naleksuh has quit [Ping timeout: 252 seconds]
bpmedley has quit [Ping timeout: 265 seconds]
kylophone has quit [Ping timeout: 265 seconds]
Naleksuh has joined #ffmpeg
kylophone has joined #ffmpeg
bpmedley has joined #ffmpeg
le_patenteux has quit [Quit: Konversation terminated!]
cantelope has joined #ffmpeg
emanuele6 has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
<kepstin>
for formatted subtitles with drawing commands used to replace text on screen (this is seen in some fancier anime subtitles), the subtitle updates should be aligned with frame updates.
<kepstin>
this is important to ensure that the subtitle doesn't draw over a frame that it's not intended to draw over, and that you don't get a flash of the underlying frame before the subtitle is displayed.
<BtbN>
I'd probably do that no matter what, just out of simplicity
<kepstin>
an example of where that helps is vrr displays, where having subtitle updates aligned to video frames means that you can get more consistent frame display times.
emanuele6 has quit [Quit: WeeChat 4.4.3]
<moi15moi>
@BtbN To me, it matters. See this issue: https://github.com/androidx/media/issues/2289. I tried to explain there why, in my opinion, it should use frame timestamps, but I wanted another opinion
<moi15moi>
@kepstin Whem you are talking about anime subtitles, I guess you are refering to ssa/ass subtitle. Do you know if I should use frame timestamps for any subtitle format or only .ass?
<BtbN>
Just aligning it with frames is much simpler by default
<BtbN>
specially with 60 fps video, and most people having 60Hz displays, that's as good as it gets anyway
<kepstin>
if you have to do it sometimes, it would probably simplify your code to be uniform for all formats
<kepstin>
subtitles are actually timed to audio in general, but there's honestly quite a lot of wiggle room in audio-timed subtitles such that the precise display time simply doesn't matter
<kepstin>
so aligning to frames, which will only be a small number of ms difference in general, is not something anyone will notice
<moi15moi>
I mean, in a case of typesetting, even if it's only 1 frame early/late, you can easily see it.
<moi15moi>
But there isn't any consensus on how it should be done?
YUiNA_ has joined #ffmpeg
<moi15moi>
Oh, my bad with my note of typesetting. I didn't read correctly ^^'
<kepstin>
ah, yeah, one trick with even audio-timed subtitles is that if a subtitle change happens close to a scene change, you want to align the subtitle change frame-precisely with the scene change. it's really distracting if the subtitle shows up a few ms before or after a scene change.
Guest4371 has joined #ffmpeg
YUiNA has quit [Ping timeout: 244 seconds]
Guest9770 has joined #ffmpeg
Guest9770 has quit [Client Quit]
Shine_ has quit [Read error: Connection reset by peer]
Guest4371 has quit [Ping timeout: 240 seconds]
phantomics_ has quit [Ping timeout: 276 seconds]
<moi15moi>
Ok, thanks. I guess the answer is "use frame timestamps" since it allow to have the precision we need for ass/ssa subtitle and also avoid scene bleeding for other format.
phantomics has joined #ffmpeg
<CHR0N0S>
grib: yes I meant I want to build a project linking against ffmpeg with CMake
___nick___ has joined #ffmpeg
___nick___ has quit [Client Quit]
___nick___ has joined #ffmpeg
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
stolen has quit [Quit: Connection closed for inactivity]
Kadigan has joined #ffmpeg
k777_ has quit [Ping timeout: 276 seconds]
k777 has quit [Ping timeout: 276 seconds]
k777__ has quit [Ping timeout: 276 seconds]
Kadigan has left #ffmpeg [#ffmpeg]
hussein1 has quit [Ping timeout: 264 seconds]
hussein1 has joined #ffmpeg
lemourin3 has joined #ffmpeg
lemourin is now known as Guest7222
lemourin3 is now known as lemourin
Guest7222 has quit [Killed (osmium.libera.chat (Nickname regained by services))]
five618480339176 has joined #ffmpeg
System_Error has quit [Remote host closed the connection]
CHR0N0S has quit [Quit: CHR0N0S]
CHR0N0S has joined #ffmpeg
peacefight has quit [Remote host closed the connection]
<CHR0N0S>
Okay I've setup my CMakeLists.txt file to create libraries and include directories properly with ffmpeg, it wasn't so bad actually! Except, now it seems like when I try to include and link against `libavutil`, it breaks a standard header file `#include <iostream>`
k777 has joined #ffmpeg
peacefight has joined #ffmpeg
k777_ has joined #ffmpeg
<CHR0N0S>
I'm getting the following error which stems from my `#include <iostream>`: `/usr/include/pthread.h:244:34: error 'clockid_t' has not been declared`
k777__ has joined #ffmpeg
<psykose>
post code
<CHR0N0S>
Where's a good place to do that
Flat has quit [Ping timeout: 245 seconds]
Flat has joined #ffmpeg
manwithluck has quit [Remote host closed the connection]
Brazhh has quit [Ping timeout: 248 seconds]
xx has quit [Remote host closed the connection]
System_Error has joined #ffmpeg
manwithluck has joined #ffmpeg
<CHR0N0S>
looks like my library includes are being sent to g++ with `-isystem` which seems like a bad idea
<CHR0N0S>
Even getting it to change to `-I/usr/include/ffmpeg/libavutil` gets this #include <iostream> to fail
emmanuelux has joined #ffmpeg
DauntlessOne45 has joined #ffmpeg
DauntlessOne4 has quit [Ping timeout: 248 seconds]
DauntlessOne45 is now known as DauntlessOne4
usagi_mimi has quit [Ping timeout: 268 seconds]
usagi_mimi has joined #ffmpeg
Flat has quit [Ping timeout: 252 seconds]
<CHR0N0S>
I think I figured out what needs to be done. Instead of including the path to each library include directly (which breaks STL includes), I will only include the path to `/usr/include/ffmpeg`
Flat has joined #ffmpeg
Flat_ has joined #ffmpeg
Flat has quit [Ping timeout: 248 seconds]
lavaball has quit [Remote host closed the connection]
minimal has quit [Remote host closed the connection]
minimal has joined #ffmpeg
derpydoo has quit [Quit: derpydoo]
moi15moi has quit [Quit: Leaving]
fling has quit [Ping timeout: 264 seconds]
k777_ has quit [Ping timeout: 265 seconds]
k777 has quit [Ping timeout: 265 seconds]
k777__ has quit [Ping timeout: 272 seconds]
k777 has joined #ffmpeg
k777_ has joined #ffmpeg
k777__ has joined #ffmpeg
Brazhh has joined #ffmpeg
k777 has quit [Ping timeout: 260 seconds]
\\Mr_C\\ has quit [Remote host closed the connection]
bertieb has quit [Ping timeout: 268 seconds]
averne_ has joined #ffmpeg
averne has quit [Ping timeout: 252 seconds]
acidbunny has joined #ffmpeg
averne_ is now known as averne
wobbol has quit [Ping timeout: 265 seconds]
TheSilentLink has quit [Ping timeout: 276 seconds]
bertieb has joined #ffmpeg
<BtbN>
passing library includes via -isystem is standard and nothing wrong with it
<BtbN>
And if you are using C++, you need to guard ffmpeg headers in an extern "C" {} block, since they're C, not C++.
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg
<CHR0N0S>
BtbN: Thanks. I didn't know -isystem wasn't a problem. I ended up determining that including the path such as /usr/include/ffmpeg/libavutil affected the include searching that would happen with a standard #include <iostream> for example
<CHR0N0S>
Without me directly including at all. So giving the compiler direct access like that was my user error. Instead, I just give it `/usr/include/ffmpeg` which forces those headers to still require <libavutil/header.h>