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

[burek]

[02:53:11 CEST] <ldlework> How do I check if I have VP9 support
[02:57:04 CEST] <Hello71> ffmpeg -codecs
[03:36:38 CEST] <leif> Does anyone have any idea why ffmpeg would set the time base to 1/1000000 with the following filter graph:
[03:36:41 CEST] <leif> https://gist.github.com/LeifAndersen/8cb1294a4e96d4c8bdd0e4805e96d11d
[03:39:43 CEST] <leif> (I also tried using "time_base=1/1000" as part of the buffersink filter, but ffmpeg still seems to change it back to 1/1000000
[04:33:58 CEST] <leif> (Also, for what its worth, I'm getting the time base with av_buffersink_get_time_bae()  )
[04:35:04 CEST] <atomnuker> some containers have specific hardcoded timebases
[04:39:46 CEST] <leif> atomnuker: That would make sense. Although the container I'm using is mp4 with h264 as the codec.
[04:40:08 CEST] <leif> Leading to the error: timebase 1/1000000 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535
[04:51:48 CEST] <furq> leif: fyi you don't need to use explicit labels if the output of one filter and the input of the next filter are the same
[04:52:16 CEST] <furq> e.g. [audio16]afifo[audio17];[audio17]afifo[audio18] is the same as [audio16]afifo,afifo[audio18]
[04:52:26 CEST] <furq> (i'm not going to ask what that actually does)
[05:05:34 CEST] <leif> furq: lol, ya. The graph was actually programatically built, and that's just how it gets rendered to text.
[05:06:12 CEST] <leif> atomnuker: I guess put another way, as far as I can tell, the filter graph doesn't really deal with containers (as I understand it), so how would it know what container requirements are?
[05:07:16 CEST] <atomnuker> the muxer itself can adjust the timestamps to whatever timebase it needs, though usually you're required to give the correct one
[05:18:18 CEST] <ldlework> I'm just getting started with ffmpeg. Why would the following have a bunch of color corruption in the recording?
[05:18:20 CEST] <ldlework> ffcast % /nix/store/9rckxnnabglaf4p2fad97hp3nknhwkgg-ffmpeg-4.0-bin/bin/ffmpeg -f x11grab -framerate 10 -video_size %s -i %D+%c -vcodec libvpx-vp9 -acodec libvorbis -show_region 1 ~/media/captures/3c651290.webm
[05:18:49 CEST] <ldlework> like the colors are all wrong in the video
[05:20:05 CEST] <ldlework> white is pink, black is green
[05:21:43 CEST] <ldlework> hmm seems to only be when I use libvpx-vp9
[05:21:51 CEST] <ldlework> if i just use libvpx it works ok
[05:22:08 CEST] <ldlework> quality is really bad though
[05:22:46 CEST] <furq> vp9 supports rgb, so if i had to guess i'd say your player doesn't support rgb in vp9 properly
[05:22:50 CEST] <leif> atomnuker: Makes sense. I'll look into that, thanks again.
[05:23:24 CEST] <furq> ldlework: add -pix_fmt yuv444p
[05:23:48 CEST] <furq> all desktop browsers that support vp9 support 4:4:4, idk about mobile
[05:25:41 CEST] <ldlework> furq: do you have any recommendations for recording terminals in perfect clarity but not silly inefficient?
[05:25:52 CEST] <ldlework> i have a LOT of artifacts in my video
[05:26:07 CEST] <ldlework> especially as text moves and stuff
[05:26:42 CEST] <ldlework> furq: look at this lol https://i.imgur.com/9WW6laO.png
[05:28:41 CEST] <ldlework> furq: ah when i went back to vp9 with your setting it improved a lot
[05:28:48 CEST] <ldlework> not perfect but big improvment
[05:29:42 CEST] <ldlework> https://i.imgur.com/Zxb3ut6.png
[05:33:00 CEST] <furq> the default bitrate for vp9 is 200kbps
[05:33:05 CEST] <furq> so you probably want to bump that
[05:33:40 CEST] <ldlework> constant quality did the trick
[05:33:56 CEST] <ldlework> furq: I added -crf 30 -b:v 0
[05:34:15 CEST] <ldlework> I guess that is going to make my files really big though
[05:34:38 CEST] <furq> shouldn't be too bad
[05:34:55 CEST] <furq> i mean my actual recommendation for recording terminals would be to use something like asciinema
[05:35:13 CEST] <furq> or an equivalent thing that isn't -as-a-service
[05:35:16 CEST] <ldlework> well it isn't just terminals
[05:35:42 CEST] <ldlework> emacs gui mode, terminals, dmenu and so on
[05:35:51 CEST] <ldlework> mostly text on flat backgrounds is what I meant to say
[05:36:08 CEST] <ldlework> where sometimes the text scrolls or the whole scene changes instantly, etc
[05:36:11 CEST] <furq> do you need browser support
[05:36:22 CEST] <ldlework> I want to display the webm in browsers yeah
[05:36:30 CEST] <furq> you're more or less stuck with vp9 then
[05:36:31 CEST] <ldlework> but most videos should be short
[05:36:36 CEST] <ldlework> ok
[05:36:45 CEST] <furq> h264 would be the only alternative and most browsers don't support 4:4:4 h264
[05:36:55 CEST] <ldlework> furq: what would be the best youtube stuff if I was going to make an actual video recording with voice and stuff
[05:37:04 CEST] <ldlework> same content, but full screen, longer, etc
[05:37:13 CEST] <furq> it doesn't make much difference really
[05:37:17 CEST] <furq> youtube will recompress everything
[05:37:21 CEST] <ldlework> heh ok
[05:37:53 CEST] <ldlework> furq: thanks a lot
[05:38:18 CEST] <furq> if you're going to host it somewhere that recompresses it then you can try using ffv1 or something
[05:38:37 CEST] <furq> it'll obviously be much bigger
[05:58:26 CEST] <ldlework> furq: i set my -framerate 60 but it doesn't seem like 60
[05:58:33 CEST] <ldlework> when recording typing it see it in spurts
[05:58:40 CEST] <ldlework> when smooth scrolling a browser it just jumps around
[06:01:18 CEST] <ldlework> when recording it says fps=3.5
[06:09:02 CEST] <leif> atomnuker: So it looks like the sink's output codec is 'mpeg4, with a pixel format of yuv420p
[08:27:52 CEST] <furq> ldlework: libvpx is principally famous for being incredibly slow
[08:28:03 CEST] <furq> which is part of why i suggested using something lossless to capture
[08:35:55 CEST] <ldlework> furq: i switched over to mp4
[08:36:05 CEST] <ldlework> when i term ffpmeg it is done encoding right away
[08:36:07 CEST] <ldlework> which is nice
[08:36:09 CEST] <ldlework> :P
[08:43:47 CEST] <furq> ok but bear in mind 4:4:4 h264 doesn't have widespread browser support
[08:43:54 CEST] <furq> firefox on windows definitely doesn't support it and never will
[08:44:08 CEST] <furq> and probably on osx as well if anyone actually uses that
[08:44:17 CEST] <furq> also anything chromium-based on windows (other than chrome)
[08:44:33 CEST] <furq> if 4:2:0 looks ok to you then great, but for screen capturing it's probably going to look awful
[08:44:45 CEST] <ldlework> i don't even know what you're saying at me :(
[08:44:51 CEST] <furq> -pix_fmt yuv444p
[08:44:55 CEST] <ldlework> ahhh
[08:45:09 CEST] <ldlework> furq, I'm open to recommendations definitely
[08:46:12 CEST] <furq> actually firefox doesn't support it anywhere for "consistency" with the fact they can't support it on windows
[08:46:15 CEST] <furq> which is dumb but oh well
[08:46:43 CEST] <ldlework> furq: I am mostly interested in two ways of recording one subject. Linux terminals and emacs and stuf, for embedding quick looping snippets in tutorial pages, and to youtube for longer formats.
[08:46:58 CEST] <ldlework> It seems like there is a lot to learn
[08:47:30 CEST] <furq> my recommendations would be: try -pix_fmt yuv420p and see if it looks ok; try messing with the libvpx speed settings (-cpu-used, -row-mt etc); encode to lossless rgb with ffv1 and then encode with libvpx later
[08:47:35 CEST] <furq> in order of how annoying they'll be
[08:47:45 CEST] <furq> bearing in mind youtube will make everything yuv420p anyway
[08:48:39 CEST] <furq> you could also maybe try upscaling the input 2x, which should mitigate how bad yuv420p looks
[10:21:33 CEST] <botik101> hello, can someone please explain to me why we need to use setpts when using beten?
[10:22:30 CEST] <botik101> here ios an example https://pastebin.com/V26HZWzU
[10:23:46 CEST] <botik101> why do i need to set the timestamps to be continuous using setpts=N/FRAME_RATE/TB
[10:29:29 CEST] <botik101> can someone please tell me why this ffmpeg between command would not give me a video? I am running it now, and the poutput file is not playable.
[10:29:43 CEST] <botik101> https://pastebin.com/V26HZWzU
[10:41:44 CEST] <botik101> i need help with between statement for ffmpeg.
[10:58:35 CEST] <botik101> can someone please tell me why this statement would not grab video? ffmpeg -t 200 -i video.mp4 -an -vf "select='between(t,166,12)+between(t,184,7)',setpts=N/FRAME_RATE/TB" out.mp4
[11:14:09 CEST] <furq> botik101: the first value in between has to be lower
[11:18:30 CEST] <botik101> it is not?
[11:19:10 CEST] <botik101> furq: t,166,12 means start from 166 second of the video for 12 seconds
[11:19:29 CEST] <furq> yeah you'd need to do t,166,178
[11:22:01 CEST] <botik101> god dammit
[11:22:04 CEST] <botik101> you are freaking right
[11:22:16 CEST] <botik101> for some reason i thought it was t, start time, length
[11:24:10 CEST] <furq> http://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation
[11:24:42 CEST] <botik101> furq: ok, it is still copying only the audio track
[11:28:51 CEST] <botik101> I took yoru advice and fixed between as this: ffmpeg -t 200 -i video.mp4 -vf "select='between(t,166,178) +between(t,184,191)', setpts=N/FRAME_RATE/TB" out.mp4
[11:29:19 CEST] <botik101> it is still only copying autiotrack... ffmpeg reports that it only wrote audio and no video
[11:30:48 CEST] <botik101> I checked the input video - it is 2 hours of soccer game - I can see it...
[11:38:56 CEST] <botik101> furq: I figured ut a problem (partially). if you specify only select for video and do not say -an, you actually get the whole file, only video will be present where it is inside between. The rest will only be sound...bizzare
[11:43:23 CEST] <Mavrik> Why bizarre?
[11:43:46 CEST] <Mavrik> If you leave a 2 hr audio track inside and only include 10 minutes of video in the middle, what else did you expect to happen? :P
[11:45:31 CEST] <botik101> mavrik - - I thought that by using select filter, it would only copy the information when select filter would be true
[11:45:54 CEST] <Mavrik> Yes, and it does.
[11:46:04 CEST] <Mavrik> But it's a filter that only runs on the video :)
[11:46:10 CEST] <Mavrik> (-vf = video filter)
[11:46:13 CEST] <Mavrik> So audio track gets untouched.
[11:46:16 CEST] <botik101> Mavrik:  now it makes sense
[11:46:17 CEST] <Mavrik> or any other streams
[11:46:26 CEST] <Mavrik> *is untuched
[11:46:44 CEST] <botik101> mavrik , I am more troubled by setpts = .... I cant figure out why it is necessary
[11:47:05 CEST] <Mavrik> No idea, it retimestamps the frames
[11:47:11 CEST] <Mavrik> Probably horribly breaking audio sync >P
[11:47:19 CEST] <botik101> Mavrik: I understand that we need to copy the timestamps but why N/FRAME_RATE/TB and not N/TB or START_PCT
[11:48:13 CEST] <Mavrik> No idea really :/
[11:48:37 CEST] <Mavrik> I'm guessing it also makes sure you have a constant framerate video
[11:49:03 CEST] <Mavrik> Which on iOS makes sense due to camera recording a variable framerate video
[11:49:13 CEST] <Mavrik> But it still probably makes it a bit judderz
[11:49:17 CEST] <Mavrik> *juddery
[12:56:34 CEST] <salatfreak> I'm trying to split a h264 video without reencoding it, so that I can concatenate the parts again without any stuttering. When using 'ffmpeg -t 2 -i video.mp4 -c copy start.mp4' and 'ffmpeg -ss 2 -i video.mp4 -c copy end.mp4' to split it and 'echo -e "file 'start.mp4'\nfile 'end.mp4'" | ffmpeg -safe 0 -protocol_whitelist file,crypto,pipe -f concat -i - -c copy concat.mp4' it does stutter unfortunately. How can I fix this?
[13:11:56 CEST] <kepstin> salatfreak: when copying video without re-encoding, you can only cut starting on a keyframe.
[13:12:16 CEST] <kepstin> salatfreak: if you want to cut at arbitrary times exactly, you have to reencode.
[13:21:47 CEST] <salatfreak> kepstin: I'm fine with ffmpeg cutting at keyframes as long as the concatenated videos don't stutter. How can I make it do that?
[13:22:54 CEST] <kepstin> if you don't want the concatenated videos to stutter, you have to find out in advance where the keyframes are, so you can sut on the exact correct times. Getting the end time right is important
[13:23:26 CEST] <kepstin> but you might want to use the "segment" muxer instead for this case
[13:23:37 CEST] <kepstin> it's designed to split files on keyframes
[14:08:03 CEST] <salatfreak> kepstin: Yay! 'ffmpeg -i video.mp4 -f segment -segment_times 2 -c copy segment_%02d.mp4' does the job :)
[17:50:16 CEST] <Triskel> hello !
[17:50:55 CEST] <Triskel> what is simpliest than obs to rtmp/streaming the desktop ?
[17:51:43 CEST] <BtbN> what?
[17:52:51 CEST] <ChocolateArmpits> there's probably none
[18:34:06 CEST] <ariyasu> Triskel, https://trac.ffmpeg.org/wiki/Capture/Desktop
[18:37:32 CEST] <kepstin> note that, particularly on windows, obs has a much better-performing screen capture than ffmpeg.
[18:39:14 CEST] <atomnuker> and on linux ffmpeg has something that obs can't compare with anywhere - kmsgrab
[19:15:30 CEST] <tmatth> atomnuker: whoa didn't know kmsgrab was a thing
[19:15:33 CEST] <tmatth> neat
[20:15:13 CEST] <kubast2> So I took a look at googles crf recommends for low res I am guessing the "37" for 240p is like there for lulz or they tested it on a 4k/1080p monitor without making it decentlly big inch/centimeters wise
[20:15:29 CEST] <kubast2> like it makes me bleed my eyes
[20:16:02 CEST] <kepstin> doesn't really matter what you set the quality to, 240p will make your eyes bleed unless it's no bigger than around 3-4" :/
[20:16:22 CEST] <kubast2> sure but like at 20 crf it looks pretty good for a 240p video
[20:16:38 CEST] <kubast2> both a like 1:1 and 2:1 and 1080p fill it doesn't bleed artifacts at all times
[20:16:39 CEST] <kubast2> at least
[20:16:40 CEST] <furq> by google do you mean a google result or do you mean their recommendations for youtube
[20:16:50 CEST] <kubast2> good VOD recomended settings
[20:16:56 CEST] <kubast2> as in google
[20:16:58 CEST] <furq> idk why i asked because they're both terrible
[20:16:58 CEST] <kepstin> They made those recommendations based on youtube, iirc, where the 240p is only sent to people playing video on potatoes over 3g
[20:17:27 CEST] <kepstin> so it was more important for it to be small instead of good looking
[20:17:30 CEST] <kubast2> Yeah and on phones it would look a bit better I guess
[20:17:41 CEST] <kubast2> even upscalled to 1080p I guess(?)
[20:17:45 CEST] <DHE> also note that google transcodes everything, so within reason it's best to provide google high quality sources
[20:18:21 CEST] <kepstin> but yeah, you'll basically never see the 240p stream on youtube unless you're in extremely bad network conditions
[20:18:38 CEST] <leif> I asked a similar question last night (local time), but I'm having a similar problem so I'll try again (also thanks to atomnuker for the help last night.). Anyway:
[20:18:43 CEST] <kepstin> if you have more bandwidth, they'd send you a bigger video size.
[20:18:54 CEST] <kubast2> yeah I am figuring out what resolution and what crf can I get away with to transcode for my phone and fit as much videos as possible tbh
[20:19:03 CEST] <BtbN> they send you 240p if you tab away but leave the video running
[20:19:21 CEST] <leif> I have a filtergraph, and when I run avfilter_graph_config() on it, it sets the time base to 1/1000000
[20:19:25 CEST] <kepstin> ah, true, that works since they can switch the video/audio separately.
[20:19:52 CEST] <kepstin> leif: what filters are in the filtergraph? filters can change the timebase.
[20:19:53 CEST] <leif> But this is a problem because the output codec is mpeg4. So does anyone know why avfilter_graph_config() would change the output to an invalid time-base?
[20:20:08 CEST] <kepstin> that's perfectly valid, that's AV_TB.
[20:20:22 CEST] <leif> kepstin: https://gist.github.com/LeifAndersen/8cb1294a4e96d4c8bdd0e4805e96d11d
[20:20:26 CEST] <kepstin> you probably just need to rescale timestamps when muxing to the container
[20:20:35 CEST] <kubast2> BtbN, yeah 240p is the highest audio quality res on youtube afaik ,they don't increase the quality over it
[20:20:48 CEST] <kubast2> as in they set 160kbps opus
[20:20:50 CEST] <kepstin> youtube can independently switch audio and video quality
[20:20:51 CEST] <kubast2> for 240p
[20:20:54 CEST] <kubast2> oh
[20:21:04 CEST] <leif> kepstin: I get this error: timebase 1/1000000 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535
[20:21:10 CEST] <leif> (When I begin to write.)
[20:21:22 CEST] <DHE> leif: sounds like you forget to set the time_base parameter to the `buffer` filtergraph input
[20:21:24 CEST] <kubast2> I didn't knew about that; 144p is locked to lower audio qualities though(?) at least as of right now ,that's how I suspected the site works
[20:22:01 CEST] <DHE> snprintf(args, sizeof(args), "video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:pixel_aspect=1/1",width, height, pixfmt, avfctx->streams[i]->time_base.num, avfctx->streams[i]->time_base.den); // what I'm using
[20:22:04 CEST] <kepstin> leif: weird, when you set up the output format context with your requested timebase, it should have changed to to an acceptable value I thought.
[20:22:17 CEST] <kepstin> or maybe it only does that when scaling up, not down
[20:22:27 CEST] <DHE> see also: https://ffmpeg.org/ffmpeg-filters.html#buffer
[20:22:38 CEST] <leif> DHE: The buffer arguments are: video_size=1920x1080:pix_fmt=0:time_base=1/1000
[20:22:49 CEST] <kepstin> leif: anyways, I think the concat filter always outputs with AV_TB, you could try just throwing an fps filter after it.
[20:23:14 CEST] <leif> kepstin: AH, okay. That may be it, I'll give it a shot! Thanks.
[20:23:47 CEST] <kepstin> but I forget exactly how that interacts with the filter stuff :/
[20:24:10 CEST] <kepstin> (it's weird, and that's one of the sources of those 'past duration too large' messages you sometimes see with ffmpeg)
[20:24:17 CEST] <leif> kepstin: OMG, that seems to work.
[20:24:32 CEST] <leif> thank you so much.
[20:24:49 CEST] <kepstin> I have a half-written patch hanging around that makes concat preserve the timebase if all inputs match :/
[20:24:55 CEST] <kepstin> maybe i should finish that
[20:25:14 CEST] <kepstin> (current concat filter is broken if a later input has a higher fps than an earlier input, btw)
[22:11:39 CEST] <leif> kepstin: Hmm...thanks for the heads up.
[22:12:08 CEST] <leif> Anyway, I'm programmatically generating the filtergraph (which is why there was the redundant fifos), so its not a big deal to just change it back. :)
[22:12:15 CEST] <leif> Anyway, thanks again.
[00:00:00 CEST] --- Thu Aug 23 2018