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

[burek]

[00:00:49 CET] <oftc_ftw> furq: just fyi, its 556M to 4.2G; going to upload now
[00:10:46 CET] <haroldp> furq: thanks so much for your help today.
[00:14:33 CET] <alexpigment> oftc_ftw: just a note on your convo about the DVDs. if you do happen to have both DVD copies and also MP4 copies for browser viewing, make sure and deinterlace to 480p60 (or 576p50 if you're in a PAL region)
[00:15:00 CET] <alexpigment> most people seem to be fine with throwing away half of the temporal resolution online, but that sticks out to my eyes way more than a slightly-lossy encoding
[00:15:19 CET] <ZexaronS> libav doesn't have trac ?
[00:15:52 CET] <oftc_ftw> alexpigment: i am no professional, but wouldn't lossless conversion imply original frame rate?
[00:16:15 CET] <JEEB> ZexaronS: the libav* libraries in FFmpeg are part of FFmpeg
[00:16:20 CET] <ZexaronS> oh nvm, it has a an irc channel
[00:16:21 CET] <JEEB> so FFmpeg's trac is the correct place
[00:16:32 CET] <JEEB> libav is a separate project, yes
[00:16:39 CET] <ZexaronS> ah so ffmpeg project created libav?
[00:17:16 CET] <JEEB> FFmpeg is a project that has libraries such as libavcodec, libavformat etc.
[00:17:21 CET] <JEEB> Libav is a fork of FFmpeg from 2011
[00:17:22 CET] <ZexaronS> eh, i meant, if I want to contribute to libav
[00:17:35 CET] <JEEB> which also provides its own versions of those libraries
[00:17:51 CET] <JEEB> I will guess you meant FFmpeg's libraries and not Libav the project
[00:18:02 CET] <JEEB> at least, given that you're on #ffmpeg
[00:18:03 CET] <ZexaronS> I just want to see if I can contribute to libavfilter that ffmpeg uses, im not insterested in other forks that ffmpeg isn't using
[00:18:18 CET] <ZexaronS> these names are confusing
[00:18:23 CET] <JEEB> yes, libavfilter that you've built from FFmpeg is FFmpeg's
[00:18:38 CET] <JEEB> so trac.ffmpeg.org is the correct place to report issues / feature requests
[00:18:46 CET] <ZexaronS> so there's more flavors of libavfilter ?
[00:18:56 CET] <JEEB> well Libav also contains libavfilter of their own :P
[00:19:00 CET] <alexpigment> oftc_ftw: if you don't specify how interlaced content is handled in FFMPEG, you end up with progressive usually
[00:19:01 CET] <JEEB> as it's a fork
[00:19:37 CET] <ZexaronS> Not sure what's the point of keeping the name if both aren't related
[00:19:39 CET] <alexpigment> oftc_ftw: and i don't think browsers / web players support interlacing to my knowledge
[00:20:01 CET] <JEEB> ZexaronS: you can think of Libav as some developers of let's call it FFmpeg-old
[00:20:10 CET] <JEEB> who forked as Libav
[00:20:21 CET] <JEEB> so yes, the base was the same
[00:20:37 CET] <JEEB> FFmpeg merges most of what Libav does so most improvements made in Libav get into FFmpeg
[00:20:38 CET] <alexpigment> now to be clear, i'm not implying that deinterlacing is a good idea for posterity, but if your goal is to have something playable on the web, you want to do x264 with deinterlacing
[00:20:54 CET] <JEEB> on the other hand Libav only does backports if someone posts a patch to Libav
[00:21:00 CET] <JEEB> (and goes through their review process)
[00:21:11 CET] <ZexaronS> but if I want a certain thing in libavfilter then I can do it through ffmpeg trac?
[00:21:16 CET] <JEEB> yes
[00:21:30 CET] <oftc_ftw> alexpigment: ok, do you quickly have a parameter that does deinterlace? or is it more complicated than that?
[00:21:36 CET] <ZexaronS> and libav doesn't necessairly merge those into their stuff ?
[00:22:05 CET] <ZexaronS> it's somewhat convoluted but I get it now
[00:22:50 CET] <alexpigment> -vf yadif=1:-1:0
[00:22:50 CET] <furq> oftc_ftw: -vf yadif=1
[00:22:55 CET] <furq> assuming your input is actually interlaced
[00:23:03 CET] <ZexaronS> jeeb: did you saw the idea i talked about earlier?
[00:23:14 CET] <alexpigment> furq: if it's coming from VHS to DVD and it's not done by an idiot, it's probably interlaced ;)
[00:23:23 CET] <furq> oh right i forgot the vhs bit
[00:23:26 CET] <JEEB> ZexaronS: nope
[00:24:10 CET] <oftc_ftw> thanks guys :)
[00:24:23 CET] <alexpigment> oftc_ftw i specified 1:-1:0 for completeness sake, but the last two values are probably implied, so furq's solution might be equivalent
[00:24:25 CET] <haroldp> If I wanna do HTML5 streaming video instead of Flash RTMP, what is a better streaming proto?
[00:24:33 CET] <furq> hls
[00:24:36 CET] <furq> which you can do with nginx-rtmp if you want
[00:25:00 CET] <oftc_ftw> alexpigment: noted, thanks
[00:30:31 CET] <haroldp> can I just set "hls on;" in the app I have, or do I need a seperate app for it?
[00:31:05 CET] <furq> you can pretty much just do that
[00:31:15 CET] <furq> you'll need hls.js for it to work on desktop
[00:36:39 CET] <obamoose> can someone help me out with setting up a stream ;_;?
[00:40:17 CET] <xtina> hi, can anyone remind me the correct syntax for h264-encoded video capture with ffmpeg?
[00:40:19 CET] <haroldp> erm, do I need to enable an http server in nginx to server this?
[00:40:35 CET] <oftc_ftw> alexpigment: i happen to live in a PAL region, could you kindly elaborate on that 576p50? i've never heard of such a thing actually. does it depend on the input? i would not care if the output is not PAL. (should i?)
[00:40:54 CET] <oftc_ftw> is this reasonable? -c:v libx264 -vf scale=-1:720 -vf yadif=1:-1:0 -crf 18 -preset veryslow
[00:41:03 CET] <oftc_ftw> ah forgot -framerate 60
[00:41:30 CET] <furq> don't use -framerate unless you want to change the framerate
[00:41:56 CET] <oftc_ftw> oh ok
[00:42:58 CET] <furq> pal dvds are 576i
[00:43:12 CET] <furq> yadif=1 does a double-rate deinterlace which gives you 576p50
[00:43:24 CET] <llogan> xtina: from a device like a webcam, or a pipe, or...?
[00:43:33 CET] <xtina> llogan: from a pi cam, yep
[00:44:03 CET] <llogan> you can just search the IRC archives for your commands you pasted here previously
[00:44:16 CET] <llogan> if you're looking for the same thing
[00:44:42 CET] <xtina> haha, i am looking, but not sure how to search irc archives
[00:44:47 CET] <xtina> i tried a google search of the irclogs
[00:44:51 CET] <xtina> but it doesn't seem tow ork
[00:44:58 CET] <oftc_ftw> the rip log says 720x576 indeed :)
[00:45:16 CET] <alexpigment> oftc_ftw sorry i missed your earlier message but furq answered it nicely. out of curiosity, why are you scaling to 720 width?
[00:45:29 CET] <oftc_ftw> so furq, how do i use it? is scale=-1:720 wrong?
[00:45:40 CET] <oftc_ftw> i have no idea actually...
[00:45:54 CET] <xtina> llogan: i tried this: https://www.google.com/search?sourceid=chrome-psyapi2&ion=1&espv=2&ie=UTF-8&q=ffmpeg%20site%3Affmpeg.gusari.org%2Firclogs%2F2017%2F02%2F&oq=ffmpeg%20site%3Affmpeg.gusari.org%2Firclogs%2F2017%2F02%2F&aqs=chrome..69i57.2831j0j4
[00:45:55 CET] <alexpigment> well, it's a good idea to get it out of anamorphic
[00:46:08 CET] <xtina> i suppose that is not the right way to search irc logs..
[00:46:09 CET] <alexpigment> but i don't know if 720:-2 does that
[00:46:27 CET] <alexpigment> furq: does the scale filer turn anamorphic into 1:1?
[00:46:54 CET] <furq> you might need setsar as well
[00:47:04 CET] <alexpigment> alternately, i guess -2:576 is probably the better way
[00:47:10 CET] <oftc_ftw> i'm sorry, i'm such a noob in this, i don't know what the correct settings would be
[00:47:18 CET] <furq> it's better to just leave it anamorphic
[00:47:25 CET] <oftc_ftw> ok, so no scale at all?
[00:47:27 CET] <furq> yeah
[00:47:33 CET] <oftc_ftw> thanks :)
[00:47:35 CET] <furq> i normally just crop to mod2
[00:47:37 CET] <alexpigment> furq: do web players support anamorphic fully?
[00:47:45 CET] <JEEB> quite a few seem to
[00:47:47 CET] <furq> firefox and chrome do
[00:47:52 CET] <furq> i can't speak to any others
[00:47:58 CET] <oftc_ftw> i use firefox, that should be fine
[00:48:12 CET] <oftc_ftw> i will use "-c:v libx264 -vf yadif=1:-1:0 -crf 18 -preset veryslow" then
[00:48:17 CET] <alexpigment> k, i'll defer to your knowledge. it seems like a thing that people *wouldn't* all support, but maybe i'm too pessimistic
[00:48:31 CET] <alexpigment> looks like a good command line to me oftc
[00:48:37 CET] <furq> i'm not sure i'd bother with veryslow if it's not for archival
[00:48:37 CET] <oftc_ftw> thanks :)
[00:48:38 CET] <TD-Linux> I think that pessimism is rational :)
[00:48:59 CET] <furq> certainly not if you have plenty of space/bandwidth
[00:49:00 CET] <oftc_ftw> furq: i have other things to do and dont care for how long it takes at all
[00:49:01 CET] <ZeroWalker> hmm when compiling in a separate folder it seems to make a ton of source files, as well as the builds. Shouldn't i just get the builds;o?
[00:49:04 CET] <furq> fair enough
[00:49:10 CET] <alexpigment> the internet seems to pretend like NTSC/PAL never existed, hence my pessimism
[00:49:18 CET] <furq> -preset medium -crf 17 will look about the same and run much faster, but it'll be a bit bigger
[00:49:18 CET] <JEEB> ZeroWalker: on *nix those are symbolic links
[00:49:36 CET] <JEEB> ZeroWalker: what will have only the build is the prefix
[00:50:02 CET] <JEEB> ZeroWalker: so after make you run `make install` and just the stuff you need to use FFmpeg with gets installed properly into what you defined as --prefix
[00:50:30 CET] <ZeroWalker> ah
[00:50:49 CET] <alexpigment> medium and crf 17 bigger than veryslow and crf 10? interesting
[00:51:10 CET] <ZeroWalker> or wait, ehm, hmm this was confusing
[00:51:26 CET] <furq> alexpigment: 18, not 10
[00:51:29 CET] <JEEB> for build you will need the stuff around, so that's why it's there in your build root
[00:51:33 CET] <alexpigment> ohhhh
[00:51:47 CET] <JEEB> and the libraries/DLLs are located incorrectly, because it's the *build* root
[00:51:49 CET] <alexpigment> remoted in and the monitor is scaled, so it looks the same
[00:51:56 CET] <llogan> xtina: i guess it's not indexed
[00:51:56 CET] <ZeroWalker> ah okay, but with the prefix and install it will copy the resulted data only?
[00:52:01 CET] <ZeroWalker> to that folder
[00:52:02 CET] <JEEB> yes
[00:52:04 CET] <furq> you crazy people and your non-ssh irc clients
[00:52:07 CET] <ZeroWalker> ah
[00:52:23 CET] <ZeroWalker> and prefix starts from the home folder?
[00:52:25 CET] <alexpigment> ;)
[00:52:32 CET] <JEEB> ZeroWalker: you will have to define it
[00:52:35 CET] <JEEB> during configure
[00:52:39 CET] <ZeroWalker> Ah
[00:52:44 CET] <JEEB> --prefix=/your/path/to/things
[00:52:46 CET] <xtina> @llogan: i am trying: -f video4linux2 -i /dev/video0 -framerate 20 -s 1280x720 -c:v h264_omx \
[00:52:50 CET] <JEEB> the directory will get created
[00:52:56 CET] <xtina> but it says 'Unknown decoder 'h264_omx''
[00:53:03 CET] <ZeroWalker> wait, but, is it relative to where it's launched or?
[00:53:10 CET] <JEEB> no
[00:53:18 CET] <xtina> my ffmpeg is compiled with omx:   configuration: --extra-cflags=-I/opt/vc/include/IL --enable-nonfree --enable-omx-rpi --logfile=CONFIG.TXT
[00:53:31 CET] <JEEB> msys2 uses *nix paths
[00:53:40 CET] <JEEB> you start off in /home/your_user_name
[00:54:09 CET] <ZeroWalker> ah okay, not used to how *nix works as i am a windows user;d
[00:54:15 CET] <xtina> omx_h264 shouldn't be a decoder right? so i guess my order of params is wrong.. but how?
[00:54:15 CET] <ZeroWalker> much appreciated
[00:54:37 CET] <JEEB> ZeroWalker: this prefix thing is what most *nix configures lets you set in one way or another
[00:54:51 CET] <JEEB> ZeroWalker: for example I do cross-compilation for Android a lot
[00:55:02 CET] <JEEB> I always start with a clean prefix for it
[00:55:05 CET] <llogan> xtina: i think omx is just an encoder.
[00:55:11 CET] <JEEB> say, /home/jeeb/ownapps/armv7_prefix
[00:55:18 CET] <xtina> @llogan: i'm trying to use it as an encoder, yes
[00:55:21 CET] <JEEB> and thus I know that everything I build goes there
[00:55:30 CET] <ZeroWalker> clean prefix, you mean empty/non-existing folder?
[00:55:36 CET] <JEEB> yea
[00:55:46 CET] <ZeroWalker> see, i am starting to understand this
[00:55:52 CET] <ZeroWalker> i might still become a hero
[00:56:30 CET] <ZeroWalker> i tried searching for the command to disable the binaries as i don't need them to no avail, you happen to know them?
[00:56:42 CET] <xtina> llogan: http://pastebin.com/fBrjCCWC
[00:57:26 CET] <JEEB> ZeroWalker: --disable-programs
[00:57:32 CET] <ZeroWalker> i want to disable many things as i pretty much only need muxer/demuxer and codec (PCM,Opus,x264) and probably swscale for now.
[00:57:36 CET] <JEEB> it's all listed in /path/to/configure --help
[00:57:40 CET] <ZeroWalker> oh
[00:57:44 CET] <ZeroWalker> thanks will check
[00:57:45 CET] <llogan> xtina: options placement matters. you're attempting to apply it to -i /tmp/temp_audio.mp3
[00:57:52 CET] <ZeroWalker> i searched on "disable binaries";p
[00:57:59 CET] <JEEB> :)
[00:58:08 CET] <JEEB> ZeroWalker: also for colorspace conversions I deeply recommend zimg
[00:58:14 CET] <JEEB> https://github.com/sekrit-twc/zimg
[00:58:19 CET] <JEEB> usable from libavfilter as zscale
[00:58:20 CET] <xtina> @llogan: i have tried putting omx_h264 in front of /dev/video0 but same error
[00:58:34 CET] <xtina> http://pastebin.com/mvQbhu18
[00:58:39 CET] <ZeroWalker> is swscale slow or something?
[00:58:58 CET] <JEEB> it supports a lot, but I consider it not always correct and in various ways meh
[00:59:08 CET] <JEEB> it was made in times when threading wasn't as big, and CPUs were slower
[00:59:14 CET] <ZeroWalker> though i am going to want to do it with the GPU through shaders (however that works). As it's data captured from Direct3D9 and the like
[00:59:17 CET] <llogan> xtina: it's being interpreted as an input option for -i /dev/vide0
[00:59:19 CET] <JEEB> ah
[00:59:40 CET] <JEEB> ZeroWalker: in that case if you're doing open source there's some shaders for that stuff @ mpv (although they're OpenGL)
[00:59:41 CET] <xtina> isn't it an input option?
[00:59:46 CET] <JEEB> vlc has D3D shaders
[00:59:57 CET] <llogan> xtina: ffmpeg <input options> -i input0 <input options> input1 <output options> output
[01:00:41 CET] <xtina> hmm, i see
[01:00:46 CET] <xtina> i guess it's not an input option after all... haha
[01:00:50 CET] <llogan> IIRC, previously you were piping from raspivid to ffmpeg.
[01:01:07 CET] <xtina> llogan: yea, but i'd like to make use of -maxrate and -bufsize
[01:01:11 CET] <xtina> in ffmpeg, so i'm switchign over
[01:01:13 CET] <ZeroWalker> well i guess one would need to use shaders for the version i capture somehow. But well i leave that aside for now as it's not a top priority, but as it's most likely much faster as the data is in the GPU to begin, i would prefer to use it if possible
[01:01:24 CET] <ZeroWalker> gonna try to do the precix stuff now
[01:03:45 CET] <llogan> xtina: http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-February/004130.html has a link to one of your pastes that has a link to the rest of them under that account
[01:04:01 CET] <llogan> (i just randomly picked a somewhat recent log)
[01:09:12 CET] <xtina> llogan: OK. i don't know what is going on but i have never gotten omx h264 working with ffmpeg. it's why i always stuck with raspivid
[01:09:34 CET] <xtina> http://vpaste.net/3MB5P
[01:11:40 CET] <llogan> debug is too verbose. try to get it working with a local output file first.
[02:11:00 CET] <oftc_ftw> furq and alexpigment: the latest command line we discussed gave me "The video playback was aborted due to a corruption problem or because the video used features your browser did not support."
[02:11:01 CET] <oftc_ftw> me
[02:11:28 CET] <oftc_ftw> VIDEOJS: ERROR: (CODE:3 MEDIA_ERR_DECODE)
[02:12:45 CET] <oftc_ftw> could -crf 18 be the reason?
[02:20:40 CET] <oftc_ftw> hmm, using only -c:v libx264 -vf yadif=1:-1:0 the videos still won't play
[02:21:18 CET] <furq> no -preset veryslow?
[02:21:25 CET] <furq> that would've been my guess
[02:21:45 CET] <oftc_ftw> furq: in the second attempt i left that out as well, just to be sure
[02:22:15 CET] <oftc_ftw> they do play locally tho, they're not corrupted
[02:25:09 CET] <oftc_ftw> a non-educated wild guess: maybe the 50fps are an issue?
[02:30:42 CET] <alexpigment> 50fps should be fine, assuming you're on a computer
[02:30:43 CET] <furq> shouldn't be
[02:31:53 CET] <furq> pastebin the output of `ffprobe foo.mp4`
[02:31:56 CET] <alexpigment> oftc_ftw: what audio codec?
[02:32:20 CET] <oftc_ftw> alexpigment: Stream #0:1 -> #0:1 (ac3 (native) -> aac (native))
[02:32:28 CET] <alexpigment> ah, gotcha
[02:32:34 CET] <alexpigment> pastebin it is then :)
[02:33:45 CET] <oftc_ftw> https://gist.github.com/anonymous/ecd4823e7c1d605a1e91ea8743341fce
[02:33:48 CET] <oftc_ftw> there you go
[02:33:59 CET] <alexpigment> oh
[02:34:01 CET] <alexpigment> high 10
[02:34:05 CET] <alexpigment> you're using 10-bit x264
[02:34:22 CET] <oftc_ftw> alexpigment: not intentionally for this lq version
[02:34:38 CET] <oftc_ftw> err, yes i do :D
[02:34:43 CET] <oftc_ftw> took a while...
[02:35:04 CET] <oftc_ftw> can i emulate the 8-bit (?) version somehow?
[02:35:09 CET] <alexpigment> ffmpeg with x264 high bit depth and normal 8-bit depth are mutually exclusive in my experience
[02:35:17 CET] <furq> more or less
[02:35:20 CET] <alexpigment> try just downloading a precompiled static build
[02:35:24 CET] <oftc_ftw> so i need to re-install?
[02:35:27 CET] <furq> no
[02:35:42 CET] <furq> wait
[02:35:43 CET] <furq> is this windows
[02:35:46 CET] <furq> if so then yes
[02:35:48 CET] <oftc_ftw> no it's linux
[02:35:56 CET] <alexpigment> oh yeah, there's a way to do it on linux
[02:36:01 CET] <alexpigment> furq knows more about it
[02:36:11 CET] <oftc_ftw> nice :)
[02:36:19 CET] <furq> if you have an 8-bit libx264.so of the same version, you can do it with LD_LIBRARY_PATH
[02:37:28 CET] <furq> LD_LIBRARY_PATH=/usr/local/lib ffmpeg -i ...
[02:37:34 CET] <oftc_ftw> hmm, it seems i'd have to download the binary which is more of an hassle than to just reinstall the 8 bit packet
[02:37:44 CET] <furq> or you could just do that
[02:37:55 CET] <alexpigment> if in doubt, 8 is what you'll want
[02:37:58 CET] <oftc_ftw> reinstallation done :P
[02:38:01 CET] <furq> if ffmpeg is dynamically linked then you should be able to swap out libx264
[02:38:06 CET] <furq> as long as the version is identical
[02:38:21 CET] <furq> the LD_LIBRARY_PATH trick is just for if you want to be able to swap between them at will
[02:39:00 CET] <oftc_ftw> i noticed these lines in the previous conversion:
[02:39:00 CET] <oftc_ftw> No pixel format specified, yuv420p10le for H.264 encoding chosen.
[02:39:00 CET] <oftc_ftw> Use -pix_fmt yuv420p for compatibility with outdated media players.
[02:39:08 CET] <oftc_ftw> could that have worked?
[02:39:08 CET] <furq> yeah that's because of the 10-bit x264
[02:39:29 CET] <furq> you can only do yuv4**p10le with 10-bit x264
[02:39:30 CET] <alexpigment> man, have i seen *that* message a lot lately ;)
[02:39:47 CET] <furq> and none of those will work with most players
[02:39:54 CET] <oftc_ftw> i see, thanks. the message is gone now, currently running the conversion
[02:40:10 CET] <alexpigment> i presume you put all the original parameters back in?
[02:40:17 CET] <oftc_ftw> hehe, i just figured 10 bit is better then 8 bit when in doubt
[02:40:30 CET] <furq> it is better in every regard except support
[02:40:35 CET] <furq> which is a shame
[02:40:38 CET] <oftc_ftw> alexpigment: i'll try the quick version first, then the veryslow one
[02:40:38 CET] <alexpigment> yep
[02:40:48 CET] <alexpigment> oh, i also think veryslow is pointless
[02:40:51 CET] <alexpigment> medium is what i use
[02:40:54 CET] <alexpigment> with a lower CRF
[02:40:58 CET] <alexpigment> as furq suggested earlier
[02:41:04 CET] <furq> i use veryslow and 20, but that's for archival
[02:41:22 CET] <furq> i wouldn't do that for cloud storage
[02:42:28 CET] <oftc_ftw> so, 17 and medium instead of 18 and veryslow? but i thought the lower the number the less lossy?
[02:42:41 CET] <alexpigment> that's my vote, fwiw
[02:43:10 CET] <furq> lower crf = higher quality
[02:43:16 CET] <furq> but also slower preset = higher quality
[02:43:23 CET] <furq> so you're reducing one and increasing the other
[02:43:29 CET] <oftc_ftw> i see :)
[02:43:39 CET] <furq> tbh i think medium at 18 will already look great
[02:43:52 CET] <furq> i'm perfectly happy with veryslow at 20 for dvd rips
[02:43:57 CET] <oftc_ftw> the new video works :)
[02:44:23 CET] <alexpigment> cool. 10-bit is about the only thing i could think that a video on a computer wouldn't support
[02:44:30 CET] <oftc_ftw> i guess i'm fine with keeping the dvd rip and a lower quality "preview" version
[02:44:42 CET] <furq> the other possibility was too high level
[02:44:47 CET] <furq> but i don't think that's an issue at 576p
[02:45:05 CET] <furq> i'm still not entirely clear on what the limits are for that
[02:45:06 CET] <alexpigment> too high of a level on a computer is rare
[02:45:15 CET] <furq> well i meant in a browser
[02:45:20 CET] <alexpigment> high is only limited on handhelds
[02:45:26 CET] <furq> level, not profile
[02:45:31 CET] <alexpigment> even so
[02:45:38 CET] <alexpigment> maybe once you get to level 5
[02:45:55 CET] <furq> i know refs affect the level but i assume it does that less at lower resolution
[02:46:02 CET] <alexpigment> yeah, refs can do it
[02:46:12 CET] <alexpigment> but you have to specify more refs i think
[02:46:15 CET] <alexpigment> right?
[02:46:16 CET] <oftc_ftw> also thanks again for the hint with deinterlace, it's so obvious when you know it. :D
[02:46:18 CET] <furq> veryslow affects refs
[02:46:29 CET] <alexpigment> oh gotcha
[02:46:32 CET] <alexpigment> <-- never uses veryslow
[02:46:34 CET] <furq> veryslow is 16 refs
[02:46:35 CET] <alexpigment> ;)
[02:46:39 CET] <alexpigment> aight, i'm out
[02:46:40 CET] <alexpigment> later guys
[02:46:42 CET] <furq> which will probably cause some issues at 1080p
[02:46:57 CET] <oftc_ftw> later alexpigment and thanks again
[02:47:12 CET] <alexpigment> np. furq always has the good info though. thank him ;)
[02:47:24 CET] <oftc_ftw> yes, thanks furq!
[02:47:58 CET] <furq> thanks furq
[02:55:24 CET] <xtina> hey guys. i'm a bit confused what ffmpeg does when it's at <1.0x speed. when i watch my livestream, the video is moving at >1.0x speed while the audio is at 1.0x speed
[02:56:37 CET] <xtina> i'm wondering if this is because i'm dropping video packets before ffmpeg eats them
[02:56:45 CET] <xtina> or if it's something ffmpeg is actually doing with the video packets?
[02:56:55 CET] <xtina> (i'm using raspivid for recording atm)
[03:10:09 CET] <xtina> i can only think that because i'm streaming <1.0x, video packets build up and ffmpeg reads them as quickly as it can, so sometimes the video is frozen and other times  the video is streaming at >1.0x speed
[03:10:26 CET] <xtina> but if that's true, why is the audio streaming at a consistent 1.0x speed - it's never frozen and never going >1.0x?
[03:11:30 CET] <xtina> i thought ffmpeg always had to mux video+audio before sending them out, so how is it possible that the video and audio are running at different speeds?
[03:35:33 CET] <xtina> i have tried using the -re param with my video input file so it streams at real-time speed
[03:35:41 CET] <xtina> but it still sometimes streams faster than realtime if my ffmpeg speed <1.0x
[03:36:07 CET] <xtina> here's my command: http://vpaste.net/61LII
[03:36:45 CET] <xtina> here's the resulting stream: https://www.youtube.com/watch?v=H3h1NxVYYZU
[03:37:06 CET] <xtina> at the 0:45s mark in you can see that the video speeds up, while the audio remains 1.0x speed
[03:37:30 CET] <xtina> my CPU usage <25% so i know that's not the issue
[03:37:35 CET] <xtina> am i misunderstanding what -re is supposed to do?
[03:38:39 CET] <xtina> if i specified -re and it sometimes still streams video at >1.0x speed, does that mean that raspivid is somehow dropping frames?
[04:24:48 CET] <kepstin> xtina: ffmpeg doesn't care about realtime, in your config it never drops frames, it just reads on, does stuff, reads another, does stuff, and so on
[04:25:32 CET] <kepstin> so any frame dropping is happening because raspivid is blocked so it can't write to ffmpeg, which prevents it from capturing another frame
[04:25:58 CET] <kepstin> I'm guessing this is less likely to happen with audio, because audio is smaller, so it's less likely to fill up the pipe buffer
[04:27:07 CET] <kepstin> the "-re" option should not be used in your case - all that does is make ffmpeg block the video even more, because it adds an occasional "sleep" in ffmpeg where it does nothing. this mode is for if you're playing back a local file to a remote server, and want it streamed at close to realtime
[04:27:27 CET] <kepstin> if you have a live source, you want ffmpeg to send data as fast as the live source is making new data, so don't use -re
[04:29:47 CET] <kepstin> since ffmpeg is a batch encoding tool, the speed indicator (1.0x) is really just to estimate how long your batch encoding time is gonna take relative to the input file length :/
[05:15:54 CET] <lindylex> I get this error "...vf/-af/-filter and -filter_complex cannot be used together for the same stream"  When I do this ffmpeg -i slice.MOV -i url.png -filter_complex "overlay=x=(main_w-overlay_w)/2:y=(main_h-overlay_h)/2" -vf "crop=640:640:250:40" 1.mov
[05:21:20 CET] <furq> you can't use filter_complex and vf
[05:21:50 CET] <furq> -filter_complex "overlay=x=(main_w-overlay_w)/2:y=(main_h-overlay_h)/2,crop=640:640:250:40"
[05:22:52 CET] <lindylex> furq: Thanks I will give this a try.
[05:36:17 CET] <lindylex> furq: thanks that was amazing it all worked.
[05:36:39 CET] <lindylex> I struggle with how to combine the commands.
[08:00:01 CET] <xtina> kepstin: thanks for the explanation, i won't use -RE then
[08:00:25 CET] <xtina> when my audio buffer overruns i see an alsa buffer overrun msg and it's very obvious audio packets drop because multi-second chunks of audio are missing
[08:00:40 CET] <xtina> but my issue with video now is that sometimes it streams at >1.0x speeds but it seems continuous and smooth - there's no obvious drops
[08:00:47 CET] <xtina> and there's no print output telling me the raspivid buffer overran
[08:01:02 CET] <xtina> how can you be sure that the raspivid buffer overruns? i dont' see any skips in the video
[08:01:12 CET] <xtina> i just see the video sometimes playing really fast..
[08:17:57 CET] <dsc_> guys, how does realtime encoding work ;d
[08:18:14 CET] <dsc_> say I have a .mkv file that I'd like to have in h264 so that it works in the browser
[08:18:26 CET] <dsc_> and I want to do this conversion server side, on-the-fly
[08:18:30 CET] <dsc_> can I do that with ffmpeg?
[08:20:30 CET] <dsc_> (without having to wait before the file is encoded)
[08:20:40 CET] <dsc_> perhaps encode it in parts ...
[08:39:56 CET] <thebombzen> xtina: I feel like we've told you about twenty five times not to use -re
[08:40:31 CET] <thebombzen> xtina: you say it's streaming at >1.0x but what is it actually streaming at?
[08:40:37 CET] <thebombzen> is it like 1.01x?
[08:46:28 CET] <xtina> thebombzen:
[08:46:31 CET] <xtina> it's streaming at 0.5x
[08:46:36 CET] <xtina> when i watch the stream itself
[08:46:38 CET] <xtina> sometimes it's buffering
[08:46:48 CET] <xtina> sometimes it's going at like 2-3x speeds (judging from watching it on youtube)
[08:47:10 CET] <xtina> this is VIDEO only. audio goes at realtime speeds (whenever it isn't buffering)
[08:47:33 CET] <xtina> i'm trying to understand what is happening here. are packets being dropped by raspivid? or is ffmpeg streaming at greater than realtime speeds for bursts of time?
[08:47:57 CET] <xtina> to be clear. ffmpeg reports ~0.5x speed. on the youtube stream sometimes it buffers, sometimes video goes 2-3x fast
[08:49:20 CET] <xtina> while the audio sometimes buffers and otherwise goes exactly 1x fast on the stream
[08:52:35 CET] <thebombzen> well are you unable to encode video in realtime or is ffmpeg not even receiving video in realtime?
[09:00:08 CET] <xtina> thebombzen: i'm not sure how to tell
[09:00:16 CET] <xtina> because raspivid gives me 0 debugging output even when i'm verbose mode
[09:00:20 CET] <xtina> but i'm h264 encoding with raspivid
[09:00:23 CET] <xtina> ffpeg just receives h264
[09:00:44 CET] <xtina> i told raspivid to annotate the frames by frame# so i could look for some frame drops
[09:00:58 CET] <xtina> and as far as i can tell, there aren't any missing frames, this is why i suspected something was wrong with ffmpeg
[09:01:43 CET] <xtina> you can see what i mean here: https://www.youtube.com/watch?v=H3h1NxVYYZU
[09:01:46 CET] <xtina> at the 0:45s mark
[09:01:48 CET] <xtina> the video starts to speed up
[09:02:00 CET] <xtina> (this is with ffmpeg streaming at 0.5x speed, due to low wifi signal)
[09:02:35 CET] <xtina> but overall, i don't know how to tell where in the pipeline things go wrong, since raspivid has no debug output...
[09:41:19 CET] <thebombzen> xtina: try reading from libavfilter rather than from a pipe
[09:41:23 CET] <thebombzen> see if it works
[09:42:10 CET] <xtina> thebombzen: isn't libavfilter a filter library? i don't want to apply filters on the inputs because then they would have to be decoded first right?
[09:42:14 CET] <xtina> i'm passing encoded audio/video into ffmpeg
[09:42:32 CET] <thebombzen> xtina: you can also use it to create a test source
[09:42:40 CET] <thebombzen> ffmpeg -f lavfi -i testsrc will give you a test source
[09:43:53 CET] <xtina> thebombzen: to clarify, my whole pipeline works great as long as i have good wifi
[09:43:57 CET] <thebombzen> also, have you considered recording from raspivid to a file for about a minute, and then using ffmpeg to stream that file (this time with -re)
[09:44:00 CET] <xtina> i'm testing it under low wifi conditons
[09:44:06 CET] <thebombzen> well
[09:44:13 CET] <thebombzen> if your wifi is bad then it's not an ffmpeg problem
[09:44:23 CET] <thebombzen> if it works with good internet then it's not an ffmpeg issue
[09:44:48 CET] <thebombzen> if this only happens when your wifi is bad then it means data is getting clogged in a buffer somewhere
[09:44:52 CET] <thebombzen> network-wise
[09:45:19 CET] <thebombzen> given that it happens only with video and not audio my best guess is your ISP is packet sniffing and throttling the video
[09:45:34 CET] <thebombzen> to which there is nothing you can do
[11:29:34 CET] <australia> Hello. I have an install error I am looking for help. " yasm/nasm not found or too old. Use --disable-yasm for a crippled build. "
[11:30:32 CET] <JEEB> if you are building for x86/x86_64 then just install yasm
[11:30:41 CET] <JEEB> you definitely don't want to build without it
[11:42:49 CET] <australia> izzymate at izzymate ~ $ urpmi ffmpeg Package ffmpeg-2.8.9-1.1plf-plf2014.1.x86_64 is already installed
[11:42:52 CET] <australia> mybad lol
[11:44:21 CET] <australia> Although I have never used it before. What Ive been curious about is when Ive used youtube-dl ( Linux ) I get downloads outputs in MKV MP4 and WEBM .............
[11:44:37 CET] <australia> I want to convert all into MP4
[13:10:46 CET] <Qas> hello everyone, which ffmpeg download should I use for ubuntu 14.4.3 ?
[13:11:11 CET] <Qas> I see official packages for later versions. and 'multimedia for trusty PPA'
[13:11:22 CET] <Qas> trusty is 14.4.3
[13:11:57 CET] <JEEB> if you need just the command line tool I recommend either building one yourself that doesn't interfere with your package management, or using one of the static binaries linked around here
[13:12:53 CET] <Qas> JEEB, yes, i will use command line, so I should use the multimedia ppa?
[13:13:22 CET] <JEEB> no
[13:13:30 CET] <JEEB> or at least I haven't seen any PPAs recommended here
[13:13:50 CET] <JEEB> mostly because PPAs tend to have packages that imitate what's in teh main repos and that will cause major chaos
[13:15:09 CET] <JEEB> I don't use these myself but you can download just the command line tool from https://johnvansickle.com/ffmpeg/
[13:15:22 CET] <JEEB> and then you can call it where you extracted it
[13:15:27 CET] <JEEB> like ~/my_apps/ffmpeg
[14:04:50 CET] <bmduser> Hi could anyone shed some light on this? I am trying to get ffmpeg to capture from the blackmagic studio2 capture card but all it captures is color bars
[14:05:45 CET] <bmduser> thinking that i didnt get the resolution and framerate correct i checked with the desktop video utility and found that it was exactly as i set at 1080p 25
[14:06:20 CET] <thebombzen> what do you mean be color bars?
[14:06:25 CET] <bmduser> however when i use ffmpeg to capture at 1080p 25 i am still getting color bars
[14:06:25 CET] <thebombzen> can you post a screenshot?
[14:06:59 CET] <thebombzen> my best guess is it's a pixel format error but can you upload a screenshot and give us the link?
[14:07:37 CET] <bmduser> color bar like this
[14:07:56 CET] <bmduser> https://i.ytimg.com/vi/mO98ninuGJc/maxresdefault.jpg
[14:08:11 CET] <thebombzen> is that the screenshot you generated?
[14:08:16 CET] <thebombzen> or is that something you googled?
[14:08:32 CET] <bmduser> no its the exact same thing that got captured
[14:08:55 CET] <bmduser> here is my pastebin
[14:08:57 CET] <bmduser> http://pastebin.com/1R0eAJ7L
[14:09:24 CET] <thebombzen> well you're using a version of FFmpeg from 2014
[14:09:26 CET] <thebombzen> that's 3 years old
[14:09:33 CET] <thebombzen> try updating your FFmpeg and trying again
[14:10:08 CET] <thebombzen> here's a link for your convenience: https://ffmpeg.zeranoe.com/builds/
[14:10:22 CET] <bmduser> ah ok thanks let me go have a look
[14:11:35 CET] <thebombzen> I also find it amusing that you're using a nonfree build of ffmpeg
[14:11:55 CET] <thebombzen> whoever gave you that is violating the license
[14:12:13 CET] <thebombzen> (unless you built it yourself)
[14:14:51 CET] <bmduser> oh i didnt realize that thanks
[14:17:28 CET] <bmduser> i am trying to wrap my head around this compiling it seems a bit overwhelming for me at the moment
[14:19:15 CET] <bmduser> am i right to say the pre compiled versions would not have been built with decklink support?
[14:19:40 CET] <bmduser> and I would need to compile on my one and enable decklink support during the compile?
[14:39:31 CET] <bmduser> thanks thebombzen i went to zeroanoe and downloaded the december version with he decklink compiled in it
[14:39:56 CET] <thebombzen> did it work?
[14:40:18 CET] <thebombzen> it'll have decklink support as long as it was built with --enable-decklink
[14:40:21 CET] <thebombzen> afaik Zeraoe does that
[15:10:25 CET] <cesdo> Hello.
[15:10:55 CET] <cesdo> Tryed to compile VLC and got some errors(
[15:11:04 CET] <cesdo> codec/avcodec/video.c: In function DecodeBlock:
[15:11:04 CET] <cesdo> codec/avcodec/video.c:848:19: error: implicit declaration of function avcodec_send_packet [-Werror=implicit-function-declaration]
[15:11:04 CET] <cesdo>          int ret = avcodec_send_packet(p_context, &pkt);
[15:11:04 CET] <cesdo>                    ^
[15:11:04 CET] <cesdo> codec/avcodec/video.c:869:15: error: implicit declaration of function avcodec_receive_frame [-Werror=implicit-function-declaration]
[15:11:04 CET] <cesdo>          ret = avcodec_receive_frame(p_context, frame);
[15:11:05 CET] <cesdo>                ^
[15:11:05 CET] <cesdo> cc1: some warnings being treated as errors
[15:11:38 CET] <JEEB> sounds like your libavcodec is too old
[15:12:04 CET] <JEEB> but the configure check should checked the version...
[15:13:02 CET] <JEEB> so it sounds like it's either picking up wrong headers (which don't contain those APIs), or you somehow got through the configure checks without having those functions in there
[15:18:10 CET] <cesdo> JEEB: I have two versions of ffmpeg -- one  is in /usr/bin and one is in ~/ffmpeg_sources. To use version that is in ~/ffmpeg_sources I did
[15:18:31 CET] <cesdo> PKG_CONFIG_PATH=/home/user/ffmpeg_sources/ffmpeg/libavcodec:/home/user/ffmpeg_sources/ffmpeg/libswresample:/home/user/ffmpeg_sources/ffmpeg/libavutil:/home/user/ffmpeg_sources/ffmpeg/libavformat:/home/user/ffmpeg_sources/ffmpeg/libswscale  ./configure --disable-chromecast --enable-aa --enable-realrtsp --disable-wayland
[15:19:12 CET] <JEEB> that's incorrect
[15:19:22 CET] <cesdo> wtf
[15:19:25 CET] <cesdo> why
[15:19:54 CET] <cesdo> How can I do it right?
[15:20:50 CET] <JEEB> what you're supposed to do is use --prefix when you configure FFmpeg (say, /home/user/ffmpeg_prefix), do a `make install` so that FFmpeg can actually create a proper directory structure and install files correctly, and then set PKG_CONFIG_PATH=/home/user/ffmpeg_prefix/lib/pkgconfig ./configure --options with VLC or anything else using that stuff
[15:21:07 CET] <JEEB> if that still picks up the wrong libav*.pc files, then you have to switch to PKG_CONFIG_LIBDIR
[15:21:18 CET] <JEEB> which ignores what you have in the pkg-config search path already
[15:21:26 CET] <JEEB> (usually only used in cross-compilation)
[15:21:54 CET] <JEEB> but yeah, the basic part being that the files in the build directory are not meant to be used as-is
[15:22:07 CET] <JEEB> it's not in the correct way since it's the *build* directory
[15:22:37 CET] <JEEB> you set a prefix with --prefix and utilize `make install` and FFmpeg's libraries, headers and apps will get properly installed into bin/ lib/ include/ in that prefix
[15:23:03 CET] <JEEB> and you set PKG_CONFIG_PATH to /your/prefix/lib/pkgconfig
[15:23:05 CET] <JEEB> and you're done
[15:23:32 CET] <JEEB> (exceptions happen when you have stuff in your /usr/lib/pkgconfig already related to that stuff, which pkg-config might or might not pick up
[15:23:53 CET] <JEEB> in which case you either get rid of the pc files in there, or use PKG_CONFIG_LIBDIR
[15:23:58 CET] <JEEB> which overrides instead of appending
[15:33:44 CET] <JEEB> cesdo: and I'm not even going to ask why you're not using the contribs system which would build Libav or FFmpeg for you
[15:43:51 CET] <marcurling> Hello, under Win7, using the ouput option "pan=stereo| FL < FL + 0.5*FC + 0.6*BL + 0.6*SL | FR < FR + 0.5*FC + 0.6*BR + 0.6*SR" gives "Specified file is unfindable" < (traslated: may be not the exact English text)
[15:44:40 CET] <marcurling> Does one has any workaround ? (I guess the pb comes from the < and pipes)
[15:49:37 CET] <marcurling> ok migthy sword, will do immediately ;)
[15:55:18 CET] <marcurling> http://pastebin.com/RvrwCAg8
[15:56:43 CET] <marcurling> (it could be just something I miss between '-acodec aac' and 'pan=...')
[15:57:42 CET] <marcurling> I got the option from https://ffmpeg.org/ffmpeg-filters.html#Mixing-examples
[16:11:49 CET] <ZeroWalker> is it possible to disable all encoder/decoders to then manually select the ones you want?
[16:11:57 CET] <ZeroWalker> instead of disable all manually
[16:12:09 CET] <JEEB> yes
[16:12:18 CET] <ZeroWalker> ah nice
[16:12:24 CET] <JEEB> --disable-everything is a thing, but you will have to make sure you enable everything you really need
[16:13:10 CET] <ZeroWalker> ah yeah saw that one, was hoping there was a thing for only encoder/decoders etc, will have to try it out, hopefully it's not that complicated
[16:14:24 CET] <ZeroWalker> oh wait there is
[16:14:26 CET] <ZeroWalker> i am blind
[16:14:27 CET] <JEEB> there might be, look at --help
[16:14:31 CET] <JEEB> gg
[16:16:04 CET] <marcurling> JEEB how could this work in a shell/console when < and | sign will be considered as redirections ?
[16:16:06 CET] <marcurling> https://ffmpeg.org/ffmpeg-filters.html#Mixing-examples
[16:16:51 CET] <JEEB> marcurling: you just make sure the shell doesn't try to evaluate it. whatever your effing shell/console/terminal emu is
[16:16:52 CET] <dsc_> Encoding chunks of video to .mp4 h264, is that something ffmpeg can do
[16:17:11 CET] <dsc_> and these chunks can be any bytestream of arbitrary length
[16:21:47 CET] <IntruderSRB> 'ello everyone
[16:21:54 CET] <IntruderSRB> @JEEB want to thank you for all the help you gave - got fmp4/cbcs finally working on my packager :D
[16:22:59 CET] <IntruderSRB> issue was the most stupid thing on earth ... for some reason my sps parser made default value for chroma_format_idc to be 0 and not 1 ... with that there's no chance I would parse h264 video slice correctly :)
[16:24:57 CET] <JEEB> heh
[16:27:22 CET] <IntruderSRB> yea ... exactly my thought after 1 week troubleshooting it :D
[16:29:04 CET] <TAFB> I want to downsize 1080p to 540p (50% scale) but want it to be super sharp. When I run "ffmpeg -i tos.mov -vf scale=-1:540 tos_0x540.mov" the final output looks "soft", is there a smoothing filter run on the output by default?
[16:31:00 CET] <JEEB> outputting 4:4:4 might help you but I have no idea of your requirements. also using scalers from zimg (via the zscale filter) might help
[16:32:43 CET] <sfan5> there's also different scalers to select http://ffmpeg.org/ffmpeg-scaler.html#scaler_005foptions
[16:33:44 CET] <JEEB> yes, different things available in both swscale and zimg/zscale
[16:34:13 CET] <TAFB> thanks guys, I'll take a look
[16:38:37 CET] <sfan5> hm why do all tutorials suggest -f also -i pulse when there is a pulse device?
[16:46:25 CET] <JEEB> welcome to tutorials, and I'm not sure of the age or quality of either module
[17:05:29 CET] <ZeroWalker> hmm, when you want to add like opus etc, how did that work, do you compile and make install opus beforehand?
[17:13:41 CET] <thebombzen> did someone say discussion of best video scalers?
[17:13:50 CET] <TAFB> me me me
[17:14:00 CET] <TAFB> 50% downscaling, what it sharp AF :D
[17:14:03 CET] <thebombzen> lol we're literally having this dicussion right now in #mpv
[17:14:09 CET] <thebombzen> but mitchell is particularly good at downscaling
[17:14:13 CET] <DHE> ZeroWalker: I think ffmpeg has its own opus encoder
[17:14:16 CET] <TAFB> mitchell?
[17:14:43 CET] <DHE> oh, never mind
[17:14:46 CET] <ZeroWalker> hmm, i get opus doesn't exist
[17:14:53 CET] <ZeroWalker> or something
[17:14:54 CET] <thebombzen> doesn't have it
[17:14:58 CET] <thebombzen> TAFB: try "spline"
[17:15:02 CET] <DHE> yeah I'm wrong
[17:15:27 CET] <TAFB> thanks thebombzen :)
[17:15:34 CET] <thebombzen> also try lanczos
[17:15:40 CET] <thebombzen> it depends onw hat looks better
[17:21:10 CET] <obamoose> hello
[17:26:58 CET] <obamoose> can someone help me figure out how to create a stream that loops forever
[17:27:24 CET] <TAFB> obamoose: pretty tricky :(
[17:27:32 CET] <obamoose> ;_;
[17:27:46 CET] <obamoose> http://pastebin.com/0QjWULPL
[17:27:50 CET] <obamoose> this is my current config
[17:27:51 CET] <obamoose> It works
[17:28:16 CET] <obamoose> but it restarts the stream after every file
[17:28:17 CET] <TAFB> nice, I ended up making up a huge concat list, worked fine for me
[17:28:21 CET] <obamoose> so it only kinda works
[17:28:40 CET] <TAFB> just make a concat list that's 90000000000 lines long with repeating lists of your file, it'll work great.
[17:28:50 CET] <obamoose> not a single file though
[17:28:51 CET] <obamoose> a directory
[17:29:19 CET] <TAFB> as long as the files stay the same, file1.mp4, file2.mp4, file3.mp4, file1.mp4, file2.mp4, file3.mp4, file1.mp4, etc.
[17:29:48 CET] <ZeroWalker> what's the command to install autoreconf in via pacman, i tried that and autotools to no avail
[17:38:46 CET] <BtbN> automake and autoconf i guess
[17:39:17 CET] <BtbN> but those dont apply to ffmpeg to begin with
[17:40:21 CET] <ZeroWalker> yeah it's for libopus, will see if making and installing it makes it work in ffmpeg
[17:42:52 CET] <JEEB> FFmpeg itself has opus decoder and encoder, but libopus is still better with encoding
[17:44:13 CET] <ZeroWalker> ah
[17:49:24 CET] <ZeroWalker> configure: error: no acceptable ld found in $PATH
[17:49:28 CET] <ZeroWalker> what's this?
[17:50:36 CET] <JEEB> oh right
[17:50:39 CET] <JEEB> you were on MSVC
[17:50:43 CET] <JEEB> that's fun with various things :P
[17:51:30 CET] <JEEB> now the fun part is that libopus probably has a MSVS solution, but of course that has no pkg-config files or such
[18:12:42 CET] <ZeroWalker> oh, yay xd
[18:17:42 CET] <ZeroWalker> okay it had msvc stuff and i could build those, so that part is fine at least. can i manually install it somehow;o?
[18:17:56 CET] <thebombzen> obamoose: have you considered the many many times I have told you what to do
[18:18:12 CET] <obamoose> I told you I'm retarded
[18:18:28 CET] <thebombzen> did you try it though?
[18:18:44 CET] <obamoose> up until I couldn't understand what I was doing
[18:18:50 CET] <obamoose> Can we try again ;_;?
[18:18:53 CET] <thebombzen> what about when we asked you to literally copy and paste
[18:18:56 CET] <obamoose> I did
[18:19:02 CET] <obamoose> while true; do cat *.ts; done | ffmpeg -y -re -f mpegts -i - <rest of your command line>
[18:19:15 CET] <thebombzen> there you go
[18:19:22 CET] <obamoose> but I don't understand ;_;
[18:19:27 CET] <thebombzen> so what?
[18:19:35 CET] <obamoose> where does the rest go?
[18:19:39 CET] <obamoose> define rest
[18:20:01 CET] <thebombzen> well you had: ffmpeg <some stuff> -i <input filename> <some other stuff>
[18:20:04 CET] <thebombzen> I mean the <some other stuff>
[18:20:05 CET] <ZeroWalker> your original command arguments i guess
[18:21:08 CET] <thebombzen> listen if you're going to be streaming other people's IP at least learn how
[18:22:03 CET] <obamoose> but but
[18:22:14 CET] <thebombzen> I'm wondering if "I'm retarded ;_; it restarts the stream after every file" is going to become the new "there's a huge bug in vlc and the devs aren't willing to fix it"
[18:24:01 CET] <obamoose> how do I track the killers IP using visual basic gui interfaces?
[18:24:05 CET] <ZeroWalker> i am actually also doing streams to point to point
[18:24:52 CET] <obamoose> cat: '*.ts': No such file or directory
[18:24:57 CET] <obamoose> is the error i'm getting
[18:25:06 CET] <obamoose> "  " yes?
[18:25:58 CET] <thebombzen> ZeroWalker: this guy is streaming to twitch
[18:26:11 CET] <thebombzen> namely he's streaming videos he downloaded from youtube channels
[18:26:20 CET] <thebombzen> without having any clue how to use a command line
[18:26:27 CET] <bmduser> thebombzen  yes it did work with the december version!!!
[18:26:29 CET] <thebombzen> or any sort of ability to read or copy/paste
[18:26:34 CET] <thebombzen> bmduser:  there you go :)
[18:26:39 CET] <thebombzen> bugs get fixed
[18:27:23 CET] <thebombzen> when I see this discussion I just wanna be like
[18:27:24 CET] <thebombzen> https://0x0.st/vsA.opus
[18:28:35 CET] <ZeroWalker> ah
[18:29:39 CET] <bmduser> thebombzen thanks so much for pointing me in the right direction i was stuck for so many days
[18:29:58 CET] <thebombzen> when it doubt update your software
[18:31:30 CET] <obamoose> thebombzen: please point me in the right direction
[18:32:09 CET] <bmduser> i am streaming rtmp and it seems to be using alot of cpu at 40-60%
[18:32:40 CET] <TAFB> bmduser: can you stream without re-encoding? that's what I do, 3% cpu usage :)
[18:32:56 CET] <bmduser> is that normal for a 1080p rtmp stream with an i7 processor
[18:33:39 CET] <thebombzen> obamoose: no
[18:33:58 CET] <thebombzen> bmduser: the actual streaming? no
[18:34:01 CET] <thebombzen> but are you transcoding
[18:34:20 CET] <thebombzen> because if you're streaming and transcoding at the same time that's expected becuse video conversion is expensive
[18:34:31 CET] <bmduser> i am taking a blackmagic input with this
[18:34:42 CET] <thebombzen> if you're taking raw yuyv422 input
[18:34:49 CET] <bmduser> -f decklink -i "DeckLink Studio 2 at 6" -threads 16 -vcodec libx264 -maxrate 3000k -strict -2 -b:v 3M -pix_fmt yuv420p -preset veryfast -acodec aac -b:a 128k -bsf:v h264_mp4toannexb -f flv rtmp://rtmpaddress
[18:34:50 CET] <thebombzen> then you have to transcode
[18:35:00 CET] <thebombzen> yes 40-60% is unsurprising
[18:35:09 CET] <thebombzen> also don't use -strict -2
[18:35:18 CET] <thebombzen> you don't need it anymore for the audio encoder
[18:35:52 CET] <damnruskie> hey im getting an error while building the arch openpht-ffmpeg package, it seems the package is out of date  - anyone happen to know of an upcoming update?
[18:36:53 CET] <thebombzen> you should be using htis instead: -pix_fmt yuv420p -c:v libx264 -maxrate:v 30M -minrate:v 3M -b:v 3M -preset:v veryfast -c:a aac -b:a 128k -f flv rtmp://theaddr
[18:37:50 CET] <marcurling> Which option (-something) should precede a pan=[parameters] please
[18:38:32 CET] <thebombzen> damnruskie: have you considered openpht-git
[18:38:45 CET] <bmduser> seem to be getting input buffer overrun
[18:39:00 CET] <damnruskie> didnt realize it was an option, thanks thebombzen
[18:39:06 CET] <thebombzen> damnruskie: you can also just build from source
[18:39:11 CET] <thebombzen> cause tha'ts literally what the AUR is
[18:39:16 CET] <thebombzen> it's a glorified build-from-source method
[18:39:24 CET] <damnruskie> ah ok awesome ill do that then
[18:39:29 CET] <damnruskie> thanks for the tips
[18:39:30 CET] <thebombzen> damnruskie: try installing pacaur from the AUR
[18:39:36 CET] <thebombzen> it's very convenient
[18:40:07 CET] <thebombzen> it allows you to run pacaur -Ss or pacaur -Si or pacaur -Su and also work with the aur
[18:40:14 CET] <thebombzen> then you don't have to do that worrying
[18:42:40 CET] <damnruskie> gotcha, ive been installing manuall previously, this seems way nicer - thanks again
[21:29:57 CET] <thebombzen> hey I have a question - suppose I'm recording highmotion content
[21:30:10 CET] <thebombzen> can I improve compression ratio by keeping the native res
[21:30:52 CET] <DHE> bigger images require bigger files. there's not much you can do about that if you want to maintain image quality
[21:30:59 CET] <DHE> can you be more specific about what you're trying to accomplish
[21:31:12 CET] <thebombzen> not native res, typo
[21:31:15 CET] <thebombzen> native framerate
[21:31:29 CET] <thebombzen> I'm recording 144 fps content - does the ratio improve if I record it to 60 fps or should I keep it at 144
[21:31:48 CET] <thebombzen> the issue is it's highmotion content and if I do 144 fps the predictors are significantly more accurate
[21:32:07 CET] <thebombzen> but I don't know if that's worth it when I have more than 2x the data
[21:32:17 CET] <DHE> yes, but it's usually a matter of pixels per second. cut the framerate in half and you can usually maintain ABOUT the same image quality for half the bitrate
[21:32:21 CET] <ChocolateArmpits> 2x only if uncompressed
[21:32:32 CET] <thebombzen> ChocolateArmpits: it is
[21:32:35 CET] <thebombzen> I'm recording it
[21:32:47 CET] <ChocolateArmpits> so you intend to storing it uncompressed too ?
[21:33:00 CET] <thebombzen> so what I'm saying is that I'm generating 144 fps content
[21:33:07 CET] <thebombzen> I'm not sure whether to record at 144 or record at 60
[21:33:11 CET] <thebombzen> for better compression ratio
[21:33:15 CET] <thebombzen> for example, 10bit encoding is worth the extra data over 8bit because it makes the predictors more accurate
[21:33:29 CET] <thebombzen> given that it's highmotion content, 144 fps will have much more accurate prediction
[21:33:37 CET] <thebombzen> but idk if it's worth it to more that double the pixels per second
[21:33:57 CET] <DHE> you can crank the encoder settings (eg: x264 veryslow) to make the motion estimation search harder for the lower framerate. dunno if that's a win for quality
[21:35:36 CET] <thebombzen> well if I'm recording in realtime that defeats the point
[21:35:49 CET] <thebombzen> I think the best option here is probably "just try it with crf 18 and see what makes a lower filesize"
[21:35:56 CET] <TAFB> i love veryslow with crf0 :)
[21:35:56 CET] <DHE> well if you're recording uncompressed there are no motion vectors.
[21:36:07 CET] <DHE> (being pedantic with "uncompressed" vs "lossless")
[21:36:14 CET] <thebombzen> DHE: what's the difference?
[21:36:24 CET] <thebombzen> x264 sees the same thing, right?
[21:36:36 CET] <thebombzen> what's the difference between recording uncompressed and recording lossless?
[21:36:37 CET] <DHE> uncompressed has constant size files, usually width * height * pixels_per_frame
[21:37:00 CET] <thebombzen> but if I record to lossless/uncompressed and then later test the bitrates with x264, is it any different?
[21:37:22 CET] <DHE> no. but you said you're recording in realtime so decisions are to be made
[21:37:33 CET] <thebombzen> well I can always record to lossless and then transcode
[21:37:41 CET] <ChocolateArmpits> lossless compression when uncompressed produces the exact input, so it essentially doesn't lose quality but maintains a lower file size
[21:37:42 CET] <thebombzen> assuming I'm just doing a short test
[21:37:50 CET] <thebombzen> ChocolateArmpits: I know that
[21:38:00 CET] <thebombzen> but DHE here is being pedantic about motion vectors
[21:38:00 CET] <ChocolateArmpits> then why are you asking this
[21:38:11 CET] <thebombzen> [20:35:56] <DHE> well if you're recording uncompressed there are no motion vectors.
[21:38:12 CET] <thebombzen> [20:36:06] <DHE> (being pedantic with "uncompressed" vs "lossless")
[21:38:22 CET] <thebombzen> because I was wondering why this ^ is relevant
[21:38:38 CET] <thebombzen> ChocolateArmpits: I happen to frequent this channel regularly so please don't baby me
[21:39:25 CET] <DHE> because I'm still confused about what it is you're doing. "generating" 144 fps content. does that mean live from a camera, or software generated and doesn't care about how fast the receiver is...
[21:39:33 CET] <thebombzen> record from screen
[21:39:41 CET] <DHE> okay, so properly realtime
[21:39:44 CET] <thebombzen> yes
[21:40:08 CET] <thebombzen> in order to test it I could record it in lossless for like 30 seconds
[21:40:14 CET] <thebombzen> and then transcode with x264
[21:40:20 CET] <thebombzen> which is what I'm going to do
[21:40:39 CET] <thebombzen> the issue is 144 is not an integer multiple of 60
[21:40:56 CET] <thebombzen> so I'm probably going to reset my monitor to 120 to make it so judder doesn't affect the output
[21:42:06 CET] <TAFB> do you have a second computer that could do the encoding and streaming? would probably work a lot better than doing it on the gaming computer. You could also buy an external hardware encoder.
[21:47:57 CET] <thebombzen> TAFB: why does that matter
[21:48:02 CET] <thebombzen> I'm not streaming it
[21:48:07 CET] <thebombzen> I'm just recording it locally
[21:48:11 CET] <TAFB> oh, sorry, thought you were live streaming
[21:48:19 CET] <thebombzen> ah no I'm nowhere near charismatic enough :)
[21:48:31 CET] <thebombzen> I record it locally with lossless nvenc using OBS's replay buffer feature
[21:48:45 CET] <thebombzen> then if I do a really cool play I have a hotkey to dump the buffer to a file
[21:48:51 CET] <thebombzen> I then transcode it so it's not like 300 Mbps
[21:48:52 CET] <TAFB> nice. I've gotta try OBS soon, ffmpeg is way too unreliable
[21:52:00 CET] <thebombzen> the issue is the transcoding from 120 to 60
[21:52:06 CET] <thebombzen> is it worth it to stay at 120?
[21:52:24 CET] <thebombzen> if not, I'll just use nvenc to encode at 60 b/c the dumps won't be as large
[21:52:45 CET] <furq> 20:48:19 ( thebombzen) ah no I'm nowhere near charismatic enough :)
[21:52:51 CET] <furq> sounds like you're well qualified for live streaming then
[21:53:12 CET] <thebombzen> well I'm only qualified in that I'm very skilled a recognizing my limitations
[21:53:16 CET] <thebombzen> far more that most actual livestreamers
[21:53:24 CET] <furq> as long as you don't have a voice that ordinary humans would find acceptable
[21:53:30 CET] <furq> that's the death sentence for streamers
[21:56:18 CET] <thebombzen> haha
[21:56:24 CET] <thebombzen> okay so the results of the test are in
[21:56:36 CET] <thebombzen> I took the same 120 fps recording (lossless) and did two transcodes
[21:56:49 CET] <thebombzen> first, straight -c libx264 -preset slow -crf 18
[21:57:06 CET] <thebombzen> and the next one was -vf framestep=2 -c libx264 -preset slow -crf 18
[21:57:41 CET] <furq> well i know which one took half as long
[21:57:42 CET] <thebombzen> 60 fps was smaller but only slightly - 21.1 Mbps for 60 fps and 23.5 Mbps for 120 fps
[21:58:21 CET] <furq> you can probably get that even closer by doubling the 120fps gop size
[21:58:30 CET] <thebombzen> 250 rather than 500?
[21:58:33 CET] <furq> although 250 is probably too small in either case
[21:58:33 CET] <thebombzen> err
[21:58:41 CET] <thebombzen> so 500 vs 1000?
[21:58:46 CET] <thebombzen> or like 400 vs 800
[21:58:47 CET] <furq> i was thinking 300 vs 600
[21:58:50 CET] <thebombzen> ah okay
[21:59:04 CET] <thebombzen> I wonder if extra bframes would close the gap or widen it
[21:59:07 CET] <furq> 600 vs 1200 is 10-second gops, which is what you'd normally get
[21:59:13 CET] <furq> i would expect veryslow would narrow the gap as well
[21:59:22 CET] <thebombzen> yea extra bframes helps 120 fps
[21:59:35 CET] <thebombzen> 10-second gops is normal?
[21:59:43 CET] <furq> 250 is 10-second gops for pal
[21:59:50 CET] <thebombzen> 250 is the normal keyint, which is 25 fps yea
[22:00:07 CET] <thebombzen> does -g takes frames or seconds as the units?
[22:00:10 CET] <furq> frames
[22:00:16 CET] <thebombzen> okay
[22:00:31 CET] <thebombzen> so I'll try again but with 400 and 800 as a good intermediary between 600 and 1200
[22:00:34 CET] <thebombzen> and 250/500
[22:01:50 CET] <furq> not sure what that'll do with an fps demo
[22:02:00 CET] <furq> guess it depends how twitchy you are
[22:02:42 CET] <thebombzen> very
[22:03:44 CET] <thebombzen> I would also try veryslow but it's very slow
[22:03:58 CET] <thebombzen> I think -preset slow is a good compromise
[22:06:38 CET] <thebombzen> weirdly enough, I wouldn't think the keyint would do all that much for highmotion content
[22:06:43 CET] <thebombzen> cause it's mostly the microscopic changes
[22:08:25 CET] <thebombzen> huh, so results part 2 are in
[22:08:43 CET] <thebombzen> increasing the keyint to 400 reduced 60 fps from 21 Mbps to 19 Mbps
[22:08:51 CET] <thebombzen> but 120 fps stayed at 23 Mbps with 800 keyint
[22:09:02 CET] <thebombzen> it appears to not have changed much
[22:10:18 CET] <furq> fun
[22:10:33 CET] <ChocolateArmpits> so long term compression benefitted more from a higher gop length, than the short term compression
[22:12:01 CET] <thebombzen> which wasn't really surprising tbh
[22:12:21 CET] <thebombzen> 120 fps has its main advantage from smaller per-frame differences
[22:12:42 CET] <thebombzen> either way, I think I'm gonna stick with 120 fps because I think the extra few Mbps are (19 vs 23) are worth it
[22:12:52 CET] <thebombzen> for double the framerate
[22:13:48 CET] <furq> i think you were lying about you/overwatch being twitchy if that's crf 18 at 1080p120
[22:14:53 CET] <BtbN> it's also a matter of the gop length
[22:15:23 CET] <BtbN> it's set as an mount of frames, so if you increase the framerate, an I frame happens more frequently
[22:15:40 CET] <thebombzen> well yea that's why I used twice the gop length for 120
[22:15:46 CET] <furq> i feel like you maybe missed part of this conversation
[22:16:05 CET] <BtbN> it fills like 5 screens of scrolling up, not going to read all of that.
[22:16:09 CET] <thebombzen> I used -g 400 for 60 and -g 800 for 120
[22:16:22 CET] <thebombzen> I took into account twice the framerate so I have the same number of seconds between Iframes
[22:16:37 CET] <furq> increasing the gop length reduced the bitrate at 60fps but didn't at 120fps
[22:16:48 CET] <furq> which i found surprising if nobody else did
[22:16:54 CET] <thebombzen> it didn't to me
[22:16:57 CET] <thebombzen> remember I'm very twitchy
[22:16:59 CET] <thebombzen> it's an fps game
[22:17:06 CET] <thebombzen> Overwatch is really twitchy
[22:17:19 CET] <furq> i don't see why that makes it unsurprising
[22:17:47 CET] <furq> unless you're so twitchy that your twitches only last 8ms
[22:19:53 CET] <thebombzen> http://0x0.st/vPK.jpg http://0x0.st/vPP.jpg
[22:19:59 CET] <thebombzen> this is the difference between consecutive frames at 60 fps
[22:20:18 CET] <thebombzen> wait lemme vstack that
[22:20:42 CET] <furq> is that the much-reviled "tracer" i've heard so much about
[22:21:00 CET] <thebombzen> http://0x0.st/vPZ.jpg
[22:21:11 CET] <thebombzen> by "much-reviled" you mean "muchloved" then yes
[22:21:17 CET] <furq> i do not mean that
[22:21:34 CET] <thebombzen> so whether or not you hate tracer depends on who you play
[22:21:45 CET] <thebombzen> if you play tracer then you like her. if you play roadhog or mccree she's fine
[22:21:54 CET] <thebombzen> if you play mercy or zenyatta you hate her guys
[22:21:57 CET] <thebombzen> her guts*
[22:22:05 CET] <furq> http://www.quake-1.com/docs/any/player.mdl_0.png
[22:22:07 CET] <furq> this is who i play as
[22:22:22 CET] <thebombzen> tracer also happens to be a good test for this
[22:22:25 CET] <durandal_1707> ot
[22:22:31 CET] <thebombzen> because her playstyle is very highmotion and twitchy
[22:22:46 CET] <thebombzen> if you're playing a reinhardt, the huge shield dude, not as much
[23:07:42 CET] <RossW> greetinks sire.
[23:07:49 CET] <RossW> oops, wrong window.
[00:00:00 CET] --- Sun Mar 26 2017