Marth64 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 is released
TheSilentLink has joined #ffmpeg
<welder>
can you briefly tell how to get it up and running?
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.]
<Xafg>
I executed the same command manually and it returned without any metadata. Very strange
<BtbN>
almost like it's not the same command than that other thing runs
<welder>
make checkasm
<Xafg>
The rest of the command is typical for Laravel so that it knows what to do with the file.
<BtbN>
well, something it does clearly messes with the metadata
<Xafg>
well, something it does clearly messes with the metadata
Xafg has quit [Quit: Client closed]
YuGiOhJCJ has joined #ffmpeg
flotwig_ has quit [Ping timeout: 252 seconds]
delthas has quit [Remote host closed the connection]
bitbinge has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
lexano has quit [Remote host closed the connection]
Sketch has quit [Remote host closed the connection]
lavaball has joined #ffmpeg
Sketch has joined #ffmpeg
jemius has joined #ffmpeg
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg
wziko has quit [Ping timeout: 252 seconds]
bitbinge has joined #ffmpeg
wziko has joined #ffmpeg
wziko has quit [Ping timeout: 265 seconds]
wziko has joined #ffmpeg
<welder>
I recall someone recently posted a link to a forum/channel (or was that discord) about developing assembly within ffmpeg, do you happen to have a link to it?
<c_14>
That's the link from the tweet anyway, not sure it's still correct
wziko has quit [Ping timeout: 265 seconds]
wziko has joined #ffmpeg
wziko has quit [Ping timeout: 248 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
DPA has quit [Ping timeout: 272 seconds]
wziko has joined #ffmpeg
wziko has quit [Ping timeout: 265 seconds]
wziko has joined #ffmpeg
wziko has quit [Max SendQ exceeded]
wziko has joined #ffmpeg
wziko has quit [Ping timeout: 264 seconds]
jemius has quit [Quit: Leaving]
minimal has joined #ffmpeg
realies has quit [Quit: ~]
StephenLynx has joined #ffmpeg
delthas_ has quit [Remote host closed the connection]
DPA has joined #ffmpeg
delthas_ has joined #ffmpeg
delthas_ has quit [Remote host closed the connection]
realies has joined #ffmpeg
wziko has joined #ffmpeg
realies has quit [Quit: ~]
flotwig has quit [Excess Flood]
Traneptora has quit [Ping timeout: 252 seconds]
flotwig has joined #ffmpeg
Marth64 has joined #ffmpeg
spuos has joined #ffmpeg
rizino has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
rizino has joined #ffmpeg
bitbinge has quit [Ping timeout: 264 seconds]
<spuos>
hey would anyone mind helping me learn some ffmpeg stuff for icecast video broadcasting? I'd go into more detail but I'm thinking of 3 different methods and I'm not sure which makes more sense
<spuos>
actually I think I can explain what I'm trying to do better
<spuos>
so basically, the end goal is to stream movie files to watch with friends, and I'm thinking of these three methods to go from file to stream
<spuos>
one: use x11grab while playing the video in mpv (I couldn't figure out a way to get alsa into the stream)
<spuos>
I'd prefer to not do it that way because it requires me to keep my laptop screen on the video and alsa grabbing would play other audio I might have in the background (not that important, I'm watching a movie)
<spuos>
two: (I'd like to do this one) bang out a ffmpeg oneliner that transcodes the video directly into a webm or other icecast-compatible format
<spuos>
the issue is my attempts here so far result in stuttering and buffering. (maybe software transcoding, maybe poor webm options chosen, I wouldn't know how to figure that out)
pyre has quit [Remote host closed the connection]
pyre has joined #ffmpeg
<spuos>
three: transcode and then stream. Probably the 'ideal' option because it would let me do a double pass and would probably be better bitrate and file size, which probably would make for a cleaner viewing experience
<spuos>
that said it would mean I need to transcode it in advance, twice. doable, but I'd like to be able to just directly toss the file onto the icecast in one line, at the time I run it
<spuos>
that's the gist of it
<spuos>
additionally, if anyone has any guides like 'so you want to become a ffmpeg wizard' I'd also love to see that
<spuos>
I could paste(bin) my ffmpeg command attempts if anyone wants to look at them
<spuos>
by the way from my mention of alsa and x11 grab you might be able to deduce I'm on linux but in case you didn't, I'm on linux, I have ~3 computers I could run the command from too. One has a fairly new AMD GPU, one has plenty of CPU, and one's a laptop that's strong enough to probably do the x11grab
wziko has quit [Ping timeout: 265 seconds]
rex has quit [Ping timeout: 244 seconds]
delthas_ has joined #ffmpeg
bitbinge has joined #ffmpeg
l4yer has quit [Ping timeout: 252 seconds]
jemius has joined #ffmpeg
e^pi-1 has quit [Quit: WeeChat 4.5.1]
realies has joined #ffmpeg
l4yer has joined #ffmpeg
l4yer has quit [Max SendQ exceeded]
spuos is now known as spuooos
spuos has joined #ffmpeg
spuooos has quit [Quit: Lost terminal]
rex has joined #ffmpeg
l4yer has joined #ffmpeg
popsch has joined #ffmpeg
<popsch>
how come "-hwaccel auto" doesn't select any of the available hardware decoders for a video? "ffmpeg -hwaccel auto -i test_h264.mp4" uses h264(native) but "ffmpeg -c:v h264_cuvid -i ..." uses the available hardware decoder. Amy I am using it wrong?
<spuos>
ooh that could be useful for my issue too
<another|>
popsch: What are you talking about?
<popsch>
another|, -hwaccel auto doesn't use the hardware acceleration when available
<another|>
Why do you think `auto` does not work?
<popsch>
because when I use "-hwaccel auto", the steam mapping shows that it uses h265 (native) instead of h265_cuvid
<another|>
`native` here doesn't mean it's not hw decoded
<popsch>
another|, but I see what it doesn't use the GPU to decode
<popsch>
I tried to simplify my command line and made that mistake.
<another|>
>[vist#0:0/h264 @ 0x55968f8cd480] [dec:h264 @ 0x55968f8c2e40] Using auto hwaccel type cuda with new default device.
<popsch>
but it doesn't list it in the stream #0.0: Stream #0:0 -> #0:0 (h264 (native) -> hevc (hevc_nvenc))
<another|>
<another|> `native` here doesn't mean it's not hw decoded
<popsch>
Ok. My mistake. Thanks a lot!
<another|>
also, if you just want to test decode, you can use the null muxer: `-f null -`
<popsch>
another|, thanks for the pointer. Btw. does "-hwaccel auto" also automatically use a hw encoder when available?
<another|>
pretty sure it doesn't
<popsch>
yes, it's what I noticed. Makes sense, because the software ones are more optimized. So it forces me to explicitly chose speed over size.
<spuos>
in case anyone missed it, I need a little help, I typed a ton up in the log but can rewrite it if anyone wouldn't mind helping me with streaming video to icecast
popsch has quit [Quit: Leaving]
lavaball has quit [Remote host closed the connection]
lavaball has joined #ffmpeg
wziko has joined #ffmpeg
bitbinge has quit [Remote host closed the connection]
iive has joined #ffmpeg
VarunAgw has joined #ffmpeg
<BtbN>
It works better to ask actual conrete questions. Just vague concepts are hard to respond to.
lavaball has quit [Quit: lavaball]
<spuos>
BtbN: I said a lot of things above, I didn't want to flood the chat again
<BtbN>
yes, and I responded to those lots of things.
<spuos>
ohhhhh
<BtbN>
At least I don't know what to tell you otherwise. If you have a concrete question, it's much better to ask that instead
<spuos>
alright so what I wanted to ask was: 1) is it realistic to transcode a mp4 into a webm/opus in real time for a livestream, 2) if I can, how do I check what part of the pipeline is causing issues for my command? 3) if it's the transcoding, how can I implement hardware encoding/decoding to make my script work
<BtbN>
Entirely depends on how powerful the CPU is.
Tano has quit [Quit: WeeChat 4.4.2]
<BtbN>
mp4 can contain a ton of things as well, but usually not vp9 or whatever you need for webm
<BtbN>
And most hw encoders can't produce vp9 either
<BtbN>
I think only Intel can?
<BtbN>
and iirc it's not great
l4yer has quit [Quit: Leaving]
<spuos>
Yeah, I was worried that my approach was fundamentally flawed, hence why I asked so many questions. Is there a way to tell if my cpu is strong enough? will enough threads suffice?
<BtbN>
if it's a half modern desktop CPU, it can probably handle it
<BtbN>
though libvpx kinda sucks and is hard to deal with
<BtbN>
Why even icecast? Isn't that for radio stuff?
<spuos>
I was running it on a m1 macbook air running linux, so maybe that's it. Besides that my desktop has a double xeon something, it's probably good
<spuos>
as for if icecast is for radio, it does both, actually. It's pretty cool
<spuos>
it supports ogg (which I know nothing about), and webm video
<BtbN>
webm is just a container
<spuos>
I think ogg is too
<BtbN>
and by "ogg for video" I guess it means theora?
<spuos>
yep
<BtbN>
If you can use VP9, that's clearly better
<BtbN>
though you could also just use an rtmp server and most likely stream your mp4 without any re-encoding.
<BtbN>
Or just throw the mp4 files onto an http server and people can stream them as they please
<another|>
I think you can also do matroska over icecas
<furq>
you can change -deadline and -cpu-used if you really want to use libvpx for live streaming
<furq>
or you could just use nginx-rtmp/mediamtx and serve h264/aac
<BtbN>
You also really want to use two-pass mode iirc, even for streaming
<BtbN>
which makes no sense, but libvpx is weird
<furq>
i don't think you can use 2-pass with -deadline realtime
flotwig has quit [Ping timeout: 252 seconds]
<furq>
also you can sort of serve h264 in mkv over icecast but it doesn't work reliably in my experience
<another|>
BtbN: yes, you want to. but how does 2pass work with live?
<furq>
last time i tried it would fail to initialise about 10% of the time
<BtbN>
You pretty much just turn it on
<BtbN>
Not actually do two passed
<furq>
once it got over that hurdle it worked perfectly
<BtbN>
*passes
<BtbN>
libvpx is just weird
<another|>
BtbN: that is true
<BtbN>
If you don't, it can't do proper rate control or something
<spuos>
wait there's a difference between vpx and vp9?
<furq>
you can probably massage that with encoder settings but why bother
<furq>
vp9 is the standard, vpx is the encoder library
<furq>
inasmuch as they wrote a standard
<furq>
same as the difference between h264 and x264
<BtbN>
libvpx pretty much is "the standard" still
<BtbN>
luckily there isn't much need for VP9 anymore, with SVT-AV1 being as good as it is, it can at the very least compete with libvpx-vp9
<spuos>
alright there's a lot to unpack, furq, I don't really want to use vpx, as much as I want to stream over icecast. Are there other (good) options for that goal? BtbN: 2-pass doesn't actually do two passes? what's rate control?
<BtbN>
libvpx is pretty much the only widely available VP9 encoder
<BtbN>
I'd say if you want to run a small private video livestream, you'll have a much happier time looking into rtmp
<another|>
others being Intel HW and eve
<spuos>
I've never heard of nginx-rtmp or mediamtx but it sounds cool. As for rtmp, I've heard of it before, but never used it. I
<furq>
i've never used mediamtx but it seems to be the popular thing nowadays
flotwig has joined #ffmpeg
<furq>
i have used nginx-rtmp and it's good but it only does rtmp which means only h264 and aac and no subtitles
<spuos>
'll bring it up with the guy who handles the icecast, but I'm unsure if that will change at any point.
<furq>
and it's kind of annoying having to set up a separate nginx instance
<spuos>
I like subtitles personally. Does rtmp not do them? What needs a separate nginx instance, nginx-rtmp?
<furq>
well i already have an nginx instance and i don't really want rtmp and the lua scripts i use for auth in my main nginx
<furq>
it used to be worse because you had to actually build a separate nginx from source and keep it separate from the distro nginx
<furq>
if i still needed to do this a lot i'd probably start with mediamtx
<BtbN>
nginx-rtmp is kinda dead sadly
<BtbN>
so if you want to stream modern codecs over rtmp, mediamtx is your better bet
<furq>
either way if you are stuck with icecast then more or less any non-ancient cpu should cope if you tune -deadline and -cpu-used
<furq>
unless you want to stream 4k60 or something
<BtbN>
flv does do subtitles, but that's not something I ever tested
<furq>
that never worked for me over rtmp
l4yer has joined #ffmpeg
<BtbN>
the server needs active support for it
<furq>
ffmpeg would mux them fine but the rtmp server just rejected the connection
<furq>
yeah
coldfeet has quit [Quit: Lost terminal]
flotwig has quit [Excess Flood]
<spuos>
does anyone mind if I paste the command I last used to try streaming?
<furq>
you'll want -row-mt or that will be singlethreaded
<another|>
vp8 is kinda meh
<furq>
oh
<furq>
yeah that only works with libvpx-vp9
<BtbN>
You will also most definitely want -re, or it'll just dump that file to icecast as fast as it possibly can
<furq>
yeah
<furq>
before -i
<spuos>
alright so if I replaced vpx with libvpx-vp9, could I add -row-mt?
<furq>
-row-mt 1
<furq>
that should probably be faster than vp8
<furq>
if it's not then add -cpu-used 4 or something
<furq>
1 is default, 8 is fastest
emanuele6 has quit [Ping timeout: 272 seconds]
emanuele6 has joined #ffmpeg
YuGiOhJCJ has joined #ffmpeg
cmc has quit [Remote host closed the connection]
cmc has joined #ffmpeg
rex has quit [Ping timeout: 248 seconds]
rex has joined #ffmpeg
Rena has quit [Quit: $WITTY_QUIT_MESSAGE]
Tano has joined #ffmpeg
Rena has joined #ffmpeg
Marth64 has quit [Quit: Leaving]
emanuele6 has quit [Quit: moo you later]
ape_din has joined #ffmpeg
<ape_din>
hi, im using this commeand: ffplay -window_title Webcam -vf hflip -fast /dev/video0 but my webcam seems to have latency. any suggestion on how to make it better?
ape_din has quit [Ping timeout: 248 seconds]
jemius has quit [Quit: Leaving]
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
relue has joined #ffmpeg
spuos has left #ffmpeg [#ffmpeg]
Marth64 has joined #ffmpeg
iive has quit [Quit: They came for me...]
SuicideShow has quit [Ping timeout: 260 seconds]
SuicideShow has joined #ffmpeg
<grib>
ape_din, is it any faster without the filter (-vf hflip)?