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

[burek]

[00:33:42 CEST] <Bray90820_> Does anyone know of a program for OS X that can do a direct copy from MKV to h.264
[00:34:45 CEST] <Bray90820> Or transcode rather
[00:35:03 CEST] <Bray90820> I don't wanna loose video quality or my 5.1 audio track
[00:35:33 CEST] <zamba> Bray90820: mkv is a container, whereas h.264 is a codec
[00:38:57 CEST] <Bray90820> Yea I am not sure what codec the videos I have right now are
[00:39:03 CEST] <Bray90820> How would I figure that out?
[00:39:45 CEST] <Bray90820> zamba:
[00:40:38 CEST] <Illya> you could use ffprobe
[00:40:58 CEST] <Illya> $ ffprobe you_file.mkv
[00:42:00 CEST] <Bray90820> Yea I'm using a mac so no ffmpeg by default :/
[00:42:24 CEST] <Bray90820> I found it in VLC tho
[00:42:30 CEST] <Bray90820> MPGV
[00:42:50 CEST] <Illya> Bray90820: install it then? I personally use homebrew (https://brew.sh) to install/manage packages
[00:43:00 CEST] <Illya> Bray90820: and the audio format?
[00:43:37 CEST] <Bray90820> AC3/A52
[00:44:15 CEST] <Bray90820> What I would like is to convert it to mp4 h.264
[00:44:57 CEST] <Illya> you wouldn't be able to do it losslessly afaik
[00:45:03 CEST] <furq> ffmpeg -i foo.mkv -c:v libx264 -c:a copy out.mp4
[00:47:33 CEST] <Bray90820> what would the file size be roughly for a 45 minute video file
[00:47:45 CEST] <Bray90820> with AC3 audio
[00:47:58 CEST] <furq> somewhere between one byte and one terabyte
[00:48:20 CEST] <Illya> Bray90820: it's very difficult to say
[00:48:36 CEST] <Bray90820> I can just try it and see
[00:48:46 CEST] <Bray90820> After I install ffmpeg
[00:49:00 CEST] <Illya> that'd probably be best
[00:51:09 CEST] <Bray90820> can someone help me I am a bit of a noob when it cones to installing binarys
[00:52:13 CEST] <Illya> just install brew http://brew.sh/
[00:52:59 CEST] <Illya> then you can do: brew install ffmpeg
[01:01:58 CEST] <Bray90820> Illya: I gotta run but I am having a few errors if you wanna take a look
[01:01:58 CEST] <Bray90820> http://pastebin.com/raw/ea2dQPtC
[01:02:19 CEST] <Illya> how did you install ffmpeg?
[01:02:40 CEST] <Bray90820> brew install ffmpeg
[01:03:09 CEST] <Bray90820> "/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" " to install brew
[01:03:29 CEST] <Illya> errr. that's really weird
[01:03:45 CEST] <Bray90820> The error is weird?
[01:04:01 CEST] <Illya> make sure you have lame maybe? brew install lame
[01:04:22 CEST] <Bray90820> Warning: lame-3.99.5 already installed, it's just not linked
[01:04:29 CEST] <Bray90820> I will fix it when I get back tho
[01:04:49 CEST] <Illya> brew link lame
[01:05:26 CEST] <Bray90820> http://pastebin.com/raw/LrAD0uvH
[01:05:34 CEST] <Bray90820> And on that note I am out
[01:06:42 CEST] <Illya> Looks like a dirty system, you weren't using macports/anything else before, were you? and you didnt try to install ffmpeg in another way?
[02:38:09 CEST] <Bray90820> Illya: I wasn't using mac ports that I know of
[06:38:53 CEST] <Prelude2004c> hey guys... how do i setup the title to show the file name from the input ?
[06:38:54 CEST] <Prelude2004c> ${ffmpeg} -re -f concat -safe 0 -vsync 0 -v 45 -i <(for f in "${HLS_SOURCE}/${CHN}"/*.conv;do echo "file '$f'";done|sort -R) -metadata title=$f -c copy -f mpegts udp://localhost:$port
[06:39:07 CEST] <Prelude2004c> doesn't seem to work at all for me
[06:41:49 CEST] <Prelude2004c> also, does any tool exist that we can use with ffmpeg or something where we can input a video and it creates subtittles ?
[10:51:10 CEST] <f00bar80> In the following script http://vpaste.net/WADJC how to make the second loop not to wait the first to exit/finish ???
[11:02:34 CEST] <f00bar80> ppl any comment?
[11:28:22 CEST] <DHE> ask in #bash ? (does that channel exist?)
[11:40:03 CEST] <MarkedOne> Hello.. I am creating screencast and the speed of video dosent match. I am using 2 steps.. creating raw video for best quality and then converting to other formats... here is pastebin http://pastebin.com/TZUd9nd9
[11:43:27 CEST] <MarkedOne> what am i doing wrong? video is faster than reality
[11:51:29 CEST] <jkqxz> MarkedOne:  Your machine isn't fast enough to do the rawvideo capture at full rate, then you've hard-coded the framerate on the encode to 60fps so you play back the ~18fps stream at 60fps.  (Presumably it's about 3x too fast?)
[11:51:58 CEST] <MarkedOne> yeah.. it seems to be 3 times faster
[11:52:56 CEST] <MarkedOne> so my HDD can save only 18fps?
[11:53:01 CEST] <jkqxz> Try changing all of the 60s to a number which your machine is actually capable of, 15 maybe.  (Many of them are redundant, but it's annoying to work out which ones.)
[11:53:29 CEST] <MarkedOne> isnt 18 fps too low?
[11:53:57 CEST] <jkqxz> Plausible.  18 * 1366 * 768 * 32 = 600Mbps, which is a reasonable hard disk transfer rate.
[11:54:04 CEST] <jkqxz> What do you mean by "too low"?
[11:54:43 CEST] <MarkedOne> when i play back the video again.. 18 pictures per second.. means lagging video probably?
[11:55:32 CEST] <jkqxz> Why would it lag?  Your machine should be able to capture all the frames correctly at that rate (so there's no delay).
[11:56:44 CEST] <MarkedOne> maybe i am wrong.. but i heard that human eye can see 30 images per sec.. and my recording will be only 15 or 18
[11:57:17 CEST] <MarkedOne> or am i missing something? :D
[11:58:25 CEST] <jkqxz> Yes, smooth movement will look visibly jerky.
[11:59:30 CEST] <jkqxz> If you want to capture at a higher framerate you'll need somewhere faster to put the raw data (such as a ramdisk), or you could try encoding it live rather than saving a raw intermediate (how much you can do then depends on how fast your CPU is).
[12:00:10 CEST] <MarkedOne> yeah.. that makes sense..
[12:01:49 CEST] <MarkedOne> can you reccomend any codecs?
[12:05:04 CEST] <jkqxz> How good do you want the output to be?  I would try something like "-c:v libx264 -preset ultrafast -crf 18" (adjust the crf value to your desired quality / speed tradeoff, lower is better).
[12:07:41 CEST] <MarkedOne> i am making video tutorial..
[12:08:19 CEST] <MarkedOne> thank you :) i will try to play with settings you give me :)
[12:11:04 CEST] <jkqxz> So you probably want the output to be bitrate-targetted, and probably not immensely high bitrate so it's sensibly streamable?  You can use "-b:v 10M" or similar with libx264 instead of the CRF.
[12:13:27 CEST] <MarkedOne> it will not be streamed... it is for school... and meant to be played from HDD :) i will try both ways.. and see which is better :)
[12:13:42 CEST] <jkqxz> If you have an recent Intel or NVidia card, then it's also possible to offload the encode onto that.  For example, something like "ffmpeg -vaapi_device /dev/dri/renderD128 -f x11grab -s 1366x768 -framerate 60 -i :0.0 -vf 'format=nv12,hwupload' -c:v h264_vaapi -b 10M out.mkv" should give you a clean capture on an Intel without using excessive CPU.
[12:16:54 CEST] <jkqxz> Oh, probably ignore that last point.  Making either of those work would need you to build your own version rather than using the one in debian.
[12:19:05 CEST] <MarkedOne> yeah xD i show me error :) nvm :)
[12:39:01 CEST] <MarkedOne> just las question :)
[12:39:13 CEST] <MarkedOne> what is difference between -framerate 60 and -r 60 ?
[12:52:32 CEST] <dystopia> you can use -framerate before -i to set input framerate
[12:52:43 CEST] <dystopia> you can use -r after -i to set output framerate
[12:52:58 CEST] <dystopia> it's kinda pointless to set input framerate though in my experience
[12:53:42 CEST] <MarkedOne> so output framerate will skip or dupli frames as needed?
[12:54:09 CEST] <dystopia> no
[12:54:22 CEST] <dystopia> duplicate frames will be present depending on your encoding method
[12:54:50 CEST] <dystopia> like if you bob non bobbable content you will have dupe frames, or on ntsc content if you don't ivtc you will have dupe frames
[12:55:01 CEST] <dystopia> the setting of the framerate has no affect on that
[12:56:35 CEST] <MarkedOne> hmm... okey.. thanks
[13:01:09 CEST] <German> Hello there... I have some transcoding trouble with 4k raw footage from a Sony FS700. When I use this command 'ffmpeg -i A001C001_160516OX/A001C001_160516OX.mxf testtc.mov' I get the audio but not the video. I am new to ffmpeg and need some guidance please.
[13:02:35 CEST] <JEEB> pastebin the `ffprobe FILE_NAME` output
[13:02:44 CEST] <JEEB> and link here
[13:04:39 CEST] <German> Hey JEEB thanks for responding. Well I might need some assistance to do that also please. I am really new to ffmpeg.
[13:06:01 CEST] <JEEB> ffprobe is a probing command that usually comes with the FFmpeg command line tools
[13:06:21 CEST] <JEEB> and instead of -i FILE_NAME it takes just FILE_NAME
[13:07:39 CEST] <German> OK thanks give me a second.
[13:15:37 CEST] <German> JEEB this should be what you looking for. http://pastebin.com/TTrAGiN1
[13:16:02 CEST] <JEEB> congratulations
[13:16:12 CEST] <JEEB> you seem to have stumbled upon another vendor lock-in
[13:16:14 CEST] <JEEB> Stream #0:0: Video: none, none, 25 tbr, 25 tbn, 25 tb
[13:17:16 CEST] <JEEB> you might want to post a sample on the trac issue tracker and tell what it would supposed to be in your opinion (as the coded format, if you have a clue about it). and then some nice fellow might or might not add support for it
[13:18:47 CEST] <dystopia> sony loves proprietary formats
[13:18:48 CEST] <German> That doesn't sound good. Just to make it clear to me. I assume vendor lock-in is when sony doesn't give details what is in the video container?
[13:19:19 CEST] <JEEB> or at least it seems to be a new way of putting stuff into MXF. MXF is full of vendor-specific stuff
[13:19:29 CEST] <JEEB> so at the very least it seems to be something new
[13:21:39 CEST] <German> Don't know what to say. I thought it wouldn't be a problem. I know I would have to install a plugin if I would like to use the footage in Avid. However I hate Avid I planed to use FCPX.
[13:22:35 CEST] <German> The plugin is directly available from Sony
[13:23:14 CEST] <JEEB> > requires a vendor plugin
[13:23:17 CEST] <JEEB> love the enterprise <3
[13:23:27 CEST] <JEEB> anyways, post a sample and give enough specs about the camera
[13:23:35 CEST] <JEEB> there's the trac issue tracker for that
[13:23:44 CEST] <JEEB> then some good soul might help you have the video
[13:24:45 CEST] <German> JEEB Thanks very much for your help. Could you be so nice and give me the URL to the tracker.
[13:26:02 CEST] <JEEB> http://trac.ffmpeg.org/
[13:26:19 CEST] <German> Thanks again!
[14:26:49 CEST] <pZombie> can ffmpeg be used to encode sequences of images sent to it, into a video?
[14:27:20 CEST] <furq> yes
[14:28:26 CEST] <pZombie> then i wonder why no screen capture program exists in windows which makes use of that. At least none that i am aware of
[14:36:38 CEST] <pZombie> how do i get a direct show device that captures the screen?
[14:37:31 CEST] <pZombie> http://pastebin.com/UuAQsf2t   it tells me that i have no direct show devices
[14:37:49 CEST] <BtbN> why would there be a direct show device which captures your screen?
[14:38:23 CEST] <pZombie> well, i am trying to understand how to capture video of my desktop using ffmpeg
[14:39:14 CEST] <BtbN> https://trac.ffmpeg.org/wiki/Capture/Desktop
[14:39:22 CEST] <pZombie> that is where i am
[14:39:32 CEST] <BtbN> Did you install the capture device it links to?
[14:39:50 CEST] <pZombie> no, i must have missed that bit
[14:40:09 CEST] <BtbN> It's not exactly obvious, but the very first line of the windows block links to it.
[14:40:26 CEST] <furq> or you could use gdigrab
[14:40:31 CEST] <furq> https://www.ffmpeg.org/ffmpeg-devices.html#gdigrab
[14:41:08 CEST] <pZombie> thanks, now it's clearer
[14:42:16 CEST] <pZombie> i have no trouble capturing x264 using vfwx264 with virtualdub, in high quality, but i want to test other codecs like vp9, theora etc
[14:42:32 CEST] <pZombie> does ffmpeg support vp9 and theora?
[14:42:48 CEST] <pZombie> i think it does but not 100% certain
[14:42:53 CEST] <furq> ffmpeg -codecs
[14:43:08 CEST] <BtbN> you most likely don't want to use theora
[14:43:10 CEST] <furq> i wouldn't recommend theora though, it's pretty ancient
[14:43:19 CEST] <furq> and i don't think it's even faster than vp8
[14:43:34 CEST] <BtbN> And for vpX to work you need a ffmpeg built with libvpx
[14:43:50 CEST] <pZombie> well, i am looking for a codec which has the same quality as x264 but is not patented
[14:43:51 CEST] <furq> i assume you're using the zeranoe builds which are built with libvpx
[14:44:07 CEST] <furq> vp9 is your only real option and it's really slow
[14:44:18 CEST] <BtbN> There is no truely non-patented codec
[14:44:27 CEST] <BtbN> Only license-fee-free ones.
[14:44:30 CEST] <pZombie> i tried vfwvp8 to capture with virtualdub, but not only is it stupidly slow, but the quality was horrible
[14:45:01 CEST] <BtbN> If you want performance and quality, h264 it is.
[14:45:12 CEST] <pZombie> vp9 does not match h264 quality?
[14:45:20 CEST] <BtbN> it does, but it's horribly slow to encode.
[14:45:21 CEST] <furq> i doubt it does at realtime encoding speeds
[14:45:37 CEST] <furq> especially at high resolutions
[14:45:45 CEST] <BtbN> And libvpx isn't exactly a good piece of software.
[14:45:51 CEST] <pZombie> well, this is quite a fast machine, so if it can match the quality of h264 somewhat, i might be fine with vp9
[14:46:55 CEST] <BtbN> Also, hardware support is lacking. So while h264 plays with nearly no CPU usage everywhere, VP9 does not.
[14:47:25 CEST] <pZombie> i read that new generation CPUs are supposed to support vp9. Could be wrong however
[14:47:46 CEST] <BtbN> The next generation of Intel-GPUs will support VP9 decoding.
[14:47:53 CEST] <BtbN> But those aren't even released yet.
[14:47:57 CEST] <furq> do you have some good reason to be worried about license fees
[14:48:33 CEST] <BtbN> I'm not even sure if Nvidia Pascal supports VP9
[14:48:43 CEST] <pZombie> not yet, no, but i would imagine that if i ever wanted to create my own video hosting site, i wouldn't want for the h264 patent holders to come after me
[14:49:08 CEST] <BtbN> Does VP9 even play in Browsers?
[14:49:10 CEST] <BtbN> Except for Chrome.
[14:49:13 CEST] <furq> yes
[14:49:24 CEST] <furq> all the major browsers except safari now
[14:49:31 CEST] <furq> for obvious reasons
[14:49:40 CEST] <BtbN> Sounds like a good way to kill slow CPUs
[14:50:37 CEST] <pZombie> maybe someone could write an opencl vp9 decoder for GPUs at some point
[14:50:48 CEST] <BtbN> no
[14:50:58 CEST] <BtbN> GPUs are terrible at video decoding.
[14:51:00 CEST] <dystopia> out of curiosity, why would you start a video hosting site? would it not be better to use youtube to host your videos then embed them on your site?
[14:51:07 CEST] <dystopia> much lower bandwidth usage that way
[14:51:08 CEST] <furq> yeah that seems like a pretty big if
[14:52:15 CEST] <pZombie> youtube is horrible. I am surprised they are the top dogs. You upload 10 times the size of a video to get 1/10th of the quality. Even worse, you cannot get perfect quality at all, because they do not allow the full color range but downsample it
[14:53:06 CEST] <furq> it's only very recently that anything other than 4:2:0 was supported in browsers
[14:53:14 CEST] <furq> i think it's still only supported in chrome
[14:53:20 CEST] <pZombie> i can show you videos captured with x264 at high compression, that look 1:1 with the original source. Pixel precise 1:1 and low size too, but when you upload it to youtube, you will never get the colors right
[14:53:30 CEST] <BtbN> Bandwidth is expensive.
[14:53:37 CEST] <furq> and yeah, that
[14:53:44 CEST] <pZombie> exactly, and this is another reason why youtube is doing it wrong
[14:53:59 CEST] <furq> you should tell them
[14:54:02 CEST] <furq> they'll probably be surprised
[14:54:06 CEST] <BtbN> If billions of videos are downloaded every day, saving a few kb in every video is very worth it.
[14:55:18 CEST] <TD-Linux> youtube also can't use all the H.264 features that x264 uses by default
[14:55:36 CEST] <BtbN> Well, they almost stopped using h264
[14:55:46 CEST] <BtbN> They only use it for devices that can't play vp8 or vp9
[14:55:51 CEST] <pZombie> BtbN - but videos captured with the full color range are extremely small in size still, using x264. Youtube makes you upload a 1GB video to get a worse quality from the re-encoding process, than a 50mb video, if they did not re-encode it and kill the colors
[14:56:04 CEST] <TD-Linux> BtbN, they still prefer H.264 over VP8
[14:56:32 CEST] <TD-Linux> full range color is pretty rare. I doubt any players would handle it correctly
[14:56:38 CEST] <pZombie> if you want, i can make a small video to prove my point. It will be small in size, have perfect colors and look just exactly like my desktop looks. Someone looking at it, would not even know it's lossy
[14:56:57 CEST] <BtbN> Probably using a very high h264 feature set.
[14:57:08 CEST] <BtbN> Or are non-420
[14:57:35 CEST] <TD-Linux> youtube also doesn't tag color matrix, and instead changed chrome from rec 601 to 709 for youtube.
[14:58:08 CEST] <JEEB> lol
[14:58:28 CEST] <JEEB> they did finally add stream info in VP9 bit stream I think?
[14:58:37 CEST] <JEEB> so at least unlike VP8 it isn't hardcoded to BT.601 as a format
[14:58:41 CEST] <JEEB> which was quite... funky
[14:58:54 CEST] <TD-Linux> the hardcoding is actually better than having it as a tag and setting it to "unknown"
[14:59:00 CEST] <JEEB> sure
[14:59:49 CEST] <TD-Linux> (both H.264 and VP9 screwed up by making "unknown" even an option)
[15:01:01 CEST] <pZombie> i made the video
[15:01:06 CEST] <pZombie> give me 1min to upload it
[15:03:08 CEST] <furq> we already know what you mean
[15:03:12 CEST] <furq> the point is that most browsers won't play it
[15:03:48 CEST] <furq> i'm not sure if any browsers will play 4:4:4 h.264
[15:03:54 CEST] <pZombie> i want to underline my point still
[15:03:58 CEST] <pZombie> for those who might not know
[15:04:12 CEST] <TD-Linux> firefox can do 4:4:4 but I've only tested VP9 and Theora
[15:04:20 CEST] <furq> yeah i know chrome and ffox support it in vp9
[15:04:47 CEST] <pZombie> here is a screenshot of part of my screen http://i.imgur.com/pXIDv5y.png  and here is the video captured in real time https://drive.google.com/open?id=0BxMwFJfbOvWvUWhqRG16YzhVU0U
[15:05:09 CEST] <pZombie> you would have to download it and play it in a good player that does not render the hell out of the source material
[15:05:16 CEST] <TD-Linux> oh you're doing a screen capture? that's basically the worst case
[15:06:02 CEST] <pZombie> it looks horrible when you play it directly inside the browser
[15:06:29 CEST] <furq> well yeah, gdrive reencodes it so that it's playable in browsers
[15:10:01 CEST] <pZombie> that's a 12mb video, about 0.5mb per second and capture in realtime. Actually i could capture it at the slowest settings for more compression even
[15:10:27 CEST] <pZombie> but i could never reach this quality when uploading to youtube, not even if i uploaded 10GB of video material
[15:11:41 CEST] <pZombie> so they are wasting bandwidth, because people are trying to upload the source material at the highest possible quality for the re-encoding to not totally mess it up
[15:13:54 CEST] <pZombie> also, if instead of capturing the full color range, i captured 420, the difference in size would be minimal
[15:14:49 CEST] <pZombie> so the true reasons behind this quality degradation are hidden somewhere else.
[15:15:34 CEST] <pZombie> why browsers do not support the full color range, why youtube makes you upload gigabytes for no reason, why no other video service exists which accepts your material as is without re-encoding etc
[15:15:57 CEST] <dystopia> because bandwidth costs money
[15:16:02 CEST] <furq> the answer of the third question is the first question
[15:16:14 CEST] <pZombie> which part of capturing this in 420 vs full color range did you not get?
[15:16:49 CEST] <dystopia> 4:2:0 isn't full colour range is it?
[15:16:58 CEST] <c_14> Actually, there's a better question that you forgot. Why do people use web browsers to play video.
[15:17:17 CEST] <pZombie> c_14 - nah, that's not really a good question.
[15:17:44 CEST] <pZombie> it makes sense to click and watch a video in a browser, rather than download it then have to click it to watch it inside a standalone player
[15:17:48 CEST] <c_14> Yes it is, it's a web browser. It's made for rendering HTML that it acquires via HTTP. That's about it
[15:18:11 CEST] <pZombie> a web browser can have a perfectly good quality video player within.
[15:18:28 CEST] <kepstin> 4:2:0 is unrelated to full vs. limited color range; that's color subsampling
[15:19:12 CEST] <pZombie> dystopia - i said that capturing in full color, compared to capturing 420, makes almost no difference at all in the final size of your video
[15:19:21 CEST] <pZombie> when encoded with x264
[15:19:57 CEST] <pZombie> the difference is so minimal that it cannot be used as an argument why youtube does not allow the full color range or why browsers do not support it in their players
[15:20:09 CEST] <furq> nobody's saying that they're subsampling it because of bandwidth
[15:20:14 CEST] <furq> they're subsampling it so that browsers can play it
[15:20:31 CEST] <furq> the fact that they reencode everything to the same too-low bandwidth is a separate issue
[15:20:48 CEST] <pZombie> ok, and why do players in browsers not support the full color range?
[15:21:00 CEST] <pZombie> what is the reason for that one?
[15:21:04 CEST] <furq> why are you asking me
[15:21:17 CEST] <pZombie> because i was hoping that you would think a few steps ahead
[15:21:26 CEST] <pZombie> given that youtube supported the full color range
[15:21:26 CEST] <furq> if i could make browser makers support everything i wanted them to, my life would be much easier
[15:21:55 CEST] <pZombie> and one of the browsers supported the full color range, but others didn't... wouldn't that set that one browser ahead of the competition?
[15:22:02 CEST] <pZombie> people would want to watch pretty videos
[15:22:07 CEST] <pZombie> rather than washed out colors
[15:22:10 CEST] <dystopia> lots of things can't handle 4:2:2
[15:22:18 CEST] <dystopia> including hw players
[15:22:24 CEST] <dystopia> it's not just a browser issue
[15:22:29 CEST] <furq> the problem is that every video host has to support the lowest common denominator
[15:22:59 CEST] <furq> not many people will notice blocky colours, but everyone will notice videos not playing
[15:23:09 CEST] <dystopia> also the average person watching your vid wont notice any issues
[15:23:16 CEST] <dystopia> yeah
[15:24:15 CEST] <furq> it's rare that 4:2:0 looks noticeably worse anyway, it's only pathological cases like screen capturing
[15:24:22 CEST] <pZombie> they certainly will notice that especially green fonts when watching some tutorial containing such, will look horrible and give them eye cancer.
[15:24:39 CEST] <pZombie> it does look extremely worse.
[15:24:41 CEST] <furq> or people who don't know that they have to outline text in videos
[15:24:56 CEST] <BtbN> You'd be surprised how bad a video can look before the average viewer will notice or even complain about it.
[15:25:01 CEST] <furq> ^
[15:25:27 CEST] <pZombie> the only reason some might think that it does not look much much worse is because they have never compared the two side by side in cases where it matters
[15:25:39 CEST] <BtbN> Just look at Twitch. People Streaming 1080p60 at 3.5Mbit/s. And everyone is impressed at the quality!
[15:25:45 CEST] <furq> i did say there are cases where it looks much worse
[15:25:50 CEST] <furq> those are not very common
[15:26:37 CEST] <furq> although it's probably getting more common with the rise of video game streaming
[15:32:06 CEST] <pZombie> which device would a yuv444 recorded video not play on for example, given that browsers supported the full color range?
[15:40:50 CEST] <zamba> can someone help me figure out why i'm experiencing these audio/video sync issues?
[15:40:59 CEST] <zamba> looking at the source (dv) it looks just fine
[15:41:22 CEST] <TD-Linux> pZombie, H.264's High profile doesn't specify 4:4:4, so many phones probably will fail
[15:44:19 CEST] <JEEB> basically >95% of all HW decoders only support 4:2:0, 8bit AVC
[16:11:00 CEST] <Mooniac>  I use ffmpeg to screenrecord with my voice as audio. With Ctrl-Z I send it to the background, but for some reason it keeps recording the audio. It stops the video recording, but it keeps recording the audio (me talking). I don't understand how this is possible. What I really want is to stop recording both (pause the dumping into the file)
[16:26:06 CEST] <pZombie> isn't there any frontend to ffmpeg for screen capturing + audio recording in realtime?
[16:31:06 CEST] <pZombie> actually, obs studio can act as a front-end to record realtime using ffmpeg when advanced settings are enabled, but "surprisingly" when trying to record in full color range, it fails
[18:14:18 CEST] <crst> Hi, can you help me in achieving the lowest file size/best quality with the fastest possible encoding time (without sacrificing quality)? I have no idea how the video release groups can get these file sizes and this amazing quality.
[18:14:47 CEST] <crst> My encodings are way too big
[18:15:02 CEST] <crst> 540p 10mins 500MB
[18:15:27 CEST] <crst> inout is 1080p
[18:15:30 CEST] <crst> *input
[18:16:04 CEST] <crst> from a DSLR with H264 and then edited in FCPX
[18:49:28 CEST] <pZombie> -pix_fmt yuv420p  what furq suggests. -pix_fmt yuv440p what i suggest
[18:49:58 CEST] <pZombie> -pix_fmt yuv420p  what furq suggests. -pix_fmt yuv444p what i suggest , not 440p sorry
[18:50:29 CEST] <pZombie> -preset placebo is what i suggest. Not sure what furq suggests
[18:50:57 CEST] <pZombie> it will take longer to encode but the file size will be as small as currently possible at the same quality
[18:51:18 CEST] <pZombie> what i do NOT know, is if it would also take more CPU to decode
[18:51:45 CEST] <pZombie> probably. I just cannot estimate how much more CPU it would take and if it would be significant for slower systems
[18:54:27 CEST] <crst> So this would be furq's command, am I right? ffmpeg -i input.mp4 -crf 20 -preset slow -tune film -vf scale=-2:540 -pix_fmt yuv444p -c:a aac -b:a 128k output.mp4
[18:55:01 CEST] <pZombie> -preset placebo if you want the max compression, but i guess that slow is good enough
[18:55:28 CEST] <crst> ah, sorry he suggested -preset veryslow
[18:55:33 CEST] <crst> later
[18:55:49 CEST] <pZombie> also good enough
[18:56:26 CEST] <crst> pZombie: and you'd go with placebo and -pix_fmt yuv444p?
[18:56:42 CEST] <pZombie> i would go with slow first, to check the quality
[18:56:50 CEST] <pZombie> only if the quality is right would i do placebo
[18:57:06 CEST] <pZombie> for that extra compression
[18:58:38 CEST] <crst> This is the summary, are you ready?:
[18:58:39 CEST] <crst> furq:
[18:58:40 CEST] <crst> ffmpeg -i input.mp4 -crf 20 -preset veryslow -tune film -vf scale=-2:540 -pix_fmt yuv420p -c:a aac -b:a 128k output.mp4
[18:58:40 CEST] <crst> pZombie:
[18:58:42 CEST] <crst> ffmpeg -i input.mp4 -crf 20 -preset veryslow -tune film -vf scale=-2:540 -pix_fmt yuv444p -c:a aac -b:a 128k output.mp4
[18:58:51 CEST] <pZombie> Yes! GO!
[18:58:57 CEST] <pZombie> \o/
[18:59:04 CEST] <crst> Ok!
[19:05:15 CEST] <crst> I'm getting back to you soon. (speed=0.556x) for 12:35min.
[19:06:55 CEST] <pZombie> btw, even if this works out to be better, you should probably dive deeper into how -pix_fmt works. I am not an expert on this, just know that when i encoded my screen capture with yuv444p it looked exactly like the original. with 420p it just looked horrible
[19:07:26 CEST] <furq> screen capturing is a pathological case
[19:08:09 CEST] <furq> for footage straight from a camera, you're unlikely to be able to notice any difference between 4:4:4 and 4:2:0
[19:09:12 CEST] <pZombie> furq - if you take a video, encode it in 420p then take the same video and re-encode it in 420 will it look the same?
[19:09:33 CEST] <furq> i assume one of those was supposed to be 444
[19:09:39 CEST] <furq> and it depends on the source
[19:09:45 CEST] <pZombie> that came out wrong
[19:10:06 CEST] <pZombie> no, i means encode the source in 420p, then take the output and re-encode it in 420p
[19:10:25 CEST] <pZombie> will the first output look the same as the second output?
[19:10:31 CEST] <furq> yes?
[19:10:48 CEST] <furq> you can't convert from 4:2:0 to 4:4:4 without rescaling
[19:11:16 CEST] <furq> 4:2:0 is half chroma resolution in both dimensions
[19:11:29 CEST] <pZombie> i am not talking about 444 at the moment
[19:12:03 CEST] <pZombie> just source enc 420p-> output enc 420p-> output2
[19:12:22 CEST] <furq> they'll look identical if you're doing a lossless encode
[19:12:33 CEST] <furq> 4:2:0 to 4:2:0 doesn't lose any information
[19:13:02 CEST] <pZombie> would output be of the same size as output2 ?
[19:13:07 CEST] <furq> yes
[19:13:14 CEST] <furq> the chroma resolution is half the luma resolution
[19:13:50 CEST] <furq> https://en.wikipedia.org/wiki/Chroma_subsampling
[19:15:27 CEST] <pZombie> what about 422 he is using as source? Does it have the full color range?
[19:15:34 CEST] <pZombie> or is it lossy like 420?
[19:16:19 CEST] <furq> 422 is half horizontal, full vertical
[19:17:25 CEST] <pZombie> from the wiki article you linked, it is lossy. "4:2:2 Y'CbCr scheme requires two-thirds the bandwidth of (4:4:4) R'G'B'. This reduction results in almost no visual difference as perceived by the viewer for photographs, although images produced digitally containing harsh lines and saturated colors will have significant artifacts"
[19:18:10 CEST] <pZombie> this would require a lot of reading to actually understand all the formats
[19:18:31 CEST] <furq> you're unlikely to ever encounter anything but 4:4:4, 4:2:2 and 4:2:0
[19:19:11 CEST] <pZombie> when i use -pix_fmt yuv444p vs -pix_fmt argb or bgra when encoding, would the output in all of those cases have the same size or would argb&bgra be larger in size?
[19:19:25 CEST] <furq> well rgba is 32bpp, so yes
[19:19:39 CEST] <pZombie> also, would yuv444p look identical 1:1 with bgra and argb?
[19:19:47 CEST] <furq> i think yuv compresses better than rgb but i'm not totally sure
[19:21:19 CEST] <pZombie> i am very sensitive to color differences. Took a test and i can discern colors 100%
[19:21:57 CEST] <crst> 2 things came into my mind: would it be beneficial (i.e. encoding speed) if I export the lossless source to 540p at first? And am I good to go to use the encoded vid with these settings on the web (self-hosted)?
[19:22:59 CEST] <furq> you'll need to use yuv420p for browser compatibility
[19:23:15 CEST] <furq> and i doubt it'll make any difference prescaling it because it'll just make the export take longer
[19:23:45 CEST] <crst> I see
[19:23:53 CEST] <crst> thanks
[19:23:56 CEST] <furq> actually i guess it depends what you mean by lossless
[19:24:04 CEST] <furq> if it's compressing it then that might be faster at a lower resolution
[19:28:55 CEST] <wst0rm> hi guys... I'm trying to compile a NVENC version of ffmpeg in a g2 amazon box with Amazon Linux but I'm having trouble to do so... Brainiarc7
[19:29:34 CEST] <wst0rm> already tried the Brainiarc7 version... and with the new 6.0 SDK
[19:30:01 CEST] <BtbN> the only dependency for nvenc is that one header from the SDK.
[19:30:07 CEST] <wst0rm> even with 6.0 in /usr/includes dir it still gives me the API 5.0 error
[19:30:23 CEST] <BtbN> you didn't use the right SDK then.
[19:30:31 CEST] <BtbN> You need the nvenc SDK 6
[19:31:53 CEST] <wst0rm> BtbN: isn't this https://developer.nvidia.com/video-sdk-601 ?
[19:32:04 CEST] <BtbN> yes, exactly that.
[19:32:11 CEST] <BtbN> As long as you don't download the legacy version.
[19:34:09 CEST] <wst0rm> no joy on that... I've downloaded the 5.0 but got the 6.0 and overwritten it on /usr/includes... it still gives me the 5.0 error... do you know of any pre-compiled builds with nvenc?
[19:36:56 CEST] <BtbN> Just look for the Major Version in the header.
[19:37:01 CEST] <BtbN> If it's 6, you're good.
[19:39:39 CEST] <wst0rm> all right thank you!
[19:41:07 CEST] <BtbN> I'd strongly suspect that it's not using the header you copied if it still complains about the version while the header has the right one in it.
[19:41:53 CEST] <pZombie> i cannot interpret the info on the web about yuv444 vs rgb correctly it seems. On the one hand, i read that both formats use 8bit per color, but then i read that it would make sense to use rgb if you wanted lossless, or go for 10bit yuv. Doesn't make sense to me.
[19:42:13 CEST] <pZombie> if both use 8bit per color, why would yuv444 not work for lossless, given your source material is 8bit per color
[19:42:48 CEST] <pZombie> on the other hand, what good would it be if your source material is 8bit per color, but you encode in yuv444 10 bit?
[19:42:53 CEST] <wst0rm> yeah... maybe some problem with the PATH... anyway... Thank you very much for your help...
[19:43:05 CEST] <pZombie> seems like you need to be a rocket scientist to understand all this
[19:49:24 CEST] <crst> furq: your settings came out pretty nice looking at first sight. 23m26s encoding time. 185MB, 14.8MB/s.
[19:49:25 CEST] <crst> pZombie: I switched to -preset slow. Looks nice, too. File is incompatible with my system, but VLC can open it. 8m32s encoding time. 171.3MB, 13.7MB/s.
[19:49:25 CEST] <crst> I'm sorry for saying that, but this is still a bit too big for 12.5min, imho. I'm trying achieve more like 3-4MB/min like the release guys can do.
[19:50:05 CEST] <pZombie> what about the quality?
[19:50:17 CEST] <pZombie> do they both look identical or are there differences?
[19:50:35 CEST] <wst0rm> btBN: you're right... ffmpeg's include path was wrong... =)
[19:50:42 CEST] <pZombie> also, i found this famous lol group everyone is talking about.
[19:50:56 CEST] <pZombie> and they actually post their full settings, or so it seems in some of their videos
[19:52:44 CEST] <pZombie> crst - those are the settings in one of the videos i saw http://pastebin.com/Cv1ciDxt but this is 1280x720p, i guess you want smaller still
[19:53:47 CEST] <crst> pZombie: no big noticeable dirrerences. Wow, thanks. Maybe I run these LOL settings against the export and see what the difference is.
[19:53:59 CEST] <pZombie> this would be a video in 720x404 http://pastebin.com/HUZ2MK3u
[19:54:19 CEST] <pZombie> but duration seems to be only 21min and size 221mb
[19:54:24 CEST] <pZombie> so bad again
[19:55:09 CEST] <crst> oh yes, this is about the same. wait a sec I'm going to check out a movie I have.
[19:55:11 CEST] <pZombie> that is 10mb/min, double what you are expecting to achieve
[19:55:34 CEST] <crst> yeah, just a liitle bit smaller
[20:05:40 CEST] <furq> crst: you probably want to denoise the source
[20:06:12 CEST] <furq> the settings in that pastebin will probably result in a larger filesize with the same source
[20:06:24 CEST] <crst> I've found an example, maybe not the best but: Indiana Jones - Temple of Doom, 1280x546, 23.976fps, 1h52min, 526.2MB, 4.5MB/s
[20:06:42 CEST] <furq> the compressibility is really entirely down to the source video
[20:06:59 CEST] <furq> if you have lots of motion and fine detail then that will kill the compressibility
[20:08:59 CEST] <crst> furq: how much more could I get out of your command if I tweak some settings?
[20:09:17 CEST] <furq> not much unless you increase the crf
[20:09:48 CEST] <crst> what's the pain limit?
[20:09:54 CEST] <furq> the default is 23
[20:10:28 CEST] <crst> ok, I'll run that. Is there a faster -preset ?
[20:10:47 CEST] <crst> faster and acceptable
[20:11:04 CEST] <crst> for a quick test
[20:11:25 CEST] <JEEB> if you have the x264 command line app you can use x264 --help to list them
[20:11:34 CEST] <JEEB> because the libx264 wrapper just reuses those
[20:11:43 CEST] <JEEB> or well, passes the value to x264 itself
[20:11:55 CEST] <furq> http://webcache.googleusercontent.com/search?q=cache:KkfgYoE8JrIJ:dev.beandog.org/x264_preset_reference.html+&cd=1&hl=en&ct=clnk&gl=uk
[20:12:12 CEST] <crst> JEEB: I have that
[20:12:29 CEST] <JEEB> furq: at least link the old x264 mewiki page :P
[20:12:45 CEST] <JEEB> that was actually updated by people from #x264 I think
[20:13:06 CEST] <JEEB> I think it got mirrored @ https://en.wikibooks.org/wiki/MeGUI/x264_Settings
[20:13:21 CEST] <JEEB> crst: if you just do x264 --help it should list them, no?
[20:13:48 CEST] <furq> if you're getting >10mbit at 540p then there's probably no real option except filtering the source
[20:13:55 CEST] <pZombie> crst i encoded 1min of video which was a youtube video i captured from my screen lossless with the lagarith codec. The output was 6mb
[20:14:05 CEST] <pZombie> i used the settings you used
[20:14:15 CEST] <furq> if it's high-motion then there's not much you can do except maybe stabilisation
[20:14:19 CEST] <pZombie> 6.4mb to be precise
[20:14:19 CEST] <JEEB> anyways, with CRF you should more or less be able to control the quality (not on an exact level because the things that define the result depend on the preset selected), and then with preset you can change the speed
[20:14:41 CEST] <furq> you could also try removing -tune film
[20:14:43 CEST] <JEEB> (this is why going from slow to veryslow/placebo with the same CRF can result in bigger files)
[20:14:51 CEST] <furq> that'll preserve less fine detail
[20:17:51 CEST] <crst> JEEB: Yes, it does, quite helpful, thanks. pZombie: nice! 6.4MB is great. My vid is in a pretty dark environment shot in candlelight, maybe because of that. I can run another test on a brighter source.
[20:18:43 CEST] <crst> there is mostly much camera motion but not so wildly in general.
[20:19:00 CEST] <pZombie> if you have some sample video you can cut to 1min, you can upload, i could try to encode it here to see if there is a difference
[20:19:19 CEST] <pZombie> https://drive.google.com/open?id=0BxMwFJfbOvWvOVNpRnJtdm5WaE0   the video i encoded, exactly 1min
[20:19:33 CEST] <pZombie> setting are as i said above, same as those you tried
[20:20:12 CEST] <pZombie> you have to download it to play it properly. In the browser it will look horrible
[20:21:12 CEST] <JEEB> yes, google re-encodes it quickly for browser viewing
[20:26:22 CEST] <pZombie> hm, strangely enough, the lagarith lossless did not capture the colors properly
[20:26:27 CEST] <pZombie> i have to look into this
[20:27:59 CEST] <crst> pZombie: my source in 900MB/min and my upload speed is really beyond good and evil, unfortunately. Like France countryside mobile connection bad...
[20:28:00 CEST] <crst> I downloaded your vid, looks not quite good, maybe I didn't get the proper sourcefile. In comparison to my encode your setting are of much better quality. Nevertheless, I'm going to do a new encode for a bright video. Or maybe I have too much noise in my vids in general because of a 1.4 Aperture I use all the time.
[20:29:19 CEST] <pZombie> are you using windows or linux?
[20:29:32 CEST] <crst> osx
[20:34:14 CEST] <pZombie> oh that is why my video looked strange, i forgot to remove the scale
[20:36:06 CEST] <pZombie> the new video without having to scale is much shorter too
[20:36:20 CEST] <pZombie> 4.56mb only per minute
[20:37:11 CEST] <pZombie> https://drive.google.com/open?id=0BxMwFJfbOvWvaDlBZlpWMENGWDg   here is the new one. better colors. Identical to the original it seems
[20:37:21 CEST] <pZombie> and smaller size too
[20:41:32 CEST] <crst> pZombie: I see, it already looks like the original source. because it's from tv.
[20:42:20 CEST] <pZombie> no, that is not the reason it looks like the original
[20:42:42 CEST] <pZombie> if i used a more lossy encoding setting, it would look less like the original
[20:43:06 CEST] <crst> I mean it already looks kind of fuzzy because its from tv.
[20:44:02 CEST] <pZombie> yes, and because it is played inside the browser as well
[20:45:40 CEST] <pZombie> as i said, if i had a cut sample of 1min or even 10 seconds, we could see how it works with the same settings on my pc
[20:45:48 CEST] <crst> Sure, great rip, nevrtheless 4.5MB/s is very impressive. Is there a lot size growth between  -ultrafast vs -slow? I just used crf23 with ultrafast and its kid of big.
[20:45:51 CEST] <pZombie> maybe the way i compiled ffmpeg makes a difference
[20:46:16 CEST] <crst> pZombie: hopefully not
[20:46:28 CEST] <pZombie> ffmpeg -i test.avi -crf 20 -preset veryslow -tune film  -pix_fmt yuv444p -c:a aac -b:a 128k output.mp4    this is all i did on my side
[20:47:21 CEST] <crst> pZombie: can you upload the source?
[20:47:30 CEST] <crst> so I can run it?
[20:47:48 CEST] <pZombie> lol, the source is 291mb
[20:47:56 CEST] <crst> pZombie: oh...
[20:48:52 CEST] <pZombie> but i can make a screenshot of the source
[20:50:06 CEST] <pZombie> http://i.imgur.com/4xbpa5n.png
[20:50:20 CEST] <pZombie> looks pretty identical to me to the compressed
[20:57:42 CEST] <pZombie> found some nice lossless lagarith samples here  http://samples.mplayerhq.hu/V-codecs/lagarith/
[20:57:59 CEST] <pZombie> download the 18mb one, i will encode now with the same settings and upload
[20:58:47 CEST] <crst> ok
[21:00:08 CEST] <JEEB> if you want encoding samples for testing, I recommend the xiph sample library
[21:00:20 CEST] <JEEB> https://media.xiph.org/video/derf/
[21:00:25 CEST] <JEEB> scroll down for higher resolutions
[21:00:39 CEST] <pZombie> thanks
[21:01:09 CEST] <pZombie> 18mb compressed down to 155kb
[21:01:30 CEST] <crst> wow, just saw in my 1st vid crf23 difference between -ultrafast and -medium is 73MB
[21:01:31 CEST] <pZombie> so 1min would be like 1mb for this format
[21:01:47 CEST] <pZombie> https://drive.google.com/open?id=0BxMwFJfbOvWvd3UwUUh6Vy02azg   here is the encoded eagle avi
[21:02:01 CEST] <JEEB> crst: just don't think that the result is completely the same, but yes - in that case it's mostly just the compression stuff getting disabled in order to gain speed
[21:03:47 CEST] <pZombie> JEEB what is CIF and QCIF?
[21:03:53 CEST] <crst> pZombie: 259kb
[21:03:59 CEST] <crst> 159kb
[21:04:13 CEST] <JEEB> pZombie: old namings for specific SD resolutions
[21:08:51 CEST] <crst> On a bright vid I'm getting 10MB/s
[21:09:06 CEST] <crst> maybe it's my camera
[21:10:51 CEST] <pZombie> what's your download speed?
[21:11:41 CEST] <pZombie> maybe if we could agree on a somewhat longer sample found here https://media.xiph.org/video/derf/
[21:11:53 CEST] <crst> depends ~200KB/s
[21:12:07 CEST] <JEEB> the issue with those of course is that they're usually raw vs just losslessly encoded
[21:12:41 CEST] <JEEB> some of them are max a few GiBs though, so if that's OK...
[21:12:45 CEST] <crst> pZombie: but we got roughly the same with the avi, didn't we?
[21:13:01 CEST] <pZombie> yes, but maybe it was too small
[21:13:20 CEST] <pZombie> what we need is a 720p good quality 1min video to encode
[21:13:30 CEST] <pZombie> but the size would be too large to download for oyu
[21:13:34 CEST] <pZombie> you*
[21:13:56 CEST] <furq_> what are you trying to test here
[21:14:16 CEST] <crst> pZombie: how big can the smallest be?
[21:14:41 CEST] <pZombie> well, if it's lagarith lossless, it will be around 300mb per minute at 720p
[21:15:11 CEST] <pZombie> furq_ just trying to see if with same encoding settings we get the same results
[21:15:28 CEST] <furq> why wouldn't you
[21:15:40 CEST] <pZombie> maybe his ffmpeg version is different, i don't know. Differently compiled, whatever
[21:15:56 CEST] <furq> as long as the libx264 version is the same you'll get the same results
[21:16:08 CEST] <crst> yeah, I compiled from homebrew for instance
[21:16:19 CEST] <pZombie> yes, but is it guaranteed that his libx264 is the same as mine?
[21:18:46 CEST] <crst> I strongly suspect my camera source files to be the culprit though. 1.4 aperture.
[21:18:58 CEST] <crst> noise
[21:19:28 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#hqdn3d-1
[21:20:28 CEST] <crst> difference between medium and slow was 5MB of my newest test with crf23
[21:21:07 CEST] <crst> furq: oh my god
[21:21:12 CEST] <crst> that's huge
[21:22:03 CEST] <crst> ah, you're referring only to hqdn3d
[21:24:04 CEST] <crst> where do i put that at best? first position?
[21:28:34 CEST] <furq> -vf scale=-2:540,hqdn3d
[21:29:00 CEST] <furq> there are other denoise filters in ffmpeg, i'm not sure which is recommended these days
[21:29:26 CEST] <viric> I have many hours of digitized vhs, interlaced, and with time base errors
[21:29:30 CEST] <viric> (lines go left and right)
[21:29:48 CEST] <viric> there is nothing ready to correct vhs time base on digital pictures, is there?
[21:38:17 CEST] <pZombie> well, i found some nice 4k video samples of 1min, they are compressed but i don't think it will make a huge difference when we scale them down to 720x404
[21:38:39 CEST] <pZombie> crst around still?
[21:39:15 CEST] <crst> pZombie: sure
[21:39:17 CEST] <pZombie> why do they use 720x404 instead of 720x405?
[21:39:32 CEST] <pZombie> (720/16)*9 = 405
[21:39:40 CEST] <JEEB> because mod1 is not a thing you can do with 4:2:0
[21:40:05 CEST] <JEEB> 4:2:0 has the chroma (blue and red color) planes limited to one sample per 2x2
[21:40:21 CEST] <pZombie> crst want to try this video? http://4ksamples.com/ses-astra-uhd-test-2-2160p-uhdtv/
[21:40:30 CEST] <pZombie> it's 323mb
[21:40:39 CEST] <pZombie> will take a little for you to download i guess
[21:40:55 CEST] <pZombie> but it is 4k and exactly 1min
[21:41:05 CEST] <pZombie> that should show us some good results i believe
[21:41:33 CEST] <JEEB> thus, the video (including luma, which you can think of as the light in the picture) has to be divisible by 2
[21:41:33 CEST] <crst> furq: nice filter: crf23 medium 94MB looks pretty sweet!
[21:42:06 CEST] <JEEB> some formats let you do non-mod2 4:2:0 but that can lead to some really weird stuff and it is not supported in most formats
[21:42:48 CEST] <crst> pZombie: ok, I'm downloading
[21:42:52 CEST] <pZombie> god, this is all so complicated
[21:43:24 CEST] <crst> 380KB/s woo!
[21:43:57 CEST] <JEEB> pZombie: I just got a book on all the history etc on this and it has a nice title: "Circles of Confusion"
[21:44:49 CEST] <pZombie> JEEB - so i have to scale this video to 720x404, 720x405 will give me an error?
[21:45:19 CEST] <JEEB> unless you use 4:2:2 or 4:4:4 which lets you have every line of height, yes.
[21:45:40 CEST] <pZombie> i will use 4:4:4
[21:45:59 CEST] <JEEB> well in that case it doesn't really matter since both luma and chroma are 1x1
[21:46:07 CEST] <JEEB> as in, each luma has a matching chroma value
[21:46:17 CEST] <pZombie> so my command would look like this? -vf scale=-2:405?
[21:46:29 CEST] <pZombie> probably wrong
[21:46:40 CEST] <JEEB> or you could just set the values specifically if you know them already
[21:46:47 CEST] <pZombie> the video source is 3840x2160
[21:46:56 CEST] <pZombie> and i want to get it down to 720x405
[21:47:09 CEST] <JEEB> that said, are you testing something in an area where 4:2:2 or 4:4:4 is an alternative?
[21:47:30 CEST] <JEEB> I mean, 4:2:2 and 4:4:4 are unsupported by >95% of all HW decoders, for example
[21:47:54 CEST] <JEEB> plus most non-libavcodec decoders don't support 4:4:4 because it's not perceived as something that "normal end users" would require
[21:47:55 CEST] <pZombie> they are supported by both VLC and MPC-HC players, which is all i care about
[21:48:02 CEST] <JEEB> ok, sure
[21:48:07 CEST] <JEEB> just saying that if you're going to make a test
[21:48:16 CEST] <JEEB> make sure it's in a range that is actually usable
[21:48:39 CEST] <JEEB> being able to play with 4:4:4 is great, but if you can't actually use it in the use case it really doesn't help as a test :P
[21:48:50 CEST] <pZombie> yes, but is the command -vf scale=-2:405 correct for getting this 3840x2160 video down to 720x405?
[21:49:28 CEST] <JEEB> it should be, yes. it does make sure that the width is mod2 but in your case 720 should be mod2 so it should lead to the correct result
[21:51:06 CEST] <pZombie> hm, something is wrong
[21:51:44 CEST] <pZombie> Past duration 0.999992 too large
[21:51:44 CEST] <pZombie> [hevc @ 000001ca942e15e0] Skipping NAL unit 63    i keep getting spammed by this message
[21:52:06 CEST] <pZombie> should i ignore it, or no go?
[21:52:25 CEST] <JEEB> that's just a message from the HEVC decoder that it's skipping those NAL units. and the past duration is just something you shouldn't be too worried about unless things keep happening like it
[21:53:30 CEST] <JEEB> HEVC sources shouldn't be used for encoding *speed* comparisons in any case btw, since the HEVC decoder is very much unoptimized (because nobody cares and nobody wants to pay to improve it within FFmpeg)
[21:53:52 CEST] <JEEB> that said, in general for speed tests you are recommended to use raw video on a fast medium
[21:54:07 CEST] <pZombie> i am not testing the speed though
[21:54:13 CEST] <JEEB> yeah, in that case it's fine
[21:54:26 CEST] <JEEB> just that you shouldn't start making assumptions regarding the speed as the decoder might be the bottleneck
[21:54:31 CEST] <pZombie> can i turn off those messages? They are so many and come so fast, i think they might be even impacting the encoding speed
[21:54:46 CEST] <JEEB> set another -v level
[21:54:55 CEST] <pZombie> just finished
[21:55:13 CEST] <pZombie> i have doubts it actually encoded anything with so many messages... checking now
[21:55:44 CEST] <pZombie> wow it did
[21:55:48 CEST] <pZombie> and the quality is STUNNING
[21:55:51 CEST] <pZombie> uploading it
[21:55:57 CEST] <JEEB> the NAL messages should be OK, since it's just "skipping these units (that we're not gonna handle)"
[21:56:13 CEST] <JEEB> not sure if that message as such is required, esp. with the standard verbosity level
[21:56:19 CEST] <crst> pZombie: what's the MB/s?
[21:56:59 CEST] <pZombie> the file is 16mb... you will die when you see the quality
[21:57:18 CEST] <crst> pZombie: can't wait
[21:57:33 CEST] <crst> so 16MB/min?
[21:57:46 CEST] <pZombie> no, video is actually 2min 22sec
[21:57:48 CEST] <pZombie> it turns out..
[21:57:57 CEST] <crst> ok
[21:58:37 CEST] <crst> pZombie: please post me your exact command
[21:59:17 CEST] <pZombie> ffmpeg -i 4k_test.mkv -crf 20 -preset veryslow -tune film -vf scale=-2:405 -pix_fmt yuv444p output.mp4   , i removed the audio it seems because i got some warning msg
[21:59:26 CEST] <pZombie> i will try with audio again
[21:59:41 CEST] <pZombie> here is the link https://drive.google.com/open?id=0BxMwFJfbOvWvOWtZd2FKemlNZDg
[22:00:35 CEST] <Regda> the report parameter does not work as describted in the doc :/
[22:00:39 CEST] <Regda> https://ffmpeg.org/ffmpeg.html#Generic-options
[22:00:51 CEST] <Regda> if i write "FFREPORT=file=ffreport.log:level=32 ffmpeg -i input output"
[22:01:29 CEST] <Regda> i get an error message like ffreport cant be found
[22:01:58 CEST] <pZombie> i ll try placebo now
[22:02:05 CEST] <Regda> how can i use this global variables ?
[22:06:31 CEST] <crst> pZombie: 16.8MB
[22:06:32 CEST] <pZombie> no difference with placebo. At 7.2mb/s still
[22:06:53 CEST] <pZombie> mine is exactly 16mb
[22:07:05 CEST] <pZombie> did you download it to check the quality?
[22:07:18 CEST] <crst> pZombie: why could that be?
[22:07:31 CEST] <crst> Not yet
[22:07:38 CEST] Action: crst be right back
[22:07:46 CEST] <pZombie> don't ask me, furq or JEEB or other experts in here might know i guess :D
[22:08:19 CEST] <pZombie> either it is you are using a different libx264 or it's related to osX somehow
[22:19:02 CEST] <wolfman2000> Afternoon. I'm trying to re-build ffmpeg to always stick to the 64-bit architecture. I'm having issues with libavformat when it gets to...ranlib I think. Is there perhaps something wrong with my configure script? http://hastebin.com/yipiqojoze.mel
[22:22:30 CEST] <JEEB> have you cleaned up properly?
[22:22:58 CEST] <JEEB> also I guess you don't have a proper cross-prefixed toolchain so you could just set that?
[22:24:43 CEST] <wolfman2000> JEEB: thought I did clean already. I'll double-check
[22:31:43 CEST] <wolfman2000> JEEB: Looks like I did miss something on the prior cleanup steps. Then again, git clean -dfx can be good for that. I'm covered now. Thanks.
[22:32:17 CEST] <JEEB> I recommend doing out-of-tree builds for that (or at least a subdirectory in the source dir if you can't make a separate dir)
[22:32:33 CEST] <JEEB> then you can just rm -rf my_build_dir && mkdir -p my_build_dir
[22:32:43 CEST] <JEEB> and do configure from within it
[22:33:03 CEST] <wolfman2000> I'll look into that. Again, thanks.
[22:36:32 CEST] <crst> pZombie: looks about the same. your's is also 16.8MB on my disk. So I think our filesystem stores/calculates sizes differently.
[22:37:18 CEST] <crst> can anybody recommend another filter setting which reduces filesize even more without being too obtrusive? right now I'm at 7.5MB/s
[22:37:40 CEST] <Regda> how can i create the environment variable FFREPORT ?
[22:37:56 CEST] <Regda> (using windows 7)
[22:38:11 CEST] <Regda> must i create them like PATH variable ?
[22:38:26 CEST] <Regda> or is that an ffmepg specific thing ?
[22:39:20 CEST] <furq> set FFREPORT=xyz
[22:39:35 CEST] <crst> pZombie: file is even exact the same (16'848'446 bytes)
[22:39:45 CEST] <furq> will set it until you close that command prompt
[22:39:54 CEST] <furq> you can set it permanently like you would set any other env var
[22:40:56 CEST] <pZombie> crst ohmy, i had to use properties on the file, you are right
[22:41:27 CEST] <furq> crst: you can use more aggressive hqdn3d settings
[22:41:32 CEST] <pZombie> the not so detailed size display in the status bar was showing it as exactly 16,0
[22:41:39 CEST] <furq> or try some of the other denoise filters
[22:42:14 CEST] <furq> but yeah any suspiciously small scene release which doesn't look like garbage will have been heavily denoised
[22:42:16 CEST] <pZombie> crst - what do you think about the quality?
[22:42:47 CEST] <furq> heavily denoised video tends to look quite good if you don't have the source to compare it to
[22:42:50 CEST] Action: crst I died
[22:43:01 CEST] <pZombie> lol
[22:43:07 CEST] <crst> :D
[22:43:15 CEST] <pZombie> it's really good, isn't it?
[22:44:05 CEST] <pZombie> i will try 420p now
[22:44:09 CEST] <pZombie> see the difference
[22:44:27 CEST] <furq> is there an abx testing tool for videos
[22:45:07 CEST] <crst> pZombie: yeah, pretty good settings. the only thing, it's not compatible with my system, I personally prefer yuv420p.
[22:46:18 CEST] <pZombie> when you say that it is not compatible with your system, which system are you referring to?
[22:46:23 CEST] <pZombie> obviously you watched the video
[22:46:55 CEST] <crst> pZombie: with vlc
[22:47:36 CEST] <crst> osx has no support for this, unfortunately, also mkv.
[22:48:02 CEST] <Regda> thanks furq, it works.
[22:48:09 CEST] <crst> and vlc is quite bad on osx
[22:48:18 CEST] <furq> vlc is quite bad everywhere
[22:49:05 CEST] <crst> furq: Ah, didn't know that, what are you using, mpv?
[22:50:33 CEST] <furq> i'm using mpc-hc for now
[22:50:42 CEST] <furq> i'll probably switch to mpv whenever i finally get rid of windows
[22:50:49 CEST] <JEEB> mpv works nicely on windows as well
[22:50:54 CEST] <JEEB> which is quite nice :3
[22:51:02 CEST] <JEEB> WASAPI ao and opengl vo
[22:51:21 CEST] <furq> yeah, i've got it installed
[22:51:22 CEST] <JEEB> and if your GPU's opengl sucks then you can use ANGLE as the bridge between d3d and opengl
[22:51:27 CEST] <furq> it's useful for streaming, which mpc-hc is useless at
[22:52:29 CEST] <furq> i'm happy enough with mpc since the switch to lav filters though
[22:52:39 CEST] <crst> furq: you're switching to linux then?
[22:52:58 CEST] <furq> i've been "about to switch to linux" for about five years
[22:53:11 CEST] <furq> so probably, but who knows
[22:53:22 CEST] <Swappage> good evening everyone :)
[22:53:29 CEST] <crst> furq: lol, what's preventing you?
[22:53:33 CEST] <furq> inertia
[22:53:58 CEST] <Swappage> i need a little advice fro you ffmpeg gurus.. hope you can help me out
[22:54:04 CEST] <Regda> why is vlc bad everywhere ?
[22:54:16 CEST] <furq> maybe bad is overstating it but it's not particularly good
[22:54:25 CEST] <furq> there are better players on every platform
[22:54:25 CEST] <Swappage> i have a somewhat corrupted video (doesn't play in any player except a proprietary weirdo software) that has the followint caracteristics
[22:54:26 CEST] <furq> except maybe android
[22:54:42 CEST] <furq> unless mpv for android is release-quality now
[22:54:43 CEST] <crst> furq: what windows version are you on if I may ask?
[22:54:46 CEST] <furq> 7
[22:55:04 CEST] <Swappage> Stream #0:0: Video: h264 (Baseline), yuv420p, 704x288, 25 fps, 25 tbr, 1200k tbn, 50 tbc
[22:55:10 CEST] <Regda> uhm i dont understand, what points are bad in vlc ?
[22:55:25 CEST] <Swappage> if i reencode it i can somewhat fix it but for some reasons it "runs faster"
[22:55:42 CEST] <Swappage> infact the original video is 4:30m long while the resulting output is 3:47...
[22:55:43 CEST] <Regda> e.g. vlc is better then wmp because vlc plays more formats
[22:56:00 CEST] <crst> furq: 7, yeah, pretty solid.
[22:56:06 CEST] <Swappage> is there a way to transcode the video by keeping the original parameters in terms of fps tbc and tbn? tbr?
[22:56:22 CEST] <pZombie> i have to admit, it's almost impossible to spot the differences between the two versions, one encoded in 444 and the other 420
[22:56:42 CEST] <pZombie> but that might be due to the source material already having been 422
[22:56:59 CEST] <furq> if you downscaled it then that should make no difference
[22:57:43 CEST] <furq> but yeah you'll only notice the difference on sharp chroma boundaries with no contrast difference
[22:57:47 CEST] <pZombie> well, i believe to see the 444 version having slightly more vivid colors
[22:58:00 CEST] <furq> which isn't something that happens very often with most footage
[22:58:05 CEST] <pZombie> actually i don't think it's just a believe, but reality
[22:58:09 CEST] <furq> obviously it happens a lot with text
[22:58:10 CEST] <pZombie> i ll make a screenshot
[22:58:49 CEST] <crst> pZombie: anything I run in vlc, stutters or has the most annoying buffering artifacts. mpv plays nicely, but it's more of a pain to launch it since i only have cli right now.
[22:58:55 CEST] <furq> pZombie: out of interest, what was the difference in filesize
[22:59:34 CEST] <furq> raw 4:4:4 is twice the size of 4:2:0, but i expect it's much less of a difference after encoding
[22:59:56 CEST] <furq> Swappage: pastebin your command line and full output
[23:00:52 CEST] <pZombie> furq - the puzzling part is that the 444 version came out shorter in size
[23:01:00 CEST] <Swappage> furq: ok one sec
[23:01:14 CEST] <pZombie> http://i.imgur.com/OHMLuAO.jpg    look at this and tell me if you see what i believe to be seeing
[23:01:23 CEST] <pZombie> the 444 version looks better
[23:01:47 CEST] <pZombie> to be fair, maybe i should have added the original version as well
[23:01:55 CEST] <crst> pZombie: also on osx you often just want to use quicklook to peak inside the vid, and therefore system compatibilty is a must.
[23:02:52 CEST] <pZombie> that's not good. I should have made a blind test
[23:02:58 CEST] <pZombie> without telling you which one is which
[23:03:05 CEST] <furq> they look almost identical to me anyway
[23:03:13 CEST] <furq> but my screen isn't the best
[23:04:23 CEST] <furq> oh hang on, that's a jpeg
[23:04:29 CEST] <furq> jpeg uses 4:2:0 subsampling
[23:04:30 CEST] <pZombie> it is?
[23:04:36 CEST] <Swappage> here
[23:04:39 CEST] <zamba> what could be the reason for a/v sync issues?
[23:04:39 CEST] <Swappage> http://pastebin.com/X5XVcMFS
[23:04:42 CEST] <pZombie> aw, i thought i used png
[23:04:46 CEST] <zamba> the source is DV..
[23:04:52 CEST] <furq> imgur will convert png to jpg if it's above a certain size
[23:04:57 CEST] <Swappage> furq: thanks for youe help :)
[23:04:59 CEST] <furq> i think 4MB
[23:05:32 CEST] <pZombie> i definitely uploaded png, imgur screwed me
[23:06:02 CEST] <crst> with h420 there's a little overhead unfortunately. In my first encode between furq and pZombie 185MB vs. 171.3MB.
[23:06:05 CEST] <pZombie> it's only 1.47mb
[23:06:09 CEST] <pZombie> hm, let me try again
[23:07:01 CEST] <pZombie> nope, my upload is 1.47mb, yet it converts it to jpeg
[23:07:08 CEST] <pZombie> what is going on?
[23:07:21 CEST] <furq> Swappage: i doubt this is the issue, but is there some reason you're using baseline and level 1
[23:07:31 CEST] <furq> if nothing else that's causing a bunch of those warnings
[23:07:57 CEST] <Swappage> furq: no not really.. i just found it on the interweb lurking for transcoding tutorials
[23:08:02 CEST] <furq> yeah get rid of those
[23:08:42 CEST] <Swappage> so you suggest to remove the -provile:v baseline -level 1 ?
[23:08:44 CEST] <furq> yeah
[23:08:49 CEST] <pZombie> furq - it's 5mb for pro version of imgur and 1mb for normal, at least if i can trust a 4 years old reply i just found
[23:08:49 CEST] <furq> get rid of -r 25 as well
[23:08:57 CEST] <furq> it should autodetect from the source
[23:09:13 CEST] <Swappage> i need the scale tho
[23:09:17 CEST] <furq> you probably also want to upgrade to a newer ffmpeg as well, 2.2.2 is pretty old
[23:09:20 CEST] <Swappage> because the video is broken and i need to rescale it
[23:09:27 CEST] <furq> scale?
[23:09:29 CEST] <Swappage> furq: mhh
[23:09:49 CEST] <Swappage> -vf scale=704:528
[23:09:58 CEST] <furq> that's not in the command you pasted
[23:10:02 CEST] <Swappage> i still get the warnings
[23:10:32 CEST] <Swappage> and the video is still faster then the original
[23:10:43 CEST] <furq> i don't think there's much you can do about the slice type errors, those are caused by a corrupt file afaik
[23:11:20 CEST] <Swappage> mh, as long as the video plays it's fine, i was wondering if it was possible to make it run at the same speed as the original
[23:12:46 CEST] <Swappage> because the original is 25 fps, 25 tbr, 1200k tbn, 50 tbc while the output is 12800 tbn, 25 tbc
[23:12:56 CEST] <Swappage> i wonder if this can affect the difference between the 2 videos
[23:14:08 CEST] <Swappage> but at the same time i don't know if it's possible to manually specify these values in ffmpeg.. i searched around and doesn't look like so
[23:15:31 CEST] <furq> -x264opts timebase
[23:15:34 CEST] <furq> i doubt that'll fix it though
[23:17:26 CEST] <Swappage> mh -x264opts timebase is there a -h to see what values it accepts?
[23:17:32 CEST] <Swappage> also downloaded latest version of ffmpeg
[23:17:35 CEST] <Swappage> trying with that now
[23:18:01 CEST] <furq> x264 --fullhelp
[23:20:57 CEST] <JEEB> I recommend -x264-params instead of -x264opts
[23:21:11 CEST] <JEEB> -x264opts supports some specific things while -x264-params passes everything to libx264 as-is
[23:21:37 CEST] <JEEB> unless -x264opts at some point became a synonym, but IIRC the last I looked they still used different code paths
[23:22:41 CEST] <crst> I was playing around with the hqdn3d, but didn't get much of a filesize improvent anymore than with the default settings. If someone has experience I'd be happy to test some good values for 540p => hqdn3d=4:4:3:3
[23:24:39 CEST] <Swappage> furq: i don't have that command line on my system...
[23:29:30 CEST] Action: crst wishes h265 would be working...
[23:31:47 CEST] <pZombie> doesn't it work ?
[23:32:57 CEST] <crst> pZombie: not in browsers...
[23:33:12 CEST] <pZombie> oh, the browsers once again
[23:34:18 CEST] <crst> http://stackoverflow.com/questions/36382568/h-265-hevc-web-browser-support
[23:38:45 CEST] <pZombie> i found an article which claims that encoding with a single cpu is better
[23:38:48 CEST] <pZombie> for compression
[23:39:12 CEST] <pZombie> https://ericolon.wordpress.com/2013/01/06/the-secrets-of-yify-and-high-quality-and-small-file-sizes-are-not-so-secret-after-all-encoding-high-quality-low-bitrate-videos-in-handbrake-for-any-device/
[23:39:17 CEST] <Swappage> furq: you think it's because the video is corrupted that it runs faster? might be skipping frames?
[23:40:03 CEST] <furq> could be
[23:41:55 CEST] <Swappage> here is what i get when i do a mediainfo on the h264 source
[23:43:01 CEST] <furq> crst: if it's low-light footage on a digital camera, you probably want to bump up the chroma spatial denoise
[23:43:05 CEST] <Swappage> http://pastebin.com/EHcL3kPp
[23:43:07 CEST] <furq> which is the second argument iirc
[23:45:21 CEST] <crst> pZombie: are you able to run a test with a single core over the 4k footage? That'd be interesting.
[23:45:47 CEST] <crst> furq: cool, I'll check that out, thanks.
[23:45:52 CEST] <pZombie> already on it
[23:46:04 CEST] <crst> pZombie: yeah!
[23:46:25 CEST] <pZombie> this page i linked seems to have some good info
[23:46:46 CEST] <pZombie> just not sure if handbrake is available to you or if you can translate it to command line
[23:46:54 CEST] <Bray90820> Illya: You around?
[23:46:55 CEST] <crst> yeah pretty interesting stuff
[23:47:22 CEST] <crst> I've got hb
[23:50:38 CEST] <pZombie> oh yes, it ended up smaller... 16,805,888 bytes vs 16,850,944 bytes
[23:51:05 CEST] <pZombie> you save about 45 kb
[23:52:02 CEST] <crst> pZombie: lol!
[23:52:22 CEST] <crst> thanks for checking that out
[23:52:43 CEST] <pZombie> hey it's something! 45 here, 45 there ... it adds upo
[23:53:26 CEST] <crst> yeah, how was encoding time?
[23:54:16 CEST] <pZombie> horrible
[23:54:37 CEST] <pZombie> this is a 5960x overclocked. Not exactly the cpu to use with a single thread only
[23:54:49 CEST] <pZombie> but i have to run the test again
[23:55:20 CEST] <pZombie> after setting to 16 threads it seems to have given me the same size, but i hit something which changed the output so not sure
[23:55:51 CEST] <pZombie> now i got a different size again after setting threads to 16
[23:56:28 CEST] <pZombie> 16,848,337 bytes ok, this is the new value with 16 threads
[23:56:34 CEST] <pZombie> now back to 1 thread with same settings
[23:57:35 CEST] <pZombie> but you can always encode 16 videos in parallel i guess
[23:57:35 CEST] <crst> nice cpu you got there
[23:57:39 CEST] <pZombie> each with 1 thread
[23:58:23 CEST] <pZombie> not sure it was a good choice. I think i would have been better off with a 6700k but they weren't out when i got this
[23:58:42 CEST] <pZombie> it's rare i really make use of all cores
[23:59:23 CEST] <crst> 3500 MHz 1 core turbo
[23:59:45 CEST] <furq> quite a lot of this article is wrong
[00:00:00 CEST] --- Mon Jun 20 2016