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

Sat Feb 8 03:05:02 EET 2020

[00:50:50 CET] <Synoptic> Hi there
[00:51:22 CET] <Synoptic> I need to grab /dev/video0 (v4l2) and output it to my rtsp server.
[00:52:08 CET] <Synoptic> I can get it to work, but I do not know ffmpeg very well, and all the examples I can find are hard for me to understand. I would like someone that could take me by the hand and help me get what I need.
[00:52:42 CET] <Synoptic> ideally, I would like to transcode the input of /dev/video0 to a h264 stream
[00:54:23 CET] <Synoptic> brb
[01:05:37 CET] <c_14> I recommend reading https://ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2 and https://ffmpeg.org/ffmpeg-protocols.html#rtsp
[01:06:40 CET] <c_14> in general it'll be something like `ffmpeg -f v4l2 -i /dev/video0 -f rtsp rtsp://host/path'
[01:07:20 CET] <c_14> any encoder options and the like go after video0 and before rtsp://
[01:07:24 CET] <Synoptic> c_14 : Yes indeed. This works, but the quality it outputs is nowhere near the actual stream from the device.
[01:07:45 CET] <Synoptic> c_14 : thank for the tip, will try a bit and see
[01:07:54 CET] <c_14> then you want to touch the encoder settings
[01:08:12 CET] <Synoptic> let me paste my line on pastebin, ok ?
[01:08:28 CET] <c_14> yeah
[01:10:08 CET] <Synoptic> https://pastebin.com/mq2080GF
[01:11:13 CET] <c_14> you probably want to encode with -c:v libx264
[01:11:33 CET] <c_14> default quality is probably fine for that encoder, but you  can play around with it with -crf
[01:11:50 CET] <Synoptic> "ffmpeg -f v4l2 -video_size 1920x1080 -i /dev/video0 -r 10 -f -c:v libx264 rtsp rtsp://localhost:8554/unicast" like this ?
[01:12:07 CET] <c_14> the -f goes before rtsp and after libx264
[01:12:24 CET] <Synoptic> ok
[01:12:53 CET] <Synoptic> ffmpeg -f v4l2 -video_size 1920x1080 -i /dev/video0 -r 10 -c:v libx264 -f rtsp rtsp://localhost:8554/unicast
[01:13:31 CET] <c_14> are you purposefully setting the output framerate instead of the input framerate?
[01:14:10 CET] <c_14> use -framerate <number> before the input to change the input framerate
[01:14:16 CET] <Synoptic> not really. The devic can output 15fps, but with the current line, it shows 5... I was messing around,
[01:15:01 CET] <c_14> use -framerate 15 before -i
[01:15:36 CET] <c_14> and get rid of the -r 10
[01:17:34 CET] <Synoptic> ok did that, but the command gets killed, let me paste it
[01:18:28 CET] <Synoptic> https://pastebin.com/pSYrRcDS
[01:18:50 CET] <Synoptic> command was : ffmpeg -f v4l2 -video_size 1920x1080 -framerate 15 -i /dev/video0 -c:v libx264 -f rtsp rtsp://localhost:8554/unicast (forgot to paste it)
[01:19:55 CET] <c_14> check the output of dmesg?
[01:20:22 CET] <c_14> that killed looks a lot like something the os would do
[01:20:25 CET] <Synoptic> out of memory. I am running on a raspberry pi
[01:21:50 CET] <Synoptic> maybe we can skip the h264 thing if its too much for the pi, we could maybe just tweak the native mpeg4 format ?
[01:21:54 CET] <c_14> check if your ffmpeg has the h264_omx encoder
[01:22:06 CET] <c_14> ffmpeg -encoders | grep h264
[01:22:15 CET] <c_14> otherwise you can just boost the mpeg4 encoder's bitrate, yeah
[01:23:01 CET] <Synoptic> DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_mmal h264_vdpau ) (encoders: libx264 libx264rgb h264_omx h264_vaapi )
[01:23:13 CET] <Synoptic> its seems to be there
[01:23:21 CET] <c_14> then try -c:v h264_omx
[01:23:40 CET] <c_14> might need to set -pix_fmt yuv420p or so
[01:23:58 CET] <c_14> probably not a terrible idea in either case
[01:24:03 CET] <Synoptic> it runs, but fps are stuck around 5
[01:24:19 CET] <Synoptic> Stream #0:0: Video: h264 (h264_omx), yuv420p, 1920x1080, q=2-31, 200 kb/s, 5 fps, 90k tbn, 5 tbc
[01:24:36 CET] <furq> Synoptic: pastebin the output of ffmpeg -f v4l2 -list_formats all -i /dev/video0
[01:24:51 CET] <c_14> Synoptic: yeah, I noticed that in the output earlier. You're requesting 15fps but the device is lowering the fps
[01:25:15 CET] <c_14> do what furq says and check what exactly the device supports
[01:25:26 CET] <Synoptic> furq : https://pastebin.com/UQq9DcyJ
[01:26:02 CET] <Synoptic> I could try mjpeg
[01:26:07 CET] <furq> is this usb2
[01:26:44 CET] <furq> usb2 wouldn't have the bandwidth for 1080p 4:2:2 at 15fps anyway
[01:28:16 CET] <Synoptic> furq : yep, usb2
[01:28:29 CET] <Synoptic> furq : good to know, thnaks
[01:28:30 CET] <furq> try ffmpeg -f v4l2 -input_format mjpeg -video_size 1920x1080 -framerate 30 -i /dev/video0 -c copy -f rtsp rtsp://
[01:30:26 CET] <Synoptic> furq : https://pastebin.com/jmgcFKTY
[01:30:39 CET] <Synoptic> but I get 15 fps
[01:43:45 CET] <Hello71> I think v4l2-ctl is better
[01:45:02 CET] <Synoptic> Hello71 : are you talking to me ?
[01:45:11 CET] <Hello71> meh
[01:47:59 CET] <Synoptic> c_14, furq : I think the PI is just too weak to handle 1080p
[02:07:48 CET] <Synoptic> c_14, furq : thanks for your help
[12:08:12 CET] <pagios> what is more dominatn a tune zerolatency or a preset ultrafast?
[12:08:26 CET] <pagios> do they work together?
[12:10:19 CET] <pagios> -preset","uultrafast","-framerate",30,"-g",30,"-hls_init_time",1,"-hls_time",1,' VS -tune","uzerolatency","-framerate",30,"-g",30,"-hls_init_time",1,"-hls_time",1,'
[12:52:10 CET] <Tyras> hello... I'm having some issues wne rewrapping video files with ffmpeg. Can't really find anything about these problems....
[12:54:33 CET] <Tyras> the first one, is when rewrapping a h264 video from mpegts to mp4. The input is a CBR h264 video, but the output always comes out as VBR. The CLI I'm using ffmpeg -i video.ts -c copy -f mp4 output.mp4; Is this a known issue?
[14:23:31 CET] <tomb^> Hi, I'm trying to concat several files and get the following error: "[mxf @ 000002db09f893c0] inconsistent FooterPartition value: 567259648 != 350554112", "found essence prior to first PartitionPack
[14:23:31 CET] <tomb^> concat:c:\0\temp\052d614a-9d97-45bc-bf59-dee0f87a3d01.mxf|c:\0\temp\1ee4a935-2fbc-4b33-9bce-9f9a97f19f65.mxf: Invalid data found when processing input
[14:23:48 CET] <tomb^> what am I doing wrong?
[18:58:19 CET] <HickHoward> hey
[18:59:16 CET] <HickHoward> so i want to know if it's possible to encode a lossless 7.1 audio file into some 7.1 E-AC-3 file through ffmpeg if at all
[18:59:56 CET] <microchip_> no, eac3 encoder in ffmpeg is still limited to 6 channels (5.1)
[19:00:01 CET] <HickHoward> damn
[19:01:49 CET] <HickHoward> as a side note there's this new sound codec i've heard being talked about
[19:01:54 CET] <HickHoward> and it's being called LC3
[19:02:17 CET] <HickHoward> apparently it's a new audio codec for bluetooth devices
[19:02:49 CET] <microchip_> yup
[19:03:13 CET] <microchip_> there's also AC-4 and someone is already working on a decoder for ffmpeg
[19:03:40 CET] <HickHoward> nice
[19:03:51 CET] <HickHoward> that aside, i already got the source code from ETSI through a link iis.fraunhofer posted on their LC3 page
[19:03:58 CET] <HickHoward> seems rather generous for them to do that
[19:06:04 CET] <JEEB> HickHoward: fraunhofer (generally) has some code, which often isn't compatible with other projects' licensing
[19:06:27 CET] <JEEB> so you can have the source code, but whether someone can utilize that code for an open source project depends on how they licensed it
[19:07:06 CET] <HickHoward> i was just picking that source code for myself
[19:07:17 CET] <HickHoward> i have no intention to spread it aboard, which means i might not even
[19:07:26 CET] <HickHoward> be able to keep that code
[19:07:41 CET] <HickHoward> for how many years
[19:08:08 CET] <JEEB> what I'm saying is that fraunhofer might have some issues as an organization, but they generally are less bad than those companies that mostly depend on forcing people to utilize their implementation
[19:08:21 CET] <JEEB> *cough* dolby, dts *cough*
[19:09:13 CET] <HickHoward> i guess apple doesn't count...?
[19:09:45 CET] <JEEB> I think apple just generally doesn't do much of those. it's mostly been prores so far?
[19:09:51 CET] <pink_mist> alac?
[19:09:52 CET] <JEEB> apple just generally doesn't play well with other kids in the sandbox
[19:09:57 CET] <JEEB> right, that too
[19:10:10 CET] <HickHoward> maybe i need to do more research on the "forcing people" part
[19:10:38 CET] <pink_mist> not sure if quicktime was like that
[19:10:57 CET] <JEEB> QT file format was actually quite well documented
[19:11:03 CET] <JEEB> see qtff.pdf
[19:12:04 CET] <JEEB> anyways, apple has at least during the last 15 or so years that I remember been less of a patent licensing and sales buzzword thing with regards to multimedia formats. they buzzword their products up, sure
[19:12:36 CET] <JEEB> but generally speaking they have only tried to get places to use their decoder with regards to prores
[19:13:13 CET] <JEEB> and that hasn't been "let's throw some nice legal threats at places" level :)
[19:13:50 CET] <HickHoward> i haven't seen much from apple at all
[19:14:02 CET] <HickHoward> at the very least, not much insanity as far as i can tell
[19:16:50 CET] <HickHoward> in any case i've somehow managed to get a part of EC3plus compiled into an exe using VS2019
[19:17:09 CET] <HickHoward> code had some issues here and there but nothing i can't fix any time soon
[19:20:57 CET] <HickHoward> oh, another question
[19:21:17 CET] <HickHoward> i want to know if Dolby AC-4 supports source files that are supposed to be using some Dolby Atmos technology?
[19:22:34 CET] <JEEB> how does that matter if it's an ac-4 decoder? if it's a valid ac-4 stream it would get decoded
[19:22:43 CET] <HickHoward> i ask this because Netflix released another open-source "movie" called Nocturne
[19:23:22 CET] <HickHoward> they've even released some lossless assets related to that movie in question, including an .wav file designed to be encoded into an Dolby Atmos stream
[19:24:05 CET] <JEEB> dolby generally doesn't put their "atmos" stuff into parts of their stuff that is standardized
[19:24:21 CET] <JEEB> also the "atmos" keyword is highly overloaded at dolby jus like dolby vision
[19:24:27 CET] <HickHoward> damn
[19:24:52 CET] <JEEB> I think the funniest was TrueHD where they just expected a decoder to not try to decode all of the things from a stream
[19:25:09 CET] <JEEB> and they just stuck some random data onto one of the data streams
[19:25:14 CET] <JEEB> so you actually have to actively ignore that
[19:25:29 CET] <JEEB> or get the otherwise ok truehd stream output garbage
[19:25:51 CET] <HickHoward> so basically Dolby Atmos is a big nothing burger
[19:26:06 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=dc2d0e06af459af9a7f91b65e0a3119acc4f1baa
[19:26:30 CET] <HickHoward> makes sense
[19:26:50 CET] <JEEB> HickHoward: it's sales keywords, classic dolby style. also dolby is well known for skipping parts of their stuff in the specifications that they publish
[19:27:02 CET] <JEEB> because they don't expect anyone to actually implement it. you pay dolby and you get a decoder :P
[19:27:25 CET] <JEEB> I think DTS did the same?
[19:28:15 CET] <JEEB> because DTS had to publish "a spec" (that looked good enough to pass a glancing look) for broadcast use of DTS-XLL (lossless extensions, aka "DTS HD-MA")
[19:28:24 CET] <JEEB> and dolby for AC-4 as well
[19:29:00 CET] <HickHoward> these companies must really suck
[19:29:37 CET] <HickHoward> release a bare-bones PR book and call it "a spec"
[19:30:02 CET] <HickHoward> though i don't really think that's the intent there
[19:30:20 CET] <JEEB> the specs generally seem to go technical enough
[19:30:35 CET] <JEEB> it's just that at some point you notice that something in the middle is conveniently missing
[19:31:33 CET] <JEEB> anyways, for the sales pitch things you generally can find related documentation from... patents
[19:31:52 CET] <HickHoward> patents
[19:32:09 CET] <JEEB> like f.ex. certain dolby HDMI packets' struct definition is... in a patent :P
[19:32:42 CET] <HickHoward> i'm guessing patents describe these kinds of technologies at more detail?
[19:33:11 CET] <rcombs> I still want to discuss marking FDKAAC as non-nonfree
[19:33:13 CET] <JEEB> if you find them, you can quite possibly gain one step closer to figuring out what is behind the buzzwords
[19:35:08 CET] <HickHoward> i suppose that's somewhat helpful
[19:35:11 CET] <HickHoward> if it is at all
[19:35:46 CET] <JEEB> rcombs: you're free to do that. I think some time ago I joined some discussion that was about that
[19:35:58 CET] <JEEB> would have to recall things from the logs what it was that time
[19:36:14 CET] <rcombs> I just dunno whose buy-in it needs
[19:37:12 CET] <furq> did they change the license or is someone just interpreting it more charitably
[19:37:19 CET] <rcombs> the latter
[19:37:27 CET] <JEEB> I don't even remember if the discussion was about the fedora patched version or the original
[19:37:48 CET] <JEEB> since fedora OK'd a version which was without LC-AAC. although I'm not sure if they link it against GPL stuff?
[19:37:58 CET] <rcombs> red hat's interpretation is that the patent clause is a no-op if you use a version of the decoder without HE, since LC's expired
[19:37:59 CET] <JEEB> LGPL is OK even atm with configure?
[19:38:09 CET] <JEEB> yea
[19:38:13 CET] <rcombs> our lawyer's interpretation is that the patent clause is a no-op period
[19:38:35 CET] <rcombs> because it's essentially just a "you have to follow local law", which doesn't actually do anything
[19:38:41 CET] <rcombs> (you have to follow local law anyway)
[23:16:23 CET] <MerlinTheWizard> Hi all.
[23:16:53 CET] <MerlinTheWizard> Can anyone tell me what is the limit of precision for the -framerate option while encoding a video from still frames?'
[23:40:29 CET] <furq> i don't think there is one
[23:42:50 CET] <MerlinTheWizard> furq, is there a limit defined on a per codec basis? And if so, is there an easy way to find it?
[23:43:26 CET] <BtbN> codecs don't care about framerate
[23:43:28 CET] <BtbN> they just encode frames
[23:43:38 CET] <furq> the limit would normally be on the container level if there is one
[23:43:50 CET] <furq> any decent container won't care though
[23:44:17 CET] <MerlinTheWizard> furq, ok. So I can throw any decimal number at it and it should usually be fine.
[23:44:20 CET] <MerlinTheWizard> Okay, thanks
[23:44:41 CET] <BtbN> keep in mind that very non standard FPS might not be treated the way you expect it to by whatever plays or decode that
[23:44:43 CET] <furq> if you're worried about losing precision then use a rational number
[23:44:53 CET] <furq> also yeah players probably won't handle 0.00001fps very nicely
[23:45:15 CET] <furq> specifically seeking
[23:45:54 CET] <MerlinTheWizard> furq, okay, so don't use a ridiculous framerate... And how do I specify a rational number? Just decimal, right?
[23:46:06 CET] <furq> -framerate 12/34
[23:46:20 CET] <MerlinTheWizard> Oh, that works? That's even better.
[23:46:23 CET] <MerlinTheWizard> Thanks a lot.
[00:00:00 CET] --- Sat Feb  8 2020