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

[burek]

[00:07:25 CET] <Bray90820> Ehh it cant hurt
[00:25:51 CET] <johnjay> i've never understood what dual channel or whatever is
[00:26:00 CET] <johnjay> why is having 2 2GB in dual better than a single 4GB ?
[00:31:19 CET] <BtbN> Because it'll be twice as fast
[00:31:29 CET] <BtbN> If your memory controler does dual channel
[00:38:18 CET] <furq> it has twice as much bandwidth
[00:38:32 CET] <furq> that doesn't really matter most of the time but some benchmarks will benefit a lot from it (20-30%)
[00:38:59 CET] <furq> idk how video encoding fares but i assume it benefits more than most
[01:51:09 CET] <analogical> I just realized that FFmpeg can't be taught because it's a black art...
[02:24:31 CET] <mfolivas> @BtbN you mentioned that I should also want to use scale=-2:1080 instead of scale=1920:1080.  Would that make a difference in performance?
[03:00:03 CET] <DHE> no, but it would keep the aspect ratio in case you're not dealing with 16:9 ratios
[03:00:27 CET] <DHE> it would give you 1080 pixels high, and the closest appropriate horizontal resolution that is a multiple of 2 (H264 requirement)
[05:01:53 CET] <kurufu> Oh yea I confirmed the issue with my adaptive sync stuff was nothing to do with mpv and the mpv video filters were working perfectly for doubling/tripling fps. But the screen just has hella pixel artifacts due to overdrive. Thanks TheAMM .
[05:05:36 CET] <kurufu> Also `fps=fps=120, hue=s=mod(n\,2)` in a low contrast high motion scene really makes the artifacts blatant.
[05:07:27 CET] <kurufu> oh this was ffmpeg meant to say this in mpv.
[05:50:09 CET] <Spice_Boy> Hi. I have dashcam video which is h264 and colourspace bt709, and when I convert it with ffmpeg it still looks good as video. If I do a windows vlc snapshot, only the original maintains the colour, but the converted has the lower range/slightly greyer colour. But, on Linux vlc snapshot, both original and converted are greyish
[05:50:16 CET] <Spice_Boy> since the video plays fine, I'm not too worried, just curious
[05:50:41 CET] <Spice_Boy> the only difference I can find is the original has "profile=High" whereas the converted one has "profile=High 4:4:4 Intra"
[05:51:23 CET] <Spice_Boy> I believe there's something to do with nvidia card in windows, but curious to know why the original version from the dashcam does have its snapshot accurate.
[05:53:00 CET] <Spice_Boy> here is the original https://pastebin.com/TgXjynMv and here is the converted https://pastebin.com/zf35RxXH
[10:12:50 CET] <Zexaron> Hello
[10:12:53 CET] <Zexaron> I get [NULL @ 0000027423fa38c0] Unable to find a suitable output format for '20'
[10:12:53 CET] <Zexaron> 20: Invalid argument
[10:12:56 CET] <Zexaron> FRAPS video
[10:13:16 CET] <Zexaron> but the application is the same as usual, it gets updated regularly so maybe they messed something up
[10:13:50 CET] <Zexaron> I was using same fraps as I ever was and no a problem before, some files won't encode, some encodeings stuck and never finish and some encodings go slower
[10:14:02 CET] <Zexaron> I tried the latest and 4.1 stable
[10:14:11 CET] <Zexaron> same thing
[10:15:05 CET] <furq> Zexaron: pastebin the full command line
[10:15:08 CET] <Zexaron> well it's 50 fps and I never used that before, that's the only thing I think it's different
[10:18:11 CET] <Zexaron> furq: https://pastebin.com/qnR9tFtj
[10:18:45 CET] <Zexaron> it's possible the game can't keep up 50FPS, but I don't remember that causing problems in the past
[10:19:11 CET] <furq> this is literally everything except the command line
[10:19:33 CET] <furq> that error message is almost always a broken command line
[10:19:45 CET] <furq> probably a missing - somewhere
[10:21:59 CET] <Zexaron> for %%F in (*.avi) do ffmpeg -i "%%~F" -vcodec libx264 -x264-params crf 20 -movflags faststart -preset slow -acodec libmp3lame -b:a 256k -ac 2 -threads 8 -f mp4 "%%~nF.mp4"
[10:22:01 CET] <Zexaron> oh sorry
[10:22:12 CET] <furq> -x264-params crf=20
[10:22:19 CET] <furq> i was close
[10:22:20 CET] <Zexaron> i guess i was experimenting with crf value, but I was doing that to try to fix something else
[10:22:41 CET] <Zexaron> I gues newwer ffmpeg has diff syntax
[10:22:58 CET] <furq> well it's either -crf 20 or -x264-params crf=20
[10:23:45 CET] <Zexaron> oh
[10:24:13 CET] <Zexaron> well there is some kind of a bug with encoding, it's stuck, it started 85 frames and idling now, CPU utilization idling
[10:24:37 CET] <Zexaron> Codec AVOption b (set bitrate (in bits/s)) specified for output file #0 (DCS_2019-01-25_01-11-39-63.mp4) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream.
[10:24:49 CET] <Zexaron> there's one warning in yellow ^^
[10:25:19 CET] <Zexaron> started encoding now
[11:55:24 CET] <egrouse> i occasionally get an error from ffmpeg when streaming via rtmp: [flv @ 0x5566dc29d180] Failed to update header with correct duration. [flv @ 0x5566dc29d180] Failed to update header with correct filesize.
[11:55:51 CET] <egrouse> why does this occur/how can i stop it? it seems very inconsistent and other videos (and even the same file) with same commands work correctly other times
[19:13:40 CET] <mfolivas> I would like to increase the performance of my encoding time for all my videos.  One thing that people recommended was to take a look at QuickSync
[19:13:47 CET] <mfolivas> Right now this is what I am running
[19:14:37 CET] <mfolivas> time ffmpeg -i two-minute-video.mp4 -vf scale=1920:1080 -profile:v baseline -level 4.1 -crf 17 -preset fast -bf 0 scaled-some-random-video.mp4
[19:15:36 CET] <mfolivas> 1) how can I figure out the encoding and decoding (I think it's by default libx264)
[19:16:15 CET] <mfolivas> 2) how I can use the encoding/decoding for QuickSync? -c:v h264_qsv??
[19:17:39 CET] <DHE> libx264 doesn't do decoding. ffmpeg has its own software decoder
[19:18:15 CET] <DHE> ffmpeg -encoders (or -decoders) will list the available codecs. decoders can be specified with -c:v in front of the input file, encoders can be specified with -c:v in front of the output file. the :v means video obviously
[19:22:53 CET] <mfolivas> @DHE thanks again!  so libx264 is only for encoding!
[19:23:56 CET] <mfolivas> again, my main concern is performance/speed and quality for the videos.
[19:24:13 CET] <mfolivas> I'm trying to understand how is QuickSync going to help me with it?
[19:25:07 CET] <pink_mist> quality is unlikely to be helped by something that's faster
[19:36:18 CET] <DHE> in general hardware encoders are worse in quality compared to software encoding, even on "fast" presets
[19:37:15 CET] <roxlu> hi, does someone knows a way to generate a test video that includes some audio blips/blops that I can use to test synchronisation during playback?
[19:37:33 CET] <pink_mist> aren't there faster presets than 'fast'? like 'veryfast' or something? you could try that instead, mfolivas
[19:47:22 CET] <mfolivas> @ pink_mist yes, I have tried different presents. I also understand that there is a balance between "fast" and "quality". I'm trying to find that balance.
[19:49:28 CET] <DHE> when you're dealing with high resolutions (1080p) it gets harder
[19:55:18 CET] <pink_mist> mfolivas: x264 is really a lot better, quality-wise, than practically all hardware-encoding solutions ... the only time hardware-encoding is better is when quality is far down the line of priorities
[20:02:13 CET] <mfolivas> @pink_mist thanks
[20:03:57 CET] <DHE> I'm told that the RTX GPUs  have a substantially improved hardware encoder over the previous generations (nvenc) but can't quantify it myself. plus they're expensive as all hell.
[20:09:32 CET] <mfwitten> Any idea why 'ffmpeg -i input.mp4 -an -c:v libx264 output.mp4' takes a 29.97 FPS input and tries to create a 120 FPS output (by duping frames)? Is the input (from an Android video recording) wrong? The output, when played, still looks fine.
[20:18:29 CET] <mfwitten> Perhaps time stamps are incorrect in the input? Putting '-vsync 0' still tries to create an output with 120 FPS; adding '-r 29.97' for the output causes ffmpeg to complain about timestamps being non-monotonics, etc.
[20:27:59 CET] <mfwitten> So, I did 'ffmpeg -i input.mp4 -an -c:v libx264 -vsync 0 output.mp4', and ffmpeg was telling me that the output would be 120 FPS, but when I run 'ffmpeg -i output.mp4', it tells me that the movie is 29.95 FPS (not 29.97, mind you!). All very strange.
[20:30:28 CET] <mfwitten> Now, I'm trying with '-r 29.97' (and without -vsync 0): ffmpeg -i input.mp4 -an -c:v libx264 -r 29.97 output.mp4
[20:30:57 CET] <mfwitten> So far, it seems to be working as expected. No dups (except for the usual 2 that ffmpeg makes for some reason, at the beginning)
[20:31:57 CET] <mfwitten> This makes 2 questions then: Is Android producing bad time stamps? Why is ffmpeg choosing 120 FPS for the output by default?
[20:32:29 CET] <JEEB> most likely just variable frame rate
[20:32:54 CET] <JEEB> the phone cameras have variable recording rate due to how long it takes to get the image
[20:33:28 CET] <JEEB> if you want to wonder what's going on, check out the pts values ffprobe -show_packets -show_streams shows :P
[20:33:41 CET] <JEEB> (you can -of json if you want to script it with python/ruby/js or something)
[20:34:15 CET] <mfwitten> JEEB: OK. I'll investigate further in that way. Thanks for the idea. Also, any idea why ffmpeg might choose 120 FPS?
[20:34:51 CET] <JEEB> fuzzy logic? also make sure it's actually 120fps and not also variable frame rate? (although I think the default "vsync" mode is cfr for stuff like mp4)
[20:35:24 CET] <mfwitten> JEEB: If the frame rate is variable on the input, then how come '-r 29.97' did result in any drops or dups (besides the initial 2 that it seems to make every time)?
[20:35:47 CET] <mfwitten> did NOT result, that is.
[20:37:06 CET] <JEEB> mfwitten: can't say anything. also if possible use exact values like 30000/1001 for those /1001 rates
[20:37:44 CET] <JEEB> mfwitten: you'll have to look at the AVPacket dts values if you want to look into what's going on :P
[20:37:56 CET] <JEEB> that's why I noted the ffprobe command
[20:38:10 CET] <JEEB> alternatively look into L-SMASH's boxdumper, which has an option to dump the timestamps
[20:38:30 CET] <mfwitten> Ok. I'll do so. Thanks again
[20:47:37 CET] <analogical> how do I trim the first 10 seconds from a video without reencoding it?
[20:50:06 CET] <brimestone> Hello. How would someone use FFmpeg/FFplay into their project? Is there a guide on how to embed?
[20:51:45 CET] <JEEB> brimestone: see the examples directory under docs
[20:52:05 CET] <JEEB> and then for specific things there's "site:ffmpeg.org doxygen trunk KEYWORD"
[20:52:23 CET] <JEEB> which then can get you to things like https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
[20:55:00 CET] <mfwitten> analogical: Maybe: ffmpeg -i input.mp4 -ss 10 -codec copy output.mp4
[20:55:12 CET] <mfwitten> analogical: (Sorry if that doesn't do it)
[21:11:56 CET] <TheAMM> What does NUT stand for?
[21:12:34 CET] <DHE> it's a custom file format/extension for ffmpeg
[21:12:52 CET] <TheAMM> I know what NUT is
[21:13:08 CET] <TheAMM> But is there any meaning behind the name?
[21:13:52 CET] <friendofafriend> Probably something saucy in Hungarian.
[22:41:14 CET] <mfwitten> JEEB: Running 'ffprobe -show_packets -show_streams input.mp4 2>/dev/null | grep 409088' shows one entry for 'pts=409088' (and it's for an audio packet), while running the same command on 'output.mp4' (after just '-vsync 0') shows 2 entries for 'pts=409088', both of which are video packets. To me, that makes no sense, and it looks like it must be a bug in ffmpeg. Regardless of the input, surely it's a bug
[22:41:20 CET] <mfwitten> for ffmpeg to produce 2 video packets with the same PTS.
[22:48:19 CET] <utack> is there a way to "concat" three image files with different fps? like take three jpg files, tell it "0.1fps first, 1.5fps second, 0.5fps third"?
[22:53:32 CET] <mfwitten> utack: fps? Are you just trying to get different durations of display?
[22:53:45 CET] <utack> yep
[22:54:01 CET] <utack> i can also input duration in ms or whatever, i just thought that "fps" was the fastest way to do it
[23:06:52 CET] <Someone_Else> i'm trying to process an interlaced video file to both save it deinterlaced and apply motion interpolation, like some media players and tv's do
[23:07:19 CET] <Someone_Else> however, i'm not sure if a tv actually doubles the framerate or smooth out the motions, or both
[23:08:04 CET] <Someone_Else> anyhow, it's tricky to find the right command line options for it
[23:08:21 CET] <Someone_Else> it should be fast, as some media players are able to do this real time
[23:09:46 CET] <Someone_Else> it's a m2ts file, 1080i
[23:12:07 CET] <mfwitten> utack: https://trac.ffmpeg.org/wiki/Slideshow#Framerates
[23:13:01 CET] <mfolivas> what does "-profile:v" does in this case: ffmpeg -i two-minute-video.mp4 -vf scale=1920:1080 -profile:v baseline -level 4.1 -crf 17 -preset fast
[23:14:27 CET] <JEEB> sets teh video profile to (constrained) baseline
[23:14:32 CET] <JEEB> profiles are feature sets
[23:14:34 CET] <mfwitten> Someone_Else: Some players just cut the resolution in half, I've read
[23:14:43 CET] <JEEB> you go (constrained) baseline -> main -> high
[23:14:49 CET] <mfwitten> Someone_Else: Meaning, they throw out the interlacing naively
[23:15:15 CET] <JEEB> (constrained) baseline drops most of the features out of the window
[23:15:27 CET] <JEEB> (CABAC and b-frames being the major things)
[23:16:58 CET] <mfwitten> Someone_Else: Take a look through the filters here: https://ffmpeg.org/ffmpeg-filters.html
[23:17:02 CET] <mfolivas> JEEB: if I would like to tune performance, quality, or file size, I would say that "profile" will not affect any of these criteria, right?
[23:17:08 CET] <mfwitten> Someone_Else: There's a number of topics having to do with de-interlacing
[23:17:34 CET] <JEEB> mfolivas: uhh, by setting profile you are limiting the encoder to that (sub-)set of features
[23:17:41 CET] <JEEB> how is that not affecting compression?
[23:17:47 CET] <JEEB> esp. with (constrained) baseline
[23:17:58 CET] <JEEB> which disables most of the useful features in H.264/AVC
[23:18:00 CET] <mfolivas> oh, now I see
[23:18:44 CET] <mfwitten> mfolivas: In case you haven't, take a look at this: https://trac.ffmpeg.org/wiki/Encode/H.264
[23:19:02 CET] <JEEB> if you're using something like CRF that will just lead to the stream utilizing more bit rate for a similar result (same CRF value does not hold between different encoding parameters so I can't just say the same CRF value is the same result)
[23:19:04 CET] <mfolivas> mfwitten: yeah, looking at that page now
[23:19:18 CET] <mfolivas> >Profile: Another optional setting is -profile:v which will limit the output to a specific H.264 profile
[23:19:32 CET] <JEEB> on the other hand, if you're forcing the encoder for a specific bit rate, then you're just losing quality
[23:19:34 CET] <mfolivas> >Omit this unless your target device only supports a certain profile (see Compatibility).
[23:19:42 CET] <mfolivas> hmm, I wonder why we're using this
[23:19:58 CET] <JEEB> by default libx264 will limit you to the profile required by your parameters (preset etc)
[23:20:01 CET] <mfwitten> mfolivas: Well, you can't forget that you have to have a player that can actually play your video
[23:20:04 CET] <Someone_Else> mfwitten: I'm quite sure my player does not. It uses around 40% cpu usage and +/- 25% gpu usage while playing the video. Based on the quality it's definitely not cut in half otherwise I would have noticed
[23:20:05 CET] <JEEB> so most of the time it would be main
[23:20:11 CET] <mfwitten> mfolivas: There's a lot of junk hardware out there.
[23:20:23 CET] <JEEB> Someone_Else: mplayer probably utilizes yadif at half rate by default?
[23:20:28 CET] <JEEB> unless they switched that to full rate
[23:20:42 CET] <Someone_Else> JEEB: I'm not using mplayer
[23:20:45 CET] <mfwitten> mfolivas: If you know exactly who is going to be playing your video, then you don't have to worry about contraining the features you want to use.
[23:20:56 CET] <JEEB> Someone_Else: argh, sorry. misread :P
[23:21:19 CET] <Someone_Else> JEEB: but the question remains, what is it doing to get this result?
[23:21:26 CET] <JEEB> eff if I know
[23:21:52 CET] <mfolivas> yeah, the use case for this is the following: we have our own cameras (proprietary), we film short videos (zipline and skydiving), and then we create the videos using some ML language
[23:21:59 CET] <mfolivas> but ultimately we leverage ffmpeg
[23:22:07 CET] <mfolivas> the problem is that the render is taking too long
[23:22:25 CET] <JEEB> then you instead of making the preset even faster just disabled all the features in another way?
[23:22:27 CET] <mfolivas> "the players" in this case are mobile phones and my linux app
[23:22:58 CET] <mfolivas> we're actually using preset
[23:23:22 CET] <JEEB> yes, but I mean - you end up with baseline if you keep moving preset towards the most fast presets in libx264 :P
[23:23:23 CET] <mfolivas> the only thing that we disable is the -bf 0 since our cameras doesn't support that
[23:23:26 CET] <utack> thanks mfwitten
[23:23:40 CET] <JEEB> no, you've effectively disabled b-frames with the profile :P
[23:23:48 CET] <JEEB> since constrained baseline disables a lot of stuff
[23:23:56 CET] <mfwitten> mfolivas: https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ
[23:24:00 CET] <mfolivas> no way!
[23:24:02 CET] <mfwitten> mfolivas: See encoding times
[23:24:10 CET] <mfolivas> looking into it!
[23:24:23 CET] <JEEB> anyways, for any encoding speed I'd recommend actually benchmarking which part of your chain is the bottleneck :P
[23:24:25 CET] <mfolivas> i see it now, brb
[23:24:30 CET] <JEEB> since you have decoding, filtering, encoding
[23:24:44 CET] <JEEB> decoding you can benchmark with just `ffmpeg -i INPUT -f null -`
[23:24:59 CET] <JEEB> with filtering you add your vf/af/filter_complex to that
[23:25:11 CET] <JEEB> that should give you a hunch on  how much each step takes
[23:25:29 CET] <JEEB> also your camera is not decoding, right? so it not supporting b-frames shouldn't really matter?
[23:29:35 CET] <mfwitten> mfolivas: Perhaps also look into whether you're using hardware acceleration: https://trac.ffmpeg.org/wiki/HWAccelIntro
[23:29:57 CET] <mfwitten> mfolivas: If you don't care too much about make a very small file, then you can probably make the the encoding process fairly quick.
[23:30:47 CET] <mfolivas> JEEB: our camera is NOT decoding
[23:31:13 CET] <mfolivas> so, yeah, I guess it really doesn't matter
[23:32:09 CET] <mfolivas> JEEB: that's what I've been trying to figure out - what's our bottleneck
[23:32:16 CET] <mfolivas> this is what we're using at the moment
[23:32:17 CET] <mfolivas> ffmpeg -i two-minute-video.mp4 -vf scale=1920:1080 -profile:v baseline -level 4.1 -crf 17 -preset fast -bf 0 scaled-some-random-video.mp4
[23:32:30 CET] <mfolivas> although, we're using a C++ lib, this is similar of what we're doing
[23:32:54 CET] <mfwitten> mfolivas: What is the input dimensions? Why are you scaling?
[23:33:27 CET] <mfolivas> the input dimensions depends on the client: 4K, 1080p, and 720p
[23:33:41 CET] <mfolivas> however, the output will differ
[23:34:36 CET] <mfolivas> as I mentioned before, our customers are getting rendered videos but they don't have to match the input.  In other words, we're getting a 4K file, but we CAN make it 1080p or 720p
[23:35:08 CET] <mfolivas> specially because now, we're having a performance issue: rendering the movies is taking too long based on the amount of users that we have
[23:36:48 CET] <mfwitten> mfolivas: Why not just provide the 4K ready to go, and charge for transcoding?
[23:37:13 CET] <mfwitten> mfolivas: Then clients get better material for their records, and you get paid for scaling down
[23:38:16 CET] <mfwitten> mfolivas: In any case, 17 is getting pretty low for crf, if time is an issue
[23:38:25 CET] <mfolivas> mfwitten: we need to upload the file to the cloud and these sites are in a VERY remote area with low internet bandwidth (10mb upload)
[23:38:49 CET] <mfwitten> mfolivas: I see
[23:44:20 CET] <mfwitten> mfolivas: Is it a time issue for your business or for your clients? Maybe you could do a much smaller, lower-quality video to upload more quickly for the impatient, and then provide the higher-quality file when it finishes later? 640x480 would probably encode a lot faster than 1080p or even 720p
[23:44:29 CET] <mfwitten> mfolivas: I don't know. I'm just thinking out loud
[23:45:06 CET] <mfwitten> 480p, I mean
[23:45:07 CET] <mfolivas> mfwitten: yes, I just don't want to play the guessing game (I've done that before)
[23:45:44 CET] <mfolivas> I rather just do an analysis and see what features to tune based on the output (file size, quality, and time)
[23:46:15 CET] <mfwitten> mfolivas: Yeah. Well, good luck. I wish I could help you more.
[23:46:29 CET] <mfwitten> mfolivas: (not that I've helped :-))
[23:49:26 CET] <mfolivas> mfwitten: you're helping a lot
[23:52:51 CET] <mfolivas> JEEB: seems that it's because of Android that we're using the Baseline profile
[23:52:53 CET] <mfolivas> >Android 9 states that all devices must be able to decode Baseline/Main Profile Level 3.1.
[23:53:38 CET] <JEEB> yea, that's the bare bare minimum
[23:54:09 CET] <JEEB> I bet there are some very cheap devices that go at the very minimum of that, but the last time I was able to actually buy one that only did *baseline* was in 2009, a samsung device
[23:54:28 CET] <JEEB> google just doesn't *require* more for device certification
[23:54:41 CET] <JEEB> or whatever that specifically means :P
[23:55:15 CET] <JEEB> I mean, I'm not saying there aren't baseline-only devices
[23:55:26 CET] <mfolivas> The fact that I'm restricted by using the profile makes me wonder what limitations/constraints I can/cannot use
[23:55:45 CET] <JEEB> I'm just noting that it might not be the device base you are aiming for
[23:56:01 CET] <mfolivas> understood
[23:56:06 CET] <JEEB> also you were IIRC encoding 1080p
[23:56:22 CET] <JEEB> pretty sure those devices that limit themselves to baseline, level 3.1 can't do that
[23:56:29 CET] <JEEB> just sayin'
[23:56:47 CET] <mfolivas> in some sites we're getting 4K and 1080p and then we can provide our clients 4K, 1080p, or 720p
[23:56:53 CET] <mfolivas> my research will define this better
[23:57:09 CET] <mfolivas> again, we're trying to figure out what's the most optimal settings
[23:57:24 CET] <mfwitten> mfolivas: I recall iPhones being a pain in the ass.
[23:57:41 CET] <JEEB> I think 3GS or so onwards the hwdec in iPhones got better?
[23:57:48 CET] <JEEB> can't remember, was so long ago
[23:57:54 CET] <JEEB> (Seriously, not facetiously)
[23:58:00 CET] <mfolivas> say for a client that needs to generate 15 minute and there are 200 videos
[23:58:37 CET] <mfwitten> mfolivas: I would never upscale (1080p to 4k); it's a total waste of your time
[00:00:00 CET] --- Thu Jan 31 2019