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

[burek]

[01:00:21 CEST] <kinkinkijkin> is there a cpu-based encoder of h265?
[01:00:31 CEST] <furq> x265
[01:00:34 CEST] <kinkinkijkin> thanks
[01:00:43 CEST] <furq> and libkvazaar but nobody uses that
[01:01:01 CEST] <kinkinkijkin> and h265 will crunch files a lot smaller, right?
[01:01:04 CEST] <mixfix41> hi i cut a clip of mine https://superuser.com/questions/138331/using-ffmpeg-to-cut-up-video but after cutting twice to have 3 clips total the 2nd clip is missing the moov atom : moov atom not found, is there a way to cut the clip and keep the moov file present in the consequetive outputs
[01:02:48 CEST] <furq> mixfix41: that should work, although you can do it all in one command using the segment muxer
[01:03:11 CEST] <furq> kinkinkijkin: in theory, sure
[01:03:20 CEST] <furq> not so much in practice
[01:04:52 CEST] <kinkinkijkin> if I have two encodes with a target bitrate of 700kbps, one h264 and one h265, which is likely to look better given settings maximized for quality with no importance on encode time?
[01:05:51 CEST] <furq> x265
[01:06:08 CEST] <kinkinkijkin> okay, thank you
[01:06:19 CEST] <furq> it'll take ~10x longer than x264 veryslow
[01:06:21 CEST] <furq> maybe even more
[01:06:48 CEST] <furq> a lot of people think it's a magic bullet and they can use x265 with default settings and it'll be 50% smaller than x264
[01:07:05 CEST] <furq> you only really see gains when you use excruciatingly slow x265 settings
[01:07:15 CEST] <furq> you can get pretty good gains though
[01:07:52 CEST] <kinkinkijkin> darn, if only I had access to hardware h265 on this setup
[01:09:48 CEST] <furq> hardware h265 is generally worse than x264
[01:10:03 CEST] <kinkinkijkin> ah...
[01:10:17 CEST] <furq> nvenc hevc is scarcely better than hvenc h264
[01:10:35 CEST] <furq> it's just an hevc bitstream because then they can write "HEVC" on their gpu box
[01:11:31 CEST] <kinkinkijkin> is there a bundled setting with x265 to get these excruciating encode times? like -preset veryslow or something like that
[01:11:35 CEST] <furq> presumably next to the picture of a 3d wizard riding a motorcycle and doing an endo on a giant vram chip
[01:11:54 CEST] <furq> and yeah x265's interface is modelled on x264's
[01:12:02 CEST] <furq> so you can just use -preset veryslow and -crf
[01:12:14 CEST] <furq> the crf values aren't the same as x264, but it's the same idea
[01:12:44 CEST] <furq> it's worth pointing out that in spite of the name and interface, they're completely different developers
[01:13:04 CEST] <furq> i think the community has a rather higher opinion of x264's developers
[01:26:57 CEST] <mixfix41> yeah it looks i can clip those output files from seg muxer thanks furq
[02:21:35 CEST] <kinkinkijkin> ah, I love it when my reencode is going at 0.12x speed
[02:21:44 CEST] <kinkinkijkin> and has been for the past 45 minutes
[02:21:51 CEST] <furq> welcome to x265
[02:22:26 CEST] <kinkinkijkin> I decided to test-reencode an episode of an anime (which was already encoded extremely well)
[02:22:34 CEST] <kinkinkijkin> instead of one of my 3-minute rally stage videos
[02:23:16 CEST] <furq> https://www.youtube.com/watch?v=3Kt7sq7F3C8
[02:23:19 CEST] <furq> is this your channel
[02:23:51 CEST] <kinkinkijkin> lol I wish
[02:24:01 CEST] <kinkinkijkin> I like how it starts out with tarmac rally
[02:24:09 CEST] <kinkinkijkin> tarmac doesn't get enough love from rally spectators
[02:25:30 CEST] <kinkinkijkin> oh my
[02:25:33 CEST] <kinkinkijkin> is this all tarmac
[02:26:58 CEST] <kinkinkijkin> oh some light gravel
[02:27:23 CEST] <geri> hi i try to concatinate some mp4 files but run into the following issue: http://ideone.com/O0JEga
[02:27:25 CEST] <geri> any idea?
[02:29:28 CEST] <kinkinkijkin> heh furq, that video even has harri rovanpera
[02:29:46 CEST] <furq> geri: the concat file should look like "file 'soccer1.mp4'" etc
[02:29:55 CEST] <geri> they are from iphone 6 and original in mov format
[02:29:55 CEST] <kinkinkijkin> the son of which is currently the WRC-2 favourite, at only 16
[02:30:16 CEST] <furq> i noticed carlos sainz in there, who also has a famous son
[02:31:02 CEST] <kinkinkijkin> and richard burns, the rally game of whom is still the current rally league standard
[02:31:20 CEST] <kinkinkijkin> even though it's 15 years old
[02:32:03 CEST] <furq> i've only really played the mcrae ones
[02:32:14 CEST] <furq> and the ones in that series after they stopped using his name
[02:32:24 CEST] <furq> i still need to check out dirt rally actually
[02:32:28 CEST] <kinkinkijkin> they only stopped using his name because he died
[02:32:37 CEST] <furq> they used his name in one after he died iirc
[02:32:38 CEST] <kinkinkijkin> dirt rally is hard, as is richard burns rally
[02:32:44 CEST] <kinkinkijkin> and sebastien loeb rally, too
[02:32:54 CEST] <furq> yeah i was a big fan of dirt 3 but i was under no illusions about how realistic it was
[02:33:08 CEST] <furq> dirt 1 was pretty good as well
[02:33:21 CEST] <furq> before they pumped it full of ken block
[02:33:45 CEST] <kinkinkijkin> ken block and gymkhana were the worst things about dirt 3
[02:33:51 CEST] <furq> NICE DRIFT BRAH. CLICK THE YOUTUBE BUTTON TO UPLOAD IT TO YOUR FANS
[02:33:55 CEST] <furq> no thanks ken
[02:34:03 CEST] <furq> 2 was much worse for that stuff
[02:34:12 CEST] <kinkinkijkin> that wasn't ken block lol, that's another guy
[02:34:17 CEST] <furq> pastrana?
[02:34:28 CEST] <kinkinkijkin> I meant that line
[02:34:33 CEST] <furq> oh right yeah
[02:34:47 CEST] <kinkinkijkin> that line is your "team engineer", the name of whom is only in the game credits
[02:35:06 CEST] <furq> the important thing is that you could still have a scottish co-driver in 3
[02:35:18 CEST] <furq> that's the most critical aspect of any rally game
[02:35:26 CEST] <drv> dirt rally is good stuff, especially in VR
[02:35:38 CEST] <furq> yeah i've been meaning to check it out
[02:35:40 CEST] <furq> along with grid autosport
[02:35:50 CEST] <kinkinkijkin> dirt rally has some unrealisms in its physics though, like the gravity is set wrong and there is no aero simulation
[02:36:04 CEST] <kinkinkijkin> it's all suspension, tires, ground, and gravity
[02:36:06 CEST] <furq> i'm not a hardcore enough sim racer to really care
[02:36:09 CEST] <furq> i don't have a wheel or anything
[02:36:17 CEST] <kinkinkijkin> the gravity is an annoying thing
[02:36:21 CEST] <kinkinkijkin> because it's way too weak
[02:36:26 CEST] <kinkinkijkin> even for fun purposes
[02:36:33 CEST] <furq> i did like how often they mentioned pike's peak in dirt 3
[02:36:41 CEST] <furq> they gave you all the pike's peak special edition cars
[02:36:45 CEST] <furq> but then they didn't let you race on pike's peak
[02:36:54 CEST] <kinkinkijkin> dirt rally has pikes peak
[02:37:03 CEST] <kinkinkijkin> in fact, pikes peak is the only hillclimb in dirt rally
[02:37:05 CEST] <kinkinkijkin> somewhat annoyingly
[02:37:07 CEST] <furq> i assume because you'd have probably found it suspicious that you'd have been able to break the record by two and a half minutes
[02:37:34 CEST] <kinkinkijkin> heh
[02:37:59 CEST] <furq> in the original grid i could do 2:30 laps around le mans, which is about 50 seconds faster than the actual car you were meant to be driving
[02:38:06 CEST] <furq> and i wasn't particularly good
[02:38:26 CEST] <geri> furq: works now, but the video is rotate by 90 degrees, any idea?
[02:38:32 CEST] <geri> i mean the final one
[02:38:41 CEST] <kinkinkijkin> add rotation metadata
[02:38:49 CEST] <kinkinkijkin> it probably had that before and it ended up being stripped
[02:39:03 CEST] <furq> if only one of them is rotated then you're probably going to have to reencode it
[02:39:07 CEST] <geri> oh
[02:39:22 CEST] <geri> ad the end of video 1 the phone is flipped
[02:39:39 CEST] <furq> yeah you'll need to reencode one of the videos
[02:39:48 CEST] <furq> the rotation metadata can't change mid-stream
[02:40:25 CEST] <furq> !filter transpose
[02:40:25 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#transpose
[02:40:35 CEST] <furq> reencode it with that and then concat it to the ones that are the right way up
[02:40:51 CEST] <furq> you'll need to make sure you use the same settings though
[02:41:04 CEST] <furq> it might be less hassle to just reencode the whole thing
[02:42:29 CEST] <furq> actually nvm you can't do a 180 flip with transpose
[02:42:32 CEST] <furq> !filter vflip
[02:42:32 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#vflip
[02:42:52 CEST] <furq> !filter rotate
[02:42:52 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#rotate
[02:42:54 CEST] <furq> one of those two will do it
[02:43:04 CEST] <furq> or hflip and then vflip
[02:44:08 CEST] <kinkinkijkin> hour and 5 minutes, reflow and reencode is half done
[02:47:53 CEST] <geri> For values between 4-7, the transposition is only done if the input video geometry is portrait and not landscape. These values are deprecated, the passthrough option should be used instead.
[02:47:54 CEST] <geri> hu?
[02:52:56 CEST] <kinkinkijkin> oh wait a second, I thought the video I'm reencoding was a really big h264, turns out it's rawvideo
[02:53:02 CEST] <kinkinkijkin> lol no wonder it's so hugeà
[02:58:37 CEST] <geri> what video format is good for a phone?
[02:59:09 CEST] <DHE> typically mp4 with H264 Main profile video
[03:01:53 CEST] <geri> how to check the codec i currently use?
[03:01:58 CEST] <geri> i have a mp4 video
[03:02:43 CEST] <DHE> ffprobe can tell you, but the profile I'm not sure about
[03:03:54 CEST] <geri> http://ideone.com/o8ujBh
[03:04:32 CEST] <geri> can i concatinate those 2 videos: intro.mp4 and final.mp4 ?
[05:02:47 CEST] <kinkinkijkin> https://www.youtube.com/watch?v=PVeIBtUwpJI 30-minute reencode from mpeg2
[05:09:40 CEST] <furq> does youtube accept hevc now
[05:10:33 CEST] <kinkinkijkin> yep
[05:10:44 CEST] <kinkinkijkin> probably still reencodes it, like it does with everything
[05:10:56 CEST] <kinkinkijkin> but it didn't lose a noticeable amount of quality
[05:11:24 CEST] <furq> well yeah it reencodes everything
[05:11:26 CEST] <kinkinkijkin> the source was already blurry, because the game being recorded is slightly blurry in my current setup
[05:11:29 CEST] <furq> but until recently you couldn't upload hevc
[05:11:34 CEST] <kinkinkijkin> so nothing is easy to notice
[05:20:23 CEST] <kinkinkijkin> furq to be honest I'm really impressed with the quality of mvtools when applied to something other than anime
[05:20:42 CEST] <kinkinkijkin> no noticeable artifacts, except some missed motion
[05:28:07 CEST] <james999> what are the problems with anime again? bad interlacing?
[05:28:52 CEST] <furq> it's bad
[05:30:11 CEST] <kinkinkijkin> when interpolating framerates, any source with lots of flat colours and large amounts of motion will have tons of artifacts
[05:30:35 CEST] <kinkinkijkin> the higher the contrast, the more visible they will be
[05:33:24 CEST] <james999> interpolating framerates? like 3:2 or converting NTSC to PAL?
[05:33:44 CEST] <kinkinkijkin> like adding new frames from motion data
[05:33:56 CEST] <kinkinkijkin> specifically from motion data is there an issue
[05:34:02 CEST] <kinkinkijkin> with artifacts, anyways
[05:34:47 CEST] <kinkinkijkin> I'm trying to work on a way of either removing the artifacts or making them far less likely of happening
[05:35:39 CEST] <kinkinkijkin> the former would require knowing how to compare frames, which I don't
[05:57:47 CEST] <thebombzen> oh man YouTube can do HEVC now?
[05:57:49 CEST] <thebombzen> about time
[06:02:52 CEST] <james999> there's probably a subtle reason why you refer to it as hevc instead of h265
[06:03:31 CEST] <james999> well that was an awkward say of asking that lol
[06:04:05 CEST] <kinkinkijkin> hevc is easier and quicker to type
[06:04:17 CEST] <kinkinkijkin> also h265 is really similar to h264
[06:04:26 CEST] <james999> yes that's what I thought of immediately after I typed it
[06:04:28 CEST] <TD-Linux> this windows CVE
[06:04:29 CEST] <TD-Linux> I'm dead
[06:04:36 CEST] <TD-Linux> also wrong channel
[06:55:09 CEST] <thebombzen> james999: because its' more common to call it HEVC than H.265
[06:55:25 CEST] <thebombzen> in the same way that H.264 can also be called AVC but nobody does, it's more common to use H.264
[09:22:47 CEST] <james999> ah ok
[10:32:04 CEST] <gr8> I have a bunch of 1080p movies that I want to convert to a lower resolution because my old computer is not able to play it. The thing is, it is converting videos very slowly obviously, so I am looking for the most efficient method to resize the video to either 720p or 540p!? Usually I am just using -c:a copy -vf scale=960:-1, but is there a better way?
[10:34:52 CEST] <furq> if you're using x264 then you probably want to use -preset superfast or something
[10:39:33 CEST] <gr8> furq: well actually I would prefer if it wouldn't do any resampling, but mechanically divide the resolution by 2, e.g. merge each 4 pixels into one...
[10:39:48 CEST] <gr8> don't know if that behavior can be enforced?
[10:40:38 CEST] <gr8> the codec is h264
[12:17:55 CEST] <crst> Hi, why do I get: Unable to find a suitable output format for 'libopus'   for:   find . -name "*.mp3" -print0 | xargs -0 -P8 -n1 -I {} ffmpeg -i {} -acodec libopus {}.opus
[12:22:20 CEST] <furq> crst: -i "{}"
[12:22:26 CEST] <furq> and quote the output filename as well
[12:24:28 CEST] <crst> furq: mhmm, I tried different combos of quoting but I still get the same error
[12:28:32 CEST] <crst> I asked at #bash before I came here, and they told me it's not a bash question
[12:42:21 CEST] <termos> my ffmpeg created flv stream plays well in ffplay but not in any of the flv flash players that I've tried. Could it be some metadata missing?
[12:42:52 CEST] <termos> the flash players are playing other rtmp flv streams well, but not the one I'm generating
[12:43:58 CEST] <furq> what codecs
[12:44:37 CEST] <termos> h264 and aac, libx264 and fdk_aac specifically
[12:44:57 CEST] <furq> weird
[12:45:30 CEST] <furq> i've not used ffmpeg's rtmp as anything other than ingest for nginx-rtmp for ages, but that works fine
[12:45:37 CEST] <furq> and i don't remember having issues back when flash was still a thing
[12:45:50 CEST] <furq> or needing to do anything out of the ordinary
[12:48:42 CEST] <termos> indeed weird, i have another encoder based on libffmpeg that's working fine so i'm sure i have missed something
[16:29:02 CEST] <termos> hm, while printing out my AVCodecContext->time_base while decoding (no errors) it just says 0/2. What is the actual time_base used here? For audio it's 1/44100 which looks correct since it's 1/sample_rate
[16:29:37 CEST] <termos> expecting the decoder to set it to something like 1/(framerate*n)
[16:38:30 CEST] <Mavrik> Check your AVStream timebase
[16:38:37 CEST] <Mavrik> That might be more accurate depending on format
[16:45:57 CEST] <termos> that one seems to be correct, well it's 1/1000 at least
[16:46:39 CEST] <termos> so i'm doing av_packet_rescale_ts from AVStream.time_base into codec time_base, so scaling 1/1000 -> 1/44100 for audio but 1/1000 -> 0/2 for video
[16:46:56 CEST] <termos> is it wrong to want to rescale here?
[16:49:20 CEST] <kepstin> why do you want to rescale there? The important thing is to have the frame pts match the timebase you're using, and that should be happening by default if you just use the stream timebase, I think?
[16:53:55 CEST] <termos> it doesn't play without rescaling, i'm following the example here: https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/transcoding.c#L547-L549
[16:54:31 CEST] <termos> i'm not using avcodec_decode_video2 but rather the newer avcodec_send_packet
[17:12:15 CEST] <draean> I'm using ffmpeg to transcode files to h264. I've noticed that an older version (x264 core 120 r2151 a3f4407) seems to transcode the same file about 6x faster than a newer version (x264 core 148 r3 4fc4a2b). If I look at the encoding settings, they appear identical with the exception that the newer ffmpeg includes 'lookahead_threads=1' I'm wondering why this drastic speed reduction in the later version?
[17:16:14 CEST] <DHE> holy crap that's old. build 120 is probably around 2011, maybe early 2012
[17:17:41 CEST] <draean> yeah, that sounds about right >_< stuff was working! so I didn't change anything, then I wanted new goodies in the later version, so i upgraded, but now my transcodes have become so much slower, it's bummin' me out =p
[17:18:06 CEST] <kepstin> draean: If you want to reduce the quality of the new version so that it's as fast as the older one, just use a slower preset? :)
[17:18:09 CEST] <DHE> you can speed it up by adding -preset fast  (or faster, or veryfast, or superfast) at the cost of image quality or file size epdending on your settings
[17:18:13 CEST] <kepstin> er, faster preset*
[17:18:40 CEST] <DHE> but over ~5 years no idea what's changed specifically. unless you feel like bisecting...
[17:18:51 CEST] <furq> 6x sounds suspect
[17:18:52 CEST] <draean> ahha. so I tried adding -preset veryfast to both the new and the old. it seemed to increase the speed of either by a similar factor
[17:19:01 CEST] <furq> does your new build have some optimisations disabled or something
[17:19:19 CEST] <DHE> that would explain a lot. perhaps missing nasm or something?
[17:19:46 CEST] <draean> oh, you ask good questions. lemme see
[17:19:48 CEST] <kepstin> huh, I thought current x264 required yasm, didn't work with nasm?
[17:19:55 CEST] <DHE> yeah my mistake
[17:20:02 CEST] <kepstin> either way, the configure output should tell you if it can't build the assembly code
[17:20:03 CEST] <DHE> you'd know if you didn't because you'd have to compile with --disable-asm
[17:20:16 CEST] <furq> x264 --version should show the config options
[17:20:49 CEST] <furq> assuming it's the same build you linked ffmpeg with
[17:21:40 CEST] <draean> root at b100-hypercaster:/media/psg/vol1/preload# x264 --version
[17:21:40 CEST] <draean> x264 0.148.3 4fc4a2b
[17:21:41 CEST] <draean> built on Oct 26 2015, gcc: 4.6.3
[17:21:42 CEST] <draean> x264 configuration: --bit-depth=8 --chroma-format=all
[17:21:44 CEST] <draean> libx264 configuration: --bit-depth=8 --chroma-format=all
[17:21:46 CEST] <draean> x264 license: GPL version 2 or later
[17:22:24 CEST] <furq> [libx264 @ 000000000060f500] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
[17:22:30 CEST] <furq> you should get a message like that from ffmpeg
[17:22:41 CEST] <furq> make sure that looks correct, that it's actually using 100% cpu etc
[17:24:46 CEST] <draean> [libx264 @ 0x374bf00] using SAR=1/1
[17:24:46 CEST] <draean> [libx264 @ 0x374bf00] using cpu capabilities: none!
[17:24:46 CEST] <draean> [libx264 @ 0x374bf00] profile High, level 3.1
[17:24:51 CEST] <draean> D:
[17:24:58 CEST] <furq> that's probably not goodf
[17:25:46 CEST] <draean> [libx264 @ 0x1152340] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[17:25:50 CEST] <draean> that's from the older version
[17:26:11 CEST] <furq> did you build the new version yourself
[17:26:22 CEST] <furq> i'm not sure whether it'll automatically build without asm if you don't have yasm installed
[17:26:30 CEST] <furq> if it does then that's probably to blame
[17:27:19 CEST] <draean> I did build it myself. so you're saying I probably don't have asm built into it, and I need it
[17:27:23 CEST] <furq> yeah
[17:27:42 CEST] <furq> install yasm and rebuild
[17:27:54 CEST] <furq> or just grab a static build of ffmpeg
[17:28:08 CEST] <furq> https://www.johnvansickle.com/ffmpeg/
[17:28:42 CEST] <draean> excellent. thanks a lot. I think I'm stuck with building it myself, we have some weirdo patch in some place I'm not that familiar with to try and more closely approximate CBR
[17:29:53 CEST] <furq> that might not be needed any more
[17:30:29 CEST] <furq> you can use -x264-params nal-hrd=cbr
[17:30:35 CEST] <furq> that's cbr enough for bluray compatibility
[19:23:08 CEST] <holst1> I'm looking at the man page http://www.linuxhowtos.org/manpages/1/ffmpeg-devices.htm and I cannot understand how I can pass the "window_id" flag to `-f xv`?
[19:27:12 CEST] <c_14> the official manpages are here https://ffmpeg.org/ffmpeg-devices.html, and just put -window_id <foo> before -f xv
[19:27:22 CEST] <kepstin> holst1: those flags just turn into command line options when used with the ffmpeg cli, so you have "-window_id 1234 -f xv"
[19:29:36 CEST] <holst1> ah thanks!
[19:39:03 CEST] <kbarry> I'm wanting to know if a file is VBR or CBR. Google is failing me in searching for how I might do this with ffprobe.
[19:39:34 CEST] <kbarry> Also, i'm only working with Audio (mp3) files.
[19:39:56 CEST] <furq> use mediainfo
[19:42:19 CEST] <kbarry> Thanks,
[19:42:35 CEST] <kbarry> Is it safe to assume there is no strait-forward method for this in ffprobe?
[19:45:42 CEST] <furq> not that i know of
[19:46:17 CEST] <furq> the most obvious way would be bit_rate != max_bit_rate
[19:46:26 CEST] <furq> but that doesn't work for the first vbr mp3 i tried it with
[19:48:46 CEST] <DHE> ffprobe doesn't scan the whole file and is usually happy once it's convinced it has all the codec parameters. unless you use options to force the issue like -show_frames
[19:49:29 CEST] <furq> i just get max_bit_rate=N/A
[19:49:37 CEST] <furq> even with -analyzeduration 100M -count_frames
[19:51:55 CEST] <furq> mediainfo generally seems more robust even if the interface is somehow even more arcane than ffprobe's
[19:59:46 CEST] <furq> http://vpaste.net/ExMGg
[19:59:48 CEST] <furq> this also works
[20:04:44 CEST] <pgorley> hi, is there an example on how to implement the mediacodec hwaccel somewhere? or is it along the same lines as vaapi and vdpau?
[20:19:44 CEST] <draean> Alright, Im still having trouble getting cpudetect to work. I have yasm installed:
[20:19:44 CEST] <draean> root at aio-b2000-12:~/ffmpeg-3.2.4# apt-cache policy yasm
[20:19:44 CEST] <draean> yasm:
[20:19:46 CEST] <draean>   Installed: 1.1.0-1
[20:19:48 CEST] <draean>   Candidate: 1.1.0-1
[20:19:50 CEST] <draean>   Version table:
[20:19:52 CEST] <draean>  *** 1.1.0-1 0
[20:19:54 CEST] <draean>         500 file:/var/www/apt_repo/master/  Packages
[20:19:56 CEST] <draean>         100 /var/lib/dpkg/status
[20:19:58 CEST] <draean> and Im installing with
[20:20:00 CEST] <draean> ./configure --arch=amd64 --extra-libs=-ldl --enable-gpl --enable-libx264 --enable-libmp3lame --enable-postproc --enable-libvorbis --enable-libtheora --enable-libvpx
[20:20:02 CEST] <draean> is this a path issue or something? I feel it must be some nub thing Im doing :/
[20:49:24 CEST] <kepstin> draean: you need to rebuild x264, not ffmpeg
[20:50:11 CEST] <kepstin> (well, if you're using static libs, you need to do both, but x264 first, for sure!)
[20:51:50 CEST] <draean> ahha, thanks
[21:24:16 CEST] <metaphysician> How do I use Quick Sync Video encoding on Ubuntu?
[21:25:59 CEST] <metaphysician> Do I only need libmfx or the entire Intel Media SDK?
[21:29:16 CEST] <BtbN> Just use libva instead
[21:31:13 CEST] <metaphysician> BtbN: For h264 encoding that would be h264_vaapi?
[21:35:19 CEST] <BtbN> metaphysician, yes, doesn't need any insane patches applied to the system
[21:48:20 CEST] <metaphysician> OK, it seems to be working with -vaapi_device /dev/dri/renderD128 -vf 'format=nv12,hwupload' -c:v h264_vaapi , but I cannot use the scale filter with this for resizing.
[21:49:14 CEST] <BtbN> just use it before uploading
[21:49:41 CEST] <BtbN> or use scale_vaapi to also hw accelerate the scaling
[22:09:07 CEST] <metaphysician> Cool, but how do you control the quality/bitrate?  -crf option doesn't work.
[22:11:32 CEST] <metaphysician> Looking at vaapi_encode_h264.c, it seems to have a quality 0-8 option.
[22:12:57 CEST] <BtbN> that's pretty much it I think, no idea, don't have a machine that supports it
[22:13:09 CEST] <kepstin> metaphysician: i think it only supports single-pass vbr, so set a bitrate.
[22:13:36 CEST] <kepstin> metaphysician: if you want high quality, you should be using x264 rather than a hardware encoder, of course.
[22:23:51 CEST] <vidj> i got a question regarding obs&ffmpeg. basically i'm using ffmpeg to record and i'm wondering if nvenc_hevc (libx265) uses gpu or cpu to encode?
[22:24:07 CEST] <vidj> and if it's even possible for x265 to use gpu encoding
[22:33:43 CEST] <vidj> what encoder would i use for hardware encoding with hevc?
[22:37:52 CEST] <ChocolateArmpits> vidj, try hevc_qsv seems the only one atm
[22:38:36 CEST] <ChocolateArmpits> Of course you have to have a supported cpu and the ffmpeg must be compiled for quick sync support
[22:40:10 CEST] <metaphysician> Thanks BtbN, kepstin.
[22:41:04 CEST] <BtbN> vidj, uhm, "nvenc_hevc (libx265)". What?
[22:41:26 CEST] <kepstin> vidj: nvenc_hevc and libx265 are two separate encoders, the first uses gpu, the second uses cpu.
[22:42:23 CEST] <kepstin> (well, nvenc_hevc uses a hardware encoder block on the gpu die, not the main "gpu" processor itself, but that's being pedantic)
[22:47:55 CEST] <thebombzen> BtbN: wouldn't you want to put the scale filter before format, not before hwupload?
[22:48:12 CEST] <BtbN> doesn't really matter
[22:48:45 CEST] <thebombzen> afaik the way libavfilter works is -vf format simply requests a format from the previous filter
[22:49:25 CEST] <thebombzen> so scale,format will cause scale to do the colorspace conversion and the size conversion in one go
[22:50:09 CEST] <thebombzen> whereas format,scale will autoinsert a scale filter in front with a colorspace conversation, and then the scale you explicitly used will be after that
[22:50:49 CEST] <thebombzen> because if the previous filter (such as vf_buffer) can't provide the requested format it'll insert a scale filter
[22:51:03 CEST] <vidj> BtbN, kepstin i guess it's just poor naming in obs
[22:51:11 CEST] <vidj> ChocolateArmpits: ye will try hevc_qsv now
[22:51:22 CEST] <BtbN> libx265 is a software encoder.
[22:51:40 CEST] <vidj> ye but nvenc_hevc should be hardware
[22:51:53 CEST] <vidj> i've no idea why there's (libx265) appended to it
[22:52:06 CEST] <vidj> same goes for hevc_qsv, (libx265) also appended
[22:52:08 CEST] <vidj> makes no sense for me
[22:52:21 CEST] <BtbN> I guess someone tought libx265 is the codec name?
[22:52:26 CEST] <BtbN> But since when does obs even support hevc?
[22:53:52 CEST] <kepstin> well, we see people confused with x264/h264 all the time here. but *lib*x265? :/
[22:55:17 CEST] <vidj> BtbN: well i've grabbed latest ffmpeg libs and put it in obs bin/
[22:55:21 CEST] <vidj> so it supports it now :D
[22:55:25 CEST] <vidj> but just for recording
[22:56:05 CEST] <vidj> i mean, im using it just for recording, it's pointless to stream with 265 when twitch and all the other services i know don't support the codec
[22:56:37 CEST] <vidj> and obs errors out on hevc_qsv :|
[22:57:56 CEST] <vidj> 22:56:14.771: ffmpeg_data_init failed
[22:59:01 CEST] <vidj> BtbN: https://www.plusforward.net/post/25305/obs%2Bx265/ you can see here my recordings with h265
[00:00:00 CEST] --- Wed May 10 2017