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

[burek]

[00:00:32 CET] <kingsley> Ah, OK.
[00:00:45 CET] <kingsley> My answer?
[00:00:50 CET] <kingsley> 5 minutes.
[00:27:38 CET] <SortaCore> what's the difference between h264_d3d11va and h264_d3d11va2?
[00:27:43 CET] <SortaCore> is the first for backward compatibility?
[01:22:37 CET] <yukiup> yo! big group here
[01:22:53 CET] <SortaCore> I'm just here for the join/leave messages
[01:23:03 CET] <yukiup> its all cool man
[01:23:16 CET] <SortaCore> I asked a question, but it seemed to whoosh
[01:23:20 CET] <SortaCore> (twice)
[01:23:30 CET] <SortaCore> so I'm just waiting for the answerers to wake up/notice/care
[01:24:08 CET] <SortaCore> listening to Legends Never Die and waiting for homemade rice pudding to cool
[01:24:09 CET] <SonicTheHedgehog> SortaCore: I guess that may be better addressed in #ffmpeg-devel
[01:24:31 CET] <SortaCore> I figured that might be true, but I didn't want to interrupt dev stuff
[01:24:35 CET] <SortaCore> without being sure
[01:26:39 CET] <SonicTheHedgehog> mhm
[01:29:59 CET] <yukiup> anyone realized how hard it is to prevent the transitions between color and black being blocky with lower bitrates?
[01:30:40 CET] <yukiup> i have to use crf 10 just to maintain the original video
[01:34:52 CET] <jkqxz> SortaCore:  They have different output formats.  d3d11va was made before there was intent to map the output frames to other components, so it uses the decoder-dependent ID3D11VideoDecoderOutputView.  d3d11va2 uses the ID3D11Texture2D containing the output surface directly.
[01:35:08 CET] <jkqxz> SortaCore:  So pretty much yes, the first one only exists anymore for backward compatibility.
[01:36:49 CET] <foul_owl> When I resize a video with ffmpeg, how do I tell it to use the same codec as the source file?
[01:40:18 CET] <yukiup> run ffmpeg to get info, the specifiy it?
[01:40:22 CET] <DHE> there's no direct command. you'll have to examine the source and request the same codec
[01:41:27 CET] <foul_owl> Ah gotcha! Thanks!
[01:43:53 CET] <SortaCore> I have noticed that the RTSP -> video output is normally double speed
[01:44:31 CET] <SortaCore> packet->dts = packet->pts = frameNum++;
[01:44:42 CET] <foul_owl> Ok probably the wrong channel but please let me know: Any legal issues with compressing using h.265 for either personal or commercial use? Anyone use it?
[01:44:50 CET] <SortaCore> then av_packet_rescale_ts(packet, video_file_encoder_context->time_base, video_file_stream->time_base)
[01:45:07 CET] <foul_owl> Like say I start a company selling tutorial videos on my web site, can I compress and host them in h.265?
[01:45:34 CET] <SortaCore> check the license, I don't think it's a non-free, but a gpl type
[01:46:26 CET] <foul_owl> Thank you
[01:46:39 CET] <foul_owl> Do you personally use it?
[01:46:52 CET] <furq> foul_owl: hevc's licensing situation is insane
[01:47:02 CET] <foul_owl> :(
[01:47:03 CET] <furq> last time i checked there were four licensing authorities
[01:47:10 CET] <SortaCore> "MulticoreWare is committed to offering the x265 software under the GNU GPL v2 license."
[01:47:19 CET] <furq> yeah that's not the same thing
[01:47:26 CET] <SortaCore> hmm maybe not
[01:47:37 CET] <foul_owl> furq: What codec do you personally use for projects then?
[01:47:45 CET] <JEEB> https://www.youtube.com/watch?v=75cdIHLWanY
[01:47:53 CET] <JEEB> this is some lawyer's talk
[01:47:55 CET] <furq> i don't have any projects that involve profiting from video
[01:47:58 CET] <SortaCore> http://x265.org/x265-licensees/
[01:48:01 CET] <furq> and also i'm in the EU where software patents don't exist
[01:48:09 CET] <furq> so i just use x264
[01:48:11 CET] <JEEB> SortaCore: that's just x265 licensing where GPL isn't possible/wanted
[01:48:20 CET] <SortaCore> ah ok
[01:48:20 CET] <JEEB> the actual HEVC licensing is separate
[01:48:29 CET] <furq> but if you want to avoid license fees, use vp9 and opus
[01:48:45 CET] <SortaCore> so HEVC is one complex license, and H265 is the GPL?
[01:48:50 CET] <JEEB> no
[01:48:54 CET] <JEEB> H.264 and HEVC are the same thing
[01:48:59 CET] <JEEB> they mean the format
[01:49:08 CET] <furq> h.265, but yes
[01:49:14 CET] <JEEB> yes, getting late :P
[01:49:22 CET] <JEEB> HEVC is the original ISO/IEC name
[01:49:28 CET] <JEEB> and H.265 is the ITU-T one
[01:49:56 CET] <SortaCore> so what's GPL and what's not?
[01:50:14 CET] <foul_owl> Sorry to open this can of worms o_O
[01:50:16 CET] <furq> x265 is gpl
[01:50:17 CET] <JEEB> x265 the software is GPL (or sepate paid license)
[01:50:36 CET] <SortaCore> so by software, you mean application written by x265 guys that uses the codec
[01:50:38 CET] <JEEB> then if you have the right to use the format depends on lots of things, separate from software licenses
[01:50:47 CET] <furq> ^
[01:51:11 CET] <SortaCore> in short, host your webserver in north korea >.>
[01:51:12 CET] <furq> if you're selling something that bundles x265 then that's fine by the x265 guys as long as you obey the terms of the GPL
[01:51:18 CET] <furq> but that is not fine by the hevc licensing authorities
[01:51:30 CET] <JEEB> IANAL (I Am Not A Lawyer), but as far as I can see the HEVC licensing went bonkers because companies decided the old way of licensing didn't bring them enough shekels
[01:51:45 CET] <furq> likewise if you sell videos encoded using any hevc encoder, you're potentially on the hook
[01:51:46 CET] <JEEB> so now we have like three or four places that tell you you're supposed to license HEVC from them :P
[01:51:58 CET] <furq> i mean you're on the hook for even using any hevc encoder at all, but if you're not making money then nobody's bothered
[01:52:54 CET] <SortaCore> so it's okay if it's non-profit?
[01:53:09 CET] <furq> in theory no but in practice yes
[01:53:14 CET] <SortaCore> otherwise you probably have to mess with one of the four companies?
[01:53:21 CET] <JEEB> one or more
[01:53:21 CET] <furq> potentially all of the four companies
[01:53:27 CET] <SortaCore> neat.
[01:53:32 CET] <furq> yeah it fucking sucks
[01:53:41 CET] <JEEB> yea, this is why people started going towards looking at alternatives
[01:53:51 CET] <furq> this is why av1 exists (or will soon)
[01:53:54 CET] <JEEB> yup
[01:53:55 CET] <furq> and vp9
[01:54:01 CET] <JEEB> AV1 is the "plan B" for a lot of companies
[01:54:55 CET] <SortaCore> so in their efforts to get more money, they turned customers away #corporationftw
[01:55:30 CET] <SortaCore> there you go @foul_owl
[01:55:44 CET] <furq> we answered the shit out of that question
[01:56:24 CET] <SortaCore> I have a trait of dumbing things down simpler and simpler, I'm on a support chatroom where people totally new to coding join all the time
[01:56:34 CET] <SortaCore> pity this one's legalese
[01:57:05 CET] <DHE> I have follow-up questions.  :)  afaik av1 is what google was intending to be vp10. there a timeline on that?
[01:57:21 CET] <furq> wikipedia claims the av1 bitstream is to be frozen q4 2017
[01:57:24 CET] <furq> i.e. now-ish
[01:57:45 CET] <furq> if TD-Linux is here then he can probably tell us how far off that prediction is
[01:59:49 CET] <foul_owl> Thank you
[02:00:58 CET] <SortaCore> in short, H264 is less convoluted, and alts ar eOPUS and VP9 - and H265 might bite you even for non-profit usage, but it's unlikely if it's non-profit
[02:09:54 CET] <foul_owl> Understood
[02:11:05 CET] <foul_owl> Ok one last question, I am editing some 4k video, basically just cutting a file into clips. If I'm doing a cut at the beginning of the raw file, it processes in about 10 seconds, whereas toward the middle of the clip it seems like it has to seek in real time. smplayer can seek in about a second or two. Is there a way to speed this up?
[02:11:29 CET] <c3r1c3-Win> H.265 will 'bite' you for non-profit use, personal use on the other hand....
[02:11:51 CET] <SortaCore> I'm guessing more I-frames?
[02:12:45 CET] <c3r1c3-Win> foul_owl: Depends on the editor and the codec and the file format.
[02:14:26 CET] <foul_owl> Codec of the raw file is h264
[02:14:33 CET] <foul_owl> Codec of output file is up for grabs at the moment haha
[02:15:13 CET] <foul_owl> According to this: http://www.ffmpeg-archive.org/Reducing-seek-time-when-start-time-offset-ss-is-large-td1460307.html it looks like ffmpeg applies the edit to all frames until it reaches the seek point?
[02:15:20 CET] <liyou> how can i see the ffmpeg-log on windows? is there any log file?
[02:15:56 CET] <SortaCore> you might have to pass in a cmd for setting the log level
[02:16:29 CET] <liyou> pls show me, SortaCore
[02:17:22 CET] <SortaCore> https://ffmpeg.org/ffmpeg.html
[02:17:29 CET] <SortaCore> use Ctrl-F for "-loglevel"
[02:17:51 CET] <SortaCore> also see -report
[02:18:52 CET] <liyou> actually, i run vlc.
[02:19:10 CET] <liyou> and vlc will call ffmpeg.
[02:19:39 CET] <SortaCore> probably under Advanced Preferences -> Advanced -> Logging
[02:19:50 CET] <SortaCore> there's a verbosity setting, use one of the numbers from -loglevel
[02:20:05 CET] <SortaCore> and restart VLC to apply it
[02:20:31 CET] <liyou> what is numbers from -loglevel
[02:20:59 CET] <SortaCore> I mean on the page I sent, under -loglevel there are example numbers
[02:21:44 CET] <SortaCore> e.g. info is 32
[02:22:34 CET] <SortaCore> ...nah, that's wrong
[02:22:40 CET] <SortaCore> "Verbosity (0,1,2) This is the verbosity level (0=only errors and standard messages, 1=warnings, 2=debug)."
[02:22:43 CET] <SortaCore> vlc uses those
[02:24:37 CET] <liyou> i think the vlc setting can no effect
[02:25:35 CET] <liyou> i need to see ffmpeg print in vlc
[02:25:40 CET] <SortaCore> did you restart it?
[02:25:46 CET] <liyou> yes
[02:25:51 CET] <SortaCore> hmm I'll hunt around
[02:26:52 CET] <liyou> left block unavailable for requested intra mode at 0 0    what happen?
[02:27:00 CET] <SortaCore> under advanced settings, Interface, there's a "log to file" setting
[02:27:20 CET] <SortaCore> that means it's missing some data to decode
[02:27:34 CET] <SortaCore> not a fatal error although video might distort briefly
[02:27:58 CET] <liyou> video screen is Blurred
[02:29:36 CET] <SortaCore> does it happen a lot?
[02:29:41 CET] <SortaCore> or every so often
[02:30:03 CET] <liyou> but i use vlc2.2.6 compiled by vlc-office to play, video screen is perfect.
[02:46:02 CET] <foul_owl> Does anyone know of a good video player for linux that will show milliseconds? Just for gathering start and stop times for making clips. Thanks!
[02:46:14 CET] <foul_owl> Smplayer works great but doesn't have milliseconds
[02:50:37 CET] <SortaCore> mpv?
[02:51:10 CET] <SortaCore> I use it on my lowpowered netbook, it does good pre-buffering and very simplistic
[02:51:24 CET] <SortaCore> not much by way of ui though
[02:54:45 CET] <foul_owl> Oo let me try it
[02:56:06 CET] <liyou> top block unavailable for requested intra mode at 1 0    what happen?
[02:59:12 CET] <foul_owl> Hmm it just looks like it displays seconds, no milliseconds
[03:06:28 CET] <foul_owl> Ah nm found a post showing how to do it, thanks!
[03:14:50 CET] <foul_owl> Is there no way to cut at exact frame number? Can only do milliseconds and hope the rounding error isn't too much?
[03:58:27 CET] <furq> !filter trim @foul_owl
[03:58:27 CET] <nfobot> foul_owl: http://ffmpeg.org/ffmpeg-filters.html#trim
[04:21:19 CET] <TD-Linux> furq, end of the year, so still pretty acurate
[05:03:40 CET] <foul_owl> Thank you!
[16:51:44 CET] Action: ilya Greets everybody!
[16:52:50 CET] <ilya> I am trying to compile ffmpeg on clean Ubuntu 16.04 using instructions - https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[16:53:54 CET] <ilya> But when i try to "./configure" i get the error "ERROR: x265 not found using pkg-config"
[16:55:06 CET] <ilya> Is that a package problem or I made a mistake?
[16:55:52 CET] <echelon> hi, what codecs are supported in the mpeg-ts container for hls streaming?
[17:06:34 CET] <__jack__> see https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#section-3.4 for audio, h264 for video (I guess)
[17:07:55 CET] <__jack__> see Although the protocol specification does not limit the video and audio formats, the current Apple implementation supports the following formats:
[17:08:00 CET] <__jack__> err : https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html
[17:08:08 CET] <echelon> thanks
[17:59:21 CET] <XSDCS> who can help me with stream via ffmpeg?
[18:02:06 CET] <DHE> that's not how it works. tell us what you're trying to accomplish (with examples if possible, use pastebin) and what's going wrong
[18:02:35 CET] <XSDCS> who can help me with stream via ffmpeg?
[18:02:40 CET] <DHE> that's not how it works. tell us what you're trying to accomplish (with examples if possible, use pastebin) and what's going wrong
[19:12:42 CET] <allanbarber> hello
[19:12:52 CET] <allanbarber> i use ffmpeg for windows
[19:13:06 CET] <allanbarber> and i have a patch ffmpeg-3.3-samygo-0.1.3.patch
[19:13:14 CET] <allanbarber> how i can apply this patch ?
[19:14:16 CET] <durandal_1707> give it to us!
[19:14:33 CET] <allanbarber> the patch?
[19:14:43 CET] <durandal_1707> yes
[19:15:18 CET] <allanbarber> i can give you the link to download it
[19:15:28 CET] <allanbarber> but i am allowed here to paste links ?
[19:16:26 CET] <durandal_1707> yes
[19:16:32 CET] <allanbarber> https://forum.samygo.tv/download/file.php?id=9071
[19:17:22 CET] <durandal_1707> please use pastebin, im not going to create account on that forum
[19:18:44 CET] <allanbarber> oh, ok thank you very much
[19:20:32 CET] <allanbarber> https://pastebin.com/PQtWWTVU
[19:20:34 CET] <allanbarber> take a look
[19:23:23 CET] <allanbarber> durandal_1707 is ok ?
[19:25:05 CET] <durandal_1707> allanbarber: do you know how to apply patch?
[19:25:09 CET] <allanbarber> no
[19:26:38 CET] <durandal_1707> allanbarber: do you have ffmpeg 3.3 source code?
[19:27:41 CET] <allanbarber> durandal_1707 i have ffmpeg-20171111-3af2bf0-win64-static
[19:28:11 CET] <durandal_1707> thats not source code
[19:28:32 CET] <durandal_1707> you need source code to patch it and then build it
[19:30:00 CET] <allanbarber> ffmpeg-3.3.3-win64-static.zip
[19:30:02 CET] <allanbarber> this is ok ?
[19:30:56 CET] <durandal_1707> static means its not source but binaries only imho
[19:32:06 CET] <allanbarber> mmm  but i don't see on ffmpeg site the source code
[19:33:06 CET] <allanbarber> dev, shared ? is ok?
[19:34:13 CET] <allanbarber> i use Windows, is source code available for windows?
[19:35:37 CET] <durandal_1707> look  at wiki how to build ffmpeg for windows
[19:38:40 CET] <allanbarber> mmm :) is to hard for me to apply this patch
[19:38:41 CET] <allanbarber> thank you
[19:41:06 CET] <allanbarber> i downloaded FFmpeg-master.zip
[19:41:13 CET] <allanbarber> with all files
[19:56:58 CET] <durandal_1707> allanbarber: master is not 3.3
[20:17:39 CET] <allanbarber> tell me where to get 3.3 please
[20:21:35 CET] <JEEB> if you want 3.3, `git clone -b release/3.3 "https://git.videolan.org/git/ffmpeg.git"`
[20:21:46 CET] <JEEB> that gets the tip of release/3.3 branch :P
[20:22:54 CET] <allanbarber> i have windows
[20:23:13 CET] <allanbarber> but i think i found here https://www.videohelp.com/download/ffmpeg-3.3.3.tar.bz2
[20:23:51 CET] <JEEB> well windows has git as well
[20:24:47 CET] <allanbarber> how i can use git? :)
[20:24:58 CET] <JEEB> msys2 is probaly simplest
[20:25:16 CET] <JEEB> http://www.msys2.org/
[20:25:57 CET] <allanbarber> thank you
[20:30:24 CET] <allanbarber> durandal_1707 i configured 3.3.3
[20:30:37 CET] <allanbarber> now what is the next step?
[20:30:46 CET] <durandal_1707> did you applied patch?
[20:31:00 CET] <allanbarber> no, because this is what i don;t kwow :)
[20:31:10 CET] <allanbarber> i don't know how to apply patch
[20:31:36 CET] <durandal_1707> git apply patch_name.patch
[20:31:45 CET] <allanbarber> i use mingw
[20:32:25 CET] <allanbarber> i need to install git ?
[20:32:31 CET] <durandal_1707> yes
[20:32:41 CET] <durandal_1707> mingw is not ffmpeg ...
[20:33:00 CET] <allanbarber> i configure ffmpeg with mingw
[20:33:21 CET] <durandal_1707> do you have patch program?
[20:33:36 CET] <allanbarber> no :)
[20:34:42 CET] <allanbarber> suggest me one
[20:35:42 CET] <durandal_1707> you need to type patch inside your mingw shell
[20:35:53 CET] <allanbarber> thanks
[20:36:30 CET] <durandal_1707> but you must also have ffmpeg source code and patch itself... in same directory
[20:40:52 CET] <echelon> hi, i just tried two-pass command from here.. https://trac.ffmpeg.org/wiki/Encode/VP9
[20:41:09 CET] <echelon> but at the end of the first pass, i got ffmpeg: command not found
[20:41:24 CET] <echelon> although it work for the first pass
[20:41:52 CET] <echelon> anyway, i have pass log, will ffmpeg automatically locate it on the second pass?
[20:43:21 CET] <echelon> first pass log*
[20:49:42 CET] <allanbarber> durandal_1707 i typed patch ffmpeg-3.3-samygo-0.1.3.patch
[20:52:49 CET] <durandal_1707> patch -p0 < ffmpeg...patch
[20:52:52 CET] <durandal_1707> ?
[20:53:56 CET] <allanbarber> no
[20:54:28 CET] <durandal_1707> in mingw shell you need to type that to apply patch
[20:56:24 CET] <allanbarber> durandal_1707 https://pastebin.com/zV3qJNs9
[20:57:03 CET] <durandal_1707> allanbarber: you still not in correct directory
[20:57:15 CET] <durandal_1707> bin is not source code of ffmpeg
[20:58:00 CET] <allanbarber> i have lots of folders
[20:58:23 CET] <durandal_1707> me too
[20:58:32 CET] <allanbarber> :)
[20:59:20 CET] <durandal_1707> correct folder have bunch of libavcodec, libavformat and so on  folders
[20:59:35 CET] <allanbarber> yes
[20:59:41 CET] <allanbarber> now i am in the main folder
[20:59:50 CET] <sfan5> echelon: yes ffmpeg will automatically locate the logfile in the second pass
[21:01:01 CET] <allanbarber> but my patch ffmpeg-3.3-samygo-0.1.3.patch where must be located?
[21:01:05 CET] <allanbarber> to type patch -p0 < ffmpeg-3.3-samygo-0.1.3.patch
[21:02:22 CET] <sfan5> pretty sure you need to use patch -p1 instead
[21:02:59 CET] <allanbarber> thanks
[21:03:03 CET] <allanbarber> its works with -p1
[21:13:10 CET] <foul_owl> I think I found a really wierd bug. I have been using -ss and -to after -i, but I recently found documentation that says this can take a very long time. I moved the -ss to before the -i, and now seeking is very fast, but the -to is not being honored! It's basically being ignored
[21:13:18 CET] <foul_owl> How can I fix that?
[21:14:25 CET] <sfan5> consider using -t instead
[21:15:23 CET] <foul_owl> I only have start and stop times, I don't have durations
[21:15:44 CET] <sfan5> you can calculate it though
[21:15:56 CET] <foul_owl> Yeah true...I guess I have to write a script to do that
[21:16:05 CET] <foul_owl> -to is buggy though?
[21:20:42 CET] <foul_owl> awk to the rescue again!
[21:21:15 CET] <kepstin> foul_owl: no, this is functioning as designed. ffmpeg rewrites timestamps on inputs to start at 0, and if you use -ss as an input option, the seek is applied before the timestamp rewriting
[21:21:40 CET] <foul_owl> but using the -to option doesn't follow the documention then
[21:22:18 CET] <foul_owl> if you use -ss before or after -i, -to should work as expected either way imo
[21:23:28 CET] <foul_owl> Ahhh ok I see it now
[21:23:34 CET] <foul_owl> the -copyts flag needs to be enabled
[21:25:18 CET] <foul_owl> My apologies, I absolutely missed that
[21:25:39 CET] <kepstin> you can alternatively use the -itsoffset input option and set it to the same value as -ss
[21:25:51 CET] <kepstin> (that way the other timestamp fixing stuff ffmpeg does still applies)
[21:26:35 CET] <kepstin> but note that -copyts or -itsoffset can have unexpected results in some cases, since it means that the *output* file will have timestamps starting at some value other than 0 (unless you fix that with filters)
[21:27:04 CET] <foul_owl> The output file won't start at 00:00 ?
[21:29:04 CET] <kepstin> depends on the output container format, but in some cases yeah
[21:29:27 CET] <kepstin> depends on the player too, some apply the same fix as ffmpeg does on inputs, to make the file start at 0 when playing
[21:29:44 CET] <foul_owl> Seems to start at 00:00
[21:29:52 CET] <foul_owl> But I will keep an eye out for that
[21:29:55 CET] <foul_owl> Very good to know, thanks!
[21:30:02 CET] <foul_owl> container is mp4
[23:34:39 CET] <echelon> i'm trying to encode some videos using vp9, but the speed is really slow (0.118x)
[23:34:56 CET] <echelon> does ffmpeg make use of all cpu cores by default?
[23:35:55 CET] <sfan5> libvpx is known for being slow
[23:36:03 CET] <sfan5> check (h)top to see whether all cores are used
[23:36:07 CET] <sfan5> i believe it does that by default
[23:37:27 CET] <echelon> i only see 1 core at 100%
[23:37:53 CET] <JEEB> congratulations, your libvpx is either old or something else's off
[23:38:12 CET] <JEEB> try -threads 4 after input (post -i INPUT)
[23:38:24 CET] <JEEB> and if it still does the same then it can't thread
[23:38:25 CET] <echelon> kk
[23:39:24 CET] <sfan5> the default encoding flags for libvpx should not hinder threading though
[23:39:41 CET] <JEEB> at least with something modern, that is
[23:40:11 CET] Action: sfan5 would like to inform everyone that he uses Arch Linux and thus has no problem with outdated software
[23:41:31 CET] <JEEB> yea, sure. it's just on the top list of things of people who come here
[23:43:24 CET] <echelon> hmm.. i used -threads 8, but i see only 2 cores being used
[23:43:59 CET] <JEEB> before or after input?
[23:44:04 CET] <echelon> after
[23:44:20 CET] <JEEB> does it use any more than before or is the speed any better?
[23:44:26 CET] <JEEB> if not, then you're most likely having an old libvpx
[23:44:31 CET] <JEEB> or it's just That Slow
[23:45:01 CET] <echelon> well, last time i was just getting 1 core
[23:45:13 CET] <echelon> speed is twice as good
[23:45:23 CET] <echelon> i'm on 3.3.1, let me try 3.3.4
[23:47:08 CET] <JEEB> the FFmpeg version shouldn't matter
[23:47:11 CET] <JEEB> this is 100% up to libvpx
[23:47:20 CET] <JEEB> which is the actual encoder from your benevolent GOOGLE
[23:48:22 CET] <echelon> the crf setting shouldn't affect it?
[23:49:17 CET] <JEEB> that sounds like rate control so unless you're setting it so that it outputs o9k megabits it shouldn't matter (although it's really encoder-dependent)
[23:53:04 CET] <echelon> alright, guess i'll just leave it running over night
[23:54:56 CET] <SortaCore> so what's the best combo of h264_qsv, libx264, dxva2, d3d11v2, nvenc, and hwaaccel to go with them
[23:55:25 CET] <SortaCore> as in, best combo of encoder and hwaccel, or decoder and hwaccel
[23:55:28 CET] <echelon> does google use some asic chips for encoding vp9 or something?
[23:55:43 CET] <sfan5> just beefy servers i'd imagine
[23:59:31 CET] <JEEB> echelon: they just do short pieces with a single thread
[23:59:37 CET] <JEEB> and of course they've got plenty of machines
[23:59:42 CET] <JEEB> also they utilize pretty fast settings
[00:00:00 CET] --- Tue Nov 14 2017