[Ffmpeg-devel-irc] ffmpeg-devel.log.20150402
burek
burek021 at gmail.com
Fri Apr 3 02:05:03 CEST 2015
[00:11:52 CEST] <wm4> jamrial: how do I do this programmatically again?
[00:14:01 CEST] <wm4> av_force_cpu_flags() I suppose
[00:14:20 CEST] <nevcairiel> i think there is a more obvious av_set_cpu_flags or something
[00:14:24 CEST] <nevcairiel> not sure
[00:14:34 CEST] <jamrial> ffmpeg -cpuflags 0?
[00:14:36 CEST] <wm4> av_set_cpu_flags_mask()
[00:14:49 CEST] <wm4> jamrial: it'd probably be hard to provoke this particular conversion in ffmpeg
[00:15:30 CEST] <jamrial> most fate tests seem to use av_force_cpu_flags
[00:16:39 CEST] <wm4> inserted av_force_cpu_flags(0); before creating a resample context; still happens
[00:17:29 CEST] <kierank> wm4: just move to avresample
[00:17:30 CEST] <kierank> it's in both
[00:17:31 CEST] <kierank> :)
[00:17:41 CEST] Action: kierank renames today april trolls
[00:18:02 CEST] <nevcairiel> should be possible to do this conversion with ffmpeg CLI, shouldnt it?
[00:18:30 CEST] <jamrial> good to know it's not asm. it's not my (or BBB's) bug then :P
[00:19:16 CEST] <nevcairiel> i'm still using avresample for i'm too lazy to switch
[00:19:28 CEST] <nevcairiel> i even made opusdec in ffmpeg support both in my fork =p
[00:19:33 CEST] <wm4> nevcairiel: probably by somehow forcing parameters
[00:21:36 CEST] <kierank> nevcairiel: can you upstream that patch
[00:21:43 CEST] <kierank> I'll do it if you don't want to be trolled
[00:22:03 CEST] <nevcairiel> http://git.1f0.de/gitweb?p=ffmpeg.git;a=commitdiff;h=12f6f3af85b7605c0a7b4756219eb276b8d6ca14;js=1
[00:22:17 CEST] <nevcairiel> feel free to steal it, i dont want to be held resposible and need to maintain it later =p
[00:22:49 CEST] <nevcairiel> much ugly ifdefs
[00:22:51 CEST] <nevcairiel> but shrug
[00:23:17 CEST] <wm4> 2 resampling APIs, sigh
[00:23:30 CEST] <wm4> just why
[00:23:58 CEST] <jamrial> wm4: "ffmpeg -i 96k6chfloat.wav -ar 48000 -ac 2 -c:a pcm_s24le 48k2chs32.wav"?
[00:24:34 CEST] <nevcairiel> wm4: the apis are quite similar, just not perfectly the same
[00:25:34 CEST] <wm4> jamrial: trying with -af aformat
[00:26:49 CEST] <wm4> ffmpeg -i /tmp/sample.flac -af aformat=sample_fmts=flt,aformat=channel_layouts=stereo out.wav
[00:27:01 CEST] <wm4> where sample.flac is https://www.mediafire.com/?c10qpnpxahh6k5t
[00:27:33 CEST] <cone-443> ffmpeg 03Pranav Vaish 07master:f669d8c1b790: avcodec/ccaption_dec: Remove the GOTO statement
[00:27:50 CEST] <wm4> removing "aformat=sample_fmts=flt," gives expected results
[00:29:29 CEST] <nevcairiel> this is actually intended behavior, if you output floats, it doesnt normalize the mixing matrix by default
[00:30:26 CEST] <wm4> eh
[00:30:36 CEST] <nevcairiel> add if you figure out how to set swresample options, set rematrix_maxval=1.0
[00:30:41 CEST] <wm4> so generating clipping is intended?
[00:30:49 CEST] <nevcairiel> well, in float it doesnt clip
[00:30:52 CEST] <nevcairiel> technically
[00:30:59 CEST] <nevcairiel> it only clips when converted to int eventually
[00:31:15 CEST] <nevcairiel> but it does seem like an odd choice of default
[00:31:53 CEST] <nevcairiel> it has a check in there to automatically clip mixing to maxval=1.0 if output is an integer format
[00:31:57 CEST] <nevcairiel> but not for floats
[00:32:00 CEST] <nevcairiel> intentionally
[00:32:05 CEST] <nevcairiel> the code is quite clear about that =p
[00:32:45 CEST] <nevcairiel> avr has the default flipped, it always reduces the mixing matrix to avoid clipping at all costs
[00:32:49 CEST] <nevcairiel> unless you tell it otherwise
[00:33:14 CEST] <wm4> setting the option does indeed help
[00:33:58 CEST] <wm4> is it normalize_mix_level in lavr?
[00:34:05 CEST] <nevcairiel> yes
[00:34:11 CEST] <nevcairiel> lavr just has a boolean
[00:34:16 CEST] <nevcairiel> either off or 1.0
[00:34:38 CEST] <wm4> time for a new ifdef in my code
[00:34:55 CEST] <nevcairiel> those are avoptions, just set them blindly
[00:35:16 CEST] <wm4> it will print a warning if an avoption doesn't exist
[00:35:31 CEST] <nevcairiel> really? by default?
[00:35:36 CEST] <nevcairiel> wonder why i've never seen that
[00:35:45 CEST] <nevcairiel> i set like drc_scale=0 on every codec, and its only valid for like ac3
[00:36:07 CEST] <wm4> pretty sure it does with av_opt_set, but not with AVDictionary options
[00:37:30 CEST] <nevcairiel> hm i dont see a message
[00:37:59 CEST] <nevcairiel> only av_opt_set_from_string has one
[00:38:04 CEST] <nevcairiel> but that api is weird anyway
[00:38:51 CEST] <nevcairiel> or av_set_options_string ... which appears to be the same, but different
[00:39:00 CEST] <nevcairiel> sure have a bunch of api garbage
[00:39:40 CEST] <wm4> I think it was when setting an unknown flag with av_opt_set()
[00:39:49 CEST] <wm4> and I confused these cases
[00:40:01 CEST] <wm4> (known option, but unknown flag argument)
[00:40:03 CEST] <nevcairiel> ah yeah that might error
[00:51:30 CEST] <BBB> jamrial: bug?
[00:57:34 CEST] <cone-443> ffmpeg 03Lukasz Marek 07master:08d0dbf2aecb: lavu/dict: don't accept AV_DICT_DONT_STRDUP_VAL for av_dict_set_int
[02:05:40 CEST] <jamrial> BBB: wm4's issue with swr wasn't asm related, so had it been a bug it would have been unlikely something you or i introduced
[02:06:22 CEST] <BBB> oh I see
[02:06:35 CEST] <BBB> (I didnt see the context of what bug you were talking about, just some bug )
[02:09:00 CEST] <andrewrk> ffmpeg ships both avresample and swresample - is one of them recommended? is that to provide compatibility with libav?
[02:09:38 CEST] <wm4> yeah, it wasn't a bug, just a nonsense default
[02:09:58 CEST] <andrewrk> I see that swresample_convert has a simpler API than avresample_convert. I don't understand what out_plane_size means
[02:10:40 CEST] <andrewrk> how would out_plane_size be different than out_samples * sample_size / plane_count?
[02:11:11 CEST] <wm4> just leave it to 0 if you don't know what it does
[02:11:32 CEST] <andrewrk> but the api says to provide it if I know it. and I'm pretty sure I would know it if I just understood what it was supposed to represent
[02:11:34 CEST] <wm4> it's optimization for asm accessing padding or so I think
[02:13:41 CEST] <andrewrk> line_size = planar ? FFALIGN(nb_samples * sample_size, align) :
[02:13:41 CEST] <andrewrk> FFALIGN(nb_samples * sample_size * nb_channels, align);
[02:14:22 CEST] <andrewrk> so it's exactly what I said, but then aligned
[02:14:53 CEST] <andrewrk> #define FFALIGN(x, a) (((x)+(a)-1)&~((a)-1))
[02:16:24 CEST] <jamrial> michaelni: ^
[02:16:52 CEST] <llogan> andrewrk: swresample is from FFmpeg, but Libav wanted to re-invent. i don't know the details of why. FFmpeg provides both for compat/user choice. swresample is the FFmpeg default.
[02:17:01 CEST] <andrewrk> llogan, ok thanks
[02:18:04 CEST] <wm4> llogan: AFAIK it's more like ffmpeg reinvented it
[02:18:14 CEST] <andrewrk> ok did not mean to start this argument
[02:18:16 CEST] <andrewrk> sorry
[02:18:19 CEST] <BBB> haha
[02:18:26 CEST] <llogan> wm4: ok. not that i give a shit.
[02:18:34 CEST] <BBB> andrewrk: yes its to provide binary compatibility to some extent
[02:18:43 CEST] <BBB> (re your earlier question why it ships both)
[02:18:57 CEST] <wm4> haha binary compatibility
[02:19:03 CEST] <wm4> you mean that libav_abi hack?
[02:19:15 CEST] <BBB> maybe its more source compat
[02:19:16 CEST] <BBB> anyway
[02:19:19 CEST] <BBB> lets not have this argument
[02:19:24 CEST] <BBB> ffmpeg vs. libav is soooo 2011
[02:19:41 CEST] <wm4> I'm fine with it if it haunts you forever
[02:19:43 CEST] <Daemon404> yeah 2015 is all about this zip:// protocol
[02:19:45 CEST] <Daemon404> amirite?
[02:19:48 CEST] <andrewrk> FFALIGN - if a is 0, doesn't that just return (x-1) ?
[02:19:51 CEST] <andrewrk> #define FFALIGN(x, a) (((x)+(a)-1)&~((a)-1))
[02:20:16 CEST] <jamrial> wm4: reinvented what?
[02:20:16 CEST] <BBB> you cant call FFALIGN with 0
[02:20:18 CEST] <BBB> thats silly
[02:20:24 CEST] <andrewrk> it's being called that way
[02:20:33 CEST] <BBB> hm& that shouldnt happen
[02:20:40 CEST] <BBB> its like dividing by zerpo
[02:21:30 CEST] <andrewrk> in swresample.h the example code has this:
[02:21:41 CEST] <andrewrk> av_samples_alloc(&output, NULL, 2, out_samples, AV_SAMPLE_FMT_S16, 0);
[02:21:47 CEST] <andrewrk> that last argument is align, which is set to 0
[02:22:15 CEST] <andrewrk> which ends up calling av_samples_get_buffer_size with align 0
[02:22:28 CEST] <BBB> hm, that probably makes no sense
[02:22:36 CEST] <andrewrk> oops, missed this: /* auto-select alignment if not specified */ if (!align)
[02:22:37 CEST] <andrewrk> sorry
[02:22:47 CEST] <BBB> ah
[02:22:48 CEST] <BBB> ok
[02:22:48 CEST] <BBB> good
[02:24:22 CEST] <andrewrk> ok so my question is answered. my buffer is already aligned, so out_plane_size is nb_samples * sample_size * nb_channels
[02:28:00 CEST] <jamrial> nevcairiel: that avr support patch for opus should be merged IMO. forcing the native opus decoder to work with only one of the two libraries is not right
[02:30:09 CEST] <michaelni> "<wm4> llogan: AFAIK it's more like ffmpeg reinvented it", <-- thats not possible as libswresample was written first
[02:33:31 CEST] <kierank> oh it's this argument again
[02:35:13 CEST] <michaelni> the git dates are not really close together so its quite easy to see which was first
[02:36:08 CEST] Action: kierank doesn't feed the trolls
[02:36:13 CEST] <llogan> libswresample has a nice set of anagrams.
[02:38:50 CEST] <Compn> back from vacation , whattda miss ? :P
[02:38:53 CEST] <wm4> hehe, so it's about commit dates? explains why ffmpeg always grabs the stuff to be merged into libav first
[02:40:38 CEST] <llogan> Compn: where did you vacation to?
[02:41:25 CEST] <kierank> roswell
[02:42:52 CEST] <Compn> llogan : florida , nice and warm
[02:43:51 CEST] <Daemon404> and old
[02:45:32 CEST] <llogan> lots of q-tips. white shoes; white hair.
[02:47:10 CEST] <llogan> actually my dad is down there somewhere. rented an RV and escaped the shit weather in Pennsylvania.
[02:50:36 CEST] <Daemon404> i instinctively do not trust RV nomads
[02:53:18 CEST] <llogan> wait until you turn 68.
[02:56:44 CEST] <Daemon404> then i, too, can buy an RV and star in an expisode of criminal minds
[02:56:51 CEST] <Daemon404> episode*
[03:00:16 CEST] <Compn> llogan : are you still in a cold state ?
[03:01:10 CEST] <Daemon404> i thought llogan was canadian
[03:04:21 CEST] <Compn> was thinking of alaska...
[03:04:25 CEST] <llogan> Compn: yeah. We didn't really have a winter though
[03:05:16 CEST] <Daemon404> Compn, alaska is canada
[03:05:19 CEST] <Daemon404> ;)
[03:05:38 CEST] <Daemon404> so is http://minnesota/
[03:05:45 CEST] <Daemon404> ... wow paste fail
[03:06:23 CEST] <llogan> where i'm at the border is about 40 mi away.
[03:06:45 CEST] <Daemon404> one of us one of us
[03:11:17 CEST] <llogan> pub trivia time... hope there is no pop culture category this time.
[04:08:12 CEST] <jamrial> how's gsoc going, btw? did someone else besides the vdpau student pass qualification? and how much time is there left for them to apply to google?
[04:19:00 CEST] <cone-443> ffmpeg 03Donny Yang 07master:d75984486399: apng: Add a basic APNG encoder
[04:20:05 CEST] <jamrial> i suppose that kinda answers the question :p
[04:32:13 CEST] <Compn> jamrial :
[04:32:28 CEST] <Compn> jamrial : lots of gsoc activity including many patches submitted and a few committed :)
[04:32:47 CEST] <Compn> lots of review on the list, many many updated patches :)
[04:38:26 CEST] <jamrial> yeah, saw the inverse telecine filter commited (quali for the vdpau project) and now that apng encoder
[04:39:39 CEST] <jamrial> also the postproc stuff. but seeing the qualifications page showing only one student under "date completed" and march already over made me wonder about deadlines
[04:48:51 CEST] <pross> Daemon404: FFmpeg'ing like its 1995
[13:05:13 CEST] <cone-056> ffmpeg 03Donny Yang 07master:80be7daaa8dd: apng: Add a basic APNG muxer
[13:20:58 CEST] <cone-056> ffmpeg 03Himangi Saraogi 07master:d768f8f5cfe8: ffmpeg: Avoid null pointer dereferences
[14:09:48 CEST] <cone-056> ffmpeg 03Carl Eugen Hoyos 07master:703402683a3f: Bump lavc and lavf minor versions for apng muxer and encoder.
[14:47:23 CEST] <cone-056> ffmpeg 03Timo Rothenpieler 07master:764f87b6ab8e: avcodec/nvenc: Fix profile parameter handling
[15:06:53 CEST] <cone-056> ffmpeg 03Rainer Hochecker 07master:3e53211a578f: vda: fix h264 decoding for avcC,vda wants the entire buffer
[15:47:53 CEST] <robUx42> hi
[15:48:14 CEST] <robUx42> anyone familiar with the dxva code or the hardware acceleration ?
[15:48:36 CEST] <robUx42> I think there's a bug when FF_THREAD_FRAME is used
[15:48:57 CEST] <nevcairiel> Don't do that, the combination is fundamentally broken
[15:49:16 CEST] <robUx42> shouldn't if be done internally then ?
[15:49:36 CEST] <robUx42> if the caller requests FF_THREAD_FRAME and that codec is used, it should not be used
[15:50:05 CEST] <nevcairiel> tell that to those weird people that accept broken playback for some convenience
[15:51:50 CEST] <robUx42> :/
[15:52:36 CEST] <robUx42> even when I feed it a different buffer whenever it needs one, it manages to produce some weird output
[15:52:59 CEST] <robUx42> like the threads are not using the proper reference frames
[16:05:03 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:c299fbbb22f5: avcodec/vda_h264: try to fix build
[16:44:51 CEST] <nevcairiel> man now carl keeps spamming me with nonsense arguments why we should allow producing invalid mkvs with adts aac without init data
[16:45:14 CEST] <nevcairiel> why is the argument "invalid files are a no go" so hard to understand :<
[16:45:23 CEST] <Rug> Where can I find a detailed description of all the nvenc -presets ?
[16:45:25 CEST] <Rug> I know that there are choices: -preset hq or bd, ll, hp, etc. But I am looking for detailed documentation on what these presets do.
[16:45:36 CEST] <nevcairiel> probably some nvidia documentation
[16:47:02 CEST] <Rug> nevcairiel: I have seen those 'keywords' on some NVidia slideshow PDF's but I can't find it anywhere else. I was hoping the ffmpeg experts would know, but thatnk-you for the reply.
[17:15:00 CEST] <Compn> Rug : email the nvenc patch authors :D
[17:15:00 CEST] <Compn> ehe
[17:15:34 CEST] <Rug> Compn: I am actually desperate enough to consider that.
[17:16:12 CEST] <Rug> Right now I am going through the Nvidia SDK, and I see references to the various presets but nothing that actually states _what_they_do_
[17:16:39 CEST] <nevcairiel> it will probably not say that anywhere
[17:16:57 CEST] <nevcairiel> high quality, bluray, low latency, high performance .. just gotta interpret their names :d
[17:17:25 CEST] <Rug> All i want is infor like HQ = video bitrate @8000kb/s Audio @ 192kb/s, etc...
[17:17:40 CEST] <nevcairiel> you can specify the bitrate
[17:18:02 CEST] <nevcairiel> blu-ray is pretty simple, its specifically tailored to create a stream compatible with the blu-ray specification
[17:18:18 CEST] <nevcairiel> HQ is otherwise the slowest and highest quality, HP is faster and lower quality
[17:18:22 CEST] <nevcairiel> so its just speed presets
[17:18:24 CEST] <Rug> Is BD "better" then HQ?
[17:18:32 CEST] <Rug> ahh
[17:18:33 CEST] <nevcairiel> probably not
[17:18:48 CEST] <nevcairiel> BD requires special things like 4 slices being used any whatnot
[17:18:53 CEST] <nevcairiel> not s ure thats going to increase compression
[17:19:00 CEST] <Rug> nevcairiel: that's good to know.
[17:19:02 CEST] <Rug> Thank-you
[17:19:19 CEST] <nevcairiel> LL is special low-latency mode for real-time encoding
[17:19:24 CEST] <nevcairiel> so unless you need that, its of no interest
[17:19:24 CEST] <Prelude2004c> hi everyone.. can i get some help... " http://pastebin.com/DqTFd5Wv " .. Basically the stream mappings.. i am trying to push 2 outputs for HLS but for some reason the 2nd output always selects a differnet audio mapping. Basically i want to make sure the audio input channel is the same for both outputs.. what am i doing wrong here ?
[17:21:32 CEST] <Rug> nevcairiel: Not really, but good to know. Our general workflow; take a video, and convert it into 8 different output formats for publishing. We use Elementals right now but want to move away from them
[17:23:23 CEST] <kierank> Rug: so basically you use x264
[17:23:35 CEST] <kierank> :)
[17:24:19 CEST] <Rug> kierank: Yeah, and we are hopeing the we can use hardware encoding with nvenc to do the job better/faster/cheaper
[17:24:54 CEST] <kierank> not sure, possibly
[17:25:53 CEST] <Rug> On some of our tests it does work very nively. 15minutes to encode a scene with CPU & x264, vs 3 minutes with nvenc
[17:26:05 CEST] <kierank> change x264's speed settings
[17:26:46 CEST] <Rug> we need the highest quality (so that's why -preset slow is used)
[17:27:30 CEST] <kierank> then it's not a like for like comparison
[17:27:39 CEST] <kierank> because nvenc isn't going to be comparable
[17:28:52 CEST] <Rug> if nvenc can produce acceptable quality, AND it's faster then it's a win-win for us.
[17:29:37 CEST] <kierank> Rug: then do a valid comparison
[17:29:41 CEST] <kierank> put x264 on a fast speed
[17:33:12 CEST] <Rug> kierank: but won't the quality suffer?
[17:33:31 CEST] <kierank> the quality will also suffer with nvenc
[17:33:40 CEST] <kierank> the point is to figure out at which point the two produce equal quality
[17:33:54 CEST] <kierank> and then trade that off with encoding time/cpu cost etc
[17:39:40 CEST] <Rug> kierank: ok, you talked me into it. I will start running a comparison of nvenc and x264 set to a 'faster' speed.
[17:41:45 CEST] <kierank> x264 on a fast speed is what your green box is running
[17:43:44 CEST] <Prelude2004c> hey, encoding into hevc ??? how do you do it " ffmpeg -i < INPUT > -c:v libnvenc -r 60 -g 60 -keyint_min 120 -b:v 3000k -minrate 0k -maxrate 4000k -s 854x480 .... OUTPUT .... that libnvenc uses h264
[17:44:02 CEST] <Prelude2004c> how do you tell it to use h265 having the latest chipset like 970 or 980 GPU's
[17:44:09 CEST] <Prelude2004c> it says it supports it on the latest SDK
[17:44:16 CEST] <Prelude2004c> but how does one specify to use it
[17:49:26 CEST] <nevcairiel> The codec is nvenc_h265
[17:49:43 CEST] <nevcairiel> libnvenc_h265 at that
[17:52:09 CEST] <BtbN> Did they actualy update the libnvenc stuff with h265?
[17:52:17 CEST] <BtbN> Or did it always support that?
[17:53:05 CEST] <nevcairiel> 5.0 had it afaik
[17:53:29 CEST] <BtbN> The 5.0 SDK, yes
[17:53:40 CEST] <BtbN> But i wasn't aware they were still working on the libnvenc thing
[17:53:53 CEST] <nevcairiel> Well its in there at least
[17:54:05 CEST] <nevcairiel> And someone made the FFmpeg wrapper use it
[17:55:08 CEST] <nevcairiel> The header we use is an oddball anyway, in the SDK its only found inside the samples, not a central include folder or something. The layout of this SDK is weird
[17:55:41 CEST] <BtbN> Well, it's clearly needed though, it's the only place that contains all the GUIDs and structs
[17:55:49 CEST] <BtbN> It's just in a weird place
[17:56:07 CEST] <BtbN> The libnvenc thing also needs it, and the cuda SDK.
[17:56:22 CEST] <BtbN> But it builds an entire wrapper library around it, instead of just using it directly.
[17:57:42 CEST] <BtbN> I can't see any h265 support in there.
[17:58:53 CEST] <nevcairiel> Well the stuff gotta come from somewhere :D
[17:59:19 CEST] <BtbN> The nvenc encoder in ffmpeg master has h265 support, it was added last week.
[17:59:46 CEST] <BtbN> libnvenc is the one nvidia tried to submit, but all the files have "Copyright (c) 2014, NVIDIA CORPORATION. All rights reserved." at the top.
[18:00:21 CEST] <nevcairiel> Ah well then
[18:00:32 CEST] <BtbN> libnvenc_h265 just doesn't exist.
[18:00:53 CEST] <nevcairiel> Aren't all external encoders called lib- something
[18:01:24 CEST] <BtbN> It's not an realy external encoder.
[18:02:02 CEST] <nevcairiel> Kinda is :d
[18:02:10 CEST] <nevcairiel> But just nvenc_h265 then
[18:08:02 CEST] <BtbN> Is there a way to fail an encoder init, but signal to try again with a diffrent pixel format?
[18:38:46 CEST] <BtbN> This is strange, the libnvenc encoder claims to support yuv420/yv12, but it looks like it just converts it to nv12 on the fly when copying it into the nvenc frame buffer.
[18:39:24 CEST] <BtbN> I wonder if it would be worth to do the same, as it avoids an extra copy, but doesn't profit from the optimized conversion from libswscale.
[18:40:09 CEST] <BtbN> Would propably slightly benefit old platforms like that one guys Phenom II, but impact performance on modern CPUs
[19:05:03 CEST] <Prelude2004c> hey
[19:05:24 CEST] <Prelude2004c> is there an AMD version for the libnvenc ?
[19:05:46 CEST] <Prelude2004c> is thre a GPU hardware library for AMD just like the envidia ?
[19:05:50 CEST] <Prelude2004c> nvidia*
[19:07:52 CEST] <wm4> yes
[19:07:54 CEST] <wm4> vaapi
[19:07:57 CEST] <wm4> (libva)
[19:08:12 CEST] <wm4> I don't know if ffmpeg has encoding support for it, maybe not
[19:10:56 CEST] <BtbN> AMD has their own api, not vaapi.
[19:11:02 CEST] <BtbN> vaapi is intel.
[19:11:42 CEST] <BtbN> It was AMD VCE or something like that.
[19:11:47 CEST] <wm4> but isn't AMD supporting vaapi now?
[19:12:05 CEST] <wm4> oh, also I was assuming Linux
[19:12:11 CEST] <wm4> while nvenc afaik also works on win32
[19:12:37 CEST] <BtbN> amd/mesa is using vdpau iirc. (And XvBA...).
[19:12:58 CEST] <wm4> crap, I confused a few things here
[19:13:53 CEST] <BtbN> libva is a horrible library, otherwise i'd have already implemented an encoder.
[19:15:26 CEST] <wm4> (though I heard Mesa was adding vaapi support)
[19:15:40 CEST] <iive> amd catalyst provide XvBA
[19:15:41 CEST] <BtbN> Yes, for some strange reason they are.
[19:15:52 CEST] <iive> there is however wrapper from it to vaapi.
[19:16:02 CEST] <BtbN> Wasn't XvBA mpeg2 only?
[19:16:11 CEST] <iive> XvMC is mpeg12
[19:16:47 CEST] <wm4> xvba can have strange issues, like swapping chroma planes when using the opaque format (wat...)
[19:17:30 CEST] <iive> well, xvba have issues, vaapi on its own have issues. combine them and...
[19:17:58 CEST] <wm4> also the xvba vaapi backend is unmaintained
[19:18:04 CEST] <wm4> didn't have changes for years
[19:18:08 CEST] <BtbN> vaapi is just an example of poor api design and weird decisions.
[19:18:27 CEST] <BtbN> Like, wtf, why do I as an api-user have to generate h264 nal bitstream, just to feed it into libva?!
[19:18:41 CEST] <BtbN> Which then generates some other bitstream itself?!
[19:18:49 CEST] <wm4> huh, for encoding?
[19:18:52 CEST] <BtbN> yes
[19:19:05 CEST] <wm4> sounds non-sensical :)
[19:19:10 CEST] <BtbN> you have to generate the sps/pps yourself
[19:19:16 CEST] <BtbN> and some other stuff
[19:19:33 CEST] <BtbN> And then you have to give it to libva, which puts it into the final bitstream...
[19:19:47 CEST] <iive> WHAT?!
[19:20:08 CEST] <JEEBsv> löl
[19:20:17 CEST] <wm4> someone wanted to add libyami support
[19:20:20 CEST] <iive> when you talking about it, I think it needs it for decoding.
[19:20:29 CEST] <wm4> which apparently handles these things transparency
[19:20:36 CEST] <iive> ...were..
[19:20:38 CEST] <Daemon404> michaelni, FYI that exr patch from greeshma still lacks copyright
[19:20:38 CEST] <BtbN> iive, yes, you do need the sps/pps for decoding.
[19:20:44 CEST] <Prelude2004c> now i am confused.. so yes they support it but not sure about FFMPEG ?
[19:20:45 CEST] <Daemon404> it was copypasted from openexr
[19:20:50 CEST] <BtbN> But from an encoder i expect it to generate it for me.
[19:20:55 CEST] <Prelude2004c> the adm's seem faster for encoding
[19:21:07 CEST] <Prelude2004c> amd*s
[19:21:11 CEST] Action: iive facepalms
[19:21:16 CEST] <wm4> Prelude2004c: no support for hw encoding with amd on ffmpeg
[19:21:19 CEST] <BtbN> iive, https://github.com/BtbN/vlc-vaapi-enc/blob/master/vlc-h264-vaapi-enc.c#L622
[19:21:23 CEST] <BtbN> That's what that looks like.
[19:21:31 CEST] <JEEBsv> wm4: in some kind of way that library naming is matching; yami means darkness in .jp
[19:21:58 CEST] <BtbN> libyami is basicaly intel saying that their primary api is so bad that they felt like wrapping it.
[19:23:15 CEST] <wm4> why can't there just be a single API that works on all flavors of Linux and hw vendors
[19:23:36 CEST] <BtbN> For decoding there almost was
[19:23:41 CEST] <BtbN> But intel decided to do their own stuff
[19:23:52 CEST] <wm4> even then it was desktop only
[19:23:52 CEST] <BtbN> Everything could be using vdpau
[19:24:04 CEST] <iive> openmax?
[19:24:22 CEST] <iive> or whatever was the android one.
[19:24:41 CEST] <wm4> omx is not even accessible to apps on android
[19:24:45 CEST] <BtbN> For encoding there is intel qsv(Win32), intel vaapi, nvidia nvenc, amd vce, v4l2, openmax
[19:24:59 CEST] <wm4> so sad
[19:25:12 CEST] <wm4> I'm just going to call everyone stupid and be done
[19:25:24 CEST] <Prelude2004c> hey , how do you know if nvidia card is 1st gen or 2nd gen ?
[19:25:29 CEST] <Prelude2004c> i need to find a card that supports HEVC
[19:25:32 CEST] <Prelude2004c> but not sure which one that is
[19:25:35 CEST] <BtbN> gtx980
[19:25:36 CEST] <BtbN> The end.
[19:25:46 CEST] <iive> hevc is h265
[19:25:53 CEST] <Prelude2004c> yes but the gtx 980s have a limitation of 2 streams
[19:26:08 CEST] <BtbN> all cards do, that's an artificial limit in the consumer nvenc api.
[19:26:20 CEST] <Prelude2004c> nvidia only allows more than 2 GPU's if on the tesla or keplar gen 2 cards
[19:26:35 CEST] <Prelude2004c> ohhhhh how do i raise that limit
[19:26:38 CEST] <BtbN> You don't.
[19:26:39 CEST] <Prelude2004c> if i want to use up more GPU's
[19:27:25 CEST] <BtbN> The chip is able to handle as many parallel sessions as it can encode(like 800 fps with 720p and medium settings), but the api is limited to 2 sessions.
[19:27:33 CEST] <Prelude2004c> any way i can have the system startup more than 2 simultantious encodings
[19:27:36 CEST] <BtbN> no.
[19:27:50 CEST] <Prelude2004c> ??
[19:27:54 CEST] <BtbN> Patch that limit out of the driver, good luck.
[19:28:16 CEST] <Prelude2004c> how would i do that ? anyone have any experience with that ?
[19:28:24 CEST] <BtbN> exactly
[19:29:19 CEST] <BtbN> You are not going to be able to open more than 2 simultaneous nvenc sessions, no matter what.
[19:30:02 CEST] <BtbN> If you need that, there is another API, which is under an NDA, for "professionals"
[19:30:32 CEST] <BtbN> You won't find support for that in any open source tool, and propably also won't find public closed-source tools supporting it.
[19:30:33 CEST] <Prelude2004c> oh really
[19:30:37 CEST] <Prelude2004c> where do i get it and what is the naem of it
[19:30:45 CEST] <BtbN> NDA.
[19:30:53 CEST] <Rug> BtbN: Do you know if the top-end Quadro cards can handle more then 2 streams/sessions/threads?
[19:31:06 CEST] <Prelude2004c> someone else told me this..
[19:31:09 CEST] <BtbN> Rug, all cards can. It's the same chip.
[19:31:16 CEST] <Prelude2004c> The 2 stream limitation is set by NVIDIA for the consumer oriented GeForce GPUs. This limitation is lifted to the maximum possible on NVIDIA Kepler and Maxwell-based Quadro GPU line and the Tesla series
[19:31:19 CEST] <BtbN> It's just an artificial limit
[19:31:30 CEST] <Rug> ok thanks.
[19:32:10 CEST] <Rug> We are looking at buying a few Tesla cards so i was wondering about that limitation.
[19:32:19 CEST] <Prelude2004c> ya me too
[19:32:30 CEST] <Prelude2004c> trying to find out what cards don't have that 2 stream limitation
[19:32:44 CEST] <BtbN> As far as i'm aware the cards don't matter at all.
[19:32:52 CEST] <BtbN> It's purely the driver enforcing that limit.
[19:32:59 CEST] <Prelude2004c> or if there is another libnvenc library that doesn't have this limitaiton.. i would like to get my hands on it
[19:33:14 CEST] <BtbN> NDA.
[19:33:48 CEST] <Rug> BtbN: You make me wish I was a driver-developer
[19:34:18 CEST] <BtbN> All the nvidia cards are basicaly the same hardware.
[19:34:27 CEST] <BtbN> no matter if GeForce, Quadro or Tesla.
[19:34:30 CEST] <Rug> That really is depressing
[19:34:44 CEST] <BtbN> It's the same hardware, the only difference is that you can use the "professional" drivers and APIs with them.
[19:35:08 CEST] <Prelude2004c> you say NDA .. what is NDA ?
[19:35:20 CEST] <Prelude2004c> sorry for my ignorance.. never heard of the term
[19:35:25 CEST] <BtbN> Non-Disclousure-Agreement.
[19:35:31 CEST] <BtbN> You sign not to talk about it.
[19:35:33 CEST] <Prelude2004c> from NVIDIA directly?
[19:38:54 CEST] <Prelude2004c> is there an nvidia development channel?
[19:39:47 CEST] <wm4> why would there
[19:40:09 CEST] <wm4> you can probably ask nvidia for commecrial support
[19:40:13 CEST] <wm4> *commercial
[19:40:25 CEST] <BtbN> They won't talk to you if you are not a company.
[19:41:22 CEST] <BtbN> And their consumer-support is useless. They kept telling me i need an nvenc license when i reported some bugs, even when the current SDK had all the license stuff removed already.
[19:41:47 CEST] <Prelude2004c> interesting
[19:41:51 CEST] <Prelude2004c> we have a company
[19:42:11 CEST] <Prelude2004c> so no way around the lift. with re-encoding the library or drivers?
[19:42:13 CEST] <BtbN> Basicaly: Get one of those cards, and try if you can open more than two sessions. If not, you are most likely out of luck.
[19:42:53 CEST] <Prelude2004c> is it the drivers or the libnvenc that has the limit ?
[19:42:57 CEST] <Prelude2004c> libnvenc right?
[19:43:02 CEST] <BtbN> There is no libnvenc.
[19:43:18 CEST] <Prelude2004c> ?? i am using that libarry to send data to GPU
[19:43:51 CEST] <BtbN> libnvenc is what the nvidia devs called the ffmpeg encoder they tried to submit.
[19:44:56 CEST] <Prelude2004c> so if i wnated programmers to look somewhere at this limitation.. where would they look?
[19:45:12 CEST] <Prelude2004c> or can't i just push everything into one process ?
[19:45:20 CEST] <Prelude2004c> put all streams in one single process
[19:45:36 CEST] <BtbN> As the nvidia driver is closed source...
[19:45:58 CEST] <BtbN> The driver won't allow to open more than 2 sessions on the entire host.
[19:46:18 CEST] <Prelude2004c> right.. but what if we have 1 session ... but multipel process handled by that session
[19:46:36 CEST] <BtbN> One Session, one Video Stream...
[19:46:38 CEST] <Prelude2004c> meaning a process in between that basically sends thew ork in 1 session to the cards
[19:46:49 CEST] <Prelude2004c> hum..
[19:47:03 CEST] <Prelude2004c> there has to be a away around this
[19:47:21 CEST] <BtbN> Sure, just add support for hardware encoding to nouveau.
[19:48:53 CEST] <Prelude2004c> vouveau ?
[19:50:04 CEST] <BtbN> It is just not going to happen...
[19:50:22 CEST] <Prelude2004c> you mean " https://wiki.archlinux.org/index.php/VA-API "
[19:50:27 CEST] <Prelude2004c> this is software only?
[19:50:35 CEST] <Prelude2004c> doesn't it get the GPU's to do the work too
[19:50:51 CEST] <BtbN> VA-API, aka libva, is the intel api.
[19:51:10 CEST] <BtbN> It's so bad nobody has ever used it to actualy implement a usefull encoder.
[19:51:21 CEST] <Prelude2004c> https://wiki.archlinux.org/index.php/VDPAU
[19:51:29 CEST] <BtbN> ...
[19:52:13 CEST] <Prelude2004c> doesn't show ffmpeg as supported
[19:52:21 CEST] <Prelude2004c> unless i can encode with something else :(
[19:52:26 CEST] <Prelude2004c> man its not as easy as i thought
[19:52:36 CEST] <BtbN> vdpau is a pure decoding api, as the name suggests.
[19:53:13 CEST] <BtbN> Just use x264 for encoding, unlimited simultanous streams, best quality, ...
[19:54:11 CEST] <Prelude2004c> hum.. c
[19:54:11 CEST] <Prelude2004c> ic
[19:54:16 CEST] <Prelude2004c> i am ok with x264 for now
[19:54:24 CEST] <Prelude2004c> but still have that 2 session limit
[19:54:31 CEST] <wm4> wat
[19:55:07 CEST] <Prelude2004c> i am ok with using h264 at the moment ... but i can't get again more than 2 sessions..
[19:55:19 CEST] <Prelude2004c> i tried going just x264 without libnvenc and the CPU usage per stream was like 70%
[19:55:21 CEST] <Prelude2004c> oops
[19:55:29 CEST] <Prelude2004c> 700% ... vs 50% of CPU with libnvenc
[19:55:33 CEST] <Prelude2004c> huge difference
[19:55:40 CEST] <wm4> so you can't afford that cpu usage?
[19:55:54 CEST] <wm4> nvenc will stress your gpu instead
[19:56:02 CEST] <Prelude2004c> not logical... i have a 25 core 2.8 Ghz.. and 3 output streams at 60fps and 720p .. the sytem can't keep up
[19:56:12 CEST] <BtbN> wm4, not realy, only the PCIe bus.
[19:56:19 CEST] <Prelude2004c> GPUs are only there to be used for encoding
[19:56:27 CEST] <BtbN> GPUs are terrible for encoding.
[19:56:30 CEST] <Prelude2004c> this system will be desgined for only encoding
[19:56:45 CEST] <Prelude2004c> again... 700% vs 50%
[19:56:54 CEST] <BtbN> Then throw CPU cores in there instead of expensive Tesla cards.
[19:57:06 CEST] <Prelude2004c> i already have 24 cores
[19:57:13 CEST] <Prelude2004c> and they can't handle 1 sigle output ( 3 bit rates )
[19:57:20 CEST] <kierank> then you're doing it wrong
[19:57:28 CEST] <Prelude2004c> ?
[19:57:29 CEST] <BtbN> I can do that on my boring i5...
[19:57:35 CEST] <BtbN> You are doing something wrong.
[19:57:40 CEST] <Prelude2004c> same code ( exactly ) with the libnvenc , CPU shows 50%
[19:57:51 CEST] <Prelude2004c> let me get you what code i am doing
[19:57:59 CEST] <BtbN> You are still doing something wrong, and are there still is no libnvenc.
[19:58:25 CEST] <BtbN> For me an ffmpeg process which is encoding with nvenc needs barely any CPU.
[19:58:48 CEST] <BtbN> And i can easily handle 2~3 x264 sessions with a decent quality on my old snb i5.
[19:59:43 CEST] <Prelude2004c> ffmpeg -i < INPUT > -c:v libnvenc -r 30 -g 60 -keyint_min 90 -b:v 1500k -minrate 1000k -maxrate 2000k -s 640x360 -x264opts "keyint=120:min-keyint=120:no-scenecut" -tune zerolatency -output_ts_offset -2 -threads 0 -strict -2 -c:a aac -ar 48000 -ac 2 -b:a 384k -f ssegment ....... < OUPUT > ...
[19:59:50 CEST] <Prelude2004c> that is basically what i am doing
[20:00:05 CEST] <BtbN> There is no libnvenc. The encoder is called nvenc.
[20:00:14 CEST] <Prelude2004c> ohhh and vs the " -c:v h264
[20:00:27 CEST] <BtbN> If libnvenc works, you are using an entirely unsupported hack from nvidia.
[20:00:41 CEST] <Prelude2004c> ?
[20:00:55 CEST] <BtbN> There is no libnvenc encoder in ffmpeg.
[20:01:34 CEST] <wm4> Prelude2004c: how much cpu x264 uses for encoding depends entirely on its settings
[20:02:00 CEST] <Prelude2004c> Unknown encoder 'nvenc'
[20:02:07 CEST] <wm4> Prelude2004c: and how can you be sure they're the same?
[20:02:17 CEST] <Prelude2004c> because i just changed the libarry
[20:02:25 CEST] <Prelude2004c> from " h264 > libnvenc "
[20:02:31 CEST] <Prelude2004c> and it worked.. from 700% down to 50%
[20:02:35 CEST] <wm4> Prelude2004c: at least I doubt that -x264opts makes the nvenc encoder use it
[20:02:37 CEST] <BtbN> Does "-c:v h264" actualy work? oO
[20:02:52 CEST] <Prelude2004c> i removed the x264opts
[20:02:59 CEST] <Prelude2004c> one sec.. testing
[20:03:32 CEST] <wm4> Prelude2004c: in any case, for a fair comparison, you need to use similar settings (they can't be exactly the same because they're different encoders), and must encode to similar quality
[20:04:02 CEST] <wm4> Prelude2004c: it's entirely possible that x264 produces decent output while the GPU one is full of artifacts (doesn't have to be, but GPU encoders are often lower quality AFAIK)
[20:04:03 CEST] <BtbN> If libnvenc works, there is nothing to discuss about anyway, you are not using ffmpeg, but some license-tainted nvidia fork of it.
[20:04:33 CEST] <BtbN> The encoder in ffmpeg is called nvenc
[20:05:14 CEST] <wm4> was libnvenc the earlier, rejected patch?
[20:05:26 CEST] <Prelude2004c> seems to always use libnvenc now since i guess when i compiled ffmpeg i said --enable-libnvenc
[20:05:30 CEST] <BtbN> wm4, yes.
[20:05:41 CEST] <wm4> ok that makes the situation pretty clear
[20:05:57 CEST] <Prelude2004c> i have tested the quality on both actually
[20:05:59 CEST] <Prelude2004c> seems the same
[20:06:31 CEST] <jamrial> Prelude2004c: you're evidenlty using an old ffmpeg build with an old rejected patch applied on top of it. you should recompile using vanilla git head
[20:09:37 CEST] <Prelude2004c> hum... maybe i am running a custom ffmpeg build
[20:09:42 CEST] <Prelude2004c> that supports the libnvenc
[20:09:59 CEST] <Prelude2004c> i remember trying it on the latest git but it could not get libnvenc
[20:10:02 CEST] <BtbN> Again: There is no libnvenc. That's what nvidia called their ffmpeg encoder.
[20:10:13 CEST] <BtbN> The official encoder in ffmpeg is called just nvenc.
[20:11:45 CEST] <Prelude2004c> ic.. so the one i am using is just an old one?
[20:12:10 CEST] <BtbN> It's something nvidia came up with, but it was rejected for various reasons.
[20:14:05 CEST] <Prelude2004c> ok.. so thank you for helping me get my head around this.. i have to think about everything
[20:14:13 CEST] <Prelude2004c> so my question is.. i want to take a multicast stream
[20:14:24 CEST] <Prelude2004c> output 3 simultatnious ( or more ) hls outputs
[20:14:35 CEST] <Prelude2004c> and use hardware encoding to do it so it doesnt' overload my CPU's
[20:14:51 CEST] <Prelude2004c> i understand the quality difference but so much more processing power on the GPU's
[20:15:01 CEST] <Prelude2004c> helps me offload a lot of that away from the CPU
[20:15:02 CEST] <BtbN> You have 24 cores, you can easily encode 10+ streams with that...
[20:16:10 CEST] <Prelude2004c> i am going to try again with just the CPU
[20:16:13 CEST] <Prelude2004c> let me disable the nvenc
[20:16:50 CEST] <wm4> why do you have 24 cores if you want it to work with 1 core?
[20:26:58 CEST] <kepstin-laptop> Prelude2004c: keep in mind that nvenc doesn't even use the gpu processing power; it really uses separate fixed-function hardware on the gpu die.
[20:27:28 CEST] <kepstin-laptop> (or maybe some sort of configurable function stuff with firmware, but either way it's separate)
[20:41:42 CEST] <cone-056> ffmpeg 03Tim Nicholson 07master:27565ace60d4: ffmpeg_opt.c: fix regression introduced in 5743095c
[20:49:05 CEST] <Prelude2004c> hey guys
[20:49:11 CEST] <Prelude2004c> so i checked now with just h264
[20:49:18 CEST] <Prelude2004c> 1300% on CPU
[20:49:27 CEST] <Prelude2004c> same exact code vs --enable-libnvenc
[20:49:37 CEST] <kierank> and?
[20:49:40 CEST] <Prelude2004c> that same exact code with the --enable-libnvenc only uses 50%
[20:49:42 CEST] <kierank> what settings
[20:49:53 CEST] <kierank> lo and behold a CPU encoder is using the CPU
[20:50:30 CEST] <Prelude2004c> i understand it is using the CPU
[20:50:39 CEST] <Prelude2004c> but i only get like 1 stream on this thing
[20:50:43 CEST] <Prelude2004c> let me post code from the command
[20:51:18 CEST] <BtbN> Get a propper build instead of that nvidia-libnvenc thing first.
[20:52:32 CEST] <Prelude2004c> cold looks like this
[20:52:32 CEST] <Prelude2004c> ffmpeg -i "udp://239.255.4.151:5000?ttl=100&fifo_size=1000000&overrun_nonfatal=1" -c:v h264 -r 60 -g 60 -keyint_min 120 -b:v:0 ${bitrate} -maxrate ${maxrate} -s ${resolution} -threads 0 -strict -2 -c:a:1 aac $
[20:52:32 CEST] <Prelude2004c> -segment_list ${HLS_PATH}/${CHN}/${CHN}_${name}.m3u8 -segment_list_type flat -segment_list_flags live -segment_list_type m3u8 -segment_time 3 -segment_list_size 15 -segment_format mpegts
[20:52:33 CEST] <Prelude2004c> "${HLS_PATH}/${CHN}/${CHN}_${name}_%08d.ts"
[20:52:36 CEST] <Prelude2004c> latest git version
[20:52:38 CEST] <jamrial> was that rejected libnvenc patch the one that tried to dump the non-free library into the tree?
[20:53:01 CEST] <Prelude2004c> i have no idea
[20:53:08 CEST] <Prelude2004c> just a version i got online
[20:53:14 CEST] <Prelude2004c> that said it supported it
[20:53:54 CEST] <jamrial> Prelude2004c: if -c:v h264 for the output works then this is a heavily modified ffmpeg build
[20:54:20 CEST] <jamrial> same applies to -c:v libnvenc
[20:54:41 CEST] <Prelude2004c> heavy modified.. i just got it from " git " repo
[20:55:31 CEST] <Prelude2004c> now running exact same command with libncenc
[20:55:47 CEST] <BtbN> jamrial, yes.
[20:56:10 CEST] <BtbN> It has code with "property of NVIDIA. All rights reserved." as header.
[20:56:13 CEST] <cone-056> ffmpeg 03Donny Yang 07master:b0a2aee4089e: png: Use libavutil's crc functions instead of zlib's
[20:57:26 CEST] <jamrial> wait, seems that -c:v h264 works. it just defaults to x264 or whatever is available, huh
[20:58:37 CEST] <Prelude2004c> yup.. ok
[20:58:51 CEST] <Prelude2004c> cant run the libnvenc on this ffmpeg latest version
[20:59:19 CEST] <Prelude2004c> seems the ffmpeg version doesn't support it
[21:29:43 CEST] <Prelude2004c> hey guys
[21:29:46 CEST] <Prelude2004c> question...
[21:29:59 CEST] <Prelude2004c> seeing as how i can only do 2 streams with the nvenc
[21:30:06 CEST] <Prelude2004c> what about if i have 2 cards or 4 cards for example
[21:30:11 CEST] <Prelude2004c> could i do 2 in each ?
[21:43:06 CEST] <BtbN> If you put each card in a seperate machine, sure.
[21:45:29 CEST] <Rug> Hello again, quick question; I am processing a 4k video clip (using nvenc) and it is still using 30%-40% of all the CPU cores. Any ideas why? (most 1080p file barely touch the cpu during processing)
[21:46:47 CEST] <BtbN> Because nvenc only takes nv12, and converting 4K yuv420->nv12 is a complex task.
[21:47:01 CEST] <Rug> ok thanks
[21:47:17 CEST] <BtbN> About 4 times as complex as for 1080p
[21:47:31 CEST] <Rug> I really don't know what we are going to do with these monster files.
[21:47:52 CEST] <Rug> This 17minute clip is eating 35GB of storage
[21:48:25 CEST] <jamrial> Rug: you could try running ffmpeg with perf or some other profiling tool. if what BtbN is true then you should see most cpu time spent on some libswscale function
[21:49:06 CEST] <Rug> jamrial: That is an excellent suggestion! Thanks.
[21:49:41 CEST] <Rug> Honestly, I've been fretting over disk-space usage, and didn't even think about _where_ in the process it was wasteing so much CPU
[21:50:22 CEST] <BtbN> Well, if you want to save disk space, nvenc won't help you though.
[21:51:12 CEST] <Rug> BtbN: no, that isn't the point. But I'm just trying to wrap my brain around all the 4k videos and wherre the hell we are going to store them.
[21:51:15 CEST] <Rug> =)
[21:51:29 CEST] <Rug> My poor ZFS array won't be able to keep up
[21:51:32 CEST] <Rug> hehe
[22:00:08 CEST] <Prelude2004c> hey, the nvidia-smi doesn't work on the 600 series right? they removed support for it?
[22:00:28 CEST] <Prelude2004c> doesn't give me data on GPU usage
[22:11:19 CEST] <Prelude2004c> i am getting more and more confused.. you guys said that using CPU's should yield better quality and similar results to " nvenc " .. but i am showing 1 stream 720p at 60fps using up approx ( 10 CPU cores 1000% )... when i turn over to nvenc it uses ( 1 CPU core 50 % )
[22:11:32 CEST] <Prelude2004c> so now i am confused why it is being said that it should be just as good with the CPU power
[22:14:14 CEST] <iive> does it process the video faster than the cpu?
[22:18:31 CEST] <kierank> well your 10 core thing is strange
[22:18:36 CEST] <kierank> but a CPU encoder uses CPU
[22:20:05 CEST] <wm4> kierank: he doesn't want it to use CPU though
[22:20:18 CEST] <wm4> which is why he has 25 cores
[22:20:22 CEST] <kierank> then why did he buy 24 cpus
[22:20:23 CEST] <kierank> lol
[22:20:23 CEST] <wm4> or something
[22:20:37 CEST] <wm4> right, 24
[22:20:53 CEST] <wm4> so magic GPUs are needed to make sure the CPUs are useless
[22:21:42 CEST] <wm4> Prelude2004c: is there any other processing going on?
[22:21:45 CEST] <wm4> scaling maybe?
[22:22:46 CEST] <kepstin-laptop> with 24 cores, there's no reason you couldn't run e.g. 12 streams with x264 by limiting each to 2 threads and setting appropriate speed options...
[22:29:48 CEST] <jamrial> michaelni: regarding the pngenc patch i just sent, the compiler that's failing is http://fate.ffmpeg.org/report.cgi?time=20150402191356&slot=x86-opensolaris-suncc5.10
[22:30:08 CEST] <Prelude2004c> hey sorry for the delayed resonse
[22:30:19 CEST] <Prelude2004c> this stuff is coming in live , not trying to transcode a file
[22:30:30 CEST] <Prelude2004c> its a live channel transcoding to HLS
[22:30:54 CEST] <Prelude2004c> doesn't make sense to use 2 cores only because the 2 cores can't keep up.. i am saying use all cores and its deciding by default to use all 10 cores
[22:31:02 CEST] <Prelude2004c> the system will allways have overhead using nvenc
[22:31:42 CEST] <Prelude2004c> so basically the idea is.. offload the work to hardware GPU's ... the cpu usage per stream is to manage the work load... so when i am up at 24 used cores i should be able to get 50 channel outputs
[22:32:03 CEST] <Prelude2004c> so 3 bit rates per channel as an example = 15 channels or so at 720p
[22:32:06 CEST] <Prelude2004c> that is the idea
[22:32:33 CEST] <Prelude2004c> each channel outputs ( 3 bitrates = 3 sessions )
[22:32:47 CEST] <Prelude2004c> one at 720p, one at 480p, and another at 360p
[22:32:55 CEST] <Prelude2004c> all 60fps
[22:33:30 CEST] <Prelude2004c> using nvenc works well asside from the 2 GPU limit which i just bought a k4200 series to test
[22:33:39 CEST] <Prelude2004c> i am told it has no limitation on those so.. i guess we will see
[22:34:11 CEST] <Prelude2004c> it is just a shame that you can't do it on a 980 Geforce card ... they are faster
[22:34:27 CEST] <Prelude2004c> silly limitation.. asside from forcing customers to pay more money to get more sessions
[22:34:51 CEST] <kepstin-laptop> you're saying "2 cores can't keep up", but that just means that you haven't bothered to play with x264's speed settings.
[22:35:48 CEST] <kepstin-laptop> if you lower the quality down to something similar to what you'd get out of a hardware encoder like nvenc, it probably *could* keep up to a live stream on a smaller number of cores.
[22:36:07 CEST] <Prelude2004c> the quality looks the same to me
[22:36:19 CEST] <Prelude2004c> looking at x264 and nvenc .. it looks the same
[22:36:45 CEST] <kepstin-laptop> you're encoding to vbr or what?
[22:36:50 CEST] <Prelude2004c> HLS out
[22:37:24 CEST] <kepstin-laptop> erm, that's not what I asked. Are you encoding to a bitrate, or a quality setting?
[22:37:31 CEST] <Prelude2004c> ffmpeg -i "udp://239.255.4.151:5000?ttl=100&fifo_size=1000000&overrun_nonfatal=1" -c:v h264 -r 60 -g 60 -keyint_min 120 -b:v:0 ${bitrate} -maxrate ${maxrate} -s ${resolution} -threads 0 -strict -2 -c:a:1 aac $ "${HLS_PATH}/${CHN}/${CHN}_${name}_%08d.ts"
[22:37:44 CEST] <Prelude2004c> bit rate
[22:37:46 CEST] <Prelude2004c> that is what i am doing
[22:37:54 CEST] <Prelude2004c> oh wait.. somethign missing there
[22:38:25 CEST] <Rug> Prelude2004c: Try throwing this in there: -preset veryfast
[22:38:27 CEST] <kepstin-laptop> hmm, maxrate? are you using vbv?
[22:38:42 CEST] <Prelude2004c> ffmpeg -i "udp://239.255.4.151:5000?ttl=100&fifo_size=1000000&overrun_nonfatal=1" -c:v h264 -r 60 -g 60 -keyint_min 120 -b:v:0 ${bitrate} -maxrate ${maxrate} -s ${resolution} -threads 0 -strict -2 -c:a:1 aac -segment_list ${HLS_PATH}/${CHN}/${CHN}_${name}.m3u8 -segment_list_type flat -segment_list_flags live -segment_list_type m3u8 -segment_time 3 -segment_list_size 15 -segment_format mpegts "${HLS
[22:38:42 CEST] <Prelude2004c> _PATH}/${CHN}/${CHN}_${name}_%08d.ts"
[22:39:00 CEST] <Prelude2004c> that is the code i am running
[22:39:20 CEST] <Rug> -c:v libx264 -preset veryfast has given me similarquality & slightly faster processing time as using the nvenc encoder
[22:39:35 CEST] <Prelude2004c> will try now
[22:39:50 CEST] <kepstin-laptop> Prelude2004c: ah, you're using -maxrate without -bufsize, so that's a noop. it's doing pure vbr encoding.
[22:40:49 CEST] <Prelude2004c> yup variable is what i wanted
[22:40:54 CEST] <Prelude2004c> because variable gives me the best quality when eeded
[22:40:56 CEST] <Prelude2004c> need*
[22:41:10 CEST] <Prelude2004c> i need a bufsize ?
[22:41:16 CEST] <Prelude2004c> of what .. 300 ?
[22:41:17 CEST] <kepstin-laptop> no, you should remove -maxrate
[22:41:22 CEST] <kepstin-laptop> since it's doing nothing :)
[22:41:30 CEST] <Prelude2004c> how do i get the maxrate going ?
[22:41:37 CEST] <Prelude2004c> introduce a -bufsize?
[22:41:54 CEST] <kepstin-laptop> if you want to ensure that the momentary bandwidth over the size of the buffer specified never exceeds maxrate, then you need both maxrate and bufsize
[22:42:04 CEST] <kepstin-laptop> the nvenc encoder probably doesn't support that, of course.
[22:42:13 CEST] <Prelude2004c> ic
[22:42:16 CEST] <kepstin-laptop> but who knows, it might...
[22:42:22 CEST] <Prelude2004c> will test that too
[22:42:28 CEST] <Prelude2004c> bufsize is in frames ?
[22:42:32 CEST] <Prelude2004c> as in 300 frames
[22:42:32 CEST] <Prelude2004c> ?
[22:42:37 CEST] <kepstin-laptop> Prelude2004c: bufsize is in the docs
[22:42:42 CEST] <Prelude2004c> k will look
[22:44:15 CEST] <Prelude2004c> bufsize still gets used actually if you dn't specify
[22:44:22 CEST] <Prelude2004c> just does it slower or on a default
[22:44:26 CEST] <Prelude2004c> as per fpeg.org
[22:44:30 CEST] <Prelude2004c> ffmpeg*
[22:45:38 CEST] <kepstin-laptop> so, you'd normally calculate what to set bufsize to based on the the user's expected internet connection speed (maxrate) and the amount of time that the player is expected to buffer.
[22:46:13 CEST] <kepstin-laptop> so e.g. if you're targetting someone with a 10mbit connection and buffering for 10 seconds, the bufsize should be 100mbits.
[22:46:42 CEST] <kepstin-laptop> that would ensure that this hypothetical person shouldn't ever have the stream stop and buffer in the middle of playback
[22:47:13 CEST] <Prelude2004c> ok so...
[22:47:30 CEST] <Prelude2004c> hum.. seems to be down a bit now with cpu on veryfast
[22:47:45 CEST] <kepstin-laptop> looks like nvenc does support buffer management for bitrate.
[22:48:03 CEST] <Prelude2004c> oh now up to 400$
[22:48:06 CEST] <Prelude2004c> 400%
[22:48:15 CEST] <kepstin-laptop> or maybe i'm confused.
[22:48:22 CEST] <Prelude2004c> :)
[22:50:09 CEST] <Prelude2004c> ok so.. with very fast seems to have sped up h264 ..
[22:50:10 CEST] <Prelude2004c> but..
[22:50:21 CEST] <Prelude2004c> doesn't seem to be much better than nvenc
[22:50:29 CEST] <Prelude2004c> with nvenc the cpu's are down to 1/5th of this
[22:50:33 CEST] <Prelude2004c> because the GPU's do the work
[22:51:10 CEST] <llogan> this conversation seems more fitting for #ffmpeg
[22:55:58 CEST] <Prelude2004c> some of these questions were asked on ffmpeg and no answers.. nobody seems to have a clue :) .. that is why i came here because you guys should know a lot more then the people there i would think ( :) )
[22:56:10 CEST] <Prelude2004c> and thank you all for your help btw
[22:56:15 CEST] <Prelude2004c> i am learning quite a bit about this stuff today
[22:57:21 CEST] <Prelude2004c> anyone know an nvidia dev forum?
[22:57:32 CEST] <Prelude2004c> because i see channel just nvidia but nobody says anything on it or talks
[22:58:35 CEST] <BtbN> This channel is meant for talk about ffmpeg development, not user support.
[23:00:07 CEST] <Prelude2004c> as in ..... AMD support for hw encoding ? :)
[23:00:12 CEST] <Prelude2004c> that may solve things
[23:00:39 CEST] <nevcairiel> VCE is kinda crappy IMHO
[23:01:49 CEST] <Prelude2004c> the cores seems faster for the price that's for sure
[23:01:52 CEST] <Prelude2004c> everything else i dont know
[23:02:32 CEST] <BtbN> ...?
[23:03:46 CEST] <Rug> I don't know if anybody cares about my opinion, but I have run some comparison tests.
[23:04:11 CEST] <Rug> a 4k video converted with nvenc vs with libx264 -preset veryfast
[23:04:31 CEST] <Prelude2004c> same quality?
[23:04:40 CEST] <Rug> The libx264 looks a little bit better, and took the same amount of time to encode
[23:04:53 CEST] <Rug> The Dark levels on libx264 are better
[23:05:09 CEST] <Rug> Some details are sharper and more accurate
[23:05:25 CEST] <Rug> But it is VERY close
[23:05:34 CEST] <Prelude2004c> ic.. i just tried to get the libx264 going and for whatever reason the image was jumping around.. not sure if it is my settings of course.. do you have a copy of what your settings looked like for best quality?
[23:05:45 CEST] <nevcairiel> This is what previous tests also resulted in pretty much
[23:05:46 CEST] <BtbN> nvenc is nowhere close to x264 in terms of quality.
[23:05:53 CEST] <Prelude2004c> ic.. so rug, if i had nvenc all really i save is the cpu power right?
[23:06:07 CEST] <Prelude2004c> because it uses the GPU cpu's instead.. only thing is GPU's have so much more processing cores.. that is why i am looking at it
[23:06:21 CEST] <Prelude2004c> anyone have a good format that i can use for quality
[23:06:27 CEST] <BtbN> It doesn't use the actual GPU, and a GPU doesn't have a cpu...
[23:06:31 CEST] <Prelude2004c> something that looks very good that i can try and apply to my input
[23:07:27 CEST] <nevcairiel> If you match speed, x264 wins over all the hw encoders in quality, even of only slightly
[23:07:31 CEST] <Rug> BtbN: This is based on as best a replication of conditions as I can manage. My source file might already be 'less then perfect' But right now the software rendered scenes look better.
[23:07:55 CEST] <nevcairiel> However x264 is of course much more flexible
[23:08:10 CEST] <BtbN> nvenc is actualy quite bad.
[23:08:16 CEST] <Prelude2004c> can anyone help me with a sample ffmpeg command .. maybe i am doing somethign wrong
[23:08:18 CEST] <BtbN> Most other hw encoders are better.
[23:08:22 CEST] <nevcairiel> On the other hand, hw encoders leave the CPU free to do other things
[23:08:28 CEST] <BtbN> ask in #ffmpeg
[23:08:50 CEST] <Rug> ffmpeg -i /mnt/working_videos/goran/4K/1784457.mp4 -r 29.97 -c:v libx264 -preset ultrafast -c:a aac -vf scale=3840:2160 -strict experimental -b:v 21700k -b:a 128k -y 4k-test.mp4
[23:09:23 CEST] <BtbN> Well, ultrafast isn't something i'd call quality.
[23:09:33 CEST] <Rug> That is the current run.
[23:09:48 CEST] <Rug> I have swapped around veryfast nvenc
[23:09:49 CEST] <nevcairiel> The point is to match the speed
[23:10:09 CEST] <nevcairiel> Otherwise your comparisons is apples and oranges
[23:10:14 CEST] <Rug> with veryfast & nvenc the times are very close
[23:10:20 CEST] <BtbN> Rug, nvenc has no veryfast.
[23:10:29 CEST] <Rug> real 34m52.899s vs real 35m10.711s
[23:10:35 CEST] <BtbN> Or do you mean x264 veryfast vs. nvenc in llhq 2pass?
[23:10:38 CEST] <BtbN> Or hq?
[23:10:52 CEST] <Rug> let me paste both
[23:11:04 CEST] <Rug> ffmpeg -i 1784457.mp4 -r 29.97 -c:v nvenc -c:a aac -vf scale=3840:2160 -strict experimental -b:v 21700k -b:a 128k -y /mnt/converted_videos/Matt/4k_output-1.mp4
[23:11:11 CEST] <Rug> ffmpeg -i 1784457.mp4 -r 29.97 -c:v libx264 -preset veryfast -c:a aac -vf scale=3840:2160 -strict experimental -b:v 21700k -b:a 128k -y /mnt/converted_videos/Matt/4k_output-2.mp4
[23:11:16 CEST] <nevcairiel> How does 2pass with nvenc work anyway? Does it write a stat file?
[23:11:26 CEST] <BtbN> nevcairiel, it's not something i'd call 2pass
[23:11:40 CEST] <BtbN> I have no idea what it actualy does, but it does boost the quality quite a bit.
[23:11:48 CEST] <nevcairiel> Weird
[23:11:59 CEST] <BtbN> It's just an option you turn on when you are using one of the ll presets.
[23:12:00 CEST] <nevcairiel> So its all internal to the encoder?
[23:12:11 CEST] <BtbN> Like the libfdk afterburner.
[23:12:30 CEST] <Prelude2004c> hey guys.. but you are running at 21Mbit/s
[23:12:36 CEST] <Prelude2004c> i am trying to encode to 5Mbit/s
[23:12:48 CEST] <nevcairiel> And if you can combine it with ll also not adding high latency of something?
[23:12:56 CEST] <BtbN> It reduces the speed quite a bit, but improves the quality a lot, specialy at lower bitrates.
[23:13:10 CEST] <BtbN> 2pass only works with the low-latency presets.
[23:13:27 CEST] <Rug> I would welcome any suggestions anybody has to improve the quality
[23:13:42 CEST] <nevcairiel> How does llhq2pass compare to normal HQ then?
[23:13:48 CEST] <Prelude2004c> interesting.. so running at --preset fast.. uses 1300% of CPU
[23:13:50 CEST] <BtbN> Which is specialy strange, as the llhq(low latency high quality) would be expected to give a lower quality than the normal hq preset.
[23:14:10 CEST] <BtbN> If you are using higher bitrates, hq is propably better.
[23:14:17 CEST] <Prelude2004c> very fast runs at approx 500% cpu
[23:14:24 CEST] <BtbN> fix your CPU.
[23:14:43 CEST] <BtbN> But for real-time streaming stuff, llhq with 2pass is the best option.
[23:14:49 CEST] <Prelude2004c> fix CPU ?
[23:14:54 CEST] <Prelude2004c> 2 pass works in live streams ?
[23:14:55 CEST] <BtbN> I never did tests at non-streaming bitrates though.
[23:14:58 CEST] <Rug> Prelude2004c: use htop (or press 1 in top) to see what it is running at per-core
[23:15:38 CEST] <Prelude2004c> ffmpeg runs on all cores
[23:15:44 CEST] <Prelude2004c> threads are set to 0 so..
[23:15:48 CEST] <Rug> Prelude2004c: yeah
[23:15:59 CEST] <BtbN> veryfast doesn't even stress my old and slow quad-core i5. You are definitely doing something horribly wrong.
[23:16:20 CEST] <Prelude2004c> how can i be doing something wrong..
[23:16:23 CEST] <Prelude2004c> hum..
[23:16:35 CEST] <BtbN> Well, using an old and unsupported self-brewed ffmpeg version for example.
[23:17:53 CEST] <BtbN> Or an x264 without most optimizations...
[23:18:54 CEST] <Prelude2004c> my exact command is as follows
[23:18:54 CEST] <Prelude2004c> ffmpeg -i "udp://239.255.4.151:5000?ttl=100&fifo_size=1000000&overrun_nonfatal=1" -c:v h264 -preset veryfast -r 60 -g 60 -keyint_min 120 -b:v:0 5000k -bufsize 64k -maxrate 6000k -s 1280x720
[23:18:54 CEST] <Prelude2004c> -threads 0 -strict -2 -c:a:1 aac -ar 48000 -ac 2 -b:a:1 384k -f segment -hls_wrap 3 -hls_list_size 15 -segment_list ${HLS_PATH}/${CHN}/${CHN}_${name}.m3u8 -segment_list_type flat
[23:18:54 CEST] <Prelude2004c> -segment_list_flags live -segment_list_type m3u8 -segment_time 3 -segment_list_size 15 -segment_format mpegts "${HLS_PATH}/${CHN}/${CHN}_${name}_%08d.ts"
[23:19:05 CEST] <Prelude2004c> is there something wrong there ? because other then that i have done nothing
[23:19:51 CEST] <cone-056> ffmpeg 03Lukasz Marek 07master:a8c5b4551e03: lavu/dict: fix set function when reuse existing key pointer
[23:19:52 CEST] <Prelude2004c> my ffmpeg version is : 4.4.7 ( latest )
[23:19:52 CEST] <cone-056> ffmpeg 03Lukasz Marek 07master:96f896750d19: lavu/dict: add more tests
[23:19:53 CEST] <cone-056> ffmpeg 03Lukasz Marek 07master:0bf980919ef9: fate: add AVDictionary tests
[23:20:20 CEST] <jamrial> you mean 2.4.7?
[23:21:07 CEST] <Prelude2004c> ffmpeg version git-2015-03-28-303c3da Copyright (c) 2000-2015 the FFmpeg developers
[23:21:07 CEST] <Prelude2004c> built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-11)
[23:21:12 CEST] <Prelude2004c> oops
[23:21:16 CEST] <Prelude2004c> thats gcc :P haha
[23:22:00 CEST] <Prelude2004c> well i just downloaded it from GIT so
[23:27:44 CEST] <cone-056> ffmpeg 03James Almer 07master:300018373248: avcodec/pngenc: don't return a value in a void function
[23:29:55 CEST] <michaelni> jamrial, fixed, i had missed the IRC ping until now
[23:37:52 CEST] <cone-056> ffmpeg 03Stephen Hutchinson 07master:d858c3a18f19: avisynth: Fix detection of AviSynth 2.5
[23:49:31 CEST] <llogan> was it ever possible to --enable-libfaac without --enable-nonfree? I'm looking at an old distributed thing. possible license violator.
[23:50:54 CEST] <j-b> yes
[23:50:58 CEST] <j-b> a long long time ago
[23:51:09 CEST] <j-b> until Diego looked at the code
[23:52:23 CEST] <llogan> thanks. i can't memorize all of this stuff. so i guess alcohol does make me dumber...
[23:52:51 CEST] <j-b> balmer's peak
[23:53:28 CEST] <llogan> a fine, fine line
[00:00:00 CEST] --- Fri Apr 3 2015
More information about the Ffmpeg-devel-irc
mailing list