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

[burek]

[03:25:50 CEST] <Abbott> so if I want to compile ffmpeg using cygwin, I only need to ./configure, and make, right? Assuming I have all of the dependencies listed here: https://ffmpeg.org/platform.html#Compilation-under-Cygwin
[03:48:30 CEST] <qmr> ffmpeg -r 30 -start_number 0001 -i FHD%d.JPG -s 1920x1080 -vcodec libx264 00-output.mp4
[03:48:36 CEST] <qmr> [image2 @ 0x7fd144800a00] Could find no file with path 'FHD%d.JPG' and index in the range 1-5
[03:48:39 CEST] <qmr> halp
[03:48:50 CEST] <qmr> oh wait, this guide is for windoze
[03:49:15 CEST] <qmr> should I change that for linux?
[03:49:16 CEST] <furq> i suspect you want FHD%04d.JPG
[03:49:20 CEST] <furq> on any os
[03:49:26 CEST] <furq> %d assumes no zero padding
[03:50:11 CEST] <qmr> my hero!
[03:50:13 CEST] Action: qmr swoons
[03:50:43 CEST] <qmr> dammit, a sequence is missing and it aborte
[03:50:45 CEST] <qmr> d
[03:51:13 CEST] <furq> !demuxer image2
[03:51:13 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#image2-1
[03:51:17 CEST] <furq> you can try using the glob stuff
[03:51:53 CEST] <qmr> going to start by just copying neighbor frame hopefully don't have to do it too many times
[03:52:00 CEST] <qmr> I guess I shut off camera when 237 was being written or something
[05:25:51 CEST] <qmr> thanks guys
[06:46:38 CEST] <bray90820> What do these errors mean "[h264 @ 0x7f8c3ed10200] A non-intra slice in an IDR NAL unit." and "[h264 @ 0x7f8c3ed10200] decode_slice_header error"
[09:04:56 CEST] <hendry> i have a Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc (default)
[09:05:30 CEST] <hendry> but it doesn't show its bitrate... or am i blind?
[09:20:18 CEST] <vlt> hendry: You can calculate that using duration and file size.
[09:26:59 CEST] <kaninte> I've also seen cases when it doesn't display bitrate. why is that?
[09:29:47 CEST] <kaninte> vlt: How do you calculate?
[09:57:07 CEST] <furq> hendry: ffprobe -show_streams
[09:57:09 CEST] <furq> or mediainfo
[10:22:59 CEST] <hendry> furq: bit_rate=N/A
[10:23:37 CEST] Action: hendry wonders if there is a tool to show VBR... like how well certain scenes were compressed et al
[10:24:10 CEST] <JEEB> for bit rate you can just divide the file size with the duration. if the container is such that there is no duration field you might have to "decode" through the file with ffmpeg once to get the data
[10:24:50 CEST] <JEEB> there are multiple tools that can show you bit rates graphed but the problem with most tools is that they will not show you what they are graphing exactly
[10:25:04 CEST] <JEEB> as in, what they are giving you as a point etc
[10:26:03 CEST] <JEEB> also stuff like VBV/HRD, which pretty much nothing takes into account
[10:52:00 CEST] <brash> I am running ffmpeg 2.8 and trying to mux an mkv with an h264 video stream, but when I run avformat_write_header(), I get an error saying "Invalid data found when processing input". What would be the best way to debug this problem? I am stepping through with gdb, but I honestly am not sure what to even look for.
[10:53:49 CEST] <hendry> JEEB: interesting, thanks
[10:53:58 CEST] <brash> I am following the muxing.c example file at http://www.ffmpeg.org/doxygen/2.8/muxing_8c_source.html
[11:13:08 CEST] <brash> All right. I figured that I am getting an undefined timestamp value. Where would I look to fix that?
[11:44:27 CEST] <brash> wzur
[12:54:44 CEST] <kaninte> I still can't figure out how some people encode 40min video to around 300MB with very good quality using x264 and aac. For me to achive that means crf=30 which destroys the quality. :-/
[13:02:41 CEST] <furq> kaninte: it massively depends on the source
[13:08:08 CEST] <CoreX> kaninte what is the source you have exactly
[13:15:28 CEST] <vlt> kaninte: Depends also on the CPU cycles invested during encoding. You should get smaller results at the same quality with somehting like "-preset veryslow".
[13:47:26 CEST] <kaninte> CoreX: I have tried videos taken från my phone and från my Canon G7Xm2 camera. I just can't compress it that much without loosing alot of quality
[13:47:48 CEST] <kaninte> vlt: I'm using veryslow
[13:52:35 CEST] <vlt> kaninte: What happens when you recode one of those 300MB/40min videos and recode them. Just as a test?
[13:52:39 CEST] <kaninte> furq: The source is very clear and noise-free in my opinion.
[13:53:28 CEST] <kaninte> vlt: Interesting test, haven't tried.
[13:54:29 CEST] <kaninte> vlt: Generally speaking, should the result be the same if you re-encode a video?
[13:55:33 CEST] <vlt> kaninte: It doesn't get better (even when using a higher bitrate) but it shouldn't get much worse.
[13:56:26 CEST] <kaninte> vlt: I mean the file size. if you use same method to re-encode should the size be the same?
[13:58:31 CEST] <brash> I'm getting an "Invalid data found when processing input" when trying to mux in a matroska container. The error occurs specifically at avformat_write_header(). Anyone have experience with this?
[13:59:22 CEST] <kaninte> vlt: I'm asking because I don't know exactly how encoding works. That is, do we loose some needed data during this process which makes it impossible to get the same result after re-encode, or not?
[13:59:26 CEST] <vlt> kaninte: I'm not sure because the source material has (in most cases) slightly changed.
[13:59:38 CEST] <kaninte> mm
[14:00:07 CEST] <vlt> kaninte: We loose data. That's the whole point of (lossy) video compression.
[14:01:05 CEST] <brash> I am thinking the error is happening when avformat_write_header() calls init_pts() and not init_muxer(). Still, not sure how to continue debugging this issue. Is this the right channel for this discussion?
[14:01:25 CEST] <vlt> kaninte: There are lossless video codecs and there's a "lossless" h264 mode (or just -crf 0?) which I don't know anything about.
[14:02:32 CEST] <furq> kaninte: are these high motion videos by any chance
[14:09:42 CEST] <drakkan1000> Hi, this sample https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/demuxing_decoding.c use deprecated api avcodec_decode_video2 and avcodec_decode_audio4 any plan to update it? thanks
[14:12:58 CEST] <BtbN> When someone sends patches for that, sure. Feel free to write one.
[14:17:34 CEST] <drakkan1000> Ok, I'll test the new api inside my application before send the patch, thanks!
[14:19:23 CEST] <kaninte> vlt: yes I know about that. just thought if you unpack and repack it exactly the same way, will anything differ
[14:19:41 CEST] <DHE> wow surprised that hasn't been updated yet
[14:20:12 CEST] <kaninte> furq: No. I'm home videos of my new born baby, So it's really static :-)
[14:28:47 CEST] <acresearch> hello people, is this a good channel to ask about desktop screen video recording (regarding best software and file format)?
[14:31:46 CEST] <brash> acresearch: what software and format are you thinking about using?
[14:37:22 CEST] <acresearch> brash: i think .mp4 is the best right? so i can edit it anywhere?
[14:40:02 CEST] <brash> Hmm. Depends on what codecs you are wanting to run through it. FWIR MP4 is limited to specs using h.264 and AAC.
[14:41:11 CEST] <brash> Are you trying to sacrifice information for size - lose some color and definition to fit into a smaller file?
[14:41:17 CEST] <acresearch> i don't care about sound, i care more about the HD quality of the final video
[14:41:37 CEST] <acresearch> brash: i want best colours, no need for sound quality
[14:43:49 CEST] <brash> By HD do you mean 1920x1080p at 60 or 1366x720p at 30 etc.?
[14:44:12 CEST] <acresearch> 1080p
[14:47:11 CEST] <brash> In my opinion, h.264/mp4 would be a good combo. ffmpeg is capable of grabbing x11 frames, but the colors seem to be 'fuzzy'. Not sure about bitrates, quant values, I P B frame periods, etc.
[14:47:29 CEST] <acresearch> hmmm
[14:47:41 CEST] <brash> Are you running linux or a proprietary OS?
[14:47:51 CEST] <acresearch> linux ubuntu 17.04
[14:48:56 CEST] <brash> IIRC the CLI ffmpeg -i x11grab -c:v libx264 -b:v BITRATE_VALUE out.mp4
[14:49:00 CEST] <kaninte> What are VP8 and VP9? Something new?
[14:49:34 CEST] <acresearch> brash: wait, i do not have the video yet, i am asking how to record one. what formats are best and any reccomended linux software
[14:49:38 CEST] <brash> acresearch: You might try that command out and see how it looks. The man pages are abundant.
[14:50:20 CEST] <brash> That's what that command does. It grabs the x11 frames, encodes them with -c:v libx264 at bitrate -b:v BITRATE_VALUE to out.mp4.
[14:50:49 CEST] <brash> kaninte: vp8 and vp9 are codecs teh goggles are pushing out for webm container.
[14:51:10 CEST] <acresearch> brash: oh, i can record my screen from ffmped???
[14:51:26 CEST] <kaninte> goggles?
[14:51:32 CEST] <brash> acresearch: yep. -i x11grab is how it's done, from what I remember.
[14:51:39 CEST] <brash> kaninte: google
[14:51:42 CEST] <acresearch> brash: wooow i did not know that
[14:51:47 CEST] <kaninte> Ahh
[14:51:49 CEST] <acresearch> brash: ok i'll give it a go
[14:52:40 CEST] <acresearch> brash: ok so the command is (ffmpeg -i x11grab -c:v libx264 -b:v 5000 out.mp4)?
[14:54:06 CEST] <acresearch> brash: i get an error: x11grab: No such file or directory     do i have to install x11grab?
[14:54:24 CEST] <brash> acresearch: change -b:v 5000 to -b:v 5000K if you want approximately 5Mbps.
[14:55:01 CEST] <brash> If you have X server installed, then you don't need to install x11grab. If you don't have libx264, you will need to install libx264 and to compile libx264 support in with ffmpeg.
[14:55:35 CEST] <brash> Wait, you are running ubuntu? I don't know if it runs an x11 server.
[14:56:12 CEST] <acresearch> x11? so is this a server i have to connect to from a website?
[14:56:47 CEST] <brash> acresearch: No. Here is a site that should help you out. I had the command wrong. https://ubuntuforums.org/showthread.php?t=2318460
[15:01:35 CEST] <acresearch> brash: i am sorry i do not understand how they solved it
[15:04:56 CEST] <furq> acresearch: don't use mp4 for that
[15:05:06 CEST] <furq> if the recording drops out halfway through you'll get an unreadable file
[15:05:37 CEST] <furq> use a streamable container like mkv, mpegts, nut etc and remux if you need an mp4
[15:06:05 CEST] <acresearch> furq: hmmm, but the question is how to record the screen from ffmpeg (or another software that can record the colours well)
[15:06:22 CEST] <acresearch> x11grab is not working with me
[15:06:27 CEST] <furq> the fuzzy colours thing is probably due to the rgb to yuv conversion, particularly if you're using yuv420p
[15:06:40 CEST] <acresearch> hmmm
[15:06:41 CEST] <furq> so the question is what you intend to do with these videos
[15:06:56 CEST] <furq> if you're uploading them to the web then that's going to happen regardless
[15:07:08 CEST] <furq> so you might as well let ffmpeg do it and save some bandwidth
[15:07:20 CEST] <furq> otherwise, use some codec that supports rgb
[15:07:39 CEST] <furq> probably libx264rgb for lossy or ffv1 for lossless
[15:07:53 CEST] <debianuser> acresearch: It depends on what you want to do. FFmpeg is good enough for screencasts. For games you may want to try SSR ( https://en.wikipedia.org/wiki/SimpleScreenRecorder ), which has some special tricks for opengl. And if you need complex overlays with webcam and mic on top of main recording and don't like command-line (unix.stackexchange.com/a/84013) you may try OBS (obsproject.com) instead.
[15:08:04 CEST] <acresearch> furq: this is a tutorial on how to use molecular graphics, so colours are important, i tried two screen recorders, one is simple usless, crashes all the time (RecordMyDesktop), the other works really well but gives dull colours (SimpleScreenRecorder)
[15:08:21 CEST] <furq> how are people going to watch the videos though
[15:08:36 CEST] <furq> if it's youtube or something then they'll convert any input to yuv420p, so you'll have the same problem
[15:08:37 CEST] <acresearch> furq: youtube
[15:09:12 CEST] <furq> iirc chrome and firefox will play yuv444p h264 now, so if you can use a hosted video player then that might be an option
[15:09:44 CEST] <acresearch> furq: wow, looks like this feild it too big to learn quickly. what is a hosted video player?
[15:09:52 CEST] <brash> acresearch: this is their command they ran ffmpeg -f x11grab -s 1360x765 -r 30 -i :0.0 -qscale 0 -vcodec huffyuv ~/Desktop/$(date +%H%M%S).avi
[15:10:03 CEST] <furq> just hosting the files somewhere
[15:10:04 CEST] <brash> just look through man ffmpeg to figure out what those options do and adjust them to your needs
[15:10:45 CEST] <furq> i'm impressed that you found an ffmpeg command on a forum that only has two obvious issues
[15:10:53 CEST] <furq> it's normally way more than that
[15:11:31 CEST] <brash> heh furq
[15:12:31 CEST] <debianuser> acresearch: Make a simple color test to make sure youtube won't break your colors. Record like a few seconds with `ffmpeg -f x11grab -s 1280x1024 -r 25 -i :0 x11grab.mkv` then play x11grab.mkv and see if your colors are fine. If they are - upload x11grab.mkv to youtube and check if colors are still fine. If they're not - it's youtube to blame and you can't do anything about that.
[15:13:04 CEST] <furq> you should probably convert to yuv420p yourself if you're uploading to youtube
[15:13:25 CEST] <furq> it's less bandwidth and also you have some control over the conversion
[15:13:57 CEST] <acresearch> furq: hmmm
[15:14:09 CEST] <furq> there is some magic to getting swscale to do a better job with rgb to yuv but colourspace stuff is all over my head really
[15:14:19 CEST] <furq> or getting zscale to do it at all if your build has that
[15:14:23 CEST] <acresearch> the command works debianuser testing to see how to grap the whole screen
[15:14:42 CEST] <acresearch> furq: this is way over my head
[15:15:03 CEST] <debianuser> acresearch: adjust resolution. E.g. replace `-s 1280x1024` with `-s 1920x1080` if that's your screen resolution
[15:15:13 CEST] <furq> a good rgb to yuv conversion should usually look basically the same
[15:15:34 CEST] <furq> but yuv420p has half the chroma resolution, which is why sharp contrast edges of colours look blocky
[15:15:40 CEST] <furq> which basically ruins small coloured text
[15:15:47 CEST] <acresearch> debianuser: i get an Invalid argument
[15:16:09 CEST] <acresearch> furq: then how can i oversome that?
[15:16:14 CEST] <furq> if you need small coloured text and this is going to youtube then there's not much you can do
[15:16:21 CEST] <furq> other than changing the colours or font size
[15:17:09 CEST] <debianuser> acresearch: What's your screen resolution? Run `xrandr` command, it'd print something like: DVI-I-0 connected 1920x1200+0+0 (...)
[15:17:34 CEST] <acresearch> debianuser: oh ok, i changed -s to 1280x800
[15:19:06 CEST] <debianuser> acresearch: Don't forget to play the recorded file locally and make sure the colors are fine there. I mean if the colors are already broken in the recorded file - no need to test it with youtube. :)
[15:19:51 CEST] <acresearch> debianuser: furq true, this is what i am trying to do,,, colour are better than SimpleScreenRecord application, but still dull, and the video is kind of low quality
[15:20:17 CEST] <acresearch> maybe because it is .avi?
[15:20:30 CEST] <furq> oh
[15:20:38 CEST] <furq> yeah the default codecs for avi are bad
[15:20:43 CEST] <furq> use mkv
[15:21:52 CEST] <acresearch> MUCH MUCH MUCH BETTER!!!!
[15:22:40 CEST] <acresearch> 600MB for 20 seconds???????
[15:22:55 CEST] <furq> what's the full command
[15:23:05 CEST] <acresearch> furq: ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -qscale 0 -vcodec huffyuv X.mkv
[15:23:12 CEST] <furq> oh
[15:23:30 CEST] <furq> the container shouldn't have made any difference then lol
[15:23:44 CEST] <furq> but yeah huffyuv is a lossless codec, and i assume that'll be using yuv444p
[15:24:01 CEST] <Mavrik> Probably RGB there tho
[15:24:04 CEST] <furq> get rid of -qscale 0 -vcodec huffyuv and use -c:v libx264 -pix_fmt yuv420p
[15:24:08 CEST] <furq> oh yeah huffyuv does rgb doesn't it
[15:24:16 CEST] <Mavrik> Note that conversion to 4:2:0 is the one that messes up the colors
[15:24:23 CEST] <Mavrik> Usually red comes out all fuzzy and dark
[15:24:27 CEST] <furq> yeah
[15:26:02 CEST] <acresearch> furq: Mavrik let me try it, i am just saving the commands so i do not forget them
[15:26:34 CEST] <brash> anyone familiar with adding a video stream to a matroska container with libavformat? I keep getting "Invalid data found when processing input" when running avformat_write_header().
[15:27:13 CEST] <acresearch> furq: no back to dull colours (but size is not 3MB)
[15:27:34 CEST] <furq> by dull do you mean like the contrast/brightness is wrong
[15:27:38 CEST] <furq> or just the blocky edges
[15:28:10 CEST] <furq> the former should actually be fixable
[15:29:01 CEST] <acresearch> furq: hmmmm how do i explain.
[15:29:20 CEST] <acresearch> the green is greshish, the blue is gresh like that... also not very HD
[15:29:48 CEST] <debianuser> acresearch: Try a different codec. `ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -vcodec libx264 -crf 11 -pix_fmt yuv444p -preset veryfast x11grab.mkv` - that'd use x264 codec, which generates smaller files, but may affect colors (I'm not sure if rgb->yuv444 is lossless). So check if colors are fine there.
[15:30:09 CEST] <acresearch> debianuser: ok let me record this command and try it
[15:30:17 CEST] <debianuser> (acresearch: also if you're saving commands, make a note next to them, like "this command has bad colors", "this has better colors", "this has good colors but 600MB for 20 sec", etc. :) )
[15:30:30 CEST] <acresearch> debianuser: i do :-) thanks
[15:31:17 CEST] <furq> debianuser: he's already using x264, and this is going to youtube so it has to be yuv420p anyway
[15:32:21 CEST] <acresearch> debianuser: nah, same dull colours  (the first command was PERFECT, but very very large files size)
[15:32:54 CEST] <furq> iirc it's doing the full to limited range conversion wrong
[15:33:01 CEST] <furq> but i can't remember how to fix that
[15:33:07 CEST] <furq> other than using yuvj420p and that's probably no good
[15:34:12 CEST] <furq> replace -pix_fmt yuv420p with -vf colorspace=range=mpeg,format=yuv420p
[15:35:02 CEST] <furq> or er
[15:35:09 CEST] <furq> -vf colorspace=range=mpeg:format=yuv420p
[15:35:28 CEST] <furq> either should work but i assume the second one is better
[15:36:00 CEST] <acresearch> failed to inject frame into filter network: Invalid argument
[15:44:34 CEST] <Nacht> Afternoon
[15:44:58 CEST] <acresearch> furq: i tried both commands
[16:02:23 CEST] <acresearch> furq: debianuser  when i change -vcodec huffyuv -> -vcodec libx264 i get low file size and low colour quality (all other flags do not affect the quality and colours)
[16:02:37 CEST] <acresearch> so the issue is with the codec ha?
[16:05:24 CEST] <Nacht> Would changing the colorspace effect the colours ?
[16:05:45 CEST] <Nacht> Like BT709 ?
[16:05:46 CEST] <acresearch> Nacht: i don't know, how do I change the colourspace?
[16:05:56 CEST] <Nacht> -color_primaries 1 -color_trc 1 -colorspace 1
[16:06:29 CEST] <acresearch> Nacht: no it is the same
[16:06:54 CEST] <Nacht> Hmm shame.
[16:07:44 CEST] <acresearch> so i read that huffyuv is a lossless codec, does this mean any other codec is less quality so would make the colours dull?
[16:07:52 CEST] <furq> no
[16:07:52 CEST] <Mavrik> Nacht, acresearch, no changing to yuv444 format should fix the color
[16:08:00 CEST] <Mavrik> However, you can't do anything about youtube
[16:08:02 CEST] <furq> huffyuv isn't doing the conversion
[16:08:06 CEST] <Mavrik> because most players only do YUV420p
[16:08:06 CEST] <furq> it's keeping it as rgb
[16:08:18 CEST] <Mavrik> and either you convert it or youtube will
[16:08:27 CEST] <furq> Mavrik: he said the colours were still wrong with 444 so i assume he means the contrast is messed up
[16:08:34 CEST] <Mavrik> ah
[16:08:38 CEST] <Mavrik> *shrug*
[16:08:46 CEST] <furq> which i guess is an incorrect full->limited conversion
[16:09:15 CEST] <furq> i forget how you're supposed to use colorspace with rgb though
[16:09:38 CEST] <furq> i guess you need to set the primaries and trcs but idk what those are meant to be for x11grab
[16:09:53 CEST] <acresearch> oh so huffyuv is not converting colour, while libx264 is converting colours which is why i get them dull?
[16:09:58 CEST] <furq> yes
[16:10:01 CEST] <acresearch> aha
[16:10:04 CEST] <acresearch> hmmmm
[16:10:20 CEST] <acresearch> it is possible to stop it from converting colours?
[16:10:35 CEST] <furq> youtube always uses yuv, so either you do the conversion or they will
[16:10:38 CEST] <acresearch> or is it an intrinsic part of the code?
[16:10:54 CEST] <acresearch> furq: but i see screen casts on youtube with amazing colours
[16:10:55 CEST] <furq> they'll probably mess it up in exactly the same way
[16:11:35 CEST] <furq> i mean you can try uploading rgb to youtube and see if they do a better job of converting it
[16:11:51 CEST] <furq> if it's a screencast then try -c:v ffv1
[16:11:59 CEST] <furq> and get rid of any -pix_fmt stuff you have
[16:12:17 CEST] <acresearch> with libx264?
[16:12:23 CEST] <furq> no get rid of that
[16:12:47 CEST] <acresearch> then use huffyuv?
[16:12:48 CEST] <furq> ffv1 is lossless so that should eliminate any other cause of things going wrong
[16:12:54 CEST] <furq> no, use ffv1
[16:13:02 CEST] <furq> huffyuv is ancient and compresses really badly
[16:16:16 CEST] <acresearch> furq: one moment, let me try them all
[16:16:20 CEST] <acresearch> back in 10 minites
[16:35:59 CEST] <acresearch> furq:
[16:36:03 CEST] <acresearch> ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -vcodec libx264 -c:v ffv1 X.mkv
[16:36:05 CEST] <acresearch> ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -vcodec ffv1 -c:v ffv1 X.mkv
[16:36:07 CEST] <acresearch> These seems to all give the same quality and large file size (10 seconds = 100+ MB)
[16:36:09 CEST] <acresearch> y
[16:39:04 CEST] <Nacht> c:v is short for vcodec
[16:39:20 CEST] <Nacht> So you're specifying the codec twice
[16:40:24 CEST] <acresearch> ohhhh ok
[16:41:40 CEST] <acresearch> so the best command so far is `ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -c:v ffv1 X.mkv` but it still gives a file size of 100 MB for 5 seconds - but colours and quality is very good
[16:44:35 CEST] <acresearch> is there a way to reduce it or compress it?
[16:50:39 CEST] <redrabbit> use another codec
[16:51:54 CEST] <acresearch> redrabbit: hmmm, is there a list for ffmpeg?
[16:52:50 CEST] <redrabbit> you can use any codec
[16:53:04 CEST] <redrabbit> if you have hardware encoders, you might want to use them
[16:53:24 CEST] <acresearch> hardware encoders? i have a macbook pro with ubuntu on it
[16:53:39 CEST] <acresearch> redrabbit: i am not sure what are all the codecs so i can test them
[16:57:10 CEST] <Fyr> guys, I can't find a manual describing d3d11va.
[16:57:19 CEST] <Fyr> do you know how to use it?
[16:57:51 CEST] <vlt> redrabbit: I think the problem was that they can't use just *any+ codec because of lost colors.
[17:01:52 CEST] <JEEB> Fyr: seems to be utilized in a similar way to other hwaccels in the API
[17:02:24 CEST] <Fyr> JEEB, there is no similarity between HW in FFMPEG.
[17:02:45 CEST] <JEEB> yes there is, HWContextType
[17:03:10 CEST] <JEEB> which contain the specifics for each hwaccel
[17:03:21 CEST] <Fyr> JEEB, ok, give me an example of its usage.
[17:04:12 CEST] <JEEB> I would probably see how mpv does it if you really want to use it through the API instead of DXVA2
[17:04:24 CEST] <JEEB> since mpv and vlc both seem to utilize the hwaccel
[17:04:53 CEST] <JEEB> the primary reason for using d3d11va seems to be UWP
[17:05:37 CEST] <JEEB> ok, ffmpeg.c also seems to have some thing for it?
[17:05:53 CEST] <JEEB> I did remember the original patch set having something for ffmpeg.c but I just never remembered if that was taken in
[17:06:06 CEST] <JEEB> oh, and there's even an example
[17:06:14 CEST] <JEEB> doc/examples/hw_decode.c:        fprintf(stderr, "Usage: %s <vaapi|vdpau|dxva2|d3d11va> <input file> <output file>\n", argv[0]);
[17:06:31 CEST] <JEEB> so that example seems to implement d3d11va
[17:06:37 CEST] <JEEB> as in, use it
[17:08:04 CEST] <acresearch> redrabbit: i tried all the lossless codecs, but ffv1 works well, the others give very bad quality
[17:08:36 CEST] <brash> acresearch: did you see which encoders you have by running ffmpeg -encoders
[17:08:45 CEST] <acresearch> brash: yes
[17:08:50 CEST] <brash> ok
[17:08:57 CEST] <acresearch> brash: i will paste you here my commands:
[17:09:45 CEST] <acresearch> brash: http://paste.debian.net/plain/985725
[17:11:08 CEST] <relaxed> acresearch: pretty sure you want -framerate 30 and not -r 30
[17:11:26 CEST] <brash> With the -i :0.0 option, you can crop the screen also by using -i :0.0+x,y where x is your crop on the horizontal and y is the crop on the vertical
[17:12:03 CEST] <redrabbit> if you want to get smaller files forget about lossless
[17:12:06 CEST] <acresearch> brash: no i need to record the full screen
[17:12:12 CEST] <redrabbit> doesnt mean it has to look bad
[17:12:15 CEST] <brash> i see
[17:12:18 CEST] <acresearch> redrabbit: hmmm
[17:12:44 CEST] <acresearch> i am hoping to grab my students by showing off good quality graphics, that way they pay attention
[17:13:21 CEST] <kepstin> x264 can be used in high quality non-lossless mode with either yuv 4:4:4 or rgb, which should give you smaller files that don't have the colour artifacting from subsampling.
[17:13:27 CEST] <redrabbit> re encode the caps with AVC
[17:13:59 CEST] <relaxed> acresearch: what are you capturing? An open window?
[17:14:09 CEST] <acresearch> relaxed: no my desktop screen
[17:14:39 CEST] <redrabbit> lossless only make sense in very specific cases
[17:15:03 CEST] <acresearch> ok wait, i was using -r 30 but then i changed it to -framerate 30 and that reduced the size nicely (now 20 seconds - 100 MB instead of 5 seconds)
[17:15:27 CEST] <acresearch> redrabbit: i just want HD quality. 1080p
[17:15:31 CEST] <relaxed> acresearch: you've seen https://trac.ffmpeg.org/wiki/Capture/Desktop ?
[17:15:52 CEST] <redrabbit> use x264 with constant quality at like 20
[17:15:56 CEST] <redrabbit> its plenty
[17:16:33 CEST] <redrabbit> -crf 20
[17:16:44 CEST] <acresearch> redrabbit: x264 reduces the nice colours
[17:16:48 CEST] <redrabbit> -vcodec libx264
[17:17:09 CEST] <kepstin> acresearch: please describe what you mean by "reduces the nice colours"
[17:17:25 CEST] <redrabbit> im sure its because you didnt tweaked the settings properly
[17:17:36 CEST] <acresearch> kepstin: the colours are not original as in the screen, they are matter, greyer, off
[17:18:10 CEST] <kepstin> acresearch: hmm, that probably means a player or color conversion issue. You can use "-c:v libx264rgb" instead and it'll completely avoid the problem.
[17:18:23 CEST] <kepstin> assuming you have a player that supports h264 in rgb mode.
[17:19:09 CEST] <acresearch> kepstin: wow,, yes
[17:19:25 CEST] <acresearch> kepstin: let me try it several times, the file size is very low
[17:19:46 CEST] <redrabbit> that's the point isnt it :p
[17:19:53 CEST] <redrabbit> desktop caps compress well
[17:20:47 CEST] <redrabbit> what are your settings atm
[17:21:36 CEST] <acresearch> kepstin: wow that actually solves my issue, nice colours, HD, and small file size :-) 30 second 8MB
[17:21:45 CEST] <acresearch> redrabbit: this is my final command: ffmpeg -f x11grab -s 1280x800 -r 30 -i :0.0 -c:v libx264rgb X.mkv
[17:22:14 CEST] <kepstin> acresearch: by default that will be using "-crf 23", feel free to try a different value to adjust the quality.
[17:22:31 CEST] <kepstin> and again, you should be using "-framerate 30" not "-r 30" on the input
[17:22:54 CEST] <acresearch> kepstin: what is the difference? i tried both and i cannot see a difference?
[17:23:09 CEST] <redrabbit> add -crf 20
[17:23:33 CEST] <kepstin> -framerate asks the screengrabber to capture 30 frames per second. Instead, -r ignores the framerate from the screengrabber and rewrites the timestamps to 30fps.
[17:24:08 CEST] <kepstin> (note that the default -framerate value is very close to 30fps, so for short videos you might not notice)
[17:24:30 CEST] <JohnJay> Is there something wrong with the syntax ffmpeg -ss 00:00 -to 45:00 .... ?
[17:24:32 CEST] <kepstin> but for long ones, or ones where you need audio sync, it's very important not to use -r input option :)
[17:24:48 CEST] <acresearch> kepstin: ohhhh ok
[17:25:05 CEST] <acresearch> now what about the -crf 20,,, what does this do?
[17:25:05 CEST] <kepstin> JohnJay: -to is not supported as an input option, only as output (for now, iirc someone proposed adding it)
[17:25:26 CEST] <kepstin> acresearch: -crf adjusts the video quality/size. Smaller numbers mean higher quality & higher size.
[17:25:39 CEST] <kepstin> acresearch: default is 23, adjust to taste.
[17:25:48 CEST] <JohnJay> kepstin: So what's the best way to segment a file into blocks of T time?
[17:26:06 CEST] <acresearch> kepstin: ohhhh ok
[17:26:12 CEST] <acresearch> kepstin: thanks
[17:26:17 CEST] <kepstin> JohnJay: you can use -to as an output option, or use the -t option instead.
[17:26:18 CEST] <relaxed> acresearch: https://trac.ffmpeg.org/wiki/Encode/H.264
[17:27:25 CEST] <kepstin> JohnJay: but if you're segmenting a file, look at using the ffmpeg segment muxer instead, to do it in one pass without having to worry about discontinuities at cuts.
[17:27:32 CEST] <JohnJay> okay the t option did allow for the HH:mm:ss syntax
[17:28:01 CEST] <JohnJay> kepstin: ok thanks, I will try that
[17:28:34 CEST] <JohnJay> Once I know what term to use finding a tip on superuser or askubuntu is usually easy. :)
[17:31:21 CEST] <acresearch> i can use .mkv for video editing later on?
[17:35:36 CEST] <JohnJay> ooo NICE the -segment_time option takes options in hh:mm:ss
[17:40:23 CEST] <acresearch> what does it mean with i get a printout: Past duration 0.998878 too large
[17:41:08 CEST] <JohnJay> I've gotten that before, dunno what it means
[17:43:15 CEST] <brash> acresearch: It probably means a time stamp (presentation or decompressed) was larger than expected. It might mean not enough CPU.
[17:43:31 CEST] <acresearch> brash: hmmm
[17:43:44 CEST] <acresearch> would this cause problems in my video output?
[17:47:21 CEST] <JohnJay> heh now if I could only get youtube-dl to download a playlist properly then i'd be all set
[17:49:51 CEST] <brash> acresearch: if it's not a buffer underflow, I wouldn't think so. The problems with using x11grab are generally losing sync with audio and video. But if you aren't capturing audio, it won't matter.
[17:50:24 CEST] <acresearch> brash: oh ok good
[17:50:57 CEST] <acresearch> i will be recording externally and hopefully sync them during editing, which is my last question. I can use .mkv files for video editing right?
[18:06:49 CEST] <brash> acresearch: I am fairly certain most video editing software support mkv files.
[18:07:02 CEST] <acresearch> nice excellent
[18:10:19 CEST] <kepstin> acresearch: that problem happens when ffmpeg guesses that the video is some constant framerate, but some frames end up being closer together than expected. (iirc, a frame might get dropped).
[18:10:44 CEST] <acresearch> kepstin: but it shouldn't ruin the video right?
[18:11:21 CEST] <kepstin> no. But you might get better results in some cases by using an fps filter to fix the frame timestamps with the expected rate, or a couple of other options
[18:11:22 CEST] <debianuser> acresearch: Also try to add option `-preset ultrafast` that'd increase the file size, but reduce cpu usage so you may get rid of "too large" warnings, if that was because of high CPU usage.
[18:12:39 CEST] <kepstin> some filter chains can cause a lot of these messages, for example using 'concat' filter when the second video has higher framerate than the first (it'll cause noticable issues then)
[18:12:56 CEST] Action: kepstin really should finish his patch for that
[18:24:46 CEST] <debianuser> acresearch: also don't forget to upload some small video file with good colors to youtube to check if youtube breaks colors or not.
[18:25:02 CEST] <acresearch> debianuser: i will do that.
[18:38:50 CEST] <ritsuka> acresearch: I would check if your app supports mkv, I don't know if premiere does
[18:39:12 CEST] <acresearch> i am still looking for a video editing program for ubuntu
[18:50:16 CEST] <debianuser> acresearch: I don't know what people use there days. There were a lot of video editing apps: lives, kino, kdenlive, cinerella, jahshaka, winff, PiTiVi, OpenMovieEditor... blender. Not sure which of those is still alive/good.
[18:50:42 CEST] <debianuser> (well, blender is certainly alive, but it might be overkill for your needs)
[18:50:43 CEST] <acresearch> debianuser: hmmm i think i wil ask in #ubuntu
[18:52:17 CEST] <debianuser> Ah, there're also apps like `transcode` and `avidemux`, for simple things like cut/resize... But you can also use ffmpeg for such things, if you don't mind to type a long command line for that. :)
[19:16:18 CEST] <JohnJay> lol
[19:16:26 CEST] <JohnJay> when I used the segment_time segment muxer
[19:16:43 CEST] <JohnJay> I told it to name the output files .mp4 even though it was mp3. and so it did what I asked for
[19:25:33 CEST] <JohnJay> okay i think i got the magic voodoo to get youtube-dl to download a playlist
[19:25:47 CEST] <JohnJay> I do youtube-dl --playlist-start=1 --playlist-end=XXX <URL>
[19:25:57 CEST] <JohnJay> if XXX is too big I guess it fails for some reason
[20:05:33 CEST] <Fyr> JEEB, what is better: dxva2 or d3d11va?
[20:06:27 CEST] <JEEB> I don't think they have too big of a difference
[20:06:46 CEST] <JEEB> d3d11va can be used with UWP?
[20:06:52 CEST] <JEEB> aka the windows ARM devices etc
[20:07:00 CEST] <JEEB> the store stuff I think?
[20:07:56 CEST] <Fyr> =|
[20:11:29 CEST] <jkqxz> They're functionally identical.  If your target platforms support both, use the one with more convenient output (IDirect3DSurface9 or ID3D11Texture2D) for whatever it is you want to do.
[20:12:29 CEST] <JEEB> yup
[20:31:06 CEST] <pgorley> JEEB: doc/examples/hw_decode.c is compiled against the ffmpeg 3.3.3 api?
[20:31:22 CEST] <JEEB> if it's there in the repo for 3.3.3 then it will work there
[20:31:31 CEST] <JEEB> docs/examples
[21:11:58 CEST] <pgorley> hmm, it's in neither 3.3.3 nor 3.3.4, i'm guessing it'll be included only starting with 3.4?
[21:14:28 CEST] <JEEB> pgorley: whatever happened after 3.3 then :P it might or might not work with 3.3
[21:15:54 CEST] <pgorley> it doesn't i tried compiling it, bunch of stuff missing in 3.3.x
[21:16:14 CEST] <JEEB> alright, that settles it then
[21:16:17 CEST] <pgorley> yup
[21:16:33 CEST] <JEEB> anyways, I just recommend trying to keep up with master where possible (or where master last was green on FATE)
[21:16:34 CEST] <pgorley> i'm gonna try to convince the team to get on master
[21:16:43 CEST] <JEEB> http://fatebeta.ffmpeg.org/
[21:16:49 CEST] <pgorley> yea, but i don't get to make the final decision :(
[21:16:52 CEST] <JEEB> sure
[21:16:59 CEST] <JEEB> FATE is generally a good way of checking your arch/OS
[21:17:03 CEST] <JEEB> if the tests pass
[21:17:12 CEST] <JEEB> not perfect, but something
[22:58:13 CEST] <BRaNaTi> Hi friends
[22:58:27 CEST] <durandal_1707> hi
[22:59:29 CEST] <BRaNaTi> I install a apt source deb-multimedia. Im not install a ffmpeg because i download a git project
[22:59:42 CEST] <BRaNaTi> this is a last vesion
[22:59:48 CEST] <BRaNaTi> version
[23:00:17 CEST] <BRaNaTi> how to install command
[23:00:45 CEST] <BRaNaTi> i run  git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg
[23:00:59 CEST] <BRaNaTi> i need install this
[23:08:06 CEST] <gh0st__> BRaNaTi: run the following command in the ffmpeg directory: ./configure && make && make install
[00:00:00 CEST] --- Wed Sep 13 2017