[Ffmpeg-devel-irc] ffmpeg.log.20171030
burek
burek021 at gmail.com
Tue Oct 31 03:05:01 EET 2017
[00:01:40 CET] <c3r1c3-Win> Depends on the implementation, but usually RTMP out-of-the-box is about 30-60 seconds.
[00:02:13 CET] <Cracki> can be 5 secs
[00:02:29 CET] <Cracki> rtmp is an adobe flash technology though...
[00:02:34 CET] <ZeroWalker> oh..
[00:02:50 CET] <Cracki> in any case... do you require this to work in a browser?
[00:02:52 CET] <ZeroWalker> not a fan of adobe flash, isn't there something, newer xd?
[00:02:55 CET] <Cracki> if yes, you have few options
[00:02:57 CET] <c3r1c3-Win> But tons/others support it. Just because it's an Adobe tech doesn't mean much.
[00:03:13 CET] <Cracki> if app, lots more options
[00:03:20 CET] <c3r1c3-Win> HLs is usually 40-90 seconds out-of-the-box.
[00:03:23 CET] <ZeroWalker> depends, it doesn't have to work in a browser, but that could ease things if it did
[00:03:27 CET] <Cracki> browsers only have webrtc or DASH/HLS
[00:03:35 CET] <c3r1c3-Win> DASH is about the same as HLS.
[00:04:06 CET] <Cracki> dash/hls can be configured to have latency on the order of seconds
[00:04:18 CET] <Cracki> that just means small blocks
[00:04:31 CET] <c3r1c3-Win> Yes (and the keyframes to go with it)
[00:04:32 CET] <JEEB> yea, lower segment lengths and then of course you can optimize latency on encoder side as well (less lookahead etc)
[00:04:40 CET] <ZeroWalker> i could make a program in android that does the thing if that's recommended, a browser would just be useful for it's simplicity
[00:05:43 CET] <ZeroWalker> hmm i guess in that case i would want something that's tcp based, as i would need to notice when a connection is dropped
[00:05:45 CET] <Cracki> https://docs.peer5.com/guides/setting-up-hls-live-streaming-server-using-nginx/
[00:05:52 CET] <ZeroWalker> else it would be hard to do a "on demand"
[00:05:55 CET] <Cracki> those things don't have connections
[00:06:09 CET] <Cracki> the server might notice if nobody asks for the segments
[00:06:35 CET] <ZeroWalker> hmm, so it basically sends data to the server
[00:06:39 CET] <Cracki> but usually what happens is that the stream is constantly turned into segments and the most recent N of them are kept for streaming
[00:06:44 CET] <ZeroWalker> and the server will send it to however is connected to it
[00:06:55 CET] <Cracki> and in the case of HLS, the "stream" is a playlist-like thing
[00:07:17 CET] <ZeroWalker> so it's basically small clips so to speak
[00:07:18 CET] <Cracki> of those segments, which are reassembled clientside
[00:07:30 CET] <Cracki> there's javascript that can reassemble them and feed them into the browser's video decoding
[00:07:49 CET] <Cracki> mpeg transport stream files, commonly
[00:08:18 CET] <ZeroWalker> hmm
[00:08:18 CET] <Cracki> afaik only apple devices can do HLS natively. for everything else, there's javascript. it's pretty standard.
[00:08:27 CET] <Cracki> it's just remuxing
[00:08:34 CET] <Cracki> if even that
[00:08:44 CET] <Mavrik> apple devices and Microsoft Edge :P
[00:09:23 CET] <ZeroWalker> yeah, just thinking that it seems to be a roundabout way. it might be easier to just request the data, then a player will wait for it (tcp) and the server will begin transfering to that device
[00:09:32 CET] <ZeroWalker> then when it's closed, it will wait for another request
[00:09:42 CET] <furq> 23:01:40 ( c3r1c3-Win) Depends on the implementation, but usually RTMP out-of-the-box is about 30-60 seconds.
[00:09:45 CET] <furq> uhh
[00:10:12 CET] <furq> that's about 10 times higher than my experience of it
[00:10:36 CET] <ZeroWalker> does html5 players support tcp from ffmpeg?
[00:10:40 CET] <furq> no
[00:10:43 CET] <ZeroWalker> :(
[00:10:52 CET] <furq> html5 players support hls and dash
[00:11:08 CET] <Cracki> ffmpeg is not a streaming server
[00:11:08 CET] <ZeroWalker> didn't they add some kind of matroska support?
[00:11:13 CET] <furq> webm
[00:11:19 CET] <furq> which you can use for fash
[00:11:20 CET] <furq> dash
[00:11:22 CET] <Cracki> mkv is a superset of webm, so they do that
[00:11:30 CET] <Cracki> >fash
[00:11:32 CET] <ZeroWalker> but ffmpeg can stream p2p right?
[00:11:38 CET] <furq> it can stream to a server
[00:11:42 CET] <Cracki> what is p2p to you?
[00:11:47 CET] <furq> it can also write hls or dash fragments, since those are just files served over http
[00:11:54 CET] <ZeroWalker> ffmpeg on server to ffplay on client
[00:11:58 CET] <ZeroWalker> for example
[00:12:03 CET] <furq> you could do that but not to a browser
[00:12:09 CET] <furq> and also ffmpeg will die if there are no clients
[00:12:28 CET] <c3r1c3-Win> furq: Good point. I'm talking about my experience when streaming through a CDN, not direct connections.
[00:12:30 CET] <ZeroWalker> cause that i can do, and then it should be fairly straightforward to just replace ffplay with something else, and then do some kind of automated request thing that activates the stream
[00:12:31 CET] <furq> fwiw you don't have to touch anything adobe to use rtmp
[00:12:44 CET] <furq> ffmpeg to nginx-rtmp to any decent standalone player on the phone
[00:12:44 CET] <Cracki> one end must have a listening socket. ffmpeg only listens once, and only if you ask it to do that
[00:12:57 CET] <furq> and yeah if you're not going through a cdn then less than 5 seconds of latency is trivial
[00:13:06 CET] <ZeroWalker> furq, yeah and that would be fine, as then i could ignore the browser part and just have ffmpeg and some kind of server to do the requests
[00:13:11 CET] <furq> right
[00:13:13 CET] <ZeroWalker> so like if a request goes to camera 1
[00:13:18 CET] <ZeroWalker> it will then simply start ffmpeg
[00:13:26 CET] <furq> i only recommend rtmp because there's an oss server which is easy to set up
[00:13:26 CET] <c3r1c3-Win> You could just write a script to have ffmpeg listen and loop around if it doesn't get anything. ;-)
[00:13:33 CET] <Cracki> ^
[00:13:50 CET] <furq> rtsp is probably better in general but i don't know of anything decent to serve it with
[00:13:57 CET] <c3r1c3-Win> That's what I did to have ffmpeg recompress my stream coming from OBS on a different box.
[00:14:21 CET] <furq> ZeroWalker: you can also do that with nginx-rtmp
[00:14:29 CET] <furq> you can have it pull in a stream on a play request
[00:15:13 CET] <furq> https://github.com/arut/nginx-rtmp-module
[00:15:27 CET] <furq> that's easy to get running so i'd probably set that up and see if it works for you
[00:15:36 CET] <furq> if not then there's probably other routes
[00:15:42 CET] <furq> probably
[00:16:29 CET] <ZeroWalker> hmm, not got any experience with nginx, but will try some stuff out and see where it leads me
[00:17:43 CET] <blap> head towards the light
[00:26:59 CET] <RadSurfer> I'm trying to convert a msmpeg4v3 to h264, with highest quality, can someone help please?
[00:27:45 CET] <RadSurfer> can't seem to lower quality below 28
[00:50:44 CET] <pzich> what happens if you set -crf to something like 10?
[00:50:58 CET] <RadSurfer> It appears to lock down to 25 then
[00:51:22 CET] <RadSurfer> apparently a 700mb file will become 3x that size?? ouch
[00:51:35 CET] <pzich> yeah, you pay a steep price for lossless
[00:51:45 CET] <pzich> or anything closer to it
[01:09:05 CET] <ZeroWalker> if you create your own ssl certificate with openssl, will the encryption and all be fine, and the only thing the browsers etc complain about is that it's not signed by some kind of authority
[01:11:40 CET] <pzich> depending on how you want to set it up, you might be able to get a cert for free at https://letsencrypt.org/
[01:12:52 CET] <RadSurfer> filesize was just a bit larger than original .avi!! so this worked well enough.
[01:17:07 CET] <redrabbit> and letsencrypt.org is quite easy to setup
[01:22:14 CET] <ZeroWalker> oh, well totally new to this, i just did this: https://www.digitalocean.com/community/tutorials/how-to-create-an-ssl-certificate-on-nginx-for-ubuntu-14-04
[01:22:22 CET] <ZeroWalker> if i can get a working thing for free then it's great
[01:22:45 CET] <ZeroWalker> i only want it as i guess if you have a user/pass thing going on, if it's not ssl the data will be sent in plain text
[01:23:15 CET] <redrabbit> letsencrypt.org avoids the issues you get with non-signed certs and its free
[01:23:23 CET] <redrabbit> self-signed
[01:24:26 CET] <ZeroWalker> ah
[01:24:30 CET] <ZeroWalker> will see if i can get it working
[01:25:42 CET] <redrabbit> also, i redirect clients that connect to http to https
[01:26:31 CET] <ZeroWalker> ah, well i only want to use https so that would be nice
[01:30:24 CET] <ZeroWalker> hmm, okay think i atleast got the certificate, maybe, no clue how to set it up with nginx though lo lxd
[01:35:58 CET] <ZeroWalker> okay might be that i am using an ip as i don't own a domain and ssl forbids it it seems
[01:56:19 CET] <DHE> ZeroWalker: off-topic, but encryption is no good if you can't trust that you're communicating with the target you think you are. self-signed certs don't have that level of trust.
[01:57:01 CET] <ZeroWalker> ah
[01:57:41 CET] <DHE> now, you can work around that by making your own certificate authority and adding it to your own browsers. that works if it's just you or your organization using them. otherwise, no do it properly
[01:59:09 CET] <ZeroWalker> hmm, well i might get away with something like that i guess, as i might not even have to use http per see as it's just a p2p, so i could have application to application and then have some kind of encryption going on there or something
[01:59:23 CET] <ZeroWalker> or maybe not, no clue at this point;p
[01:59:43 CET] <ZeroWalker> btw is there a way to make a html button execute code on the server itself
[01:59:48 CET] <ZeroWalker> or rather, a script
[02:25:53 CET] <Quick_Wango> Hi! I'm currently using the loudnorm filter to normalize my audio. On a few Led Zeppelin songs the first pass (measuring) return inf and -inf values for multiple and -70 for the thresholds. Can anyone explain this?
[02:27:00 CET] <Quick_Wango> might that be an encoder problem?
[03:46:26 CET] <Quick_Wango> ok the audio file was just a little broken
[04:12:20 CET] <hendry> is there a way to detect a blank .ts? https://s.natalian.org/2017-10-30/blank.ts
[04:13:19 CET] <Dan0maN> hello all. i'm looking to purchase a usb RCA/S-Video capture device to try to digitize some old VHS and 8mm camera media. was looking at this one: https://www.amazon.com/Hauppauge-610-USB-Live-Digitizer-Capture/dp/B0036VO2BI
[04:13:48 CET] <Dan0maN> anyone have any other suggestions for one of these?
[04:14:12 CET] <Dan0maN> (will be used on a linux host)
[04:16:05 CET] <blap> where are you located Dan0maN
[04:16:55 CET] <blap> well that's nice and convenient (usb)... i still have a hauppage dual-channel pci card here
[04:17:07 CET] <blap> which would be nice if someone would use it
[04:21:41 CET] <hendry> Dan0maN: i prefer the driverless USB UVC ones https://natalian.org/2015/03/13/HDMI_in/
[04:22:42 CET] <hendry> Dan0maN: i would probably get this http://www.magewell.com/usb-capture-hdmi
[04:28:37 CET] <Dan0maN> thanks, hendry. and sorry, blap. i'm working with mostly laptops and tablets these days.
[04:30:22 CET] <Dan0maN> hendry: these look to be hdmi only. i'm having to convert some ancient videos for my mother and wife. will need RCA and/or S-Video inputs
[04:32:24 CET] <hendry> Dan0maN: i'm sure you can find some HDMI adaptors for that
[04:32:44 CET] Action: blap ponders wat do
[04:32:45 CET] <hendry> Dan0maN: aren't there firms that do that for you where you are? it's PAINFUL work
[04:33:15 CET] <hendry> Dan0maN: if it's a linux host, then iirc all that hauppage / blackmagic wont' work. Magewell is the only realistic choice that I've found.
[04:34:08 CET] <Dan0maN> hendry: interesting. i saw this for the hauppage: https://www.linuxtv.org/wiki/index.php/Hauppauge_USB-Live-2
[04:34:24 CET] <Dan0maN> and one of the amazon reviews shows it working for ubuntu with vlc
[04:35:44 CET] <Dan0maN> i personally run centos, but if the 3.6+ kernels support it, then i should be covered by the 3.10. all else fails, i could pxe/livecd an ubuntu if i had to
[04:35:51 CET] <hendry> Dan0maN: don't think i trust that
[04:36:17 CET] <hendry> Dan0maN: i would want to see outputs like `v4l2-ctl -L -d /dev/video0` to get some confidence
[04:36:33 CET] <hendry> but i guess you can always return it, since it's Amazon ?
[04:37:04 CET] <Dan0maN> hopefully
[04:37:26 CET] <Dan0maN> i mean, i just got some mid-ordered matcha tea in that apparently can't be returned. *shrugs*
[04:38:09 CET] <Dan0maN> but thanks for the warnings, hendry. this is why i figured i would ask in here
[04:38:21 CET] <Dan0maN> hoping to find a trustworthy device
[04:43:16 CET] <Chad__> Hello. I'm struggling with getting an image to loop while I have audio input from a mic and pushing to rtmp server. I have figured out stream from my raspberry pi camera with the audio input, however, can't seem to figure out how to remove the video and replace with the image. This is the video command I got to work: ffmpeg -f alsa -ac 1 -i plughw:1,0 -f v4l2 -s 1920x1080 -r 30 -input_format h264 -i /dev/video0 -vcodec copy -preset v
[04:43:29 CET] <Chad__> Hmm. It cut off the command: ffmpeg -f alsa -ac 1 -i plughw:1,0 -f v4l2 -s 1920x1080 -r 30 -input_format h264 -i /dev/video0 -vcodec copy -preset veryfast -r 15 -g 30 -b:v 64k -ar 44100 -threads 6 -b:a 96k -bufsize 3000k -f flv rtmp://rtmp_url
[05:23:38 CET] <SolarAquarion> ibavdevice/decklink_dec.cpp: In function int ff_decklink_read_header(AVFormatContext*):
[05:23:39 CET] <SolarAquarion> libavdevice/decklink_dec.cpp:962:77: error: expected ; before ) token
[05:23:39 CET] <SolarAquarion> st->r_frame_rate = av_make_q(st->time_base.den, st->time_base.num));
[05:34:23 CET] <hendry> hi, what's good guide for a standard 1080p stream bitrate, 720p bitrate and so on? Any resources just for a rough guideline?
[05:35:52 CET] <lindylex> I am trying to add an overlay to my concat videos like this but it is not working : ffmpeg -i c1.mov -i c2.mov -i c3_.mkv -i brandVideos.png -filter_complex " [0:v:0] [0:a:0] [1:v:0] [1:a:0] [2:v:0] [2:a:0] concat=n=3:v=1:a=1 [v] [a], overlay=x=770:y=680 " -map "[v]" -map "[a]" -vcodec libx264 -crf 23 -preset medium -acodec aac -strict experimental -ac 2 -ar 44100 -ab 128k -y love.mp4
[05:53:53 CET] <lindylex> I figured it out. This is how you do it ::: ffmpeg -i c1.mov -i c2.mov -i c3_.mkv -i brandVideos.png -filter_complex " [0:v:0] [0:a:0] [1:v:0] [1:a:0] [2:v:0] [2:a:0] concat=n=3:v=1:a=1 [v] [a]; [v]overlay=x=770:y=680 [out] " -map "[out]" -map "[a]" -vcodec libx264 -crf 23 -preset medium -acodec aac -strict experimental -ac 2 -ar 44100 -ab 128k -y love.mp4
[06:44:04 CET] <thebombzen> apparently Opus supports 5.1 surround sound, but ffmpeg refuses to encode 5.1 surround sound with libopus. is this a bug?
[08:31:37 CET] <lebron_> Hi! I am trying to use ffmpeg for encoding video with vp8_vaapi encoder on Skylake i3 6006u CPU. On centOS im install IntelMediaSDK and compile ffmpeg with --enable-vaapi flag. But when encoding i got error "Failed to query surface attributes: 20 (the requested function is not implemented)."
[08:31:37 CET] <lebron_> <nik> this is afret this command: ffmpeg -vaapi_device /dev/dri/renderD128 -i 1080p.mp4 -vf 'format=yuv420p,hwupload' -c:v h264_vaapi out.mkv
[08:31:37 CET] <lebron_> <nik> can anyone help me with that?
[08:59:12 CET] <hendry> never had any success with h/w driven encoding. i think i've heard ppl on this channel say you're better off with software encoding. Not entirely sure why.
[09:15:16 CET] <JEEB> hendry: hw encoding never was made for good compression ratios. if you need something that doesn't utilize the cpu and you can stick bits at it until it sticks it works f.ex. for capture
[09:15:37 CET] <JEEB> esp. with stuff like lossless cosing being available with newer nvidias :p
[09:16:19 CET] <JEEB> x264's ultrafast or superfast can often end up as fast and have much better compression if you can utilize the cpu
[09:17:30 CET] <JEEB> also the hw asics can only take on X encodes at a time as it's specific hardware for the task. cpu based encoding tends to be mire scalable
[09:29:00 CET] <hendry> JEEB: good stuff
[09:33:50 CET] <hendry> JEEB: whilst you're about, my screen recording tool's mkv cannot be groked by FCPX and most other tools without a heavy re-encode. https://github.com/kaihendry/recordmydesktop2.0/blob/master/x11capture#L55 Why is that?
[09:36:56 CET] <JEEB> I just happened to be around and will not be for a while for anything longer :P
[09:48:49 CET] <inter123> Hello there. I am getting a message of "http 403 forbidden" message(ffmpeg, linux, static build), whereas in my windows pc the link works fine
[09:48:59 CET] <inter123> Does anyone have an idea what am I doing wrong?
[10:05:29 CET] <rabbe> hey.. any SBC's which are good for running ffmpeg?
[10:06:15 CET] <rabbe> since i want USB3 i have my mind on a Rock64 computer
[10:14:58 CET] <sfan5> rabbe: odroid-xu4 might also be worth looking at
[10:15:24 CET] <sfan5> really depends on which task you intend to run on it
[10:16:42 CET] <rabbe> i have a USB3 capture card. intend on capturing 1080p at 60fps, storing files temporarily and provide a REST api for 1 user to fetch it (then delete the file)
[10:18:15 CET] <rabbe> further along, i would like to get WebRTC to work.. v4l2 -> rtsp -> webrtc using a Janus gateway to provide 2-3 clients with a live feed.. (as well as having the REST api to control recording of the stream + fetch recording)
[10:19:14 CET] <rabbe> (alternativly control recording using webrtc data channels)
[10:19:55 CET] <rabbe> odroid-xu4.. i will check out, tnx
[10:23:31 CET] <sfan5> sounds like you need a high-end board for that
[10:25:42 CET] <rabbe> any suggestion?
[10:29:34 CET] <sfan5> nope no idea
[10:30:47 CET] <rabbe> but just for recording and share to one client, it will work with rock64 or xu4?
[10:32:11 CET] <rabbe> i guess i can adjust the quality, but frame rate is important
[10:36:13 CET] <sfan5> do you intend to use x264?
[10:40:15 CET] <rabbe> the solution i had so far (on x86) used ffmpeg to create an h264+aac flv over rtmp to nginx and recording was made by having another ffmpeg saving the rtmp as .ts until ctrl-c, followed by .ts > .mp4
[10:40:37 CET] <rabbe> guess i don't need nginx now
[10:41:28 CET] <rabbe> so i don't know, ffmpeg directly to h264+aac .ts, followed by .ts > .mp4?
[10:42:15 CET] <sfan5> that's a yes
[10:42:22 CET] <rabbe> if i understand correctly, that you cannot save to .mp4 and stop recording with ctrl-c
[10:42:34 CET] <rabbe> u need the .ts step
[10:43:25 CET] <sfan5> since H.264 encoding is quite heavy on the CPU and ARM boards aren't the powerful ones you should consider hardware encoding
[10:43:44 CET] <sfan5> getting it to work on these boards is always a huge mess but they provide predictable performance
[10:44:58 CET] <rabbe> maybe i'm over my head then..
[10:45:24 CET] <Nacht> Good lord I'm building a monster now. Concatting trough filter, scaling and then adding an overlay, in one command
[10:45:42 CET] <sfan5> it's not impossible for x264 to work nicely on an arm board, 1080p60 is just very demanding
[11:14:32 CET] <inter123> Can someone please take a look at my problem? I have posted it here: https://superuser.com/questions/1263719/ffmpeg-on-linux-returns-http-error-403-forbidden-but-in-works-on-windows
[12:59:25 CET] <rabbe> does ffmpeg need any parameters to use hardware encoding?
[13:00:15 CET] <Nacht> rabbe: https://trac.ffmpeg.org/wiki/HWAccelIntro
[13:02:04 CET] <rabbe> Rockchip MPP is used by the Rock64 computer?
[13:08:00 CET] <Nacht> rabbe: I can't say I'm familiar with Rockchip
[13:08:18 CET] <rabbe> seems to be Rock64 related anyway
[13:13:45 CET] <sleepyhead> hi
[13:13:55 CET] <sleepyhead> anyone here familiar with the work of mkvcage?
[13:14:30 CET] <sleepyhead> i just want to know how this particular uploader manages to get his 720p uploads down to such a low file size
[13:14:36 CET] <sleepyhead> non of the others manage to do it
[13:15:28 CET] <sleepyhead> it's all h264.
[13:20:27 CET] <CoreX> sleepyhead send me a link in pm to his work
[14:34:36 CET] <rabbe> sfan5: is hardware encoding working for the xu4?
[14:36:49 CET] <rabbe> using ffmpeg
[15:11:11 CET] <firefish5000> I am trying to merge audio/video from a capture device to mkv AND output a frame every 5 seconds to a png (which I use with imagemagick to detect an end of stream frame)
[15:12:13 CET] <firefish5000> the command I am using atm. ffmpeg -i /dev/video0 -f alsa -i 'sysdefault:CARD=USB20' -c:a copy -c:v copy -f matroska -y tmp.mkv -vf fps=1/5 -update 1 tmp.png
[15:15:32 CET] <firefish5000> if I remove the png output part (everything after tmp.mkv) I get video and audio in the mkv as expected, but with the png output, I only get video, or audio is corrupted. Not sure which
[15:36:42 CET] <firefish5000> This seems to work. ffmpeg -i /dev/video0 -f alsa -i 'sysdefault:CARD=USB20' -c:a copy -c:v copy -f matroska -y pipe:1 | ffmpeg -f matroska -i pipe:0 -c copy -f matroska -y tmp.mkv -vf fps=1/5 -y -update 1 tmp.png
[15:57:01 CET] <sfan5> rabbe_: i'm guessing not, each arm bord usually has a somehow different hwenc solution so you're mostly on your own
[15:57:41 CET] <rabbe_> okay
[15:57:44 CET] <rabbe_> thanks
[16:01:48 CET] <sfan5> if you can afford it a low-end i3 / pentium with vaapi encoding support (which is supported by ffmpeg) might be a better choice
[16:51:26 CET] <schody> Hello, I use this command: ./ffmpeg -i input.avi -ss 800 -f mp4 -vcodec h264 -acodec aac -preset ultrafast -movflags frag_keyframe+empty_moov+faststart - It seems whole input file is decoded as I get long delay between ffmpeg starts to produce output. Is it intended? Produced output is correct regarding -ss flag.
[16:52:01 CET] <schody> I expected the input is seeked to position pointed by -ss
[17:02:11 CET] <diqidoq> Which is the best command line tool option for scaling images under Linux by knowing the algorythm under the hood? ffmpeg? imagemagick? The latter sadly do not show off if it is bilinear or lancosz etc.
[17:04:07 CET] <diqidoq> or at least imagemagick do not say which version of lanczos
[17:37:08 CET] <relaxed> diqidoq: did you look at "man ffmpeg-scaler" ?
[17:37:59 CET] <diqidoq> relaxed: thanks for chiming in. I will check!
[17:42:18 CET] <relaxed> diqidoq: look at https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg and set the algorithm with -sws_flags
[19:09:30 CET] <mbrr> Big thanks to all the developers and contributors to ffmpeg. Been able to achieve very low latency live audio streaming for my work.
[19:09:55 CET] <JEEB> :)
[19:15:51 CET] <mbrr> Last step is getting the audio to play on mobile. Currently it plays with ffplay on my laptop. Couldn't get vlc or any other application to play the opus/mpegts/udp stream.
[19:16:36 CET] <mbrr> I'm installing android-studio with the Native Dev Kit to build an android app that uses ffplay.
[19:16:52 CET] <JEEB> try mpv-android if you want something based on libavformat
[19:17:02 CET] <JEEB> (in the file picker there's a thing to input a URL at)
[19:17:23 CET] <JEEB> also vlc should work with UDP I'd say :/
[19:17:41 CET] <JEEB> it does have a different URL format
[19:17:52 CET] <JEEB> if you are setting the source IP
[19:18:02 CET] <JEEB> (which often is needed on many networks)
[19:18:03 CET] <mbrr> I think the problem with vlc has something to do with opus in mpegts
[19:18:11 CET] <JEEB> ah, then it's just an old vlc
[19:18:27 CET] <JEEB> it plays opus in mpeg-ts with master (upcoming 3.0)
[19:19:21 CET] <mbrr> oh maybe that's it. will try with vlc from source. thanks JEEB!
[19:19:36 CET] <JEEB> np
[19:19:58 CET] <mbrr> will try mvp-android too
[19:20:03 CET] <JEEB> cheers :)
[19:20:11 CET] <JEEB> it's probably the worst android app you've ever seen
[19:20:19 CET] <JEEB> but hey, I'm a multimedia developer
[19:20:34 CET] <JEEB> (and the other devs are more systems developers than UI developers)
[19:20:48 CET] <JEEB> generally though, stuff like multicast over wifi can be rather flakey
[19:20:53 CET] <JEEB> although I guess with audio only it might be better
[19:21:22 CET] <JEEB> I couldn't get RTSP over UDP or multicast UDP to work at my office when I got some streams going :P
[19:21:30 CET] <JEEB> and I wasn't even using wifi
[19:21:36 CET] <JEEB> darn poor networks
[19:22:01 CET] <mbrr> oh. That is what I'm doing - multicast udp. but you were working on video?
[19:22:16 CET] <JEEB> yea I was dealing with a ~13 megabit mpeg-ts pipe
[19:22:36 CET] <JEEB> was getting constant drops even over the wired network due to the switches etc
[19:22:49 CET] <JEEB> but as I noted, a low bit rate audio thing is less likely to have that issue
[19:24:55 CET] <JEEB> I mean, given that you get the multicast over the wifi altogether
[19:24:56 CET] <mbrr> When you say drops, do you mean packets or streams? Would it come right back?
[19:25:02 CET] <JEEB> packets
[19:25:11 CET] <JEEB> and yes, it would stay around, just packet drops etc
[19:25:24 CET] <JEEB> but this was over wired anyways
[19:25:48 CET] <mbrr> I get that when I stream from rpi.
[19:27:15 CET] <mbrr> thinking I'll need to move to a more powerful single board computer
[19:34:09 CET] <mbrr> is mvp-android in the play store or should I pull from github?
[19:34:44 CET] <furq> mbrr: i take it icecast is too high latency
[19:34:57 CET] <pgorley> hi, does 3.4 contain all the hwaccel decode api changes?
[19:35:27 CET] <mbrr> yeah. I didn't even try icecast. need real time
[19:35:47 CET] <JEEB> mbrr: yea it is on the play store :)
[19:35:49 CET] <sfan5> mbrr: it's in the play store, github has identicaly apks anyway
[19:36:00 CET] <sfan5> identical*
[19:36:03 CET] <JEEB> yup
[19:38:13 CET] <mbrr> found it. was searching mvp. thanks
[19:43:42 CET] <mbrr> it works! mpv-android, my savior
[19:44:08 CET] <mbrr> Is there a way to specify the nobuffer flag like I was in ffplay?
[19:44:47 CET] <sfan5> mpv has --no-cache but mpv-android does not provide any way to pass "raw" flags like that
[19:44:48 CET] <mbrr> thank you. thank you. thank you.
[19:45:56 CET] <JEEB> some protocols take parameters also in the URL
[19:51:45 CET] <mbrr> May I fork mvp-android and use it as a base? just need to tweak the buffer size for real time.
[19:52:22 CET] <JEEB> as long as you follow the license (also check the license for the file selector and if it doesn't match drop that one as a depedency)
[19:56:26 CET] <sfan5> hint: it's mpv for "mpv plays video"
[19:56:31 CET] <sfan5> ;)
[19:59:59 CET] <mbrr> and a recursive acronym to top it off. mpv for the win. thanks all
[20:01:33 CET] <JEEB> also do note that (lib)mpv's and FFmpeg's licenses are what in the end decide the license of the whole package, as those are the libraries basically doing all the heavy lifting :)
[20:02:02 CET] <JEEB> although if you're just publicly forking and publishing all the sources you've used you should even be OK with GPL
[20:49:05 CET] <mbrr> thanks sfan5 for these wonder buildscripts and documentation.
[20:49:22 CET] <mbrr> *wonderful
[20:49:44 CET] <JEEB> yea, he did a great job there :)
[22:33:13 CET] <redrabbit> hi
[22:33:23 CET] <durandal_170> hi
[22:33:28 CET] <redrabbit> i tried using -c:v h264_cuvid for hw accelleration on input
[22:33:39 CET] <redrabbit> it works well however mpeg2 content fails with this
[22:33:53 CET] <redrabbit> and its for a streaming software that uses 1 line for any type of content
[22:34:06 CET] <durandal_170> mpeg2 is not h264
[22:34:09 CET] <redrabbit> so i tried -hwaccel cuvid but it doesnt use hw accell
[22:34:11 CET] <redrabbit> yep
[22:34:22 CET] <redrabbit> i need something that works with both
[22:34:44 CET] <redrabbit> suposedly -hwaccel cuvid does but it didnt enable hw decoding for me
[22:38:16 CET] <redrabbit> h264_cuvid mjpeg_cuvid mpeg2_cuvid vc1_cuvid vp9_cuvid hevc_cuvid mpeg1_cuvid mpeg4_cuvid vp8_cuvid
[22:39:11 CET] <redrabbit> meh.. looks like i have to stick with sw decoders because i dont see a way to use hw decoding with 1 line that fits with both mpeg2 and avc
[22:39:43 CET] <durandal_170> no
[22:42:53 CET] <redrabbit> so its not possible?
[22:44:28 CET] <pgorley> you could do a bash script or something
[22:44:59 CET] <redrabbit> well im not sure i can, its only a config file in a streaming iptv software
[22:45:26 CET] <pgorley> :/
[22:45:36 CET] <redrabbit> maybe request such feature and sit tight
[22:45:42 CET] <redrabbit> erf
[22:48:19 CET] <pgorley> you could poke the cuvid maintainer, maybe they plan on making it follow the hwaccel api instead of using only standalone hw decoders
[22:58:30 CET] <orbea> Hi, idk how or why, but suddenly the ffmpeg configure script started reaching an infinite loop on my system... I traced it to line 6668 in the master: unique ${linkunit}_extralibs
[22:58:38 CET] <redrabbit> with hw decoder : 2.30% cpu, without : up to 25%
[22:58:38 CET] <redrabbit> :(
[22:58:43 CET] <orbea> I managed to work around it with this, but im not sure this is correct? http://dpaste.com/2X4N5B7
[22:58:50 CET] <redrabbit> good idea to try with cuvid
[23:13:43 CET] <geri> hi
[23:13:55 CET] <geri> what video codec you recommend for screen recording?
[23:14:05 CET] <geri> screen capture
[23:14:09 CET] <geri> i was reading about TechSmith or iSCC
[23:17:14 CET] <furq> neither of those are part of ffmpeg, so probably not those
[23:17:42 CET] <geri> ok
[23:17:54 CET] <geri> whats recommended with ffmpeg lib?
[23:18:44 CET] <furq> probably ffv1
[23:18:54 CET] <geri> i could only store those frames which include changes on the screen...
[23:18:57 CET] <furq> or maybe qtrle if you're doing desktop capture
[23:19:11 CET] <geri> are those codecs doing somth like that?
[23:19:18 CET] <furq> ffv1 does
[23:19:21 CET] <furq> well
[23:19:25 CET] <furq> actually nvm i misread that
[23:19:37 CET] <furq> no, but ffv1 does inter-frame compression, so any unchanged frames will be very small
[23:19:48 CET] <furq> same with x264 lossless but i don't think that does particularly well with rgb
[23:20:13 CET] <geri> it would be good if you could pass the video codec only those changes somehow'
[23:20:32 CET] <geri> so in case if nothing changes the data beeing transferred will be small
[23:20:32 CET] <furq> there are filters you can use to drop unchanged frames
[23:20:45 CET] <furq> the capture device will still send every frame though
[23:21:06 CET] <furq> !filter mpdecimate @geri
[23:21:06 CET] <nfobot> geri: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate
[23:21:07 CET] <geri> in full resolution?
[23:21:14 CET] <furq> yes
[23:21:30 CET] <furq> you can adjust the capture framerate but that's probably not a great solution
[23:24:27 CET] <geri> when i look at opencv the framerate should be constant
[23:25:17 CET] <geri> is ffv1 fast?
[23:25:27 CET] <furq> it should be fast enough
[23:25:36 CET] <furq> depends what the resolution and framerate is, and what cpu you're using
[23:25:54 CET] <geri> faster than 'H264'
[23:26:05 CET] <geri> or X264
[23:26:11 CET] <furq> depends what x264 settings you're using
[23:26:21 CET] <furq> it's probably slower than x264 ultrafast but i'd expect it to be smaller for rgb
[23:31:36 CET] <Cracki> ffv1 has noticeable inter-frame compression? hm... last time, I didn't get that to work
[23:35:19 CET] <furq> sure
[23:35:29 CET] <furq> try -f lavfi -i smptebars -c:v ffv1
[23:35:38 CET] <furq> then compare that with ffvhuff or something
[23:36:14 CET] <Cracki> -c:v ffv1 -g 1500 still gives me huge data rates
[23:36:32 CET] <Cracki> does it need some more arguments?
[23:37:07 CET] <geri> how is DIVX performance?
[23:37:10 CET] <Cracki> (on screencast source)
[23:37:17 CET] <furq> http://vpaste.net/5U6Ma
[23:38:42 CET] <Cracki> 120 kbit/s for a static image is a bit much, I think
[23:38:50 CET] <Cracki> suggests intra-only
[23:38:56 CET] <Cracki> does it do inter-frame too?
[23:39:50 CET] <Cracki> ok my screencast source might be bad... i'll try another
[23:40:38 CET] <geri> H264 supports inter compression?
[23:40:55 CET] <Cracki> got a qtrle source with static content, still 15 Mbit/s
[23:41:15 CET] <Cracki> most video codecs get their data rate down by using inter-frame compression
[23:42:13 CET] <Cracki> ah! ffv1 does no inter-frame prediction at all
[23:43:03 CET] <Cracki> I should spend some time on the qtrle encoder code...
[23:43:11 CET] <geri> are those videowriters in opencv always assume const framerate? https://docs.opencv.org/3.3.0/dd/d9e/classcv_1_1VideoWriter.html
[23:43:19 CET] <Cracki> yes
[23:43:27 CET] <Cracki> but nobody here is supposed to know that
[23:45:53 CET] <furq> Cracki: what is ffv1 doing then
[23:46:21 CET] <Cracki> intra
[23:46:36 CET] <furq> i mean how is it so small compared to other intra-only codecs
[23:46:48 CET] <Cracki> I wouldn't know
[23:46:59 CET] <Cracki> perhaps other intra-only codecs are just _dumb_
[23:48:03 CET] <Cracki> https://en.wikipedia.org/wiki/FFV1#Compression_details
[00:00:00 CET] --- Tue Oct 31 2017
More information about the Ffmpeg-devel-irc
mailing list