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

[burek]

[00:00:25 CEST] <vade> hi JEEB - are you familiar with the nuances of the filter API? I have had a working filter chain - but trying to incorporate dynaudnorm or loudnorm filters shows a bug in my code I cant find, where I consistenly get error EAGAIN from my buffer sink at the end of my chain
[00:00:55 CEST] <vade> in short , I read packet -> decode -> send to my sink
[00:00:59 CEST] <vade> er source
[00:01:04 CEST] <vade> that works
[00:01:11 CEST] <vade> pulling from my sink fails
[00:01:25 CEST] <JEEB> haven't done filters yet, sorry
[00:01:44 CEST] <JEEB> but there should be filters of varying quality of insanity in the FFmpeg tree to look at for examples
[00:01:52 CEST] <JEEB> oh, calling filters
[00:01:54 CEST] <JEEB> ok
[00:02:24 CEST] <JEEB> yeah, I've only called swscale as-is so not too much use of me in that, either
[00:03:02 CEST] <vade> hrm. Yea. Im seriously bashing my head against this. I have aformat and have called other filters no problem
[00:03:08 CEST] <vade> but forwhatever reason, this is giving me grief
[00:04:59 CEST] <durandal_1707> vade see what ffmpeg does
[00:07:18 CEST] <vade> yea. ive looked at that, and at docs/filtering audio
[00:07:33 CEST] <vade> the docs appear to push to the src, and then pull from the sink
[00:08:00 CEST] <vade> ffmpeg pulls from sink first, then pushes for whatever reason, and also calls avfilter_graph_request_oldest
[00:08:12 CEST] <vade> ive tried both, I still get my config problem
[00:08:43 CEST] <vade> whatever im setting it up as, either in the filter chain, or in how im using it causes constant EAGAINs in the sink
[00:11:00 CEST] <vade> hm
[00:11:21 CEST] <vade> so it loos like the av_fifo size is zero
[00:43:18 CEST] <intracube> does anyone know what the difference is between -pix_fmt monob and monow ?
[00:43:36 CEST] <intracube> both seem to give visually identical output
[00:46:18 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixfmt.h#L71
[00:46:35 CEST] <drv> they just indicate whether black = 0 and white = 1 or vice versa
[00:49:50 CEST] <vade> durandal_1707: is there any pragmatic difference between avfilter_graph_create_filter and avfilter_graph_alloc_filter + avfilter_init_str ?
[01:38:27 CEST] <kyleogrg> hi
[01:38:46 CEST] <kyleogrg> "concat" isn't working when I use the full paths to the files:
[01:39:04 CEST] <kyleogrg> example: "concat:C:\file1.avi|C:\file2.avi"
[01:39:11 CEST] <kyleogrg> how can i do this?
[01:45:27 CEST] <kyleogrg> okay, file name was misspelled
[01:45:30 CEST] <kyleogrg> adios
[01:59:00 CEST] <intracube> BtbN: drv: hm, ok. I wonder why one set of the png images I was writing to didn't appear inverted
[01:59:28 CEST] <intracube> but thanks for the info
[02:11:57 CEST] <drv> png probably converts monob/monow into paletted mode anyway, so it would make no difference
[02:14:28 CEST] <intracube> drv: ah ok, thanks
[03:48:27 CEST] <hispeed67> do i need to do anything to enable multi-cpu/threads in ffmpeg?
[03:48:53 CEST] <hispeed67> ie should i recompile it ?
[03:49:10 CEST] <furq> it should normally work automatically
[03:49:29 CEST] <hispeed67> ok.. got my new computer today furq.. :)
[03:49:32 CEST] <furq> some codecs need you to explicitly pass -threads (and some don't support multithreading)
[03:50:08 CEST] <hispeed67> all the fun of figuring out how to get the most out of second CPU now.
[03:50:35 CEST] <furq> if you're using x264 it should just work automatically
[03:50:50 CEST] <furq> if you got that dual westmere-ep it should be pretty quick
[03:51:04 CEST] <hispeed67> was thinking about playing with h.265
[03:51:54 CEST] <hispeed67> no.. it's old.. but it's dual cpu.. 8 core total... e5345 (x2) with 24G ram
[04:01:26 CEST] <hispeed67> wow.. sysbench is cool.. wow at the difference between my systems though.
[04:28:40 CEST] <Guest81991> Hello I have questions about FFMpeg on my linux server is this the right place?
[04:28:48 CEST] <c_14> probably
[04:29:00 CEST] <c_14> ask and we will find out
[04:29:12 CEST] <Guest81991> LOL ok
[04:31:01 CEST] <Guest81991> I have a dedicated server with a well known company and the specs are really good. When I put a MP4 on my server when it plays it buffers and seems to have to downloaded
[04:31:29 CEST] <c_14> Are you creating the mp4?
[04:31:40 CEST] <Guest81991> same video on youtube plays fine  will FFMpeg help me on my server?
[04:31:58 CEST] <c_14> what you need to do is move the moov atom to the front of the file, the -movflags +faststart option will do that for you
[04:32:14 CEST] <c_14> something like ffmpeg -i input.mp4 -map 0 -c copy -movflags +faststart out.mp4
[04:32:28 CEST] <Guest81991> c_14 yes I use Adobe Premire to compress etc
[04:33:05 CEST] <c_14> maybe check if premiere has some sort of faststart option or some way to move the moov atom itself. That way you don't have the intermediate step
[04:33:16 CEST] <Guest81991> I am being told I need FFMpeg on my server to fix that issue of buffering
[04:34:06 CEST] <Guest81991> atom such as molecules?
[04:34:19 CEST] <c_14> nah
[04:34:24 CEST] <c_14> it's just called that
[04:35:50 CEST] <Guest81991> well if the same video plays good on you tube but buffers on my server I would think it is my server?
[04:36:07 CEST] <c_14> youtube reencodes every video you upload onto it
[04:36:28 CEST] <Guest81991> that I do know c_14
[04:37:11 CEST] <Guest81991> but I am told FFMpeg if installed on my server will fix that issue
[04:37:33 CEST] <c_14> Like I said, you can use ffmpeg to create an mp4 with the moov atom at the front
[04:40:12 CEST] <Guest81991> so I understand better I should first use FFMpeg on my windows machine to further process the MP4 before I upload to my server?
[04:40:31 CEST] <c_14> doesn't matter where you run it, but ye
[04:43:37 CEST] <Guest81991> do you know of any good tuts   on ffmpeg?
[04:44:36 CEST] <c_14> the wiki has decent pages for a lot of basic stuff, other than that there's the manpages and asking questions here or on the ffmpeg-user mailing list
[04:45:01 CEST] <c_14> every tutorial I know of is either out of date, not very good or flat-out wrong
[04:46:10 CEST] <Guest81991> yes I have viewed many but it does not answer all my questions
[04:46:47 CEST] <c_14> https://trac.ffmpeg.org/wiki https://ffmpeg.org/ffmpeg-all.html
[04:47:11 CEST] <Guest81991> Reading the manual is vague
[04:50:03 CEST] <Guest81991> maybe I need to hire a developer to set ip up on server to allow me to stream a video faster?
[04:50:48 CEST] <Guest81991> thank you c_14
[04:51:17 CEST] <Guest81991> I will keep trying to understand
[07:25:40 CEST] <Ffmegggg> I want to link an extra library to ffmpeg build. How do I modify the Makefile for ffmpeg to link the library ?
[07:27:25 CEST] <Ffmegggg> I have already created the .a for the library. I just want to link it to the ffmpeg's executable by compiling it again
[07:29:41 CEST] <Ffmegggg> Anyone plz help
[09:37:37 CEST] <Fyr> guys, how does concatenation protocol go if one of the input files doesn't contain audio while other ones do?
[10:22:11 CEST] <TiTE> 'llo
[12:43:31 CEST] <ocZio> hi all
[12:43:51 CEST] <ocZio> I have a video question which might not be directly related/solved by using ffmpeg but I am not sure where else I can ask
[12:44:24 CEST] <Sokolio> shoot
[12:44:50 CEST] <ocZio> would it be possible to have the following setup: PTZ Camera outputs a source (HD SDI?) => capture/encode with ffmpeg and make it available for webrtc/html5 video ?
[12:45:31 CEST] <ocZio> basically I am trying to see the output of the PTZ camera in the browser :-)
[12:46:03 CEST] <Sokolio> 1) To capture SDI you'll need a grabber, like BlackMagic or Aver
[12:46:32 CEST] <Sokolio> that's actually possible
[12:46:54 CEST] <Sokolio> 2) encode and package into HLS so your browser can pick it up
[12:47:52 CEST] <ocZio> Sokolio, how would I go to do 2) ? ffmpeg or ?
[12:48:05 CEST] <ocZio> I have read about HLS, (apple's?) seem to be supported by Chrome and that is good I guess...
[12:48:30 CEST] <furq> ocZio: -f hls out.m3u8
[12:48:35 CEST] <furq> https://github.com/dailymotion/hls.js/
[12:48:40 CEST] <furq> it's supported in all browsers if you use that
[12:48:46 CEST] <Sokolio> <ocZio> ffmpeg can grab from some of the grabbers
[12:48:48 CEST] <furq> otherwise it's only supported on mobile
[12:49:10 CEST] <furq> the latency is unavoidably bad though
[12:49:20 CEST] <ocZio> if it is around 300-400 ms I can live with that
[12:49:25 CEST] <furq> it's much worse than that
[12:49:25 CEST] <ocZio> how much are we talking about ?
[12:49:29 CEST] <ocZio> feck
[12:49:39 CEST] <furq> webrtc is the only web video tech with decent latency
[12:49:44 CEST] <furq> and i have no idea where to start with that
[12:49:58 CEST] <Sokolio> Well, HLS is not good in terms of latency
[12:50:04 CEST] <Sokolio> it's very bad
[12:50:25 CEST] <ocZio> ok so in any case I will need to have a so called grabber
[12:50:38 CEST] <furq> dash is pretty much just as bad, which is the other html5 option
[12:50:42 CEST] <Sokolio> well, hwo do you imagine grabbing SDI video?
[12:50:55 CEST] <furq> you could use flash and rtmp, but i'm not totally sure how low you can get that
[12:51:01 CEST] <Sokolio> @furq true, that applies to Smooth STreaming as well
[12:51:04 CEST] <furq> otherwise it's webrtc
[12:51:15 CEST] <Sokolio> rtmp and flash is pretty fast
[12:51:23 CEST] <ocZio> furq, I can't use flash, I need to have the <video> tag working rather than plugins flash etc...
[12:51:25 CEST] <furq> i have no idea if you can get sub-second latency with it
[12:51:31 CEST] <Sokolio> but you need a server for that, nginx rtmp for example
[12:51:31 CEST] <furq> looks like it's not an option though
[12:52:19 CEST] <ocZio> now I am lost :P
[12:52:44 CEST] <ocZio> so HD SDI source=>blackmagic (pci express device or ?)=>somehow to webrtc ?
[12:53:07 CEST] <Sokolio> BM comes as pci or usb 3.0
[12:53:24 CEST] <Sokolio> SDI -> Grabber -> ffmpeg -> webrtc
[12:53:53 CEST] <Sokolio> I wonder if AverMedia have SDI grabbers?
[12:53:58 CEST] <ocZio> ok - ok - ? - ?
[12:54:21 CEST] <ocZio> will ffmpeg act as a server and generate webrtc content to be consumed ?
[12:54:52 CEST] <Sokolio> Dunno, never tried that
[12:55:08 CEST] <Sokolio> but ffmeg can grab frames through BM (decklink)
[12:55:09 CEST] <Sokolio> https://www.ffmpeg.org/ffmpeg-devices.html#decklink
[12:55:23 CEST] <Sokolio> but you'll need a custom build
[12:57:29 CEST] <ocZio> yikes
[12:57:47 CEST] <ocZio> and we all know the support for windows and how long it is going to take me to compile on win7 :P
[12:58:42 CEST] <Sokolio> dunno :/
[12:59:05 CEST] <Sokolio> I used to build for Win using mingw and it sorta worked
[12:59:14 CEST] <Sokolio> and it works in commercial systems
[12:59:54 CEST] <Sokolio> but not sure how to deal with grabbers, the provide SDK for both windows and linux
[13:02:08 CEST] <ocZio> thanks for the ideas
[13:02:25 CEST] <ocZio> I have the feeling this is going to be more complicated than I was thinking :)
[13:06:59 CEST] <Sokolio> <ocZio> It didn't sound easy from start
[13:07:58 CEST] <ocZio> maybe there are camera which already do all that and give just stream to consume ?
[13:13:29 CEST] <Sokolio> <ocZio> there are, they are called IP cameras
[13:13:57 CEST] <ocZio> so what does that outputs and how can I get the feed to the browsers?
[13:14:18 CEST] <Sokolio> Most of them have their little proprietary solutions
[13:15:10 CEST] <Sokolio> some of them even have a web server with jpeg stream preview, it's difficult to find a rule or a standard
[13:15:14 CEST] <Sokolio> just browse catalogs
[13:19:49 CEST] <ocZio> I need full stream rather than just low res jpegs
[13:19:54 CEST] <ocZio> but thanks, I will have a look!
[13:51:10 CEST] <ocZio> does any of you have a capture card available now ? :P if yes could you confirm my theory and check https://webrtc.github.io/samples/src/content/devices/input-output/
[13:51:23 CEST] <ocZio> does it work? with webrtc...
[14:19:14 CEST] <_fireion> Hi ! I recently compiled ffmpeg with NVENC. I have GeForce 930M. It supports NVENC. However I'm getting error that No NVENC compatible devices found.
[14:19:36 CEST] <_fireion> The command which I used was ./ffmpeg -y -i input.mp4 -vcodec nvenc -b:v 5M -acodec copy output.mp4 -loglevel debug
[14:19:54 CEST] <Fyr> >>No NVENC compatible devices found.
[14:20:07 CEST] <Fyr> it seems like it says what it means.
[14:20:21 CEST] <_fireion> And the output was http://pastebin.com/PUYz78KF
[14:20:22 CEST] <Fyr> ffmpeg's nvenc is not compatible with your device.
[14:20:45 CEST] <_fireion> Hi Fyr: Here it's written http://www.notebookcheck.net/NVIDIA-GeForce-930M.139035.0.html
[14:20:50 CEST] <_fireion> That NVENC is supported.
[14:21:07 CEST] <Fyr> [18:20:24]	Fyr: ffmpeg's nvenc is not compatible with your device.
[14:21:41 CEST] <_fireion> FFMPEG's nvenc ? So it means it will work with some other NVENC ? Where is the ffmpeg's nvenc compatibility list ?
[14:22:49 CEST] <JEEB> you should check where the message comes from
[14:22:58 CEST] <JEEB> it could be coming from your nvenc sdk or whatever driver related
[14:23:08 CEST] <Fyr> http://trac.ffmpeg.org/wiki/HWAccelIntro#NVENC
[14:23:13 CEST] <JEEB> in which case it's pretty much "either drivers are wrong or you have failed with something else" :P
[14:23:27 CEST] <_fireion> JEEB: Can you tell me how to do it ?
[14:23:35 CEST] <JEEB> not now, hard at work :P
[14:25:46 CEST] <Sokolio> I remember doing development using Nvenc on win32 and I couldnt use the encoder when display was through nvidia
[14:25:54 CEST] <Sokolio> had to switch display to intel
[14:26:02 CEST] <_fireion> Ha. It's saying Fyr: '''Note: If you get the No NVENC capable devices found error make sure you're encoding to a supported pixel format. See encoder info as shown above.'''
[14:26:10 CEST] <_fireion> The page which you linked.
[14:26:11 CEST] <Fyr> ok
[14:26:46 CEST] <Fyr> _fireion, have you tried another CUDA-based program?
[14:26:53 CEST] <_fireion> Yes.
[14:26:59 CEST] <_fireion> I tried programs from CUDA SDK
[14:27:23 CEST] <Sokolio> But NVENC doesn't have anything to do with CUDA
[14:27:26 CEST] <Fyr> _fireion, can you run flacCL with CUDA?
[14:27:34 CEST] <_fireion> All work fine. Fortunately for me the display driver is almost latest 364.xx
[14:27:39 CEST] <Sokolio> There's NVCUENC which is CUDA
[14:28:05 CEST] <_fireion> I did not compile with openCL. I will try Fyr.
[14:28:51 CEST] <Fyr> no, I meant, can other programs use your videocard?
[14:30:16 CEST] <_fireion> Yes.
[14:30:36 CEST] <_fireion> I can show you nvidia-smi log. compiz, google-chrome etc. are using it.
[14:31:01 CEST] <_fireion> Also X is using it right now.
[14:31:14 CEST] <Fyr> ok, it seems like the problem is caused by FFMPEG.
[14:34:09 CEST] <_fireion> So can you tell me how should I debug ?
[14:34:30 CEST] <_fireion> I'll be back in 10 mins. I'm hungry :-P
[14:35:04 CEST] <Fyr> sorry, I can't.
[14:35:50 CEST] <Fyr> all I can advise is to use -report option and post a bug report.
[14:36:47 CEST] <Fyr> the developers will never fix the bug, but a few people might recommend you the solution.
[14:56:16 CEST] <_fireion> Fyr, btw, I did not do make install. I was trying from built directory before installing. Can doing it possibly change anything ?
[14:56:40 CEST] <Fyr> I don't know.
[14:57:06 CEST] <Fyr> I tried to use FFMPEG Cuda, however, received an error, something like yours.
[14:57:35 CEST] <Fyr> since then I use only standard hwaccels implemented in Zeranoe's builds.
[14:57:50 CEST] <Fyr> they usually work without rain dances.
[15:03:44 CEST] <_fireion> So CUDA for encoding or decoding ? btw I'm filing report. I'm adding versions of everything I used except a huge load of packages I installed.
[15:03:59 CEST] <_fireion> (using apt-get)
[15:12:03 CEST] <_fireion> How do I attach log file to ticket ? It's not showing any upload button on the page.
[15:12:35 CEST] <Fyr> looks like you should use "code" or "spoiler".
[15:14:19 CEST] <_fireion> "spoiler" lol. Is there any recommended site to upload reports ?
[15:15:09 CEST] <_fireion> Oh. Got it . It allows uploading after clicking on create ticket button.
[15:17:28 CEST] <_fireion> Well here's it https://trac.ffmpeg.org/ticket/5625 . Any suggestions / additions ?
[15:18:17 CEST] <Fyr> _fireion, have you tried another pixel_format?
[15:18:29 CEST] <_fireion> I tried the one which they gave on their wiki
[15:18:33 CEST] <_fireion> That has to work.
[15:19:05 CEST] <Fyr> have you tried omitting this parameter?
[15:19:15 CEST] <Fyr> +profile?
[15:19:37 CEST] <_fireion> https://trac.ffmpeg.org/wiki/HWAccelIntro I tried this one under NVENC here .
[15:19:45 CEST] <_fireion> I will try that now.
[15:20:25 CEST] <Fyr> I meant, you should try default values first.
[15:21:04 CEST] <_fireion> Yes. ffmpeg -i input.mp4 -c:v nvenc_h264 -pixel_format yuv444p -preset default output.mp4 -report . This also gives same error .
[15:21:33 CEST] <Fyr> _fireion, could you omit -pixel_format and -preset options?
[15:22:12 CEST] <Fyr> use just -i and -c:v
[15:22:21 CEST] <_fireion> Still same error.
[15:23:06 CEST] <_fireion> So do you want me to add that to bug report ?
[15:23:36 CEST] <Fyr> >>Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[15:24:36 CEST] <Fyr> have you tried another encoder?
[15:24:55 CEST] <_fireion> The only nvenc encoder which is supported on my GPU is nvenc
[15:25:03 CEST] <Fyr> I recommend using standard h264 first.
[15:25:07 CEST] <_fireion> Ok.
[15:25:20 CEST] <_fireion> Worked.
[15:25:40 CEST] <Fyr> _fireion, so, standard H264 encoder works?
[15:25:43 CEST] <_fireion> Yes.
[15:26:02 CEST] <Fyr> have you tried -hwaccel nvenc option?
[15:26:03 CEST] <_fireion> nvenc_hevc is not supported. It is encoding right now.
[15:26:50 CEST] <Fyr> have you tried:
[15:26:50 CEST] <Fyr> $ ffmpeg -i input.mp4 -hwaccel nvenc output.mkv
[15:26:50 CEST] <Fyr> ?
[15:27:09 CEST] <_fireion> I will try now.
[15:28:18 CEST] <_fireion> Unrecognized hwaccel nvenc. supported vdpau vaapi
[15:29:11 CEST] <_fireion> I moved that option before -i. Only then it worked. Before moving it gave some other error.
[15:30:28 CEST] <_fireion> I tried vaapi and vdpau, they both did not work.
[15:32:49 CEST] <_fireion> VDPAU device creation on X11 display :0 failed.
[15:51:09 CEST] <Sokolio> <_fireion> VDPAU is a linux API by nVidia
[15:51:29 CEST] <Sokolio> And you mentioned working with Windows?
[16:21:51 CEST] <cyphix> Hi. I try to write a script that records my screen in good quality (pretty much HD). I use a first ffmpeg call to record a lossless video, and then compress it. The lossless call is the following: 'ffmpeg -f x11grab -r 30 -s 1920x1080 -i :0.0+0,0 -c:v libx264 -qp 0 -preset ultrafast -threads 0 lossless.mkv', and the second call, to compress the lossless video, is the following: 'ffmpeg -i lossless.mkv -an
[16:21:54 CEST] <cyphix> -c:v libx264 -preset medium -threads 0 -crf 18 testing.mkv'. But with this, I still end with a huge file, way too heavy to deal with long records. Does someone have any suggestions on what to change to keep a good quality but reduce the size?
[16:23:05 CEST] <agrathwohl> cyphix: Instead of `-preset ultrafast` use `-preset veryslow`
[16:23:25 CEST] <Sokolio> <cyphix> set bitrate (-b:v 5M)
[16:23:36 CEST] <Sokolio> for 5Mb/s
[16:27:52 CEST] <cyphix> agrathwohl: Oh yeah, the veryslow preset changes a lot!
[16:29:08 CEST] <Sokolio> how about specifying bitrate?
[16:29:37 CEST] <Sokolio> this has the most impact on size
[16:30:24 CEST] <cyphix> Sokolio: I'm testing it now. So I simply add -b:v 5M in my initial call?
[16:30:41 CEST] <Sokolio> Well, 20M is a Bluray quality video
[16:30:54 CEST] <Sokolio> 5-10 is terrestrial TV HD
[16:31:20 CEST] <Sokolio> if you take a slow preset 5M should look good anyway
[16:31:22 CEST] <c_14> Instead of setting a bitrate, just increase the crf on th esecond command
[16:31:37 CEST] <c_14> with libx264 crf > bitrate
[16:32:18 CEST] <Sokolio> crf is constant rate factor, but you need to experiment with the value, that's the main problem
[16:32:19 CEST] <cyphix> yeah, adding -b:v 5M doesn't change much
[16:32:43 CEST] <c_14> try setting the crf to like 25 or thereabouts
[16:32:49 CEST] <c_14> record a short video then check the qulaity/size
[16:32:58 CEST] <c_14> If the quality is good enough and it's too big increase the crf
[16:33:02 CEST] <cyphix> c_14: I'll do that now
[16:33:05 CEST] <c_14> if the quality isn't good enough decrease it
[16:33:09 CEST] <BtbN> Sokolio, NVENC needs a CUDA context, and can take CUDA frames as input.
[16:33:34 CEST] <BtbN> So it's at least related to CUDA.
[16:33:42 CEST] <Sokolio> It does, but just for memory transfer stuff
[16:35:25 CEST] <Sokolio> One allocates a buffer pool in GPU memory and that's pretty much it when it comes to NVENC <--> CUDA
[16:35:58 CEST] <BtbN> Well, you can't use NVENC without CUDA though. Even if you purely send software frames.
[16:35:58 CEST] <cyphix> c_14: wow, increasing crf makes a massive difference too. Thank you!
[16:36:59 CEST] <Sokolio> There's NVCUVENC too, which is purely CUDA, so you can use both at the same time
[16:37:22 CEST] <cyphix> should I change 'preset medium' to 'preset veryslow' for the second command too?
[16:37:34 CEST] <c_14> If you have the cpu time, yes
[16:37:52 CEST] <cyphix> the cpu time? You mean it will take longer to compress?
[16:38:15 CEST] <c_14> yes, you can choose between medium-veryslow depending on how much time you can give it
[16:38:25 CEST] <Sokolio> linx264 can go threaded
[16:38:28 CEST] <cyphix> ok, Ill run some tests
[16:38:50 CEST] <cyphix> it still looks pretty fast, so it should be fine with veryslow
[16:40:22 CEST] <cyphix> I'm not familiar with all this, but does the option '-threads' indicate the numnber of cpu cores used? If so, shouldn't I increase it?
[16:40:49 CEST] <c_14> 0 is automatic which is somewhere between 1.5 * numcpu and 1.1*numcpu or something (for libx264)
[16:40:59 CEST] <c_14> Also, for libx264 -threads 0 is default so you don't need to set it
[16:41:57 CEST] <cyphix> oh ok
[16:42:43 CEST] <cyphix> oh... I ran my tests with a mostly static screen. But if I try to record a running movie, it can't record it properly. Is it linked to the 'veryslow' option?
[16:44:08 CEST] <debianuser> cyphix: Also in your second command the quality/bitrate is mostly defined by -crf option. Default is -crf 23, I think. -crf 18 is a higher quality and size, -crf 50 is a very low quality but small size as well. Summary: preset ultrafast/superfast/veryfast/faster/fast/medium/slow/slower/veryslow/placebo - reduces size, but increases CPU; -crf 0-50 - reduces size and quality.
[16:44:50 CEST] <c_14> cyphix: you don't want to use veryslow on the first command
[16:45:03 CEST] <c_14> cyphix: make the preset faster until you can record in realtime
[16:46:14 CEST] <cyphix> Oh ok. So I define the first command in sort that I can record properly, and then I adjust the second command in order to get a reasonable size/quality output?
[16:46:20 CEST] <c_14> yes
[16:47:11 CEST] <cyphix> debianuser: And for the second command, the slower the preset, the smaller the size, but the longer to process it, right?
[16:48:11 CEST] <c_14> yes
[16:52:08 CEST] <cyphix> and so, finally, no bitrate change?
[16:52:33 CEST] <debianuser> -crf sets the bitrate
[16:52:39 CEST] <cyphix> oh yes
[16:54:31 CEST] <cyphix> my final result for a pretty good quality video of 10 seconds is 1.5M. Does it sounds reasonable for you or could it be better?
[16:54:45 CEST] <debianuser> -crf is sort of smart bitrate controller :) it attempts to adjust quality in a smarter way, giving more bits to things that need it and fewer bits to things that you most probably won't notice, so technically it's not "bitrate", it's "quality", but it affects bitrate
[16:57:46 CEST] <debianuser> As a rough guess I'd say it's very good, but size depends on the video A LOT. :) Low resolution video takes less space than high-res video, static video takes less space, video with low details takes low space, "big black nothing" video takes no space at all :)
[16:58:01 CEST] <cyphix> last question (hopefully): when I start recording, the first 3-4 seconds are lagged. It not an issue for long videos, but it could be annoying for short ones. Any idea where it could come from?
[17:00:06 CEST] Action: debianuser doesn't know about startup lag...
[17:00:14 CEST] Action: debianuser actually came here to ask a question... heh...
[17:01:39 CEST] <c_14> cyphix: try using -framerate 30 instead of -r 30
[17:03:59 CEST] <cyphix> c_14: oh indeed, it seems to solve it. Thanks again :)
[17:07:23 CEST] <debianuser> Hello. I'm recovering some accidentally deleted files... Got a large incomplete .3gp file, that was not working at all (no moov atom). I managed to rebuild it with some hacks to https://github.com/ponchio/untrunc (great tool btw!) But video and audio streams are going very out of sync (5-10 minutes after 1 hour). How can I convince ffmpeg to play video a little bit slower than audio?
[17:08:44 CEST] <c_14> you can try messing around with the container framerate using something like l-smash (may or may not work depending on the codec), you can make the audio play faster with the atempo filter and you can make the video slower with the setpts filter
[17:09:06 CEST] <c_14> Filtering requires reencoding so I'd probably speed up the audio rather than slowing down the video
[17:09:27 CEST] <c_14> Messing with the container settings would be better though since you don't have to reencode (if it works and your player supports that)
[17:10:03 CEST] <BtbN> Sokolio, NVCUVENC uses cuda kernels for encoding. It's horrible and slow. Nobody wants that.
[17:10:13 CEST] <BtbN> GPUs are just bad at de/encoding videos.
[17:17:04 CEST] <Sokolio> I was using nVidia Tegra's GPU and it was horrible
[17:17:35 CEST] <Sokolio> Now I'm using hardware de/encoders on i.mx6 and they work quite well
[17:18:36 CEST] <Sokolio> <BtbN>, the general rule is that hardware encoders have problems with maintaining quality
[17:18:53 CEST] <BtbN> nvenc is quite good at doing that, if you tell it to.
[17:20:23 CEST] <Sokolio> frankly, nvenc was so far the best h/w encoder I've seen
[17:20:41 CEST] <Sokolio> I havent used QuickSync though
[17:21:46 CEST] <debianuser> c_14: I tried to reencode with `-filter_complex setpts=PTS*1.07234`, but ffmpeg produced a file with weird interleaving - when seeking to 1 hour player(mplayer) gets 250 sec A-V desync and then slowly syncs back...
[17:26:23 CEST] <c_14> hmm, that with 3gpp output? have you tried using a different format?
[17:26:48 CEST] <debianuser> The output was to .mkv
[17:27:12 CEST] <c_14> have you tried any other format?
[17:34:15 CEST] Action: debianuser tries to repack into .avi... it takes some time...
[17:40:43 CEST] <debianuser> c_14: Just tried .avi (`./ffmpeg -i VID_fixed.mp4 -vcodec libx264 -preset ultrafast -acodec aac -filter_complex setpts=PTS*1.07234 VID_repack.avi`) - that works better in the player, but I still get "Badly interleaved AVI file detected - switching to -ni mode"
[17:42:31 CEST] <c_14> might be a bug/deficiency in ffmpeg that it won't properly reinterleave input with strange characteristics. Have you tried using something like l-smash/mkvtoolnix/gpac to remux the output?
[17:45:06 CEST] <vade> durandal_1707: regarding my filtering / eagain issue - if I modify the filter_audio.c example to use dynaudnorm filter I get a continuous stream of error EAGAINs
[17:48:11 CEST] <debianuser> c_14: haven't tried yet. I'll try... thanks for the setpts hint and idea to test other formats by the way! :)
[18:36:49 CEST] <nikk_> Hi! I am recording realtime from a webcam. ffmpeg outputs statistics during encoding with lines similar to http://pastebin.com/ENxQiHpQ . I wonder what the "speed=" part indicates and how it relates to the "fps=".
[18:39:59 CEST] <__jack__> fps is frame per second; speed is relative to realtime (1x = same as realtime, 2x = twice faster etc)
[18:40:20 CEST] <__jack__> there, you're slower than realtime, use another preset
[18:40:31 CEST] <nikk_> My impression is that "speed" is frames encoded per second (note that this is different from output fps) divided by incoming frames per second
[18:40:42 CEST] <nikk_> yeah, that was what I was afraid of
[18:42:09 CEST] <nikk_> @__jack__ do you know if frames are dropped or queued in RAM?
[18:42:47 CEST] <c_14> both
[18:43:16 CEST] <c_14> they're usually queued but occasionally dropped
[18:43:18 CEST] <nikk_> Is there a way to query or set the queue size?
[18:43:23 CEST] <c_14> ffmpeg will keep a count of the amount of dropped frames
[18:43:29 CEST] <c_14> your output line looks like no frames were dropped
[18:44:09 CEST] <nikk_> do you know how to spot if any frames were dropped? I dont see a "dropped=0"
[18:44:37 CEST] <__jack__> nikk_: at one time, frames WILL be dropped, you can't keep them forever, the queue is limited (by hardware, at least)
[18:45:07 CEST] <c_14> nikk_: the drop= output only shows up if frames were dropped
[18:46:28 CEST] <nikk_> __jack__: unless resources available for encoding varies with time, but I guess thats pretty uncommon
[18:46:35 CEST] <nikk_> c_14: thanks, thats good to know
[18:47:00 CEST] <nikk_> Also, does anybody know if "fps=" incoming or outgoing frames per second
[18:47:44 CEST] <nikk_> "fps=7.3" (from the link) is inconsistent with my input source so that indicates that it should be output fps
[18:48:38 CEST] <__jack__> nikk_: the buffer is only useful to handle temporary slowdown; for live, your overall power MUST be higher than the required encoding power; else, it will crash
[18:49:14 CEST] <c_14> nikk_: the current number of frames encoded per second
[18:50:37 CEST] <__jack__> nikk_: in your case, you should use a more powerfull computer, or reduce the resolution, or use a lighter preset (that last advice is probably the best one, it will just output a bigger file; you can still reencode it asynchronously if needed)
[18:51:38 CEST] <nikk_> c_14: so "output" in my terminology. Thats good to know, thanks!
[18:53:23 CEST] <nikk_> __jack__: I'm stuck with the hardware I'm afraid, and would preferably not sacrifice resolution
[18:54:15 CEST] <__jack__> nikk_: then preset is your solution
[18:54:35 CEST] <nikk_> __jack__: Im using "-c:v libx264 -qp 0 -preset ultrafast", I basically just want to dump it on the harddrive without ignoring really low hanging space saving fruit
[18:54:42 CEST] <__jack__> (or another codec, if relevant)
[18:54:50 CEST] <nikk_> __jack__: do you have any other lossless tips?
[18:55:14 CEST] <c_14> nikk_: try ffv1 or maybe huffyuv
[18:55:14 CEST] <__jack__> nikk_: do you need to change the codec ? else, just -c:v copy
[18:55:38 CEST] <c_14> -c:v copy would use rawvideo (for desktop capture) you probably don't want that
[18:55:48 CEST] <kepstin> encoding in lossless is gonna bit a bit slow if only because of the data size that has to be fed through the encoder. x264 is often faster in a mid to high quality lossy mode :/
[18:56:26 CEST] <__jack__> c_14: is the webcam seen as a screen capture ? never used that kind of device
[18:56:57 CEST] <c_14> depends on the webcam, usually either mjpeg, H.264 or raw
[18:57:22 CEST] <c_14> if the webcam does one of the first two, just use -c:v copy
[18:57:28 CEST] <nikk_> __jack__: I'm on Linux, so it is exposed through Video4Linux /dev/video0
[18:57:51 CEST] <nikk_> c_14: yeah, mine does MJPG or YUV
[18:58:57 CEST] <nikk_> It's kind of wierd that even with MPJG and "-c:v copy" I get roughly "speed=0.75". Any thoughts on that?
[19:00:09 CEST] <nikk_> keptstin: that's a good tip, I'm planning on reencoding lossly later anyway
[19:03:39 CEST] <thebombzen> nikk_: sometimes you get really bad speeds if your hard drive is slow
[19:03:52 CEST] <thebombzen> because it can't read form the hard drive fast enough
[19:04:17 CEST] <thebombzen> although mjpeg's compression should be good enough that you don't run into that issue
[19:04:50 CEST] <AlexQ> Hi
[19:04:55 CEST] <nikk_> or write, as my case might be. My webcam input is probably only shuttled through RAM
[19:05:51 CEST] <durandal_1707> vade: see also mpv lavfi code
[19:06:03 CEST] <AlexQ> I'm converting 10 bit HEVCs to 8 bit AVCs. Did that before and got cool results straight away, but now I have some files where black is converted to ugly gray and the contrast is visibly reduced. What should I do?
[19:08:08 CEST] <AlexQ> HEVC (Main 10) yuv420p10le(tv) ffprobe says.
[19:08:57 CEST] <JEEB> any other colorimetry info on the input other than that?
[19:09:21 CEST] <JEEB> because that should tell that the input is limited range
[19:09:44 CEST] <JEEB> and thus it shouldn't get by default be a case of mismanaged range
[19:10:16 CEST] <AlexQ> VLC plays it as gray as well (but on 8-bit laptop screen). It is defo something with black level, even black screens are dark gray.
[19:10:29 CEST] <JEEB> the bit depth shouldn't matter
[19:10:39 CEST] <JEEB> also for a rendering reference, I recommend mpv's opengl renderer
[19:10:50 CEST] <JEEB> which is its default renderer
[19:11:15 CEST] <JEEB> like, 10=>8bit does lose precision but it shouldn't make blacks grey :P
[19:11:27 CEST] <AlexQ> Of course, it worked well before
[19:11:45 CEST] <JEEB> post full ffprobes of input and output in a pastebin/gist
[19:11:47 CEST] <AlexQ> I think the encode might have improper color range metadata or sth
[19:11:47 CEST] <JEEB> and link here
[19:13:08 CEST] <AlexQ> Well, there isn't anything else relevant in ffprobe on the input other than what I already pasted here, unless you want me to run ffprobe with some additional options?
[19:13:18 CEST] <JEEB> and please test with mpv's opengl renderer because that's what I trust enough :)
[19:13:28 CEST] <JEEB> AlexQ: so there's no bt709/whatever info noted?
[19:13:40 CEST] <JEEB> try `ffmpeg -i file` instead then
[19:13:54 CEST] <JEEB> (without further options it will just give you info)
[19:14:29 CEST] <AlexQ> Stream #0:0(eng): Video: hevc (Main 10), yuv420p10le(tv), 1920x1080, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default) that's all, nothing of importance in metadata. Will check with ffmpeg -i instead
[19:15:05 CEST] <AlexQ> Same as with ffprobe
[19:15:17 CEST] <JEEB> try ffmpeg with -v debug
[19:15:21 CEST] <AlexQ> So what, the color space info is missing?
[19:15:59 CEST] <thebombzen> speaking of 10bit, does anyone know if x265 has the annoying problem where 10-vs-8-bit is chosen at compiletime?
[19:16:26 CEST] <JEEB> no, you just have to enable 16bit mode during compilation and it supports 8-12
[19:16:59 CEST] <JEEB> of course it will use less optimized code for the 8bit mode but it will encode 8 and 10 (and 12)
[19:17:12 CEST] <JEEB> AlexQ: so both look like that?
[19:17:17 CEST] <JEEB> I'd like to see input and output
[19:17:42 CEST] <JEEB> so far I've seen nothing that would make something misguess the YCbCr range
[19:18:03 CEST] <JEEB> also you might want to post the full transcoding ffmpeg command line and terminal output
[19:18:06 CEST] <JEEB> *pastebin
[19:18:15 CEST] <AlexQ> Can I just expand the range manually? Just check what that black is
[19:18:22 CEST] <AlexQ> With some filter?
[19:18:36 CEST] <JEEB> yeah, but you don't want full range YCbCr
[19:18:51 CEST] <JEEB> because most players don't support full range and the default metadata is limited
[19:19:18 CEST] <JEEB> so please post (pastebin/gist) ffprobe/ffmpeg output of input and output and the command line + terminal output of the command line
[19:19:30 CEST] <JEEB> that should help anyone who wants to help see what is happening in your transcoding :P
[19:20:19 CEST] <AlexQ> Can't I run raw decode with decoding filter to tell me something about the colors, as there is stats filter for audio?
[19:20:46 CEST] <AlexQ> I don't think you're gonna find anything in these pastes, but I can paste if you want...
[19:21:09 CEST] <JEEB> please do what I requested and we can then go into that. you can add a keyboard shortcut for range switching
[19:21:35 CEST] <JEEB> I added it to my mpv configuration because one of the sources of clips I used to watch just failed at transcoding
[19:21:42 CEST] <JEEB> (or at least flagging their content correctly)
[19:21:50 CEST] <JEEB> mpv being https://mpv.io/
[19:22:22 CEST] <AlexQ> Can't I switch range in VLC?
[19:22:59 CEST] <thebombzen> does anyone know if x265 is still at https://bitbucket.org/multicoreware/x265 or if they've moved to a Git repo?
[19:23:22 CEST] <JEEB> AlexQ: to be completely honest you cannot trust most of th evideo renderers in vlc
[19:23:40 CEST] <JEEB> mpv is just the one I know that Does Things Right as far as video rendering is considered
[19:23:54 CEST] <JEEB> as long as the opengl renderer works
[19:23:57 CEST] <nikk_> thebombzen: http://x265.org/ says "Source code is available on https://bitbucket.org/multicoreware/x265"
[19:23:58 CEST] <JEEB> if you are on windows there are windows builds
[19:24:27 CEST] <thebombzen> AlexQ: I second the recommendation of MPV
[19:24:32 CEST] <JEEB> AlexQ: I was at the hackathlon where we finally added some metadata passing for colorimetry for vlc 3.0 :P
[19:25:05 CEST] <JEEB> + there's talk that mpv might just release its opengl video renderer as a separate library so in the future vlc might use it
[19:25:21 CEST] <Zeranoe> Is it possible to reconstruct a FLV/F4V stream from following the TCP packets of the RTMP connection?
[19:25:54 CEST] <JEEB> but currently - as long as the opengl renderer works on your system - it is the best thing that I know of that could be used as a "reference render" of a video clip
[19:27:13 CEST] <JEEB> also the color range switching is "l vf toggle format=colorlevels=full" in my mpv's input.conf
[19:28:28 CEST] <thebombzen> I use ffplay for testing because it's lightweight, but I sometimes run into split frames
[19:29:03 CEST] <AlexQ> Any working ppa for Ubuntu for mpv? I got "W: Failed to fetch http://ppa.launchpad.net/mc3man/mpv-tests/ubuntu/dists/wily/main/binary-amd64/Packages  404  Not Found" on that one
[19:29:31 CEST] <thebombzen> mpv is the best I've seen
[19:30:27 CEST] <AlexQ> Can I just use mpv from Ubuntu Wily's repo, or is it too old for that purpose?
[19:30:46 CEST] <JEEB> AlexQ: anyways it would be nice if you could help us help you :)
[19:30:46 CEST] <JEEB> including the pastes I requested onto a site of that type that you prefer
[19:31:10 CEST] <AlexQ> With -v debug or not?
[19:31:13 CEST] <JEEB> it should work for some purposes
[19:31:23 CEST] <JEEB> and no, I don't think there's a decent ppa
[19:31:30 CEST] <JEEB> everyone who cares enough for latest uses mpv-build
[19:31:45 CEST] <JEEB> https://github.com/mpv-player/mpv-build
[19:32:03 CEST] <JEEB> AlexQ: no -v debug needed I think
[19:32:27 CEST] <JEEB> AlexQ: also you totally should move to xenial at some point
[19:33:21 CEST] <AlexQ> Yeah, going to backup and check how satisfied I am with an upgrade, otherwise going to make clean install
[19:33:57 CEST] <JEEB> but first just let's get your FFmpeg issues dealt with :)
[19:36:14 CEST] <AlexQ> I guess that is the encodes' fault, but guess that would be easy to fix
[19:36:30 CEST] <JEEB> anyways, focus on the logs
[19:36:34 CEST] <JEEB> and the command line you used
[19:37:10 CEST] <AlexQ> Could you just make a guess what is wrong with that input file that it is decoded by VLC or transcoded by ffmpeg with a limited black level and tell me how I could try to fix that? Are there many possibilities or what?
[19:37:34 CEST] <JEEB> there are several components that can do stuff wrong, but I just can't know by geusswork
[19:37:41 CEST] <JEEB> I'm not a goddamn psychic
[19:37:53 CEST] <JEEB> to see your command lines and terminal output or whatever that would actually give me knowledge
[19:38:18 CEST] <AlexQ> ffmpeg -i "video.mkv" -i "audio.wav" -map 0:0 -map 1:0 -c copy -c:v libx264 -crf 18 -preset veryfast -tune film "output.mkv"
[19:38:47 CEST] <JEEB> and the basic terminal output of that as well as the terminal outputs of the input and output files' ffprobe
[19:39:07 CEST] <JEEB> thank you for the command line and I hope you didn't remove too many bits of it for pasting purporses :P
[19:39:44 CEST] <JEEB> (file names I don't give a flying duck in most cases, but some people have weird tendencies of thinking they know I require and what I don't)
[19:40:20 CEST] <AlexQ> Nah, it is exactly how I used that, just shortened filenames. But for that transcode terminal output, I don't need to transcode the whole file again, do I :D?
[19:40:30 CEST] <AlexQ> just a bit?
[19:40:48 CEST] <JEEB> just enough for it to get started
[19:40:56 CEST] <JEEB> output file name can be /dev/null if you want to
[19:46:46 CEST] <thebombzen> AlexQ: you can also use -f null to discard the output
[19:46:55 CEST] <thebombzen> rather than having muxing overhead with -f matroska /dev/null
[19:47:10 CEST] <JEEB> anyways, not like the transcode has to finish
[19:47:28 CEST] <JEEB> it just has to start up and get set and then you can kill it off
[19:49:54 CEST] <AlexQ> Input transcode: http://paste.ubuntu.com/17150110/
[19:50:37 CEST] <AlexQ> (I can download newer build of ffmpeg if you want, that is on a faster Windows machine that I used to transcode that stuff)
[19:51:48 CEST] <JEEB> yeah, that ending up incorrect range is really weird... you're doing limited to limited
[19:52:01 CEST] <JEEB> unless you specifically note that "hey this output is full range btw"
[19:52:18 CEST] <JEEB> you can install the wily version of mpv I think and see how that looks with `mpv file.mkv`
[19:52:35 CEST] <JEEB> (just make sure that it's using the opengl renderer
[19:52:42 CEST] <JEEB> (it's the default)
[19:53:18 CEST] <AlexQ> both input and output play with gray instead of black; as I said, I guess the original input file is messed up... So how can I fix it?
[19:53:32 CEST] <AlexQ> on mpv*
[19:53:35 CEST] <JEEB> with mpv?
[19:54:18 CEST] <JEEB> but yes, now that would make sense :)
[19:54:22 CEST] <JEEB> if both have eff'd up range
[19:58:25 CEST] <AlexQ> I have around RGB(15,15,15) (compression noise or sth, not ideally uniform color) on black screens instead of around 0,0,0
[19:59:02 CEST] <AlexQ> so what should I do? Apply some metadata, force other color range for the input file before transcoding? I don't mind transcoding again
[20:00:03 CEST] <AlexQ> That's on mpv. Haven't tried that range switch in mpv, don't know how to enable that, exactly
[20:03:28 CEST] <JEEB> AlexQ: https://mpv.io/manual/master/#files
[20:03:33 CEST] <JEEB> create an input.conf
[20:03:36 CEST] <JEEB> and put that one line into that
[20:04:16 CEST] <JEEB> `l vf toggle format=colorlevels=full`, which binds l (small L) for toggling full/limited range YCbCr input
[20:05:19 CEST] <AlexQ> so that will bind that to 'l' key?
[20:05:41 CEST] <AlexQ> aa, okay, sorry, didn't check your replies
[20:05:57 CEST] <AlexQ> ~/.config/mpv/input.conf on my Ubuntu I guess
[20:08:01 CEST] <AlexQ> JEEB: Well, it just becomes even worse when I switch to full range in mpv, which was kinda what you probably guessed will happen I guess?
[20:12:19 CEST] <JEEB> AlexQ: yeah :P if you have grey in limited range then it becomes even worse with full range
[20:12:36 CEST] <JEEB> (as in, if you just take it in as full range, because suddenly you're even more away from the black/white)
[20:12:46 CEST] <JEEB> or that thing just isn't black - that can be the case as well
[20:14:38 CEST] <kepstin> so basically, the problem is that at some point, the video containing limited-range data was interpreted as if it was full range, then converted to limited range (again)
[20:15:10 CEST] <JEEB> possibly, sometimes what you think should be black is actually grey etc
[20:15:22 CEST] <JEEB> of course the fact that there's no colorimetry metadat in the input either is kind of wonky
[20:15:24 CEST] <AlexQ> The whole file looks like grayish because of that. There is no black at all
[20:15:48 CEST] <kepstin> it should be fixable during a transcode using some of the options on the 'scale' filter in ffmpeg, but I'm guessing the actual issue happened prior to you inputting the video into ffmpeg
[20:16:09 CEST] <JEEB> I don't think the scale filter can fix this :P
[20:16:26 CEST] <JEEB> I don't think it can even do full<=>limited range conversions properly
[20:16:38 CEST] <JEEB> which is why I tend to poke the zscale filter for that
[20:16:54 CEST] <JEEB> scale = swscale = people don't want to touch it
[20:16:59 CEST] <kepstin> hmm. if it does do the conversion properly, you should be able to use the scale filter with the in_range and out_range options to do the conversion
[20:17:10 CEST] <JEEB> that's a whole big IF
[20:17:23 CEST] <AlexQ> let's just try, it doesn't need to be perfect
[20:17:25 CEST] <JEEB> also in this case a normal range conversion wouldn't help I think
[20:17:31 CEST] <AlexQ> I just don't want that stuff to be awfully gray :D
[20:17:37 CEST] <JEEB> just grab another rip
[20:17:57 CEST] <kepstin> hmm. the trick is that you need to do a limited range to full range conversion, then interpret the output of that as limited range.
[20:18:25 CEST] <AlexQ> Can't I just do it as a color filter?
[20:18:37 CEST] <AlexQ> Just expand brightness range?
[20:18:58 CEST] <AlexQ> map input brightness to output brightness so that it is correct
[20:19:55 CEST] <JEEB> at this point I would be surprised if the range is the only thing that's fucked up, so I just recommend you go grab another copy of that piece ;)
[20:20:35 CEST] <JEEB> because most probably you have on your hands something that isn't the only available copy of that piece
[20:20:55 CEST] <JEEB> if it is and you have destroyed the master then I give you the pink elephant award of course
[20:21:09 CEST] <kepstin> you could probably do that, but you want to make sure you use a color/levels filter operating on the YUV data rather than converting to RGB. But yeah, better to get a source that hasn't been messed up in teh first place
[20:21:23 CEST] <kepstin> even if you fix it, it's gonna have additional banding at least :/
[20:22:50 CEST] <vade> durandal_1707: ok, im confused as to how the beavior of the examples / vs EAGAIN works. if I use filtered_audio example, and I request a time of 20, I get 937 requested frames to the buffer src. If I use the provided filter chain, I get 937 frames out. However, if I replace aformat with say, dynaudnorm I get 8 filtered frames processed
[20:23:36 CEST] <durandal_1707> depends on filter
[20:24:40 CEST] <vade> laskjdf
[20:29:12 CEST] <kepstin> AlexQ: looks like doing '-vf scale=in_range=pc:out_range=tv' should do a reasonable job of fixing the levels in your file.
[20:29:18 CEST] <vade> so the nb_sample count of a returned filtered AVFrame* changes from under me?
[20:29:50 CEST] <vade> even if I request the sink frame size via av_buffersink_set_frame_size ?
[20:30:29 CEST] <AlexQ> kepstin: Will it work without actually scaling the video? As I found some bug report about that, but it is 2yrs old or so... Will try, thanks vmuch!
[20:30:51 CEST] <kepstin> AlexQ: yeah, if you don't provide any height or width, the scale filter doesn't change the video size
[20:31:14 CEST] <AlexQ> kepstin: Yes, but will it apply the input/output range conversions then?
[20:31:22 CEST] <kepstin> it does, yes.
[20:31:29 CEST] <AlexQ> Good, cause it apparently used not to
[20:31:50 CEST] <kepstin> the 'scale' filter is rather poorly named, it's used to do all of the internal color and pixel format conversions in ffmpeg :/
[20:34:09 CEST] <AlexQ> kepstin: The result was just the opposite, it got it worse (brighter)
[20:34:18 CEST] <AlexQ> kepstin: Any fix for that?
[20:34:26 CEST] <kepstin> oh, oops, i got it backwards
[20:34:30 CEST] <kepstin> switch the 'pc' and 'tv'
[20:35:09 CEST] <AlexQ> So that actually does anything else than changing stream tags/metadata/whatever?
[20:36:58 CEST] <AlexQ> kepstin: Yeah, it works nicely, thanks! JEEB: That's what I wanted by saying 'just guess and try if it works'.
[20:37:27 CEST] <kepstin> AlexQ: that filter changes the contents of the image data *without* changing any metadata
[20:37:53 CEST] <kepstin> so the output video is still the standard "tv" range, but the image data has been adjusted so that black/white (and the colors too) are at the right levels.
[20:38:50 CEST] <AlexQ> Ooh, okay
[20:39:12 CEST] <AlexQ> So how did you guys know that the input file was tagged as a 'tv' range?
[20:39:58 CEST] <kepstin> AlexQ: based on your ffmpeg output. It said "yuv420p10le(tv)" on the line for the input video stream.
[20:41:32 CEST] <kepstin> you want most video to be in the 'tv' range; that's the standard for video, and it's what basically all players and decoders expect
[20:41:50 CEST] <kepstin> it's just that for some reason, your input video had been converted from pc to tv range twice.
[20:43:51 CEST] <cyphix> Hi again. After the former discussion, I use 'ffmpeg -f x11grab -framerate 30 -s 960x1042 -i :0.0+2880,37 -c:v libx264 -qp 0 -preset faster -threads 0 lossless.mkv' to record my screen. But I just realized the x265 was available for ffmpeg, and apparently might be a better compression codec. Unfortunaltey, the same command, with libx265 instead of libx264 doesn't work. Would it be wise to try to modify my
[20:43:54 CEST] <cyphix> command to use x265? What should I do to make it work?
[20:44:45 CEST] <llogan> cyphix: unfortunately, "doesn't work" is not descriptive
[20:45:00 CEST] <cyphix> llogan: oh yes sorry. Let me show you the errors I get
[20:45:11 CEST] <thebombzen> cyphix: I recommend utvideo inside matroska for screenrecording
[20:45:30 CEST] <llogan> cyphix: please provide a link to a pastebin site to show the complete console output (and include the command)
[20:46:37 CEST] <cyphix> llogan: here it is: https://p.cyphix.org/view/7b63c428
[20:47:05 CEST] <cyphix> thebombzen: oh? I'm not familiar with it. What does it change?
[20:47:18 CEST] <cyphix> we are talking about the container, right?
[20:47:28 CEST] <thebombzen> utvideo is a lossless video codec
[20:47:39 CEST] <thebombzen> that's designed to encode quickly
[20:47:56 CEST] <thebombzen> unlike ffv1 which is designed to be efficient
[20:49:14 CEST] <cyphix> thebombzen: well, I get very nice results with a very reasonable size with this. Would utvideo be competitive in term of file size?
[20:49:36 CEST] <thebombzen> I haven't done a full comparison. That's just what I use
[20:49:40 CEST] <kepstin> cyphix: x265 is a different codec from x264, so the options are different
[20:49:59 CEST] <kepstin> cyphix: to do lossless x265, you need to use '-x265-params lossless=1' iirc
[20:50:14 CEST] <cyphix> thebombzen: I might try it then, but I'll first try to make x265 work if possible, it seems promising
[20:50:30 CEST] <thebombzen> something I need to check out as well
[20:50:36 CEST] <kepstin> cyphix: also, if you read that output that you pasted, it states exactly what the problem causing the error is
[20:50:53 CEST] <kepstin> cyphix: and also, you'll probably find that x265 is even slower than x264 :)
[20:51:09 CEST] <cyphix> kepstin: Ah ok. Could you help me find the correct replacements needed?
[20:51:47 CEST] <cyphix> kepstin: You mean it is a bad solution for direct capture?
[20:52:14 CEST] <kepstin> cyphix: I would not use a software x265 encoder for direct capture, no.
[20:52:54 CEST] <kepstin> (btw, if you *actually* want lossless capture of an rgb screen image with x264, you should use '-c:v libx264rgb')
[20:53:26 CEST] <cyphix> kepstin: Ok I see. But in order to record my screen, I first record it lossless, and then compress it with a second ffmpeg call. Would it be interesting to "convert" the lossless output into x265?
[20:54:13 CEST] <kepstin> cyphix: it might save a little bit of space, and contribute a bit extra to global warming. up to you :/
[20:54:19 CEST] <cyphix> kepstin: well, I don't search for lossless per se. I just want a good quality recording, for a good size
[20:54:36 CEST] <kepstin> then you probably don't want lossless
[20:54:40 CEST] <kepstin> lossless != good size :)
[20:55:18 CEST] <cyphix> kepstin: That's why I then compress it with (currently) this command: ffmpeg -i lossless.mkv -an -c:v libx264 -preset faster -threads 0 -crf 25 test.mkv
[20:55:26 CEST] <kepstin> If you just want "good quality, good size", then pick a setting for -crf that you find ok. For 8-bit x264, maybe something around 14?
[20:55:59 CEST] <kepstin> cyphix: and you can obviously make the file smaller by using a slower preset, if you're doing a re-encode after capturing.
[20:56:43 CEST] <cyphix> kepstin: Indeed, but 'faster' seemed to be a good compromize. Otherwise, it will take too much time compressing it if the video is long.
[20:57:31 CEST] <kepstin> if that's what your opinion is, then you probably don't want to use x265 :) That falls into the "you can spend more time to get smaller files" category as well.
[20:58:19 CEST] <cyphix> kepstin: Ah ok. I didn't know, and it's indeed a factor I have to take into account. I'll stay with my currenct settings then. Thank you for your advices!
[21:01:08 CEST] <AlexQ> Sorry, I lost connection. Don't know if my messages were received.
[21:01:58 CEST] <kepstin> AlexQ: got nothing after the 'So how did you guys know...'
[21:02:56 CEST] <AlexQ> kepstin: So my output file is "yuv420p" on ffprobe, no parenthesis with (tv) like input. It was supposed to be tagged as TV range to have the desired effect; is it TV range then or not/
[21:02:56 CEST] <AlexQ> ?
[21:03:08 CEST] <kepstin> AlexQ: it's tv range
[21:03:28 CEST] <JEEB> tv range is the default for YCbCr
[21:03:38 CEST] <JEEB> for RGB full ("pc") range is default
[21:04:21 CEST] <AlexQ> kepstin: Can I run that filter twice in a single pass? I'd like to see what happens then
[21:05:34 CEST] <kepstin> AlexQ: each time you run that filter, it'll expand the range. You'll get contrast stretched and black/white clipped.
[21:06:25 CEST] <kepstin> iirc, it'll also mess with the colors in weird ways
[21:06:43 CEST] <kepstin> (make stuff more saturated, I think)
[21:06:56 CEST] <AlexQ> kepstin: I guess so. That is strange; I checked on MX Player on my Android phone and it almost certainly is black when it was supposed to be black I guess (black screen between scenes, didn't check credits background, didn't transcode yet)
[21:07:08 CEST] <AlexQ> kepstin: But the same file on VLC on a PC seems to have gray there xD
[21:07:42 CEST] <kepstin> AlexQ: it's hard to tell on phones, they often do a bunch of extra video processing and have variable backlight, etc.
[21:08:14 CEST] <JEEB> yeah, also mx player is known for having optimized its rendering instead of focusing on being correct
[21:08:16 CEST] <AlexQ> kepstin: But mpv opens up with TV range by default. It seems that that VLC plays that video with full range
[21:08:33 CEST] <JEEB> https://github.com/mpv-android/mpv-android/releases
[21:08:40 CEST] <JEEB> you can also try this if you want to .p
[21:08:49 CEST] <AlexQ> I'm talking about desktop mpv now
[21:09:07 CEST] <AlexQ> on my Ubuntu and VLC on Win7. That is strange, isn't it?
[21:09:25 CEST] <JEEB> vlc has tons of renderers
[21:09:29 CEST] <JEEB> which are of different quality
[21:09:54 CEST] <AlexQ> maybe using accelerated renderer on that Windows machine or sth
[21:10:01 CEST] <AlexQ> with messed up range
[21:10:01 CEST] <JEEB> also as I said, VLC used to pass very little stuff to the renderer before, I was at the hackathlon where people added more support :P
[21:10:20 CEST] <JEEB> there's also https://mpv.srsfckn.biz/ if you want mpv for windows
[21:11:01 CEST] <kepstin> I found out recently that when you pause a youtube video on an ipad, it displays out of range colors: https://twitter.com/kepstin/status/722869226940157953 :)
[21:11:05 CEST] <AlexQ> never play any videos there, just used that machine for encoding and thought it is not good still (there was improvement from the input file, but it was still gray where it wasn't supposed to be). Guess there was that conversion, but still treated as full range.
[21:11:54 CEST] <JEEB> just linking for reference. mpv's rending chain from decoder to renderer seems to be the least retarded one
[21:12:03 CEST] <JEEB> not that it can't have bugs
[21:12:15 CEST] <JEEB> but it definitely is my go-to reference for "my picture looks weird" kind of things
[21:12:31 CEST] <JEEB> if it looks weird in a modern mpv binary, the video is most probably somehow derped
[21:12:52 CEST] <AlexQ> Thanks guys :) Dunno who was encoding that they didn't check at least the first file before encoding the rest
[21:13:22 CEST] <AlexQ> Just out of curiosity: is it applying that mapping before converting to 8 bit?
[21:14:10 CEST] <kepstin> AlexQ: not sure. Would have to see the output of that ffmpeg command with '-v verbose' to know where it is doing the format conversions
[21:14:11 CEST] <JEEB> if there is no range change the bit dpeth conversion should be relatively simple + dithering, no real color change should happen (of course, we're talking of swscale so there be dragons)
[21:19:36 CEST] <kepstin> AlexQ: looks like with that filter setup, the same swscale invocation is changing the color range and bit depth at the same time. so who knows :/
[21:22:19 CEST] <kepstin> (you could do it explicitly as two steps with e.g. -vf scale=in_range=tv:out_range=pc,format=yuv420p10le,format=yuv420p )
[21:22:45 CEST] <kepstin> (it'll auto-insert a second 'scale' filter between the two format= things to do the actual conversion)
[21:22:53 CEST] <AlexQ> kepstin: Isn't there a rule in ffmpeg that automatically applied filters are added on the end of the filter chain?
[21:23:36 CEST] <kepstin> AlexQ: no, scale filters are auto-inserted in various places through the chain as needed depending on the supported input/output formats of various filters.
[21:24:12 CEST] <AlexQ> kepstin: Mhm. Should have checked that maybe, before converting; there could be some difference in quality
[21:24:36 CEST] <kepstin> actually, in this case, '-vf scale=in_range=tv:out_range=pc,format=yuv420p10le' would do the same thing as the other command I gave, since there's an implicit format conversion at the end because of the selected output codec.
[21:25:42 CEST] <AlexQ> kepstin: So you're saying that -v verbose won't tell me how my videos are actually filtered with my non-explicit command line?
[21:26:11 CEST] <AlexQ> kepstin: I mean, with implicit pixfmt conversion
[21:26:36 CEST] <kepstin> AlexQ: with just '-vf scale=in_range=tv:out_range=pc', it's doing both the 10 to 8bit and color range conversion in "one step" using swscale. But I don't know what that actually does internally.
[21:34:07 CEST] <ssinfod> Hello, I'm trying to record a video with opencv on the Raspberry Pi 2 and I have this message when my video reaches around 300MB:
[21:34:09 CEST] <ssinfod> [mpeg4 @ 0x21d9580] get_buffer() failed (-12 (nil))
[21:34:26 CEST] <ssinfod> Any idea what is wrong ?
[21:34:38 CEST] <ssinfod> This apprears in the console.
[21:35:05 CEST] <ssinfod> I suspect there is a problem with the video encoding/compression but I don't know where to start looking !
[21:35:43 CEST] <ssinfod> My programm is using OpenCV 2.4.9 on the RPI2. It is in C.
[21:36:01 CEST] <kepstin> AlexQ: either I'm horribly misunderstanding the swscale code, or it converts the video from 12 to 16bits, applies the range adjustment, then converts from 16 to 8 bits.
[21:36:51 CEST] <AlexQ> kepstin: Huh. Thanks :)
[21:51:08 CEST] <AlexQ> C'ya
[22:37:33 CEST] <grotesk> Hey guys, does anyone have a good c-code example for a pure stream copy?
[22:38:29 CEST] <grotesk> I'm already trying to get it with ffmpeg_g, but i'm not that skilled :(
[22:38:42 CEST] <Nobgul> HI all I have a problem with encoding a 1080p video down to a lower quality, The encode works and the video will play but a peice of software i am using nimble stream says that "failure to load mp4 file structure" I have pasted the exact ffmpeg sytax i am using here http://pastebin.com/JRBMzqzi any help would be greatly appriciated.
[22:39:13 CEST] <Nobgul> I forgot to mention i am using the latest ffmpeg on cent os 7
[22:39:51 CEST] <__jack__> Nobgul: drop the strict experimental (won't help for your issue, but still)
[22:40:38 CEST] <Nobgul> Ok should i try the reencode with that or do you think there may be larger issues?
[22:41:11 CEST] <Nobgul> Ah i read your answer wrong sorry.
[22:41:11 CEST] <__jack__> don't think it'll change the issue
[22:42:02 CEST] <__jack__> you may want to add "-movflags faststart", maybe, dunno
[22:42:34 CEST] <Nobgul> I am willing to try just about anything
[22:42:48 CEST] <BtbN> Well, you are writing an flv file with an mp4 extension.
[22:43:49 CEST] <Nobgul> Thats what i had said to the person who helped me and he said that i need to tell it what type of file to write. so should i remove the -f flv? or replace it with -f mp4?
[22:44:20 CEST] <thebombzen> Nobgul: depends on whether you want to write an mp4 file or an flv file
[22:44:26 CEST] <thebombzen> FFmpeg's smart enough to detect the file extension
[22:44:33 CEST] <Nobgul> mp4
[22:44:43 CEST] <thebombzen> also you didn't give a video bitrate, so FFmpeg will assume 200 kbps. I assume that's too low for you
[22:44:54 CEST] <BtbN> if you omit -f it will figure out the format from the extension.
[22:45:01 CEST] <Nobgul> ok so ill remove the -f flv and the strict.
[22:45:30 CEST] <Nobgul> well the original is 1080p i am creating 360 480 and 720 from it.
[22:45:30 CEST] <thebombzen> Nobgul: also because you're using libx264, you might want to read the x264 encoding guide
[22:45:51 CEST] <thebombzen> https://trac.ffmpeg.org/wiki/Encode/H.264
[22:45:53 CEST] <BtbN> you realize that 1080p is 16:9, while that is 4:3?
[22:45:53 CEST] <thebombzen> Read that.
[22:46:52 CEST] <thebombzen> yea. you probably want 640x360
[22:47:06 CEST] <thebombzen> you can use -vf scale=-1:360 and it will automatically scale it to have the same aspect ratio, but be 360p
[22:47:07 CEST] <BtbN> or just -1:360
[22:47:19 CEST] <Nobgul> I wasnt so much concerned with the bitrate or aspect ratio, as much as getting a proper encode that works with the software, I can fix the rest after if you knwo what i mean.
[22:47:39 CEST] <Nobgul> Ah sweet thanks for that tip.
[22:48:45 CEST] <thebombzen> but yea. FFmpeg recognizes file extension. you only need to use something like -f mp4 if you're not writing to a file with the .mp4 extension
[22:49:21 CEST] <Nobgul> I thought so and was told i was wrong.. Thats what i get for not just comming here and asking for help.
[22:49:37 CEST] <thebombzen> -f flv would force it to be an flv file. as though you were writing to out.flv and then renamed it out.mp4. it's weird that someone told you that
[22:50:46 CEST] <Nobgul> Because hes doing it wrong but it still plays in jwplayer and vlc so he wouldnt know its wrong. But either way i have some reading to do thanks for the link.
[22:51:30 CEST] <Nobgul> INitially i had asked why cant i just do -a copy -v copy -fv scale=480:360
[22:55:52 CEST] <Nobgul> Im going to give it a go ill check back in a few minutes. Thank you all for your help.
[22:59:25 CEST] <Nobgul> Getting an error now. sws: filterSize 1920 is too large, try less extreme scaling or increase MAX_FILTER_SIZE and recompile
[23:00:25 CEST] <Nobgul> When i change scale back to 480:360 it works..
[23:02:34 CEST] <vade_> durandal_1707: ah - i got it - finally - once I force a set frame size everything behaves. one final question - in terms of analysis filters like loudnorm which output to a log function - is there a way to trigger that output? I mark EOF for the filter source - is there a specific log level i should be interecepting ? :X
[23:10:22 CEST] <Nobgul> Thank you all removing the strict and the -f flv and now the file encoded and plays just fine.
[23:11:09 CEST] <Nobgul> aspect ratio is jacked but i can fix that.
[23:16:45 CEST] <vade_> ah uninit / free wasnt being called
[23:16:47 CEST] <vade_> ha - this works
[23:16:48 CEST] <vade_> doppppe
[00:00:00 CEST] --- Fri Jun 10 2016