[Ffmpeg-devel-irc] ffmpeg.log.20150814
burek
burek021 at gmail.com
Sat Aug 15 02:05:01 CEST 2015
[01:19:28 CEST] <wget> Hi guys. Does anyone know what the FFmtech was about? http://ffmpeg.org/pipermail/ffmtech-board-election/2011-June/000001.html I can only find such emails from MLs, but cannot have a clear definition. WWas that related to libav?
[01:23:28 CEST] <llogan> wget: try #ffmpeg-devel for that one
[01:57:33 CEST] <wget> llogan: OK thanks ;-)
[02:18:01 CEST] <vdg> hi o/
[02:20:34 CEST] <vdg> i need(for a project) cut videos (on a pipe with ffmpeg) with 1 sec max in lengh. I try segment(-f) but i get videos of ~3 secs, then, i force add keyframes to see if I can reduce the lengh without any sucess
[02:20:38 CEST] <vdg> (http://paulherron.com/blog/forcing_keyframes_with_ffmpeg/)
[02:21:21 CEST] <vdg> can anyone help me saying some sort of thing then i can use o read to improve my result?
[02:39:08 CEST] <well0ne> Hi, can someone maybe help me to translate a Sentence to german? Its heavy
[02:41:07 CEST] <klaxa> well0ne: depends on the sentence, but i'll give it my best
[02:41:41 CEST] <klaxa> but let's take this to a query since it is (apparently) not at all ffmpeg-related
[02:41:57 CEST] <well0ne> i know
[03:39:39 CEST] <TikityTik> what are some tricks to reducing webm size?
[03:40:03 CEST] <TikityTik> to squeeze like 0.5 MB more?
[03:41:12 CEST] <kepstin> lower the requested bitrate by an amount that corresponds to the filesize decrease you want?
[03:44:45 CEST] <TikityTik> kepstin: I already did that
[03:44:59 CEST] <TikityTik> but the quality is already so shitty
[03:45:34 CEST] <TikityTik> i did manage to fit a lot more though using -ac 1 -ar 22000 -b:a 64k
[03:45:53 CEST] <kepstin> oh, so you want to improve quality without changing the filesize? or reduce filesize without lowering quality? THat's a rather different question ;)
[03:45:54 CEST] <TikityTik> does lowering -ar actually help with size quite a bit?
[03:46:12 CEST] <TikityTik> kepstin: I want good quality with a low file size
[03:46:29 CEST] <kepstin> TikityTik, changing -ar without changing -b:a doesn't change -b:a.
[03:47:11 CEST] <TikityTik> isn't more data stored though with higher -ar?
[03:47:14 CEST] <kepstin> if you want less bits you have to either tell it you want less bits, or use a quality-based encoder setting rather than bitrate
[03:47:36 CEST] <kepstin> TikityTik, you're using -b:a 64k, so the audio encoder will try to output approximately 64kilobits ever second.
[03:47:39 CEST] <TikityTik> i am using libvpx along with -b:v -crf -bufsize
[03:48:01 CEST] <kepstin> if you want it to output less bits, then set the requested bitrate lower.
[03:48:47 CEST] <TikityTik> it's already at 171 kbps
[03:48:55 CEST] <kepstin> with 22kHz mono, you could probably be ok with around 32-48kbit audio instead of 64kbit.
[03:49:01 CEST] <TikityTik> and looks pretty crappy even at 360 resolution
[03:49:50 CEST] <kepstin> if you don't mind seeking sucking a bit, you can try increasing the keyframe interval, that should improve the video quality (without changing file size)
[03:50:17 CEST] <kepstin> set -g to something like 10*framerate
[03:51:40 CEST] <TikityTik> this is what i'm using atm, ffmpeg -i out.mkv -c:v libvpx -c:a libvorbis -bufsize 2M -crf 10 -b:v 203k -vf scale=-1:480,subtitles=out.mkv -ac 1 -b:a 32k -ar 22000 -sn -g 240 out.webm
[03:52:36 CEST] <kepstin> You can try setting the video encoder options "-quality good -speed 0' and see if that improves quality a bit
[03:53:00 CEST] <kepstin> if you do that and increase the keyframe interval with -g, that's the best you're gonna get with vp8
[03:53:32 CEST] <TikityTik> vp8 uses -quality? and what's -speed?
[03:53:53 CEST] <kepstin> TikityTik, see http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-speed
[03:54:16 CEST] <kepstin> the ffmpeg option "-quality good" corresponds to "--good" and "-speed 0" corresponds to "--cpu-used 0"
[03:54:27 CEST] <kepstin> that's the recommended settings for high quality, slow vp8 encoding
[03:55:27 CEST] <TikityTik> I thought those were for h264 only
[03:55:41 CEST] <TikityTik> yeah, i'm getting incorrect parameter
[03:55:48 CEST] <kepstin> no, h264 uses a completely different set of options
[03:56:00 CEST] <kepstin> h264 doesn't have '-quality' or '-speed'
[03:56:59 CEST] <TikityTik> my mistake, mistyped -speed fast
[03:57:09 CEST] <TikityTik> how does -quality work?
[03:57:44 CEST] <kepstin> TikityTik, it sets some mode inside the vpx encoder, which things inside the black box that few people understand.
[03:58:11 CEST] <TikityTik> but why would i change -quality to realtime, best, good?
[03:58:26 CEST] <kepstin> read the doc I linked
[03:58:33 CEST] <TikityTik> and is it okay to use with -crf and -b:v?
[03:58:54 CEST] <kepstin> yes.
[03:59:09 CEST] <kepstin> note that -crf in libvpx does not behave like it does in h264.
[03:59:09 CEST] <TikityTik> i see
[03:59:28 CEST] <TikityTik> should i just use -best?
[03:59:31 CEST] <TikityTik> err, --best
[04:00:07 CEST] <kepstin> if you have lots of time to waste for no guaranteed gain, sure.
[04:00:29 CEST] <TikityTik> there's no gain?
[04:00:42 CEST] <TikityTik> also changing to -g 7200 didn't seem to change seeking
[04:00:50 CEST] <TikityTik> i tried to make it where you could only seek every 30s
[04:00:56 CEST] <kepstin> according to the libvpx docs that i told you to read, ' Setting --good quality and --cpu-used=0 will give quality that is usually very close to and even sometimes better than that obtained with --best'
[04:01:10 CEST] <TikityTik> i am reading it
[04:01:12 CEST] <kepstin> TikityTik, the player will still be able to seek anywhere, it'll just be slower
[04:01:17 CEST] <TikityTik> "This usually gives the best quality output but is extremely slow."
[04:01:19 CEST] <TikityTik> that's why i asked
[04:01:51 CEST] <kepstin> TikityTik, if you have lots of time to waste, try both, pick the one that's better quality/smaller.
[04:02:02 CEST] <TikityTik> i only need to encode 2 minutes so
[04:03:33 CEST] <kepstin> if your goal is to hit a specific filesize with max quality, you really should be doing a 2-pass bitrate encode (no -crf)
[04:04:00 CEST] <TikityTik> why is that? I heard -crf is best to maintain constant quality
[04:04:25 CEST] <kepstin> you use -crf mode if you want a certain quality and don't care about file size
[04:04:47 CEST] <kepstin> you use 2-pass bitrate encode if you want a specific filesize and as much quality as you can get in that size
[04:04:52 CEST] <TikityTik> i see
[04:05:14 CEST] <kepstin> (admittedly, crf mode in libvpx is kind of weird in how it interacts with the bitrate setting)
[04:05:18 CEST] <TikityTik> so how would that look like option wise?
[04:05:38 CEST] <TikityTik> -bufsize 2M -bt 210k?
[04:06:11 CEST] <kepstin> same options as you have, but remove -crf, add -pass 1, then re-run again with -pass 2
[04:06:35 CEST] <TikityTik> what do you mean re-run?
[04:06:41 CEST] <kepstin> run the same command twice
[04:06:53 CEST] <kepstin> except use -pass 1 the first time, and -pass 2 the second time
[04:06:55 CEST] <TikityTik> wouldn't that overwrite the output?
[04:06:58 CEST] <kepstin> yes
[04:07:11 CEST] <TikityTik> wow
[04:07:18 CEST] <kepstin> it collects statistics about the video during the first run, and uses them to optimize the bitrate during the second encode.
[04:07:34 CEST] <TikityTik> i'm really glad ffmpeg is so advanced, but there's so much to learn hahah.
[04:07:52 CEST] <kepstin> this is really a property of the codec, not ffmpeg itself.
[04:08:09 CEST] <kepstin> (although lots of codecs do this, it's standard practise)
[04:08:15 CEST] <TikityTik> but https://people.xiph.org/~j/ffmpeg.html isn't even on the wiki is it?
[04:09:29 CEST] <TikityTik> i'm not sure how I would be able to google for that
[04:09:30 CEST] <kepstin> the ffmpeg-codecs doc for libvpx gives the option mappings, but doesn't have any descriptions
[04:09:33 CEST] <TikityTik> err find it
[04:09:50 CEST] <TikityTik> yeah
[04:10:03 CEST] <TikityTik> kepstin: how did you find that page?
[04:10:12 CEST] <kepstin> which one, http://www.webmproject.org/docs/encoder-parameters/?
[04:10:20 CEST] <kepstin> that's just the official doc for libvpx.
[04:10:36 CEST] <TikityTik> no, https://people.xiph.org/~j/ffmpeg.html
[04:10:53 CEST] <TikityTik> I'm already impressed with 2-pass
[04:11:24 CEST] <TikityTik> like there's so much more detail
[04:11:28 CEST] <TikityTik> still blocky though
[04:11:47 CEST] <kepstin> well, with that kind of bitrate/filesize, it's never gonna look great with vp8.
[04:12:46 CEST] <kepstin> but if you use a large value for -g, either '-quality best' or 'quality good -speed 0', and do a 2-pass encode, that's the absolute best the codec can possibly do at the requested file size.
[04:12:51 CEST] <TikityTik> kepstin: how did you learn about -pass? Is that a vpx thing only?
[04:12:58 CEST] <k_sze> So reusing the codec context straight out of the stream doesn't always work, right? What method will always work? allocate a new codec context and copy it?
[04:13:02 CEST] <TikityTik> I mean a libvpx codec option only.
[04:13:05 CEST] <kepstin> TikityTik, no, it's a common thing many codecs support.
[04:13:25 CEST] <kepstin> TikityTik, very useful back when we were encoding movies with xvid to put on a 700mb cdrom, for example :)
[04:13:32 CEST] <TikityTik> lol
[04:14:02 CEST] <kepstin> not so useful nowadays, since most people aren't trying to fit videos in constrained space
[04:14:14 CEST] <TikityTik> well for websites it is
[04:14:15 CEST] <kepstin> still used for stuff like dvd/bluray authoring, probably.
[04:14:34 CEST] <TikityTik> most websites have file limits if it's a public upload
[04:15:43 CEST] <kepstin> yeah, well, the modern, erm, online video publishing community tends to just use -crf encodes now, since they don't usually have to worry about file size limits, and it's faster
[04:16:05 CEST] <TikityTik> kepstin: want to see what i encoded after?
[04:16:31 CEST] <kepstin> note that the -crf mode in libvpx isn't nearly as good as the one in h264, in my opinion
[04:16:46 CEST] <TikityTik> i noticed that -crf is pretty shit
[04:16:49 CEST] <TikityTik> with libvpx
[04:17:06 CEST] <kepstin> in h264, using -crf or 2-pass gives the same quality per bitrate, but in vpx -crf kinda sucks
[04:17:40 CEST] <kepstin> fun fact: the way 2-pass encodes in x264 specifically work is that during the first pass it analyzes the video, then it picks a crf. It then does a crf encode as the second pass.
[04:18:03 CEST] <kepstin> crf stands for "constant rate factor" - it wasn't originally supposed to be a user-selectable option
[04:18:11 CEST] <kepstin> it's just an implementation detail of their 2-pass code.
[04:18:47 CEST] <kepstin> libvpx works in a completely different way. They just re-used the option name in ffmpeg because people were familiar with it.
[04:20:24 CEST] Action: TikityTik facepalms
[04:22:06 CEST] <kepstin> the libvpx "CQ" (constant-quality) mode was actually designed by google so that when they were batch-encoding youtube videos, it wouldn't use extra bitrate if the video already looked good enough.
[04:22:38 CEST] <kepstin> so the idea was they'd set -bitrate to the max bitrate they were ok with, then the libvpx cq mode would make some files smaller and save them a bit of disk space and bandwidth.
[04:23:33 CEST] <kepstin> it just happens that if you set the max bitrate really high, then it sort of behaves ok as a quality-based encode setting.
[04:24:23 CEST] <kepstin> (in libvpx, cq mode actually works best with a 2-pass encode, oddly enough)
[04:24:59 CEST] <kepstin> but yeah, to be honest, there's not really much reason to use webm and libvpx any more
[04:26:23 CEST] <kepstin> all three major browsers can play h264 in mp4 just fine, and the x264 encoder is generally somewhat than libvpx, particularly if you let it use high profile and a slow preset.
[04:26:38 CEST] <kepstin> somewhat better than*
[04:28:00 CEST] <TikityTik> yeah but webms don't work with x264
[04:28:23 CEST] <kepstin> yeah, that's why you use mp4 instead :)
[04:28:56 CEST] <TikityTik> /wsg/ doesn't allow mp4s
[04:29:31 CEST] <kepstin> meh, their problem. I guess they don't like visitors who use IE/Edge :)
[04:30:48 CEST] <kepstin> for general web publishing, it used to be that you'd have to put both webm and h264/mp4 videos up to get decent cross-browser coverage, but nowadays mp4 alone does ok.
[04:31:32 CEST] <kepstin> the last holdout was firefox, but it uses system h264 decoders now where available.
[04:31:51 CEST] <kepstin> which is pretty much everywhere except fedora linux :)
[04:33:27 CEST] <TikityTik> kepstin: anyhow it's finished, not sure if this is your kind of thing. https://i.4cdn.org/wsg/1439519554470.webm
[04:34:31 CEST] <kepstin> ... I certainly have a better quality version of that scene locally that i could watch ;)
[04:34:49 CEST] <TikityTik> eh, i made it 4 MB so meh lol
[04:40:57 CEST] <klaxa> didn't know /wsg/ allowed more than 2 minutes
[04:41:10 CEST] <kepstin> looks like it's purely filesize based, i guess?
[04:41:46 CEST] <kepstin> probably most stuff is difficult to get small enough if you have more than 2 minutes.
[04:42:21 CEST] <kepstin> at least while still looking ok :)
[04:55:39 CEST] <TikityTik> klaxa: yeah it's based off filesize, 4 MB is the limit
[05:27:29 CEST] <TikityTik> kepstin: ?
[05:27:42 CEST] <TikityTik> woops forgot to type the question
[05:27:56 CEST] <TikityTik> What does -speed change? Does it affect -cpu-used or -threads?
[05:28:21 CEST] <kepstin> the "-speed" option in ffmpeg changes the libvpx setting named 'cpu used'
[05:29:08 CEST] <TikityTik> kepstin: Also, when using -threads, does it affect quality?
[05:37:57 CEST] <pzich> TikityTik: I think it will if you're optimizing for realtime, otherwise it'll just be slower
[05:43:09 CEST] <TikityTik> pzich: what is realtime?
[05:44:28 CEST] <TikityTik> meaning encode as fast as the video would be playing?
[10:22:38 CEST] <rosafi_> Good morning
[10:24:16 CEST] <rosafi_> I am trying to create HLS stream using FFMPEG, I am having two kinds of streams -video and audio-. In other samples there are three streams -audio, video and id3-. How can I get the ID3 tag automatically?
[10:27:35 CEST] <k_sze> Hi guys. I encoded hundreds of hour-long surveillance video using libx264 encoder in ffmpeg.
[10:27:58 CEST] <k_sze> sometimes I see that the first frame of a video does not have a timestamp of 0.0 second.
[10:28:18 CEST] <k_sze> Is that just AVStream.mux_ts_offset?
[10:35:46 CEST] <rosafi_> Hi, how can I add timed text metadata to my HLS ts files using ffmpeg?
[10:46:57 CEST] <kvz> Hi, I sent an email too root with what I think is a very interesting a hosting proposal for FFmpeg, but didn't hear back yet. Should I assume all is settled and you are not interested, or did something go wrong and do you want to checkout the proposal still? I can put it up in a gist if you want?
[10:48:03 CEST] <JEEB> kvz: developers are at the -devel channel
[10:48:12 CEST] <JEEB> also a lot of the discussion was done on the -devel mailing list
[10:49:54 CEST] <kvz> Thanks, I'll try -devel.
[11:48:46 CEST] <Fyr> what container can be used for h265?
[11:49:23 CEST] <JEEB> it's standardized in both 14496-15 (aka you can put it into mp4) as well as MPEG-2 Systems
[11:49:47 CEST] <JEEB> additionally matroska has (more or less) copied the 14496-15 mapping
[11:49:59 CEST] <Fyr> ok, what containers?
[11:50:10 CEST] <JEEB> those are the three containers :P
[11:50:20 CEST] <Fyr> mp4, mkv ... and?
[11:50:30 CEST] <Fyr> m2ts?
[11:50:36 CEST] <JEEB> mpeg-ts in general, yes
[11:50:45 CEST] <Fyr> ts or m2ts?
[11:51:28 CEST] <JEEB> they are technically the same thing :P m2ts usually is 192 byte mpeg-ts (which can also be parsed as 188 byte content)
[11:53:30 CEST] <Fyr> you could just write "mkv, m4v/mp4, ts."
[11:53:50 CEST] <JEEB> m4v is not usually used for mpeg-4 systems derivatives :P
[11:54:45 CEST] <JEEB> although I have no idea what Apple calls some stuff, I think ffmpeg will just output raw MPEG-4 Part 2 (standard that XVid and DivX based upon) with dot-m4v
[11:55:16 CEST] <Mavrik> I think Fyr is still unhappy due to TMI :P
[11:55:24 CEST] <iive> isn't m4v mp4 without audio?
[11:56:26 CEST] <Fyr> obviously, JEEB doesn't understand completely the topic, that's why he wrote so many words.
[11:56:42 CEST] <JEEB> lol
[12:02:01 CEST] <JEEB> Mavrik: yes, I tend to give information. he asked about containers after all. also it was clear he didn't understand what was (in general) the difference between m2ts (or the lack of it)
[12:02:41 CEST] <Mavrik> That wasn't a criticism ;)
[12:02:53 CEST] <Mavrik> iive, eh, there's a bunch of minor nuances around the MPEG4 conatiners
[12:03:07 CEST] <Mavrik> where some players (*cough cough Apple*) like to make a fuss
[12:03:30 CEST] <JEEB> as far as ffmpeg is concerned m4v is "DE m4v raw MPEG-4 video"
[12:03:34 CEST] <JEEB> which is what I noted
[12:03:49 CEST] <JEEB> but apple IIRC could have used m4v for mpeg-4 container + DRM + video (and usually audio)
[12:04:02 CEST] <JEEB> since they also used the m4a extension for audio stuff
[14:22:59 CEST] <cowai> Can ffmpeg stream mpegts tcp to itself without a server?
[14:23:33 CEST] <cowai> so that others can connect and look at the stream without using multicast udp?
[17:24:08 CEST] <jarr0dsz> hi everyone
[17:24:16 CEST] <jarr0dsz> im trying to compile ffmpeg but getting a ERROR: libtheora not found on ubuntu
[17:24:28 CEST] <jarr0dsz> anyone an idea how i could resolv that? searching for an apt-get package failed on me for this libtheora
[17:38:51 CEST] <DHE> you need libtheora-dev actually
[17:38:57 CEST] <DHE> or if you don't want theora, you can build ffmpeg without it
[19:20:11 CEST] <Nolski> Hi, I'm noticing a lot of incremental skipping and fragmenting when converting from avi to webm. Is there a more proper way of doing it rather than ffmpeg -i foo.avi foo.webm?
[19:23:42 CEST] <Mavrik> Nolski, using default settings for reencode usually isn't the best idea
[19:23:49 CEST] <Mavrik> Since ffmpeg sometimes chooses terrible settings
[19:24:00 CEST] <Mavrik> https://trac.ffmpeg.org/wiki/Encode/VP8
[19:24:16 CEST] <Mavrik> Use the CRF settings
[19:24:38 CEST] <Nolski> Mavrik: ah, I figured that was the case. Thanks :)
[19:25:27 CEST] <Mavrik> Yep, wiki: "Important: If neither -b:v nor -crf are set, the encoder will use a low default bitrate and your result will probably look very bad. Always supply one of these optionsideally both." :)
[19:25:56 CEST] <Nolski> Wise advice haha.
[19:33:27 CEST] <TikityTik> Why is my bitrate going above my specified target bitrate?
[19:33:46 CEST] <JEEB> how are you calculating?
[19:33:47 CEST] <TikityTik> Even though I have -maxrate 436k, i'm getting 1366 kbps
[19:33:53 CEST] <JEEB> and how are you setting it?
[19:34:01 CEST] <BtbN> What encoding mode are you in?
[19:34:02 CEST] <JEEB> + which encoder
[19:34:04 CEST] <TikityTik> ffmpeg -ss 0:14.85 -i in.webm -c:v libvpx -c:a libvorbis -vpre webm -maxrate 436k -b:v 372k -ac 1 -b:a 64k -vf scale=1280:720 -vol 512 out2.webm
[19:34:07 CEST] <TikityTik> vp8
[19:34:08 CEST] <JEEB> oh
[19:34:13 CEST] <JEEB> libvpx is just like that
[19:34:19 CEST] <JEEB> enjoy
[19:34:19 CEST] <TikityTik> err what
[19:34:28 CEST] <JEEB> I wish I was joking :P
[19:34:37 CEST] <TikityTik> so any advice?
[19:34:49 CEST] <TikityTik> kepstin: you awake? :D
[19:34:59 CEST] <JEEB> 1) set bufsize as well 2) hope things help 3) scream at google
[19:35:02 CEST] <BtbN> ~0.4Mbps is a little low for 720p
[19:35:09 CEST] <BtbN> It might just be unable to do that.
[19:35:17 CEST] <JEEB> yes, libvpx probably just goes "nope"
[19:35:31 CEST] <JEEB> and instead of warning you about going over maxrate+bufsize it just goes on happily
[19:35:31 CEST] <TikityTik> BtbN: can i make the resolution 720p but have shitty quality?
[19:35:42 CEST] <BtbN> Aparently libvpx can't.
[19:35:45 CEST] <BtbN> Use x264
[19:35:47 CEST] <TikityTik> Also i had no problem doing it with another 720p video
[19:35:59 CEST] <JEEB> then it required less rate
[19:36:13 CEST] <JEEB> as in, it was simpler to compress
[19:36:26 CEST] <TikityTik> wtf
[19:36:32 CEST] <JEEB> also check your vpre's contents
[19:36:41 CEST] <JEEB> although what you set after them /should/ override them
[19:37:02 CEST] <TikityTik> !paste
[19:37:04 CEST] <JEEB> also if you're using an older version of libvpx you might see if there's a newer version
[19:37:18 CEST] <JEEB> although that would be a case of compiling stuff
[19:37:23 CEST] <TikityTik> this is what i got: http://pastebin.com/nBsVfuyE
[19:37:41 CEST] <JEEB> (also since google hates proper releases you have to manually check what is the version of libvpx used in the latest stable of chrome)
[19:38:14 CEST] <JEEB> I really wonder why google doesn't just tag them as releases :P
[19:38:19 CEST] <TikityTik> i notice my bitrate went down without using that preset
[19:38:29 CEST] <JEEB> uhh
[19:38:37 CEST] <JEEB> you were limiting the rate control
[19:38:44 CEST] <JEEB> see qmax and qmin
[19:38:52 CEST] <JEEB> also that is way big bufsize
[19:38:52 CEST] <TikityTik> ah true
[19:38:57 CEST] <TikityTik> why's that?
[19:39:07 CEST] <TikityTik> i'm making 4 MB files
[19:39:14 CEST] <JEEB> well the idea of bufsize is that the player buffers that amount
[19:39:22 CEST] <JEEB> and then maxrate is calculated over that amount of data
[19:39:26 CEST] <JEEB> so it never goes over it
[19:39:43 CEST] <JEEB> effectively you're not really limiting the bit rate at all if your files end up being 4MB :P
[19:40:17 CEST] <TikityTik> so what bufsize do you recommend?
[19:40:39 CEST] <JEEB> depends on how you are planning to play that thing
[19:40:51 CEST] <TikityTik> through firefox
[19:40:53 CEST] <JEEB> becausee bufsize should be set to the same value at encoding and playback
[19:41:02 CEST] <JEEB> well, d'uh
[19:41:18 CEST] <JEEB> but you can basically think of "X seconds of buffer" with X*maxrate
[19:41:46 CEST] <JEEB> so if you set bufsize to twice maxrate, it means you have to buffer two seconds and after that as long as libvpx doesn't fuck up you should never have to buffer again
[19:42:00 CEST] <JEEB> as long as your network connection is at least maxrate
[19:42:38 CEST] <TikityTik> if i don't specify a crf value, what happens?
[19:43:00 CEST] <JEEB> you are overriding it anyways on your command line with -b:v
[19:43:26 CEST] <JEEB> also crf doesn't mean the same as with x264 or x265, not to mention that they changed what it gets matched to with vp9 and vp8 in libvpx :P
[19:43:32 CEST] <TikityTik> i hear you should try to do 2-pass, crf, and targetted bitrate'
[19:44:18 CEST] <JEEB> if you are doing things over limited bandwidth you should be using VBV (bufsize+maxrate is called that) and either CRF (although this is usually with libx264 or libx265) or 2pass average bit rate
[19:44:37 CEST] <TikityTik> no, i'm worried about filesize and quality
[19:44:39 CEST] <JEEB> so [VBV] + [some sort of rate control]
[19:44:51 CEST] <JEEB> well of course, everyone is :P
[19:45:08 CEST] <TikityTik> JEEB: https://boards.4chan.org/wsg/thread/247727/welcome-to-wsg#p543929
[19:45:22 CEST] <JEEB> I'm just telling to you that if you are doing stuff over some kind of limited bandwidth you should *always* use VBV (which is maxrate+bufsize)
[19:45:59 CEST] <JEEB> what the flying fuck
[19:46:10 CEST] <JEEB> why would someone set both CRF and average bit rate
[19:46:16 CEST] <JEEB> those two effectively null each other away :P
[19:46:26 CEST] <JEEB> they are two completely different modes of rate control
[19:46:32 CEST] <JEEB> so whichever you set last stays
[19:46:39 CEST] <JEEB> s/stays/sticks/
[19:47:00 CEST] <Nolski> wait really?
[19:47:13 CEST] <JEEB> I will guess the person meant one or the other by including both of them in the same line
[19:47:23 CEST] <Nolski> so if you do -crf 10 ... -b:v 1M it just uses the -b:v option?
[19:47:26 CEST] <JEEB> yes
[19:47:36 CEST] <JEEB> since the thing parses the command line from the beginning to the end
[19:47:41 CEST] <TikityTik> a lot guides i read recommended using crf and b:v
[19:47:53 CEST] <TikityTik> :S
[19:48:15 CEST] <TikityTik> JEEB: so what should i use if I want to control based off quality for vp8?
[19:48:16 CEST] <JEEB> if you don't believe me you can go read the libvpx wrapper's code :P
[19:48:16 CEST] <Nolski> That's very unexpected, I wonder why tutorials would ever do that
[19:48:37 CEST] <TikityTik> JEEB: Also I've been reading this. https://boards.4chan.org/wsg/thread/700091/webm-academy
[19:48:46 CEST] <JEEB> I'm pretty damn sure CRF and ABR (average bit rate) are two separate cases in a switch statement
[19:49:32 CEST] <Mavrik> JEEB, IIRC libvpx actually does some magic if you set both P
[19:49:39 CEST] <Mavrik> It was retarded.
[19:49:45 CEST] <JEEB> wtf... let me check
[19:49:59 CEST] <Mavrik> Not sure if they patched that out though, It's been like a year when I've played with it.
[19:50:08 CEST] <JEEB> although I'm not sure if you even can set both rate controls at the same time
[19:50:22 CEST] <JEEB> I mean, on libavcodec level
[19:51:30 CEST] <JEEB> wow
[19:51:50 CEST] <JEEB> I have read through libx264.c and it's much simpler to read than libvpx.c
[19:53:10 CEST] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libvpxenc.c#L411
[19:53:18 CEST] <JEEB> does this mean what I think it means?
[19:53:39 CEST] <JEEB> if you set maxrate or bufsize or initial buffer occupancy, you *must* set some sort of bit rate
[19:54:08 CEST] <JEEB> this... makes no fucking sense
[19:57:31 CEST] <Mavrik> That's about the most common and proper response to libvpx.
[19:57:53 CEST] <DHE> x264 does most of the checking logic in the codec itself, simplifying the ffmpeg layer a bit.
[19:58:15 CEST] <JEEB> DHE: I'm still flabbergasted at it needing the -b:v there
[19:59:25 CEST] <JEEB> I will guess it's due to the libvpx wrapper setting bit rate to rc_target_bitrate
[19:59:42 CEST] <JEEB> which is probably required for the maxrate+bufsize to work correctly?
[19:59:46 CEST] <TikityTik> if I'm using the concat filter, https://trac.ffmpeg.org/wiki/Concatenate#filter , then do I need to specify encoding options again or will it try to use similar encoding options?
[19:59:48 CEST] <JEEB> because I just...
[20:00:10 CEST] <JEEB> TikityTik: for one output same set of settings are used
[20:00:22 CEST] <JEEB> or well, it is a single encode basically
[20:00:32 CEST] <TikityTik> JEEB: so if i put, ffmpeg -i out3.webm -i out2.webm -filter_complex "[0:0] [0:1] [1:0] [1:1] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" out.webm
[20:00:39 CEST] <TikityTik> it will use the same settings?
[20:01:01 CEST] <TikityTik> it doesn't seem to be the case
[20:01:02 CEST] <JEEB> [v] and [a] will be the inputs, and you have a single output
[20:01:25 CEST] <DHE> so before output.webm you can put your settings
[20:01:33 CEST] <TikityTik> JEEB: i mean if it will apply the same options from the input file to the output file
[20:01:36 CEST] <JEEB> no
[20:01:41 CEST] <TikityTik> ah :S
[20:01:42 CEST] <JEEB> that should never be the case
[20:01:56 CEST] <JEEB> your inputs are irrelevant at the point where you are re-encoding them
[20:07:51 CEST] <Nolski> God, why is libvpx so freaking slow
[20:09:22 CEST] <JEEB> vp8 encoding shouldn't be too bad, although of course still slow compared to libx264
[20:09:39 CEST] <JEEB> vp9 on the other hand could end up being quite slow even with the ~year old threading
[20:10:33 CEST] <Nolski> I'm encoding vp8 and it's 24 frames/sec
[20:10:47 CEST] <JEEB> consider that fast for that encoder ;)
[20:12:26 CEST] Action: Nolski cries
[20:19:19 CEST] <TikityTik> why can't i make ffmpeg make a video incredibly loud?
[20:21:43 CEST] <Nolski> TikityTik: doesn't the aeval filter do that?
[20:22:07 CEST] <Nolski> http://www.ffmpeg.org/ffmpeg-filters.html#aeval
[20:22:42 CEST] <TikityTik> will bitrate also interfere with volume?
[20:22:50 CEST] <JEEB> no
[20:23:07 CEST] <JEEB> if the audio encoder can't encode your audio within the rate you set to it, you will just get audio artifacts :P
[20:23:09 CEST] <durandal_1707> volume filter
[20:25:26 CEST] <TikityTik> i find it doesn't go as loud as i want it to
[20:25:36 CEST] <TikityTik> I'm trying to make some john cena clip
[20:25:44 CEST] <TikityTik> with the volume filter that is
[20:25:48 CEST] <TikityTik> but let me check aeval
[20:26:34 CEST] <durandal_1707> what kind of loud?
[20:26:50 CEST] <TikityTik> like hurting your ears loud lol
[20:27:10 CEST] <TikityTik> trying to make these, https://i.4cdn.org/wsg/1437203959574.webm
[20:27:10 CEST] <durandal_1707> with bunch of clipping
[20:27:15 CEST] <TikityTik> nah
[20:27:30 CEST] <TikityTik> perhaps even louder
[20:27:33 CEST] <TikityTik> than that vid
[20:27:56 CEST] <TikityTik> the worst i've seen was this, incoming anime though, https://i.4cdn.org/wsg/1439526609768.webm
[20:32:37 CEST] <durandal_1707> just increase bass
[20:33:00 CEST] <TikityTik> but why is it that when i increase volume, it doesn't get louder?
[20:33:13 CEST] <TikityTik> almost to the point of crackling
[20:34:09 CEST] <ChocolateArmpits> compress the audio, then increase volume
[20:34:20 CEST] <durandal_1707> what command you tried?
[20:34:42 CEST] <TikityTik> -vol 20, -filter_complex volume=20
[20:35:31 CEST] <durandal_1707> use compand to compress audio
[20:35:47 CEST] <TikityTik> why would compressing the audio make it louder?
[20:37:28 CEST] <ChocolateArmpits> Because you are limiting the dynamic range, if you want everything to be loud i.e. on a short dynamic range, you have to compress
[20:38:22 CEST] <durandal_1707> Exactly
[20:38:31 CEST] <TikityTik> I have no idea what i'm looking at when i'm reading compand
[20:38:45 CEST] <TikityTik> https://www.ffmpeg.org/ffmpeg-filters.html#compand
[20:38:53 CEST] <TikityTik> in terms of how to type this all out
[20:39:33 CEST] <TikityTik> for instance, it doesn't describe attacks
[20:39:56 CEST] <durandal_1707> defaults also kills some dynamic ranges
[20:41:24 CEST] <TikityTik> what is attacks?
[20:42:04 CEST] <ChocolateArmpits> the point in time when the compression is initiated
[20:42:37 CEST] <ChocolateArmpits> or actually any audio filter, the term is broad
[20:43:08 CEST] <ChocolateArmpits> it's even written in the compand section "attacks refers to increase of volume and decays refers to decrease of volume"
[20:43:14 CEST] <TikityTik> i'm guessing the max values are -1 to 1?
[20:44:12 CEST] <durandal_1707> only points option really matter for you
[20:46:57 CEST] <TikityTik> i have no idea what values to even put for points, as i'm googling on what it means
[20:47:02 CEST] <TikityTik> what is x0/y0?
[20:47:32 CEST] <TikityTik> this is supposed to be a function right? but it looks like it's making an evelope
[20:48:54 CEST] <durandal_1707> input volume to output volume
[20:49:55 CEST] <TikityTik> why would you even specify input volume if it's a transfer function?
[20:50:57 CEST] <TikityTik> and why is it negative?
[20:51:10 CEST] <durandal_1707> say from -60 to -20
[20:51:57 CEST] <durandal_1707> Its in dB
[20:52:12 CEST] <TikityTik> but you cannot hear under 0 dB
[20:53:17 CEST] <durandal_1707> this is different unit
[20:54:39 CEST] <TikityTik> what?
[20:54:41 CEST] <durandal_1707> lowest is usually -90 highest is 0
[20:54:49 CEST] <TikityTik> :|
[20:57:44 CEST] <TikityTik> durandal_1707: how do i specify a default value for attacks and decays?
[20:57:58 CEST] <TikityTik> can i just put 'nul' or something?
[20:58:26 CEST] <durandal_1707> just do not give it
[20:58:58 CEST] <TikityTik> durandal_1707: it's complaining though
[20:59:15 CEST] <TikityTik> durandal_1707: it's complaining though, -filter_complex "compand=-90/0"
[20:59:42 CEST] <durandal_1707> compand=points=....
[20:59:51 CEST] <TikityTik> ah, i apologize
[21:00:36 CEST] <TikityTik> durandal_1707: so would i just put -90/0 to make everything loud?
[21:00:54 CEST] <durandal_1707> try it
[21:01:03 CEST] <TikityTik> i did but i'm not sure if i could make it louder
[21:01:29 CEST] <durandal_1707> Add more points
[21:02:00 CEST] <durandal_1707> that ends to 0
[21:02:29 CEST] <TikityTik> wouldn't i have to do that from -90 to 0 to make everything loud?
[21:02:58 CEST] <TikityTik> well not, constricted
[21:03:07 CEST] <TikityTik> well, not constricted*
[21:03:48 CEST] <durandal_1707> not really
[21:06:08 CEST] <TikityTik> i still don't understand points
[21:06:18 CEST] <TikityTik> is -90 the quietest?
[21:07:14 CEST] <durandal_1707> usually, you can go lower
[21:08:02 CEST] <TikityTik> i didn't notice a big jump in volume, -filter_complex "compand=points=-900/0|-90/0|0/0,volume=200"
[21:08:46 CEST] <durandal_1707> -90/0 -80/0 -70/0 -40/0...
[21:11:15 CEST] <TikityTik> yeah it didn't give much of a jump in volume, "compand=points=-90/0|-80/0|-70/0|-60/0|-50/0|-4
[21:11:15 CEST] <TikityTik> 0/0|-30/0|-20/0|-10/0,volume=200"
[21:11:28 CEST] <TikityTik> ignore that linebreak
[21:14:56 CEST] <durandal_1707> hmm perhaps mcompand from sox can help you it compress bands
[21:15:38 CEST] <durandal_1707> multi band compressor
[21:33:54 CEST] <ChocolateArmpits> multibandcompressor is only needed to compress different parts of the spectrum band
[21:34:12 CEST] <ChocolateArmpits> if you want to up the volume then common compressor is enough
[21:41:17 CEST] <TikityTik> ChocolateArmpits: why can't i make it very loud?
[21:48:23 CEST] <TikityTik> ChocolateArmpits: I've tried, -filter_complex "compand=attacks=0.1:points=-90/0|-80/0|-70/0|-60/0|-50/0|-40/0|-30/0|-20/0|-10/0:gain=10dB,volume=2"
[00:00:00 CEST] --- Sat Aug 15 2015
More information about the Ffmpeg-devel-irc
mailing list