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

[burek]

[01:11:22 CET] <johnjay> kepstin: the guy had one other video about the 480i stuff
[01:11:27 CET] <johnjay> https://www.youtube.com/watch?v=1MY-jUkogbg
[01:11:48 CET] <johnjay> mostly interlacing sounds like a nightmare for capturing
[01:38:10 CET] <another> very interesting. thanks johnjay
[01:40:34 CET] <johnjay> np. i don't know much C so i'm always looking for good articles or tutorials on video stuff
[01:40:46 CET] <johnjay> otherwise i guess you could read ffmpeg src and learn everything. XD
[02:20:15 CET] <analogical> I'm noticed something really strange. All incompletely downloaded .mkv files are playable but only some incompletely download .mp4 files are playable. Home comme?
[02:21:14 CET] <analogical> *come
[02:36:44 CET] <DHE> mp4 files need muxing options to be stream-friendly
[02:37:00 CET] <DHE> and a truncated file is, like, a partial stream sorta
[03:44:36 CET] <kepstin> analogical: it's basically a design flaw in the mp4 container. some initialization data the codec needs to start decoding is stored in the same place as the index
[03:45:05 CET] <kepstin> analogical: and the index is variable size and can't be written until after the video's encoded, so it's normally put at the end of the file. This means the initialization data is also at the end of the file
[03:45:15 CET] <kepstin> analogical: so if you're missing the end of the file, you can't decode anything
[03:46:00 CET] <kepstin> analogical: ffmpeg (and other tools) can optionally do a second pass to move this data to the start of the file instead - that's what happened in the files that are playable for you.
[03:47:52 CET] <analogical> interesting!
[04:06:34 CET] <kepstin> this is also why you shouldn't use mp4 files for things like live screen capture - if something crashes/breaks, the resulting partial file won't be playable
[04:13:40 CET] <johnjay> kepstin: that sega genesis dithering looks gorgeous doesn't it
[04:14:03 CET] <johnjay> amazing what you can do with just composite video
[09:16:36 CET] <bencc1> I have a/v sync issue in adobe premiere with mp4 captured using ffmpeg
[09:17:04 CET] <bencc1> in "ffprobe -i cap.mp4 -show_streams" I see that
[09:18:01 CET] <bencc1> The video stream start_time=0.020996 while the audio stream start_time=0
[09:18:37 CET] <bencc1> video start_pts=1290 and audio start_pts=0
[09:18:58 CET] <bencc1> video timecode=N/A
[09:19:39 CET] <bencc1> should I fix this when I capture with ffmpeg? could this cause a/v sync issue in a video editor?
[12:56:07 CET] <chinknot> I'm trying to use pipes to input an embedded image from an audio file into a second ffmpeg command, why is my pipe broken? https://pastebin.com/raw/iTmffq7j - the error says: [image2 @ 0x7fffcb59bac0] Could find no file with path 'pipe:0' and index in the range 0-4pipe:0: No such file or directory
[14:24:08 CET] <kepstin> chinknot: the 'image2' muxer/demuxer is designed to work only with files, since it turns each frame of video into a separate file. You can try 'image2pipe' instead.
[14:26:24 CET] <chinknot> thank you. it worked this time
[15:41:36 CET] <bencc1> what does time_base=1/61440 in ffprobe means?
[15:41:58 CET] <bencc1> I've created a 30 CFR file so I think it should be 1/60000
[15:44:21 CET] <Hello71> not sure, but I think it doesn't matter
[15:44:22 CET] <Hello71> as long as the numerator is right
[15:50:08 CET] <Derpton899> Hello?
[15:50:12 CET] <Derpton899> Oh finally.
[15:51:49 CET] <Derpton899> Hi. I have a question about ffmpeg. Is it possible to save a video capture stream directly to disk drive without encoding it? I have a USB capture card plugged into my raspberry pi 3b+, and I want to save the video footage from the capture card into my drive without encoding it as raspberry pi does not have that much power to do so.
[15:55:48 CET] <BtbN> In theory, yes. In reality, your storage will be too slow to sustain that.
[15:56:32 CET] <BtbN> Specially with the USB Cap card already fighting with the USB Storage about the very limited USB2 bandwidth.
[15:57:29 CET] <Derpton899> I have an external HDD connected to it using USB. I have a streaming server set up on it which I use to download files using torrents and stream from rpi. It can handle around 80 mbps read/write
[15:58:32 CET] <Derpton899> I think that should be sufficient? Or is it still too slow?
[16:01:02 CET] <Derpton899> https://pastebin.com/raw/N93we0xd this is what I'm working with.
[16:03:02 CET] <Derpton899> Is it possible to tell me what I need to do to achieve what I plan to do?
[16:03:48 CET] <Derpton899> I have tried "ffmpeg -f v4l2 -input_format mjpeg -i /dev/video0 -c:v copy test.mkv" but I'm not sure if that is the correct way of doing it.
[16:08:03 CET] <Hello71> don't some versions of rpi have hardware encoding
[16:08:25 CET] <Hello71> knowing them it's some proprietary blob that doesn't work in ffmpeg, but still
[16:09:22 CET] <Derpton899> I'm not sure if hardware encoding is available in rpi 3's.
[16:19:50 CET] <wondiws> Derpton899, I'm pretty sure it is
[17:18:06 CET] <bencc1> how can I ensure constant audio pkd_duration and pkt_duration_time when capturing from pulseaudio?
[17:18:39 CET] <bencc1> I see in "ffprobe -show_frames" that each audio packet has different duration
[17:18:44 CET] <bencc1> this is how I capture:
[17:18:48 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
[19:45:17 CET] <kepstin> bencc1: i dunno what's up, aac has a fixed frame size of 1024 samples, so all the audio packets should have the same duration (excluding preroll, of course).
[19:45:38 CET] <kepstin> bencc1: pulseaudio has nothing to do with it, since the audio gets re-framed before encoding to meet the encoder requirements
[19:53:01 CET] <bencc1> kepstin: part of the frames: https://pastebin.com/raw/242My9tC
[19:53:42 CET] <bencc1> ffmpeg -f pulse -ac 2 -ar 48000 -i default -f x11grab -framerate 30 -i :0.0 -acodec aac -b:a 96k -ar 48000 -vcodec libx264 -pix_fmt yuv420p -preset:v veryfast -crf 23 -vf fps=30 cap.nut
[19:54:01 CET] <bencc1> also tried to add "-ar 48000" to -acodec but still doesn't help
[19:54:30 CET] <bencc1> do I need something like "-af "aresample=async=1" ?
[19:54:43 CET] <kepstin> what's the timebase?
[19:54:56 CET] <kepstin> (need -show_streams in ffprobe to get that)
[19:56:28 CET] <bencc1> https://pastebin.com/raw/PD76LyCz
[19:56:39 CET] <bencc1> kepstin: ^^ -show_streams
[19:57:55 CET] <bencc1> I also don't understand why video stream has "time_base": "1/61440" instead of "1/60000"
[19:58:32 CET] <kepstin> that's an mp4 quirk, x11grab uses microsecond timebase but it gets reduced a bit to go into mp4
[19:58:46 CET] <kepstin> so yeah, audio's using sample rate timebase, that's fine.
[19:59:15 CET] <kepstin> is the ffmpeg capture command running slower than realtime?
[19:59:34 CET] <bencc1> I do get warnings when it runs
[19:59:44 CET] <kepstin> oh, humm, you're using -vf fps=30, i have no idea why tou'd have that weird timebase
[19:59:49 CET] <kepstin> either way, mp4 muxer issue :/
[20:00:12 CET] <bencc1> "-vf fps=30" ensure I have CFR for video
[20:00:17 CET] <kepstin> wait, your command and that output don't match. the output is mp4, but your command has nut
[20:00:19 CET] <bencc1> I think I need something similar for audio
[20:00:42 CET] <bencc1> ffmpeg -i cap.mkv -c:a copy -c:v copy -chunk_duration 1000k -movflags +faststart out.mp4
[20:00:56 CET] <kepstin> and that has an mkv
[20:00:57 CET] <bencc1> I capture with .nut and at the end convert to mp4
[20:01:07 CET] <bencc1> ffmpeg -i cap.nut -c:a copy -c:v copy -chunk_duration 1000k -movflags +faststart out.mp4
[20:01:09 CET] <bencc1> fixed
[20:01:18 CET] <kepstin> ignore the mp4, look at the nut file you captured :/
[20:01:19 CET] <bencc1> ffmpeg -i cap.mkv -c:a copy -c:v copy -movflags +faststart out.mp4
[20:01:25 CET] <bencc1> why?
[20:01:47 CET] <kepstin> because you need to narrow down the cause of the issue.
[20:01:50 CET] <bencc1> I copy the audio and video streams. do you think the muxer changes frame time?
[20:01:54 CET] <bencc1> ok
[20:02:11 CET] <bencc1> is there a way to force constant audio frames on the output?
[20:02:24 CET] <bencc1> similar to "-vf fps=30" for video?
[20:02:29 CET] <kepstin> when you did the original capture, was the "speed" output of the ffmpeg stats line 1.0 ?
[20:02:40 CET] <bencc1> close to 1.0
[20:03:08 CET] <bencc1> shouldn't "-vf fps=30" fix the speed?
[20:03:17 CET] <bencc1> again, I'm looking for something similar for audio
[20:03:24 CET] <kepstin> fps and speed are unrelated
[20:03:53 CET] <bencc1> this doesn't force constant audio frames: "-acodec aac -b:a 96k -ar 48000"
[20:03:55 CET] <kepstin> speed is whether the ffmpeg command is encoding video as fast as it's reading it, if it's lower than 1.0 that means it's falling behind realtime and stuff breaks
[20:04:10 CET] <bencc1> ok
[20:04:23 CET] <bencc1> I still think that it should be possible to force constant audio frames
[20:04:39 CET] <bencc1> because it's working for video
[20:05:03 CET] <kepstin> please look at the frame times in the nut file to narrow down where the issue is being introduced
[20:06:24 CET] <kepstin> but if the problem's present there, it could possibly means that your system isn't reading audio fast enough, so it's missing bits. and there's no real way to fix that.
[20:06:55 CET] <kepstin> please also pastebin the output, of the original capture ffmpeg command as well
[20:07:17 CET] <bencc1> I will
[20:07:31 CET] <bencc1> but I still looking for a way to force constant audio output
[20:07:47 CET] <bencc1> it should be possible to duplicate and drop audio frames if ffmpeg doesn't keep up
[20:07:57 CET] <bencc1> that's what I'm doing for video and it's working
[20:10:52 CET] <kepstin> audio doesn't work like that :)
[20:11:56 CET] <kepstin> that said, the resample filter *can* be configured to stretch audio to match timestamps, but iirc you'll get pitch shifting with that, and it won't fix dropouts.
[20:12:14 CET] <kepstin> so if you're missing audio, it'll go from sounding bad to sounding bad differently.
[20:12:37 CET] <kepstin> do you have an actual problem during playback, anyways?
[20:13:51 CET] <bencc1> the video editing person complains that there is A/V sync issue when opening the mp4 in Adobe Premiere Pro
[20:14:09 CET] <bencc1> there is no problem when playing the file in the browser or video players
[20:22:23 CET] <bencc1> kepstin: I have two steps: 1) capture to nut 2) convert to mp4 without transcoding
[20:22:40 CET] <bencc1> does it make sense to re-encode the audio to ensure constant frame rate?
[20:23:01 CET] <kepstin> i have asked you for two things: output of the original capture command, and to look at the timestamps in the nut file
[20:23:02 CET] <bencc1> maybe capture in higher quality to ensure I won't loss quality
[20:23:13 CET] <bencc1> I will
[20:23:20 CET] <kepstin> (actually, look at the packet timestamps too please)
[20:23:40 CET] <bencc1> I need to run the capture again and it'll take 2 hours
[20:23:58 CET] <kepstin> then, just run it for a few minutes to get a sample?
[20:24:28 CET] <bencc1> ok
[20:24:56 CET] <bencc1> trying
[20:27:06 CET] <bencc1> kepstin: 1 minute will be enough? more?
[20:27:58 CET] <kepstin> if your ffprobe output is right, it looks like the issue was happening even right at the start of the file, so it doesn't have to be too long.
[20:28:59 CET] <bencc1> ok
[20:40:55 CET] <asterismo_l> hi
[20:41:23 CET] <asterismo_l> i'm having some problems on compiling ffmpeg without SSE and SSE4 cue support
[20:41:49 CET] <asterismo_l> it seems that the VPS i'm running ffmpeg, does nat have this instruction sets enabled
[20:42:16 CET] <bencc1> kepstin: 1 minute output: https://pastebin.com/raw/CJuJFc52
[20:42:28 CET] <asterismo_l> my question is, i only have to compile ffmpeg? or must i compile x264 too?
[20:45:07 CET] <bencc1> kepstin: ffprobe -show_streams of the nut file: https://pastebin.com/raw/KQynq24j
[20:46:48 CET] <bencc1> kepstin: ffprobe -show_frames of the nut file (first few frames) https://pastebin.com/raw/1aJvnZMn
[20:46:58 CET] <bencc1> now audio packet duration seems constant
[20:47:27 CET] <bencc1> I don't know if the problem is in the .mp4 file or because of server load or something else
[20:48:53 CET] <kepstin> something's pretty seriously wrong there, hmm. you shouldn't be getting that "Queue input is backward in time" warning
[20:49:05 CET] <kepstin> that means the timestamps pulseaudio is giving you are busted
[20:50:53 CET] <bencc1> kepstin: is there something wrong with my capture command?
[20:51:26 CET] <kepstin> i think the capture command is fine, although you might want to try without the -thread_queue_size options to make sure that's not the issue.
[20:51:36 CET] <kepstin> it's possible you some sort of timing issue with the system clock or sound card
[20:51:36 CET] <bencc1> ok
[20:52:05 CET] <kepstin> (if this is a vm, virtual clocks behave... really poorly depending on configuration)
[20:52:27 CET] <bencc1> this is a docker container on a google cloud vm
[20:52:42 CET] <bencc1> is there anything I can do to improve the clock?
[20:52:50 CET] <kepstin> ask google nicely
[20:53:13 CET] <kepstin> (they'll ignore you, so that's a silly way of saying "no, get a better host")
[20:53:33 CET] <bencc1> yes
[20:53:47 CET] <bencc1> what about re-encoding the audio stream when converting .nut to .mp4?
[20:53:51 CET] <bencc1> should it work?
[20:54:51 CET] <asterismo_l> i'm using this tutorial for compiling x264. Is there any way to pass a disable sse3 and sse4 instruction flag?
[20:54:55 CET] <asterismo_l> https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[20:55:24 CET] <kepstin> bencc1: hmm... probably not, but you might as well try
[20:55:42 CET] <kepstin> bencc1: I honestly still use dedicated hardware for all my realtime stuff to avoid problems like this :/
[20:56:18 CET] <kepstin> asterismo_l: x264 and ffmpeg automatically select which assembly to use depending on what the cpuid flags claim the cpu supports, you must have a really busted vm host :/
[20:57:51 CET] <asterismo_l> its like their hypervisor is not handling cpu well
[20:57:56 CET] <bencc1> kepstin: I don't understand why re-encoding audio won't work
[20:58:49 CET] <asterismo_l> https://paste.debian.net/1122749/
[20:58:56 CET] <kepstin> bencc1: if everything's working correctly, re-encoding will preserve timestamps, so the audio will have the same issue where audio timestamps are going up faster than can be accounted for by the number of samples.
[20:59:05 CET] <bencc1> kepstin: that's interesting: "ffprobe -show_frames" for the nut file show constant audio frame duration
[20:59:18 CET] <bencc1> but audio duration for the mp4 varies
[20:59:24 CET] <kepstin> bencc1: the difference between pts of successive frames is the important bit
[20:59:27 CET] <bencc1> any idea why?
[20:59:28 CET] <kepstin> bencc1: ignore the durations
[20:59:39 CET] <bencc1> ok
[21:00:20 CET] <kepstin> asterismo_l: honestly, i'd recommend complaining to your vm host so you can get a refund so you can switch to a better host which doesn't have broken cpus :/
[21:01:11 CET] <kepstin> asterismo_l: you can check the x264 and ffmpeg configure scripts, there might be options to disable assembly for specific instruction sets
[21:01:34 CET] <kepstin> but the encoder does run a fair bit faster if you get a cpu that supports those, so... :/
[21:01:38 CET] <bencc1> kepstin: your suggestion is to check the machine/vm/container clock?
[21:01:53 CET] <bencc1> kepstin: no post-processing or command param to try?
[21:02:02 CET] <kepstin> bencc1: i assume there's no physical sound card?
[21:02:24 CET] <bencc1> no
[21:02:25 CET] <kepstin> bencc1: any command that would "fix" the audio timestamps would likely cause a/v desync
[21:02:32 CET] <bencc1> tried without "-thread_queue_size". same result
[21:02:59 CET] <kepstin> bencc1: then check the pulseaudio log output, i'd guess it's running on high-res timers, and is probably complaining about the problem :/
[21:03:14 CET] <bencc1> I thought that transcoding the audio means aac->raw->aac so I can "fix" it
[21:03:26 CET] <kepstin> bencc1: that would "fix" it, but would also cause a/v desync
[21:03:29 CET] <bencc1> where is the pulseaudio log?
[21:03:40 CET] <kepstin> depends how you started pulseaudio
[21:03:46 CET] <bencc1> ubuntu
[21:03:52 CET] <bencc1> sorry, debian
[21:03:59 CET] <bencc1> started with: "pulseaudio --start"
[21:04:32 CET] <kepstin> hmm, this is a docker container, you said? it wouldn't have a user journal then
[21:04:42 CET] <kepstin> i honestly don't know what it would do
[21:05:26 CET] <bencc1> I'll try to add log target to the command
[21:05:27 CET] <bencc1> testing
[21:06:30 CET] <kepstin> bencc1: what are you capturing anyways? are you sure it's not possible to use it as an input directly, so you don't have to do realtime capture of application output? :/
[21:07:35 CET] <bencc1> I'm capturing chromium browser running in xvfb virtual display
[21:08:36 CET] <kepstin> if you weren't in docker, i would suggest trying aloop, since it runs in the kernel, it might not have as bad timing issues
[21:08:58 CET] <kepstin> note that pulseaudio likes to run with realtime scheduling mode, which probably also doesn't work in docker
[21:10:14 CET] <kepstin> i used to have an application where i was using a browser in xvfb to render a video, and i ended up rewriting it to be a python script that drew the thing directly with pycairo and sent raw frames to ffmpeg to encode
[21:10:20 CET] <kepstin> so... yeah.
[21:10:31 CET] <kepstin> (runs faster than realtime now)
[21:10:39 CET] <bencc1> cool
[21:11:17 CET] <bencc1> does it run faster than the speed of light?
[21:12:07 CET] <kepstin> it was a batch processing thing, not live input, so having the browser render it realtime was the limiting factor on speed.
[21:12:32 CET] <bencc1> I tried this: 'pulseaudio --start > ./pulse.log 2>&1
[21:12:41 CET] <bencc1> but log file is empty
[21:12:48 CET] <bencc1> I'll try raising the log level
[21:14:06 CET] <kepstin> you'd have to run pulseaudio in the foreground (without --daemonize - note that --start implies --daemonize) for it to log to stderr.
[21:14:30 CET] <kepstin> you can use --log-target to tell it to log to a file instead tho
[21:14:56 CET] <kepstin> (i found that out by reading the man page just now)
[21:14:58 CET] <bencc1> trying
[21:19:18 CET] <another> asterismo_l: update your ffmpeg
[21:19:36 CET] <another> iirc this is a known bug which has been fixed in recent versions
[21:19:42 CET] <asterismo_l> another, i'm compiling it from source
[21:20:05 CET] <another> good
[21:20:16 CET] <another> but you don't need to disable sse*
[21:20:16 CET] <asterismo_l> wget -O ffmpeg-snapshot.tar.bz2 https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2
[21:33:41 CET] <bencc1> kepstin: pulseaudio log: https://pastebin.com/JvAiqzJd
[21:36:27 CET] <kepstin> well, you should probably be recording at 44100Hz instead of 48000Hz to avoid an extra resample (and extra cpu usage)
[21:36:42 CET] <kepstin> but yeah, pulseaudio is definitely complaining about a bunch of buffer underruns there
[21:37:56 CET] <bencc1> where do you see buffer issues in the log?
[21:38:42 CET] <kepstin> there's a bunch of "Requesting rewind due to end of underrun"
[21:38:59 CET] <kepstin> and a rewind sounds like something that would generate broken back in time timestamps
[21:39:26 CET] <bencc1> ok
[21:40:35 CET] <bencc1> anything I can do about it?
[21:40:40 CET] <bencc1> beside using 44100Hz
[21:41:12 CET] <kepstin> bencc1: ask the pulseaudio people for help, i guess?
[21:41:33 CET] <kepstin> trying to get it to run with realtime scheduling might make a difference, but i have no idea how you'd do that
[21:41:57 CET] <bencc1> thanks
[21:57:47 CET] <BtbN> Hm, I want to concat and stream a ton of mostly unrelated videos out via rtmp. First step is that I transcode them all using the same settings. Step two I create a m3u8 playlist with discontinuity tags with all of them in, and play it with -re.
[21:58:23 CET] <BtbN> Result: On the boundaries of the videos, it freezes for a few seconds, then the audio audibly fast-forwards, playback resumes, but a/v is horribly off-sync?!
[22:19:01 CET] <kepstin> BtbN: you might be better off using the ffmpeg's concat demuxer/playlist format
[22:21:53 CET] <BtbN> kepstin, doesn't make a difference
[22:22:04 CET] <BtbN> the files can be in vastly different resolutions/framerates/...
[22:22:16 CET] <BtbN> that's why I opted for a local HLS playlist, so I can at least signal that
[22:22:31 CET] <BtbN> was hoping throwing a scale and fps filter in there would just transform everything. But it doesn't.
[22:22:50 CET] <kepstin> hmm, the issue might be due to how ffmpeg opens each file as it comes up in the playlist, so there's a delay as it does that
[22:23:09 CET] <BtbN> A few seconds of being "stuck" shouldn't be an issue
[22:24:04 CET] <kepstin> you could try doing something like having the ffmpeg reading the playlist output to something like nut in a pipe to a second ffmpeg that does the rtmp stream (the latter would have -re, the first would not)
[22:24:34 CET] <BtbN> This would be a bit messy to setup, since it's not a shell calling ffmpeg here.
[22:26:53 CET] <BtbN> I also tried just two-step concatenating everything into a temporary file first, and then streaming that. But it shows the same behaviour.
[22:27:27 CET] <kepstin> hmm, i'd really expect that to work.
[22:27:45 CET] <kepstin> must be something weird going on with timestamps then
[22:27:48 CET] <BtbN> I feel like Twitch horrily messed up the timestamps in those VODs
[22:27:54 CET] <BtbN> (They are downloaded highlights)
[22:28:30 CET] <kepstin> worst case if you do them as separate ffmpeg inputs and use the concat muxer, that should apply all the timestamp cleanups and give you something reasonable
[22:28:40 CET] <kepstin> sorry, concat filter*
[22:29:15 CET] <BtbN> Yeah, that's my next idea, but will be a behemoth of a commandline, since I'll need to do it for audio and video, and lists can have a couple dozen videos
[22:29:56 CET] <BtbN> And it'll probably explode if there's the slightest discrepancy between audio and video length in one of the inputs?
[22:30:20 CET] <kepstin> concat filter corrects mismatched audio/video lengths in the inputs
[22:30:33 CET] <BtbN> But isn't it only a video filter?
[22:30:42 CET] <kepstin> no, it's an a/v filter
[22:30:51 CET] <BtbN> ah, nvm that then
[22:31:10 CET] <kepstin> you can use it on only video or only audio if you want, of course
[22:31:24 CET] <kepstin> but it can also work on arbitrary combinations of audio+video tracks.
[22:31:43 CET] <BtbN> Looking at the downloaded video file from one of the Highlights... even that is already messed up
[22:31:53 CET] <BtbN> so Twitch is definitely doing shit with their timestamps
[22:36:14 CET] <BtbN> This Video, for example: https://www.twitch.tv/videos/456369484
[22:36:21 CET] <BtbN> Downloading it via ffmpeg -i https://vod-metro.twitch.tv/d3ecb02f27b35de68d4e_esamarathon_49108928056_5062920213/chunked/highlight-456369484.m3u8 -vf scale=1920:1080,fps=60 -c:v libx264 -crf 26 -preset veryfast -c:a aac -ar 48000 -b:a 192k test.ts
[22:36:43 CET] <BtbN> generates a TON of [mpegts @ 0x55d8862f0300] Non-monotonous DTS in output stream 0:1; previous: 345547, current: -1527330; changing to 345548. This may result in incorrect timestamps in the output file.
[22:37:02 CET] <BtbN> So yeah, they are returning garbage timestamps
[22:43:39 CET] <BtbN> But somehow only for the first ~40 seconds of that video
[22:48:44 CET] <BtbN> Maybe I need https://github.com/FFmpeg/FFmpeg/commit/d6ac6650b911f0957e69545d7fc25be6b7728705#diff-0e876d29bdcae30d9d256f04bc8795db
[23:12:50 CET] <BtbN> Yeah, that seems to work _a lot_ better.
[23:29:20 CET] <vlt> Hello. What does filter "loudnorm" do? Just change volume depending on RMS peak or similar or will it compress?
[23:32:04 CET] <CoreX> read the documentation https://ffmpeg.org/ffmpeg-filters.html#loudnorm
[23:36:52 CET] <vlt> CoreX: Thank you!
[00:00:00 CET] --- Fri Dec 27 2019