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

[burek]

[02:15:53 CET] <Alexa> Hi! On Linux, How do I get single line output video processing instead of getting new line for every single frame that is encoded?
[02:25:18 CET] <kepstin> Alexa: make your terminal window wider, if the stats line wraps it doesn't update in-place in many (most? all?) terminals
[02:30:14 CET] <Alexa> kepstin, it does in every terminal emulator I've used on Linux.
[03:26:49 CET] <illuminated> what would you convert aac 5.1 audio to that would be compatible with roku/kodi
[04:08:51 CET] <Z2ATG> does anyone know what the strict_gop option does and what needs to be compiled into ffmpeg for it to be available as an option?
[04:25:37 CET] <kepstin> Z2ATG: that's an option to the libx264 encoder, you need to use -x264opts to set it
[04:26:04 CET] <kepstin> i think
[04:26:20 CET] <kepstin> hmm, there might be an option mapping with a different name
[04:26:53 CET] <kepstin> oh, wait nvm, i'm confused
[04:27:09 CET] <kepstin> that's a value that the -mpv_flags option takes apparently
[04:27:17 CET] <kepstin> which affects the *builtin* mpegish encoders
[04:27:24 CET] <kepstin> (no special compile options needed)
[04:27:32 CET] <kepstin> probably mostly useful with mpeg2video
[04:27:54 CET] <Z2ATG> hmm
[04:28:20 CET] <Z2ATG> so I'm getting "[NULL @ 0x4064f80] Unable to find a suitable output format for 'strict_gop'" and then "strict_gop: Invalid argument"
[04:28:46 CET] <kepstin> that means you have "strict_gop" somewhere in an invalid place in your command line
[04:28:53 CET] <kepstin> please share your entire command line
[04:29:32 CET] <Z2ATG> alright, don't slap me I'm new to this
[04:29:35 CET] <Z2ATG> ./ffmpeg -y -i z1_pkg.mp4 -c:v h264 -profile:v high -level:v 3.1 -bf 0 -b:v 4000 -maxrate 4000 -muxrate 4000K -preset veryslow strict_gop 1 -vsync 0 -look_ahead 0 -video_track_timescale 10 -crf 1 -movflags empty_moov+frag_keyframe+omit_tfhd_offset+default_base_moof -f mp4 test.mp4
[04:29:43 CET] <Z2ATG> do you want me to put full output in pastebin?
[04:29:50 CET] <kepstin> no, that's fine
[04:30:23 CET] <kepstin> so you have "strict_gop" just sitting on its own, not as a value to any other option, and without starting with a - so ffmpeg assumes its an output filename
[04:30:49 CET] <kepstin> just remove it (and the following '1')
[04:31:43 CET] <Z2ATG> ah, missed the -, foolishness
[04:31:56 CET] <kepstin> there's no option named "strict_gop", so adding a - won't help
[04:32:21 CET] <Z2ATG> that's strange
[04:33:12 CET] <kepstin> strict_gop is a *value* that the -mpv_flags option takes, not an option on its own.
[04:33:37 CET] <kepstin> Note that ffmpeg doesn't have a builtin h264 encoder, so with -c:v h264 it's probably actually selecting -c:v lib264 for you
[04:33:59 CET] <kepstin> as far as i can tell, libx264 does not use the -mpv_flags option, or at least not the strict_gop flag
[04:34:10 CET] <kepstin> it's selecting -c:v libx264 sorry
[04:34:47 CET] <Z2ATG> so what I'm trying to do, is I have a video which has been encoded with some options, and then it is being reencoded, and I'm trying to encode it back.  The original encoding has -strict_gop 1 in the command and uses h264_qsv as the encoder.
[04:35:17 CET] <kepstin> oh, huh, i guess that must be an encoder-specific option to the h264_qsv encoder
[04:35:20 CET] <kepstin> i've never used that
[04:35:30 CET] <Z2ATG> it is obscure O_o
[04:35:51 CET] <kepstin> nah, it's just that for most use cases I do, i don't have a reason to use hardware encoders
[04:36:13 CET] <kepstin> what do you mean "encode it back"?
[04:36:37 CET] <kepstin> h264 encoding is lossy, every time it gets re-encoded it gets worse quality
[04:37:22 CET] <Z2ATG> So I have one system encoding the video to (from what I can gather) a fragmented form, which is being played in a javascript video player
[04:38:08 CET] <kepstin> that doesn't necessarily require re-encoding, if the video happened to already be the right codec it's possible to copy it instead.
[04:38:23 CET] <Z2ATG> so that part is working ok
[04:38:25 CET] <kepstin> but go on...
[04:38:34 CET] <Z2ATG> but if that same video is played in like vlc, there is no tracking data
[04:38:44 CET] <kepstin> you mean, you can't seek in it?
[04:38:50 CET] <Z2ATG> yeah
[04:39:09 CET] <kepstin> easy enough to fix, use "ffmpeg -i whatever.mp4 -c copy newfile.mp4" to remux it without re-encoding
[04:39:15 CET] <kepstin> that'll turn it into a non-fragmented file
[04:39:17 CET] <kepstin> without re-encoding
[04:39:17 CET] <Z2ATG> yeah
[04:39:38 CET] <Z2ATG> so that has been done, and now we have like a free atom and and mdat atom at the front of the file, then moov
[04:39:58 CET] <Z2ATG> now, I want to make the remuxed file, and make it the original fragmented form
[04:40:09 CET] <Z2ATG> ideally with minimal lossiness
[04:40:32 CET] <Z2ATG> erm, first make meant to be take*
[04:40:49 CET] <kepstin> you probably won't be able to exactly recreate it, but you'd want to use -c copy and then appropriate fragmentation-related options to the mov/mp4 muxer
[04:40:55 CET] <kepstin> again, this don't require re-encoding
[04:41:05 CET] <Z2ATG> oh, that's good to know
[04:41:24 CET] <Z2ATG> I've been trying to copy the original encoding options
[04:43:22 CET] <Z2ATG> so are the fragmentation related options just the movflags?
[04:43:27 CET] <kepstin> yeah
[04:43:42 CET] <Z2ATG> ahhh
[04:43:47 CET] <Z2ATG> I knew I was overcomplicating this
[04:43:51 CET] <Z2ATG> thanks
[05:04:05 CET] <cpplearner> Guys, I tried encoding to AAC with -b:a 128k, but the bitrate is not changing. What should I do?
[05:04:50 CET] <cpplearner> ffmpeg -i input.mkv -c:v copy -c:a libfdk_aac -b:a 128k -ac 2 output.mkv
[05:05:13 CET] <cpplearner> The bitrate is still 384 kb/s
[08:18:04 CET] <familiyaF> Hi, I am trying to transcode a video using hwaccel on AMD R5 230 GPU. I am able to decode, however while encoding I am getting the following error
[08:18:04 CET] <familiyaF> Encoding entrypoint not found (7 / 6).(Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height( (My cmd line
[08:18:04 CET] <familiyaF> ffmpeg -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i input.mp4 -c:v h264_vaapi -b:v 2M -maxrate 2M output.mp4
[16:31:21 CET] <zerodefect> When uploading a file to the FFmpeg FTP server as part of a bug, who has access to those files? I want to send a file, but I could land in hot water if it is widely shared. :(
[16:33:18 CET] <JEEB> not sure we still have a public upload ftp
[16:34:29 CET] <zerodefect> Oh ok, I was reading instructions here: https://ffmpeg.org/bugreports.html . It looks like public only has write access, but I was more interested who has access to those files once uploaded?
[16:35:14 CET] <JEEB> zerodefect: if it's abig file you could see if dd'ing thefirst xyz megabytesstill leads to the samwresult. also if the contentis problematic but you know how it was created you could recreate thw same issue with aless problematic source?
[16:36:16 CET] <JEEB> zerodefect: i know there is a samples site which is public. the one in that document I'm not sure if I tested and found it to be not accessible? if it is now, then that has definitely changed
[16:36:39 CET] <JEEB> but i do not know if that points to the samples server or not
[16:37:39 CET] <JEEB> thus i think it'dbe simpler in.theshort run if a cut with dd or so part of thesample is enough, or if a similar sample can be recreayed with less problematic content
[16:38:03 CET] <zerodefect> Yes, good points regarding reproducable testcase. I have a whopping 63GiB file in S3. I'm having issues previewing it off AWS S3 via https with ffplay. It takes an age to start playing but GStreamer has no issues. So my issue is not a traditional use case (yay cloud!)
[16:38:57 CET] <JEEB> sorry for tve typos btw, touchscreen keyboard on a train
[16:39:09 CET] <zerodefect> No problem at all
[16:39:52 CET] <JEEB> anyways does the same exact thing have issues locally or when piped?
[16:40:08 CET] <JEEB> or only via https?
[16:40:31 CET] <JEEB> locally you have fast read and seek etc, while piping means thereis no seek
[16:40:48 CET] <zerodefect> No issues when playing off filesystem. Not tried piped. I'm beginning to wonder if it is an https issue.
[16:41:33 CET] <JEEB> i know thereis one fix i pulled into master that fixed some gnutls stuff
[16:41:40 CET] <zerodefect> :O
[16:41:44 CET] <JEEB> are you how far from master?
[16:41:52 CET] <JEEB> this was earlier this year
[16:42:13 CET] <zerodefect> Oh ok. I pulled a nightly build a few days ago but no difference.
[16:42:34 CET] <JEEB> https://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commit;h=bc1749c6e46099ec85110361dbe6f7994a63040d
[16:42:40 CET] <JEEB> ok so newer than this
[16:43:01 CET] <JEEB> what does ffprobe -v verbose  -i url say?
[16:44:46 CET] <zerodefect> Let me try your suggestion. I used -report and I noticed it had read the start and then seeked to the end but then was repeatedly seeking backwards. It's like it's trying to find something. ...
[16:45:36 CET] <JEEB> does s3 let you do partial requests btw?
[16:45:45 CET] <JEEB> byte offsets etc
[16:47:13 CET] <zerodefect> Yup. I can see in -report that it's successfully using `Range:` header
[16:48:35 CET] <JEEB> yea but does it actually succeed?
[16:48:49 CET] <JEEB> is this mxf or what btw?
[16:49:43 CET] <zerodefect> Yes, mxf over https: https://pastebin.com/cSva2P9G
[16:50:16 CET] <zerodefect> Short snipped (eventually ctrl+c)
[16:50:21 CET] <zerodefect> *snippet
[16:50:43 CET] <JEEB> anyways, may get back hereas i get home. afk
[16:54:11 CET] <zerodefect> @JEEB - I could share link with you if I could communicate with you somehow privately.
[16:55:26 CET] <zerodefect> ...if you're interested of course. No pressure :)
[18:34:55 CET] <transhuman> Hi! can anyone tell me what parameters I need for ffmpeg to get it to output the following format type of video I am having trouble replicating what telegram will take. https://paste.debian.net/1120538/   THANKS in advance, your help is appreciated!
[18:55:13 CET] <kepstin> transhuman: it's possible that there might be other requirements that aren't obvious from that file, but it looks like ordinary h264 video and aac audio in mp4 container.
[18:55:15 CET] <transhuman> nm thanks anyway I solved it
[18:55:35 CET] <transhuman> it seems to be the -pix_fmt yuv420p
[18:55:42 CET] <transhuman> not sure what that does
[18:56:06 CET] <kepstin> ah, yeah, most video's already 4:2:0 sampling but if your source is a gif or screencapture you might need to add that conversion yourself
[18:56:24 CET] <transhuman> ok thanks
[18:56:25 CET] <kepstin> (this is why we usually ask for the output of the ffmpeg command you ran, that would have been obvious there)
[18:56:49 CET] <transhuman> yes it would have been I just didnt know what I was looking at sorry...
[18:57:11 CET] <transhuman> anyway thanks
[18:57:28 CET] <kepstin> yeah, which is why the more info you share, the more eyeballs on it to spot things like that :)
[19:12:12 CET] <klongwood3> Hello I recently made a posting in the mailing list, but wondered if a response would be possible here as well
[19:12:20 CET] <klongwood3> Is there any reference to how ffmpeg's algorithm determines frame count for audio?
[19:13:13 CET] <JEEB> frame count?
[19:13:33 CET] <klongwood3> frame number to be more specific
[19:13:45 CET] <klongwood3> http://www.ffmpeg-archive.org/FFmpeg-audio-frame-count-nb-samples-misunderstanding-td4690189.html
[19:13:48 CET] <pink_mist> "ffmpeg's algorithm"? there's literally hundreds of different algorithms in ffmpeg
[19:13:57 CET] <JEEB> FFmpeg's own APIs are not frame-exact if that's what you mean
[19:13:58 CET] <pink_mist> which one do you even mean
[19:14:20 CET] <JEEB> when you go around parsing a file with FFmpeg you generally get packets, and usually each audio packet is a decodable thing
[19:14:34 CET] <JEEB> (exceptions like MPEG-H Audio or AC-4 exist of course)
[19:14:50 CET] <JEEB> so the amount of audio frames more or less depends on how many audio packets the compressed stream contains
[19:15:19 CET] <JEEB> I think AAC mostly has 1024 sample packets, and AAC had some 900-something I think?
[19:15:27 CET] <JEEB> *AC-3 for the second one
[19:15:35 CET] <JEEB> FLAC can have very long ones
[19:16:21 CET] <klongwood3> the audio stream is started from "sender" with a USB microphone. This audio stream is transported over TCP using RTSP, to a "receiving" machine. Both are using linux. I am trying to keep record of once the stream ends what frame number they end on.
[19:16:53 CET] <JEEB> "frame number"?
[19:17:15 CET] <JEEB> do you just want to know how many audio frames were decoded from whatever is the input?
[19:17:54 CET] <kepstin> "frame count" is mostly meaningless for audio, you really want to count number or samples, or just duration in seconds.
[19:18:16 CET] <klongwood3> In my log, the "sender" using ffmpeg to send rtsp ends on frame (n) number 359, but the "reciever " ends at frame number (n) 208
[19:18:57 CET] <kepstin> the first ffmpeg would be re-framing the audio samples from the input, whatever it is, to fit in rtsp packets.
[19:19:16 CET] <JEEB> I quickly had a look at your log and I'm not sure what you're calculating. if you just want to know how many packets/frames went through ffmpeg.c's decoding or encoding
[19:19:19 CET] <JEEB> then use -debug_ts
[19:19:36 CET] <JEEB> that specifically logs every time packet is read from input, passed to a decoder, frame received from decoder
[19:19:45 CET] <JEEB> crap passed into a filter etc etc
[19:19:45 CET] <klongwood3> JEEB this is with cli not c
[19:19:51 CET] <JEEB> ffmpeg.c is the cli
[19:19:51 CET] <JEEB> :P
[19:19:59 CET] <klongwood3> ohh got me there
[19:20:03 CET] <JEEB> as opposed to FFmpeg the project, hwihc includes the cli apps and the libraries
[19:21:08 CET] <JEEB> also with audio the thing is that your audio formats have packets that contain frames of differing size
[19:21:21 CET] <JEEB> like I just noted, so your input and outputs can differ in count
[19:21:45 CET] <kepstin> a "frame" in ffmpeg at the decoding side is just "however many samples the decoder decoded from one packet"
[19:22:03 CET] <JEEB> if you are 100% sure that your receiver will get all packets, then you should check the count of packets fed to muxer, and then the count of packets read from demuxer
[19:22:07 CET] <JEEB> those in theory should match
[19:22:16 CET] <kepstin> and if the encoding side of ffmpeg needs frames of different size, then the audio will go through a fifo to get re-frames.
[19:22:20 CET] <kepstin> re-frames
[19:22:31 CET] <kepstin> re-framed. i can't type today
[19:22:33 CET] <JEEB> but I'm still trying to figure what exactly you're gaining by checking the count
[19:22:50 CET] <JEEB> like, I can tell you how to get a count of some sort, but is that really useful for you?
[19:22:55 CET] <JEEB> is there something you actualyl want to get done
[19:26:17 CET] <klongwood3> well i am parsing the log for the last line to get the last recorded audio number. This is for multiple clients, but I have noticed it with 1 to 1 in my mentioned post.
[19:26:39 CET] <klongwood3> its really just a mechanism to make sure we recieve all the data samples at the a server before we end the stream
[19:26:54 CET] <kepstin> if you want to count samples, then count samples not frames
[19:27:07 CET] <klongwood3> samples = nb_sample??
[19:27:23 CET] <klongwood3> what do you mean "count" samples? can you clarify that
[19:28:59 CET] <JEEB> I kind of want to recommend -debug_ts if you want to know what exactly went out/in, but on the other hand it's just UGGHHHH that someone is parsing this stuff (which could at any point change if anyone wants to change the debug messaging)
[19:29:40 CET] <JEEB> for things that went into the muxer, there's a line that begins with "muxer <- "
[19:30:04 CET] <JEEB> and then on receiving side there's "demuxer -> "
[19:33:22 CET] <JEEB> unfortunately it seems like feeding into/receiving from an aduio decoder is not logged in that way
[19:34:44 CET] <JEEB> generally speaking there pretty surely is a programmatic way of doing it properly, but at this point of time I have a hunch that you don't want to actually write any multimedia code whatsoever so even if I recommend you something you would just brush it off
[19:34:58 CET] <JEEB> so eff it, if you want packets passed on and received, that is it :P
[19:36:09 CET] <klongwood3> writing like a encoder/decoder? or an algorithm that will give correct count?
[19:36:33 CET] <JEEB> signaling in some way so you don't need to parse stderr
[19:41:24 CET] <klongwood3> well audio frame count parsing was just a mechanism where to keep in account for no "audio cut off". Really the scenario is similar to a walkie talkie. One machine has a push button mechanic along with the receiver.  however we have come across where if the sender releases the button too early, or in reality immediately when they stop talking,
[19:41:25 CET] <klongwood3> parts of the audio is cut off/not heard when receiving. Frame count tracking was just a mechanism to have a safety method to tell the server not to close connection until the number is received
[19:42:39 CET] <klongwood3> parsing the stderr/log is not bad as it is from the log file outputted from the -report option
[19:45:50 CET] <JEEB> with UDP stuff I generally just set timeout, and then that's something between 250ms to 1.5s
[19:46:09 CET] <JEEB> if you don't get any packets within that time, just drop connection. otherwise block until the I/O has timed out
[19:46:42 CET] <klongwood3> side note, ffplay keeps giving an erro for debug_ts : Missing argument for option 'debug_ts'
[19:46:53 CET] <JEEB> yes, it's ffmpeg.c only
[19:47:03 CET] <klongwood3> damn
[19:48:00 CET] <klongwood3> also another question somewhat related, does RTSP always have sample size of 1024???
[19:48:04 CET] <JEEB> no?
[19:48:09 CET] <JEEB> as I said at the very beginning
[19:48:12 CET] <JEEB> it depends on the format
[19:48:18 CET] <JEEB> AAC is usually (but not always) 1024
[19:48:27 CET] <JEEB> AC-3 has something like 900-blah
[19:48:33 CET] <JEEB> FLAC can have quite long ones
[19:48:39 CET] <JEEB> no idea of vorbis or opus
[19:53:04 CET] <klongwood3> is there a reason why audio coming in has various/differing sample size from my USB mic? or is it also because of the fomat?
[19:54:05 CET] <JEEB> if you mean the input to whatever module you're utilizing with FFmpeg, that can depend on the capture settings, hardware and heck - even the actual capture module
[19:54:18 CET] <JEEB> I would guess the audio framework and its APIs mostly control that
[19:54:32 CET] <JEEB> (of your system, which the FFmpeg module is utilizing)
[19:57:49 CET] <klongwood3> I've tried setting the audio option frame_size when receiving audio from the mic (input) but nothing happens
[19:58:15 CET] <klongwood3> that prob is because like you mentioned, the various dependencies
[19:58:31 CET] <JEEB> also which module takes in which options :P
[20:00:26 CET] <JEEB> ffmpeg -h demuxer=pulse
[20:00:45 CET] <JEEB> that should output the options available (outside of the global ones) which that module takes in
[20:15:13 CET] <klongwood3> I ran the following command and got this output : https://pastebin.com/HFdDKtnR
[20:16:46 CET] <klongwood3> however when I ran with the setting -frame_count i still get varying "nb_sample" for each frame : https://pastebin.com/eBxcvsSV
[20:18:04 CET] <klongwood3> also what is fdebug ts?
[20:18:16 CET] <klongwood3> i receive an error when adding that option
[20:19:21 CET] <kepstin> hmm, you're encoding to aac, so it doesn't matter what size your input frames are, the aac encoder will re-frame them to 1024 samples per frame (plus padding)
[20:19:29 CET] <kepstin> the frame sizes up to the encoder are meaningless
[20:19:46 CET] <kepstin> what you probably want to do instead of counting decoded frames, is you should count encoded packets
[20:20:00 CET] <kepstin> just just look at the pts/duration.
[20:20:03 CET] <kepstin> or just*
[20:22:54 CET] <klongwood3> oddly enough, with -af 'ashowinfo' , the pts are not ending at the same time. The sender is ffmpeg :
[20:23:30 CET] <klongwood3> https://pastebin.com/N5ac0eFQ
[20:23:44 CET] <klongwood3> ffplay is the receiver : https://pastebin.com/YiSfg00R
[20:24:29 CET] <klongwood3> the sender ends with this line: n:312 pts:232734 pts_time:4.84863 pos:-1 fmt:s16 channels:1 chlayout:mono rate:48000 nb_samples:1200 checksum:EBBB95A2 plane_checksums: [ EBBB95A2 ]
[20:24:59 CET] <klongwood3> receiver ends with this line : [Parsed_ashowinfo_0 @ 0x7f6044005160] n:222 pts:227015 pts_time:4.72948 pos:-1 fmt:fltp channels:1 chlayout:mono rate:48000 nb_samples:1024 checksum:D0175357 plane_checksums: [ D0175357 ]
[20:30:19 CET] <kepstin> depending how the sender was stopped, it might be possible that there was some audio that passed through the filter chain but didn't get encoded/sent.
[20:31:29 CET] <kepstin> you also have multiple -f options on the output section of your ffmpeg sender command line, only the last one takes effect.
[20:32:18 CET] <klongwood3> -f s16le -f rtsp is not transporting the audio at 16bit format?
[20:32:32 CET] <kepstin> no, since the -f s16le is ignored, so it's using -f rtsp
[20:32:43 CET] <kepstin> it's then selecting the default codec since you didn't specify one
[20:32:45 CET] <kepstin> which happens to be aac
[20:33:34 CET] <JEEB> klongwood3: it's -debug_ts , not fdebug_ts
[20:33:46 CET] <JEEB> and I specifically noted you the keywords to grep for on the sending and receiving end with it :P
[20:34:06 CET] <klongwood3> in the doc, there is a part after -debug_ts that mentions fdebug_ts
[20:34:13 CET] <klongwood3> but i dont see any reference to it
[20:34:25 CET] <kepstin> if you want to send pcm audio over rtsp, you'd need to do something like "-c:a pcm_s16le"
[20:34:39 CET] <kepstin> (assuming rtsp allows that, i don't know enough about rtsp to say yes or no)
[20:34:45 CET] <JEEB> klongwood3: I have no idea what it does, but there is -fdebug ts
[20:35:06 CET] <kepstin> might run into udp packet size issues with raw pcm audio, fwiw.
[20:35:10 CET] <JEEB> that seems to print some stuff from within libavformat
[20:35:26 CET] <klongwood3> JEEB i keep getting error if i try running fdebug_ts : Reading option '-fdebug_ts' ...Unrecognized option 'fdebug_ts'.
[20:35:29 CET] <kepstin> (or maybe the rtsp muxer handles it for you and it's fine)
[20:35:41 CET] <JEEB> klongwood3: I... just noted how it is written in the docs
[20:35:49 CET] <JEEB> thanks for ignoring what I write. it makes me feel real good
[20:35:50 CET] <klongwood3> kepstin i am transporting over TCP tho
[20:36:58 CET] <klongwood3> JEEB not trying to, same as I have no idea either. Just wanted to let you know what response I got from using (attempting) that option. '=D
[20:38:38 CET] <kepstin> yep, that's the result you get for using any option that doesn't exist, it's not really interesting&
[21:19:42 CET] <ncouloute> So I want to make sure I got this right. The "Read frame with in pts XXXX" The XXXX value is coming from where in the log? I thought it was off the concat line but those PTS numbers dont match. I was hoping to use those so I know where the file starts and ends. Seems to be taken from the stts: line. Here is the log in question: https://paste.ee/p/DjHxM
[21:42:22 CET] <kepstin> ncouloute: that log message is printed by the fps filter
[21:42:57 CET] <kepstin> (as you can see from the stuff in [] before the message)
[21:44:37 CET] <kepstin> there should be a concat log where the pts number after the "->" matches with the "read frame with in pts" log from the fps filter
[21:44:46 CET] <ncouloute> yeah mine doesnt match
[21:44:56 CET] <kepstin> these logs are not necessarilly going to be near to eachother
[21:46:11 CET] <kepstin> in your paste, the concat log on line 3513 matches with the fps log on line 3571 for example
[21:46:40 CET] <ncouloute> yeah but thats the audio strema.. the stream:1
[21:47:19 CET] <kepstin> no, that's the video. audio is stream 0
[21:48:15 CET] <kepstin> lookat lines 690-700
[21:48:20 CET] <kepstin> to see the stream mapping
[21:49:38 CET] <ncouloute> I always thought video was the first one hmm I guess not always the case =/
[21:52:50 CET] <ncouloute> I guess it depends on the file... is there any way to force ffmpeg to map the video stream to 0?
[21:53:03 CET] <kepstin> no, that's the input so it depends on the file it's reading
[21:53:20 CET] <ncouloute> As I would rather not have to parse that as well
[21:53:22 CET] <kepstin> you can check the stream order with ffprobe or something before you start
[21:53:32 CET] <kepstin> that at least has output designed to be machine-readable
[21:53:57 CET] <kepstin> as opposed to fragile human-readable debug logs with no stability guarantees :)
[21:54:50 CET] <kepstin> honestly, with the amount of effort you're putting into this log parsing thing, it probably makes sense to build an app using ffmpeg apis instead.
[21:58:52 CET] <ncouloute> I would love to use ffprobe if I could pass the same ffmpeg line to ffprobe get the start and stops of the concatenated file..No telling where the frames will end up unless you parse it as it goes along. I really should just learn the api then I can fix a lot of the issues I come across. I just dont understand how video works. I need to find some resouces for that
[22:01:53 CET] <kepstin> video is not really that complicated... as long as you're not dealing with interlaced stuff, video is basically a series of frames, each frame is a still image plus a timestamp that says when it should be displayed.
[22:02:02 CET] <kepstin> the rest is just implementation details ;)
[22:03:12 CET] <ncouloute> I will have to handle every type of video... I thought about using a frameserver like avisynth but that slows things down signficantly. Another benefit of the API I can use concat filter which handles funky files better since it doesnt try to concat them first. Concat filter doesnt have the nice logging of concat demuxer.
[22:03:34 CET] <bencc1> How can I capture with x11grab using constant framerate?
[22:03:57 CET] <bencc1> this is what I'm trying:
[22:03:59 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 cap.mkv
[22:04:14 CET] <kepstin> if you're writing an app using ffmpeg libraries, you can do the concatenation yourself at any stage, and know exactly what you're doing to the timestamps.
[22:05:05 CET] <kepstin> bencc1: x11grab do to its design can't do true constant framerate. (it works by repeatedly sleeping then asking for a frame)
[22:05:42 CET] <bencc1> kepstin: can I apply a filter in the same command to force constant frame rate?
[22:05:58 CET] <bencc1> or do I have to do another pass after the screen capture?
[22:06:39 CET] <ncouloute> yeah, I'll take another crack at the ffmpeg api then. Hopefully also it will tell me why it doesnt always make a cfr file on concat of cfr files.
[22:06:44 CET] <kepstin> yes, you can convert to constant framerate in one command, add a "-vf fps=30" or so. But note that it might drop or duplicate some frames to achieve the constant rate, meaning it could add some judder.
[22:07:14 CET] <kepstin> (of course, you might have some judder from the x11grab in the first place)
[22:08:02 CET] <klongwood3> JEEB: do you still have any other recommendations?
[22:12:30 CET] <bencc1> kepstin: I've tried adding "-vf fps=30" but "ffmpeg -i cap.mkv -vf vfrdet -f null -" show that I don't get constant framerate
[22:13:04 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.mkv
[22:13:57 CET] <kepstin> mkv has a fixed timebase of 1/1000, so due to rounding errors a lot of files show up as vfr even if they're not really.
[22:14:33 CET] <kepstin> the vfrdet filter should show a fairly small difference between min and max delta (should be a difference of 1 ideally)
[22:19:18 CET] <bencc1> kepstin: got disconnected
[22:19:34 CET] <bencc1> checking if "-vf fps=30" really give 1 error
[22:20:23 CET] <kepstin> you could alternatively use a container which supports different timebases; try nut for example instead of mkv.
[22:26:08 CET] <bencc1> kepstin: checked the mkv - [Parsed_vfrdet_0 @ 00000000005eee40] VFR:0.667752 (615/306) min: 12 max: 55 avg: 33
[22:26:32 CET] <bencc1> with the command above so for some reason "-vf fps=30" doesn't help
[22:26:35 CET] <bencc1> I'll try nut
[22:27:09 CET] <bencc1> I'm also getting many: [null @ 0000000000583f80] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1138528 >= 1138512
[22:37:54 CET] <bencc1> kepstin: nut gives me: [Parsed_vfrdet_0 @ 0000000002a7b500] VFR:0.001408 (1/709) min: 2048 max: 8192 avg: 8192
[22:38:23 CET] <bencc1> and during the capture I'm getting an error: [nut @ 0x565055677a20] read_timestamp failed. Last message repeated 4 times
[22:42:33 CET] <bencc1> kepstin: when converting the .nut to .mp4 I'm getting "VFR:0.000000 (0/937)" so it seems to work
[22:42:35 CET] <bencc1> thanks :)
[22:43:11 CET] <bencc1> I'll test on a longer capture now
[22:56:40 CET] <bencc1> kepstin:  do I need to add "-vsync cfr" and/or "-enc_time_base 1/1000"
[22:56:41 CET] <bencc1> ?
[23:50:20 CET] <bencc1> when using nut I'm getting an error: [nut @ 0x55acde247a20] EOF before video frames
[23:50:29 CET] <bencc1> what could be the reason?
[23:53:21 CET] <bencc1> kepstin: thanks. I'll add log and paste it
[00:00:00 CET] --- Wed Dec 11 2019