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

[burek]

[09:27:17 CEST] <hotbobby> I am looking for a suggestion of a RTSP streaming server that works with ffmpeg. I can only find proprietary solutions, all in one streaming software etc, nothing like nginx+rtmp module but for rtsp
[09:28:28 CEST] <JEEB> yea, rtsp is definitely not as popular as those HTTP-based things nowadays
[09:29:00 CEST] <hotbobby> i am researching alternative protocols due to low performance of flv video over high latency (not low bandwidth) connections
[09:29:48 CEST] <hotbobby> if you ask me the popularity of rtmp is unwarranted :P
[09:30:55 CEST] <JEEB> yes, and it really isn't popular any more
[09:31:11 CEST] <JEEB> other than as an ingest format since most people are lazy to implement fragmented ISOBMFF or NUT or Matroska :)
[09:31:34 CEST] <JEEB> even the nginx-rtmp module supports HLS and DASH which are very popular because those pesky browsers can use XHR to access the stream
[09:32:04 CEST] <Nacht> RTMP is nice for low latency though
[09:32:42 CEST] <hotbobby> oh even hls gave me poor performance. rather, it worked fine for the duration of chunk length but left me hanging a few seconds in between
[09:33:07 CEST] <JEEB> usually players should be buffering ~3 segments
[09:33:28 CEST] <JEEB> Nacht: I'd say anything that isn't chunk-based should be better than the HTTP stuff we have right now :D
[09:33:42 CEST] <hotbobby> oh im just using vlc with the default options. i should look into that
[09:33:45 CEST] <JEEB> the chunk-based stuff is currently 100% because of browsers not being able to keep reading
[09:33:46 CEST] <kaninte> Hi! I'm trying to encode home videos so that I can archive them in my NAS. The goal is ofcourse to have small files with good quality. Using ffmpeg I get quite a size reduction but when I compare with other files for instance a whole 2h movie encoded to around 1.5GB my files are huge. Is there a standard way to do what I'm trying to do?
[09:33:59 CEST] <JEEB> or well, they can read but they will also keep buffering I think?
[09:34:30 CEST] <JEEB> like, even if you just do MPEG-TS over HTTP as a single stream that should have pretty low latency as long as you set up your encoder and player correctly
[09:34:36 CEST] <JEEB> or Matroska
[09:34:52 CEST] <hotbobby> you see, originally my files are mpeg 2 transport streams that are like 15 mbps
[09:35:04 CEST] <hotbobby> i wish i could ust reencode at a lower bitrate but leave the ts alone! :P
[09:35:08 CEST] <Nacht> 15Mbps total ?
[09:35:26 CEST] <hotbobby> total? per second, yes
[09:35:34 CEST] <Nacht> As in, all the different bitrates together ?
[09:35:42 CEST] <hotbobby> the entire stream, yes
[09:36:29 CEST] <Nacht> I quite like HLS, it's simple and does the job.
[09:37:59 CEST] <hotbobby> kaninte: the way youve worded your question seems confusing. without going into detail you may not care about i suggest encoding your camera files as x264 at a decent enough bitrate you do not notice the degredation in quality. if you need help forming a command to do this just say so
[09:38:48 CEST] <hotbobby> Nacht: i really want to like hls but it has that weird stuttering. perhaps i need to mess with different settings or just not watch inside of vlc
[09:39:11 CEST] <Nacht> hotbobby: The manifest is looking normal ?
[09:39:23 CEST] <JEEB> you will have issues if the latency doesn't go completely bonkers and your segment length is long enough
[09:39:29 CEST] <JEEB> *is not long enough
[09:39:38 CEST] <JEEB> argh, fuck my morning English
[09:39:52 CEST] <hotbobby> i think segment length was 10s, but yes the latency -does- go bonkers thats the use case im trying to solve around
[09:40:01 CEST] <kaninte> hotbobby: well, I was asking for a typical/standard way to encode videos for archiving. But yes, I use x264 crf:23 for video and ACC br:128. Do you have any suggestions?
[09:40:05 CEST] <JEEB> basically if you have enough time to get the responses for the future segments that'll work as long as you're within two or so segments
[09:40:22 CEST] <JEEB> but if your latency is really bonkers then the player will go through three segments and boom :P
[09:40:40 CEST] <hotbobby> is there a standard way to encode video for arching? :P maybe losslessly
[09:40:42 CEST] <JEEB> (a player with a general reading of the spec should have ~3 segments buffered)
[09:40:50 CEST] <Nacht> Which are usually the first 2-3 segments your player is required to have to fill the buffer
[09:40:56 CEST] <JEEB> they're trying to standardize FFV1 and Matroska for archival now in the EU
[09:42:09 CEST] <hotbobby> i wish there was a hls that chunked on a single frame basis, i thought thats what rtmp does
[09:42:16 CEST] <kaninte> hotbobby: yes, if you record movies of your baby and you want to store them and you don't want to upgrade your storage every week for the videos to fit :)
[09:42:43 CEST] <hotbobby> like ideally i would just be taking my mpeg 2 stransport stream and lower the video bitrate so its not incredibly large :(
[09:43:55 CEST] <hotbobby> kaninte: go all in on x265 maybe. it is -a- future but not -the- future :o
[09:44:34 CEST] <hotbobby> hevc makes some tiny files but only the last 2(?) generations of intel cpus have hardware decoders for it
[09:45:37 CEST] <kaninte> hotbobby: I've thought of that but what I've read x265 is more efficient on 4k videos. My videos are Full HD. Or do you mean that x265 has a better compression rate?
[09:46:05 CEST] <JEEB> it is a better format in general but unfortunately it lacks a lot of love
[09:46:11 CEST] <JEEB> I would not use it unless you specifically need HEVC
[09:46:15 CEST] <hotbobby> its more efficient for any video, its cool seeing full episodes of shows being around a hundred megabytes
[09:46:34 CEST] <hotbobby> but uhh yeah its the playback part thats not practical
[09:46:41 CEST] <JEEB> no, the encoding one too
[09:46:53 CEST] <kaninte> really? that's cool
[09:46:57 CEST] <JEEB> as far as I've seen due to the lack of community around x265
[09:47:12 CEST] <JEEB> the encoder is not really anywhere close to being realistic to use
[09:47:24 CEST] <JEEB> other than for very low bit rate scnearios where you will have artifacts in any case
[09:47:30 CEST] <JEEB> and it's not the *format's* fault
[09:47:34 CEST] <JEEB> the format is fine
[09:47:46 CEST] <bencoh> well, for file encoding it's roughly fine
[09:47:54 CEST] <bencoh> but don't expect to use it for live encoding
[09:48:06 CEST] <JEEB> well this seemed to be some archival use case?
[09:48:13 CEST] <JEEB> in which case something something lossless something something
[09:48:37 CEST] <kaninte> but still my confusion is why "other" people can compress hour long movie to around 900MB with good quality and whatever I do I get 13min video around 600MB with same codec for video/audio
[09:48:44 CEST] <hotbobby> lossless and save space by using black and white and mono audio :)
[09:49:24 CEST] <kaninte> JEEB: Yes, just home videos I want to store.. but I will be making more all the time so I would like them to be small
[09:50:24 CEST] <Nacht> kaninte: Most likely using higher CRF values
[09:52:01 CEST] <kaninte> Nacht: I've been expermenting with CRF all weekend :) Problem is the only way I get comparable file sizes is using values like CRF=30. This really makes bad quality video
[09:53:38 CEST] <hotbobby> do -crf and -b:v contradict eachother?
[09:54:14 CEST] <kaninte> What do you mean?
[09:54:20 CEST] <hotbobby> for example can i set a ceiling with the video bitrate flag and an attempted quality with crf? or does crf kind of take care of that itself
[09:55:06 CEST] <kaninte> CRF uses variable bit rate so I've not try to assign a static value
[09:56:26 CEST] <Nacht> Another option to try is using 2-pass encoding
[09:57:00 CEST] <kaninte> Nacht: You mean using constant bitrate?
[09:57:20 CEST] <kaninte> I thought that is discouraged
[09:57:42 CEST] <hotbobby> i was live streaming at a constant bitrate until a few moments ago...
[09:58:09 CEST] <hotbobby> crf is really cool i wish i had read the documentation more closely :P
[09:58:27 CEST] <Nacht> 2-Pass encoding uses a constant bitrate, but allocates the bitrate to the places that need it most
[09:59:02 CEST] <kaninte> Nacht: Hmm..I didn't know that
[09:59:21 CEST] <JEEB> uhh, constant is usually used in a different context
[09:59:29 CEST] <JEEB> that's usually called ABR (AVERAGE bit rate)
[09:59:58 CEST] <JEEB> constant bit rate is when you are within some VBV/HRD parameters and keep the bit rate generally constant'ish within those parameters throughout the stream
[10:04:07 CEST] <hotbobby> wow this is amazing, -crf 50 and -q:a 9 turn a 14mbps stream into like 50 kBps
[10:04:27 CEST] <hotbobby> this works fine without stuttering on my cellular connection it's a shame it looks so bad :o
[10:05:04 CEST] <kaninte> hotbobby: what does -q:a do?
[10:05:13 CEST] <bencoh> I'ms sure it looks fine on a 64x64 display
[10:05:43 CEST] <hotbobby> kaninte: crf for libmp3lame, 9 is worst 0 is best quality
[10:07:04 CEST] <kaninte> hotbobby: It's for the audio?
[10:07:14 CEST] <hotbobby> yes, variable bitrate audio
[10:07:34 CEST] <hotbobby> whereas -b:a 320k would be constant (i think)
[10:08:00 CEST] <JEEB> audio encoders generally don't have ABR rate control
[10:08:06 CEST] <JEEB> which is why that ends up being CBR'ish
[10:08:12 CEST] <JEEB> (depending on the exact encoder)
[10:08:51 CEST] <kaninte> Yeah I had no idea that you could even do that for audio
[10:10:07 CEST] <JEEB> generally audio takes so much less space that people generally only tend to implement quantizer-based VBR and something pretty much CBR
[10:10:19 CEST] <JEEB> there's just not that much worth optimizing there in general
[10:11:13 CEST] <hotbobby> yeah i am not really enjoying any real space saving encoding audio at 64k as opposed to v0. i think v0 averages ~260k
[10:11:39 CEST] <bencoh> just set a constant bitrate for audio, don't bother playing with that
[10:11:44 CEST] <bencoh> :)
[10:13:16 CEST] <hotbobby> is it possible to pass through the audio from the source untouched?
[10:13:38 CEST] <hotbobby> reencoding lossy mp3 to lossy mp3 again is..... lame :o
[10:15:56 CEST] <hotbobby> -c:a copy
[10:45:15 CEST] <kaninte> Anyone used the preset tuning? How much difference could you expect?
[10:46:35 CEST] <JEEB> it depends on various things, you should generally use the slowest preset that is fast enough for your use case
[10:46:46 CEST] <JEEB> in libx264 at least
[10:47:35 CEST] <kaninte> There are additional tunings like film,animation,grain, etc..
[10:48:03 CEST] <JEEB> yes, tunes are tunes
[10:48:06 CEST] <JEEB> presets are presets
[10:48:23 CEST] <JEEB> tunes are not required
[10:48:36 CEST] <JEEB> presets are something you should set although 'medium' (default) is not bad
[10:48:46 CEST] <kaninte> I know, but how much gain will you get using them?
[10:49:08 CEST] <kaninte> I thought tunes are part of preset.. oops :)
[10:51:27 CEST] <JEEB> nope
[10:53:48 CEST] <hotbobby> there is an excellent table that defines the commands used in presets for extra finetuning http://dev.beandog.org/x264_preset_reference.html
[10:54:13 CEST] <hotbobby> i believe the ones that make the biggest different are scene changes and lookahead?
[10:55:05 CEST] <kaninte> thanks
[13:28:53 CEST] <alqemyst> hi, does anybody knows is it possible to stream mpegts to unix domain socket?
[13:29:07 CEST] <JEEB> why not?
[13:29:56 CEST] <alqemyst> I'm looking to unix.c, but can't find the way to do it
[13:30:19 CEST] <alqemyst> is socket created with ffmpeg?
[13:38:13 CEST] <Nacht> alqemyst: https://ffmpeg.org/ffmpeg-protocols.html#unix
[13:40:02 CEST] <alqemyst> but what is the syntax then: -f mpegts unix:///var/run/test.sock
[13:41:07 CEST] <Nacht> That should work I believe
[13:41:43 CEST] <alqemyst> hm..
[13:41:44 CEST] <alqemyst> unix:///var/run/test.sock: No such file or directory
[13:45:50 CEST] Action: mrAZ looking for help with -map or -map_channel option: needed to extracl left from 2nd audio channel to 1+2nd channel(mono)
[13:46:55 CEST] <alqemyst> if I change this line in unix.c then socket is created, but nothing happends really
[13:47:00 CEST] <alqemyst> { "listen",    "Open socket for listening",             OFFSET(listen),  AV_OPT_TYPE_BOOL,  { .i64 = 1 },
[13:51:07 CEST] <alqemyst> but when I connect first reader it start with encoding, when I stop reader it breaks
[13:51:11 CEST] <alqemyst> strange
[13:52:34 CEST] Action: mrAZ have detected the channels https://paste.ubuntu.com/25514054/ so i think i would need 0.2.0, but then how to map it to 2 mono channels?
[13:53:59 CEST] Action: mrAZ or do i need pan option?
[13:55:35 CEST] <Nacht> mrAZ: Both should suffice. https://trac.ffmpeg.org/wiki/AudioChannelManipulation
[13:55:56 CEST] <mrAZ> Nacht: i was reading that
[14:24:58 CEST] <alqemyst> it works if socket is created before ffmpeg
[14:25:00 CEST] <alqemyst> socat - UNIX-LISTEN:/var/run/test.sock
[14:25:31 CEST] <alqemyst> but if ffmpeg is stopped it also destroys the socket, which is not correct behaviour in my opinion
[15:12:32 CEST] <paveldimow> Hi, anyone knows if it's possible to have one process to write mp4a file while other is reading/playing ?
[15:12:42 CEST] <JEEB> fragmented isobmff
[15:13:24 CEST] <paveldimow> that was FAST :)
[15:14:24 CEST] <JEEB> basically set the fragment duration accordingly (with audio only it can be as short as a single sample if you *really* want)
[15:14:36 CEST] <JEEB> and the muxer should write fragmented output
[15:14:50 CEST] <JEEB> now, of course it depends on what is reading that thing, if it supports movie fragments
[15:15:44 CEST] <paveldimow> Huh, Wowza (media server we are using) does not support fmp4 :(
[15:16:00 CEST] <paveldimow> my idea was to use wowza to save live audio
[15:16:47 CEST] <paveldimow> while I have ffmpeg to read that file and use uct/trim to get the segment user requested...
[15:16:55 CEST] <DHE> maybe use a different format then? mpegts maybe?
[15:17:09 CEST] <DHE> not a wowza user, just throwing out ideas
[15:17:26 CEST] <paveldimow> IIRC they can only use mp4 for recording
[15:17:39 CEST] <paveldimow> but I will check thank you JEEB and DHE
[15:23:37 CEST] <grkblood13> I'm having an issue with mapping. Whenever I run the following script I get the error: "Invalid input file index: 1." Could someone tell me what's wrong? https://pastebin.com/a4QqknLN
[15:25:44 CEST] <klaxa> i think you want 0:1 instead of1:0
[15:26:10 CEST] <klaxa> doesn't look like you have 2 input files, but only one
[15:26:37 CEST] <klaxa> wait... what are you trying to do?
[15:26:56 CEST] <grkblood13> this: http://wiki.webmproject.org/adaptive-streaming/instructions-to-do-webm-live-streaming-via-dash
[15:27:10 CEST] <grkblood13> take an input source and make two seperate output sources i believe
[15:27:28 CEST] <grkblood13> i tried 1:0 thinking that might work but it was the same thing.
[15:27:57 CEST] <klaxa> huh... 1:0 should be correct
[15:28:23 CEST] <klaxa> are you using alsa or pulseaudio? if you are using pulseaudio you should use: -f pulse -i default instead of -f alsa [...] -i hw:2
[15:28:29 CEST] <klaxa> maybe you need to use hw:0 also?
[15:28:38 CEST] <klaxa> instead of hw:2 i mean
[15:28:42 CEST] <klaxa> not too good with alsa
[15:28:52 CEST] <grkblood13> well, i took all of that out since my input is different
[15:29:06 CEST] <grkblood13> in my script im just doing -i $1
[15:29:15 CEST] <grkblood13> $1 being a stream link
[15:29:15 CEST] <klaxa> then you have no second input
[15:29:31 CEST] <klaxa> does it have audio? then you want -map 0:1 instead of -map 1:0
[15:29:50 CEST] <grkblood13> alright, thanks
[15:29:53 CEST] <klaxa> although that will only map it to the second output and not to the first
[15:30:09 CEST] <klaxa> you could skip using -map altogether and it will use video and audio for both by default
[15:30:46 CEST] <grkblood13> well, i have to map if its using different codecs correct?
[15:31:01 CEST] <grkblood13> their tutorial uses vp9 for one and vp8 for the other
[15:31:41 CEST] <klaxa> i'm not 100% sure, but i don't think so, otherwise use -map 0:0 -map 0:1 in front of -c for both outputs
[15:33:57 CEST] <c_14> klaxa: I think one of the outputs is audio-only and one video-only, so what he's doing is correct (barring the 1:0 0:1 switchup)
[15:34:38 CEST] <c_14> (as in, he doesn't want to map both streams in both outputs)
[15:34:52 CEST] <klaxa> >-c:a libvorbis \
[15:34:52 CEST] <klaxa> >  -c:v libvpx \
[15:34:57 CEST] <klaxa> that tells a different story though :P
[15:35:29 CEST] <c_14> yeah, but he sets the video bitrate for one and the audio bitrate for the other
[15:35:31 CEST] <c_14> never both
[15:35:39 CEST] <c_14> and he sets audio_chuck_duration for only the second one
[15:36:17 CEST] <c_14> Though he does set -deadline for the second output instead of the first
[15:36:23 CEST] <c_14> Which is a libvpx-only option
[15:36:35 CEST] <grkblood13> well, the script is working now so thats good
[16:35:41 CEST] <paveldimow> Can I read/write to flv at the same time?
[16:36:03 CEST] <paveldimow> I can't find any usable info about it
[16:43:00 CEST] <paveldimow> heh it looks like flv is indeed read/write compatible! what a nice format :)
[17:18:35 CEST] <Fyr> guys, are there ARM computers for encoding?
[17:19:08 CEST] <Fyr> I mean computers, like Raspberry Pi, but designed particularly to encode video.
[17:22:33 CEST] <Nacht> Well.. yeah. Hardware encoders
[17:22:52 CEST] <Nacht> Like Ericson or Harmonics
[17:23:14 CEST] <Nacht> Ericsson*
[17:23:43 CEST] <Nacht> https://www.harmonicinc.com/
[17:25:22 CEST] <klaxa> many GPUs include encoding hardware as well
[17:26:45 CEST] <Mavrik> They're just not good.
[17:27:29 CEST] <klaxa> is there any "good" encoding hardware?
[17:29:15 CEST] <Nacht> I quite enjoyed my old Envivio encoders. They were quite good
[17:30:04 CEST] <Mavrik> Envivios are okish, but still can't really compete with Xeon servers running x264
[17:30:13 CEST] <furq> can anything
[17:30:44 CEST] <Mavrik> Nope.
[17:30:53 CEST] <furq> i'm glad we cleared that up
[17:30:58 CEST] <Mavrik> I think Cisco and some of those now actually sell you a "hardware encoder"
[17:31:05 CEST] <Mavrik> Which is a Xeon box with their software running x264 :P
[17:31:08 CEST] <furq> nice
[17:31:12 CEST] <furq> not even their own h264 encoder
[19:48:01 CEST] <Fyr> can FFMPEG utilize Intel Phi?
[19:52:39 CEST] <JEEB> Fyr: no
[19:52:49 CEST] <kepstin> but Intel VCA/VCA2 should work fine
[19:52:59 CEST] <kepstin> (they're just some xeon chips on pcie cards)
[19:55:23 CEST] <Fyr> JEEB, why does FFMPEG keep avoiding AMD's VCE?
[19:55:49 CEST] <JEEB> I don't think it does? nobody just cared about it is the real thing. although doesn't it expose something through VA-API?
[19:55:55 CEST] <JEEB> VA-API is something that FFmpeg supports
[19:56:18 CEST] <Fyr> on Linux, yes.
[19:57:02 CEST] <JEEB> on windows you have dxva2
[19:57:21 CEST] <JEEB> encoding wise someone has to give a shit and since FFmpeg is a community project... :P
[19:57:29 CEST] <Fyr> it doesn't bring actually acceleration.
[19:57:55 CEST] <JEEB> uh-huh, this HEVC dxva2 decoding through lavc totally is just a mistake and never happened
[19:57:57 CEST] <JEEB> nod nod
[19:58:30 CEST] <JEEB> of course I have no idea if ffmpeg.c supports it, but that's now none of my problem (´4@)
[20:07:06 CEST] <stripes416> win 2
[20:07:17 CEST] <stripes416> geez, sorry y'all
[21:17:21 CEST] <analogical> hi is it possible to convert an MKV-file to an MP4-file without re-encoding the file??
[21:17:37 CEST] <JEEB> ffmpeg -i input.mkv -c copy out.mp4
[21:17:46 CEST] <analogical> ...using FFMPEG
[21:17:47 CEST] <JEEB> (add -map 0 if you want all streams from input)
[21:27:01 CEST] <iive> have in mind that mp4 supports less formats than mkv :D
[21:29:02 CEST] <JEEB> well that's a given, yes
[21:46:52 CEST] <kmax> help
[21:47:28 CEST] <kmax> any HLS gurus in here?
[21:47:52 CEST] <kmax> using HLS to get RTSP video from cctv cams out to html5 video
[21:48:12 CEST] <kmax> creating the m3u8 on the fly... takes a long time
[21:48:23 CEST] <kmax> trying to figure out if there is a way to speed it up
[21:48:37 CEST] <kmax> tried lowering the length of the chunks etc etc
[21:57:44 CEST] <kmax> anyone know of a forum dedicated to ffmpeg support?
[22:01:35 CEST] <c7j8d9> doom9?
[00:00:00 CEST] --- Tue Sep 12 2017