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

[burek]

[00:31:37 CET] <kingsley> How would you test if libavcodec57 supoprts acodec=vorbis?
[00:34:59 CET] <DHE> avcodec_find_{en,de}coder_by_name("vorbis");
[00:40:03 CET] <kingsley> DHE: Please elaborate.
[00:40:36 CET] <DHE> you are asking about the C API, right?
[00:40:55 CET] <kingsley> Oh
[00:41:23 CET] <kingsley> Maybe I owe an apology for being terse and vague.
[00:42:12 CET] <kingsley> I'd prefer to use the command line, or possibly just read.
[00:42:28 CET] <kingsley> ffmpeg's documentation says to use acodec=libvorbis.
[00:42:54 CET] <kingsley> But maybe acodec=vorbis works too.
[00:43:29 CET] <DHE> $ ffmpeg -codecs | grep vorbis    # or something like that
[00:43:38 CET] <kingsley> The later is what kdenlive passes to melt which gives /usr/lib/i386-linux-gnu/libavcodec.so.57 a segmentation fault.
[00:44:20 CET] <kingsley> DHE: Thanks.
[00:46:03 CET] <kingsley> It reports...
[00:46:06 CET] <kingsley> DEA.L. vorbis               Vorbis (decoders: vorbis libvorbis ) (encoders: vorbis libvorbis )
[00:46:33 CET] <DHE> good. so you have full vorbis support
[01:07:18 CET] <kingsley> DHE: Yeah, in theory.
[01:08:46 CET] <kingsley> But, at least for me, acodec=vorbis crashes /usr/lib/i386-linux-gnu/libavcodec.so.57 crashes with a seg fault, but acodec=libvorbis does not.
[01:09:48 CET] <kingsley> I'm downloading a so called "AppImage" of kdenlive now. Evidently it works. I'll try to test it.
[01:09:50 CET] <furq> not that it's a solution, but the builtin vorbis encoder is terrible anyway
[01:10:03 CET] <furq> assuming you can actually change what kdenlive wants to use
[01:10:41 CET] <kingsley> furq: For what it's worth, I found I could work around the bug by
[01:10:54 CET] <kingsley> a.) rendering to the .mkv format, and then
[01:11:12 CET] <kingsley> b.) using ffmpeg to convert that to .webm.
[01:11:41 CET] <kingsley> But, I'd like to fix the bug.
[01:29:09 CET] <kepstin> hmm. if you disable the internal vorbis encoder at buildtime, will it use libvorbis if you request "vorbis"?
[01:29:23 CET] <kepstin> or just error out?
[01:33:33 CET] <DHE> I'm wondering if you have some kind of ABI error. surprised it crashes otherwise
[01:46:04 CET] <kingsley> kepstin and DHE: Sorry guys.
[01:46:12 CET] <kingsley> I gotta go for a while.
[01:46:26 CET] <kingsley> However, much like California's might ex gubernator...
[01:46:38 CET] <kingsley> U'll be bok
[01:50:55 CET] <kingsley> kepstin and DHE: Feel free to type any thoughts you may happen to have  on how I might test the ABI theory.
[01:51:37 CET] <kingsley> I might be OK with trying to disable the internal vorbis encoder too, if it can be done at run time.
[01:52:06 CET] <kingsley> I should be able to see your thoughts when I return.
[01:52:08 CET] <kingsley> So
[03:48:27 CET] <gp5st> hello. I'm sorry if I'm being dense with the docs. My root issue is that i'm trying to encode 192x1080 at 60fps and I constantly have the video drop a lot of frames. I'm on linux (ubuntu 16.04 on a thinkpad). I was exploring if hardware accel is an option and am greeted by https://dpaste.de/Hj10/raw ("Unrecognized option 'init_hw_device'") So I don't know if the answer is no or if I need a different version of ffmpeg.
[03:50:17 CET] <gp5st> the source is an X framebuffer (via OBS) (all ears on dropping obs and recording a display and an audio stream from the command line)
[03:57:24 CET] Action: gp5st facepalms https://trac.ffmpeg.org/wiki/Capture/Desktop I didn't see this earlier somehow. same question on if hardware acceleration is an option though :-\
[04:03:20 CET] <Fenrirthviti> gp5st: Are you using OBS to actually encode?
[04:04:20 CET] <gp5st> Fenrirthviti, I guess so? It takes encoder options which appear to be passed to ffmpeg, so I'm really not sure. I'm perfectly happy moving to straight command line if I can get it working though
[04:04:28 CET] <gp5st> (I don't need any of the other features of OBS)
[04:05:04 CET] <Fenrirthviti> (I'm part of the OBS project team) OBS doesn't use ffmpeg to encode if you're using x264
[04:05:08 CET] <Fenrirthviti> It uses x264 directly.
[04:05:22 CET] <Fenrirthviti> We only use ffmpeg if you're using the custom ffmpeg output
[04:05:27 CET] <Fenrirthviti> or for nvenc
[04:06:08 CET] <gp5st> ah, I see
[04:06:13 CET] <Fenrirthviti> hope over to #obsproject and I can get some more info and see if I can help determine what's going on
[04:06:20 CET] <gp5st> will do, thanks!
[04:21:19 CET] <gp5st> circling back to the "Unrecognized option 'init_hw_device'" error, do I need a different version of ffmpeg, or is it only valid with other options
[04:50:06 CET] <gp5st> ok back :) switched over to the intel drivers for my machine
[07:26:04 CET] <kingsley> How would you debug a seg fault at src/libavcodec/vorbisenc.c:1073?
[07:26:33 CET] <kingsley> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=884268;filename=symb;msg=35
[08:26:29 CET] <pmjdebruijn> kingsley: the other questions is whether it may already be fixed in svn? did you check ffmpeg changelogs with regard to that file
[08:26:42 CET] <pmjdebruijn> kingsley: (btw) the vorbisenc encoder isn't recommended for general use (libvorbis is)
[08:26:52 CET] <pmjdebruijn> (that's a bit beside the point, but I thought I'd mention it)
[08:41:04 CET] <hendry> hi, how do I tell if my audio stream in silent?  Stream #0:1[0x1e2](und): Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 96 kb/s
[08:41:21 CET] <hendry> Extract the audio stream and then what tool tells me the levels are too low I wonder?
[08:44:21 CET] <Spring> since I can't ask in #handbrake due to not being voice and OPs afk atm does anyone know if Handbrake supports a preset for HDR content?
[08:44:27 CET] <Spring> *voiced
[08:49:11 CET] <Nacht> hendry: You can use ffmpeg. ffmpeg -i audo.mp3 -af "volumedetect" -f null /dev/null
[08:49:35 CET] <dradakovic> Is there any way for ffmpeg to try to reconnect to the input if input was down? My input is http radio and it seems to have a timeout after a while. I would like ffmpeg to reconnect after timeout. I use parameters -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 4294
[08:54:30 CET] <dradakovic> ffmpeg session is still running but nothing is of course outputted as input was down
[08:55:07 CET] <hendry> Nacht: thanks! wonder how I can that into JSON so I can parse it ? https://s.natalian.org/2018-01-03/silent-output.txt
[08:55:30 CET] <hendry> I guess anything less than -50.0 dB is pretty much silent?
[08:58:42 CET] <Nacht> hendry: There's also silencedetect: https://www.ffmpeg.org/ffmpeg-filters.html#silencedetect
[08:59:13 CET] <Nacht> hendry: Only ffprobe can output in JSON. Afaik it doesn't have a volume level detect option. I might be wrong though
[09:04:59 CET] <hendry> Nacht: silence detect is interesting! again struggling to parse its output =) [silencedetect @ 0x5648acb24940] silence_start: -0.0030839
[09:05:06 CET] <hendry> I'll figure it out, thank you!!
[11:09:44 CET] <NickRubat> hi
[11:22:26 CET] <Fyr> guys, I need to remove some parts of the audio, how can I do that? I don't need 00:10:00-00:10:01, 00:20:00-00:20:01, 00:30:00-00:30:01 etc.
[11:23:03 CET] <Fyr> I know -ss and -to, but, I don't need 7 parts of the audio.
[11:25:31 CET] <Fyr> I need a reverse atrim filter
[12:10:50 CET] <Fyr> guys, so nobody knows how to remove a few seconds in the middle?
[12:11:31 CET] <durandal_1707> Fyr: use trim with concat?
[12:11:51 CET] <Fyr> with -filter_complex?
[12:12:19 CET] <durandal_1707> no, you can use simple too
[12:12:37 CET] <durandal_1707> its complicated
[12:38:00 CET] <DHE> maybe the aselect filter?
[12:51:03 CET] <Fyr> wow, it looks cool.
[12:53:17 CET] <Fyr> however, my brain is too small to comprehend how to apply it.
[12:57:44 CET] <sfan5> aselect='between(mod(t\,10)\, 0\, 1)-1'
[12:57:47 CET] <sfan5> something like that probably
[13:23:35 CET] <dradakovic> Does anyone have any clue on how to reconnect ffmpeg to the http input in case it drops? Session stays open but if http was dropped there is nothing on the output.
[13:46:10 CET] <BtbN> restart it
[13:53:39 CET] <sunslide> hi guys, I'm trying to build a command-line to support both RTSP and MJPEG streams and save them to a playlist, RTSP works great but MJPEG streams aren't, https://pastebin.com/K7x4F6AR anyone?
[13:59:14 CET] <sunslide> here is the output: https://pastebin.com/vQc9b64W
[16:18:01 CET] <nilshi> hello. I am not sure if my x11grab recording skips frame or not. There is a "speed:" indicator during recording that never reaches 1. always at 0.8 to 0.9x.  And when I end the recording it says "skipped: xy%". So I guess my recording is not fast enough to keep up?
[16:18:32 CET] <nilshi> is there a flag to be super strict and abort if even for one frame recording was too slow?
[16:26:17 CET] <c_14> don't think that flag exists, and yeah you're too slow
[16:27:13 CET] <nilshi> it is amazing that my powerful computer seems to be too slow to record my desktop 1920x1080 at 60Hz.
[16:27:32 CET] <nilshi> well... I'll read some more about ffmpeg in the meantime
[16:30:21 CET] <c_14> What's your recording command?
[16:31:33 CET] <nilshi> it varies :)
[16:31:41 CET] <nilshi> ffmpeg -draw_mouse 0 -y -framerate 30 -video_size 1920x1080 -f x11grab -i :44 output.mp4
[16:31:43 CET] <nilshi> but also
[16:31:59 CET] <c_14> try -preset fast/veryfast
[16:32:03 CET] <nilshi> with -c:v libx264rgb -crf 0 -preset:v ultrafast
[16:32:09 CET] <c_14> oh
[16:32:11 CET] <c_14> eeh
[16:32:28 CET] <c_14> try utvideo or eh ffvhuff or huffyuv
[16:32:37 CET] <furq> don't bother with huffyuv
[16:32:43 CET] <nilshi> I think I tried that also. Well, I can give it another try
[16:32:43 CET] <furq> ffvhuff is faster and compresses better
[16:32:57 CET] <furq> also don't use mp4, you'll get an unplayable file if the recording is aborted
[16:32:59 CET] <furq> use mkv
[16:33:40 CET] <nilshi> the thing is I have plenty of RAM and 8 cores and a Radeon RX 480. And I don't see them even maxed out in htop. not even close. Recording onto an SSD. So my computer hardware seems not to be the bottleneck
[16:34:26 CET] <nilshi> furq: right. I normally do. I have around 20 very similar ffmpeg commands in a text file here and I chose one of the recent ones to show
[16:34:26 CET] <furq> you could maybe use the new amd vce stuff if you have an rx 480
[16:34:41 CET] <furq> that's very new though, you'll need ffmpeg master afaik
[16:34:50 CET] <nilshi> no problem, I'll compile.
[16:34:52 CET] <nilshi> I am on arch
[16:35:41 CET] <nilshi> first I want to test a few other things though. It may neither be the hardware nor ffmpegs fault but just some Xorg setup
[16:35:45 CET] <nilshi> I am not recording my main X
[16:36:00 CET] <nilshi> thanks for the input so far.
[16:36:20 CET] <nilshi> furq: where can I read about amd vce stuff? I am not very experienced with ffmpeg at all
[16:36:47 CET] <nilshi> like so many I do copy and paste from the internet and then look up what the flags mean. Well, the last point my already put me above the average :)
[16:36:50 CET] <furq> i've not used it and i'm not sure if it's made it into the docs yet
[16:36:57 CET] <furq> it only got added about a month ago
[16:38:00 CET] <jkqxz> On Linux it's VAAPI, as it has been for a while.  The recently-added stuff (AMF) is Windows-only so far.
[16:38:11 CET] <furq> oh right
[16:38:24 CET] <furq> does encoding through vaapi work properly yet
[16:40:01 CET] <jkqxz> The screen capture examples on <https://trac.ffmpeg.org/wiki/Hardware/VAAPI> should work, maybe with "-profile:v constrained_baseline" or something on AMD.
[16:40:33 CET] <furq> nilshi: try ffvhuff first anyway
[16:40:44 CET] <furq> if that's dropping frames then it's doubtful any encoder will solve the problem
[16:41:04 CET] <furq> unless you're loading up other cores ofc
[16:42:31 CET] <jkqxz> Yeah.  If the capture isn't running fast enough in itself then offload isn't going to help.
[16:43:11 CET] <furq> x264 ultrafast ought to be good enough for 1080p60 with that cpu, but only if the cpu is relatively unloaded otherwise
[16:43:40 CET] <jkqxz> (Well, kmsgrab might, but it is pretty annoying to use.)
[16:56:02 CET] <mickie> Hi All, I have a .ts file from DVB-T2 and want to transcode its audio stream (aac_latm 48000 Hz, 5.1, fltp) into an AC3 also 6ch. The video stream is h264 (High).  How can I achieve this?
[17:04:06 CET] <nilshi> a recording speed of 0.9x is enough? does it ever start at 1 and stays there, stable?
[17:04:19 CET] <nilshi> fps seems to be locked at 30 at the moment. did not try 60 with ffvhuff yet
[17:04:20 CET] <DHE> ffmpeg -i inputfile -c:v copy -c:a ac3 -b:a 384k outputfile    # adjust bitrates etc needed
[17:04:45 CET] <DHE> nilshi: you might not get 1.0 exactly, but 0.98x is likely okay if your CPU isn't pegged
[17:04:50 CET] <nilshi> some drops happened :(
[17:05:43 CET] <nilshi> all 8 cores are at 25% to 30% during recoring. I have 4 GB RAM free (of 8)
[17:06:39 CET] <jkqxz> Does it make any difference if you set "-vsync 0"?  The timing synchronisation stuff can mess with live capturing.
[17:07:10 CET] <nilshi> that is the output so far https://hastebin.com/aqifomekud.pas
[17:07:43 CET] <nilshi> is there something obviously wrong?
[17:08:10 CET] <nilshi> jkqxz: I'll try without vsync as well
[17:08:24 CET] <nilshi> I have a long list to try things out now :)
[17:08:47 CET] <mickie> Thanks DHE, will test the output now.
[17:09:57 CET] <nilshi> with 60fps ffmpeg puts out Past duration 0.998070 too large
[17:10:04 CET] <nilshi> like crazy. several times a second
[17:10:09 CET] <nilshi> what kind of error is that?
[17:28:59 CET] <nilshi> time for ffmpeg-git for the vaapi stuff
[17:29:10 CET] <nilshi> or is that already released?
[17:32:16 CET] <alexpigment> nilshi: that happens very frequently (past duration too large). in my experience it's when the input frame rate and output frame rate don't match
[17:32:32 CET] <alexpigment> for example, if I have a 60fps video and encode it to 30fps
[17:34:22 CET] <nilshi> it doesn't happen when I do 30fps. And I guess in the end 30fps would be enough for all intents and purposes. But my ambitions are higher :)
[17:34:43 CET] <alexpigment> don't shortchange yourself, 30fps is not enough :)
[17:34:51 CET] <alexpigment> i only work with 30i or 60p primarily
[17:35:15 CET] <alexpigment> anyway, your pastebin shows -framerate 30
[17:35:18 CET] <nilshi> I'm a teacher and production of high quality educational video material where you need to see mouse movement and details.. that should have a certain technical quality
[17:35:22 CET] <alexpigment> and presumably x11grab is at 60fps
[17:35:42 CET] <nilshi> alexpigment: with 30fps I don't get that message that often. When I use the same command line and change to 60fps it begins spamming
[17:36:17 CET] <alexpigment> what if you don't specify a -framerate value? what does the final framerate become?
[17:36:18 CET] <nilshi> BUT! I think I should have mentioned that this is very experimental here. I am actually recording xvfb. That could be a total bottleneck in itself
[17:36:29 CET] <nilshi> probably 0 :) I have to check
[17:36:52 CET] <alexpigment> i haven't tried it with x11grab. just wondering if there's an inherent frame rate
[17:37:38 CET] <alexpigment> the other thing you could try is putting a redundant -r [30 or 60] after the input is defined
[17:37:54 CET] <nilshi> 29.970 frames
[17:38:51 CET] <alexpigment> ok, so say that you use 60 instead like you were talking about. when you frame step the resultant video, are there a bunch of duplicate frames?
[17:39:29 CET] <alexpigment> actually, i'm guessing the answer is yes; every other frame is probably duplicated
[17:39:32 CET] <nilshi> is there a tool that analyses that for me? I think my video material does not allow me to distinguis
[17:39:45 CET] <alexpigment> i think VLC has a frame step key
[17:39:51 CET] <alexpigment> like the right arrow or something
[17:39:52 CET] <nilshi> but if it is 29.97 frames and I say 60...
[17:40:12 CET] <alexpigment> right, so past duration too large may be every time it makes up a frame
[17:40:23 CET] <alexpigment> try just setting -framerate to 30000/1001
[17:40:30 CET] <nilshi> no -r ?
[17:40:33 CET] <alexpigment> do you get the message at all at that point
[17:40:34 CET] <alexpigment> not for now
[17:41:38 CET] <nilshi> with that it ran for 11 seconds without anything and then the "too large" message began, many.
[17:41:59 CET] <nilshi> it is dropping, not duplicating
[17:42:03 CET] <nilshi> dup=0 drop=10
[17:42:18 CET] <alexpigment> hmmm, i just don't know then
[17:42:37 CET] <alexpigment> sounds like your buffer is just running out then
[17:42:56 CET] <alexpigment> it can't capture in realtime
[17:43:44 CET] <nilshi> it happens when I record my real X :0 as well. So it has nothing to do with xvfv
[17:43:49 CET] <nilshi> xvfb
[17:44:08 CET] <furq> does -rtbufsize work with xcbgrab
[17:44:08 CET] <nilshi> Î am running an RT-Audio system though. That may interfere
[17:44:10 CET] <furq> i forget now
[17:44:20 CET] <furq> if it does then you can try bumping that
[17:44:30 CET] <nilshi> xcbgrab?
[17:51:04 CET] <nilshi> I compiled from git now and activated my ffmpeg vaapi device. The screen capture command from https://trac.ffmpeg.org/wiki/Hardware/VAAPI spits out an error:
[17:51:33 CET] <nilshi> https://pastebin.com/Rs9WSqMd
[17:53:09 CET] <alexpigment> ah one of those messages :)
[17:53:26 CET] <alexpigment> all the hardware encoders i've worked with will do that when you specify something it doesn't understand
[17:53:31 CET] <alexpigment> or software encoders too i guess
[17:53:49 CET] <alexpigment> what if you get rid of the -vf and the -qp?
[17:54:37 CET] <alexpigment> and intel QSV did that on me when i didn't specify -look_ahead 0 , which is weird, but whatever
[17:55:36 CET] <nilshi> different error
[17:55:38 CET] <nilshi> https://pastebin.com/eRsdizr6
[17:55:40 CET] <nilshi> looks worse
[17:55:54 CET] <furq> pretty sure you need the -vf
[17:56:03 CET] <furq> try adding -bf 0
[17:56:04 CET] <alexpigment> ok, put the vf back in, then instead of -qp whatever, try -b:v 5M
[17:56:10 CET] <alexpigment> or try what furq said
[17:56:15 CET] <nilshi> that was the same I got when I tried to run that command without ffmpeg from git
[17:56:28 CET] <alexpigment> seems weird that you should have to specify -bf 0 when ffmpeg knows it can't do b-frames but still
[17:56:41 CET] <furq> i'm guessing it maybe doesn't know that
[17:56:50 CET] <alexpigment> it says it in the pastebin
[17:57:01 CET] <alexpigment> right above the error
[17:57:08 CET] <furq> i assume that's a strerror from vaapi
[17:57:10 CET] <furq> idk though
[17:57:25 CET] <nilshi> that was better with -bf 0
[17:57:27 CET] <nilshi> https://pastebin.com/G8SmJZ94
[17:57:28 CET] <alexpigment> i'll trust your knowledge on this. i know *some* part of the process knows b frames aren't supported
[17:57:41 CET] <nilshi> some drops and dups at the beginning, then 30sec stable recording before I ended
[17:57:57 CET] <furq> i know very little about hwenc, i'm just saying the error message doesn't necessarily mean ffmpeg knows
[17:58:08 CET] <alexpigment> that's fair
[17:58:46 CET] <alexpigment> does vaapi have a speed mode?
[17:58:50 CET] <jkqxz> I suspect you are going to want "-profile:v constrained_baseline" too.  It defaults to high, which has some weird problems on AMD.
[17:59:13 CET] <alexpigment> well, constrained baseline should at least be faster, albeit very gimped
[17:59:25 CET] <jkqxz> alexpigment:  Yes, it's mapped from "-compression_level".  It only has much effect on recent Intel, though.
[17:59:27 CET] <nilshi> I don't know what either of this means
[17:59:35 CET] <nilshi> is it like fast/ultrafast?
[17:59:45 CET] <alexpigment> constrained baseline is like a subset of features of h.264
[17:59:52 CET] <alexpigment> a very basic subset
[18:00:55 CET] <alexpigment> anyway, i guess it's worth putting -compression level in there then. i have no idea what the scale is
[18:02:07 CET] <jkqxz> It doesn't do anything at all on AMD, and will probably complain that the option isn't supported.
[18:02:36 CET] <alexpigment> are you thinking the lack of b frames message indicates it's AMD?
[18:02:41 CET] <alexpigment> (e.g. the 500 series)?
[18:02:41 CET] <nilshi> hm... guys. the video is empty
[18:03:07 CET] <furq> it's a 480
[18:03:20 CET] <nilshi> RX 480, yes.
[18:03:29 CET] <nilshi> open source drivers
[18:03:38 CET] <alexpigment> ah, i didn't see that info
[18:03:38 CET] <jkqxz> Probably add the "-profile:v constrained_baseline"?  High profile is the default and generally doesn't work properly there.
[18:03:47 CET] <nilshi> alexspeller: it was before you joined
[18:03:57 CET] <alexpigment> gotcha
[18:05:08 CET] <nilshi> nope, still nothing
[18:05:28 CET] <nilshi> or wait...
[18:05:33 CET] <alexpigment> add the -framerate 30000/1001 back in at the beginning maybe?
[18:05:51 CET] <nilshi> mplayer says wrong video. vlc now plays a very cropped version
[18:06:05 CET] <alexpigment> hmmm
[18:06:35 CET] <nilshi> 10 seconds equal 120kb of video. That doesn't sound right
[18:07:02 CET] <nilshi> or it is the magical codec which stores in another dimension
[18:07:08 CET] <alexpigment> well, it kinda does ;)
[18:07:32 CET] <alexpigment> if the video doesn't change much over time, it doesn't use much more bitrate
[18:07:51 CET] <nilshi> it is recording a terminal with asciiquarium
[18:07:53 CET] <nilshi> a lot of black
[18:08:02 CET] <alexpigment> sounds easy to encode
[18:08:21 CET] <nilshi> I could start glxgears instead
[18:08:32 CET] <nilshi> no, that is opengl. Another can of worms
[18:08:48 CET] <nilshi> right now the resolution is the problem. And that mplayer does not want to play the file at all
[18:09:27 CET] <nilshi> ... where is video size
[18:11:03 CET] <nilshi> ok, if I actually put in the resolution it records correctly. mplayer still doesn't like it though.
[18:12:57 CET] <alexpigment> do you have mediainfo or a similar program to look at the video properties?
[18:13:11 CET] <alexpigment> it might be obvious what's going on by seeing that
[18:13:41 CET] <alexpigment> i guess ffprobe will do the same
[18:14:08 CET] <nilshi> yes
[18:14:09 CET] <alexpigment> also, did you try the -profile:v constrained baseline like jkqxz?
[18:14:15 CET] <nilshi> yes, it is in
[18:14:20 CET] <alexpigment> k
[18:14:42 CET] <alexpigment> he works a lot with hardware encoder stuff, so he's really the main authority imho
[18:14:42 CET] <nilshi> https://pastebin.com/z4V3jJV3
[18:15:33 CET] <alexpigment> weird. i doubt mplayer would have a problem with the h.264 level being 5.1, but it is very high still
[18:16:06 CET] <alexpigment> also, it's cabac with baseline profile
[18:16:14 CET] <alexpigment> maybe it expects those two to be mutually exclusive
[18:16:44 CET] <nilshi> ffmpeg -y -vaapi_device /dev/dri/renderD128 -video_size 1920x1080 -f x11grab -i :44 -vf 'hwupload,scale_vaapi=format=nv12' -c:v h264_vaapi -bf 0 -profile:v constrained_baseline output.mp4
[18:16:53 CET] <nilshi> that is the current command
[18:17:27 CET] <alexpigment> try adding -coder cavlc -level 41
[18:17:37 CET] <nilshi> just before output?
[18:17:42 CET] <alexpigment> right
[18:19:49 CET] <nilshi> same behaviour with mplayer https://pastebin.com/pEDyt2Em
[18:20:03 CET] <alexpigment> cabac is still on...
[18:20:05 CET] <alexpigment> hmm
[18:20:31 CET] <nilshi> maybe it is not related to this video and I got an mplayer problem, unrelated
[18:20:53 CET] <alexpigment> it could be
[18:21:05 CET] <nilshi> /usr/bin/mplayer: error while loading shared libraries: libswscale.so.4: cannot open shared object file: No such file or directory
[18:21:20 CET] <nilshi> where does this come frome. The only thing that changed is ffmpeg from git. no other system update
[18:21:27 CET] <nilshi> *shrugs*
[18:23:38 CET] <alexpigment> maybe related; https://www.linuxquestions.org/questions/slackware-14/mplayer-error-libwscale-s04-4175599926/
[18:24:27 CET] <nilshi> I see. I just compiled ffmpeg from git. There is a ffmpeg-full-git package as well. Described as "with all features. Maybe I need that
[18:25:05 CET] <alexpigment> possibly. i'll claim ignorance
[18:26:17 CET] <nilshi> it is part of ffmpeg. https://github.com/FFmpeg/FFmpeg/tree/master/libswscale
[18:26:57 CET] <nilshi> I didn't install the full package because it draws in pulseaudio :(
[18:40:55 CET] <sfan5> nilshi: you need to recompile mplayer if you install a git version of ffmpeg
[18:43:41 CET] <nilshi> better than installing pulseaudio
[18:47:02 CET] <nilshi> no luck, but I'll work with vlc for now
[18:47:16 CET] <nilshi> I can always revert to the binary ffmpeg and wait for the next release. Right now I just want to find out
[18:59:05 CET] <nilshi> it doesn't look good. I can't shake the feeling that something in my system may be misconfigured.
[18:59:22 CET] <nilshi> I'll settle with 29.97 fps and the occasional fram dop or dup for now.
[19:00:04 CET] <nilshi> last question: can I record RGB colors with vaapi ? I want to try how that looks different
[19:17:17 CET] <Fyr> Can anyone explain to me why if output is 45 minutes long?
[19:17:17 CET] <Fyr> ffmpeg -ss "00:28:16" -i "input.mkv" -to "00:45:52" -map 0 -c copy "output.mkv"
[19:17:45 CET] <Fyr> it's supposed to be 17 minutes.
[19:26:20 CET] <alexpigment> Fyr: i don't recall the difference between -t and -to but I think generally people use -to
[19:26:24 CET] <alexpigment> gah
[19:26:31 CET] <alexpigment> *people generally use -t is what i meant
[19:26:46 CET] <alexpigment> secondly, you're defining your starting point before the input and the ending point after the input
[19:27:17 CET] <alexpigment> you should put them on one side or the other
[19:28:37 CET] <alexpigment> also, looking now, but i guess -to is the ending timestamp but -t is the length, so I guess that's fine. try putting the -ss and -to on the same side of the input in the command line
[19:43:09 CET] <Fyr> is there a way to split file efficiently? something like -ss 00:01:00 -t 60 1.mkv -ss 00:02:00 -t 60 2.mkv
[19:43:09 CET] <Fyr> etc
[19:48:06 CET] <alexpigment> https://stackoverflow.com/questions/5651654/ffmpeg-how-to-split-video-efficiently
[19:49:48 CET] <Fyr> thanks
[20:12:57 CET] <kepstin> Fyr: when you use the -ss input option, ffmpeg resets the timestamps so that '0' is the seek point, therefore the -to option will go until 45:52 after the seek point.
[20:17:40 CET] <kepstin> (there are ways to avoid this, e.g. the -copyts option or using -itsoffset)
[20:22:25 CET] <Mista_D> ffmpeg with two filters runs at  0.4 real time (usually its 6-7 times real time on 12 core Xeon DELL T7500). Any advice please?
[20:22:25 CET] <Mista_D> ffmpeg -i 1080p_2997_tc_yuv422p.mxf -map_metadata -1 -vf fieldmatch,yadif,decimate,fps=1/3 -crf 4 -pix_fmt yuv420p -an -s 960x540 -g 1 -threads 0 3sec_intervals.mov
[20:23:23 CET] <kepstin> yadif is a pretty slow filter
[20:23:36 CET] <kepstin> but that's a bid difference, hmm.
[20:28:00 CET] <alexpigment> is there any advantage to using "fieldmatch,yadif,decimate"?
[20:29:17 CET] <kepstin> if you have bad cuts or fades or whatnot in telecined video, the yadif there will deinterlace the fields that couldn't be matched
[20:29:31 CET] <alexpigment> ah
[20:29:37 CET] <Mista_D> alexpigment: its to convert TC back to 24 fps
[20:30:02 CET] <alexpigment> Mista_D: understandable, I just didn't understand the point of using yadif in that context
[20:30:06 CET] <alexpigment> i'll trust kepstin on this
[20:31:02 CET] <kepstin> normally you'd use it was "yadif=deinterlace=interlaced" so it only runs on frames marked as interlaced tho (iirc, fieldmatch sets that on frames where it had unmatched fields, or you could use idet)
[20:31:27 CET] <alexpigment> yeah, that was what I was reading here on the FAQ: fieldmatch=order=tff:combmatch=full, yadif=deint=interlaced, decimate
[20:31:32 CET] <kepstin> er, "yadif=deint=interlaced"
[20:31:53 CET] <alexpigment> in which case, maybe that would speed the operation up, if that is indeed th eproblem
[20:32:05 CET] <kepstin> Mista_D: i'd suggest just moving the yadif filter to after the fps filter, and add the deint=interlaced option to it
[20:32:18 CET] <kepstin> that'll make it run on way fewer frames, should speed it up a fair bit
[20:32:32 CET] <alexpigment> very good point
[20:32:33 CET] <Mista_D> OKTried removing fieldmatch and decimate, now it at x4.87 RT. seems good on output (will burn in timecode to make sure the frames are matching).
[20:32:54 CET] <Mista_D> will try the yadif after too in a minute...
[20:33:04 CET] <kepstin> if your content is already progressive (24p or whatever), there's no point in using fieldmatch/decimate
[20:33:17 CET] <kepstin> but that looks like it's 60i telecined?
[20:33:26 CET] <alexpigment> the filename seems to indicate it's telecined
[20:33:29 CET] <kepstin> you'd really have to look at the video to check
[20:33:31 CET] <alexpigment> well
[20:33:36 CET] <alexpigment> "1080p_2997"...
[20:33:37 CET] <alexpigment> not sure
[20:35:33 CET] <alexpigment> honestly, he's doing fps=1/3 and 960x540... seems like you could just drop half of the fields rather than doing anything complicated
[20:35:53 CET] <kepstin> ah, true, if you're downscaling that much no point in deinterlacing at all
[20:36:03 CET] <kepstin> just use a filter that drops the other field
[20:36:10 CET] <kepstin> be way faster than downscaling even
[20:36:57 CET] <alexpigment> -vf field,fps=1/3
[20:37:14 CET] <kepstin> you'd still need to scale it horizontally
[20:37:28 CET] <alexpigment> he's specifying the resolution explicitly
[20:37:39 CET] <alexpigment> which should imply a scale filter
[20:37:44 CET] <kepstin> oh, right, using -s
[20:39:16 CET] <kepstin> Mista_D: give this a try, then: "ffmpeg -i 1080p_2997_tc_yuv422p.mxf -map_metadata -1 -vf field,fps=1/3 -crf 4 -pix_fmt yuv420p -an -s 960x540 -g 1 -threads 0 3sec_intervals.mov"
[20:39:46 CET] <kepstin> that's with alexpigment's filters, should be the fastest way to do what you're trying to do.
[20:39:50 CET] <Mista_D> kepstin: cool thanks!
[21:00:31 CET] <nilshi> can I count from the end instead from the start in st=? I just want 0.5 seconds fade to black at the end. this is for batch processing:  ffmpeg -i input.mts -vf 'fade=t=out:st=SEC:d=0.5' out.mkv
[21:01:25 CET] <alexpigment> https://video.stackexchange.com/questions/19867/how-to-fade-in-out-a-video-audio-clip-with-unknown-duration
[21:01:54 CET] <alexpigment> a lot of that is about fading the audio
[21:02:02 CET] <alexpigment> but i would assume the principle still applies
[21:03:40 CET] <nilshi> just read that before asking. I was wondering if a workaround was still needed or if that feature was already in ffmpeg now
[21:04:50 CET] <alexpigment> i'm not aware of a different way to do it
[21:05:25 CET] <alexpigment> i suppose you could use a variable for the time and calculate it with an ffprobe call beforehand
[21:06:50 CET] <nilshi> ok, will do that. Not the biggest problem in the world :)
[21:06:58 CET] <alexpigment> also not the cleanest solution :)
[21:07:12 CET] <alexpigment> seems like it should be an option for the filter
[21:07:17 CET] <nilshi> I have two days of ugly hacking behind me. I don't mind about some awk now
[21:07:55 CET] <alexpigment> fair enough :)
[21:14:36 CET] <nilshi> why u no work with grep, ffprobe
[21:15:36 CET] <nilshi> well, not needed here. https://trac.ffmpeg.org/wiki/FFprobeTips#Duration
[21:34:00 CET] <kepstin> the only way the filter could do that is by buffering (delaying) frames for the duration of the fadeout. Doable, but kinda messy & might be memory intensive if it's a long fade.
[22:17:25 CET] <nilshi> kepstin: it is just the convenience to let ffmpeg run ffprobe itself and get the duration
[22:17:44 CET] <nilshi> on the other hand ffmpeg is not  for endusers, so.. who cares
[22:20:41 CET] <kepstin> and of course that's not possible at all on stuff like piped media or network streams
[23:01:15 CET] <nilshi> when I apply the filter my video shrinks from 250MB to 4MB. That sounds like degredation
[23:01:49 CET] <nilshi> ffmpeg -y -i "$FILENAME" -vf "fade=t=out:st=$STARTFADE:d=$FADE" "$FILENAME-faded.mkv"
[23:02:17 CET] <durandal_1707> nilshi: pastebin full ffmpeg cmd output, increase cbr
[23:06:37 CET] <nilshi> durandal_1707: https://pastebin.com/BT4HY1B4
[23:07:00 CET] <nilshi> I have not set cbr at all
[23:08:19 CET] <durandal_1707> use similar preset
[23:08:40 CET] <furq> nilshi: if the input is lossless then you need to set the same params for the output
[23:08:59 CET] <furq> and also you need to specify libx264rgb or it'll convert to yuv
[23:09:07 CET] <kingsley> pmjdebruijn: I'm back.
[23:09:19 CET] <nilshi> -c:v libx264rgb -crf 0 -preset:v ultrafast -af aresample=async=1:first_pts=0
[23:09:27 CET] <nilshi> these are my recording options
[23:09:32 CET] <kingsley> Thanks for your vorbis-y thoughts.
[23:09:50 CET] <furq> set the first two
[23:09:59 CET] <sfan5> or three
[23:10:46 CET] <nilshi> let's see
[23:11:03 CET] <kingsley> You reasonably asked if I checked if src/libavcodec/vorbisenc.c seg fault at line 103 is already fixed in svn.
[23:11:06 CET] <kingsley> I have not.
[23:11:33 CET] <durandal_1707> svn is not used long ago
[23:12:01 CET] <kingsley> I was interested to see libvorbis is generally preferred to vorbisenc.
[23:12:15 CET] <durandal_1707> use libvorbis
[23:12:22 CET] <kingsley> If you happen to have the time, and are so inclined, I'd be interested in your further thoughts on...
[23:12:33 CET] <nilshi> yes that worked.
[23:12:52 CET] <nilshi> Now I can finally upload the video to youtube so that my nice quality shall be destroyed
[23:12:54 CET] <kingsley> 1.) Where can I check if the vorbisenc.c's seg fault is fixed in svn, and
[23:13:22 CET] <durandal_1707> kingsley: which project use svn?
[23:14:45 CET] <kingsley> 2.) can you cite a link to a web page that I can show kdenlive's maintainer, so he might consider passing "acodec=libvorbis" to melt instead of "acodec=vorbis"?
[23:15:35 CET] <furq> kingsley: https://trac.ffmpeg.org/wiki/Encode/HighQualityAudio#AudioencodersFFmpegcanuse
[23:15:40 CET] <furq>  Please note it is not recommended to use the experimental vorbis for Vorbis encoding; use libvorbis instead.
[23:17:01 CET] <kingsley> durandal_1707: I don't know, but if I understand correctly, pmjdebruijn seeemd to think a few hours ago that src/libavcodec/vorbisenc.c is.
[23:17:05 CET] <furq> with that said it's 2017 so he should really be using libopus
[23:17:36 CET] <therage3> Agreed
[23:17:39 CET] <therage3> Opus ftw
[23:18:30 CET] <kingsley> furq: Thank you very much for the vorbis link.
[23:18:44 CET] <kingsley> I hope to draw it to the attention of the proper maintainers.
[23:19:12 CET] <nilshi> all this work for just a silly animation! https://youtu.be/CL37Cxb5Eh4
[23:19:23 CET] <kingsley> My testing suggests it explains why kdenlive isn't rendering .webm format video.
[23:23:48 CET] <furq> https://github.com/KDE/kdenlive/blob/640d4467558db92b5d2dbcc0baaf74a4a5f664c2/data/profiles.xml#L6
[23:23:52 CET] <furq> that's a bit of an oversight yeah
[23:24:05 CET] <furq> especially considering it was updated to use the new aac encoder for mp4
[23:24:55 CET] <kingsley> furq: I'm happy to report that much like "acodec=libvoris", "acodec=libopus" avoids the seg fault caused by acodec=voris".
[23:25:01 CET] <kingsley> That's the good news.
[23:25:04 CET] <kingsley> The bad news?
[23:25:11 CET] <furq> if the segfault is in vorbisenc.c then that's no surprise
[23:25:18 CET] <kingsley> The rendered video was silent!
[23:25:25 CET] <furq> it wouldn't surprise me if that was a lavc bug because nobody uses the builtin vorbis encoder
[23:25:29 CET] <furq> except kdenlive, apparently
[23:26:04 CET] <durandal_1707> kingsley: which player you use?
[23:26:24 CET] <kingsley> furq: Yes. The seg fault is in vorbisenc.c.
[23:26:45 CET] <furq> you probably want to change quality=good and aq=%audioquality if you're using opus
[23:26:54 CET] <kingsley> furq: gdb's full back trace is at
[23:26:56 CET] <furq> idk what -quality good even does, i've never heard of that
[23:26:57 CET] <kingsley> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=884268;filename=symb;msg=35
[23:27:14 CET] <furq> but -aq does nothing with libopus afaik, you should use e.g. -ab 128k
[23:30:22 CET] <kingsley> furq: Thank you very much for pointing your huge ffmpeg brain at my little seg fault.
[23:30:41 CET] <kingsley> It seems to me that you've made not one, but two important contributions:
[23:31:18 CET] <kingsley> 1.) a link to web page saying to use libvorbis instead of vorbis, which I can show to maintainers, and
[23:31:33 CET] <kingsley> 2.) perhaps the exact line of kdenlive's code with the bug.
[23:40:13 CET] <alexpigment> nilshi: looks nice!
[23:40:19 CET] <alexpigment> oh nm, he left ;)
[00:00:00 CET] --- Thu Jan  4 2018