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

[burek]

[00:02:24 CET] <Elec_A> DHE: yes! Thank you!
[00:02:32 CET] <Elec_A> using framrate solved it
[00:03:04 CET] <furq> weird
[00:03:10 CET] <furq> i thought -r was mapped to -framerate there
[00:06:44 CET] <DHE> no, but I would have thought that overriding the incoming framerate would be functionally identical anyway
[00:07:28 CET] <DHE> unless I'm woefully misunderstanding what -r does on an input
[11:56:46 CET] <th3_v0ice> Hello all. I have one question regarding the decoder context. When we open a file with avformat_open_input followed by avformat_find_stream_info, should we create a new decoder context with avcodec_alloc_context3(input_stream->codecpar->codecid), or should we use the input_stream->codec as a decoder context?
[15:25:36 CET] <sunslider> hi guys, can I force ffmpeg to flush buffer to the output file? right now it writes the buffer only when I close it..
[15:25:45 CET] <sunslider> and I'm using it to stream
[17:03:44 CET] <zalaare> How do I tell ffmpeg to simply ignore the pgs_subtitle stream during a video copy?  It seems it always wants to do /something/ with it and fails because afaik pgs_subtitles still cannot be -c copy. [-ss 00:00:00.0 -map 0:v:0 -map 0:a:0 -map -0:sn -c copy -t 00:00:30.0]
[17:05:55 CET] <kepstin> zalaare: if you just don't map the subtitles, they won't get copied
[17:06:21 CET] <kepstin> zalaare: you should have only "-map 0:v:0 -map 0:a:0" in your command.
[17:06:43 CET] <kepstin> zalaare: note that "-map -0:sn" is not correct syntax, I have no idea what that would do
[17:07:25 CET] <zalaare> @kepstin: I snagged that from google search.  Supposedly disable default copy all, and ignore subtitles
[17:07:39 CET] <klaxa> that's -sn though not -map 0:sn
[17:07:52 CET] <zalaare> well it still doesn't work :(
[17:08:01 CET] <kepstin> zalaare: have to see your full command line
[17:08:24 CET] <kepstin> zalaare: if you map only video and audio, then subtitles would not be copied, so you must have a different problem
[17:08:48 CET] <zalaare> [code]ffmpeg -hide_banner -loglevel info -nostats -i "/tmp/Charade/Charade.Bluray-1080p.(1963).mkv" -ss 00:00:00.0 -map 0:v:0 -map 0:a:0 -c copy -t 00:00:30.0 -y "/tmp/Charade/Charade.Blur ay-1080p.(1963).tmp.mkv"[/code]
[17:09:09 CET] <zalaare> error: [matroska,webm @ 0x55dc6db88d80] Unsupported encoding typeCould not find codec parameters for stream 3 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options
[17:09:34 CET] <sfan5> add -sn before the -c copy
[17:09:55 CET] <sfan5> also -ss 0 should not be necessary
[17:09:57 CET] <zalaare> @sfan5 same
[17:10:07 CET] <kepstin> adding -sn shouldn't do anything, the subtitle track isn't mapped already
[17:10:16 CET] <sfan5> right
[17:10:21 CET] <sfan5> then it's having a problem with your input file
[17:10:24 CET] <kepstin> zalaare: can you share the *complete* output on a pastebin site?
[17:10:30 CET] <zalaare> sure
[17:11:38 CET] <th3_v0ice> Is that space in the output file name intentional?
[17:11:49 CET] <sfan5> so your options are either increasing analyzeduration / probesize until ffmpeg is happy OR removing the subtitle tracks first by remuxing using mkvmerge
[17:12:32 CET] <zalaare> https://pastebin.com/raw/igh9jVay
[17:13:00 CET] <zalaare> @th3_voice: copy-paste issue.
[17:13:04 CET] <kepstin> zalaare: that worked perfectly fine according to the output...
[17:13:15 CET] <kepstin> it copied the non-sub tracks and made you a 30s video file
[17:13:18 CET] <zalaare> it did? lol
[17:13:51 CET] <zalaare> Yup it did.  You're absolutely right.  It went so fast I assumed it borked.
[17:14:29 CET] <zalaare>  /slaps himself
[17:14:32 CET] <kepstin> well, copy is fast, and 30s is very small, so i'd expect it to be nearly instant yeah
[17:57:03 CET] <trg> Hi all, I'm using ffmpeg to create a video with audio from x11grab and alsa and experiencing a few performance issues. Wondering if anybody could give me a sanity check to see if there's anything I could be doing better, as I'm a novice ffmpeg user
[17:57:23 CET] <trg> Here's the command I'm using:
[17:57:31 CET] <trg> ffmpeg -y -video_size 1920x1080 -framerate 25 -f x11grab -draw_mouse 0 -thread_queue_size 512 -i :99 -f alsa -acodec pcm_s32le -thread_queue_size 1024 -ac 2 -i hw:Loopback,1,0 -c:v libx264 -crf 0 -preset ultrafast /home/vagrant/output.mp4
[17:59:46 CET] <pomaranc> you do realize crf 0 is lossless, right?
[17:59:54 CET] <relaxed> trg: -thread_queue_size 512 and -acodec pcm_s32le -thread_queue_size 1024 -ac 2 go after -i hw:Loopback,1,0
[18:00:19 CET] <relaxed> unless -thread* is some demuxer option
[18:00:21 CET] <trg> yes, as I understand from what I've read, the lossless option will give me a much larger file, but tax the cpu less while the recording is happening
[18:00:25 CET] <furq> thread_queue_size is an input option
[18:00:31 CET] <furq> although you're defining it twice for the same input
[18:00:52 CET] <furq> fyi the warning you get about thread_queue_size being too low is usually meaningless
[18:01:18 CET] <relaxed> instead of -ac 2 you want -channels 2
[18:01:18 CET] <furq> also i don't think lossless is less taxing on the cpu
[18:01:20 CET] <trg> ah good to know, thanks
[18:01:32 CET] <furq> generally with x264 lower crf gives worse performance
[18:01:47 CET] <furq> lossless is a special case though so maybe that's different
[18:02:17 CET] <furq> also (again) mp4 is not suitable for live recording
[18:02:25 CET] <furq> if the recording gets interrupted you'll end up with an unplayable file
[18:02:36 CET] <trg> I got the lossless idea from here, not sure if I interpreted incorrectly -- https://trac.ffmpeg.org/wiki/Capture/Desktop#LosslessRecording
[18:02:44 CET] <furq> use mkv or something that can tolerate being interrupted and then remux it if you need an mp4
[18:03:05 CET] <trg> ah great, didn't know that. thank you --
[18:04:22 CET] <furq> i just did a quick benchmark and crf 20 is faster than crf 0
[18:05:26 CET] <furq> actually nvm they're about the same with preset ultrafast
[18:10:50 CET] <Fenrirthviti> furq: you'd be correct on anything but ultrafast
[18:11:30 CET] <furq> that sounds plausible
[18:14:44 CET] <kepstin> ultrafast disables cabac, right? and that's one of the big things that slows the encoder down as the bitrate gets higher
[18:22:40 CET] <Fenrirthviti> it disables many things, including my happiness.
[18:37:45 CET] <ddubya> why would QFile::rename() fail with permission denied, if the file and directory permissions are 660, 770, UID is creator
[18:38:27 CET] <ddubya> oh and destination file doesn't exist too
[18:41:11 CET] <klaxa> directory permission -x means not accessible
[18:41:32 CET] <klaxa> to be able to enter a directory it needs +x
[18:41:45 CET] <klaxa> oh wait
[18:41:49 CET] <klaxa> nevermind me it is +x
[18:43:12 CET] <trg> thanks furq & relaxed -- switching to mkv made a huge difference.
[18:43:51 CET] <furq> mkv shouldn't have actually made any performance difference
[18:44:02 CET] <furq> unless you weren't setting the audio codec
[18:46:23 CET] <trg> hmm, let me switch some stuff back and double check
[18:50:57 CET] <ddubya> oops wrong channel
[19:19:18 CET] <trg> all right, earlier I hadn't isolated enough variables in thinking the .mp4 output was performing worse. now i've run identical commands on identical VMs, with only the output format changed, and .mp4 is consistently about 10 frames per second better than the .mkv output. odd.
[19:21:37 CET] <trg> it's possible the issue is with my environment and not ffmpeg usage. i'll keep investigating
[20:08:54 CET] <Fenrirthviti> This might be a dumb question, but what's the difference between avfilter-6 and avfilter-7? Just version?
[20:09:28 CET] <durandal_1707> no
[20:11:07 CET] <Fenrirthviti> Anywhere I can see the differences? Or is there a quick description?
[20:11:52 CET] <sfan5> the Changelog probably
[20:12:56 CET] <Fenrirthviti> well if it's not a version difference, then I'm not sure where I'd find that
[20:13:48 CET] <Fenrirthviti> which is what I was asking to begin with, if avfilter-7 is a newer version of avfilter-6
[20:14:01 CET] <Fenrirthviti> or if they're fundamentally used for different things.
[20:14:33 CET] <sfan5> "avfilter-7 is a newer version of avfilter-6" is weird way of putting it, but correct
[20:14:43 CET] <Fenrirthviti> well that's why I'm asking for clarification here
[20:14:45 CET] <Fenrirthviti> because I don't understand.
[20:14:59 CET] <Fenrirthviti> Sorry for wasting your time.
[20:15:22 CET] <sfan5> avfilter-6 is the avfilter library with major version 6, avfilter-7 is the one with major version 7
[20:16:18 CET] <Fenrirthviti> ok, thanks.
[20:16:55 CET] <sfan5> if you'd like to see what changed, you would need to read the changelog between 5th Sep 2015 and 21th Oct 2017
[20:17:36 CET] <sfan5> you can track changes much better by comparing ffmpeg version numbers though
[20:21:21 CET] <Fenrirthviti> gotcha, looking for major api breakages mostly
[20:21:32 CET] <Fenrirthviti> or if avfilter-7 could be a drop-in replacement for -6
[20:21:49 CET] <Fenrirthviti> but given that it's major version increase, seems unlikely.
[20:26:22 CET] <sfan5> usually it's just some APIs there were deprecated
[23:48:15 CET] <kepstin> Fenrirthviti: the two libraries will not be binary-compatible, but if you can recompile your code against the newer ffmpeg without errors, then you can use the new lib.
[23:48:54 CET] <Fenrirthviti> this context would be the shared link .dll files
[23:50:34 CET] <kepstin> if you compile your code against an ffmpeg that builds avfilter-7, then you link to avfilter-7. if you compile your code against an ffmpeg that builds avfilter-6, then you link to avfilter-6.
[23:53:56 CET] <Fenrirthviti> makes sense
[00:00:00 CET] --- Tue Feb 20 2018