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

burek burek021 at gmail.com
Fri Feb 15 03:05:01 EET 2019


[00:03:28 CET] <mfolivas> Want to get better performance with the encoding/decoding.  I want to try with hardware encoding were image quality and file size but on the decoding side neither of those matter.
[00:03:38 CET] <mfolivas> looking into this: http://trac.ffmpeg.org/wiki/HWAccelIntro
[00:18:23 CET] <mfolivas> is NVENC only supports GPU?
[00:18:58 CET] <BtbN> nvenc, as the name suggests, only works on Nvidia GPUs
[00:19:15 CET] <BtbN> Though it's not run by the GPU, but by dedicated silicon
[00:19:29 CET] <mfolivas> BtbN as always thanks!!
[00:26:10 CET] <mfolivas> any idea how I can get the vaapi_device to play in Quicktime?
[00:26:16 CET] <mfolivas> time ffmpeg -vaapi_device /dev/dri/renderD128 -i two-minute-video.mp4 -vf 'hwupload,scale_vaapi=w=1920:h=1080:format=nv12' -c:v h264_vaapi -level 4.1 -preset fast -compression_level 5 vvapi_two-minute-video.mp4
[00:26:27 CET] <mfolivas> I am not able to play it in Quicktime
[00:29:11 CET] <mfolivas> BtbN I'm trying to see if I can get a quick gain with hw. Right now my videos are taking too long for my business case.
[00:31:18 CET] <hans_> i guess the "retrying with new connection: Invalid argument"-part is a bug? http://paste.debian.net/plain/1067697
[00:31:31 CET] <hans_> anyway, haven't updated my ffmpeg installation in months
[00:32:11 CET] <tmm1> is there a way to select frames *without* some metadata key set
[00:53:14 CET] <brandonkal> Hello, I am trying to generate thumbnails and scale them down. But the output images are the same size as the source. Here is the command:
[00:53:19 CET] <brandonkal> `ffmpeg -hide_banner -y -i src.mp4 -vf scale="240:-1" -vf fps=1/5 stills/img%03d.jpg`
[00:53:38 CET] <JEEB> you are defining vf twice
[00:54:01 CET] <JEEB> -vf "fps=1/5,scale=240:-2"
[00:54:08 CET] <JEEB> probably should do it :P
[00:55:16 CET] <brandonkal> Yep. Thanks JEEB
[02:54:29 CET] <mfolivas> anyone using libmfx?
[02:54:38 CET] <mfolivas> I'm trying to install it in Linux/Debian to be more exact
[05:00:56 CET] <brandonkal> Is it possible to only transcode if the source codec is not the desired output codec? Or should I script ffprobe and then build out the command?
[05:01:39 CET] <brandonkal> Same question for resize. i.e. don't resize to 1080 if source is only 720
[05:30:39 CET] <brandonkal> Another question: ffmpeg is saving my encoding settings to file metadata. That is cool but how do I disable this or save it to a sidecar file?
[07:16:16 CET] <rnmhdn_> ffprobe gives three streams for a file
[07:16:40 CET] <rnmhdn_> I run this to remove the third stream but it doesn't get removed
[07:16:43 CET] <rnmhdn_> ffmpeg -i 8.mp4 -map 0
[07:16:50 CET] <rnmhdn_> / ffmpeg -i 8.mp4 -map 0:0 -map 0:1 -acodec copy -vcodec copy video.mp4
[07:21:03 CET] <rnmhdn_> Here are my streams:
[07:21:20 CET] <rnmhdn_> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661)
[07:21:49 CET] <rnmhdn_> Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo
[07:22:03 CET] <rnmhdn_> Stream #0:2(eng): Data: none (tmcd / 0x64636D74)
[11:09:08 CET] <Ariyasu> im using -ss before -i when encoding to x264 but it's not frame accurate
[11:09:21 CET] <Ariyasu> it's still jumping to the proceding i-frame
[11:09:43 CET] <Ariyasu> i thought that only happened when doing a stream copy
[11:25:10 CET] <Ariyasu> Input #0, mpegts, from 'test.ts':
[11:25:10 CET] <Ariyasu>   Duration: 00:38:59.46, start: 94117.334222, bitrate: 6236 kb/s
[11:25:24 CET] <Ariyasu> what is that "start: 94117.334222" value?
[11:38:25 CET] <JEEB> Ariyasu: start timestamp
[11:38:33 CET] <JEEB> mpeg-ts streams almost never start from zero and go forwards
[11:38:42 CET] <JEEB> ffmpeg.c can (and does by default) adjust it to start from zero
[11:48:35 CET] <Ariyasu> what format is the timestamp jeeb?
[11:50:22 CET] <Ariyasu> i've been issuing "ffmpeg -ss 00:04:55.000 -i" "ffmpeg -ss 00:04:55.040 -i" "ffmpeg -ss 00:04:55.080 -i" "ffmpeg -ss 00:04:55.120 -i" ect... and it always starts on the preceding iframe instead of the frame im specifying
[11:50:56 CET] <Ariyasu> https://pastebin.com/raw/UJKVcEhN these are my test lines
[12:39:50 CET] <th3_v0ice> Ariyasu, iirc -ss in front of the -i is a fast search, and it will go to the nearest I frame. If you specify -ss after -i then it will decode frames and will give you frame level accuracy you are looking for. This method is obviously slower.
[12:40:21 CET] <Ariyasu> thank you th3_v0ice
[12:40:27 CET] <Ariyasu> i will do some testing
[12:40:45 CET] <JEEB> basically if you're not on an IRAP (intra random access picture), it will pick the previous one
[12:40:56 CET] <JEEB> also if it's MPEG-TS the seek is not exact
[12:41:10 CET] <JEEB> you will want to remux to mp4 or so if you want exact'ish cutting
[12:41:26 CET] <JEEB> (or use something that does indexing, like ffms2 through vapoursynth/avisynth)
[12:41:56 CET] <Ariyasu> im trying to save time by not cutting my input file but just using marked cut points from video redo
[12:42:17 CET] <Ariyasu> if i need to remux or index, then im not gonna save any time
[12:42:20 CET] <Ariyasu> but thanks for the info
[12:42:44 CET] <Ariyasu> videoredo has frame acurate cutting though and uses ffmpeg iirc to make it's cuts
[12:42:52 CET] <Ariyasu> so i wonder how it deals with the issue
[12:43:11 CET] <JEEB> sounds like an editor so it decodes, and omst likely either decodes or uses indices like ffms2
[12:43:20 CET] <JEEB> and ffms2 also is a wrapper on top of FFmpeg's libraries
[12:43:27 CET] <JEEB> it just uses the APIs to create an index
[12:43:37 CET] <JEEB> and then you can f.ex. do exact seeks even if the input has no index of its own
[12:44:39 CET] <JEEB> so it depends on if you want to do re-encoding or just cutting of pieces
[12:44:59 CET] <JEEB> (Also if you index + use the APIs nicely you could even do a mix)
[12:45:08 CET] <JEEB> so you re-encode the part where you can't make an exact cut
[12:45:15 CET] <JEEB> and otherwise copy the input stream
[12:46:28 CET] <Ariyasu> jeep i want to encode the entire file
[12:46:44 CET] <Ariyasu> from an input frame i specify
[12:46:53 CET] <Ariyasu> not do cutting or stream copy at all
[12:47:16 CET] <Ariyasu> i will do some testing with the info you have given me
[12:47:18 CET] <Ariyasu> thanks
[12:47:19 CET] <JEEB> then it sounds like you could generate a filter chain
[12:47:31 CET] <JEEB> you just decode the whole shebang, but only pass some frames to the encoder
[12:47:37 CET] <JEEB> instead of -ss -t
[17:30:13 CET] <mfolivas> besides `-preset` what else can affect the performance of rendering?
[17:30:22 CET] <mfolivas> oh, and hardware of course
[17:30:43 CET] <mfolivas> I'm looking for settings that I can tuned on the ffmpeg
[17:30:58 CET] <kepstin> mfolivas: video content, resolution, framerate; filters
[17:31:20 CET] <kepstin> in some cases using a hardware decoder can give a slight speedup to transcodes
[17:32:43 CET] <kepstin> but yeah, in most simple cases the bottleneck is the encoder.
[17:33:21 CET] <kepstin> there may be something specific to the command that you're running where we could give suggestions, but there's no magic options.
[17:33:48 CET] <mfolivas> kepstin thanks! I'm looking to analyze some of the commands like -preset
[17:34:43 CET] <kepstin> "-preset" is an encoder specific option, used most commonly with x264; x264 has a ton of options but aside from specific requirements there's basically no reason to adjust them individually, just use a preset.
[17:35:53 CET] <egrouse> i ended up using -preset in combination with -crf and -tune to get what i needed sort; seems to have knocked off all my previous issues with streams going down
[17:36:17 CET] <egrouse> which is gooood as i was about to start trying to log timestamps so i could resume when it broke but hey
[17:36:19 CET] <egrouse> now it doesnt break
[17:37:29 CET] <kepstin> crf is tricky with live streams, because often you're required to fit in specific bitrate limits - you might want to use vbv controls (the "-maxrate" and "-bufsize" options) to ensure it doesn't exceed the required rates.
[17:37:50 CET] <kepstin> or even a full vbr mode
[17:38:24 CET] <mfolivas> egrouse I need it form video and I need performance
[17:38:35 CET] <mfolivas> not sure if I could use the "fastdecode" in tune
[17:39:07 CET] <egrouse> kepstin, i must admit i currently have both -crf and the maxrate/bufsize options; is it likely only one of them is working therefore?
[17:39:19 CET] <kepstin> egrouse: no, they work in combination
[17:39:35 CET] <egrouse> i did the annoying thing where i made 2 changes at once and im not 100% sure which one actually fixed it
[17:39:48 CET] <egrouse> and ok cool
[17:39:52 CET] <kepstin> "fastdecode" option is generally not useful, only needed if the computer trying to play the video is too slow to decode it
[17:39:52 CET] <egrouse> all good then :)
[17:40:28 CET] <kepstin> although fastdecode will often speed up encoding as well, because it disables some features - but it's better to use a faster preset instead
[17:40:46 CET] <egrouse> currently using 'faster' preset and tune 'zerolatency' with crf 16 and that seems to nail it
[17:41:36 CET] <kepstin> yeah, just check your cpu usage and make sure it's sufficiently below 100% that there's room for it to spike a bit if you get a burst of complex content
[17:42:08 CET] <egrouse> yeah its like 50%
[17:42:26 CET] <egrouse> i had big issues before where it was at 100% all the time and kept cutting out
[17:42:42 CET] <egrouse> but just dropped to 720 instead of 1080 and now its a lot better
[17:42:52 CET] <egrouse> facebook only takes 720p anyway so, shrug
[17:42:59 CET] <kepstin> yeah, if your cpu is pegged at 100% then that means the encoder can't keep up with the realtime data
[17:43:15 CET] <kepstin> (you'll also see the "speed" in the ffmpeg cli status bar go below 1.0x)
[17:43:47 CET] <furq> egrouse: do you actually need sub-second latency
[17:43:52 CET] <furq> because otherwise zerolatency is terrible
[17:44:04 CET] <furq> if you're going to facebook then i'm assuming you don't want it
[17:44:36 CET] <egrouse> im not sure; that was one of the two changes i made at which point it was 'fixed'
[17:44:49 CET] <egrouse> we are pushing to restream which then pushes to fb, twitch, yt - dont know if that makes any difference
[17:45:21 CET] <furq> was it you who needed baseline profile for some reason
[17:45:31 CET] <furq> if so then zerolatency forces baseline iirc
[17:45:36 CET] <egrouse> i dont think so
[17:45:41 CET] <kepstin> yeah, if you're doing something like that then latency obviously isn't a big deal, so i wouldn't use that tune
[17:45:45 CET] <furq> i must be thinking of someone else
[17:45:51 CET] <furq> but yeah zerolatency is almost always bad
[17:45:57 CET] <egrouse> ok cool, i will review settings - cheers for the info
[17:46:08 CET] <egrouse> stream kept getting dropped i think due to delay in processing or not being able to keep up
[17:46:54 CET] <furq> well zerolatency also turns a bunch of stuff off
[17:47:05 CET] <furq> although it also turns frame threading off which will slow things down
[17:47:11 CET] <kepstin> egrouse: if your cpu was at 100% before, then it was probably dropped because your computer wasn't sending video fast enough. solution is to use a faster preset
[17:47:14 CET] <furq> you'd be better off using -preset veryfast or something
[17:47:25 CET] <egrouse> i must say that this here channel is probably the most informative and useful irc channel i've ever been in, ha; learnt so much just by even reading other peoples queries/answers
[17:47:28 CET] <egrouse> so, thanks for that :D
[17:50:31 CET] <egrouse> changed settings will see what happens next time it kicks in ~
[18:12:07 CET] <mfolivas> according to the documentation crf should be between 17-28
[18:12:13 CET] <mfolivas> is that correct?
[18:12:27 CET] <mfolivas> or should I play with that as well to see if that affect performance?
[18:12:43 CET] <furq> aren't you using h264_vaapi
[18:13:19 CET] <Blacker47> mfolivas, at first crf will affect quality and that is with what you should start. cut a short clip of video (10-60 sec) and test with different settings to get what you want.
[18:16:49 CET] <kepstin> note that the preset values and crf values aren't completely separate - changing crf can change encoding speed slightly (particularly lower crf values - resulting in higher bitrates - can be slower depending on other options), and if you change the preset, then the meaning of the crf value changes (quality won't be quite the same, although it's usually pretty close)
[18:17:27 CET] <JEEB> which means that you have your 2500 or so frame sample, and you run different presets over it to check speed differences
[18:17:34 CET] <JEEB> you should end up with the slowest fast enough preset
[18:17:42 CET] <JEEB> then you start with crf 23 and if it looks good you go up
[18:17:46 CET] <JEEB> if you it looks bad you go down
[18:18:17 CET] <JEEB> and you should after that have the slowest preset that is fast enough for you, as well as the highest crf for that type of content (resolution, frame rate, contents)
[18:18:32 CET] <kepstin> yeah, I usually work it by picking a crf from the "reasonable" range that looks ok on medium preset, adjust the preset to get the speed I want, then fine-tune the crf value to set quality if needed.
[18:19:39 CET] <JEEB> but yea, many people who have already encoded some types of content have some sort of default range for *their* eyes and use case
[18:20:01 CET] <JEEB> for example I would know which value I would start with for 720p24 animation if encoding with 10bit x264 :P
[18:20:50 CET] <JEEB> but what you need to underline here is that different content is different, and that different people as well as viewing styles all affect your requirements
[18:20:58 CET] <JEEB> (as far as parameters go)
[18:22:03 CET] <JEEB> also generally it's much easier to go towards something that looks "good enough" from something that might not look exactly good enough, and thus I generally start with the default CRF with x264 (which is aimed a bit on the 'compress more' side)
[18:22:43 CET] <kepstin> i wish figuring out quality/speed settings for vp9 was as easy as with x264
[18:22:56 CET] <kepstin> maybe that's something that'll be better in av1? probably not, but who knows :/
[18:23:11 CET] <JEEB> everyone's favourite - libvpx
[18:23:12 CET] <JEEB> :)
[18:23:22 CET] <kepstin> (x264 was *really* terrible to use until they added the preset stuff, btw)
[18:23:49 CET] <kepstin> before the presets system, you'd just copy/paste bad option sets off wikis and hope they did ok :/
[18:23:50 CET] <JEEB> yup
[18:24:15 CET] <furq> i can't imagine people would put bad video encoding settings on a wiki
[18:24:30 CET] <furq> next you'll be telling me they're doing it in forum posts
[18:25:38 CET] <egrouse> :D
[18:26:42 CET] <kepstin> did they eventually end up removing that x264 code that printed a warning if it detected options that looked like the bad defaults from old ffmpeg versions?
[18:26:49 CET] <JEEB> nope
[18:26:50 CET] <kepstin> must have, i can't seem to find it any more.
[18:26:53 CET] <JEEB> oh
[18:26:56 CET] <kepstin> hmm, then i just can't find it
[18:27:06 CET] <JEEB> let me just boot my dev VM
[18:27:45 CET] <kepstin> a sufficiently old ffmpeg where that would be an issue wouldn't compile against current x264 anyways
[18:27:59 CET] <JEEB> true
[18:28:41 CET] <JEEB> encoder/encoder.c:            x264_log( h, X264_LOG_ERROR, "broken ffmpeg default settings detected\n" );
[18:28:59 CET] <JEEB> 545de2ffec6ae9a80738de1b2c8cf820249a2530
[18:29:03 CET] <JEEB> so at that point it was still there
[20:51:33 CET] <tmm1> how can i render a video frame's planes to separate images?
[20:52:43 CET] <DHE> https://ffmpeg.org/ffmpeg-filters.html#extractplanes sounds like what you want
[20:53:02 CET] <tmm1> thanks!
[20:55:48 CET] <tmm1> is there a way to get ffplay to start timestamps at 0 like ffmpeg's output does
[20:59:17 CET] <kepstin> the timestamps starting at 0 is something the ffmpeg cli tool has special code to do on the inputs
[20:59:47 CET] <kepstin> if you just want to reset timestamps in ffplay, you could do something like setpts=PTS-STARTPTS, but note that it'll break a/v sync.
[21:05:12 CET] <tmm1> ok cheers
[21:14:24 CET] <tmm1> are there any docs on the various modes in vf_blend
[21:14:58 CET] <durandal_1707> tmm1: there is documentation for all filters
[21:15:44 CET] <tmm1> yes i see the vf_blend docs but i'm curious what modes like dodge, freeze, linearlight etc do
[21:17:30 CET] <durandal_1707> look at source code
[21:49:20 CET] <tmm1> are there any examples of how to use the hysteresis filter
[21:51:00 CET] <JEEB> seems like it takes two inputs
[21:53:20 CET] <JEEB> yea, seems to be -filter_complex "[0:v][1:v]hysteresis[outcome]" -map "[outcome]"
[21:53:36 CET] <JEEB> so two video inputs, filter them and you should get one output?
[21:54:09 CET] <TheWild> hello
[21:55:28 CET] <TheWild> got mpv and vtt out of the internets, converted vtt to ass, burned on top of mp4. But the two-line subtitles don't sync quite right. How I can get just single line?
[21:55:40 CET] <TheWild> *got mp4 and vtt
[21:56:28 CET] <JEEB> you probably need some sort of merging of lines that are during the same time or so. not sure if there's anything automagic for that
[21:57:59 CET] <TheWild> :/
[21:58:17 CET] <TheWild> the original vtt has correct, single line subtitles. Just ffmpeg messes it up.
[21:59:07 CET] <JEEB> huh, it shouldn't convert that sort of stuff
[21:59:18 CET] <JEEB> if there's a single line that's a single AVSubtitle
[21:59:32 CET] <TheWild> I'm getting first subtitle displayed on lower row, next on upper row and lower doesn't disappear
[21:59:34 CET] <JEEB> unless the webvtt "decoder" makes multiple rectangles
[21:59:51 CET] <JEEB> oh
[21:59:58 CET] <JEEB> also timings shouldn't be touched
[22:00:11 CET] <JEEB> so if it has overlapping timings then -fix_sub_duration is probably for you
[22:00:18 CET] <JEEB> if they shouldn't overlap
[22:00:31 CET] <TheWild> lower is changed when next subtitle comes into play, but because of the alternating lines, the sentences are just mangled.
[22:00:32 CET] <JEEB> but then again that's just a workaround for broken timings in that case
[22:00:44 CET] <TheWild> overlapping timings? Oh, I didn't check this
[22:01:13 CET] <TheWild> oh gosh
[22:01:47 CET] <TheWild> point for you, and ffmpeg didn't mess up anyting. Just the subtitles are in fact overlapping :/
[22:02:07 CET] <JEEB> yea, for better or worse the decoders and encoders generally don't poke at the values too much
[22:02:30 CET] <JEEB> but yes, you either fix the overlaps yourself, or if you're OK with "show until next one" then -fix_sub_duration does that
[22:06:59 CET] <TheWild> "show until next one" is fine, but -fix_sub_duration doesn't seem to make a thing. Does it only work when converting subtitles and not burning them in?
[22:07:41 CET] <JEEB> it should work since it's adjusting by the decoded AVSubtitles (unless that thing is somehow skipped with the lavfi flow that you're using)
[22:07:55 CET] <JEEB> right, it probably is since you're using the subtitle filter most likely
[22:11:36 CET] <TheWild> converted vtt to ass again with -fix_sub_duration, the resulting file seems okay.
[22:11:41 CET] <TheWild> Yes! Yes! Yes! Yes!
[22:11:49 CET] <TheWild> this worked!
[22:11:51 CET] <JEEB> :)
[22:11:51 CET] <TheWild> thank you JEEB
[22:34:44 CET] <tmm1> is there a filter i can use to turn all pixels below a certain threshold to black
[22:35:15 CET] <JEEB> probably, I just can't name it
[22:35:28 CET] <JEEB> (as seems to be the answer to most questions regarding "is there a thing for X"
[22:35:30 CET] <tmm1> geq might work
[22:37:45 CET] <furq> geq will work but it's slow
[22:38:04 CET] <furq> you might be able to coerce chromakey/colorkey into doing it but you'll need some extra work to figure out the right values
[22:42:55 CET] <tmm1> i basically want a black/white image based on threshold
[22:49:26 CET] <furq> if you mean literally two colours then you could do a format conversion to monob/monow and back again
[22:49:36 CET] <furq> you wouldn't have any direct control over the threshold though
[22:51:49 CET] <furq> like i said, geq will do this, so probably try that first and see if it's too slow
[22:51:58 CET] <tmm1> awesome, thank you
[22:52:16 CET] <tmm1> yea geq gives me good control over the threshold, but format=monob gets pretty close to what i want too
[22:52:37 CET] <furq> you could mess around with the brightness etc to tune it
[22:53:15 CET] <furq> there's probably some precise way to get the right threshold but i'm not enough of a lavfi guy to tell you
[00:00:00 CET] --- Fri Feb 15 2019


More information about the Ffmpeg-devel-irc mailing list