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

[burek]

[01:51:13 CEST] <TikityTik> is there a difference to putting the video filter before specifying the video codec and codec settings vs after??
[01:51:24 CEST] <TikityTik> and does 2 pass actually help crf encoding with libvpx?
[01:53:40 CEST] <JEEB> the major differences are between input and output related parameters, their order within those two don't really matter other than if you define something twice :P
[01:54:07 CEST] <TikityTik> so there's no difference in what i said?
[01:54:15 CEST] <JEEB> ffmpeg INPUT_OPTIONS_FOR_INPUT -i INPUT OUTPUT_OPTIONS_FOR_OUTPUT OUTPUT
[01:55:02 CEST] <JEEB> basically you can have multiple inputs and outputs and the order of the options matter in the sense if they're before or after inputs and f.ex. before which input or output they come
[01:55:12 CEST] <JEEB> but if you have the most common case, then you have one input and one output
[01:55:31 CEST] <JEEB> and thus it only matters that options you meant for output are after input and before output
[01:55:38 CEST] <JEEB> and what you meant for input are before input
[01:56:15 CEST] <JEEB> the order within those parts only matter on the level of "if you define option X more than once, most likely the last definition will stand"
[01:57:41 CEST] <TikityTik> thanks, and what about 2pass for libvpx crf?
[01:59:53 CEST] <furq> TikityTik: yes it does actually help because -crf isn't really crf for vpx
[02:00:28 CEST] <furq> although mostly because vpx's rate control is just generally bad
[02:00:38 CEST] <furq> a lot of features are only enabled on the second pass
[02:01:31 CEST] <TikityTik> also how do i know what bufsize to use? i don't know when to have 1 MB bufsize of 4 MB bufsize
[02:01:50 CEST] <furq> what makes you think you need to set bufsize
[02:02:00 CEST] <DHE> vbv demands it, but he doens't understand the rules
[02:02:01 CEST] <TikityTik> crf doesn't work without bufsize i believe
[02:02:10 CEST] <DHE> no
[02:02:21 CEST] <TikityTik> oh?
[02:02:40 CEST] <DHE> are you specifying both a bitrate and crf setting?
[02:03:11 CEST] <TikityTik> DHE: now i'm only doing either CBR or CRF only
[02:03:20 CEST] <TikityTik> not both since i learned that it's crap lol
[02:03:42 CEST] <furq> yeah you need to set -b:v 0
[02:03:49 CEST] <furq> or -b:v max-bitrate
[02:04:15 CEST] <TikityTik> so if i want to use only crf i need -b:v 0?
[02:04:18 CEST] <furq> yes
[02:04:24 CEST] <furq> unless something changed recently
[02:04:27 CEST] <TikityTik> how do i figure this out on my own without IRC? lol
[02:04:36 CEST] <furq> no comment
[02:04:50 CEST] <DHE> you get true constant-quality mode, but the codec can do whatever it wants in terms of bitrate
[02:04:56 CEST] <furq> this is particular to libvpx, other encoders have less dumb default settings
[02:05:02 CEST] <TikityTik> heh
[02:05:44 CEST] <furq> also i can't find an authoritative source for 2-pass cq being better that's newer than about 2011
[02:05:45 CEST] <TikityTik> i don't need bufsize if i do CBR i assume?
[02:05:54 CEST] <TikityTik> only cbr and not crf
[02:05:55 CEST] <furq> so maybe that's not true any more but it probably is
[02:06:24 CEST] <DHE> actually you do. CBR is just a variant of VBR where minbitrate, bitrate and maxbitrate are the same number
[02:06:26 CEST] <furq> TikityTik: -b:v isn't cbr, it's abr
[02:06:55 CEST] <TikityTik> ok so i guess i can skip -b:v and use minrate = maxrate?
[02:07:12 CEST] <furq> set b:v to the same value as minrate and maxrate
[02:07:20 CEST] <DHE> usually b and maxrate are good enough
[02:07:21 CEST] <TikityTik> ughh, redundant typing
[02:07:32 CEST] <furq> i don't actually know if you need all three but it can't hurt
[02:07:36 CEST] <TikityTik> so would i need bufsize for that?
[02:07:40 CEST] <DHE> yes
[02:07:46 CEST] <TikityTik> i see...
[02:07:49 CEST] <furq> really?
[02:08:02 CEST] <DHE> I'm an x264 guy, but I'm assuming the rules are about the same, no?
[02:08:04 CEST] <furq> i don't see why bufsize would make a difference if minrate is enforced
[02:08:28 CEST] <furq> actually nvm yes i do
[02:08:45 CEST] <furq> trac doesn't mention bufsize in the cbr section anyway
[02:09:15 CEST] <furq> i'm going to stop thinking about libvpx now because it's hurting my brain
[02:09:19 CEST] <TikityTik> when when do i need to remake pass 1? if i only change input options?
[02:09:27 CEST] <TikityTik> or if i change output options?
[02:10:25 CEST] <DHE> again, I'm an x264 guy. you can usually get away with setting changes on pass 2 that don't affect the frame type decisions (I, P, B)
[02:12:30 CEST] <TikityTik> wow my bitrate sure jumped up with crf mode and setting -b:v 0
[02:20:44 CEST] <TikityTik> thanks everyone for the info btw
[02:25:23 CEST] <another> TikityTik: https://trac.ffmpeg.org/wiki/Encode/VP9
[02:25:33 CEST] <TikityTik> i have to specifically use vp8
[02:25:40 CEST] <another> TikityTik: https://trac.ffmpeg.org/wiki/Encode/VP8
[02:28:10 CEST] <TikityTik> so why do you need -b:v 0 for true crf mode? what is happening without it?
[02:30:50 CEST] <another> constrained quality i presume
[02:32:00 CEST] <TikityTik> what do you mean?
[02:32:59 CEST] <another> see the VP9 article
[02:33:24 CEST] <another> i think most of that applies to VP8 as well
[02:34:49 CEST] <furq> TikityTik: -crf and -b:v together will clamp it to that maximum bitrate
[02:35:08 CEST] <furq> and the default bitrate setting for libvpx is 200kbps
[02:35:15 CEST] <TikityTik> interesting
[02:35:23 CEST] <furq> it's some legacy ffmpeg thing afaik
[02:38:01 CEST] <another> isn't that the default bitrate for all video?
[02:47:22 CEST] <TikityTik> what's a good way of comparing crf encodings to see which one turned out better?
[02:47:36 CEST] <TikityTik> i'm trying to watch it side by side but it's too hard to tell
[02:57:07 CEST] <TikityTik> ah whatever
[02:58:44 CEST] <TikityTik> also is it true that -quality best makes the quality worse for libvpx vp8?
[03:33:29 CEST] <TikityTik> hahah i guess i ask too many questions
[04:31:56 CEST] <buhman> how do I get good quality encoding with h264_vaapi or hevc_vaapi? I tried both intel/radeon cards, and I see very clearly square patches on the output
[04:32:32 CEST] <buhman> I was reading https://trac.ffmpeg.org/wiki/Hardware/VAAPI but a few options I tried from there had no effect (like changing bitrate/profile/..)
[04:47:53 CEST] <TikityTik> just a noob here but i thought using graphic drivers for encoding is worse than using the cpu?
[04:47:59 CEST] <TikityTik> that it's mainly for livestreaming
[04:50:26 CEST] <TikityTik> buhman: is thise for a video file or a stream?
[04:51:42 CEST] <buhman> TikityTik: when you have live input, the encoder needs to be able to keep up with the input framerate
[04:52:21 CEST] <buhman> it doesn't matter so much if the output is a file or "stream" api
[04:55:42 CEST] <TikityTik> buhman: https://video.stackexchange.com/questions/14656/why-processor-is-better-for-encoding-than-gpu
[05:01:58 CEST] <buhman> I don't think any of this is relevant to my question
[05:07:49 CEST] <TikityTik> ah, sorry then
[07:45:29 CEST] <acresearch> people, i have 2 videos that i want to fuse into 1 video, how?
[09:56:21 CEST] <xqo> hello, does anyone understand the WEBM/Matroska format? I'm trying to extract ogg vorbis audio from webms, what kind of element has the actual audio data? frames? blocks? segments?
[09:57:56 CEST] <xqo> The docs are a little hard to read, but I _think_ Segments hold actual file data, and contains all the frames, and that anything outside Segments is metadata. Can someone confirm?
[09:57:59 CEST] <JEEB> looking at a matroska file with mkvinfo with specific flags lets you see the structure. simpleblocks etc usually contain the stuff, although muxers can utilize different muxing techniques
[10:01:32 CEST] <xqo> @jeeb ok! do you also understand how the simpleblocks are arranged? What is confusing is how the docs reference seek-time very often. Do you simply find the first and last simpleblock, and join them all in the order they are in the file, or are they arranged arbitrarily?
[10:03:11 CEST] <xqo> first simpleblock referenced by a track*
[10:06:59 CEST] <acresearch> people, i have 2 videos that i want to fuse into 1 video, how?
[12:13:09 CEST] <hedgehog90> I have a 24fps CFR lossless HuffYUV video and i want to convert it to h264, but it always changes the framerate mode to Variable. I've tried specifying the framerate with -r on both input and output, but it doesn't work. Any ideas?
[12:13:36 CEST] <hedgehog90> (by it I mean ffmpeg always changes the framerate mode to Variable)
[12:16:19 CEST] <hedgehog90> ffmpeg -i input.mkv -r 24 -c:a aac -b:a 384k -vf "scale,format=pix_fmts=gbrp,zscale=m=709:dither=random,format=pix_fmts=yuv420p" -c:v libx264 -preset veryfast -profile:v high -level 4.1 -crf 6 -threads 0 -r 24 output.mkv
[12:18:58 CEST] <durandal_1707> use fps filter and not -r 24
[12:21:48 CEST] <Hypnotoad90_> any known common reason why av_read_frame and/or avcodec_decode_audio4 might start spitting out a bunch of frames that are only one sample long?
[12:23:25 CEST] <durandal_1707> Hypnotoad90_: hmm? needs more info, could be anyting
[12:25:46 CEST] <Hypnotoad90_> unfortunaly don't have access to the machine it occured to at the moment, but it happened on a pcm 2 channel audio stream, after several dozen frames it suddenly started producing frames with unusual sizes after initially being consistently 1024 samples long, for instance dozens of frames only 1 sample long in a row, followed later by a large frame tens of thousands of samples long
[12:26:38 CEST] <durandal_1707> still not enough info
[12:30:05 CEST] <Hypnotoad90_> of course, im checking if there are currently known or frequent issues that could cause that, that i could check against
[12:30:15 CEST] <Hypnotoad90_> im not asking specifically what's causing it in my case right now
[12:35:01 CEST] <hedgehog90> Regarding my framerate issue - I;ve just realised if I remux the supposedly constant frame rate mkv in question using mktoolnix, it says the framerate is 24.203fps and it sets the mode to variable
[12:35:09 CEST] <hedgehog90> What's going on?
[12:36:26 CEST] <JEEB> you can take a look at the timestamps in mkvinfo etc
[12:36:40 CEST] <JEEB> also matroska cannot handle all frame rates exactly
[12:37:05 CEST] <JEEB> I wouldn't be surprised if your input file isn't really possibly CFR either
[13:11:45 CEST] <hedgehog90> JEEB, I just checked and the interval between frames is 42,42,41 repeated until the final frame, which is correct
[13:12:30 CEST] <hedgehog90> Not sure how the avg frame rate 24.102 is being calculated from that...
[13:13:23 CEST] <hedgehog90> So how do I tell ffmpeg to brute force the frame rate to 24fps? And will it cause issues with my audio sync? I tried the fps filter but no luck?
[13:15:56 CEST] <BtbN> Via the fps filter.
[13:16:13 CEST] <BtbN> Audio should stay in sync, the fps filter will only drop or duplicate frames.
[13:16:55 CEST] <hedgehog90> Hmm...
[13:17:46 CEST] <hedgehog90> I just checked the frame interval from an output (the result of an ffmpeg conversion) and the first few frame intervals are: 65 41 42 19 64
[13:17:59 CEST] <hedgehog90> and then 42, 42, 41 for the rest of the video
[13:18:25 CEST] <hedgehog90> I don't want any frame dropping
[13:18:58 CEST] <hedgehog90> I just want to take my supposedly 24fps and prevent ffmpeg from messing with the frame intervals
[13:19:06 CEST] <hedgehog90> as it appears to be doing
[13:19:11 CEST] <BtbN> It doesn't. FFmpeg passes through timestamps.
[13:19:59 CEST] <hedgehog90> and yet my source timestamps appear to be perfectly 24fps
[13:22:09 CEST] <hedgehog90> any ideas what's going on here?
[13:22:31 CEST] <hedgehog90> Maybe I could upload a snippet of the source file and someone could take a look.
[13:30:00 CEST] <hedgehog90> ok, bizarrely this is all being caused by the aduio - I tried the same command with -an (remove audio) instead of converting the original pcm to aac, and now the framerate is a constant 24fps
[13:30:36 CEST] <hedgehog90> So how do I get true 24fp avc with aac audio? This is maddening.
[13:41:38 CEST] <hedgehog90> Another thing - if I don't specify -r 24 for my input, then ffmpeg takes a look at my 42,42,41 interval source file, and just outputs it with all intervals of 41 (24.417 fps)
[13:42:11 CEST] <hedgehog90> I do not get this... please help.
[13:46:12 CEST] <durandal_1707> hedgehog90: your input is not CFR
[13:46:41 CEST] <hedgehog90> Right, it should be 41.6666 interval every frame, right?
[13:47:34 CEST] <hedgehog90> Unfortunately this is the output from the video editing software and I've explicitly set it to export at 24fps. This is what I get.
[13:48:58 CEST] <durandal_1707> leave input as is, and use fps filter to make output CFR
[13:49:31 CEST] <durandal_1707> for 24 fps output it will drop some frames
[13:49:57 CEST] <hedgehog90> I really don't want any dropped frames
[13:50:07 CEST] <BtbN> You'll need to fix your input then
[13:50:14 CEST] <hedgehog90> It's lossless video btw
[13:52:44 CEST] <durandal_1707> cant you make it 25 FPS?
[13:52:52 CEST] <hedgehog90> No
[13:53:15 CEST] <hedgehog90> I could losslessly export each individual frame and reconvert back to video losslessly at 24fps... but surely there's a way of doing this in one command and simply
[13:55:46 CEST] <hedgehog90> If I upload a snippet of the source video will someone please take a look?
[14:04:36 CEST] <durandal_1707> hedgehog90: does vfrdet filter report something useful for your input?
[14:05:47 CEST] <hedgehog90> VFR:0.663900 (160/81) min: 41 max: 42)
[14:06:32 CEST] <hedgehog90> I've check other 24fps mkv files I have, and they all have the same interval pattern as my source. The source appears to be fine.
[14:07:53 CEST] <hedgehog90> If I enter -r 24 before the input, and dont convert the audio to aac, then I retain the same frame intervals and it appears to be genuinely 24fps
[14:08:03 CEST] <durandal_1707> you could change pts to not follow this strange pattern, but i dunno how this should look like...
[14:09:22 CEST] <hedgehog90> By specifying the framerate before the input, i think it's working, but as soon as i try to add aac audio it goes to variable framerate and the first bunch of frames have unusual intervals
[14:14:13 CEST] <hedgehog90> does this odd behaviour ring a bell with anyone?
[14:14:34 CEST] <hedgehog90> why is my audio encoding changing the video's frame rate?
[14:14:48 CEST] <durandal_1707> tried -vsync 0 to input and output?
[14:15:18 CEST] <durandal_1707> they may have weird muxing interval...
[14:16:35 CEST] <hedgehog90> made no difference, variable frame rate again
[14:18:32 CEST] <hedgehog90> it's only the first 5 frames that go 'variable' (ie, not 42,42,41), but this is enough to make my video not processable by some sites
[14:19:11 CEST] <hedgehog90> with aac encoding my first 5 frames have the intervals 65 41 42 19 64
[14:26:23 CEST] <durandal_1707> hedgehog90: if you trim that bad frames, do you get valid output?
[14:29:25 CEST] <hedgehog90> exactly the same frame rate intervals if I trim the beginning
[14:29:40 CEST] <hedgehog90> this appears to be a problem with aac now.
[14:30:30 CEST] <durandal_1707> you could try other aac encoder...
[14:31:01 CEST] <hedgehog90> like?
[14:33:28 CEST] <hedgehog90> definitely something up with my ffmpeg aac encoder. I've just tried uploading some short clips with aac encoding to a particular video processing site  and they all get rejected. I remove the audio and they are accepted.
[14:37:36 CEST] <durandal_1707> it is muxing A+V issue
[14:38:48 CEST] <hedgehog90> could you elaborate?
[14:55:54 CEST] <hedgehog90> Using an mp4 container now, haven't changed anything else, framerate appears to be constant...
[15:03:39 CEST] <JEEB> hedgehog90: mp4 can actually hold a lot of frame rates exactly, unlike matroska
[15:04:23 CEST] <JEEB> think of matroska being only able to specify the times for each audio/video frame on the level of 1/X where X is something divisible by 10
[15:05:29 CEST] <JEEB> but that is usually considered "constant enough rate" if the container cannot hold it 100% exactly
[15:05:34 CEST] <JEEB> same thing with the broadcast MPEG-TS
[15:05:43 CEST] <JEEB> which has a hard-coded time base of 1/90000
[15:05:50 CEST] <JEEB> and FLV, which is hard-coded to 1/1000
[15:53:15 CEST] <Tazmain> Hi all, I have a wireshark trace with RTP, so I can extract the RTP but it was encoded using OPUS, how do I play it or convert to wav. I am really stuck here `ffmpeg  -c:a libopus -i file.raw -vn  sa.ogg` or `ffmpeg -c:a libopus -i file.raw -c copy out.opus` <- I tried this , I get an empty output file
[15:53:49 CEST] <saml> Tazmain, you want to convert to .wav file (audio)?
[15:54:02 CEST] <Tazmain> or play it :(
[15:54:18 CEST] <Tazmain> either convert or play. Not having any luck
[15:55:14 CEST] <saml> mv file.raw  file.ogg;  ffmpeg -i file.ogg file.wav
[15:55:26 CEST] <saml> i don't know exact -f {format} parameter
[15:55:51 CEST] <Tazmain> saml, but the file is raw binary
[15:55:59 CEST] <saml> ffmpeg -f {format-for-opus} -i file.raw -vn -c:a pcm_s32le  file.wav
[15:56:14 CEST] <Tazmain> that is why there is that ` -c:a libopus`
[15:56:14 CEST] <saml> ffmpeg detects type based on extension
[15:56:21 CEST] <Tazmain> oh?
[15:56:35 CEST] <saml> or, you'll have to specify -f format exactly
[15:56:43 CEST] <acresearch> people, i have 2 videos that i want to fuse into 1 video, how?
[15:57:24 CEST] <saml> Tazmain, can you upload the file.raw somewhere?
[15:57:28 CEST] <Tazmain> I can
[15:58:01 CEST] <Tazmain> saml, here you go https://send.firefox.com/download/fe076e66b48e76cc/#RdwKzgQA04_xoD5f3BpYzg
[15:58:07 CEST] <saml> acresearch, maybe use -f concat
[15:58:20 CEST] <saml> https://www.ffmpeg.org/ffmpeg-all.html#concat-1
[15:58:45 CEST] <acresearch> saml: ffmpeg -f concat file1.avi file2.avi    ?
[15:59:51 CEST] <saml> https://trac.ffmpeg.org/wiki/Concatenate
[16:00:18 CEST] <saml> Tazmain, hrm i thought it was just a proper opus container. So, I'm wrong. I don't know how to read the file properly
[16:00:28 CEST] <Tazmain> makes two of us
[16:00:35 CEST] <Tazmain> it comes from RTP
[16:00:41 CEST] <Tazmain> wireshark pcap file
[16:00:45 CEST] <Tazmain> the RTP stream is opus
[16:02:14 CEST] <saml> yeah it's out of my league
[16:07:08 CEST] <Tazmain> saml, looks like pjsip might be able to, it uses ffmpeg
[16:08:11 CEST] <Tazmain> if I can get it to compile that is
[16:10:50 CEST] <saml> Tazmain, it's a raw tcp dump in the middle of stream?
[16:11:07 CEST] <Tazmain> its UDP (RTP) and it's the full conversation
[17:22:31 CEST] <Yamakaja> Hey, i'm a bit lost here - i can't really find any documentation on the mpeg2video codec 0.o
[17:23:07 CEST] <Mavrik> What kind of documentation do you need? :)
[17:23:18 CEST] <Yamakaja> I'd like to know what the -g flag does
[17:23:30 CEST] <DHE> group-of-pictures, or interval between keyframes
[17:23:46 CEST] <Yamakaja> Which unit?
[17:23:49 CEST] <DHE> frames
[17:24:04 CEST] <Yamakaja> Lol, it's set to 1 here
[17:24:55 CEST] <Mavrik> Nice
[17:25:03 CEST] <Mavrik> Efficient stream :)
[17:25:09 CEST] <DHE> that'll skyrocket the bitrate (or tank the quality)
[17:25:26 CEST] <Yamakaja> Alright, another question: I'm currently looking for the best format to stream over the network with the latency reduced as much as possible over a possibly lossy connection (udp) at semi-reasonable bitrates ~10-20mbps max
[17:25:29 CEST] <DHE> for mpeg2 I believe 15-18 is the sort of optimal value
[17:25:59 CEST] <DHE> the quasi-standard is mpegts in CBR mode. the catch is getting the parameters right for it
[17:26:30 CEST] <Mavrik> yp
[17:27:34 CEST] <Yamakaja> Lol, halved my bitrate by setting the value to 18
[17:27:47 CEST] <DHE> I do this quite a bit, but I also have custom patches to libavformat/udp.c
[17:27:57 CEST] <Mavrik> Custom patches for?
[17:28:09 CEST] <DHE> the UDP transmission driver in ffmpeg
[17:28:20 CEST] <Yamakaja> To decrease latency?
[17:28:40 CEST] <DHE> yeah. I enable realtime scheduling, and use file capabilities to let ffmpeg use it (plus other things)
[17:30:03 CEST] <JEEB> yea I think that required root on some level?
[17:30:17 CEST] <JEEB> to get the cap
[17:30:33 CEST] <DHE> yes and no. you can get exactly the cap necessary (cap_sys_nice) without making the process setuid root, or giving other caps
[17:30:46 CEST] <DHE> setcap cap_sys_admin+ep /usr/local/bin/ffmpeg
[17:31:03 CEST] <DHE> setcap cap_net_bind_service,cap_sys_admin+ep /usr/local/bin/ffmpeg    # for also being able to bind to low port numbers. needed for my multicast setup. :(
[17:31:34 CEST] <JEEB> yea I'm happy that low port #s haven't been used in my case yet :)
[17:31:55 CEST] <DHE> yeah I don't have that luxury. :(
[17:32:03 CEST] <Yamakaja> Any hints as to how i should be configuring mpegts?
[17:32:23 CEST] <DHE> Yamakaja: Select a bitrate that is suitable and will never be exceeded. Let's say 17 megabits for the sake of this example.
[17:32:27 CEST] <JEEB> what is the use case? usually you set a muxrtae
[17:32:42 CEST] <JEEB> bitrate is then avoption for udp
[17:32:46 CEST] <DHE> ffmpeg -i <input> <encodingopts> -muxrate 17M -bitrate 17M -pkt_size 1316 -f mpegts udp://239.0.0.1:5000
[17:33:29 CEST] <DHE> if you select too low a speed, you'll get PCR errors from ffmpeg
[17:34:26 CEST] <DHE> I have a patch to my udp driver that does realtime scheduling on the transmission thread. without it you will definitely want to set -burst_bits 50000 or higher
[17:34:44 CEST] <DHE> even with realtime scheduling I find I need 10000 or more
[17:34:51 CEST] <Mavrik> Does ffmpeg still cause a huge amount of pcr jitter if you do muxrate?
[17:35:03 CEST] <Mavrik> Last I check the code was rather funny and not quite correct
[17:35:07 CEST] <DHE> actually forcing CBR mode basically fixes PCR issues
[17:35:27 CEST] <Mavrik> CBR on MPEG-2?
[17:35:35 CEST] <Mavrik> I was only using it for H.264
[17:35:36 CEST] <Yamakaja> I'm a bit confused as to how parameters are assigned to the different "targets" - everything before (since the "target" before that) a "-i", "-c" and "-f" will be applied?
[17:35:51 CEST] <DHE> no, CBR on the mpegts muxer affects its PCR generating behaviour
[17:37:21 CEST] <Yamakaja> I still have pretty much exactly one second of latency in my stream (I'm playing it with vlc with caching set to 50ms)
[17:37:31 CEST] <Yamakaja> Any ideas as to what i could be doing wrong?
[18:21:37 CEST] <DHE> fwiw https://github.com/DeHackEd/FFmpeg/commits/local this is my local patch set. I plan to offer one or two for ffmpeg merging, but most not
[18:59:22 CEST] <rjp421> on linux, can i screen grab a 320x240 area around the cursor? also, can i scale the output to 320x240 keeping aspect ratio of the source (which is not always the same)?  current command 'ffmpeg -f x11grab -r 8 -s 1600x900 -i :0.0+0,0 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video2'
[19:01:20 CEST] <DHE> display aspect ratio is preserved by skewing the sample aspect ratio unless overridden manually when resizing video
[19:20:18 CEST] <TikityTik> is there a way to quickly get an estimate for what crf values for libvpx will get you under a filesize? I thought of adjusting cpu-used and quality but the filesize is way too different i think
[19:24:01 CEST] <TikityTik> also how do you get timestamps with minutes like 8:30 to work with the bottom solution for this? https://trac.ffmpeg.org/ticket/2067
[19:24:14 CEST] <TikityTik> is there a better work around?
[19:29:52 CEST] <cehoyos> If you want a filesize, why don't you pass a bitrate?
[19:30:31 CEST] <TikityTik> because i want to maximize quality and constrained bitrate kind of ruins that
[19:31:42 CEST] <cehoyos> Your question above sounds to me as if you have exactly this constraint. If you don't have it, you should choose the quality you want.
[19:34:41 CEST] <TikityTik> cehoyos: how would i constrain it properly in libvpx vp8?
[19:36:06 CEST] <furq> in theory you want 2-pass abr (-b:v and nothing else)
[19:36:17 CEST] <furq> idk how well that works in practice with vpx though
[19:36:19 CEST] <cehoyos> Do you mean that libvpx-vp8 does not support abr?
[19:36:28 CEST] <cehoyos> (I haven't played with it for some time.)
[19:37:23 CEST] <cehoyos> I certainly hope that 2-pass abr works perfectly with libvpx (if not, it would say a lot about the encoder's quality), the question is if one-pass abr works to some degree...
[19:37:37 CEST] <TikityTik> I found i had better quality just playing around with pure crf alone
[19:37:39 CEST] <furq> there's not much more to be said about the quality of libvpx
[19:37:46 CEST] <furq> particularly its rate control
[19:37:54 CEST] <TikityTik> better results i mean
[19:39:27 CEST] <cehoyos> Ok, I tested 2-pass, it reached two bitrates that I tested to ~0.5% (which is good afair)
[19:39:56 CEST] <furq> iirc it has issues with undershooting
[19:40:11 CEST] <cehoyos> One-pass also works fine here.
[19:40:21 CEST] <TikityTik> so 2 pass is pointless?
[19:40:51 CEST] <TikityTik> cehoyos: can you show me what command you used for your test?
[19:40:57 CEST] <cehoyos> No, it overshot
[19:41:11 CEST] <cehoyos> ffmpeg -i input -pass n -b:v xxx -y out.mkv
[19:41:35 CEST] <cehoyos> 2-pass is definitely not pointless, it just takes longer
[19:42:00 CEST] <TikityTik> hmm, i assumed crf would be vastly superior to abr
[19:42:02 CEST] <furq> iirc some encoder features are only enabled on second pass
[19:42:06 CEST] <furq> so it's especially not pointless for vpx
[19:42:28 CEST] <furq> with something like x264 the first pass pretty much just works out the right crf value for the second pass
[19:42:33 CEST] <TikityTik> because i assume abr would use a lot of bitrate for still scenes and not enough bitrate for fast moving scenes
[19:42:35 CEST] <cehoyos> Especially the feature of "encoding" is only enabled on second pass;-)
[19:42:38 CEST] <TikityTik> if someone can correct me
[19:42:49 CEST] <furq> TikityTik: that's what one-pass abr will do
[19:43:00 CEST] <cehoyos> No, this is exactly what it does not (contrary to constant quality)
[19:43:02 CEST] <TikityTik> interesting
[19:43:23 CEST] <furq> the whole point of two-pass is that it will analyse the whole video and figure out where it can allocate more rate and still hit the target rate
[19:43:54 CEST] <TikityTik> so to avoid overshooting and undershooting i'm guessing just specifying -b:v for 2-pass won't cut it? you need min and max rate specified too?
[19:44:03 CEST] <cehoyos> Even for one-pass abr, it shouldn't do it (and it didn't in my tests, it undershoots for the credits)
[19:44:43 CEST] <furq> it'll make worse decisions though
[19:48:34 CEST] <cehoyos> Yes, there is no free lunch;-)
[19:49:16 CEST] <kepstin> yeah, the goal of abr (without any other limits) is that the average over the whole video hits a certain target.
[19:50:31 CEST] <furq> https://github.com/deterenkelt/Nadeshiko/wiki/Pitfalls-in-VP9
[19:50:39 CEST] <furq> i don't know how accurate this is but it's reinforcing my decision to just stick with x264
[19:51:52 CEST] <kepstin> i kinda wish xpv8 had become a thing
[19:53:15 CEST] <furq> whatever happened to x262
[19:54:09 CEST] <kepstin> i think it ... technically works? but is basically dead in terms of development
[19:54:24 CEST] <furq> did it ever get good enough to be worth using
[19:54:53 CEST] <kepstin> no idea
[20:04:23 CEST] <TikityTik> thanks for the help guys
[20:15:37 CEST] <kepstin> that pitfalls doc is out of date in one respect, you can use -row-mt in recent libvpx versions and the multithreading is less terrible.
[20:19:13 CEST] <kepstin> everything else tho... it's an encoder developed by google for google use cases :/
[20:23:16 CEST] <cehoyos> I expect them to accept patches just as we do...
[21:38:25 CEST] <rjp421> on linux, can i screen grab a 320x240 area around the cursor? also, can i scale the output to 320x240 keeping aspect ratio of the source (which is not always the same)?  current command 'ffmpeg -f x11grab -r 8 -s 1600x900 -i :0.0+0,0 -vcodec rawvideo -pix_fmt yuv420p -threads 0 -f v4l2 /dev/video2'
[21:54:10 CEST] <Ke> sal
[21:54:26 CEST] <Ke> nvm
[21:56:12 CEST] <rnderr> \o/
[21:59:00 CEST] Last message repeated 1 time(s).
[21:59:26 CEST] <relaxed> rjp421: try, ffmpeg -video_size 320x240 -framerate 8 -follow_mouse centered -show_region 1 -f x11grab -i :0.0 ...
[22:00:11 CEST] <relaxed> the output will be 320x240
[22:04:40 CEST] <TikityTik> how do i make sure libvpx abr undershoots my target filesize without resorting to limiting maxrate?
[22:05:04 CEST] <TikityTik> i'm getting like 100 kB off mark but even when i calculate a bitrate by taking away a 100 kB, it still overshoots
[22:05:19 CEST] <TikityTik> not sure if it's abr or vbr when i just specify -b:v
[22:05:37 CEST] <TikityTik> and i'm using 2 pass abr
[22:12:19 CEST] <rjp421> relaxed, cool thanks
[22:14:26 CEST] <rjp421> it works!
[23:14:25 CEST] <TikityTik> anyone know how to avoid overshooting by 100 kB?
[23:14:30 CEST] <TikityTik> for my question?
[23:21:21 CEST] <another> I'm curious: What is your usecase that you need such accurate rate control?
[23:22:04 CEST] <TikityTik> file limits could be 8 MB, or such, and I wanted to push out the max quality for the file size limit
[00:00:00 CEST] --- Tue Apr 30 2019