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

[burek]

[00:03:35 CET] <cehoyos> Your mfx may be old
[00:03:54 CET] <shibboleth> yes, i'm using 2015r6 since it is the last to support ivy bridge
[00:04:07 CET] <shibboleth> current doesn't even support haswell
[00:06:49 CET] <shibboleth> is there anything in ffmpeg commit/notes that makes 2015r6 incompatible?
[00:19:03 CET] <fling> cehoyos: is libaom still slow?
[00:48:45 CET] <Arnob> @durandal11707: "it means your ffmpeg version is too old" :-) ok, thank you. I am using Linux Mint 18.3, it's time for an upgrade...
[00:49:33 CET] <shibboleth> cehoyos, ?
[01:00:07 CET] <cehoyos> shibboleth: You just found out that newer FFmpeg is incompatible with old libmfx, this is generally not surprising but not something I knew
[01:00:37 CET] <shibboleth> yeah, i asked if this is "likely" or simply "possible"
[01:05:50 CET] <nicolas17> fling: "-threads 1" means *don't* use multiple threads
[01:12:02 CET] <shibboleth> is there anything in changelogs that points this out?
[01:15:29 CET] <fling> looks like libaom still slow
[01:15:32 CET] <fling> nicolas17: ok
[01:15:44 CET] <nicolas17> do you have libaom from git?
[01:15:48 CET] <BtbN> It's libaom. It's never going to be fast.
[01:15:52 CET] <nicolas17> latest git master is faster than 1.0
[01:15:55 CET] <nicolas17> but it's still slow
[01:16:01 CET] <fling> no, 1.0.0, can go latest
[01:16:08 CET] <fling> how much faster? :D
[01:16:24 CET] <nicolas17> hmm I don't remember numbers, someone here might know
[01:16:35 CET] <fling> I will just rebuild
[01:16:48 CET] <fling> speed=0.00229x
[01:29:52 CET] <fling> latest is faster 0.0113x
[02:46:55 CET] <K1rk> Hello, I am trying to help someone get a rather advanced ffmpeg setup working how they need it to.
[02:47:13 CET] <K1rk> We compiled an ffmpeg.exe (they're using Windows) using RDP's ffmpeg build helper: https://github.com/rdp/ffmpeg-windows-build-helpers
[02:47:38 CET] <K1rk> This build and several other builds we have seem to set a vbv_delay of "n/a".
[02:47:48 CET] <K1rk> We have another build where the vbv_delay gets set to -1 with the same input params
[02:47:58 CET] <K1rk> Is this something that is changed during compiling or is there a flag I am missing somewhere?
[02:51:45 CET] <K1rk> It's possible that we could be reading too much into this particular difference, but when we see this difference in the output we seem to experience some kind of memory leak that results in an eventual crash.
[02:52:01 CET] <K1rk> So I was looking to see if we could manually set vbv_delay=-1 somehow on my build of ffmpeg.exe
[02:55:55 CET] <Soni> how do I make a 100MHz pcm_u8 mono from my 48kHz 16-bit stereo audio?
[06:52:29 CET] <qmr> how can I stream device w mplayer or ffmpeg on macos?  it's FPV doodad, it presents as a USB webcam
[06:52:45 CET] <qmr> [AVFoundation input device @ 0x7fc28bc3a3c0] [0] USB2.0 PC CAMERA  in ffmpeg
[11:39:33 CET] <jokoon> generally speaking, when I re-encode a video, when I downsize, is it faster the lower the new resolution?
[11:39:50 CET] <furq> yes
[11:44:39 CET] <jokoon> I want to resize several videos which have various size, I want them to have the same width, if I set -vf scale=360:-1 does it mean ffmpeg will choose a multiple of 4 size for h264?
[11:45:35 CET] <jokoon> or will it slightly stretch the video or add pixels?
[11:46:06 CET] <jokoon> are there other ways to make sure things are multiple of 4 ?
[11:54:32 CET] <furq> jokoon: 320:-4
[11:54:53 CET] <jokoon> you mean 360:-4?
[11:54:55 CET] <furq> yeah
[11:54:58 CET] <jokoon> ok thanks!
[11:55:35 CET] <furq> -2 should be fine unless you need mod4 for some other reason
[11:59:24 CET] <jokoon> well Im encoding in 264 so I need mod4
[11:59:40 CET] <jokoon> Don't I ?
[11:59:54 CET] <furq> no
[12:00:55 CET] <jokoon> only mod2?
[12:01:03 CET] <furq> it depends on the pixel format
[12:01:10 CET] <furq> which is almost always yuv420p, so mod2 is fine
[12:01:22 CET] <jokoon> ok
[12:27:49 CET] <jokoon> How is it possible to change the framerate without re-encoding the video?
[12:29:29 CET] <jokoon> Yesterday I asked about making several video the same framerate so I can make a proper xstack. I heard there are several option, it seems framerate is slightly better than fps
[12:30:15 CET] <jokoon> Also I want 30 to be the framerate
[12:30:29 CET] <jokoon> meaning several videos will have their framerate increased
[12:32:31 CET] <durandal_1707> not possible without reencoding
[12:34:21 CET] <jokoon> https://stackoverflow.com/questions/45462731/using-ffmpeg-to-change-framerate/45465730
[12:34:45 CET] <jokoon> the answer says "Remux with new framerate"
[12:35:14 CET] <BtbN> If you don't have audio, sure, that works.
[12:36:36 CET] <cehoyos> You can use the input option "-r", but the option is a hack and will not work in all cases
[12:36:49 CET] <jokoon> ok
[12:36:59 CET] <jokoon> so -framerate is better
[12:37:08 CET] <cehoyos> No, framerate is another option
[12:37:15 CET] <cehoyos> You must use the input option "-r", but the option is a hack and will not work in all cases
[12:37:47 CET] <BtbN> There simply is no way to change the framerate without re-encoding, if you don't want the video to run faster/slower afterwards and be entirely off-sync with its audio.
[12:38:02 CET] <cehoyos> You can change the framerate without re-encoding with ffmpeg
[12:38:28 CET] <jokoon> cehoyos, but it will speedup/slowdown the video
[12:38:29 CET] <BtbN> Which will effectively just speed up/slow down the video.
[12:38:40 CET] <jokoon> yes that's not what I want
[12:38:51 CET] <cehoyos> of course, that is what you want to achieve with a change of framerate
[12:39:02 CET] <BtbN> Not really, no
[12:39:04 CET] <jokoon> not really
[12:39:12 CET] <BtbN> you usually want to drop/duplicate frames. Which requires a re-encode.
[12:39:12 CET] <jokoon> I mean not necessarily
[12:39:44 CET] <cehoyos> If you have 100 input frames with a framerate of 25fps and you want to change the framerate (as you wrote above), the duration of the video will change
[12:39:48 CET] <cehoyos> This is unavoidable
[12:40:07 CET] <BtbN> Not if you duplicate every frame and show each only half as long.
[12:40:20 CET] <cehoyos> Then you have to re-encode
[12:40:27 CET] <BtbN> ... yes?
[12:40:38 CET] <jokoon> I was just curious about the SO answer
[12:40:59 CET] <jokoon> not sure if that SO answer talked about that solution speeding up/ slowing down the vid
[12:41:24 CET] <BtbN> It discards the entire container and metadata involved, and treats the video as a stream of raw frames. And puts new timestamps on it.
[12:41:35 CET] <cehoyos> The SO question clearly states that the goal was to change the duration of the stream
[12:41:36 CET] <BtbN> So, effectively it just speeds up/slown down the video, while discarding any audio.
[12:41:52 CET] <jokoon> oh then sorry I did not read it properly
[12:42:42 CET] <cehoyos> Second line
[12:47:05 CET] <jokoon> so I can use -framerate to turn a 24fps video into a 30fps video
[12:47:34 CET] <jokoon> I know it won't increase quality
[12:47:41 CET] <jokoon> I just need the video to be 30fps
[12:47:46 CET] <BtbN> It will make it worse, cause re-encode.
[12:47:57 CET] <jokoon> I know
[12:48:12 CET] <jokoon> As I said, I need this because Im using xstack after this
[12:48:24 CET] <cehoyos> What do you mean with "-framerate"?
[12:48:48 CET] <jokoon> as an alternative to -r? Ive read -r is hacky
[12:48:55 CET] <cehoyos> (Command line and complete, uncut console output missing.)
[12:49:05 CET] <cehoyos> "-r" is a hack that can be useful, yes
[12:49:15 CET] <cehoyos> The input option "-r" is a hack that can be useful, yes
[12:49:24 CET] <cehoyos> The output option -r is not a hack
[12:50:17 CET] <cehoyos> The input option "-r" changes video speed, you wrote that you don't want to change video speed, so you don't need an alternative for "-r", you need something else
[12:50:25 CET] <cehoyos> not entirely sure what you need / wnat
[12:50:31 CET] <furq> if this is just for xstack then don't do anything
[12:50:42 CET] <furq> just use the fps filter on that input before xstack
[12:51:06 CET] <cehoyos> There is a framerate filter (that does not have a "-"), it is what you need but I suspect it is cpu-expensive
[12:51:27 CET] <cehoyos> Using the fps filter is much cheaper (nearly free)
[12:51:50 CET] <jokoon> and it doesn't change the video length?
[12:52:02 CET] <cehoyos> It changes the framerate, not the duration
[12:52:06 CET] <jokoon> ok
[12:52:13 CET] <cehoyos> To change the duration, you can use the input option "-r"
[12:52:27 CET] <furq> jokoon: -i 24fps.mkv -i 30fps.mkv -lavfi "[0:v]fps=30[tmp0];[tmp0][1:v]hstack"
[12:52:55 CET] <cehoyos> Is tmp0 needed?
[12:53:21 CET] <furq> not if you tell me it isn't
[12:54:22 CET] <jokoon> Im going to do the xstack separately because I need to attach videos together
[12:54:54 CET] <jokoon> I have about 30, that I need to play in a 2x2 xstack
[12:54:54 CET] <BtbN> That's a full pointless intermediate re-encode
[12:55:07 CET] <furq> yeah that just loses more quality
[12:55:15 CET] <jokoon> not a problem
[12:55:20 CET] <cehoyos> This works here with two input files: -lavfi fps=25,hstack
[12:55:50 CET] <furq> yeah i was about to say you should just unconditionally make every video 30fps
[12:56:04 CET] <furq> but i'm not entirely sure that's a noop if the input video is already 30fps
[12:56:04 CET] <jokoon> that's what Im doing
[12:56:15 CET] <furq> i mean in the same command as xstack
[12:56:18 CET] <furq> there's no point doing it ahead of time
[12:56:25 CET] <cehoyos> No, the fps filter can only work on one input
[12:56:39 CET] <jokoon> because I will merge several videos
[12:57:05 CET] <cehoyos> If you care about quality or speed or harddrive space, you should do it in one command
[12:57:11 CET] <jokoon> I have about 30, and I want to make a single one, in a 2x2, that plays them all
[12:57:14 CET] <furq> well you wouldn't be using xstack if you weren't merging several videos
[12:57:32 CET] <BtbN> you apply the fps filter to the input _before_ giving it to xstack
[12:57:37 CET] <furq> ^
[12:57:54 CET] <BtbN> And I'm pretty sure the fps filter is a no-op if the input fps already matches
[12:58:10 CET] <cehoyos> of course
[12:58:14 CET] <jokoon> Im merging them in xstack but I also need to merge them in time, the durations are different for all of those videos
[12:58:38 CET] <jokoon> of course Im not changing the fps if it's already 30
[12:58:46 CET] <furq> also videos don't need to be the same framerate for xstack anyway
[12:58:54 CET] <cehoyos> If quality or encoding time and harddrive space don't matter, there is nothing wrong with not doing it in one command
[12:58:57 CET] <jokoon> only doing it on those who are not 30fps, it's maybe 80% of those vids
[12:59:44 CET] <jokoon> you can have several framerate with xstack?
[12:59:48 CET] <jokoon> really?
[12:59:54 CET] <furq> you can with hstack so i assume xstack is the same
[13:00:01 CET] <cehoyos> Yes, but there is a master and a slave and it may not be documented which is which
[13:00:11 CET] <cehoyos> therefore you should choose it yourself
[13:00:12 CET] <furq> i'm pretty sure it rebases them all to match the first input
[13:00:17 CET] <furq> which may not be ideal
[13:00:19 CET] <cehoyos> yes
[13:00:30 CET] <jokoon> so... the video will decode several videos in a video that is a xstack?
[13:00:44 CET] <furq> no it just automatically changes the fps of every video to match the first input
[13:00:58 CET] <cehoyos> xstack is not a video, it is a filter like crop or pad
[13:01:04 CET] <jokoon> hum
[13:01:11 CET] <cehoyos> Having more than one input
[13:01:32 CET] <furq> but like we've been saying, you can do that manually with -lavfi fps=30,xstack
[13:01:37 CET] <jokoon> oh it does it automatically
[13:01:53 CET] <cehoyos> Which means not relying on something that may not be documented (I didn't check) and is free anyway
[13:02:01 CET] <cehoyos> (mostly)
[13:02:09 CET] <furq> yeah my basis for saying it's the first video is i just tried it with two inputs to hstack
[13:02:21 CET] <furq> so that might not be accurate for other situations
[13:03:08 CET] <cehoyos> https://ffmpeg.org/ffmpeg-filters.html#xstack doesn't say that the framerate of the first video is used
[13:03:19 CET] <jokoon> yes I checked too
[13:03:31 CET] <jokoon> I assumed it was required because it made sense
[13:03:37 CET] <cehoyos> But this shouldn't affect you in any way since you are using the fps filter anyway
[13:04:04 CET] <jokoon> well Im not using the FPS filter if I can do without
[13:04:10 CET] <cehoyos> You should
[13:04:14 CET] <jokoon> oh ok
[13:04:32 CET] <cehoyos> Relying on undocumented behaviour makes very little sense
[13:04:34 CET] <jokoon> because, hardware might have trouble playing a xstack?
[13:04:43 CET] <cehoyos> no
[13:04:52 CET] <jokoon> ok
[13:04:55 CET] <furq> well say one of your input videos is 5fps and ffmpeg decides to rebase all the other videos to match that
[13:04:58 CET] <furq> that's not going to be great
[13:05:22 CET] <furq> plus the automatic behaviour is almost certainly doing the same thing the fps filter would
[13:05:38 CET] <jokoon> no, the worst fps is 24
[13:05:42 CET] <cehoyos> I suspect there is an additional memcpy
[13:05:48 CET] <jokoon> the best being around 60
[13:06:12 CET] <furq> well it's presumably good to actually know for sure what the output framerate is going to be
[13:06:22 CET] <jokoon> ALTHOUGH, I heard that if the framerate don't match, it might induce several more reencode
[13:06:28 CET] <furq> uh
[13:06:29 CET] <jokoon> was told this yesterday
[13:06:35 CET] <furq> whatever that was doesn't apply to this
[13:07:20 CET] <cehoyos> jokoon: I believe you so far have no idea what xstack (and fps) do, please run a few tests on your local system, then come back if you have more question (and more knowledge)
[13:07:27 CET] <jokoon> copypasting: <kepstin> jokoon: basically every time there's a new frame on any input, xstack will make an output frame
[13:07:54 CET] <furq> that has nothing to do with reencoding
[13:08:09 CET] <jokoon> that has to do with different framerates
[13:08:27 CET] <durandal_1707> yes, it will pick highest fps
[13:08:34 CET] <furq> it doesn't
[13:08:42 CET] <furq> at least hstack doesn't
[13:08:42 CET] <durandal_1707> timebase to be more exact
[13:08:45 CET] <cehoyos> It's not documented
[13:09:16 CET] <kepstin> that was my understanding based on looking at how the framesync code works with videos with non-matching timebases.
[13:09:25 CET] <furq> hstack is picking the lcm timebase of both inputs
[13:10:00 CET] <durandal_1707> it pickes first timebase returnted by framesync
[13:10:13 CET] <durandal_1707> so one that can hold all timestamps
[13:10:32 CET] <furq> yeah that makes sense
[13:10:42 CET] <furq> [Parsed_xstack_0 @ 000001cd0d764840] [framesync @ 000001cd0dc19a40] Selected 1/150 time base
[13:10:46 CET] <furq> i get that with 25 and 30fps inputs
[13:10:56 CET] <furq> but the actual reported output fps always matches the first input
[13:11:01 CET] <furq> "always"
[13:11:26 CET] <cehoyos> Does it report drops?
[13:11:39 CET] <furq> it does
[13:11:46 CET] <furq> at least if the first input is lower framerate
[13:11:54 CET] <cehoyos> That's what I meant
[13:13:44 CET] <kepstin> huh, that doesn't do what I thought, if it's using a timebase that's lcm of all inputs, there's no reason it would drop frames.
[13:14:06 CET] <cehoyos> ffmpeg (the application) does
[13:14:11 CET] <kepstin> is the filter not setting the framerate to vfr?
[13:14:18 CET] <kepstin> that's a bug the concat filter used to have
[13:15:18 CET] <kepstin> concat used to set the output framerate to the framerate of the first input, then ffmpeg (or the ffmpeg filter code, not sure) would drop the extra frames if the second input had higher framerate.
[13:15:34 CET] <furq> https://clbin.com/gIeOe
[13:15:41 CET] <furq> for some reason it's not dropping frames with -f null
[13:15:46 CET] <furq> it was when i was piping to mpv
[13:16:49 CET] <kepstin> what format were you piping?
[13:16:55 CET] <furq> rawvideo in nut
[13:18:20 CET] <kepstin> i notice that ffmpeg output has the output stream saying 25fps, which does indicate that the stack filter might be incorrectly setting the output fps to the fps of the first input.
[13:18:42 CET] Action: kepstin should look at the code to verify
[13:19:03 CET] <furq> yeah mpv reports it as 25fps
[13:19:16 CET] <furq> not sure why ffmpeg says it encoded 50 frames
[13:20:12 CET] <cehoyos> furq: -f null defaults to vfr, -f mov (and friends) to cfr
[13:20:53 CET] <kepstin> confirmed, the stack filter does set the outlink frame_rate to the frame rate of the first input, it should set it to 1/0 if the frame rates of all inputs don't match :/
[13:20:54 CET] <furq> oh right
[13:20:56 CET] <furq> https://clbin.com/CxXsk
[13:20:59 CET] <furq> yeah there you go then
[13:22:04 CET] <furq> that actually makes a lot more sense now
[13:23:17 CET] <furq> mpv still reports 25fps with -vsync vfr but i guess that matches what kepstin just said
[13:25:27 CET] <durandal_1707> ah i need to fix this vfr
[13:26:53 CET] <kepstin> interesting that the stack filter is explicitly setting outlink frame_rate to the framerate of the first input. The bug in concat was that it didn't set the outlink frame_rate at all, so the filter framework was implicitly setting it to the framerate of the first input.
[13:30:31 CET] <jokoon> so... should I still convert all those videos into 30fps?
[13:30:44 CET] <jokoon> I have time following up
[13:30:51 CET] <jokoon> a hard time*
[13:31:02 CET] <cehoyos> No, you should use the fps filter to make sure the xstack filter gets identical output
[13:31:04 CET] <cehoyos> Yes, I know
[13:31:10 CET] <jokoon> Should I ask on the forums?
[13:31:12 CET] <kepstin> my advice still stands, convert all inputs to matching fps before sending to stack filter
[13:31:13 CET] <cehoyos> [13:07] <cehoyos> jokoon: I believe you so far have no idea what xstack (and fps) do, please run a few tests on your local system, then come back if you have more question (and more knowledge)
[13:31:45 CET] <jokoon> ok
[13:37:13 CET] <kepstin> hmm, it would probably make sense for the framesync code to provide a suitable output frame_rate to use. There's probably a lot of filters that generate one output frame each time framesync provides a set of frames, so it would be nice to not have to duplicate the logic to find a suitable output frame_rate
[13:39:09 CET] <kepstin> add a frame_rate field to FFFrameSync, have ff_framesync_configure put something reasonable in there.
[13:52:20 CET] <kibibyte> hi
[14:35:54 CET] <bencc1> I'm capturing the screen to a nut file with:
[14:35:56 CET] <bencc1> ffmpeg -f pulse -ac 2 -ar 48000 -i default -f x11grab -framerate 30 -i :0.0 -acodec aac -b:a 96k -vcodec libx264 -pix_fmt yuv420p -preset:v veryfast -crf 23 -vf fps=30 cap.nut
[14:36:40 CET] <bencc1> when I play the video it freezes for few seconds while the audio continues
[14:36:59 CET] <bencc1> am I doing something wrong with the -framerate and fps params?
[14:37:18 CET] <cehoyos> Do you mean the audio start early?
[14:37:33 CET] <bencc1> the audio plays ok all the time
[14:37:49 CET] <cehoyos> And A/V sync is always correct except for the first second?
[14:38:08 CET] <bencc1> A/V sync is ok
[14:38:26 CET] <cehoyos> But please provide the command line including complete, uncut console output.
[14:38:27 CET] <bencc1> the picture freeze while the audio continue and after few seconds the picture continue moving
[14:38:35 CET] <cehoyos> Audio starts early
[14:38:51 CET] <bencc1> the picture freeze every few seconds again
[14:38:56 CET] <bencc1> not just at the start
[14:39:02 CET] <bencc1> I'll paste the command
[14:39:08 CET] <cehoyos> Then please provide the command line you tested together with the complete, uncut console output
[14:39:14 CET] <bencc1> ok
[14:58:08 CET] <jokoon> here are some funny framerate of the videos I have: 35300000/1176673 3654750/121951 40910415/1365044 47234296/1576051 49955000/1666871 517950181/8641135 60000/1001 842490000/35139083
[14:58:28 CET] <jokoon> although the 60k/1001 is pretty bormal
[14:58:31 CET] <jokoon> normal
[14:59:30 CET] <jokoon> Might have to do with the video sensors
[15:09:30 CET] <bencc1> cehoyos: https://pastebin.com/BFPPwh3p
[15:11:23 CET] <bencc1> cehoyos: this time it the picture doesn't freeze in the result so I'm trying again
[15:11:29 CET] <bencc1> but the command and console are correct
[15:23:08 CET] <cehoyos> Does ultrafast improve the situation?
[15:24:28 CET] <bencc1> cehoyos: I'll try
[15:24:58 CET] <bencc1> in the paste I see several warnings that might be relevant:
[15:24:58 CET] <bencc1> Stream #0: not enough frames to estimate rate; consider increasing probesize
[15:25:05 CET] <bencc1> Thread message queue blocking; consider raising the thread_queue_size option (current value: 512)
[15:25:11 CET] <bencc1> Queue input is backward in time02.29 bitrate=   1.4kbits/s speed=0.541x
[15:25:17 CET] <bencc1> Non-monotonous DTS in output stream 0:1; previous: 112378, current: 109448; changing to 112379. This may result in incorrect timestamps in the output file.
[15:25:25 CET] <bencc1> is this indication of a problem?
[15:26:07 CET] <cehoyos> jokoon: Old software produced such framerates, this is all supposed to be 30000/1001 or 60000/1001
[15:26:24 CET] <cehoyos> No, but speed=0.541x is (imo)
[15:27:08 CET] <bencc1> cehoyos: speed should be 1x?
[15:27:14 CET] <cehoyos> Please do not post excerpts of the console output, always paste the command line together with the complete, uncut console output
[15:28:21 CET] <bencc1> cehoyos: ok. just highlighted lines from the complete paste I sent before which might be relevant
[15:29:55 CET] <cehoyos> I would hopefully find the relevant lines but gtg now, sorry
[15:30:36 CET] <bencc1> thank you for the help
[16:19:13 CET] <jokoon> launched the xstack, speed is at 1.5
[16:19:21 CET] <jokoon> old cpu
[16:22:22 CET] <jokoon> so the output is 30fps, the input are 30/1 30/1 25/1 24000/1001
[16:23:56 CET] <jokoon> except it seems one video was trimmed when using scaling=360:-2
[16:25:10 CET] <kepstin> do you mean scale=360:-2?
[16:25:25 CET] <jokoon> yes
[16:25:43 CET] <kepstin> those scale options don't compensate for sar, so if one of the video has a different sar than the others you might have issues.
[16:25:58 CET] <jokoon> SAR?
[16:26:16 CET] <kepstin> other than that, it's the good old "please paste the ffmpeg command line as you ran it, and the complete console output"
[16:30:55 CET] <jokoon> https://bpaste.net/show/64LXU
[16:32:09 CET] <jokoon> oh sorry the output
[16:35:46 CET] <jokoon> output https://bpaste.net/show/WB4GS
[16:37:25 CET] <kepstin> your second input file isn't the same aspect ratio as the others, it's something weird between 4:3 and 16:9
[16:37:32 CET] <kepstin> what do you want to do with it?
[16:37:47 CET] <kepstin> either has to be letterboxed or cropped.
[16:38:01 CET] <jokoon> letterboxed
[16:40:19 CET] <jokoon> mmmh Im reading questions on SO
[16:40:32 CET] <jokoon> something with pad=
[16:41:26 CET] <kepstin> yeah, you have to scale based on height to match the other videos, then use the pad filter to add bars
[16:42:05 CET] <kepstin> "scale=-2:202,pad=360:202:-1:-1" is probably close
[16:42:35 CET] <kepstin> (360 width doesn't have a nice even integer height for 16:9 video, which is annoying)
[16:43:24 CET] <jokoon> what's the next best width for that?
[16:46:58 CET] <pink_mist> 480 probably? at least 480 is common
[16:47:17 CET] <jokoon> ok
[16:47:35 CET] <jokoon> I will have to work on concatenating videos next
[16:47:43 CET] <jokoon> thanks for the great help!
[16:48:14 CET] <kepstin> I'd probably go with 640x360 per tile, then the final video will be 1280x720 (720p) normal size
[16:49:43 CET] <jokoon> I would have to use on a generic 'pad=' argument first
[16:54:31 CET] <ntrrgc> Is there a way to perform a synchronous wait for decoded frames in avcodec? It seems to be assumed you will poll with avcodec_receive_frame(), but that's not ideal.
[16:56:45 CET] <BtbN> the ffmpeg APIs are blocking.
[16:57:27 CET] <ntrrgc> will therefore avcodec_receive_frame() block until at least one decoded frame becomes available?
[16:57:33 CET] <BtbN> if recv_frame comes back with EAGAIN, calling it again won't change that result usually. It wants more input.
[16:58:28 CET] <BtbN> Generally, you decode by feeding the decoder packets until it bails out, then get frames, and then repeat
[16:59:00 CET] <BtbN> Or just a loop of "feed packet, try recv frame(s)".
[17:01:17 CET] <ntrrgc> what I've found is that until a new packet is fed, you can't receive all the previously decoded frames
[17:02:21 CET] <ntrrgc> this is gstreamer avdec element, so there is quite a bit more code than just avdec, but the loop is like you describe
[17:03:48 CET] <kepstin> due to frame reordering with bidirectionally predicted frames, it's expected that there are circumstances where you can't get a frame until you send more packets to the decoder.
[17:04:15 CET] <ntrrgc> and the situation is, if I feed quickly packets for time [0, 3) and then stop because of an unbuffered condition, how many decoded frames are obtained depends on thread luck, but it's often noticeably lower than the number of fed packets
[17:05:06 CET] <ntrrgc> this can't be due to frame reordering (alone) since changes to the CPU scheduler affect the outcome
[17:05:12 CET] <kepstin> thread luck shouldn't matter, this is generally deterministic based on characteristics of the input stream.
[17:06:10 CET] <ntrrgc> if I set aside a few packets, e.g. [2, 3) and send them 5 seconds later, then I actually get [0, 2) decoded every time.
[17:06:29 CET] <kepstin> which codec and decoder is being used?
[17:07:30 CET] <ntrrgc> h264, decoder only
[17:08:07 CET] <kepstin> which decoder? ffmpeg's builtin software decoder?
[17:10:48 CET] <ntrrgc> I think so. The default one.
[17:13:33 CET] <kepstin> hmm. i'd have to check the code to confirm, but calling receive_frame on that should block to wait for decoding, and return the next reordered frame.
[17:14:36 CET] <kepstin> if the next reordered frame isn't available because you haven't fed enough input, it will of course return EAGAIN.
[17:18:57 CET] <kepstin> you'd be able to understand what's going on better if you log the dts vs. pts of each packet.
[17:20:37 CET] <ntrrgc> there is quite a lot of stuff going on in my bug report, so I'll try to make a reduced test case.
[19:54:37 CET] <form> hi, when using -ss to cut a mkv file (ffmpeg -ss 10 -i in.mkv -c copy out.mkv) the "Encoding settings" in the header generated by x264 will be discarded and dont get into the output file. with -ss 0 they do. is this a bug?
[19:55:34 CET] <form> with "Encoding settings" i mean the encoding-parameters of x264 which you can verify with mediainfo
[19:57:13 CET] <JEEB> if those SEI messages are in the stream itself, that's not really a bug
[19:57:27 CET] <JEEB> as opposed to the part of matroska where you have the decoder initialization data :)
[20:06:57 CET] <form> hm, i dont know what you mean. the input file was encoded using ffmpeg, too. how can i ensure that the parameters are visible in the trimmed file, too?
[20:08:27 CET] <JEEB> when you are cutting, you are skipping packets. the SEI message (think of a packet which says "I have some random data inside" and which is text)
[20:08:35 CET] <JEEB> is a packet on the time line
[20:08:39 CET] <JEEB> probably in the very beginning
[20:08:52 CET] <JEEB> thus, when you seek, you move further into the stream
[20:10:13 CET] <form> yes its in the beginning. but ffmpeg could look there, as is does for other parameters like "fps" etc., too :-)
[20:10:40 CET] <kepstin> those other parameters are in an actual header, they aren't part of the main data stream
[20:10:59 CET] <kepstin> the x264 encoding options are just a "junk" bit of data stuck in with the encoded video frames.
[20:11:17 CET] <form> ah, understoof
[20:11:19 CET] <form> -f+d
[20:11:19 CET] <JEEB> form: if you mean the parameter sets ("decoder initialization data"), that's in a separate thing
[20:11:36 CET] <JEEB> separate from the actual A->B video stream packets
[20:11:54 CET] <form> i mean the encoder settings like " cabac=1 / ref=5 / deblock=1:0:0 ... "
[20:11:58 CET] <JEEB> kepstin: not really junk. it's a proper NAL unit :D but yes, it's "just a packet"
[20:12:04 CET] <JEEB> yes, I know. that's in a SEI packet :P
[20:12:24 CET] <bencc1> I have a server with 8 hyperthreads. how can I limit ffmpeg to 1 core when transcoding?
[20:12:32 CET] <bencc1> using "-threads 1"?
[20:12:49 CET] <kepstin> bencc1: 1 core or 1 hyperthread?
[20:12:54 CET] <JEEB> yes, although ffmpeg.c probably will spawn multiple threads overall :P
[20:13:09 CET] <JEEB> your OS might also be able to set the process to a specific set of processor(s)
[20:14:41 CET] <bencc1> kepstin: limit to 1 hyperthread
[20:36:49 CET] <bencc1> if I want to reduce CPU load when capturing should I remove "-vf fps=30" re-encode in a post-processing to set constant frame rate??
[20:37:27 CET] <bencc1> this is what I currently do: https://pastebin.com/BFPPwh3p
[20:38:00 CET] <kepstin> bencc1: should be negligible (probably not even a detectable difference)
[20:38:10 CET] <bencc1> ok
[20:38:22 CET] <bencc1> should I change "-preset:v veryfast -crf 23" to "-preset:v ultrafast -crf 0" ?
[20:38:42 CET] <kepstin> depends on what your goal is and how your system performs
[20:39:12 CET] <kepstin> note that -crf 0 is lossless (with 8-bit video) which means the resulting file is a lot bigger, might have to worry about io speed limitations
[20:39:45 CET] <bencc1> I capture to .nut and later convert to mp4. the image in the output freeze for a few seconds each time during the video while the audio keep playing
[20:39:55 CET] <bencc1> there is no A/V sync issue
[20:40:21 CET] <kepstin> could be any number of things causing that, would have to analyze system load as a whole to figure out where the bottleneck is.
[20:42:38 CET] <kepstin> all that means is that ffmpeg wasn't able to run x11grab to fetch the next frame in time, which could be due to it being busy encoding, being blocked writing to disk, being unable to get cpu because some other task is running, or even something in the x server taking a while.
[20:43:38 CET] <bencc1>  kepstin: my disk throughput is 0.48 MS/s
[20:43:53 CET] <kepstin> what, is this an sd card or something?
[20:44:09 CET] <kepstin> you'd be better off plugging in a spinning hdd over usb 2.0 and using that instead.
[20:44:15 CET] <kepstin> that's probably the main issue.
[20:44:18 CET] <bencc1> google cloud SSD persistent disks
[20:45:15 CET] <bencc1> sorry, that's per GB so it's 30 times that. about 15MB/s
[20:46:13 CET] <kepstin> hmm, 15MB/s is fine if it doesn't have unpredicatable high latencies. but you should still check actual achieved disk speeds using monitoring tools, make sure your system doesn't have high io wait.
[20:46:45 CET] <bencc1> checking in prometheus
[20:48:38 CET] <kepstin> (if your kernel's new enough, the io pressure monitoring in /proc/pressure/io is great for this, typical good case is for the "some" measurement to be in the low single digits)
[20:49:21 CET] <bencc1> I measure node_cpu_seconds_total with prometheus node_expoter
[20:49:30 CET] <bencc1> I'll check if they use /proc/pressure/io
[20:49:46 CET] <bencc1> node_cpu_seconds_total is 0.015%
[21:01:23 CET] <jokoon> kepstin, you told me that 640*360 was a good tile choice, to get 720p, why's that?
[21:02:11 CET] <kepstin> nothing really special, that's just a common 'HD' video resolution that's easily divisible into 4.
[21:02:24 CET] <pink_mist> because those numbers add up to 1280*720 if you stack them in a 2x2 grid
[21:03:49 CET] <jokoon> doesn't that also work for 480*270?
[21:04:35 CET] <pink_mist> no, that doesn't add up to 1280*720 if you stack them 2x2
[21:04:56 CET] <jokoon> I know
[21:05:03 CET] <kepstin> that gives you 960x540, which is an unusual resolution. it would work fine, of course.
[21:05:47 CET] <jokoon> what's wrong with unusual?
[21:14:07 CET] <jokoon> oh ok so when letterboxing, its pad=<wanted width>:<wanted height>:<letterbox width>:<letterbox height>
[21:14:31 CET] <jokoon> iw and ow are input width and output width
[21:15:36 CET] <jokoon> my problem being I want to upscale AND downscale
[21:15:42 CET] <jokoon> AND letterbox
[21:18:25 CET] <kepstin> not sure what you mean by upscale and downscale
[21:18:30 CET] <kepstin> you can only do one or the other?
[21:19:06 CET] <kepstin> well, i suppose you can scale up in one axis and down in the other if you want to stretch your video in strange ways
[22:03:30 CET] <TanaPanda> Hello
[22:03:54 CET] <TanaPanda> I am streaming a video using the command: ffmpeg -loglevel debug -max_interleave_delta 15000000 -rtbufsize 128000k -threads 0 -stream_loop -1 -re -i /home/pi/Desktop/ActiveChannel/Property_LCI.mp4 -codec copy -shortest -f mpegts udp://192.168.6.2:20?pkt_size=1316?buffer_size=65536
[22:04:45 CET] <TanaPanda> but the video took a hot min to get up to 1x speed and the picture was coming in choppy
[22:04:47 CET] <TanaPanda> any thoughts
[22:13:01 CET] <TanaPanda> also. When I stream out the video file using VLC i keep my wifi connection. However when I stream out via ffmpeg i lose my internet. Do i need to add a command saying that the file should only stream out via ethernet?
[22:42:42 CET] <bencc1> can low disk IOPS cause freezes when capturing the screen with ffmpeg?
[22:43:42 CET] <bencc1> when I have one instance of ffmpeg capturing a xvfb screen inside docker it works fine
[22:43:54 CET] <bencc1> when I have 4 instances on the same machine I get freezes
[22:44:12 CET] <bencc1> but I don't see a problem with CPU load or memory in the machine graphs
[22:45:41 CET] <BtbN> elmininate the disk writes and find out?
[22:45:57 CET] <BtbN> But screen grabbing is just relatively inefficient, so I'd suspect multiple processes doing it will just kill it.
[22:48:03 CET] <bencc1> BtbN: what will be the bottleneck?
[22:48:17 CET] <BtbN> The screen capture
[22:48:27 CET] <bencc1> cpu, memory, disk?
[22:48:35 CET] <BtbN> no, the screen capture itself
[22:49:03 CET] <bencc1> I'm running each screen capture in a separate docker container with separate virtual xvfb screen
[22:49:26 CET] <bencc1> assuming I have enough resources, why is the screen capture the bottleneck?
[22:49:32 CET] <bencc1> what resource does it consume?
[22:49:41 CET] <kepstin> memory bandwidth mostly
[22:49:57 CET] <BtbN> On entirely headless X, without a GPU involved, just memory.
[22:49:57 CET] <bencc1> so not total ram but memory bw?
[22:50:03 CET] <BtbN> But it's also horribly inefficient and locking in itself
[22:50:06 CET] <bencc1> without GPU
[22:50:15 CET] <BtbN> So it does not need any resourced to suck
[22:50:46 CET] <bencc1> it has to be limited by something
[22:51:00 CET] <bencc1> it might be memory bandwidth, I don't know
[22:51:16 CET] <bencc1> but I don't understand what "horribly inefficient and locking in itself" means
[22:51:19 CET] <bencc1> what does it lock?
[22:51:22 CET] <BtbN> X
[22:51:38 CET] <bencc1> doesn't each docker container has separate X?
[22:51:50 CET] <BtbN> Who know how that stuff interacts.
[22:51:53 CET] <kepstin> if you're running separate xvfb for each then yeah
[22:52:01 CET] <bencc1> yes, I am
[22:52:12 CET] <BtbN> It should be fairly trivial to test if it's disk io.
[22:52:16 CET] <BtbN> Just... don't write to disk
[22:52:16 CET] <bencc1> each ffmpeg running in a separate docker container with a separate xvfb
[22:52:25 CET] <bencc1> how?
[22:52:56 CET] <bencc1> if I don't write to disk, how can I test the ffmpeg video output?
[22:53:11 CET] <kepstin> switch ffmpeg to use "-f null -" instead of your real output file
[22:53:35 CET] <bencc1> and compare what?
[22:53:35 CET] <kepstin> hmm, well, i suppose it would be hard to tell if it's hitting this issue
[22:58:36 CET] <bencc1> what happens if ffmpeg doesn't have enough iops on the disk?
[22:58:43 CET] <bencc1> how can I see it in ffmpeg?
[22:59:53 CET] <kepstin> wouldn't be anything obvious, other than that the speed in the stats output might drop below 1.0x
[23:00:12 CET] <kepstin> ffmpeg cli wasn't designed as a realtime tool, but as a batch tool :/
[23:10:37 CET] <bencc1> can I make ffmpeg use less iops? maybe with increasing thread_queue_size or similar?
[23:13:53 CET] <kepstin> use settings that make the video output smaller, i guess?
[23:14:24 CET] <kepstin> add 6 to your crf, that should significantly reduce the output bitrate.
[23:14:44 CET] <kepstin> make it look terrible, but it's just for testing so whatever
[23:15:38 CET] <bencc1> thanks
[23:15:53 CET] <bencc1> maybe I'll switch to SSD and check if it fixes the issue
[23:16:16 CET] <bencc1> it has much more iops and throughput
[23:22:33 CET] <jokoon> hum
[23:22:40 CET] <jokoon> I have a video with an orientation
[23:22:45 CET] <jokoon> how can I change that?
[23:23:29 CET] <jokoon> nevermind
[23:33:51 CET] <jokoon> actually I cant manage to make it work
[23:34:05 CET] <jokoon> I tried -codec copy with a metadata change
[23:34:20 CET] <jokoon> '-codec', 'copy', '-metadata:s:v','rotate="90"',
[23:46:21 CET] <jokoon> also has a chroma location: left
[23:46:37 CET] <jokoon> I have green zones after converting
[23:52:33 CET] <jokoon> forget it I reencoded
[00:00:00 CET] --- Wed Dec 18 2019