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

[burek]

[01:06:30 CET] <bencc1> I transcoded the same 90 mintues video with preset veryfast (195 MB) and medium (260MB)
[01:06:51 CET] <bencc1> isn't veryfast suppose to give larger file?
[01:07:50 CET] <JEEB> with CRF? CRF isn't supposed to be the same between different parameters
[01:08:07 CET] <JEEB> because what the CRF algorithm "sees" differs quite a bit
[01:09:28 CET] <bencc1> JEEB: yes, crf 23
[01:09:37 CET] <JEEB> well there's your answer
[01:10:09 CET] <JEEB> CRF was never meant to be comparable between parameters (or encoders for that matter, for those who think that x264 and x265 share CRF values)
[01:10:11 CET] <bencc1> there is no way to compare them with the "same" quality?
[01:10:25 CET] <JEEB> you need to define "quality" first
[01:10:47 CET] <bencc1> true :)
[01:11:12 CET] <bencc1> if I'll decrease the crf I'll get better quality with same cpu load?
[01:11:21 CET] <bencc1> assuming we know how to define quality
[01:11:58 CET] <JEEB> with lower CRF it will try to occur less error onto the source
[01:12:10 CET] <bencc1> so it'll use more cpu?
[01:12:15 CET] <JEEB> ...
[01:12:24 CET] <bencc1> yes?
[01:12:25 CET] <JEEB> how the flying fuck did you read that
[01:12:56 CET] <JEEB> in any case, more CABAC means more CPU power, so the more data you output from an encoder the more theoretically it is using CPU
[01:13:01 CET] <bencc1> when trying to occur less error, does it means just large file size or maybe it requires more work?
[01:13:11 CET] <JEEB> it means just more bits
[01:13:33 CET] <JEEB> but of course more bits in theory means (on some level) more CPU usage because there is more data to process (and to compress with CABAC)
[01:13:46 CET] <JEEB> same thing goes with decoding, more bit rate actually makes the decoding require more CPU
[01:14:07 CET] <JEEB> whether or not that is relevant to your scenario on the scale of the difference depends
[01:14:52 CET] <bencc1> I'm decoding a large number of 'screen captures'
[01:15:13 CET] <bencc1> less CPU load means I can transcode more in parallel
[01:15:24 CET] <bencc1> smaller file size means less storage and bandwidth
[01:15:59 CET] <bencc1> but preset and CRF are both affecting I'm not sure how to choose
[01:16:05 CET] <bencc1> but *if*
[01:16:38 CET] <bencc1> not sure if I should go with preset veryfast/medium/slow and what CRF to choose
[01:18:43 CET] <JEEB> if you want to maximize the amount of things being done in parallel then you want to use threads 1 anyways, and in that case all that matters is A) how long a single transcode takes and B) how much compression you get
[01:19:33 CET] <JEEB> if you really want to start poking around then you can use a metric like SSIM, and use -tune ssim and try to match different presets to the same SSIM
[01:19:42 CET] <JEEB> shouldn't be too hard to script
[01:19:51 CET] <JEEB> SSIM is not quality, but it's one of the least bad metrics
[01:19:54 CET] <bencc1> I have to do it in realtime. I'm actually recording a xvfb display
[01:20:31 CET] <JEEB> well then you don't have a large number of 'screen captures', do you?
[01:20:44 CET] <JEEB> you have actual screen capture that you want to encode in real time
[01:21:04 CET] <bencc1> I'm recording a web browser in a virtual display playing something
[01:21:21 CET] <bencc1> so I can have X sessions each with each own virtual display
[01:21:55 CET] <JEEB> ok, then to maximize the amount of sessions you can have you need to use threads 1 *and* use a preset that is realtime
[01:22:20 CET] <bencc1> "-preset medium crf 23" uses 15% of my cpu
[01:22:48 CET] <bencc1> that might give me a very large file, doesn't it?
[01:23:01 CET] <bencc1> compared to preset medium for example
[01:23:03 CET] <gurki> JEEB: more data to process doesnt neccesarily result in more cpu cycles needed
[01:23:13 CET] <JEEB> gurki: with CABAC I'd say it does
[01:23:32 CET] <JEEB> whether or not it is a relevant difference is a separate discussion
[01:24:07 CET] <gurki> i dont know enough about CABAC to discuss the impacts on that, i just found it neccesary to state that more data doesnt always need more cpu :)
[01:24:08 CET] <bencc1> "-preset:v ultrafast -crf 0 -threads 0" works but it gives me a very large file
[01:24:09 CET] <JEEB> bencc1: go to sleep - you are clearly writing not what you are thinking
[01:24:14 CET] <gurki> sorry for interrupting :)
[01:24:16 CET] <JEEB> gurki: this was specific to AVC
[01:24:19 CET] <bencc1> :)
[01:24:31 CET] <JEEB> and CABAC is the lossless compression scheme in it
[01:24:58 CET] <JEEB> there's also CAVLC but that is mostly irrelevant and has similar effect anyways (just compresses less well)
[01:28:25 CET] <JEEB> gurki: you can think of CABAC and CAVLC as decompressing or compressing something with huffman or something along those lines - the more data you have coming in to the algorithm the more CPU cycles it will take to finish (dec)compressing that input
[03:19:34 CET] <funyun> can ffmpeg handle this? if so, can anyone point me in the right direction? i'm trying to add a 3 minute audio file looped into the background of a 2 hour audio file. so the total length would still be 2 hours. but the 3 minute audio will play looped in the background
[04:29:50 CET] <ItWasntM_> share your command if you have one funyun
[04:30:04 CET] <ItWasntM_> should be easy to set your audio to loop
[04:51:01 CET] <RossW> is there a way to tell ffmpeg to use (request, negotiate, whatever) a higher bitrate (quality) from an RTSP source (camera)?
[05:37:02 CET] <ZeroWalker> hmm, okay i seems to somewhat be able to encode2 now, but i don't get the package system. cause i tell it to encode a frame, but it doesn't (got_package == 0), so i just do a while loop till it gets a package, which seems to happen after 51 loops. what's the point of that, can't i just request an encode and it will wait till it's done?
[10:05:40 CET] <LongWork> if i want to create a file with an hevc bistreamed binary content, is this the right ffmpeg command :  ffmpeg -i test.mp4 -c:v copy -bsf:v hevc_mp4toannexb test.ts ?
[10:11:44 CET] <JEEB> LongWork: I think that bsf:v might be automated now with latest FFmpeg
[10:40:35 CET] <NaGeL> hello. I'm trying to compile ffmpeg on my ubuntu 14.04.1 server with the folowing command: PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure   --prefix="$HOME/ffmpeg_build"   --pkg-config-flags="--static"   --extra-cflags="-I$HOME/ffmpeg_build/include"   --extra-ldflags="-L$HOME/ffmpeg_build/lib"   --bindir="$HOME/bin"   --enable-gpl   --enable-libass   --enable-libfdk-aac   --enable-libfreetype
[10:40:35 CET] <NaGeL> --enable-libmp3lame   --enable-libopus   --enable-libtheora   --enable-libvorbis   --enable-libvpx   --enable-libx264   --enable-libx265   --enable-nonfree   --enable-openssl   --enable-gnutls
[10:40:44 CET] <NaGeL> but it fails on this:
[10:40:54 CET] <NaGeL> ERROR: gnutls not found using pkg-config
[10:41:07 CET] <NaGeL> I installed gnutls with apt-get install gnutls-bin
[10:41:12 CET] <NaGeL> so its instaled
[10:41:36 CET] <NaGeL> i need that becouse of https support and openssl alone doesnt work sadly :(
[10:42:12 CET] <JEEB> you need the dev package for actually developing/building thigns against something
[10:42:40 CET] <JEEB> hint: it should have a similar name but ending with -dev :P
[10:51:01 CET] <NaGeL> there is no dev package of it....
[11:03:40 CET] <ben___> hi, I'm trying to use the ffmpeg libs to do simple livestreaming. I want to produce h264 and wrap it in mkv. Can anyone recommend a good tutorial on how to do this? So far I've only found tutorials on decoding videos.
[11:10:27 CET] <NaGeL> JEEB, cant find any dev packages :(
[11:10:35 CET] <NaGeL> or at least not ones that work :(
[11:19:46 CET] <ben___> To be a more precise: I'm stuck on setting the right timebases both on the encoder and muxer. Somehow my mkv-output says it has a framerate of 1k, and I have no idea why. Working source code would also help a lot (already checked the muxing.c example from ffmpeg)
[14:39:10 CET] <xeche> anybody remember what avcodec_parameters_from_context replaced?
[14:39:40 CET] <xeche> having to work with an ancient ffmpeg build (2.4) because of distro
[14:40:12 CET] <xeche> except for the codec parameter stuff, I think the API usage is mostly the same in 2.4 and 3.1 though
[15:06:52 CET] <DHE> xeche: just using the AVStream->codec field for the parameters
[17:41:37 CET] <shincodex> I want to static link all av librarys to have microsoft linker perform further optimization
[17:41:47 CET] <shincodex> But LGPL foolishly say taht only dll use
[17:41:57 CET] <shincodex> where to have written permission for static link
[17:45:03 CET] <nido_> "You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: d) Do one of the following:  0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and unde
[17:45:51 CET] <nido_> what probably also works is to not distribute the binaries
[17:45:54 CET] <shincodex> That is kinda hard to read
[17:46:15 CET] <shincodex> What do you mean not distrubute binaries
[17:46:17 CET] <nido_> that's licenses for you. written for lawyers rather then people
[17:46:24 CET] <shincodex> (yes)
[17:46:34 CET] <shincodex> a exe is a binary
[17:46:39 CET] <shincodex> a dll is one sorta
[17:46:39 CET] <nido_> i mean you compile however you like to, then you don't give the resulting binaries to other peopel but keep them for yourself only
[17:46:41 CET] <shincodex> reall a so is
[17:46:58 CET] <shincodex> Whoa what
[17:47:07 CET] <shincodex> I compile as static and dont give it out?
[17:47:09 CET] <shincodex> the hell?
[17:47:14 CET] <shincodex> Teh whole point is to give it out
[17:47:17 CET] <shincodex> or do you mean the source
[17:48:15 CET] <nido_> i have no idea what yuor plan was; but you said you want to static link for some reason; i figured it was for your own use
[17:48:43 CET] <shincodex> Nope.
[17:48:49 CET] <shincodex> here is all in one exe
[17:49:01 CET] <shincodex> there is no about box
[17:49:02 CET] <shincodex> but if you like
[17:49:10 CET] <shincodex> exe --about
[17:49:24 CET] <shincodex> blah blah blah ffmpeg here is where you can find owner in his apartment blah blah blah
[17:50:59 CET] <nido_> I dont understand. whats with the 'about box'? and if you're gonna statically link avcodec and have a problem with lgpl im guessing you dont want to link it with any foss code ( includnig ffmpeg itself)?
[17:51:21 CET] <shincodex> only static link 3? av libraries
[17:51:31 CET] <shincodex> sws scale i think is another
[19:00:43 CET] <faLUCE> I don't understand if this is a missing feature of ffplay. I receive a real time audio+video mpegts stream through HTTP, captured with a web camera. The video framerate is variable, and if it's low, then ffplay increases the latency when playing the stream, in order to keep synced audio and video. But when the video framerate increases, and it goes to 25, the previous latency is not automatically decreased by ffplay, and
[19:00:45 CET] <faLUCE> if I want to see the stream with no-latency, I have to stop and start again ffplay. Why?
[19:17:17 CET] <alexpigment> does anyone know how to compile ffmpeg for mac with 10-bit h.265?
[19:17:33 CET] <JEEB> decoding comes out of the box, `brew install ffmpeg` should do it
[19:17:48 CET] <alexpigment> 10-bit hevc encoding
[19:17:49 CET] <JEEB> for encoding you will need to build libx265 and enable it in the configure
[19:18:04 CET] <JEEB> (plus remember to enable the high bit depth mode in libx265's configuration)
[19:18:29 CET] <alexpigment> so i put "--with-x265" and "--with-10-bit" on the build parameters. i take it you're saying that isn't enough
[19:19:47 CET] <JEEB> I have no idea to which that latter thing points
[19:20:05 CET] <JEEB> you can check if 10bit libx265 is linked against your FFmpeg by checking `ffmpeg -h encoder=libx265`
[19:20:17 CET] <JEEB> that should output the capabilities as far as pixel formats go
[19:20:22 CET] <JEEB> that should include yuvXXXp10
[19:20:30 CET] <JEEB> the *p10* being the important bit
[19:20:36 CET] <JEEB> which means it's 10bit
[19:20:56 CET] <alexpigment> yeah, it's only doing 8
[19:21:29 CET] <JEEB> then you'll have to dig further and make sure relevant things got rebuilt
[19:21:33 CET] <alexpigment> i guess what i'm wondering is if doing this through brew install ffmpeg [params] is possible
[19:21:35 CET] <JEEB> rebuild libx265 and FFmpeg
[19:21:48 CET] <alexpigment> and if not, do i need to use xcode or something?
[19:21:50 CET] <JEEB> then make sure that `which ffmpeg` shows the right ffmpeg tool
[19:21:55 CET] <JEEB> no, no need for xcode
[19:22:31 CET] <alexpigment> so just rebuild it with the same parameters?
[19:22:41 CET] <alexpigment> i'm confused about what rebuilding it will do
[19:23:40 CET] <JEEB> in case you switched params for libx265 or FFmpeg
[19:23:47 CET] <JEEB> and it didn't auto-rebuild FFmpeg where needed
[19:23:53 CET] <relaxed> alexpigment: my builds have 10bit support, http://johnvansickle.com/ffmpeg/
[19:23:55 CET] <JEEB> (for the updated components to show u)
[19:24:21 CET] <relaxed> oh, mac
[19:24:35 CET] <alexpigment> relaxed: yeah, i did windows last week
[19:24:37 CET] <alexpigment> doing mac this week
[19:24:47 CET] <alexpigment> but i do appreciate the link to your builds
[19:28:45 CET] <relaxed> alexpigment: you should be able to build libx265 with both 8, 10, and 12bit support. See x265/build/linux/multilib.sh
[19:30:44 CET] <JEEB> I think libx265 if you don't want the 8bit only optimizations should be able to build one library that can encode 8-10bit
[19:30:49 CET] <JEEB> unlike libx264
[19:31:01 CET] <JEEB> the multilib is only needed IFF you want the 8bit only optimizations
[19:31:41 CET] <furq> alexpigment: looks like you should be able to build x265 with --with-16-bit and then rebuild ffmpeg
[19:31:44 CET] <furq> with brew
[19:32:19 CET] <JEEB> right, that's why I wanted to note what the "--with-10-bit" parameter meant
[19:32:22 CET] <JEEB> that ne mentioned
[19:32:43 CET] <JEEB> because libx265's cmake parameter is 16bit
[19:32:55 CET] <furq> yeah i figured that was for x264
[19:36:39 CET] <bencc1> when encoding h264 ffmpeg use the following cpu features on my server: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[19:36:52 CET] <bencc1> are there other features I need to consider when choosing my next server?
[19:37:21 CET] <furq> clock speed?
[19:38:54 CET] <alexpigment> sorry back. thanks for the info guys. i'm going to try the --with-16-bit option. i had seen "--with-10-bit" option on a forum post somewhere. as you guys probably know, there is a lot of useful ffmpeg information randomly in small corners of the internet, but it's littered with just as much misinformation. i guess that's the case with any obscure subjects
[19:38:58 CET] <furq> haswell and up have avx2 but i don't think that's really a huge deal
[19:39:15 CET] <furq> and i'm not aware of anything newer which makes any difference
[19:40:39 CET] <alexpigment> bencc1: i presume you're wanting x264 rather than a hardware solution like NVENC or QuickSync?
[19:41:26 CET] <furq> well that message comes from libx264, so i assume so
[19:54:49 CET] <ChocolateArmpits> I have a single input that can only be called once. What protocol should be used to restream the contents back to localhost so that multiple other ffmpeg processes can pick it up, basically multiplying the same single source? I can't use tee for this.
[20:07:57 CET] <furq> i take it you can't use multiple outputs either
[20:08:58 CET] <ChocolateArmpits> well in case some of the processes crash I don't want them taking out others
[20:09:19 CET] <ChocolateArmpits> Like a destination ending connection
[20:10:27 CET] <furq> i'm not sure if any protocols support multiple clients without using an external server
[20:59:05 CET] <zipnine> Hi all!
[20:59:48 CET] <zipnine> How do you manage/maintain multiple ffmpeg programs?
[21:00:34 CET] <JEEB> in what sense?
[21:00:40 CET] <zipnine> I know I can create a script and run them in the background but I want to catch any errors or have an convenient place to view all the running threads. Just curious what everyone is doing.
[21:01:17 CET] <zipnine> JEEB: I need to transcode 10 incoming (live) streams and want to monitor them in case they have errors or crash.
[21:02:15 CET] <JEEB> the simplest thing is to write a service file for systemd for each of them, and log stderr
[21:02:26 CET] <JEEB> that also enables automated restart in case of crash or exit
[21:02:58 CET] <llogan> or use the fifo muxer to enable recovery of the output in case of disconnection/failure
[21:03:08 CET] <zipnine> okay. got it.
[21:03:10 CET] <zipnine> what
[21:03:28 CET] <zipnine> what's fifo muxer? I'll check the man pages.
[21:03:35 CET] <zipnine> err not man..docs.
[21:03:37 CET] <llogan> http://ffmpeg.org/ffmpeg-formats.html#fifo
[21:04:01 CET] <llogan> it can be a little confusing to use...especially if you use it with the tee muxer
[21:33:39 CET] <ZeroWalker> anyone know why encode2 doesn't always return a package? http://sprunge.us/bBBA
[21:34:54 CET] <BtbN> because it doesn't have to.
[21:35:07 CET] <BtbN> With reordering and delay for lookahead
[21:35:59 CET] <JEEB> ZeroWalker: you keep feeding it frames and at some point it will return some packets. and then at the end you will have to "flush" the encoder so that no more packets come out
[21:38:40 CET] <ZeroWalker> wait so when you flush, you will get all the frames?
[21:39:04 CET] <ZeroWalker> but is it possible to make it instant, cause latency is the key in my case
[21:39:31 CET] <kepstin> ZeroWalker: if you want to reduce delay, you need to change encoder or encoder settings to reduce delay
[21:39:32 CET] <ZeroWalker> i get quality will be reduced cause of it
[21:39:47 CET] <ZeroWalker> but can i make it sleep till the frame is done?
[21:39:51 CET] <kepstin> ZeroWalker: e.g. with libx264, use "tune=zerolatency" option. And yes, it will reduce quality
[21:40:37 CET] <ZeroWalker> cause i would like to Encode, then after that the frame is done and i do something with it etc
[21:40:41 CET] <ZeroWalker> ah yeah that one
[21:42:00 CET] <kepstin> ZeroWalker: the normal usage is you just push frames into the encoder, and it eventually starts giving you frames back. You then flush when done (give it "NULL" frames) until the encoder stops returning encoded frames.
[21:43:25 CET] <ZeroWalker> hmm, kinda confusing, but then again not used to this kind of async methods
[21:44:11 CET] <kepstin> x264, depending on options, can buffer as much as 250 frames in memory before it starts giving you encoded frames.
[21:44:39 CET] <ZeroWalker> ah
[21:45:08 CET] <kepstin> (the "zerolatency" option switches it into a strict 1-frame-in’1-frame-out mode, with noticable quality loss)
[21:47:57 CET] <ZeroWalker> ah well then that's what i want probably in my case.
[21:48:32 CET] <ZeroWalker> hmm, isn't the x264 options done specially in ffmpeg, trying to find it, not sure if it's the AVDictionary or
[21:49:53 CET] <DHE> you can use the standard AVCodecContext settings where they have obvious x264 equivalents, or you can use the AVDictionary to submit them like you would ffmpeg command-line parameters
[21:50:24 CET] <ZeroWalker> but tune and preset is one of those that aren't there right?
[21:50:40 CET] <DHE> and of course you can use av_dict_set(&dict, "x264opts", "no-scenecut:frameref=5:....", 0);
[21:50:44 CET] <ZeroWalker> cause looking at it now, i think you need to do some weird stuff
[21:50:48 CET] <DHE> and say "screw it" to the whole standard
[21:51:35 CET] <ZeroWalker> ah, hmm that might be easier as i am used to the command lines
[21:53:10 CET] <ZeroWalker> or wait maybe not if it comes to defining the pixel formats
[21:54:14 CET] <DHE> also I believe x264 doesn't accept tune, profile or preset from x264opts, but ffmpeg will eat them properly if used as av_dict_set(&dict, "profile", "baseline", 0);
[21:54:39 CET] <JEEB> x264-params is the thing that pushes stuff straight into libx264
[21:54:50 CET] <JEEB> x264opts is something that should be killed off to be honest
[21:54:58 CET] <JEEB> since it just has its own parser and all that jazz
[21:55:28 CET] <JEEB> x264-params also has a variant with libx265 with x265-params
[21:59:48 CET] <llogan> JEEB: i see no reason for both. does x264opts have any advantage over x264-params?
[22:00:11 CET] <JEEB> no
[22:00:25 CET] <JEEB> x264-params was added because x264opts was half-assed originally
[22:00:53 CET] <llogan> will you submit a patch removing x264opts?
[22:01:43 CET] <JEEB> hmm, might even do that
[22:02:10 CET] <JEEB> although FFmpeg generally only loses features when people don't notice. like the chinese HLS muxer guy
[22:02:19 CET] <JEEB> who just pushes his removals of options etc
[22:02:44 CET] <JEEB> but yeah, I guess it's worth a try :P
[22:03:10 CET] <llogan> i'll push it if there are no insane objections
[22:03:19 CET] <llogan> *sane
[22:04:02 CET] <llogan> while you're at it can you merge the prores' too?
[22:04:18 CET] <JEEB> and yeah, I just checked what x264opts does in my local repo and it still does the same thing it did before
[22:04:31 CET] <JEEB> so I will post a patch to remove it telling people to use x264-params instead
[22:04:58 CET] <llogan> thanks
[22:05:17 CET] <JEEB> as it seems like it's just setting AVOptions by itself or something (why would you even...)
[22:05:48 CET] <JEEB> while x264-params uses x264_params_parse
[22:09:52 CET] <llogan> i purged it from the 264 wiki page
[22:10:43 CET] <ZeroWalker> so, i should use x264-params;o?
[22:11:16 CET] <JEEB> you can use the avcodec options or x264-params
[22:11:33 CET] <JEEB> avcodec options open some things (I'd say, most things) on the avcodec side
[22:11:54 CET] <JEEB> but x264-params lets you pass things straight to libx264 as key=value pairs
[22:12:19 CET] <ZeroWalker> does avcodec support tune, preset?
[22:12:36 CET] <JEEB> yes
[22:12:44 CET] <JEEB> those are normal avcodec options for the libx264 encoder
[22:12:54 CET] <llogan> you can see a list: ffmpeg -h encoder=libx264
[22:13:10 CET] <DHE> AVCodecContext->profile is a field
[22:19:15 CET] <JEEB> or wait
[22:19:38 CET] <JEEB> llogan: am I reading this incorrectly because it seems like encoders.texi is talking of it as if it does the same thing as x264-params
[22:21:16 CET] <JEEB> yea... I don't see it actually touching x4->params
[22:22:30 CET] <JEEB> so either the documentation is lying out of its arse or I can't see it happening with OPT_STR
[22:22:59 CET] <llogan> I don't know if I would trust documentation that states, "They accept it as well since long ago but this is kept undocumented for some reason."
[22:23:53 CET] <JEEB> because what I remember is that x264opts tried to emulate that hard by just adding avoptions with similar names
[22:24:05 CET] <JEEB> and that would match with OPT_STR
[22:24:18 CET] <JEEB> oh
[22:24:29 CET] <JEEB> should have looked at the definition of that macro
[22:24:34 CET] <JEEB> d'uh
[22:25:09 CET] <JEEB> much less obvious than the x264-params thing, but seems to do primarily the same darn thing :V
[22:26:07 CET] <llogan> we still don't need two
[22:27:12 CET] <JEEB> you can bet someone will raise a whirlwind because the documentation mentions x264-params coming from Libav
[22:27:16 CET] <JEEB> but yeah, I agree
[22:27:23 CET] <JEEB> and x264-params and x265-params are a pair
[22:27:36 CET] <furq> can you set creation_time with ffmpeg when muxing an mp4
[22:28:00 CET] <llogan> we can just remove that Libav line since it will be moot
[22:28:24 CET] <llogan> and +1 on the name pairing
[22:29:20 CET] <llogan> furq: i believe so. -metadata creation_time now
[22:29:25 CET] <llogan> =now
[22:29:39 CET] <furq> neat
[22:29:54 CET] <llogan> creation_time=$(date +%FT%T%z) or whatever
[22:30:31 CET] <furq> now is fine
[22:31:05 CET] <llogan> check that it works. iirc it used to set some oddball time, but it was fixed i think. i can't remember.
[22:31:09 CET] <furq> yeah i am doing
[22:31:28 CET] <furq> i have a bunch of videos going to google photos and it sets the date on them to the mp4 creation_time
[22:31:41 CET] <furq> which i don't care about, i just want them to be in order
[22:32:12 CET] <furq> i would just use mp4box but that's bailing out on some of these files
[22:32:34 CET] <furq> cue JEEB throwing up in his mouth a little bit
[22:33:20 CET] <llogan> humperdinck!
[22:33:28 CET] <furq> creation_time   : 2017-03-06T21:30:27.000000Z
[22:33:29 CET] <furq> perfect
[22:33:30 CET] <furq> thanks
[22:33:54 CET] <llogan> i wonder if "now" is documented...
[22:40:26 CET] <JEEB> furq: GPAC is awful but I do understand that L-SMASH's tooling doesn't yet handle all of the cases that mp4split et al handle
[22:41:49 CET] <furq> can l-smash set (or just remove) creation_time
[22:44:11 CET] <furq> i already have it installed for boxdumper but i'm not japanese enough to find the docs
[22:45:22 CET] <JEEB> I can't see a specific option for it but you could try running remuxer through a file and see if it overrides that or not (possibly not since remuxer might have been made with the idea of minimizing changes)
[22:45:28 CET] <JEEB> muxer most likely does set the value, though
[22:45:35 CET] <JEEB> API-wise it most likely does it
[22:45:59 CET] <furq> i'll have a look next time i've got a batch to remux
[22:46:06 CET] <furq> i'm already halfway through doing it with mp4box/ffmpeg now
[22:46:17 CET] <JEEB> makes sense
[22:46:37 CET] <JEEB> anyways, because the biggest users of L-SMASH are API users the tools aren't bad but limited :D
[22:46:41 CET] <furq> or "MP4Box" since i'm on debian
[22:46:58 CET] <JEEB> that's the actual binary name in GPAC
[22:47:03 CET] <JEEB> they love their CamelCase tools
[22:47:17 CET] <furq> yeah but freebsd (hopefully amongst others) has the good sense to rename it to mp4box
[22:47:57 CET] <furq> which of course meant i tried mp4box first on debian and it didn't work, and then i tried MP4Box first on freebsd and it didn't work
[22:49:04 CET] <JEEB> sounds like when I learned to drive I started with the truck but my first test was on a normal vehicle. there I got told that I was driving it just like a truck. and then the things reversed and I got told that I was driving the truck a bit like a normal car
[22:49:32 CET] <furq> i was thinking more like a usb a connector, but that works too
[22:52:09 CET] <alexpigment> does the concept of shared vs static ffmpeg apply on OS X, or is that just a Windows thing?
[22:52:50 CET] <JEEB> it applies to OS X just fine as well, only relevant if you're building FFmpeg to link against it in your own application
[22:52:55 CET] <JEEB> as in, using the libav* APIs
[22:53:48 CET] <ZeroWalker> when using stuff like av_frame_alloc, can one just reuse it with just changing the data?
[22:55:22 CET] <alexpigment> JEEB: so if i'm building it via brew install ffmpeg, do you know the parameter that makes it a shared library?
[22:55:30 CET] <JEEB> no fscking idea
[22:55:48 CET] <alexpigment> k. i looked through the help but couldn't find anything. i'll keep googling. thanks
[22:59:17 CET] <newbie_> Does anyone have any reading material on how frames, samples etc are working?
[23:03:07 CET] <kepstin> ZeroWalker: you should only change stuff in the frame if it's not referenced in multiple places (i.e. reference count is 1 and you hold the only reference). You should consider using a buffer pool (from libavutil/buffer.h) as an allocator and just allocate new buffers each time, which will be recycled automatically.
[23:04:12 CET] <bencc1> alexpigment: yes
[23:06:02 CET] <alexpigment> bencc1: do you happen to know what the parameter is? in other words, what do i type after brew install ffmpeg --[shared vs static toggle]
[23:08:54 CET] <Tatsh> hi, converting and encoding an old xvid file
[23:08:56 CET] <Tatsh> [mpeg4 @ 0xc63060] Video uses a non-standard and wasteful way to store B-frames ('packed B-frames'). Consider using the mpeg4_unpack_bframes bitstream filter without encoding but stream copy to fix it.
[23:09:03 CET] <Tatsh> is this a warning i can ignore?
[23:10:07 CET] <JEEB> yes
[23:10:34 CET] <JEEB> it's trying to guilt-trip you because b-pictures in AVI are an abomination
[23:10:56 CET] <JEEB> (as AVI is an ooold container and really doesn't lend itself well to the whole b-picture thing :P)
[23:13:56 CET] <faLUCE> which is the equivalent option of gop_size for audio encoding?
[23:14:50 CET] <kepstin> faLUCE: doesn't make sense which how most audio codecs operate.
[23:15:04 CET] <JEEB> not sure any audio encoders let you set the frame size
[23:15:08 CET] <JEEB> but that would be the only thing
[23:15:17 CET] <kepstin> well, opus does, but other than that...
[23:15:51 CET] <bencc1> alexpigment: no, sorry
[23:16:10 CET] <kepstin> I don't think ffmpeg's libopus wrapper exposes that, though.
[23:17:41 CET] <kepstin> faLUCE: audio codecs generally encode fixed size frames (X samples per frame), and you can decode starting at any frame (usually with a delay - you get back audio starting at some point slightly after where you started decoding)
[23:18:41 CET] <faLUCE> kepstin: I see. Then I don't understand why ffplay adds some delay before decoding a http mpegts audio-only LIVE stream
[23:20:34 CET] <kepstin> faLUCE: I'd assume most of the delay is just tcp connection setup and network buffering...
[23:20:40 CET] <JEEB> llogan: sent the patches
[23:20:45 CET] <JEEB> now waiting for the pop corn response
[23:21:50 CET] <faLUCE> kepstin: I'm doing all 127.0.0.1... If I stream an audio file with "ffmpeg -i AVLibMP2File.mp2 -listen 1 -acodec copy -f mpegts http://localhost:8080/stream.ts" I don't have any delay
[23:22:36 CET] <faLUCE> is there a way to debug what is ffplay doing during the delay ?
[23:22:40 CET] <Tatsh> JEEB, i know
[23:22:42 CET] <Tatsh> it's long since that time though
[23:22:49 CET] <faLUCE> I tried -v debug, but it did not give me useful infos
[23:22:53 CET] <Tatsh> 10+ years where everyone thought xvid was cool
[23:23:38 CET] <Tatsh> it's too bad almost nothing supports mpeg-4 part 2 natively
[23:24:35 CET] <JEEB> my sony console from 2005 supported mpeg-4 part 2 in isobmff
[23:25:21 CET] <furq> that sure is a weird way to say "psp"
[23:25:22 CET] <Tatsh> so did mine
[23:25:26 CET] <Tatsh> my xbox 360 too
[23:25:36 CET] <Tatsh> both ps3 and xbox 360 supported it after updates
[23:26:02 CET] <TD-Linux> that's a weird way to say "luckily"
[23:26:42 CET] <Tatsh> JEEB, was that a psp with hardware support?
[23:26:47 CET] <JEEB> yes
[23:26:52 CET] <Tatsh> interesting, i had no idea they did that
[23:26:56 CET] <JEEB> it had an ASIC for mpeg-4 part 2 and AVC
[23:27:11 CET] <Tatsh> ios has AVC and now HEVC but no mpeg-4 part 2
[23:27:17 CET] <alexpigment> didn't most dvd players in the 2000s support MPEG-4 Part 2 (i.e. XviD or DivX logos on the front)?
[23:27:23 CET] <Tatsh> not most, a bunch did
[23:27:30 CET] <Tatsh> but not the top brands like Sony, JVC, etc
[23:27:44 CET] <JEEB> Tatsh: I'm pretty sure there's a part 2 ASIC there on the iDevices as well, just no interfaces
[23:27:53 CET] <JEEB> just like the HEVC interfaces have been quietly removed
[23:27:54 CET] <Tatsh> most of the brands you never heard of would randomly support things like DivX (or what they really mean)
[23:28:23 CET] <Tatsh> they also tended to support VCD despite virtually non-existence of commercial VCDs in the US
[23:28:44 CET] <JEEB> I actually have a single 100% official and fuck-expensive VCD
[23:28:52 CET] <alexpigment> Tatsch: I think it was more openly and widely supported than that. Not just osbscure chinese brands. (context: i visit goodwill every week to look for electronics. i see that logo on high-end stuff)
[23:28:57 CET] <Tatsh> hehe and it's not from Japan or China?
[23:29:04 CET] <JEEB> neither of those
[23:29:18 CET] <Tatsh> i have some DivX 'DVDs' that are unplayable
[23:29:21 CET] <JEEB> also did VCD ever become something in Japan, they went for DVD pretty quickly
[23:29:28 CET] <JEEB> and before that laserdisc
[23:29:30 CET] <Tatsh> i don't think it ever really took off
[23:29:33 CET] <Tatsh> because laserdisc
[23:29:34 CET] <TD-Linux> I remember making a VCD when I got my first CD burner
[23:29:37 CET] <alexpigment> i think VCD only took hold in China tbh
[23:29:52 CET] <Tatsh> VCD was a cheap alternative in china for some reason, probably because of easier pirating
[23:29:54 CET] <TD-Linux> and then never again because MPEG-1 at 240p
[23:29:56 CET] <alexpigment> because japan cared about quality and VCD's quality was pretty awful
[23:29:57 CET] <JEEB> TD-Linux: well yea d'uh, my first back-ups of animoo were VCDs as well
[23:30:04 CET] <JEEB> and yes, after that never again
[23:30:06 CET] <Tatsh> then SVCD came out and fixed almost nothing
[23:30:41 CET] <TD-Linux> JEEB, laserdisc animu is where it's at
[23:30:44 CET] <Tatsh> i did backup a number of my DVDs to VCD way back when
[23:30:52 CET] <Tatsh> pretty normal to reduce to the lesser size as a backup
[23:31:12 CET] <Tatsh> and with a CRT TV you wouldn't care too much
[23:31:15 CET] <alexpigment> tatsh: it was poor decisions like that that made me have to re-rip a few hundred DVDs like that in the past year
[23:31:20 CET] <Tatsh> alexpigment, same
[23:31:28 CET] <Tatsh> i've re-ripped all mine
[23:31:40 CET] <Tatsh> a few i still have in xvid because i don't have the disc here
[23:31:49 CET] <furq> ironically enough all my dvds are backed up in china now
[23:31:53 CET] <Tatsh> i have like almost 100 films in my storage unit
[23:31:54 CET] <Tatsh> dvd
[23:32:14 CET] <Tatsh> but yeah i think VCD only took in china because piracy :P
[23:32:24 CET] <furq> and price
[23:32:43 CET] <alexpigment> yeah, CDs were cheap, and if you didn't care about quality, then it was a pretty good format i suppose ;)
[23:32:50 CET] <Tatsh> once it was there in pirated form, legit prints were made and the distributors had no choice
[23:32:55 CET] <Tatsh> because everyone had a VCD player at home
[23:33:10 CET] <TD-Linux> I really want to burn a laserdisc but there's virtually no information on the sync encoding
[23:33:12 CET] <Tatsh> still today in china you can find pirated blu-ray so cheap
[23:33:18 CET] <furq> they're still somewhat popular in vietnam and places like that
[23:33:35 CET] <furq> TD-Linux: do you have an ld-r drive
[23:33:41 CET] <Tatsh> TD-Linux, burn a laser-disc? how?
[23:33:42 CET] <furq> or are you going to do it by hand
[23:33:46 CET] <TD-Linux> furq, no, it would be with a hacked fw CD burner
[23:33:55 CET] <furq> you'd have to hack more than the firmware
[23:34:09 CET] <Tatsh> laserdisc format is very unusual to me
[23:34:23 CET] <alexpigment> yeah, laserdisc is analog
[23:34:23 CET] <Tatsh> it's like a disc but then it's like a vinyl
[23:34:24 CET] <alexpigment> so...
[23:34:33 CET] <faLUCE> "ffmpeg -f alsa -i plughw:2,0 -listen 1 -acodec mp2 output.mp2"  <---- Unknown input format: 'alsa'   ..... what's wrong? I use 2.8.7
[23:34:39 CET] <Tatsh> faLUCE, update
[23:34:46 CET] <furq> you didn't build with alsa support
[23:35:09 CET] <furq> ffmpeg -devices
[23:35:22 CET] <Tatsh> good old days with the hacked mpeg-4 codec from MS, then DivX, then XviD took over
[23:35:25 CET] <kepstin> huh, I thought laserdisc was pcm-encoded composite video, not analog?
[23:35:35 CET] Action: kepstin doesn't really know tho :)
[23:35:51 CET] <alexpigment> no, the audio could be digital on later releases, but the laserdisc video itself was always analog
[23:36:07 CET] <Tatsh> that was a big deal because most VHS decks didn't even support Dolby anything
[23:36:24 CET] <Tatsh> and even for VHS, very few films came with high quality audio, even hi-fi was relatively rare
[23:36:26 CET] <faLUCE> ok thnks
[23:36:37 CET] <Tatsh> where hi-fi means stereo
[23:36:44 CET] <alexpigment> i have some really high end VHS decks at home from doing A>D conversions. i don't know if they did anything crazy with audio
[23:36:45 CET] <furq> faLUCE: install libasound2-dev before rebuilding if you're on a debian-alike
[23:36:57 CET] <Tatsh> most TVs in the US at that time were mono anyway
[23:37:05 CET] <Tatsh> alexpigment, same here
[23:37:08 CET] <alexpigment> tatsch - if you're talking about when laserdisc first came out, then yeah
[23:37:08 CET] <Tatsh> but i have at least a hum remover
[23:37:17 CET] <alexpigment> i actually have an HD VCR
[23:37:23 CET] <alexpigment> and one or two tapes
[23:37:25 CET] <TehEpikDuckeh> Hey guys, having an issue using "hevc_cuvid" and encoding to h264 using "h264_nvenc". I get the error as follows: "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height"
[23:37:31 CET] <furq> is that d-vhs
[23:37:38 CET] <Tatsh> i have one deck for A-D and a TBC
[23:37:38 CET] <alexpigment> yep
[23:37:42 CET] <Tatsh> and a hum remover
[23:37:59 CET] <furq> you should get a vhd player as well
[23:38:00 CET] <alexpigment> teh: yeah i think you have to specific another parameter like -look_ahead 0 or something
[23:38:06 CET] <kepstin> huh, so laserdisc is encoded with pulse-width-modulation representing the analog signal. neat.
[23:38:07 CET] <alexpigment> lemme see if i have that error in my notes
[23:38:14 CET] <TehEpikDuckeh> Sorry, let me send you the commands I used.
[23:38:32 CET] <Tatsh> i use the happauge ImpactVCB-e for capturing
[23:38:45 CET] <faLUCE> furq: all done. Well, I just checheck that in LOCALHOST, if I do:  "ffmpeg -f alsa -i plughw:2,0 -listen 1 -acodec mp2 -f mpegts http://localhost:8080/stream.ts" and try to receive the stream with ffplay, ffplay has a delay of some seconds.  Is there a way to reduce this delay ?
[23:38:50 CET] <alexpigment> tatsh - yeah i have several TBC VCRs, panasonic and JVC
[23:38:55 CET] <furq> shrug
[23:39:01 CET] <Tatsh> in general i spent about $600 for AD conversions for my VHS
[23:39:05 CET] <alexpigment> tehepikduckeh: lay it on me
[23:39:20 CET] <TehEpikDuckeh> alexpigment: Alright, here's the paste: http://pastebin.com/n9tfv96e
[23:39:24 CET] <feliwir> i read everywhere that a vp6 decoder is easy, but it is pretty difficult :(
[23:39:25 CET] <Tatsh> is there such a thing as playing a VHS at like 4x the speed and capturing it?
[23:39:29 CET] <TehEpikDuckeh> alexpigment: The command is first line.
[23:39:39 CET] <Tatsh> like, if you play a tape at 4x speed (~120 FPS) and record at 120 FPS
[23:39:40 CET] <faLUCE> if I stream a file, there's not any delay when receiving it
[23:39:47 CET] <Tatsh> i'm just wondering if such equipment exists
[23:39:55 CET] <feliwir> i am trying to write on in C# but Huffman, IDCT and so on is very complicated
[23:40:12 CET] <TehEpikDuckeh> Tatsh: I think that'd give you 4 different frames per frame, because of how VHS reads the tape.
[23:40:23 CET] <Tatsh> yeah that's the problem
[23:40:26 CET] <TehEpikDuckeh> Tatsh: ... that'd be if you were going at 120 fps.
[23:40:28 CET] <Tatsh> but how did mass copying work for VHS?
[23:40:34 CET] <kepstin> Tatsh: theoretically possible, but i doubt anyone has actually made equipment for it, other than maybe high-speed tape dubbers.
[23:40:37 CET] <Tatsh> did they really just play one source to 50 VCRs at the same speed?
[23:40:44 CET] <TD-Linux> furq, biggest question is if CLV mode will even accept the pregroove spacing
[23:40:47 CET] <Tatsh> at realtime speed *
[23:40:59 CET] <feliwir> can anyone take a look if this is a good approach i am going: https://github.com/feliwir/sage/tree/bb22a8e6a62b0f1cbe4383048d430394ffb5dc77/vp6
[23:41:04 CET] <furq> i thought the biggest question would be how you fit the disc into a cd drive
[23:41:28 CET] <Tatsh> TD-Linux, how do you trick your drive into thinking it's a writable disc?
[23:41:32 CET] <furq> after all, there's a sticker that says not to take the cover off the drive
[23:41:33 CET] <TehEpikDuckeh> Tatsh: I don't know where you live exactly, but you may be able to request the movie/tv show from your local library and rip it. Since it's the same content as VHS, it shouldn't be illegal.
[23:41:37 CET] <furq> you wouldn't want to run afoul of a sticker
[23:41:42 CET] <TD-Linux> furq, well I'd make a smaller than normal LD. written from the inside out
[23:41:51 CET] <Tatsh> TehEpikDuckeh, these are home movies not professional film
[23:42:03 CET] <Tatsh> for any of that, i've either bought the dvd or digital
[23:42:13 CET] <TehEpikDuckeh> Tatsh: I see. It'd probably be best to record it at normal speeds.
[23:42:13 CET] <Tatsh> dvd/bluray/digital
[23:42:28 CET] <TD-Linux> Tatsh, copying machines can go faster than realtime, but basically yes
[23:42:54 CET] <kepstin> interesting, wikipedia suggests that 12 cm LD was actually something that exists
[23:42:56 CET] <TehEpikDuckeh> Tatsh: If it's really important, then you wouldn't want to tape to be damaged. Even though you can fix it, it's not worth it.
[23:43:09 CET] <furq> https://upload.wikimedia.org/wikipedia/commons/5/53/CRVDisc.jpg
[23:43:11 CET] <furq> oh
[23:43:16 CET] <furq> i guess there are writable laserdiscs
[23:43:25 CET] <alexpigment> tehepikduckeh: try adding a few parameters. e.g. /var/lib/emby-server/ffmpeg/test/ffmpeg-git/ffmpeg -c:v hevc_cuvid -i /media/HDD/Movies/Whiplash.mkv -c:v h264_nvenc -global_quality 20 -preset slow -profile:v high -level 4.1 -c:a copy test.mkv
[23:43:41 CET] <furq> https://upload.wikimedia.org/wikipedia/commons/thumb/1/1f/LaserRecorder.jpg/800px-LaserRecorder.jpg
[23:43:44 CET] <furq> TD-Linux: problem solved
[23:43:47 CET] <Tatsh> amazing concept
[23:43:48 CET] <furq> i'm sure those are very cheap now
[23:43:54 CET] <Tatsh> was laserdisc proposed as a general data storage format?
[23:43:56 CET] <TehEpikDuckeh> alexpigment: Hmmm, same exact error as before.
[23:44:01 CET] <TD-Linux> furq, yeah those are literal unobtanium
[23:44:06 CET] <TD-Linux> and also cheating
[23:44:30 CET] <Tatsh> alexpigment, so i guess you saw how horrible VHS quality really can be
[23:44:42 CET] <TehEpikDuckeh> alexpigment: There's no difference at all from the "[h264_nvenc @ 0x1f79e40] No NVENC capable devices found" to the "Error while ...".
[23:44:54 CET] <furq> Tatsh: looks like they were only used for video editing
[23:45:00 CET] <alexpigment> tehepikduckeh: are you sure cuvid and nvenc are supported on your ffmpeg build and also your hardware?
[23:45:01 CET] <TD-Linux> kepstin, on CLV you can see the hsync/vsync and scanlines https://people.xiph.org/~tdaede/pics/ld/20170129_0009.jpg
[23:45:10 CET] <TehEpikDuckeh> alexpigment: 100% sure.
[23:45:17 CET] <alexpigment> do you have recent drivers?
[23:45:20 CET] <TD-Linux> on a couple with scrolling credits you can actually read the credits with a microscope :)
[23:45:50 CET] <TehEpikDuckeh> alexpigment: It works just fine if I use CUVID and use software encoding, and works just fine w/ "h264_cuvid" to "hevc_nvenc".
[23:45:55 CET] <alexpigment> i had to update my nvidia drivers to something fairly recent to get it to work, as i recall. i tested on 600 > 1000 series cards
[23:46:06 CET] <TehEpikDuckeh> alexpigment: They are the latest NVIDIA drivers on Debian 8.
[23:46:11 CET] <alexpigment> ah debian
[23:46:11 CET] <TehEpikDuckeh> Direct from NVIDIA.
[23:46:12 CET] <Tatsh> haven't got nvenc to work yet
[23:46:23 CET] <alexpigment> i only have experience with NVENC on Win64
[23:46:27 CET] <TehEpikDuckeh> Let me tell you, NVENC wasn't fun when I first was having to compile things.
[23:46:35 CET] <Tatsh> haven't really tried it though; gentoo doesn't want to support building nvenc in
[23:46:36 CET] <kepstin> Tatsh: wikipedia says sony designed a data laserdisc that could hold >3gb.
[23:46:36 CET] <Tatsh> it seems
[23:46:46 CET] <Tatsh> so i have to use my own build
[23:47:11 CET] <TehEpikDuckeh> alexpigment: I tested this on my friends computer (Win 10), and he has a 1080. If I remember correctly, it worked immediately.
[23:47:21 CET] <Tatsh> was it epic?
[23:47:23 CET] <BtbN> Tatsh, setting the nvenc useflag is too much?
[23:47:47 CET] <TehEpikDuckeh> That 1080 transcoded at 478 fps.
[23:47:56 CET] <TehEpikDuckeh> 487 fps*
[23:48:07 CET] <Tatsh> BtbN, doesn't seem to work for me and i forget exactly what the syntax means when it has a % on the use flag
[23:48:13 CET] <alexpigment> tehepikduckeh: yeah, my 1060 is 300-500 depending on the settings. anyway, maybe there's another problem that i'm not aware of with debian or linux implementations
[23:48:20 CET] <BtbN> it means it's new.
[23:48:23 CET] <Tatsh> what about 4k?
[23:48:29 CET] <Tatsh> anyone tried 4k encoding with nvenc?
[23:48:36 CET] <alexpigment> yes
[23:48:39 CET] <alexpigment> it's also very fast
[23:48:49 CET] <alexpigment> MUCH faster than x264 or x265
[23:49:02 CET] <TehEpikDuckeh> alexpigment: No idea. I've even tried using the backport repository for GPU drivers, but nope.avi when it comes to working.
[23:49:06 CET] <alexpigment> in fact, i wish NVENC wasn't so limited, because x265 4K at 10-bit is SLOWWWWWWWW
[23:49:09 CET] <Tatsh> the major limitation though is like, no filters?
[23:49:13 CET] <kepstin> alexpigment: if it's faster than x264, you just don't have enough cpu cores ;)
[23:49:28 CET] <alexpigment> well, i've got 4/8 on this system
[23:49:48 CET] <alexpigment> but seriously, NVENC is extremely fast. if speed is your primary concern, i don't know why you'd use x264/x265
[23:49:59 CET] <TehEpikDuckeh> alexpigment: I think it depends on the card you use. Which card you have?
[23:50:03 CET] <furq> because speed isn't usually your primary concern
[23:50:04 CET] <alexpigment> 1060
[23:50:15 CET] <BtbN> The card doesn't matter. The generation does.
[23:50:17 CET] <TehEpikDuckeh> Should work just fine. Weird.
[23:50:18 CET] <alexpigment> furq: that was a bit of a joke, but you beat me to it
[23:50:22 CET] <Tatsh> i get pretty good speed with my intel 5930k overclocked to 4.2 GHz
[23:50:25 CET] <furq> yeah all the 10 series cards have the same nvenc asic
[23:50:29 CET] <TehEpikDuckeh> I ask which card as it's easier than thinking about generations and such.
[23:50:39 CET] <furq> maybe it'd make a difference to decoding but i can't imagine it'd be significant
[23:50:42 CET] <TehEpikDuckeh> Correcct furq
[23:51:15 CET] <TehEpikDuckeh> alexpigment: I'm going to try reinstalling the drivers from NVIDIA.
[23:51:53 CET] <alexpigment> tehepikduckeh - cool, good luck. i know i've seen the error you mentioned, and i want to say it was driver-related, but it's been a few weeks since i was knee-deep in hardware encoding research
[23:51:53 CET] <TehEpikDuckeh> I've asked about this on the Emby forum and someone said the following: "My guess would be that input-output pixel formats don't match and hardware conversion filter should be applied (that is pure speculation)."
[23:52:40 CET] <alexpigment> for what it's worth, i think qsv gives the same error if you don't specify -look_ahead 0
[23:52:42 CET] <TehEpikDuckeh> alexpigment: I can also try another build of FFmpeg. How should I go about it: build from source, or someone already have it built so I don't have to waste 15 minutes?
[23:52:46 CET] <alexpigment> so perhaps that's what i'm remembering
[23:53:10 CET] <TehEpikDuckeh> alexpigment: Where'd I put that at exactly in the command?
[23:53:11 CET] <alexpigment> i don't have a linux build
[23:53:41 CET] <alexpigment> tehepikduckeh - after the input file, but still, it's specify to intel quicksync. no need to test it on an nvidia machine
[23:53:52 CET] <TehEpikDuckeh> I get "Unrecognized option" whenever I use that.
[23:54:19 CET] <TehEpikDuckeh> Oh, I see. I wanted to use QSV because it's faster, but a 1050 is SOOO much cheaper than a new mobo/CPU.
[23:58:30 CET] <alexpigment> tehepikducken: they can't be used simultaneously either. so if you have an nvidia card, qsv is out
[23:58:43 CET] <alexpigment> at least that's how it is on windows
[23:59:05 CET] <TehEpikDuckeh> alexpigment: I tried that on my friends computer and saw an error. If I were to get compatible hw, I'd just use QSV.
[23:59:08 CET] <alexpigment> and qsv isn't fast in my experience, but then again i haven't tested skylake or newer
[00:00:00 CET] --- Tue Mar  7 2017