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

[burek]

[03:11:59 CEST] <fling> How do I save all the incoming ffserver streams to files?
[03:17:02 CEST] <fling> updated util-linux and segfault gode
[03:17:09 CEST] <fling> s/gode/gone/
[03:17:18 CEST] <fling> But how do I check all the binaries for segfaults?
[03:17:31 CEST] <fling> D'oh! wrong channel :P
[03:57:55 CEST] <fling> So can't I save different streams to different files specifying the stream start date as a filename?
[06:27:14 CEST] <fling> Lookl like I could run ffmpeg in a loop for this&
[07:28:30 CEST] <hero_biz> hi guys
[07:29:07 CEST] <hero_biz> guys,i'm trying to encode 2 audio tracks of a mkv file and make 2 one output per track.
[07:29:28 CEST] <hero_biz> i used this command:
[07:29:41 CEST] <hero_biz> ffmpeg -i a.mkv -map 0:a -c:a:0 libfdk_aac -b:a:0 48k audio1.aac -c:a:1 libfdk_aac -b:a:1 48k audio2.aac
[07:30:00 CEST] <hero_biz> but it seems it does not work correctly, because first I get this warning:
[07:30:15 CEST] <hero_biz> "Codec AVOption b (set bitrate (in bits/s)) specified for output file #1 (audio2.aac) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any stream."
[07:30:33 CEST] <hero_biz> and second this is shows at end of encode for stream mapping:
[07:31:17 CEST] <hero_biz> "Stream mapping:  Stream #0:1 -> #0:0 (ac3 (native) -> aac (libfdk_aac))   Stream #0:2 -> #0:1 (ac3 (native) -> aac (native))   Stream #0:1 -> #1:0 (ac3 (native) -> aac (native))"
[07:31:42 CEST] <hero_biz> any idea what I have done incorrectly?
[07:32:42 CEST] <relaxed> ffmpeg -i a.mkv -map 0:a:0 -c:a:0 libfdk_aac -b:a:0 48k audio1.aac -map 0:a:1 -c:a:1 libfdk_aac -b:a:1 48k audio2.aac
[07:34:36 CEST] <hero_biz> relaxed: ty,now streams are ok, but encoding not:
[07:34:51 CEST] <hero_biz> "Stream mapping:   Stream #0:1 -> #0:0 (ac3 (native) -> aac (libfdk_aac))   Stream #0:2 -> #1:0 (ac3 (native) -> aac (native))"
[07:36:26 CEST] <hero_biz> aha corrected it myself,ty help :)
[07:36:43 CEST] <hero_biz> needed to use 0 for 2nd track encoders too:
[07:36:56 CEST] <hero_biz>  ffmpeg -i a.mkv -map 0:a:0 -c:a:0 libfdk_aac -b:a:0 48k audio1.aac -map 0:a:1 -c:a:0 libfdk_aac -b:a:0 48k audio2.aac
[07:40:50 CEST] <relaxed> right, in this case you could just use -c and -b
[07:41:45 CEST] <CoJaBo> I like how ffmpeg will quite happily create a 2×1080 output file, and default to 16:9 display aspect ratio for it
[07:42:34 CEST] <furq> only if your input file has the dar set to 16:9
[07:43:33 CEST] <CoJaBo> Took a stupid long while to figure out what happened >_>
[07:43:48 CEST] <CoJaBo> I thought the playback app was broken :/
[07:45:18 CEST] <CoJaBo> Looks hella tippy tho
[07:46:41 CEST] <CoJaBo> ..trippy
[10:00:01 CEST] <Accord> hey, anyone know why screen capture doesn't work in windows 10?
[10:00:21 CEST] <Accord> [dshow @ 03b67700] Could not find video device with name [screen-capture-recorder] among source devices of type video.
[10:00:21 CEST] <Accord> video=screen-capture-recorder: I/O error
[10:28:10 CEST] <furq> Accord: https://github.com/rdp/screen-capture-recorder-to-video-windows-free
[10:40:13 CEST] <Accord> furq, that seems to be using the ffmpeg command I am
[10:40:40 CEST] <furq> that is the screen-capture-recorder device
[10:40:59 CEST] <Accord> huh
[10:41:13 CEST] <Accord> didn't need it on windows 8
[10:42:04 CEST] <furq> are you sure you weren't using gdigrab
[10:42:15 CEST] <Accord> yep
[10:42:21 CEST] <Accord> will try this now, thanks
[10:44:24 CEST] <Accord> seems to work, thanks again :)
[10:46:37 CEST] <Accord> though i do get a lot of [dshow @ 0311b640] real-time buffer [screen-capture-recorder] [video input] too full or near too full (545% of size: 3041280 [rtbufsize parameter])! frame dropped!
[11:05:21 CEST] <c_14> Try increasing the -rtbufsize option
[11:15:18 CEST] <Accord> c_14, how much should i set it? i tried 6x 3041280 as said in the error but i still get it
[15:11:41 CEST] <termos> Hi I'm resampling my audio from 48khz to 44.1khz and it's fine, but 48khz to 22.05khz causes my audio to play in slow motion. Is there something special I need to be able to resample this far?
[15:12:56 CEST] <termos> Oh I might have found it
[15:29:03 CEST] <DHE> sounds like you didn't resample it, but simply replaced the sample rate value
[15:47:20 CEST] <BtbN> Anyone ever tried to play a 5.1 or mono, or rather, non 2 channel stereo, file in Spotify?
[15:47:52 CEST] <BtbN> They hard-coded it to two channels apparently, so when playing 5.1, it plays the interleaved samples like it was stereo.
[15:48:51 CEST] <DHE> like, skipping through the various channel samples?
[15:55:47 CEST] <mantas322> Hi guys
[16:11:51 CEST] <ntz_> hello
[16:12:40 CEST] <ntz_> can anybody please help me with capturing my screen ? it worked for me in past, I've googled out several commands for that but it has only black screen now ...
[16:12:52 CEST] <ntz_> I have opensuse with x11
[16:15:13 CEST] <c_14> ffmpeg -f x11grab -i :0 out.mkv ?
[16:17:01 CEST] <ntz_> c_14: http://susepaste.org/view/raw/21759184
[16:17:09 CEST] <ntz_> yeah, that's basically how it worked before
[16:18:08 CEST] <c_14> I'm pretty sure the problem's just that your version of mplayer doesn't support 444p vp9
[16:18:16 CEST] <c_14> try with ffplay
[16:18:25 CEST] <c_14> or use a different codec (like ffv1)
[16:18:29 CEST] <c_14> or mpv/vlc
[16:18:45 CEST] <c_14> Also, you don't want to use vp9 for screan recording
[16:18:48 CEST] <c_14> It'll be too slow
[16:19:00 CEST] <c_14> According to the output you're recording at half-realtime
[16:19:12 CEST] <ntz_> o.O
[16:19:25 CEST] <ntz_> c_14: is mplayer involved in that when I do it with ffmpeg ?
[16:19:34 CEST] <c_14> no
[16:19:50 CEST] <ntz_> oh, for playback
[16:20:25 CEST] <ntz_> gotcha ... weird since my mplayer simply plays/played anything - even videos that vlc has problem with - I considerf mplayer as the most reliable player for years
[16:20:55 CEST] <bencoh> using almost exclusively mplayer here, but ... I wouldn't call it "most reliable player" :)
[16:21:13 CEST] <bencoh> (even if I'm still a huge fan)
[16:21:20 CEST] <ntz_> anyhow, I still suspect a ffmpeg not capturing my screen properly
[16:21:33 CEST] <ntz_> btw https://trac.ffmpeg.org/wiki/Capture/Desktop
[16:21:38 CEST] <c_14> ntz_: use a different codec
[16:21:54 CEST] <ntz_> this results in black screen
[16:21:56 CEST] <c_14> like -c:v utvideo or -c:v mpeg4 or -c:v ffv1
[16:22:05 CEST] <ntz_> ok
[16:22:23 CEST] <c_14> or switch the output pixel format -pix_fmt yuv420p
[16:23:01 CEST] <ntz_> I tried this `ffmpeg -f x11grab -i $DISPLAY -c:v mpeg4 x11_out.mkv'' still black screen, perhaps I have broken teh x11grab part ?
[16:23:30 CEST] <ntz_> ^^ surely, shall not be .mkv but doesn't matter, it's just a filename
[16:24:35 CEST] <ntz_> http://susepaste.org/view/raw/87428127
[16:24:41 CEST] <ntz_> ^^ is this helpful in any way ?
[16:24:49 CEST] <c_14> avfoundation won't work
[16:24:52 CEST] <c_14> that's osx only
[16:25:22 CEST] <ntz_> I was attracted by that -list_devices
[16:25:32 CEST] <ntz_> which spits error message in linux
[16:27:07 CEST] <c_14> if you try `ffmpeg -f x11grab -i $DISPLAY out.gif' does that produce output you can view?
[16:29:09 CEST] <ntz_> c_14: it creates 9KB big gif that seems just empty
[16:29:21 CEST] <ntz_> after say 5 seconds of capturing
[16:29:42 CEST] <ntz_> http://susepaste.org/view/raw/22681952
[16:30:10 CEST] <c_14> Is the top left-corner of your monitor black by any chance?
[16:30:34 CEST] <ntz_> wait, I was stopping that always with ctrl+c, now I see it says `q' to quit
[16:30:45 CEST] <c_14> they do the same thing
[16:31:58 CEST] <ntz_> pff, no difference .. maybe one more point, I have two displays: http://susepaste.org/view/raw/2414989
[16:32:34 CEST] <c_14> It'll always record offsetted on the top leftest corner
[16:33:13 CEST] <c_14> 14:30 <c_14> Is the top left-corner of your monitor black by any chance?
[16:33:26 CEST] <ntz_> I'm afraid that something broke because I was able to record my screen with ffmpeg completely fine ... past == few years ago when things weren't so complicated
[16:33:46 CEST] <ntz_> c_14: I can show ya, second please:
[16:36:34 CEST] <ntz_> c_14: http://susepaste.org/view/raw/90700736
[16:36:38 CEST] <ntz_> this is my screen
[16:37:14 CEST] <ntz_> X does create some virtual size of the screen so maybe yes, I have from the POV of ffmpeg some parts of my 2800 x 1920 screen black
[16:38:34 CEST] <c_14> try -i :0+1600 maybe
[16:40:08 CEST] <ntz_> c_14: wou, that did something
[16:40:27 CEST] <ntz_> c_14: thanks !!!! I think you've pointed me to the right direction
[16:40:51 CEST] <c_14> So it looks like you just need to push the window out of that giant black space to wherever you want.
[16:42:33 CEST] <ntz_> c_14: ffmpeg -f x11grab -i $DISPLAY+1600 -framerate 25 -video_size 1024x768 x11_out.mp4
[16:42:38 CEST] <ntz_> good, now it works ^^^
[16:42:53 CEST] <c_14> both -framerate and -video_size should be in front of -i
[16:43:03 CEST] <ntz_> ofc it doesn't record what I wanted but this finally produces a video file with section of my screen
[16:46:06 CEST] <ntz_> c_14: PERFECT, thanks much .... this works as I needed `ffmpeg -f x11grab -framerate 25 -video_size 1200x1920 -i $DISPLAY+1600 x11_out.mp4', however as in result, ffmpeg recording my screen devours all my cpu resources (I have i5 laptop) and the video is a bit blurred
[16:46:31 CEST] <ntz_> so I guess it's just the matter of some other opts like to use more light-weight codec or such like
[16:46:47 CEST] <c_14> try using -c:v libx264 -preset faster or something
[16:46:55 CEST] <c_14> Or record with a lossless codec first and reencode later
[16:47:24 CEST] <ntz_> Unknown decoder 'libx264'
[16:47:30 CEST] <c_14> after -i
[16:47:30 CEST] <ntz_> but that's no-issue :)
[16:47:36 CEST] <ntz_> ok
[16:47:47 CEST] <c_14> options that affect the input go before -i options that affect the output go after it
[16:48:54 CEST] <ntz_> ok, memorizing it
[16:49:33 CEST] <ntz_> c_14: thanks much for help .... I think that now it's up to me to read the man, google out and find out what codec shall be optimal according to performance of my laptop and available codecs here in suse
[16:49:43 CEST] <ntz_> c_14++
[16:50:04 CEST] <ntz_> because now it definitelly works
[16:50:12 CEST] <ntz_> however a bit blurred
[16:54:06 CEST] <ntz_> c_14: may I ask one additional question ? I have here teh dual gfx laptop, there's intel i915 gfx chip and nvidia chip that I have completely disabled ... does ffmpeg use at some extend some gfx hw accel ?
[16:54:44 CEST] <ntz_> for instance can I use vdpau for better performance while capturing a screen using ffmpeg ?
[16:54:51 CEST] <ntz_> ^^ in the case of nvidia
[16:54:58 CEST] <c_14> not unless you explicitly tell it to
[16:55:17 CEST] <ntz_> ok
[16:55:34 CEST] <ntz_> but generally said, it's done in cpu, right ? so i915 is not ptoblem ?
[16:55:39 CEST] <c_14> vdpau is only for decoding, if you have nvenc support you can use that for encoding if you don't have the cpu to encode otherwise (but x264 --preset ultrafast is usually better)
[16:55:49 CEST] <c_14> It's usually done on the cpu, yes
[16:58:27 CEST] <ntz_> the performance here with relatively recent cpu is tragic :( ... just trainwreck
[16:58:41 CEST] <c_14> that still vp9?
[16:58:43 CEST] <ntz_> model name      : Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
[16:58:47 CEST] <c_14> vp9 is really slow
[16:58:49 CEST] <c_14> that's expected
[16:58:56 CEST] <c_14> well, libvpx is really slow
[16:58:56 CEST] <ntz_> ok
[16:59:44 CEST] <ntz_> I'd try with looseless codec
[17:04:35 CEST] <ntz_> c_14: ffmpeg -f x11grab -framerate 25 -video_size 1600x900 -i $DISPLAY+0,1020 -c:v libx264 -qp 0 -preset ultrafast x11_out.mp4
[17:04:46 CEST] <ntz_> ^^ I dare to say that this works perfect !!!!!
[17:04:59 CEST] <ntz_> THANKS MAN !!!
[17:05:29 CEST] <ntz_> not blurred with acceptable performance (ofc it eats some cpu but not that bad with looseless codec)
[17:05:41 CEST] <kepstin> if you're doing screen capture, you might consider using 'libx264rgb' instead of 'libx264', that avoids a colorspace conversion.
[17:05:53 CEST] <ntz_> thanks for point
[17:09:30 CEST] <ntz_> http://www.starenka.net/ntz/x11_out.mp4
[17:09:33 CEST] <ntz_> gooood
[17:09:47 CEST] <ntz_> kepstin: libx264rgb doesn't work .... it just shows first frame
[17:09:52 CEST] <ntz_> but nothing more
[17:10:04 CEST] <ntz_> again, thanks much channel for your help !!!!!
[17:12:28 CEST] <ntz_> last question .... which codec shall be considered as the least cpu intensive (loseless is fine) ?
[17:12:48 CEST] <c_14> rawvideo
[17:12:53 CEST] <c_14> that'll murder your hdd though
[17:13:18 CEST] <c_14> other than that, either libx264 on ultrafast or ffv1 or utvideo maybe
[17:13:31 CEST] <ntz_> fairt
[17:13:36 CEST] <ntz_> s/t$//
[17:15:13 CEST] <kepstin> somewhere inbetween rawvideo and ffv1 is ffvhuff, which is really fast but only moderately smaller than raw.
[17:18:06 CEST] <ntz_> to be honest I don't catch why it's so big :D ... well, there are protocols like vnc and rdp (and forexample tw allows you share the screen over the network with rather low bandwidth)
[17:18:31 CEST] <ntz_> it just seems that once I want it save to a disk it starts to be big
[17:18:43 CEST] <c_14> you can make it real small really easily
[17:18:49 CEST] <c_14> just use a largish crf on libx264
[17:18:56 CEST] <viric> libx264 can do also lossless
[17:18:59 CEST] <c_14> something like 25 should be fine
[17:19:10 CEST] <c_14> As soon as you go lossless you go big
[17:20:14 CEST] <kepstin> ntz_: stuff like vnc and rdp are very far from lossless, they tend to do things like send only partial updates, reduce colors, and use jpeg or even lossy video codecs on complex or rapidly changing screen sections.
[17:20:35 CEST] <viric> partial updates can be lossless
[17:21:14 CEST] <kepstin> hmm, true. But (aside from x264, to a limited extent - and I dunno about utvideo) most lossless video codecs tend to be intra-only.
[17:21:37 CEST] <kepstin> since they're designed as digital intermediate formats for editing.
[17:22:28 CEST] <ntz_> hmm
[17:23:26 CEST] <kepstin> hmm. an i5-2520M? I forget how capable the qsv encoder is on that chip line, if it's even present.
[17:23:53 CEST] <ntz_> well, this cpu shall be some mid range in mobile cpus
[17:24:14 CEST] <ntz_> but I don't feel that's enough powerful
[17:25:04 CEST] <kepstin> that's not really related, the quicksync encoder is a fixed-function gpu block. which should be present and capable of doing h264 on your cpu.
[17:25:31 CEST] <kepstin> if it works (e.g. via vaapi), that might be a reasonable way to get a realtime low-cpu encode at not-quite-lossless.
[17:26:40 CEST] <ntz_> btw http://susepaste.org/view/raw/48373111
[17:26:48 CEST] <ntz_> I guess this seems all correct, right ?
[17:26:55 CEST] <ntz_> I mean how it is built ...
[17:27:07 CEST] <jkqxz> Sandy Bridge Quick Sync H.264 encode quality isn't so good, but it will be fine at high bitrates.  VAAPI should work; I think libmfx won't because they dropped support for the older models.
[18:18:36 CEST] <pikajude> can I add multiple .srt files to a .mp4 (not burning in)?
[18:21:55 CEST] <IntelRNG> YOu can do it in mkv, I guess you could for mp3
[18:21:59 CEST] <IntelRNG> mp4*
[18:22:01 CEST] Action: IntelRNG checks
[18:24:03 CEST] <IntelRNG> I think srts are not supported without conversion btw
[18:24:36 CEST] <pikajude> i'm fine with conversion, i just want to put multiple sub tracks into a .mp4
[18:24:40 CEST] <pikajude> because i want to import it into itunes
[18:26:27 CEST] <IntelRNG> Does itunes support mkv? Just curious.
[18:33:22 CEST] <pikajude> i seriously doubt it
[18:33:59 CEST] <pikajude> i gave it a .mkv file and it seemed to do nothing
[18:34:01 CEST] <pikajude> so I guess that's the answer
[18:35:27 CEST] <pikajude> i figured out how to do it, btw
[18:36:12 CEST] <pikajude> turns out you just have to put -i foo.srt for all the subtitles
[18:39:10 CEST] <pikajude> and then -map them all
[21:42:12 CEST] <monoflo> Hi! I followed a tutorial on how to create video files in C# frame-by-frame (http://en.code-bude.net/2013/04/17/how-to-create-video-files-in-c-from-single-images/). I was able to get everything to work but I would now like to change codecs to H264 and configure some keyframe settings, neither of which I know how to do.
[21:43:37 CEST] <monoflo> I downloaded a .NET Framework that included ffmpeg, and through a .dll I have access to an enum of Video Codecs which does not include H264
[21:45:43 CEST] <monoflo> Would someone here  happen to be familiar with AForge Video and be able to give me a hand?
[21:53:31 CEST] <Accord> monoflo, your best bet might be checking out the C examples and try to translate that to whatever libs you're using
[21:55:37 CEST] <FishPencil> Is it possible to decode raw H.264 data, if the stream doesn't contain any header or container information?
[21:55:38 CEST] <monoflo> Where can I find those?
[21:56:12 CEST] <JEEB> FishPencil: what do you consider a header?
[21:56:27 CEST] <FishPencil> JEEB: An RTMP header for example
[21:56:50 CEST] <JEEB> AVC can be either in AVCc or Annex B. Annex B is basically in-band so as long as you get valid Annex B packets you should be able to decode it
[21:57:52 CEST] <monoflo> Accord: Think I found them. Thanks
[22:06:20 CEST] <FishPencil> JEEB: Correction: it's an f4v with an AAC stream and H.264. It's currently only seeing the AAC stream, and ffprobe is spitting errors with it
[22:14:08 CEST] <Danimal> I'm using gdigrab and virtual-audio-capturer, and my video is falling behind the audio. is there a way to enforce sync?
[22:41:43 CEST] <Danimal> ugh. bit it's intermittent. this is hte worst
[22:43:40 CEST] <furq> would it not be better to use screen-capture-recorder
[22:48:39 CEST] <Danimal> mmmm, I had a reason why i wasn't using that one. but can't remember what it was. why would that be better?
[22:50:10 CEST] <furq> i would assume it works better with virtual-audio-capturer considering they're both written by the same guy
[22:50:16 CEST] <furq> but also gdigrab is pretty slow
[22:53:43 CEST] <Danimal> okie, well that makes sense, I could give it a try. driving me batty that I can't reliably reproduce the issue though. Only seen it once.
[22:54:01 CEST] <Danimal> but it showed up within a minute of starting it up
[22:55:15 CEST] <Danimal> here's a command line. "C:/Program Files/ffmpeg/bin/ffmpeg.exe" -fflags genpts -f gdigrab -framerate 30 -draw_mouse 0 -i desktop -itsoffset 00:00:00.08 -f dshow -i audio="virtual-audio-capturer" -r 30 -c:v libx264 -preset veryfast -b:v 12000000   -bufsize 24000000 -muxrate 17069000 -crf 23    -c:a libvo_aacenc -b:a 192000 -ac 2 -ar 48000 -pix_fmt yuv420p -vf "scale=1280:720" -g 100 -keyint_min 100 -sc_threshold 0 -async 1 -f mpegts -flus
[22:55:44 CEST] <Danimal> I'll give screen capture recorder a try
[23:21:30 CEST] <kepstin> gdigrab being slow shouldn't affect sync, but the fact that it's using a different timing source from the audio might :/
[23:22:09 CEST] <kepstin> (gdigrab uses pc realtime clock as timing source, while audio is probably timed on the sound card I guess)
[00:00:00 CEST] --- Fri Jul  8 2016