[Ffmpeg-devel-irc] ffmpeg.log.20190518

[burek]

[00:05:09 CEST] <leif> Does anyone know what good parameters are for getting ffmpeg+v4l2 to have nice output when recording with a camlink?
[00:06:00 CEST] <leif> (Right now I'm using `ffmpeg -f v4l2 -i /dev/video0 out.mp4, and it looks very blurry
[00:06:17 CEST] <leif> Especially compared to if I just open up the stream in OBS, it looks much cleaner.
[00:07:54 CEST] <cehoyos> Assuming your device provides rgb (complete, uncut console output missing), use an encoder that supports rgb
[00:08:28 CEST] <cehoyos> qtrle or png could be possibilities if you want lossless encoding
[00:09:08 CEST] <cehoyos> and if you record uniform areas
[00:10:49 CEST] <leif> cehoyos: The output is https://gist.github.com/LeifAndersen/77e5abd6bcf08a3e4a1656c00242da1d
[00:11:43 CEST] <cehoyos> For yuyv422, x264 is the right encoder, you may want to increase quality.
[00:12:05 CEST] <cehoyos> Or check if the v4l2 device supports other colour spaces (this seems likely if obs output looks nicer)
[00:13:10 CEST] <leif> cehoyos: Makes sense. How would I check that with ffmpeg?
[00:13:10 CEST] <cehoyos> ffmpeg -list_formats 1 -i /dev/video1
[00:13:28 CEST] <leif> Ah, lol, typing race conditions....thanks.
[00:14:12 CEST] <leif> cehoyos: It says [video4linux2,v4l2 @ 0x170b200] Raw       :     yuyv422 :           YUYV 4:2:2 : 1280x720
[00:14:44 CEST] <cehoyos> Nothing else?
[00:14:48 CEST] <cehoyos> (No more lines?)
[00:15:03 CEST] <leif> Full output: https://gist.github.com/LeifAndersen/12ea51ceeb72dc91818f983f3a8feb07
[00:15:13 CEST] <leif> (Sorry, I'm a bit slow at copy/pasting sometimes.)
[00:15:33 CEST] <cehoyos> (I get seventeen formats here with an old tv card that can also do video-in)
[00:15:40 CEST] <cehoyos> Don't worry!
[00:16:11 CEST] <leif> Ya....the camlink is an increadibly simple device.
[00:16:18 CEST] <cehoyos> Sorry, I don't understand how other software can produce a better image: Only yuv422 is supported and x264 should be the best encoder for this format.
[00:16:34 CEST] <cehoyos> Ahhh
[00:16:50 CEST] <leif> So maybe just tell x264 to use higher quality maybe?
[00:16:57 CEST] <cehoyos> It drops nearly all frames: Your hardware is not fast enough for x264 default, use something like ultrafast
[00:17:12 CEST] <leif> Mmmmm...I'll try that.
[00:17:48 CEST] <cehoyos> No, speed is ok
[00:17:59 CEST] <cehoyos> That means the encoder is (or looks) fast enough.
[00:18:07 CEST] <cehoyos> You can still try other crf values
[00:18:28 CEST] <leif> Okay.
[00:18:59 CEST] <leif> For reference, the machine the camlink is plugged into is a precision 5530, with some relatively modern i7 in it.
[00:19:07 CEST] <leif> (IIRC, ffmpeg doesn't use the gpu by default, right?)
[00:19:23 CEST] <cehoyos> x264 does not
[00:19:51 CEST] <cehoyos> Since x264 has better quality than any gpu, this would not fix your issue
[00:20:00 CEST] <cehoyos> Just try higher quality encoding.
[00:20:59 CEST] <leif> trying that now.
[00:25:12 CEST] <leif> cehoyos: yup, that did it. Thanks! :D
[00:26:04 CEST] <cehoyos> Great!
[08:29:06 CEST] <kartikay> Hey guys, I had recently read some article regarding how we can make scientific animations by piping PPM images into ffmpeg and piping the output to vlc
[08:29:24 CEST] <kartikay> now I wanted to try that but unfortunately lost the link to the article
[08:31:30 CEST] <Mysterytrain> invaders!
[08:37:08 CEST] <furq> kartikay: cat *.ppm | ffmpeg -f image2pipe -i - -c:v rawvideo -f nut - | vlc -
[08:37:26 CEST] <furq> or just cat *.ppm | mpv --demuxer=lavf --demuxer-lavf-format=image2pipe -
[08:47:40 CEST] <grosso> hi
[08:47:55 CEST] <grosso> I'm looking for a way to send control messages through an rtmp streaming, in addition to audio and video
[09:49:42 CEST] <mnu> I'm looking to make a webm from a flac and an image, but am struggling to find anything about doing it this way round, everything I come across point at webm -> flac. rather than creating webms from and audio file.
[10:02:37 CEST] <DoITCreative> Hey guys, I have a few *.ts files and I want to convert them all to 1 video file, like avi or mp4, how to do this in ffmpeg (linux)
[10:03:55 CEST] <furq> DoITCreative: https://trac.ffmpeg.org/wiki/Concatenate#protocol
[10:04:11 CEST] <DoITCreative> thanks ;)
[10:04:17 CEST] <furq> mnu: -i foo.flac -loop 1 -i bar.jpg -shortest out.webm
[10:04:23 CEST] <furq> plus whatever encoder options you want
[10:07:01 CEST] <mnu> furq: nice ty I'll give that a shot
[10:21:35 CEST] <ButtDog> I'm currently using Moviepy to concat two videos and the ouput doesn't have sound. Here's the ffprobe of the output video: https://pastebin.com/VEFdCbrA
[10:21:53 CEST] <ButtDog> Any suggestions or ideas would be greatly appreciated!
[10:23:20 CEST] <mnu> furq: that worked well but produced a vp9 webm, I need to make a vp8 one, but am struggling with the encoder options for that
[10:23:28 CEST] <furq> -c:v libvpx
[10:26:22 CEST] <mnu> 'Failed to decode frame: Bitstream not supported by this decoder
[10:26:24 CEST] <mnu> Error while decoding stream #1:0: Invalid data found when processing input
[10:27:28 CEST] <furq> it's an output option
[10:28:48 CEST] <mnu> hiooo
[10:28:51 CEST] <mnu> man I was being dumb
[10:28:56 CEST] <mnu> forgive me
[14:28:58 CEST] <whitestone> hello
[16:06:14 CEST] <whitestone> someone know this error
[16:06:15 CEST] <whitestone> There are not enough buffered video frames. Video may misbehave!
[18:07:31 CEST] <grosso> hi
[18:07:34 CEST] <grosso> I'm looking for a way to send control messages through an rtmp streaming, in addition to audio and video
[18:21:47 CEST] <alpha-carinae> hey all
[18:22:17 CEST] <alpha-carinae> i just used h264/h265 most of the time
[18:22:30 CEST] <alpha-carinae> im wondering why vp8/9 didn't get popular
[18:22:37 CEST] <alpha-carinae> encoding time and resources?
[18:34:02 CEST] <DHE> h264/5 has industry media industry backing. vp9 has google/youtube backing
[18:34:21 CEST] <alpha-carinae> oh
[18:35:02 CEST] <DHE> (pretend I didn't type "industry" twice there plz)
[18:35:10 CEST] <alpha-carinae> hahaha
[18:35:14 CEST] <alpha-carinae> so umm
[18:35:28 CEST] <DHE> anyway. h265 would probably have caught on better if not for the licensing on it
[18:35:48 CEST] <alpha-carinae> so i have some doubts now
[18:36:05 CEST] <alpha-carinae> what exactly do these licenses mean?
[18:36:07 CEST] <alpha-carinae> i mean
[18:36:17 CEST] <alpha-carinae> x265 is an encoder and it has a gpl license
[18:36:27 CEST] <DHE> yes, but the codec itself has patents held by the MPEG-LA
[18:36:45 CEST] <alpha-carinae> the codec means the structure right?
[18:36:49 CEST] <DHE> yes
[18:36:55 CEST] <alpha-carinae> the prototype
[18:36:58 CEST] <alpha-carinae> so umm
[18:37:06 CEST] <DHE> the h265 spec
[18:37:12 CEST] <alpha-carinae> ah yeah
[18:37:14 CEST] <alpha-carinae> if the implemented program is gpl
[18:37:26 CEST] <alpha-carinae> then where exactly does the patents apply?
[18:37:30 CEST] <alpha-carinae> do*
[18:39:11 CEST] <DHE> x265 is an encoder. but the h265 specification uses ideas and strategies that are patented by various companies.
[18:39:43 CEST] <alpha-carinae> oh so those ideas are patented?!
[18:39:50 CEST] <alpha-carinae> wow what a great move
[18:40:01 CEST] <alpha-carinae> now people are patenting knowledge!
[18:41:35 CEST] <alpha-carinae> hmm so doubt
[18:41:50 CEST] <DHE> just google MPEG-LA
[18:41:53 CEST] <alpha-carinae> does licensing mean costs?
[18:45:01 CEST] <kurosu> alpha-carinae: for a company, basically, yes
[18:45:56 CEST] <kurosu> as an individual, unlikely that any of them go after you
[18:46:25 CEST] <alpha-carinae> thanks kurosu, so if the company commercially uses any h264 video, produced by any encoder, it needs to pay?!
[18:46:26 CEST] <alpha-carinae> oh
[18:46:55 CEST] <DHE> I suggest reading the actual license. size of userbase is a factor
[18:47:11 CEST] <alpha-carinae> sorry if im making this a bad convo
[18:47:19 CEST] <alpha-carinae> im bad at understanding these things
[18:47:22 CEST] <alpha-carinae> so from what i understand, building an encoder isn't wrong, but using the video is.
[18:52:56 CEST] <Mavrik> It's not wrong, it's just patented.
[18:53:00 CEST] <Mavrik> So you need to pay to use it :)
[18:53:16 CEST] <alpha-carinae> i see
[18:53:30 CEST] <Mavrik> And there's a lot of companies that want to put their money jar your way :)
[18:53:46 CEST] <Mavrik> For decoding you usually pay for patents together with software/hardware in your device.
[18:54:00 CEST] <Mavrik> For encoding it's complicated because they want to charge you if you encode for commercial use.
[18:54:08 CEST] <Mavrik> And there's several competing patent holders for H.265
[18:54:25 CEST] <alpha-carinae> wow
[18:54:43 CEST] <Mavrik> Which is why AV1/VPx codecs came to be :)
[18:54:45 CEST] <alpha-carinae> you mean when i buy a laptop, i pay some royalty?
[18:54:57 CEST] <Mavrik> For the H.264/H.265 decoding block in your CPU or GPU yes.
[18:55:00 CEST] <alpha-carinae> yeah
[18:55:02 CEST] <Mavrik> And when you buy a phone.
[18:55:15 CEST] <alpha-carinae> wow i see
[18:55:42 CEST] <Mavrik> It's not a bad business for patent holders, which is why so many of them came crawling out of the woods when H.265 was standardized ;)
[18:56:05 CEST] <alpha-carinae> lol i wonder if we need to pay for sharing h264 vids online
[18:56:25 CEST] <alpha-carinae> but it doesn't seem fair :|
[18:56:40 CEST] <alpha-carinae> which is why vpx and av1 came out
[18:57:13 CEST] <Mavrik> You don't have to pay for personal use
[18:57:33 CEST] <Mavrik> Mostly. :)
[18:57:36 CEST] <alpha-carinae> I see
[18:57:42 CEST] <alpha-carinae> Thanks Mavrik :)
[18:57:51 CEST] <Mavrik> But yeah, H.265 patent thig held it back quite a lot.
[18:58:08 CEST] <Mavrik> And unsurprisingly the decoder/TV industry is the one holding the patents, so they've been pushing H.265
[18:58:24 CEST] <Mavrik> While Google and other software companies gathered around AV1 now to avoid those royalties.
[18:58:54 CEST] <alpha-carinae> i see
[18:59:09 CEST] <alpha-carinae> yeah bluray shipping with hevc
[18:59:15 CEST] <alpha-carinae> especially 4k
[18:59:26 CEST] <Mavrik> Yeah, and Apple for example is one of the companies that get royalties for HEVC
[18:59:53 CEST] <alpha-carinae> i wonder if google was one of em too, it wouldnt press on av1 so much
[19:00:22 CEST] <Mavrik> Guess what they're pushing to play 4K on Apple TV and iPhone :)
[19:00:24 CEST] <Mavrik> Urh, lag.
[19:00:30 CEST] <Mavrik> alpha-carinae: of course they wouldn't :)
[19:00:47 CEST] <Mavrik> But as it stands, paying those royalties is expensive for YouTube :)
[19:01:28 CEST] <alpha-carinae> Yeah
[19:03:09 CEST] <Mavrik> But this whole mess kinda made sure most people are still using H.264 which is less insane :)
[19:04:23 CEST] <DHE> av1 is a generation ahead of vp9 and h265 (which are ballpark equivalent for quality per bitrate)
[19:06:02 CEST] <alpha-carinae> DHE you mean in terms of spec and technology?
[19:06:39 CEST] <alpha-carinae> but that also means it takes longer for av1 to meaningfully be encoded on our regular computers
[19:06:44 CEST] <alpha-carinae> :(
[19:09:54 CEST] <Mavrik> TBH all three, VP9/H265/AV1 are very slow to encode without dedicated HW
[19:10:29 CEST] <alpha-carinae> Yeah
[19:10:34 CEST] <alpha-carinae> Especially my laptop
[19:10:35 CEST] <alpha-carinae> :(
[19:11:15 CEST] <alpha-carinae> im learning all these and these are interesting but h264 is the only thing that goes ok
[19:11:17 CEST] <alpha-carinae> so far
[19:11:20 CEST] <alpha-carinae> h265 is poor
[19:11:25 CEST] <alpha-carinae> and vpx too
[19:13:28 CEST] <DHE> there's also maturity. x264 is something like 15 years old now?
[19:14:09 CEST] <alpha-carinae> yeah
[19:16:16 CEST] <DHE> av1 encoding will improve. it's only been a year or so since the big announcement of a user-ready (if slow as ****) encoder
[19:17:49 CEST] <alpha-carinae> i hope it does
[19:40:34 CEST] <alpha-carinae> hey again
[19:40:51 CEST] <alpha-carinae> so i heard prores is a good codec for prodcution
[19:41:00 CEST] <alpha-carinae> *production
[19:44:00 CEST] <alpha-carinae> that it can be used to archive good quality video for a ling time
[19:44:20 CEST] <alpha-carinae> but i also heard it's not supported on linux
[19:44:27 CEST] <alpha-carinae> is there any alternative?
[19:52:18 CEST] <another> ffmpeg supports prores
[19:52:56 CEST] <alpha-carinae> in linux too?
[19:53:41 CEST] <another> everywhere afaik
[19:53:51 CEST] <alpha-carinae> ah i see
[20:00:15 CEST] <Hello71> wtf does that have to do with linux
[21:37:19 CEST] <snap1> what is more popular these days?  CPU encoding or GPU encoding?
[21:44:59 CEST] <t3st3r> Depends on what you want. If you care about decent bitrate vs quality tradeoff, cpu encoding is about this. If you're pressed by realtime requirements, gpu encoding HW encodes fast, sure.
[21:47:02 CEST] <t3st3r> Also depends on how exactly "popular" would be defined.
[21:49:08 CEST] <tpaper> Hi all! I am using ffmpeg to transcode (and save to disk) an http video stream. I have a small opencv c++ software that detects movements in the stream. My goal is to "pause" the ffmpeg recording when there is no movement... I thougt about sending some POSIX signal to the process but SIGSTOP and SIGCON does not seems to work fine
[21:50:03 CEST] <snap1> t3st3r is GPU really faster?
[21:50:09 CEST] <snap1> gpu encoding*
[21:50:51 CEST] <t3st3r> snap1> depends on what one defines as GPU encoding. Say dedicated video encoding hardware is tailored for realtime use cases. So it ofc fast.
[21:53:48 CEST] <t3st3r> But there is no free lunch - this approach usually takes more bitrate to achieve comparable quality. Slow encoding happens if codec undertaking a lot of efforts to find best ways to encode out of all numerous possibilities.
[21:54:32 CEST] <snap1> if i use $200 CPU and use x264  and $600 CPU and use x264 : is it safe to assume  they both produce exact same  x264 video file?  but  $600 would be just faster?
[21:55:44 CEST] <t3st3r> snap1> Yes under some certain assumptions more expensive cpu would just finish job faster - assuming overall amount of processing stays same.
[21:56:23 CEST] <t3st3r> This said it could be tempting to use e.g. more threads if cpu hardware can afford it. Unfortunately it can make codec decision making slightly less optimal.
[21:56:47 CEST] <snap1> now, what if i change my question to:
[21:56:58 CEST] <snap1>  if i use $200 GPU and use x264  and $600 GPU and use x264 : is it safe to assume  they both produce exact same  x264 video file?  but  $600 would be just faster?
[21:58:22 CEST] <t3st3r> GPUs these days have builtin codecs HW. I'm not sure if someone bothered to compare this HW in GPUs. But it supports only few formats and mostly targets realtime use.
[21:58:51 CEST] <t3st3r> So most of time ppl care whether it fits real time or not. Faster than that is not terribly exciting.
[21:59:37 CEST] <t3st3r> Maybe you refer about hybrid approach where parts or most of codec offloaded as "GPU compute" - but I'm not aware of widely used implementations of this.
[21:59:48 CEST] <t3st3r> (at least in ffmpeg context)
[22:00:13 CEST] <snap1> wow there is hybrid encoding?
[22:00:34 CEST] <t3st3r> Hmm there were at least ettempts on this. But I can't remember glaring success.
[22:01:24 CEST] <snap1> i see
[22:01:32 CEST] <snap1> t3st3r are you a ffmpeg dev?
[22:02:03 CEST] <t3st3r> no, just some random person who is somewhat curious about video encoding.
[22:02:33 CEST] <snap1> what do you prefer?  cpu or gpu encdoing
[22:04:14 CEST] <t3st3r> My use cases and goals could be a bit specific - I enjoy by good encoding in small file size, taking it as kind of challenge. At which point cpu encoding is ofc best.
[22:05:30 CEST] <t3st3r> I also got strange habits to fiddle with vp9 and now av1. Later is hardly supported by hardware yet. Would be added in few years I bet. But it imply buying other device.
[22:10:41 CEST] <snap1> how is vp9 compared to h265
[22:11:29 CEST] <Mavrik> Quality-wise it's about the same.
[22:12:14 CEST] <snap1> is it just me or anything before h264  sucked
[22:17:28 CEST] <DHE> yeah
[22:17:31 CEST] <DHE> it did
[22:21:34 CEST] <snap1> then how did youtube/twitch survive  before h264 existed
[22:22:14 CEST] <DHE> flash video
[22:22:23 CEST] <DHE> obviously
[22:22:23 CEST] <Mavrik> Did they even exist before H.264?
[22:22:27 CEST] <snap1> .flv  that's just container
[22:22:39 CEST] <snap1> what  video codec did it use
[22:23:00 CEST] <Mavrik> Usually H.264 even in that
[22:23:06 CEST] <Mavrik> Or VP6 or what was the horrible thing
[22:23:06 CEST] <another> tiwtch was founded in 2011
[22:23:25 CEST] <snap1> and h264 was founded when?
[22:23:52 CEST] <Mavrik> H.264 was standardized in 2003
[22:24:31 CEST] <snap1> oh, then twitch never had this issue
[22:24:35 CEST] <DHE> there was a codec generally known as "flash video", fourcc "flv1"
[22:24:44 CEST] <DHE> is that vp6?
[22:25:08 CEST] <another> no. that's sorenson spark
[22:25:09 CEST] <snap1> dhe not sure, i thought flv was just container
[22:25:41 CEST] <DHE> it is, but flash still needed a video codec to be useful
[22:26:00 CEST] <Mavrik> I remember working on streaming live video (baseline) to Nokia 6120 phones of 2007 vintage
[22:26:17 CEST] <Mavrik> And video platforms on the web weren't really a thing... baseline H.264 was though.
[22:26:38 CEST] <Mavrik> Yeah, FLV was either sorenson, VP6 or H.264
[22:26:50 CEST] <DHE> yeah flash was how video was done back then. other than save it to disk and watch it in windows media player later.
[22:27:44 CEST] <Mavrik> mhm, but more than that - streamed video wasn't really much of a thing though
[22:27:51 CEST] <Mavrik> IPTV used MPEG-2
[22:28:03 CEST] <Mavrik> but on the web you were mostly downloading stuff or buying DVDs :P
[22:28:14 CEST] <Mavrik> or pirating DivX/Xvid
[22:28:55 CEST] <snap1> divx was horrible quality
[22:30:25 CEST] <Mavrik> Better than MPEG-2 video which was industry standard :P
[22:30:48 CEST] <Mavrik> It's not like you had a CPU that could decode more than PAL/NTSC anyway.
[22:35:56 CEST] <Ariyasu> hello
[22:36:37 CEST] <Ariyasu> when encoding 1920x1080i h264 to x264 and scaling it down to 720x404
[22:36:46 CEST] <Ariyasu> ffmpeg does not use all of my cpu resources
[22:37:11 CEST] <Ariyasu> utilisation is like 50%, what could the bottleneck be?
[22:37:21 CEST] <DHE> that does happen, especially at low resolutions and especially when there are a LOT of cores...
[22:37:30 CEST] <Ariyasu> when i encode the same source to x264 @ 720p or 1080p it uses full cpu
[22:37:39 CEST] <Ariyasu> yeah i have 16 cores
[22:37:41 CEST] <Ariyasu> ok
[22:37:50 CEST] <snap1> Ariyasu that's normal
[22:38:10 CEST] <Ariyasu> ok thats fine then
[22:38:24 CEST] <Ariyasu> just wanted to make sure it wasn't something i could "fix" to make it go faster :)
[22:49:55 CEST] <norwood67> hey, is there a way to play a video on tty1 without having X installed?
[22:53:03 CEST] <durandal_1707> norwood67: yes, use mpv
[22:53:57 CEST] <norwood67> thanks...
[22:54:36 CEST] <snap1> i know how to convert to opus using ffmpeg   ffmpeg -i audio.flac -c:a libopus -b:a 128k  audio.opus:  but how do i do this in  OBS
[22:56:45 CEST] <Soni> how can I make pixel art with ffmpeg?
[22:59:12 CEST] <Ariyasu> isnt there an option in obs to use a custom command snap1
[22:59:24 CEST] <snap1> yes there is
[22:59:48 CEST] <snap1> i know how to convert  flac to opus  ffmpeg -i audio.flac -c:a libopus -b:a 128k  audio.opus
[23:00:18 CEST] <snap1> but i don't know what command to use  for OBS to use opus
[23:52:25 CEST] <circuitbone> Soni:  image magick and ffmpeg
[00:00:00 CEST] --- Sun May 19 2019