<aaabbb>
how can i get an estimate for what the crf of an hevc video would be from just the average bitrate?
<BtbN>
that's impossible
<aaabbb>
info=1 is default in x265 so i can always check that with mediainfo but not if rf=2pass
<BtbN>
also, "what the crf would be" in itself does not make sense already
<ecapi>
BtbN, you get the new mario wonder?
function1 has joined #ffmpeg
<aaabbb>
BtbN: really? but i could do it by brute force, it's just that that would take a long time
<BtbN>
The crf value only is meaningful combined with almost all other encoder settings
<aaabbb>
you're right, i shouldn't have said "from just"
<BtbN>
so "finding the crf value of a video" makes no sense. Specially given that crf is a concept of x265, not of hevc in itself.
<aaabbb>
assume i have the other settings and the video itself
<aaabbb>
and it came from x265 (or x264)
<BtbN>
I mean, if you would somehow reverse the entire encocer, you probably could derive it. But... why?
<aaabbb>
if i know the encoder settings and it uses 2 pass rate control, there's no way to find out roughly what crf would have created a file of that size/bitrate?
<aaabbb>
encoder settings and have original video*
<BtbN>
if the crf value doesn't happen to be baked into the metadata, no
<BtbN>
But again, why? The crf value isn't very useful after the fact
<aaabbb>
i'm just curious about it, if there's no way to do it other than brute force then that's ok
<aaabbb>
but i wanted to know if i had to reencode it, approximately what the crf was (or would have been if rc=crf)
<BtbN>
if you have to re-encode it, the original crf does not help you at all
<aaabbb>
i guess i still have a lot to learn
<BtbN>
Every time you re-encode it, the quality gets worse
<BtbN>
mirroring the previous settings does not mean it'll come out with the same quality
<aaabbb>
i'm aware of that at least
<furq>
if you run the first pass with the same bitrate and settings with x264 it'll print "final ratefactor" in the logs
<furq>
but whether that actually maps to crf i don't know
<furq>
and x265 doesn't do that
<aaabbb>
oh ok
<BtbN>
It's dynamically adjusting the quality per-area of the video as well, isn't it?
<aaabbb>
that's exactly what i was wondering
<BtbN>
So in the case of a two-pass, I'm not sure if it's equivalent to _any_ singular crf value
<furq>
supposedly 2-pass and crf for x264 use the exact same ratecontrol and the first pass just picks the right rf value
<furq>
but then also supposedly that's not true
<furq>
depends which forum posts you read
<aaabbb>
furq: that's exactly what i had believed
<aaabbb>
i always thought 2 pass was letting the encoder go through the video once to get an estimate of what crf is needed to reach a certain size, and then actually encoding with that crf on the second pass
Shine_ has joined #ffmpeg
<aaabbb>
since i've been downscaling a set of videos (and transcoding to hevc) to save space, i found several of them actually get larger than the h264 originals, and i found out it's because the originals are using 2 pass rate control, so some of the h264 originals are much lower quality
<aaabbb>
that's what made me curious
<BtbN>
you use 2 pass if you target a specific size. It does not automatically mean that it'll be better. Just that it's the overall best possible at the given settings for the given size
<aaabbb>
is that more or less similar to how x265 does rate control?
<aaabbb>
i think i'll use crf=24 for most of the videos, and the ones where file size inflates drastically, i'll use crf=30 instead
<BtbN>
I'd say just don't touch the ones that get bigger?
<furq>
i have no idea how x265 does it but i would expect it to be similar
<BtbN>
It probably means they are of high-complexity, and you will trash the quality
<aaabbb>
they are indeed high complexity, but they are far too big to keep
<aaabbb>
even crf=34 seems to get a good enough quality after downscaling
<aaabbb>
the videos are in a forest. are there any settings that can optimize for that if i don't care too much about the quality of forest background? it's probably a naive question, but i don't want it to spend so many bits on the leaves on trees when that's not the ponit of the video
<BtbN>
nah, encoders got no idea what a forest is
<aaabbb>
but something to reduce the number of bits spent on high frequency parts of the video wouldn't help?
<BtbN>
Super modern encoders have "area of interest" kind of things, where they can either try automatically to figure out what's most "interesting", or be fed that info externally
<aaabbb>
then an even more naive question: would it be generally better to increase the crf at 720p, or cut down to 480p but use a higher crf (when coming from a 1080p source)?
<aaabbb>
what's considered best practice?
<BtbN>
"increase or use a higher value"? :D
<aaabbb>
use a higher value lol
<BtbN>
I assume you mean lower? :D
navi has quit [Quit: WeeChat 4.0.4]
<aaabbb>
s/but use a higher crf/but user a lower crf/
<aaabbb>
i've only been using ffmpeg for a few weeks i'm still getting used to high crf and high qp means low quality xD
<BtbN>
I don't think there's a clear answer to that though
<BtbN>
it's entirely up to what you prefer
<BtbN>
cripser lower resolution, or less crisp higher
<aaabbb>
i've heard that hevc is particularly good at being optimized for high resolutions but i'm not sure if that matters in this instance
Shine_ has quit [Read error: Connection reset by peer]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
Capstan has quit [Ping timeout: 248 seconds]
minimal has quit [Quit: Leaving]
thilo has quit [Ping timeout: 258 seconds]
thilo has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
StudioUser92 has joined #ffmpeg
<StudioUser92>
Hi all.. how's everyone?
<q66>
aaabbb: mostly you want higher resolution if you can help it
<q66>
it compresses cleaner so it'll look better when scaled up while not looking worse when scaled down
<aaabbb>
got it
<aaabbb>
that's what i decided to do, i'm only reducing it to 720
<StudioUser92>
I'm new to ffmpeg and I'm trying to grab an audio stream and send it to an rtsp server. But I'm getting error "av_interleaved_write_frame(): Broken pipe; Error muxing a packet"
<StudioUser92>
this is the cmd I'm running ```ffmpeg -i http://x.x.x.x:23085/stream -acodec mp3 -f rtsp rtsp://canal90:TestStream@localhost:8554/studio```
<furq>
looks like the rtsp server is closing the connection
<furq>
i guess you'd need to check its logs if there are any
<furq>
you can try ffmpeg -v verbose as well
<furq>
also you probably want -c:a copy instead of -acodec mp3
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<StudioUser92>
furq "No more output streams to write to, finishing." Is this what you mean? This indicates that it is having a problem with the output closing connection or something?
ecapi has quit [Ping timeout: 264 seconds]
qqq has quit [Remote host closed the connection]
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg
t3xtm0de has joined #ffmpeg
t3xtm0de has left #ffmpeg [#ffmpeg]
ecapi has joined #ffmpeg
<StudioUser92>
INF [RTSP] [session 77b40756] is publishing to path 'studio', 1 track (MPEG-1/2 Audio)
<StudioUser92>
DEB [RTSP] [conn 192.168.65.1:48464] [s->c] RTSP/1.0 200 OK
<StudioUser92>
INF [RTSP] [session 77b40756] destroyed: session timed out
<StudioUser92>
I've enabled debug log on the server.. but it doesn't say anything out of the ordinary except that the connection was closed. But I still don't know why it's being terminated and if it's the client (ffmpeg) or the server
jos1 has quit [Ping timeout: 258 seconds]
<TheSashmo>
dosnt close a connection for me
<TheSashmo>
are you on wifi? @StudioUser92
<StudioUser92>
Yes, but I'm running a local docker container and doing tests
<StudioUser92>
I spun up a new container and made some changes and it's working now
maxim_d33 has quit [Ping timeout: 260 seconds]
<ecapi>
any east coasters ready to chaneg their clocks in a few?
jos1 has joined #ffmpeg
maxim_d33 has joined #ffmpeg
nillyhan has quit [Quit: anyway, read bokuyaba]
nillyhan has joined #ffmpeg
StudioUser92 has quit [Ping timeout: 248 seconds]
FH_thecat has quit [Quit: Leaving]
_yazooq has joined #ffmpeg
YuGiOhJCJ has quit [Ping timeout: 256 seconds]
yazooq has quit [Ping timeout: 252 seconds]
theobjectivedad has quit [Remote host closed the connection]
theobjectivedad has joined #ffmpeg
YuGiOhJCJ has joined #ffmpeg
lusciouslover has quit [Ping timeout: 255 seconds]
waleee has quit [Ping timeout: 260 seconds]
FH_thecat has joined #ffmpeg
_yazooq has quit [Ping timeout: 264 seconds]
Ram-Z has quit [Ping timeout: 240 seconds]
Ram-Z has joined #ffmpeg
FH_thecat has quit [Quit: Leaving]
FH_thecat has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
FH_thecat has quit [Client Quit]
FH_thecat has joined #ffmpeg
FH_thecat has quit [Quit: Leaving]
Swedaniel has joined #ffmpeg
FH_thecat has joined #ffmpeg
<Swedaniel>
Hi
dsrt^ has joined #ffmpeg
<ecapi>
hola
<Swedaniel>
how are you?
<ecapi>
ok getting ready fpr the clock change in ~20 mins
<Swedaniel>
ooh! is it clock change for everyone now?
<ecapi>
dunno about everyone but here on the us eastcoast
kmango has quit [Read error: Connection reset by peer]
<Swedaniel>
ok, cool! i think maybe it is soon time to set winter time here in europe or maybe it has allready been set im not sure
AbleBacon has quit [Read error: Connection reset by peer]
Tano has quit [Quit: WeeChat 4.0.4]
<aaabbb>
why isn't accurate_rnd and full_chroma_int the default for scaling? it doesn't seem like it has a big impact on performance
stolen has joined #ffmpeg
Muimi has joined #ffmpeg
Muimi has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Shuriko has quit [Ping timeout: 272 seconds]
DarkG has joined #ffmpeg
Ogobaga has quit [Read error: Connection reset by peer]
Ogobaga has joined #ffmpeg
mrelcee has quit [Quit: I want Waffles!]
mrelcee has joined #ffmpeg
ecapi has quit [Remote host closed the connection]
rv1sr has joined #ffmpeg
ecapi has joined #ffmpeg
lusciouslover has joined #ffmpeg
Buster__ has joined #ffmpeg
junaid_ has joined #ffmpeg
cmtaur^ has quit [Ping timeout: 245 seconds]
cmtaur^ has joined #ffmpeg
dsrt^ has quit [Ping timeout: 264 seconds]
dsrt^ has joined #ffmpeg
junaid_ has quit [Remote host closed the connection]
lusciouslover has quit [Ping timeout: 240 seconds]
Buster__ has quit [Ping timeout: 264 seconds]
junaid_ has joined #ffmpeg
junaid_ has quit [Quit: leaving]
ivanich has joined #ffmpeg
junaid_ has joined #ffmpeg
vlm has joined #ffmpeg
junaid_ has quit [Ping timeout: 255 seconds]
ivanich has quit [Remote host closed the connection]
lavaball has joined #ffmpeg
tomb^ has joined #ffmpeg
<tomb^>
Hi, I have a quictime reference files, I was wondering what would be the way to merge them and convert to an mp4... any tips?
dsrt^ has quit [Ping timeout: 240 seconds]
cmtaur^ has quit [Ping timeout: 264 seconds]
cmtaur^ has joined #ffmpeg
dsrt^ has joined #ffmpeg
flom84 has joined #ffmpeg
flom84 has quit [Remote host closed the connection]
dbal has quit [Read error: No route to host]
dbal_ has joined #ffmpeg
flom84 has joined #ffmpeg
dbal__ has joined #ffmpeg
dbal_ has quit [Ping timeout: 255 seconds]
microchip_ has quit [Quit: There is no spoon!]
microchip_ has joined #ffmpeg
microchip_ has quit [Remote host closed the connection]
microchip_ has joined #ffmpeg
ivanich has joined #ffmpeg
ivanich has quit [Remote host closed the connection]
ivanich has joined #ffmpeg
Muimi has joined #ffmpeg
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg
stolen has quit [Quit: Connection closed for inactivity]
stolen has joined #ffmpeg
flom84 has quit [Quit: Leaving]
marc|gonzalez has joined #ffmpeg
<marc|gonzalez>
Hello everyone, I recently upgraded from Ubuntu 18.04 to 22.04, and VLC has been aborting every time I try to seek.
Capstan has joined #ffmpeg
<marc|gonzalez>
Assertion !p->parent->stash_hwaccel failed at src/libavcodec/pthread_frame.c:671
<marc|gonzalez>
I suppose this problem only affects Ubuntu? (and maybe Debian)
<marc|gonzalez>
In other words, it might be an integration issue, rather than an upstream issue?
rv1sr has quit []
<marc|gonzalez>
michaelni: does this ring any bell?
<JEEB>
please do not highlight specific users
<CounterPillow>
Karen demands to speak to the manager
<JEEB>
no need to go into personalities
nina has joined #ffmpeg
TheSilentLink has quit [Quit: Good Bye! My bouncer has probably crashed or lost connection to the internet...]
<JEEB>
marc|gonzalez: the ubuntu FFmpeg was last updated in May 2022? it's not immediately clear which version that is actually. then you have VLC which is the API user. probably getting the relevant vlc/libavcodec/vaapi/vaapi module debug symbols
<JEEB>
and getting a gdb backtrace is probably your best bet
TheSilentLink has joined #ffmpeg
<JEEB>
also for the record that specific assert is on a vaapi driver that then underneath utilizes VDPAU underneath, which is less optimal than just using VDPAU or nvdec on nvidia hardware
<JEEB>
but of course there's no details on that
<JEEB>
(what the actual hardware is, and whether that module even is relevant)
<marc|gonzalez>
CounterPillow: are you calling me a Karen?
<JEEB>
just stop, I told him to stop so no reason to go on. you might have just not understood at that point that it is highly bad to highlight specific project members without there having already been a discussion
<marc|gonzalez>
JEEB: oh I thought you were talking to me that tagging Michael was "highlighting a user"
<JEEB>
yes, it was
<JEEB>
as in, most clients unless you configure otherwise will in one manner or another highlight the user