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

[burek]

[01:49:09 CET] <xintox> .
[01:49:12 CET] <xintox> woops
[01:49:17 CET] <xintox> #h4kr
[02:10:48 CET] <JustinBieber> so to use rubberband filter I have to install librubberband ? is it separate library or it ships with ffmpeg ? I have ffmpeg-2.3 does it support rubberband ?
[02:11:17 CET] <c_14> The rubberband filter is relatively new.
[02:11:20 CET] <c_14> Probably only 2.8 up
[03:05:51 CET] <Pinchiukas> Anyone can help me with http://video.stackexchange.com/questions/17371/random-errors-from-ffprobe ?
[03:58:23 CET] <qxt> I need to encode video for some html5 sites I am working on. What format is the most supported by browsers? There is mp5, H.254 and webm. I
[03:59:13 CET] <qxt> mp4 sry* A few years back I used vp8 and vorbis for stuff. Not sure how things are now.
[04:00:30 CET] <qxt> I hear webm is not supported by Microsoft and Apple. Is this true? Have not used MS or Apple since about 1995
[04:03:49 CET] <qxt> mp4, h.264 and vp8 *this keyboard is way small*
[04:16:15 CET] <Kieran> Hello everyone!
[04:33:16 CET] <Uhkam> Hi, anyone able to give an assistance here?
[04:44:20 CET] <Soni> any youtubers which use ffmpeg for editing their videos?
[07:25:47 CET] <Logicgate> what should be the maximum size of a 7 second 720p video?
[07:26:45 CET] <c_14> 39MiB
[07:26:49 CET] <c_14> eh, ne
[07:26:54 CET] <Logicgate> roughly right?
[07:26:55 CET] <Logicgate> okay cool
[07:27:06 CET] <c_14> 462MiB
[07:27:29 CET] <c_14> That would be uncompressed
[07:27:59 CET] <Logicgate> I thought it was roughly 2megabits per second no?
[07:28:45 CET] <Logicgate> The H.264 standard defines maximum bit rates for 1280x720 at 30fps as between 14.000 and 42.000 kbit/s, depending on the profile (baseline, main, high etc.)?
[07:29:41 CET] <c_14> You never told me what video codec you were using so I used uncompressed video as that is the maximum upper limit.
[07:29:47 CET] <c_14> well
[07:29:51 CET] <c_14> reasonable upper limit
[07:31:22 CET] <Logicgate> what would be the reasonable upper file size limit?
[07:31:42 CET] <Logicgate> 720x720 @ 25fps using H.264 with 128kbps audio
[07:36:29 CET] <c_14> Depends on how high you push the bitrate
[07:36:51 CET] <c_14> Anything from 1MiB to 400MiB
[07:37:00 CET] <Logicgate> Lol jesus
[07:37:18 CET] <Logicgate> Would giving users 50mb be reasonable?
[07:37:37 CET] <c_14> probably
[07:38:05 CET] <c_14> most streaming is between 2 and 5 thousand kb so for a 7s video that should be around 14-35MiB
[07:38:14 CET] <c_14> eh
[07:38:16 CET] <c_14> MB
[07:40:05 CET] <Logicgate> Alright, thank you c_14
[07:52:48 CET] <jafa> are there docs or a recommended way to compile ffmpeg to work with qt5 on windows platform?
[07:53:49 CET] <jafa> I tried compiling under msys2 configuring ffmpeg for target-os=mingw32
[07:54:27 CET] <jafa> compiles fine but crashes in weird ways at runtime
[07:55:19 CET] <jafa> most commonly the app terminates and the qt debugger simply reports that the app terminated (no error)
[08:43:45 CET] <jafa> if I use Zeranoe FFmpeg pre-compiled builds it works fine
[08:51:42 CET] <jafa> ah, looks like they are cross-compiled from linux. will try
[11:02:57 CET] <vapashos> hello everyone i'd like to ask a question about how to create an avc bitstream from a .yuv file using ffmpeg
[12:34:57 CET] <relaxed> vapashos: look at ffmpeg -h demuxer=rawvideo , you have to tell the rawvideo demuxer how to handle the input
[13:04:37 CET] <thetrueavatar> Hello
[13:05:07 CET] <thetrueavatar> I need some help to encode in x265 with ffmeg and preset file. Can anybody help me please ?
[13:07:08 CET] <thetrueavatar> here is my cli command: ffmpeg  -i "Kyrielle montage tout OK.avi" -c:a copy -c:v libx265 -vpre veryslow "outFile.mkv"
[13:07:26 CET] <thetrueavatar> and it says File for preset 'veryslow' not found
[13:07:44 CET] <relaxed> change it to -preset veryslow
[13:07:47 CET] <thetrueavatar> I have tried with -preset but it doesn't seems to use it
[13:07:55 CET] <thetrueavatar> it only do quantizer 0 by default
[13:08:01 CET] <thetrueavatar> whatever the string is used
[13:08:04 CET] <relaxed> oh, it's x265
[13:08:34 CET] <relaxed> https://trac.ffmpeg.org/wiki/Encode/H.265
[13:08:52 CET] <thetrueavatar> indeed  I didn't try to encode directly with x265 cli. Will read your link
[13:09:07 CET] <relaxed> well, I meant libx265
[13:09:38 CET] <thetrueavatar> I'm working on linux so I have build all by myself
[13:09:39 CET] <relaxed> from the wiki it looks like -preset should work. Which ffmeg version are you using?
[13:09:46 CET] <thetrueavatar> 2.8.4
[13:10:06 CET] <thetrueavatar> I took the source code from the site
[13:10:10 CET] <thetrueavatar> here is my configuraitoin
[13:10:27 CET] <thetrueavatar>  --prefix=/home/clibois/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/clibois/ffmpeg_build/include --extra-ldflags=-L/home/clibois/ffmpeg_build/lib --bindir=/home/clibois/bin --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libvorbis --enable-libx264 --enable-libx265 --enable-nonfree
[13:11:24 CET] <thetrueavatar> I don't have any error but quantizer is set to 0(lossless)
[13:11:54 CET] <relaxed> try -x265-params preset=veryslow
[13:11:58 CET] <furq> thetrueavatar: -x265-params crf=28
[13:12:33 CET] <furq> i'm not sure why the default would be lossless though
[13:12:56 CET] <furq> afaik the default is -b:v 200k
[13:12:58 CET] <thetrueavatar> ah wait I see
[13:13:12 CET] <thetrueavatar> q=-0.0
[13:13:56 CET] <thetrueavatar> preset veryslow only set ration to 28 ?
[13:14:20 CET] <furq> preset shouldn't affect the crf at all
[13:14:43 CET] <furq> crf should (in theory) result in the same quality regardless of other settings
[13:16:02 CET] <JEEB> no
[13:16:07 CET] <JEEB> crf depends on preset
[13:16:31 CET] <JEEB> because crf depends on the internals that switch between presets
[13:16:33 CET] <thetrueavatar> maybe it just a display problem cause bitrate is rather slow for a quantizer 0.
[13:16:58 CET] <thetrueavatar> there is a - before the 0.0 of the q=-0.0
[13:18:13 CET] <thetrueavatar> however bitrate of 200kbits seems rather low for a 1080p resolution....
[13:19:04 CET] <furq> thetrueavatar: 200k is the default if you don't specify a bitrate/crf/etc
[13:19:18 CET] <furq> that doesn't mean it's a good default
[13:19:47 CET] <thetrueavatar> well it start à 50 and ramp up progressively. Now I'm a t 321kbits/s
[13:20:12 CET] <thetrueavatar> and I guess that's the role of the preset to define crf no ?
[13:22:55 CET] <furq> thetrueavatar: http://x265.readthedocs.org/en/default/presets.html
[13:24:47 CET] <thetrueavatar> According to your link don't see why I should set crf
[13:24:56 CET] <thetrueavatar> ". When you use slower presets, x265 tests more encoding options, using more computations to achieve the best quality at your selected bit rate (or in the case of crf rate control, the lowest bit rate at the selected quality)."
[13:25:11 CET] <thetrueavatar> ah
[13:25:46 CET] <thetrueavatar> that's a bit weird that x264 doens't need any crf defintion and x265 should
[13:25:56 CET] <furq> x264 defaults to crf 23
[13:26:11 CET] <furq> in ffmpeg, i mean
[13:26:53 CET] <thetrueavatar> ok didn't know
[13:27:10 CET] <furq> actually it looks like x264 itself does
[13:27:32 CET] <thetrueavatar> will read a bit more about crf to fully understand how it works. Thanks
[13:27:36 CET] <furq> which i guess explains why ffmpeg has a sensible default for x264 and not for most other codecs
[13:28:54 CET] <thetrueavatar> well it's written that default crf should be 28 according to https://trac.ffmpeg.org/wiki/Encode/H.265
[13:29:38 CET] <thetrueavatar> ah maybe I misread. They say that in the example they will use default crf à 28...
[13:31:25 CET] <thetrueavatar> Tried ffmpeg  -i "Kyrielle montage tout OK.avi" -c:a copy -c:v libx265 -preset veryslow -x265-params crf=28 "outFile.mkv"
[13:31:29 CET] <thetrueavatar> but still same result
[13:33:30 CET] <thetrueavatar> frame=  366 fps=2.2 q=-0.0 size=     611kB time=00:00:14.90 bitrate= 335.7kbits/s
[13:35:07 CET] <furq> that works for me
[13:35:35 CET] <thetrueavatar> Here is the complete stack(in cas I missed something)
[13:35:59 CET] <thetrueavatar> I will pm you with this cause it's a bit lonbg
[13:36:13 CET] <furq> pastebin it
[13:36:34 CET] <furq> i've never encoded x265 until about a minute ago to test if that command worked
[13:38:30 CET] <thetrueavatar> http://pastebin.com/raw/XEktNCMe
[13:38:40 CET] <thetrueavatar> http://pastebin.com/XEktNCMe
[13:38:55 CET] <furq> x265 [info]: Rate Control / qCompress            : CRF-28.0 / 0.60
[13:39:04 CET] <furq> that looks like it's working to me
[13:39:25 CET] <furq> if it's a static title card or something then 400kbps is totally feasible for 1080p
[13:39:25 CET] <thetrueavatar> indeed.
[13:39:57 CET] <thetrueavatar> ok so there just a littlbe display bug in ffmpeg which is showing me q=-0.0
[13:40:40 CET] <furq> also it looks like -crf 28 works now
[13:41:28 CET] <thetrueavatar> in fact it was working with preset only
[13:41:52 CET] <thetrueavatar> I'm a begginer with ffmpeg and x265 cli. Used to encode with megui on windows :-)
[13:42:09 CET] <furq> if you can figure out megui then ffmpeg should be simple
[13:42:32 CET] <furq> megui's ui is loathsome
[13:43:33 CET] <thetrueavatar> well I used to choose a preset in the ui so never really looked at each configuration checkbox
[13:43:55 CET] <furq> i tried it again recently because i wanted to use an avisynth script (qtgmc)
[13:44:00 CET] <furq> that was a waste of two hours
[13:44:33 CET] <thetrueavatar> don't think that avisynth script still worth trying cause there is no more resizing and no more mpeg2 noise to filter.
[13:44:50 CET] <furq> i was ripping a poorly deinterlaced dvd
[13:45:00 CET] <thetrueavatar> ah indeed with that kind of source...
[13:45:11 CET] <furq> i still technically am because i haven't ripped it yet
[13:45:28 CET] <thetrueavatar> btw afair there was a nice gui tool for avisynth script
[13:46:41 CET] <thetrueavatar> AVISynth UI if I remember well
[13:46:52 CET] <thetrueavatar> there was a nice preview option
[13:47:11 CET] <furq> i'm probably just going to wait for someone to add qtgmc to handbrake
[13:47:22 CET] <furq> by which i mean add it to ffmpeg
[13:48:22 CET] <thetrueavatar> qtmc is an avisynth  editor  ?
[13:48:38 CET] <furq> it's a fancy deinterlace filter
[13:49:03 CET] <thetrueavatar> ah ok
[13:49:44 CET] <thetrueavatar> handbrake is using ffmpeg for encoding ?
[13:50:04 CET] <furq> i think it uses libav* directly
[13:50:25 CET] <furq> i only use it because it handles PGCs and chapters correctly
[13:50:26 CET] <thetrueavatar> However i don't see any possibility to chosse an avisynth  script
[13:51:40 CET] <thetrueavatar> my little boy is crying. will have to leave. thanks for the help
[14:00:04 CET] <grublet> what command line would i need to be able to split an audio file based on timecodes stored in a text file?
[15:59:31 CET] <bazingirno> can x265 act as "drop in" where h.265 is used? Need to do some html5 stuff.
[15:59:48 CET] <furq> did you mean h.264
[16:00:39 CET] <furq> if so then no
[16:00:52 CET] <bazingirno> no mean the new stuff but I would think I am asking the same with x264 vs h264
[16:01:12 CET] <furq> x265 is an h265 encoder
[16:01:17 CET] <furq> likewise with x264
[16:01:29 CET] <furq> but h265 isn't supported by any browsers yet
[16:02:11 CET] <bazingirno> just tried some vp9 stuff and it worked nice with FF. But vp9 is not h265.
[16:02:17 CET] <furq> it sure isn't
[16:02:46 CET] <furq> for html5 video your choices are h264, vp9, vp8 or theora
[16:02:55 CET] <furq> in descending order of how much you'd want to use them
[16:03:17 CET] <bazingirno> wonder what the new standard will be for html5. vp9 did not work with Edge
[16:03:30 CET] <bazingirno> in the past I would use vp8 and vorbis
[16:03:34 CET] <furq> http://caniuse.com/#feat=webm
[16:03:34 CET] <bazingirno> with webm
[16:03:38 CET] <bazingirno> lol yeah
[16:03:44 CET] <JEEB> MS is going to integrate libvpx or libavcodec for VP9
[16:03:45 CET] <furq> edge and safari don't support vp8 either afaik
[16:03:45 CET] <JEEB> and opus
[16:03:48 CET] <JEEB> for edge
[16:04:00 CET] <JEEB> I would guess libvpx even though it's slower
[16:04:11 CET] <JEEB> due to its license being less restrictive than lavc's
[16:04:22 CET] <JEEB> (zomg I have to publish the source code for a library I use)
[16:04:23 CET] <bazingirno> omgz... why cant MS and Apple stop being dicks and just work with ppl
[16:04:30 CET] <JEEB> lol
[16:04:35 CET] <JEEB> I'd push that straight onto google
[16:04:43 CET] <JEEB> for making those formats behind closed doors
[16:04:53 CET] <JEEB> there's a reason why they're not standard formats
[16:05:01 CET] <bazingirno> Reason I no w only buy Nexus stuff
[16:05:03 CET] <JEEB> because they were never made a standard
[16:05:06 CET] <bazingirno> I now*
[16:05:10 CET] <JEEB> or as a standard
[16:05:20 CET] <JEEB> as a complete bystander I could register onto jct-vc mailing list
[16:05:31 CET] <JEEB> and look through what they were and are doing with HEVC
[16:05:36 CET] <furq> they're all as bad as each other
[16:05:38 CET] <JEEB> (which is also known as H.265)
[16:05:56 CET] <JEEB> meanwhile G is just doing it the way On2 was doing it, it seems
[16:06:03 CET] <JEEB> no specs and the impplementation is the spec
[16:06:29 CET] <JEEB> also doing On2 like marketing and thrusting non-technical topics into I think IETF (?) technical meetings
[16:06:54 CET] <JEEB> I was really ready to give G a chance after VP8 until VP9 came out
[16:07:01 CET] <JEEB> then they just did the same thing with VP9
[16:07:03 CET] <JEEB> and I went meh
[16:07:22 CET] <JEEB> VP8 was inherited from On2 so I was OK with there being issues in how it was created etc
[16:07:26 CET] <furq> i look forward to the new open media alliance codec and the exciting ways in which i won't be able to use it because of lack of support
[16:08:18 CET] <bazingirno> Reading up a little on this as we speak. Seems MS is going to start using VP9 with Edge in the next big "update" or w/e they call it
[16:08:33 CET] <furq> good luck getting apple to use anything other than h.264
[16:08:41 CET] <JEEB> they are not starting to use it, they're just going to enable support
[16:08:53 CET] <JEEB> also rather than VP9 I'm more interested in how they're also going to enable Opus
[16:09:03 CET] <JEEB> which is a pretty cool audio format
[16:09:23 CET] <JEEB> but yes, your iOS devices will still not handle it and mobile devices in general have almost no available HW decoding for VP9/8
[16:10:19 CET] <JEEB> and of course for VPx to be used anywhere you have to have a working rate control, which IIRC libvpx doesn't still properly have
[16:10:26 CET] <JEEB> because 'tube doesn't need it
[16:10:36 CET] <JEEB> (they have their own wrapper that handles that)
[16:11:45 CET] <bencoh> ondemand OTT streaming :]
[16:12:02 CET] <JEEB> I fucking hate that wording
[16:12:03 CET] <JEEB> so marketing
[16:12:22 CET] <Soni> any youtubers which use ffmpeg for editing their videos?
[16:12:38 CET] <bencoh> me too, but that's exactly what youtube is, and that's probably why they never bothered writing a working rate control
[16:13:01 CET] <JEEB> bencoh: no they do have rate control... it's just not in the public
[16:13:12 CET] <JEEB> which is why the public library doesn't have it :P
[16:13:34 CET] <bencoh> JEEB: does it work, or is it just in the same state as the one in x265 (not really working)? ;)
[16:13:53 CET] <bencoh> (not expecting you to answer since you dont have the source either :)
[16:14:32 CET] <JEEB> pretty sure even with all the fuck-ups libx265's rate control works better than libvpx's
[16:14:39 CET] <JEEB> (both being public)
[16:15:01 CET] <JEEB> I think the main problem was that some options you'd expect to be wired weren't in the libavcodec wrapper
[16:15:18 CET] <JEEB> so you had to input them in the straight-to-library key-value thing
[16:15:33 CET] <bencoh> even with those, x265 rc didnt work properly
[16:15:33 CET] <JEEB> that said, I haven't exactly tested the VBV too hard
[16:16:19 CET] <bencoh> vbv was always a tad wrong and we had to drop a few packets here and there (strict cbr mux)
[16:16:50 CET] <JEEB> ok
[16:16:58 CET] <JEEB> glad someone is testing it
[16:17:04 CET] <bencoh> I havent tried for 6 months though
[16:17:10 CET] <Soni> how do I put a video stream over another video stream?
[16:17:20 CET] <bencoh> (it was at previous $job)
[16:18:02 CET] <JEEB> that sounds about right for me as well, although I had no intention of actually checking if the thing was exact
[16:18:10 CET] <JEEB> as long as it was close enough
[16:18:33 CET] <JEEB> my own private tests usually just poke at crf without VBV
[16:21:03 CET] <relaxed> Soni: https://ffmpeg.org/ffmpeg-filters.html#overlay-1
[16:29:02 CET] <Soni> relaxed, thanks
[16:29:11 CET] <Soni> any youtubers which use ffmpeg for editing their videos?
[16:31:43 CET] <DHE> plenty. why?
[16:37:22 CET] <Soni> cool
[16:37:34 CET] <Soni> can I use ffmpeg for livestreaming?
[16:38:07 CET] <DHE> well, yes, but it's a question of what other software goes with it. nginx-rtmp, or some dumb http server (apache or nginx again) for serving HLS or DASH are the open source options
[16:39:12 CET] <DHE> ffmpeg does have ffserver but it's not really that great
[16:41:53 CET] <Soni> I see
[16:42:36 CET] <Soni> and how do I screen capture with ffmpeg?
[16:47:56 CET] <paule32> Soni: use vlc
[16:48:19 CET] <paule32> else x11grab,
[17:30:56 CET] <ethe> Soni: which os?
[17:45:24 CET] <Soni> ethe, linux
[17:46:49 CET] <ethe> then as paule32 said, use x11grab. here's screen capture with ffmpeg (using x11grab): http://wiki.oz9aec.net/index.php/High_quality_screen_capture_with_Ffmpeg
[18:53:03 CET] <thetrueavatar> I'm just back to  transcoding for an almost 7 year's break. If you have any technical source to help me to fill the gap feel free ^^
[18:54:01 CET] <thetrueavatar> I found on doom9 the following Russian comparaison of most recent codec: http://compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf
[18:55:25 CET] <JEEB> x264 is still the thing to use except for testing and cases where you want to push rates so down that it would look bad with any format. You can do best scaling and colorspace conversions with anything based on the zimg library (which is used by the zscale filter in FFmpeg)
[18:55:44 CET] <JEEB> libx265 will take a lot of time and still has issues with random detail drop even with relatively high rates
[18:56:23 CET] <JEEB> also they haven't gotten the psychovisual optimizations done for the delicious part of HEVC, which is coding tree units bigger than 16x16
[18:56:59 CET] <JEEB> unless you are encoding for plastic hardware boxes, 10bit libx264 is a deffo recommendation
[18:59:47 CET] <thetrueavatar> ok. By scaling your mean resizing(1080p->720p)  ?
[19:01:30 CET] <JEEB> and converting from 8bit YCbCr to 10bit or so etc
[19:01:39 CET] <JEEB> or between BT.709 and BT.2020 or BT.601
[19:03:39 CET] <thetrueavatar> to be honest I don't know what's 8bit YCbr is
[19:04:43 CET] <thetrueavatar> BTW if you have any teorical explanation about encoding(with math no problem) this will definitevly interest me
[19:06:11 CET] <JEEB> something like http://lurkertech.com/lg/video-systems/ ?
[19:06:34 CET] <JEEB> not exactly encoding, but video systems
[19:07:19 CET] <furq> are there significant advantages to 10bit x264 with 8bit sources
[19:07:39 CET] <thetrueavatar> that seems to be a good start.
[19:07:40 CET] <JEEB> depends on your source, and the advantages are in compression anyways
[19:07:46 CET] <thetrueavatar> thanks
[19:07:51 CET] <furq> yeah i'm reading that it compresses better but i can't imagine it makes that big a difference
[19:07:54 CET] <JEEB> since you start losing less in gradients and other similar things
[19:08:03 CET] <furq> ah
[19:08:15 CET] <JEEB> and in general makes a similar error smaller
[19:08:18 CET] <JEEB> since you've got more bits
[19:08:32 CET] <furq> let's see if i even have 10bit support
[19:08:33 CET] <JEEB> depending on source it's somewhere around 5-10% or even more
[19:08:40 CET] <JEEB> forget about it with hardware
[19:08:48 CET] <furq> i meant in this build of ffmpeg
[19:08:58 CET] <JEEB> it's there from around 2011
[19:09:09 CET] <thetrueavatar> is 10bit the defaut for x264 preset veryslow ?
[19:09:11 CET] <furq> is it just -profile high10
[19:09:17 CET] <JEEB> unless you specifically disabled it which was created due to needs from the chromium project
[19:09:31 CET] <JEEB> no, you can only encode 10bit with a 10bit libx264 and only 8bit with a 8bit one
[19:09:37 CET] <JEEB> you don't have to specify anything
[19:09:42 CET] <JEEB> thetrueavatar: no
[19:09:49 CET] <furq> well yeah that's what i meant
[19:10:04 CET] <thetrueavatar> you're working too on chromium ?
[19:10:09 CET] <JEEB> no
[19:10:24 CET] <JEEB> the reason why you can disable 10bit and some other features in lavc's AVC decoder is because of them
[19:10:33 CET] <JEEB> because they wanted to minimize the binary size
[19:10:47 CET] <JEEB> that said, almost no-one does that and I'm actually not sure if that patching got into upstream FFmpeg
[19:11:14 CET] <furq> https://ffmpeg.zeranoe.com/blog/?p=435
[19:11:16 CET] <furq> oh neat
[19:11:20 CET] <furq> i guess i'll give that a try then
[19:11:50 CET] <JEEB> you'd probably want a build with zimg in it so you don't have to go through swscale
[19:11:53 CET] <furq> i can't imagine player support is noticeably worse than for regular high profile
[19:11:58 CET] <thetrueavatar> ok so I have to rebuild my ffmpeg to use 10bit decoder...
[19:12:08 CET] <JEEB> thetrueavatar: yours is older than 2011?
[19:12:19 CET] <thetrueavatar> no just build it yesterday
[19:12:35 CET] <JEEB> then unless you specifically disabled features in the AVC decoder you have the decoder just fine
[19:12:46 CET] <JEEB> it's the encoder which you can only have either bitness of linked in
[19:12:59 CET] <thetrueavatar> I ment encoder
[19:13:19 CET] <furq> i should probably figure out why compiling fdk-aac crashed msys2 and compile it myself
[19:13:34 CET] <furq> but i've spent too much of my life fixing msys' bullshit
[19:14:16 CET] <thetrueavatar> I'm trying to shrink the size of  a 3000kbits  1080p personal videot(1h43)
[19:14:26 CET] <JEEB> that's already relatively low bit rate
[19:14:28 CET] <furq> 3000?
[19:14:59 CET] <JEEB> 3 mbits is not that much given what kind of results the commercial or hardware encoders give
[19:15:00 CET] <thetrueavatar> 3310 to be exact
[19:15:09 CET] <furq> yeah that seems very low already
[19:15:41 CET] <thetrueavatar> well that's 3.5gb and wanted to compress it because it seems to be to big for my dnla server
[19:16:01 CET] <thetrueavatar> and btw I try to use x265 for fun
[19:16:04 CET] <furq> downscaling to 720p is probably your best bet if you don't want to murder the image quality
[19:16:26 CET] <JEEB> thetrueavatar: x265 is "OK" but very slow and can lose random details
[19:16:42 CET] <thetrueavatar> that was one of my question. Is it better to downscale or to rise quantize ?
[19:16:45 CET] <JEEB> definitely lacks the love that x264 got community-wise
[19:17:00 CET] <furq> i guess you could try x265 veryslow if you have a couple of days to spare
[19:17:13 CET] <thetrueavatar> that's exactly what I'm doing...
[19:17:27 CET] <furq> personally i would downscale it, but then i downscale all my 1080p content
[19:17:32 CET] <thetrueavatar> 10 minutes for a 6 hour encoding on a core I7 haswell
[19:17:34 CET] <furq> i don't have any screens big enough to notice the difference
[19:18:22 CET] <JEEB> well 1080p at 3mbits... there's probably not even enough details there :P
[19:18:29 CET] <thetrueavatar> I'm a bit surprise that the bitrate is less than 1K
[19:18:39 CET] <thetrueavatar> during x265 encoding.
[19:18:41 CET] <furq> if the dlna server is choking on the filesize then you could try splitting it
[19:18:42 CET] <JEEB> that's because you've set the rate control to what you've set
[19:18:52 CET] <thetrueavatar> crf 28
[19:18:56 CET] <JEEB> nowadays encoders don't really struggle at hitting any target
[19:18:57 CET] <furq> but if it can't handle a 3.5GB video file then you've got bigger problems
[19:19:15 CET] <JEEB> (except maybe sub-audio-track rates with 1080p30 or so)
[19:19:17 CET] <thetrueavatar> it's running on my nas
[19:19:21 CET] <thetrueavatar> so cpu is...
[19:19:27 CET] <furq> oh
[19:19:45 CET] <furq> well x265 decoding takes more cpu than x264
[19:20:02 CET] <thetrueavatar> I know that's juste for the fun this encodig ^^
[19:20:02 CET] <furq> downscaling will definitely help if you're cpu-bound
[19:20:15 CET] <JEEB> anyways, you should pick a few scenes (overall like 2500-5000 pictures with 24p) and decide which crf value to use
[19:20:29 CET] <JEEB> after that you can do the long encode with that
[19:20:41 CET] <JEEB> additionally I definitely recommend building x265 with high bit depth support enabled
[19:20:47 CET] <JEEB> 10bit helps there as well
[19:21:03 CET] <thetrueavatar> this is a private concert so there are a lot of dark part
[19:21:36 CET] <JEEB> ugh, that sounds like the 3mbps "source" that you have is really bad to begin with
[19:21:45 CET] <JEEB> concert and only 3mbps at 1080p
[19:22:19 CET] <JEEB> of course downscaling to 720p would help there to alleviate the fact that there's not much crap left to encode
[19:22:22 CET] <thetrueavatar> well that's stupid they made a 1080p h264 video with a small 256kbit mp3....
[19:22:44 CET] <thetrueavatar> I would have tought that dark would help encoding ?
[19:23:00 CET] <furq> depends how dark
[19:23:13 CET] <JEEB> well dark or not dark there probably at some point were details
[19:23:15 CET] <JEEB> if not, sure
[19:23:26 CET] <furq> if "private" implies that it was filmed with one static camera then that will help bitrate a lot
[19:23:51 CET] <furq> also 256k mp3 is pretty good these days, especially LAME
[19:24:13 CET] <furq> it wouldn't be my first choice though
[19:24:16 CET] <thetrueavatar> yep you'r right I tought public would be completely black but no there are too many details
[19:25:03 CET] <thetrueavatar> Well if I had to record a concert I would definitively try to get the best codec and bitrate for sound...
[19:25:44 CET] <thetrueavatar> maybe in lossless mode
[19:27:57 CET] <thetrueavatar> is it a special git branch for 10bit x264 ?
[19:29:10 CET] <JEEB> no
[19:29:13 CET] <JEEB> just a configure parameter
[19:29:25 CET] <thetrueavatar> ah ok
[19:29:44 CET] <thetrueavatar> we're talking of linux's configure ?
[19:29:47 CET] <JEEB> same with x265
[19:29:54 CET] <JEEB> uhh, software configuration when you build it :P
[19:31:03 CET] <thetrueavatar> so definitively ./configure on linux :p
[19:31:39 CET] <JEEB> not limited to of course
[19:31:46 CET] <JEEB>  same scripts are also used on other systems
[19:32:41 CET] <thetrueavatar> ok will sto my x265 encoding since anyway I must work with my latop tomorow ^^
[19:32:58 CET] <thetrueavatar> Will give a try with x264 10bit and 720p scaling
[19:34:14 CET] <thetrueavatar> do I need to rebuild ffmepg or only libx264 ?
[19:34:27 CET] <JEEB> both
[19:34:39 CET] <thetrueavatar> ok ^^
[19:45:42 CET] <thetrueavatar> Nothing special to configure on ffmpeg build to support 10 bit ? Just build x264 with 10 bit enable ?
[19:56:47 CET] <JEEB> and x265 with high bit depth support if you want to use that encoder as well
[19:57:05 CET] <JEEB> also as I noted you'll want to build with the zscale filter enabled as well
[19:57:09 CET] <JEEB> which bases on the zimg library
[19:57:15 CET] <JEEB> https://github.com/sekrit-twc/zimg
[20:09:59 CET] <thetrueavatar> oki thanks !!
[20:10:23 CET] <thetrueavatar> there is no way to use avisynth script with ffmpeg ?
[20:10:41 CET] <JEEB> sure is, but I'd rather use vapoursynth and vspipe myself
[20:11:04 CET] <JEEB> native high bit depth support and all those goodies
[20:11:18 CET] <thetrueavatar> ah that's new for me vapoursynth
[20:11:27 CET] <thetrueavatar> replacement of avisynth ?
[20:11:32 CET] <JEEB> that said if you're just rescaling and doing bit depth conversions zscale/zimg is also usable from FFmpeg
[20:11:46 CET] <JEEB> a cross-platform similar thing that tries to fix a lot of the design issues in avs
[20:12:03 CET] <JEEB> avs was very much bound to the VFW system's limitations
[20:12:22 CET] <JEEB> and never had proper support for stuff like timestamps and high bit depth
[20:12:40 CET] <JEEB> avs still has a bigger legacy, but I finally switched my (mostly test) encodes to vs last year
[20:13:03 CET] <JEEB> there was quite a bit of work done to have the primary things available
[20:13:42 CET] <JEEB> that said, vs or avs are just extra complexity if you are doing something simple :P
[20:14:54 CET] <thetrueavatar> that's rigth since there is no need to clean grain from source as it used to be with mpeg2
[20:16:40 CET] <thetrueavatar> if source is 8 bit I need to convert it ?
[20:17:01 CET] <JEEB> yeah
[20:17:24 CET] <JEEB> also zimg does the image processing in higher bit depth in genera and tries to be as correct as possible
[20:17:43 CET] <JEEB> I think the only negative thing was that the colorimetry metadata didn't get passed on so you'd have to set that in the encoder manually
[20:18:14 CET] <JEEB> but that's an issue with the zscale filter in FFmpeg, not zimg itself
[20:18:39 CET] <thetrueavatar> zscale is another thing to compile and configure or is it embedded in ffmpeg ?
[20:18:51 CET] <JEEB> zimg is a library that the zscale filter uses in FFmpeg
[20:18:58 CET] <JEEB> I linked the repo to zimg
[20:19:10 CET] <thetrueavatar> ah ok
[20:19:19 CET] <thetrueavatar> ok I have already build it
[20:19:33 CET] <JEEB> then you just have to enable the zscale filter in your FFmpeg configuration
[20:19:37 CET] <thetrueavatar> so there is no special configuration for build with zscale
[20:19:42 CET] <thetrueavatar> ok ^^
[20:20:13 CET] <JEEB> I was happy recently as vapoursynth switched from swscale based scaling and colorspace conversion to zimg based
[20:20:33 CET] <JEEB> no need to get scaling plugins for general scaling/colorspace conversion
[20:20:44 CET] <JEEB> swscale being the old thing in FFmpeg
[20:21:06 CET] <JEEB> made in a different time where doing realtime conversions on CPU was already a feat
[20:21:44 CET] <thetrueavatar> do you know where I  cand find documentation about configuration parameter ?
[20:21:50 CET] <thetrueavatar> to build ffmpeg
[20:22:00 CET] <JEEB> ./configure --help
[20:22:05 CET] <thetrueavatar> lool
[20:22:09 CET] <JEEB> although generally you don't need the kitchen sink
[20:22:30 CET] <JEEB> you generally need just the stuff that gets enabled by default and maybe some very specific things that you might be using
[20:22:49 CET] <JEEB> decoder-wise you should always be set, thus leaving pretty much encoders being the thing you require
[20:23:01 CET] <JEEB> (and zscale nowadays as an exception)
[20:24:07 CET] Action: llogan has yet to try zscale
[20:24:53 CET] <JEEB> zimg should be rather well threadable etc, but I haven't done any calculations of how effective the libavfilter scaler is
[20:25:00 CET] <thetrueavatar> Not sure to understand. You mean that I don't neeed zscale to scale down my source and convert it to 10bit ?
[20:25:02 CET] <JEEB> also it'd be nice to get the colorimetry passed on
[20:25:25 CET] <JEEB> thetrueavatar: it's not *required* , but if you're gonna build a new FFmpeg anyways, better take the better way :P
[20:25:41 CET] <JEEB> swscale is what it is and I like using it less and less
[20:25:50 CET] <thetrueavatar> ok. Sorry for all those questions. I'm really a newbie with ffmpeg :p
[20:26:40 CET] <thetrueavatar> hum don't find any option to use zimg/zscale. only found an option to disable swscale :p
[20:27:10 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L275
[20:27:48 CET] <thetrueavatar> hum weird I didn't had this in my ./configure --help
[20:28:06 CET] <thetrueavatar> or didn't see it ...
[20:28:11 CET] <JEEB> then you're building an old version, most probably
[20:28:28 CET] <JEEB> in FFmpeg the standard is that you look at the latest FATE results and use the latest git master that passes it
[20:28:35 CET] <JEEB> (for your architecture(s))
[20:29:01 CET] <thetrueavatar> I have downloaded source from ffmpeg.org, I didn't took them from git ...
[20:29:46 CET] <JEEB> then check what on earth you downloaded :)
[20:30:09 CET] <thetrueavatar> well will take source from git...
[20:30:30 CET] <JEEB> the github is just a mirror btw, the git.videolan.org one is the main repo atm
[20:30:38 CET] <JEEB> just that it's prettier to link at it @ github
[20:30:44 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=summary
[20:31:05 CET] <thetrueavatar> https://github.com/FFmpeg/FFmpeg  ?
[20:31:23 CET] <llogan> the github may lag behind
[20:31:52 CET] <thetrueavatar> http://ffmpeg.org/releases/ffmpeg-2.8.4.tar.bz2 << that's what I took
[20:31:54 CET] <thetrueavatar> before
[20:31:56 CET] <JEEB> well yeah
[20:32:03 CET] <JEEB> that will not have among other things the zscale filter
[20:32:23 CET] <JEEB> releases happen every now and then and the project is very moving
[20:33:07 CET] <llogan> thetrueavatar: releases are targeted towards distributors and the paranoid. general users are encouraged to use a build from current git master if possible
[20:33:37 CET] <llogan> releases don't usually get backports of new features that appear after the release
[20:34:16 CET] <thetrueavatar> indeed with master source code I got the option
[20:35:01 CET] <JEEB> generally you can see how broken FFmpeg currently is for your architecture/OS by looking at FATE results. but that is no different between releases and random versions from git
[20:35:11 CET] <JEEB> FATE being http://fate.ffmpeg.org/
[20:35:27 CET] <JEEB> let's just say that a lot of stuff gets tested
[20:36:00 CET] <thetrueavatar> fate is a kind of integration testing tools ?
[20:36:19 CET] <thetrueavatar> like like hudson/jenkins in the java world ?
[20:36:24 CET] <JEEB> not that much really, although there's nowadays tests run via the API
[20:36:41 CET] <JEEB> a) do things build b) do specific tests pass on various architectures/OSs
[20:38:29 CET] <thetrueavatar> well guess that on linux/X86 this should be ok
[20:40:26 CET] <JEEB> yeah, the 64bit variety of that is most tested
[20:41:12 CET] <thetrueavatar> you mean linux 64 bit ?
[20:41:24 CET] <JEEB> intel arch 64bit linux, yes
[20:41:45 CET] <thetrueavatar> I'm still on 32bit cause 3 years ago using 64 bit was a real nightmare for me
[20:41:48 CET] <JEEB> I generally just check that the tests aren't currently failing when updating stuff for various purposes :)
[20:42:18 CET] <thetrueavatar> you don't have an automatic mail that say "hey guys this man broke everything" ? :p
[20:42:38 CET] <JEEB> people usually notice it pretty well :)
[20:42:45 CET] Action: JEEB has only broken FATE once
[20:43:31 CET] <thetrueavatar> there is not kind of unit testing done in this project ?
[20:43:50 CET] <JEEB> well the newer API tests are closer to that
[20:44:00 CET] <JEEB> generally it's testing of if specific input gives specific output
[20:44:09 CET] <thetrueavatar> I'm working in the JAVA/JEE env so don't know how it works in the c world ^^
[20:44:14 CET] <xintox> what's the best way to restart ffmpeg without causing stream interruption?
[20:44:50 CET] <BtbN> Well, don't restart it if you don't want to interrupt it.
[20:45:18 CET] <JEEB> thetrueavatar: after you build stuff you can run `make fate` given that you have the FATE sample set somewhere
[20:45:29 CET] <xintox> BtbN: i have to sometimes...but is there anyway to cause it to not drop? I don't care if it flickers or whatever, but right now all the players stop playing it completely.
[20:45:43 CET] <thetrueavatar> ok. ffmpeg is in oo or pure c ?
[20:45:51 CET] <JEEB> pure C, not like it stops OO though
[20:45:57 CET] <JEEB> OO is just a paradigm
[20:46:14 CET] <BtbN> xintox, you can't exit an application without it closing all its sockets.
[20:46:17 CET] <thetrueavatar> yes I know just asking if it was c++ with oo
[20:46:33 CET] <JEEB> C++ is not liked in the multimedia circles
[20:46:40 CET] <JEEB> you will be accepted if your API is C though
[20:46:50 CET] <JEEB> like zimg and some other things have
[20:47:16 CET] <JEEB> the one time I broke FATE was due to output of a filter in between not being bitexact though, so I broke everything but optimized intel arch nîn
[20:47:43 CET] <JEEB> (someone reviewing my patch told me to remove flags from tests which I didn't know of - one of which was bitexact)
[20:47:47 CET] <thetrueavatar> well if you don't have any inheritance mechanism in the language I don't see how to do OO ^^
[20:48:14 CET] <JEEB> structs that have similar function pointers?
[20:48:52 CET] <thetrueavatar> Ok forget that structure things. My level of c is close to zero tbh
[20:49:31 CET] <JEEB> but yeah, C++ can in some things be useful, which is why some libraries use it. the main thing is that they have C interfaces that they can be used through
[20:50:28 CET] <llogan> relaxed: looks like a user is having an issue with one of your builds: http://superuser.com/questions/1024300/ffmpeg-alsa-audio-capture-not-working
[20:51:13 CET] <thetrueavatar> ok ffmpeg build with all the stuff.  any documentation pointer to scaling - 10bit conversion ?
[20:52:24 CET] <JEEB> -vf zscale=w=1280:h=720,format=yuv420p10
[20:52:25 CET] <thetrueavatar> found for zscale. Will look for 10 bit conversion
[20:52:31 CET] <thetrueavatar> how nice ^^
[20:53:33 CET] <JEEB> the format is a separate filter but it's a funky one, it basically gives the requirement for the preceding filter. if it can't be done, it will plug in an swscale filter automagically
[20:54:09 CET] <thetrueavatar> arf ffmpeg: error while loading shared libraries: libzimg.so.2: cannot open shared object file: No such file or directory
[20:54:19 CET] <thetrueavatar> Id dit make install tough
[20:54:28 CET] <JEEB> run ldconfig as root
[20:54:49 CET] <thetrueavatar> nothing ...
[20:54:59 CET] <JEEB> (I will implicitly think that you make installed into a directory which is indexed)
[20:55:33 CET] <thetrueavatar> hum if I did it was totally unintended... :p
[20:55:53 CET] <JEEB> if not you will have to either add the directory into /etc/ld.so.conf.d/ as a file (and run ldconfig) or use LD_LOAD_PATH (I think that was the env var)
[20:56:10 CET] <JEEB> ok, it ws LD_LIBRARY_LOAD_PATH
[20:56:29 CET] <JEEB> it's usually simpler to add things to /etc/ld.so.conf.d though if you have custom prefixes
[20:56:30 CET] <c_14> Wasn't it just LD_LIBRARY_PATH?
[20:56:43 CET] <JEEB> don't remember to be honest :P
[20:56:53 CET] <JEEB> I switched to adding things to ld.so.conf.d recently
[20:57:11 CET] <c_14> I just build statically or set LD_RUN_PATH before compiling
[20:57:27 CET] <JEEB> yeah, static compilation is another thing I often do
[20:57:33 CET] <thetrueavatar> I thinkg I forgot to mention --enable-static in the configure...
[20:58:06 CET] <c_14> --enable-static doesn't help if one of the dependencies only has dynamic libraries
[20:59:16 CET] <thetrueavatar> ok my library is in /usr/local/lib like the other...
[21:02:20 CET] <thetrueavatar> ok nevermind probably due to my command line completely wrong(write -v:code instead of -c:v...)
[21:02:55 CET] <thetrueavatar> ok encoding running. Thanks a lot for all this help
[21:05:41 CET] <thetrueavatar> hum q=40.0  with ffmpeg -i "Kyrielle montage tout OK.avi" -c:a copy -c:v libx264 -preset veryslow -vf zscale=w=1280:h=720,format=yuv420p10 "Kyrielle montage tout OK.mkv"
[21:05:46 CET] <thetrueavatar> what's the catch ?
[21:06:14 CET] <thetrueavatar> I tougth default crf was 23
[21:07:35 CET] <c_14> 10-bit x264 might have a different default. At the very least the crf range is different
[21:08:33 CET] <JEEB> the crf default is the same
[21:08:40 CET] <JEEB> q value has nothing to do with it
[21:08:45 CET] <JEEB> the crf range is different
[21:08:51 CET] <JEEB> (goes to negative)
[21:09:39 CET] <thetrueavatar> oki tought quantizer and crf was an exact matching
[21:09:55 CET] <JEEB> nope
[21:10:12 CET] <JEEB> the whole idea of CRF is to be more intelligent than "static" quantizers
[21:10:16 CET] <thetrueavatar> is quantizer variable with a given crf ?
[21:10:24 CET] <JEEB> of course
[21:10:24 CET] <thetrueavatar> ah ok so quantizer is adaptive
[21:10:38 CET] <JEEB> it's adaptive within the picture (AQ) as well as between pictures
[21:11:05 CET] <furq> thetrueavatar: -qp is constant quantiser mode
[21:11:18 CET] <JEEB> or -q:v
[21:11:23 CET] <furq> i don't think anyone uses it outside of -qp 0
[21:11:31 CET] <JEEB> but you shouldn't use it for anything else but zero, which is lossless with all bit depths
[21:11:36 CET] <JEEB> (with libx264/x265)
[21:11:47 CET] <JEEB> yeah, it should only be used for development
[21:11:47 CET] <furq> is that the only difference between -qp 0 and -crf 0
[21:11:51 CET] <JEEB> yes
[21:12:00 CET] <thetrueavatar> btw is encoding an x264 video with an x265 lossless can be smaller ? Just theorical question
[21:12:00 CET] <JEEB> crf 0 is only lossless when 8bit x264 is used
[21:12:23 CET] <JEEB> the lossless value would be some negative value with >8bit
[21:12:31 CET] <JEEB> so it's simpler to just use -q:v
[21:13:05 CET] <thetrueavatar> is there any definition/explanation on how crf works ?
[21:13:34 CET] <thetrueavatar> don't hesitate to tell me "just google it" if it's obvious
[21:14:41 CET] <llogan> libx264 ignores -q:v
[21:15:50 CET] <JEEB> really?
[21:16:42 CET] <llogan> i think so. i didn't look at the code, but lazily did -f md5
[21:18:32 CET] <JEEB> ok, seems like only x4->cqp is looked
[21:18:34 CET] <kepstin> tbh, i'm kind of surprised that crf wasn't mapped to -q:v in ffmpeg
[21:18:54 CET] <kepstin> but whatever, too late to change that now :)
[21:18:56 CET] <JEEB> I kind of understand the reason for it since back in the day -q:v was "the thing" for MPEG-4 Part 2 based encoders
[21:19:28 CET] <JEEB> and some people truly thought it meant quality
[21:20:59 CET] <thetrueavatar> JEEB: You told me quantizer was dynamically adapted but I see a constant q=40.0. Is q the quantizer ?
[21:21:12 CET] <kepstin> thetrueavatar: 'crf' stands for 'constant rate factor'; the way 2-pass x264 works is that it analyzes the video to determine the "constant rate factor" necessary to get a video with constant perceptual quality throughout at the requested bitrate.
[21:21:36 CET] <thetrueavatar> I tought crf was in one pass in fact...
[21:21:37 CET] <kepstin> thetrueavatar: it just happens that it made a decent way to do quality-based 1-pass encodes too, so it was exposed for that
[21:21:53 CET] <kepstin> but it's originally an internal implementation detail of 2-pass mode
[21:22:02 CET] <jonascj> I fail at getting a ~10sec clip from a video: "ffmpeg -ss 00:06:10 -i input.mp4 -vcodec copy -acodec copy -to 00:06:25 output.mp4" gives me 6min of video, not 15sec. What am I doing wrong?
[21:22:13 CET] <JEEB> thetrueavatar: you shouldn't look into the q value at all
[21:22:37 CET] <JEEB> as long as you see that your selected crf value is used in libx264's output, that should be it
[21:22:42 CET] <furq> jonascj: specify -ss as an output option or add -copyts as an output option
[21:22:58 CET] <jonascj> furq: so specify -ss after -i?
[21:23:16 CET] <furq> if the start point is already correct with -ss as an input option then use -copyts
[21:23:22 CET] <furq> -ss as an output option is slower
[21:23:24 CET] <kepstin> jonascj: when -ss is used as an input option, timestamps are rewritten to start at 0 (unless you use -copyts)
[21:23:43 CET] <jonascj> oh, I see, that is why it fails.
[21:23:53 CET] <jonascj> (or why I fail)
[21:23:56 CET] <c_14> Or use -t instead of -to
[21:23:56 CET] <thetrueavatar> VBR is only usefull to get a given average bitrate or a fixed size ? Right ?
[21:24:22 CET] <furq> thetrueavatar: no?
[21:24:24 CET] <c_14> You mean ABR or CBR?
[21:24:44 CET] <kepstin> technically using x264 with -crf gives you vbr output...
[21:24:54 CET] <furq> "technically"
[21:25:23 CET] <jonascj> -ss after -i solved the problem. -t instead of -to did as well.
[21:26:04 CET] <thetrueavatar> isn't vbr not always ABR ? Since it's adapt bitrate to get given size ?
[21:26:56 CET] <furq> targeting a given size is abr
[21:26:57 CET] <kepstin> vbr just means that individual frames/packets/whatever aren't constrained to be the same size
[21:27:12 CET] <furq> if you're not targeting a given size (e.g. with -crf) then it's just vbr
[21:27:39 CET] <thetrueavatar> ah ok it was misconception  of mine
[21:29:16 CET] <thetrueavatar> ok after all that knowledge transfer need to eat ^^
[22:36:12 CET] <thetrueavatar> still someone there ? Still got some questions ?
[22:36:20 CET] <thetrueavatar> :p
[22:38:07 CET] <thetrueavatar> Was wondering if there was a way to speed encoding  with some kind of gpu hardware encoding ?  For instance, I got a NAS with a dedicated chip for encoding/decoding
[22:39:28 CET] <tdr> not unless you can feed that NAS code to execute
[22:40:08 CET] <JEEB> do note that none of the ASIC encoders are there for high compression ratio encoding
[22:40:21 CET] <JEEB> it's usually to get a some sort of picture out with low latency
[22:42:58 CET] <furq> thetrueavatar: there are ways but you can't use them to speed up x264 encoding
[22:43:18 CET] <furq> they use their own encoders which are generally (always?) of a lower quality
[22:43:59 CET] <furq> you can do opencl lookahead in x264 now but that's of questionable utility
[22:44:13 CET] <furq> and also i can't imagine you have a good enough gpu in your nas
[22:44:23 CET] <thetrueavatar> there is a dedicated chip
[22:44:39 CET] <thetrueavatar> intel evansport
[22:44:44 CET] <JEEB> basically if you don't want high compression, sure. some ASICs are usable
[22:44:58 CET] <JEEB> but as I noted, they're not there for high compression style of encoding
[22:45:11 CET] <furq> yeah as JEEB said it's mostly useful for low latency encoding
[22:45:15 CET] <furq> they're not really suitable for general use
[22:45:21 CET] <thetrueavatar> that can transcode vc1-clip to h264 1080p
[22:45:34 CET] <JEEB> do you even read what's being told?
[22:46:00 CET] <furq> ignore the thing i said about opencl, i know you're talking about a dedicated asic
[22:46:14 CET] <thetrueavatar> euh you'r talking to me ?
[22:46:17 CET] <furq> yes
[22:46:28 CET] <thetrueavatar> I was askinhg to JEEB ^^
[22:46:35 CET] <furq> i'm pretty sure he was as well
[22:47:27 CET] <thetrueavatar> Not sure what you mean by High compression then.
[22:47:52 CET] <JEEB> high compression ratios
[22:48:08 CET] <JEEB> 23:41 < JEEB> do note that none of the ASIC encoders are there for high compression ratio encoding
[22:48:11 CET] <JEEB> 23:41 < JEEB> it's usually to get a some sort of picture out with low latency
[22:48:25 CET] <JEEB> as you noted there you were using a slow x264 preset I'm pretty sure what you were trying to do is that
[22:49:05 CET] <JEEB> the ASICs can give you a good picture but the amount of bit rate they require is much more than even the faster presets of x264 (in general)
[22:49:22 CET] <thetrueavatar> ok now I get it
[22:49:24 CET] <furq> i'd expect it to be better than x264 ultrafast but not much
[22:49:38 CET] <furq> does ffmpeg even support quicksync yet
[22:49:44 CET] <JEEB> yeah
[22:49:45 CET] <thetrueavatar> that's because there is a ffmpeg install by default on the nas
[22:49:48 CET] <JEEB> also nvenc
[22:50:01 CET] <c_14> quicksync is a pain though
[22:50:06 CET] <c_14> nvenc is much easier to use
[22:50:15 CET] <JEEB> on linux, that is
[22:50:26 CET] <JEEB> anyways, those are generally there for the people who want throwaway encodes quickly
[22:50:29 CET] <c_14> never tried on windows
[22:50:31 CET] <furq> there's an open bug but it looks like it just refers to decoding and preprocessing
[22:50:41 CET] <thetrueavatar> so I tought it could be mapped to the hardware chip. Didn't think chip had his own embedded encoder
[22:51:03 CET] <furq> you're not doing x265 encoding on evansport are you
[22:51:05 CET] <JEEB> would have to have much more traffic between the ASIC and the CPU then
[22:51:10 CET] <thetrueavatar> no not that crazy
[22:51:35 CET] <JEEB> although it depends, basically in theory you could outsource CABAC or so, but I'm really not sure if that's the bottleneck :P
[22:52:00 CET] <furq> x264 is slow enough on my core 2 duo nas
[22:52:13 CET] <JEEB> you'd only want to outsource things that aren't worse off than what you'd have in software basically
[22:52:57 CET] <thetrueavatar> beside converting the concert of my wife, I wanted to automatically convert every video done by my camera but it was slow as hell
[22:53:06 CET] <furq> x264 is pretty fast anyway
[22:53:47 CET] <thetrueavatar> I wanted to automatically convert this video by my nas upon rsync my video with my sd card
[22:54:20 CET] <thetrueavatar> I know I want to do a lot of things ^^
[22:54:28 CET] <furq> well yeah you can do that
[22:54:39 CET] <furq> but you'll have to either encode on an atom or use quicksync's encoder
[22:54:58 CET] <furq> neither of which sound like great options but ymmv
[22:56:38 CET] <thetrueavatar> as said encoding with the atom cpu is slooooow. Will check if it's worth trying to dig into quicksync's encoder
[00:00:00 CET] --- Mon Jan 11 2016