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

[burek]

[00:00:17 CEST] <blap> Susan Wojcicki intensifies
[00:02:06 CEST] <jya> I don't know what ffmpeg is doing when creating files, but that's now the 3 files it has created with a size of 0 which I can no longer delete
[00:02:20 CEST] <jya> permission denied
[00:03:03 CEST] <durandal_1707> how you managed that....?
[00:03:17 CEST] <jya> cannot get attributes for "c:\Users\mozilla\Work\Mozilla\mozilla-central\toolkit\components\gfx\content\test2.mp4":  Access Denied
[00:03:33 CEST] <jya> durandal_1707: I have no ideas :)
[00:03:43 CEST] <jya> got some error at some stage about streams
[00:03:52 CEST] <iive> jya: windows?
[00:03:55 CEST] <jya> just trying the various options , often wrongly
[00:04:02 CEST] <jya> yes on windows
[00:04:10 CEST] <iive> probably a ffmpeg is still holding the files open
[00:04:22 CEST] <jya> even on a privileged finder; delete option has been removed
[00:04:43 CEST] <jya> no ffmpeg process running
[00:05:13 CEST] <iive> then something else is holding them. sysinternal suite from microsoft have some utils that might help.
[00:05:43 CEST] <iive> i guess you've run scandisk already
[00:05:54 CEST] <jya> ah it was chrome holding the file even if it has finished playing it
[00:06:04 CEST] <jya> can reproduce the issue in chrome too
[01:07:18 CEST] <kmax> Hello
[01:07:50 CEST] <kmax> looking for advice about making hls stream start faster
[01:08:06 CEST] <kmax> using FFMPEG to create m3u8 and play it via Clappr Player
[01:08:13 CEST] <kmax> takes about 15 seconds right now
[01:08:18 CEST] <kmax> to start playing
[01:08:35 CEST] <kmax> keyframes and chunks are set to 5 seconds
[01:10:48 CEST] <bencc> 5*3=15 so that makes sense
[01:10:55 CEST] <bencc> you can try using 2 seconds segment
[01:11:10 CEST] <kmax> we did... was not much different
[01:11:34 CEST] <kmax> how do people use HLS then?  that seems like a really long connect time
[01:11:47 CEST] <kmax> the other platforms we use connect in seconds... :)
[01:11:56 CEST] <bencc> kmax: https://www.wowza.com/blog/hls-latency-sucks-but-heres-how-to-fix-it
[01:12:12 CEST] <bencc> depends on your use case
[01:12:13 CEST] <kmax> hey thank you!
[01:12:27 CEST] <furq> kmax: are you sure you're actually getting 2-second chunks
[01:12:46 CEST] <bencc> you'll always get 3*chunk-time latency
[01:12:58 CEST] <furq> yeah it's at least two chunks and potentially way more
[01:13:28 CEST] <bencc> kmax: wowza says you can even use 0.5 second. not sure if it'll work
[01:13:32 CEST] <furq> but iirc with the segment muxer you still need to set the gop size when encoding
[01:13:46 CEST] <furq> otherwise it'll just cut at gop boundaries
[01:14:36 CEST] <bencc> that's the command I'm using
[01:14:38 CEST] <bencc> https://pastebin.com/WVpEvYWL
[01:14:38 CEST] <kmax> you mean it needs at least 2 chunks before it will start?
[01:14:43 CEST] <bencc> yes
[01:14:48 CEST] <bencc> for buffering
[01:14:49 CEST] <furq> the player won't start until it's buffered two chunks
[01:14:53 CEST] <furq> or more, depending on the player
[01:14:55 CEST] <bencc> otherwise it won't be stable
[01:15:19 CEST] <bencc> furq: does my command correctly set the gop size?
[01:15:58 CEST] <furq> idk i've never used force_key_frames
[01:16:13 CEST] <furq> when i've had to do this i just used -g and -x264-params keyint-min
[01:16:33 CEST] <JEEB> hint: scenecut=0 is what you see x264's mailing list note
[01:16:38 CEST] <JEEB> -g and that
[01:16:42 CEST] <furq> does it make any difference
[01:16:44 CEST] <JEEB> yes
[01:16:50 CEST] <furq> oh really
[01:16:57 CEST] <JEEB> keyint-min does different things and is strictly not recommended on the x264 ML
[01:17:01 CEST] <JEEB> you can find details there
[01:17:02 CEST] <furq> fair enough
[01:17:13 CEST] <JEEB> just disable scenecut if you need static GOPs
[01:17:14 CEST] <furq> that seems odd
[01:17:19 CEST] <bencc> JEEB: do you have a complete command example?
[01:17:42 CEST] <furq> i assume force_key_frames gets passed to the encoder somehow
[01:18:00 CEST] <furq> but if not, -r 25 -g 125 -x264-params scenecut=0 -segment_time 5
[01:18:18 CEST] <furq> or whatever as long as -g is -r * -segment_time
[01:18:45 CEST] <kmax> i got lost here... what does this command do?
[01:19:06 CEST] <DHE> I thought it was no-scenecut
[01:19:18 CEST] <JEEB> in cli yes
[01:19:26 CEST] <DHE> also the HLS muxer uses -hls_time instead of -segment_time
[01:19:46 CEST] <DHE> kmax: you're not encrypting the segments are you?
[01:19:48 CEST] <JEEB> also no-scenecut=1 might work in libx264 API as well
[01:19:54 CEST] <kmax> no
[01:20:19 CEST] <JEEB> but if you look at the x264 ML you will see scenecut=0 being the usually recommended way of setting the parameter
[01:21:13 CEST] <DHE> yeah a quick source scan says that's probably right
[01:25:17 CEST] <kmax> let me make sure I have this...
[01:25:27 CEST] <kmax> this is the command we should try. correct?
[01:25:28 CEST] <kmax>  -r 25 -g 125 -x264-params scenecut=0 -segment_time 5
[01:25:57 CEST] <DHE> -r 25 changes the output framerate. is that what you want?
[01:26:41 CEST] <kmax> just trying to make the video start quicker...
[01:26:53 CEST] <kmax> hoping to create the m3u8 quicker
[01:26:59 CEST] <kmax> by making shorter files
[01:27:15 CEST] <kmax> but setting the keyframes lower has not helped...
[01:27:59 CEST] <kmax> yeah i am sure we would leave the -r flag out
[01:34:09 CEST] <DHE> just to clarify, the issue is that the delay between the player starting up and the video actually beginning to play is too long?
[01:35:32 CEST] <kmax> no the issue is how long it takes the m3u8 to be created
[01:35:53 CEST] <kmax> you can look in chrome console... and the m3u8 cannot be reached...
[01:35:57 CEST] <kmax> for about 15 seconds...
[01:36:12 CEST] <kmax> then once it is created... the player starts right up
[01:36:59 CEST] <kmax> seems like thats just how long it takes for the m3u8 to be created...
[01:37:17 CEST] <kmax> we tried different combos of settings for keyframes and chunk size
[01:37:23 CEST] <kmax> 2, 4,5 etc
[01:37:49 CEST] <kmax> when we set it to 10 the delay is like 30 seconds
[01:38:02 CEST] <kmax> Clappr player wants to buffer 3 chunks before starting
[01:49:54 CEST] <DHE> oh... well that's not going to help. it sounds like you're generating the m3u8 on the fly and the client has to wait around for it to start
[01:50:11 CEST] <DHE> which is just the wrong way to do it
[02:00:57 CEST] <cryptodechange> still telecined/interlaced frames with fieldmatch,yadif=deint=interlaced,decimate :(
[02:01:19 CEST] <cryptodechange> lots of 'Frame #X at X is still interlaced' messages
[02:02:17 CEST] <kepstin> cryptodechange: yeah, fieldmatch can in some cases flag frames that still have combing as progressive, which means that yadif will skip them
[02:03:11 CEST] <kepstin> there's a bunch of thresholds you can tweak in fieldmatch
[02:03:43 CEST] <kepstin> or you can also try throwing in an idet filter after it to re-check the frames
[02:04:43 CEST] <kepstin> seeing a bunch of 'Frame #X at X is still interlaced' is expected - those are the ones that are flagged for yadif to fix. It's the ones where you don't see that message which are the problem :)
[02:14:20 CEST] <cryptodechange> Yeah it seems the frames I'm noticing were not logged
[02:17:28 CEST] <CoreX> cryptodechange what type of content are you trying to encode with fieldmatch
[02:25:09 CEST] <cryptodechange> DVD animation
[02:25:15 CEST] <cryptodechange> @CoreX
[02:51:46 CEST] <kmax> DHE are you still here?
[02:51:55 CEST] <kmax> yes we are generating the M3u8 on the fly
[02:52:15 CEST] <kmax> its that time to create it that is causing the delay in the video starting.
[02:52:21 CEST] <kmax> once the hls play list is made...
[02:52:27 CEST] <kmax> the video starts instantly from then on
[02:52:37 CEST] <kmax> but we cant have all the streams going all the time
[02:52:48 CEST] <kmax> so we have to start them as they are requested
[02:53:01 CEST] <kmax> it is RTSP video from surveillance IP cameras
[02:54:47 CEST] <kmax> @DHE are you still on?
[02:55:03 CEST] <kmax> #DHE I dont know how to tag someone in this chat
[02:55:24 CEST] <DHE> no tags. just say their name
[02:55:33 CEST] <DHE> # is a channel. @ is a channel-op
[02:55:34 CEST] <kmax> thanks
[02:55:46 CEST] <kmax> you were saying something about us going about this the wrong way
[02:56:07 CEST] <kmax> creating the m3u8 on the fly...
[02:56:10 CEST] <DHE> you're trying to generate an HLS playlist on the fly and it's not possible to run them all the time instead
[02:56:41 CEST] <kmax> right.
[02:56:57 CEST] <kmax> they do generate on the fly... and it works well... but the start time is more than we would like
[02:57:13 CEST] <DHE> does the video need to be transcoded? is there a limiting factor preventing them from running all the time?
[02:57:17 CEST] <DHE> that's what HLS is really intended for
[02:57:42 CEST] <kmax> yeah... the limiting factor is that most the clients have low bandwidth
[02:57:51 CEST] <kmax> and if all cameras are streaming at the same time it is too much
[02:57:57 CEST] <kmax> for the upload speed they have
[02:57:58 CEST] <DHE> so you need to transcode which is killing the CPU?
[02:58:14 CEST] <kmax> so we need to just start the cameras that are requested.. and being viewed at that time
[02:58:29 CEST] <kmax> out of 16 cams they might only have 4 being watched at any given time
[02:58:51 CEST] <kmax> actually the cpu and memory are doing well
[02:59:07 CEST] <kmax> it would be great to just let them all stream all the time...
[02:59:15 CEST] <kmax> but it would tax the clients internet too much
[02:59:24 CEST] <kmax> so can only play the cameras on demand
[02:59:45 CEST] <kmax> and it has to be html5... so there is no plugin and it will work on all devices
[03:00:03 CEST] <kmax> this is working... and we are near "completion"  :)
[03:00:17 CEST] <kmax> but i really need to lower the start time if i can possibly find a way
[03:06:31 CEST] <kmax>  
[03:07:18 CEST] <DHE> you're transoding with libx264?
[03:08:01 CEST] <kmax> yes
[03:08:15 CEST] <kmax> i admit i am working with a developer...
[03:08:24 CEST] <kmax> but i have been in the code some with him...
[03:08:32 CEST] <kmax> i am fairly sure the answer is yes.
[03:08:40 CEST] <DHE> for experimentation purposes, try adding -tune:v zerolatency
[03:08:50 CEST] <DHE> it'll have a negative quality impact, but see if it improves startup delays.
[03:08:56 CEST] <kmax> he seems to have run out of ideas...so i am trying to find something  :)
[03:09:30 CEST] <kmax> thanks so much for the idea!
[03:55:07 CEST] <cryptodechange> trying 'dejudder,fps=30000/1001,fieldmatch,yadif=deint=interlaced,decimate'
[03:55:11 CEST] <cryptodechange> though I don't think that will change anything
[04:37:28 CEST] <kepstin> use dejudder after the decimate if anything, it'll fix the frame timestamps
[04:37:48 CEST] <kepstin> but that won't make any difference to whether interlaced frames pass through
[04:55:41 CEST] <cryptodechange> should I bother with fps=30000/1001?
[04:56:16 CEST] <kepstin> if you have a good source it's not necessary, but it won't hurt
[05:03:47 CEST] <cryptodechange> it seems every 4th and 5th frame is interlaced, should I set the mode to pcn?
[07:06:17 CEST] <cryptodechange> still no luck :(
[07:06:19 CEST] <cryptodechange> https://imgur.com/a/R19yp
[08:14:06 CEST] <bray90820> Would this be a good place to get help with general video editing?\
[09:24:59 CEST] <stevenliu> Hello everyone, it there have any facedetect filter?
[09:25:24 CEST] <stevenliu> or it need develop by my self?
[09:37:01 CEST] <alone> stevenliu, i guess to early for answering here
[09:37:38 CEST] <stevenliu> 
[09:38:55 CEST] <alone> 8:38 UK time, US - 03:38
[09:39:00 CEST] <alone> (EST)
[09:39:06 CEST] <alone> r u from Asia?
[09:56:24 CEST] <bigx> hello there, anyone with nvenc experience?
[09:56:35 CEST] <bigx> actually, nvdec, to be precise
[09:57:27 CEST] <bigx> in the doc (https://developer.nvidia.com/nvidia-video-codec-sdk#NVDECFeatures) vp8 can be hw decoded when the pixel format is yuv420
[09:57:57 CEST] <bigx> does it mean vp8 with yuva420 pixel format will not be hw decoded?
[09:58:31 CEST] <bigx> (vp8 with yuva420, is a vp8 video with an alpha channel)
[09:59:50 CEST] <JEEB> from hwdec you generally get either 8 or 10 bit 4:2:0 YCbCr, pronto
[10:00:11 CEST] <JEEB> that said alpha in VPx formats is IIRC separate so you can try to handle it separately, but generally that means decoding the whole stream :D
[10:00:30 CEST] <JEEB> since the alpha-only decoding generally isn't available as a separate
[10:00:32 CEST] <JEEB> thing
[10:14:39 CEST] <wondiws> I have to set "extern "C" around my avcodec.h etc includes when using C++, is this correct?
[10:14:52 CEST] <JEEB> yes
[10:14:56 CEST] <JEEB> since FFmpeg's libraries are C
[10:15:04 CEST] <JEEB> and you want to use them from C++
[10:15:38 CEST] <wondiws> JEEB, you're not going to put #ifdef CPP in the ffmpeg headers? :)
[10:16:05 CEST] <JEEB> I think that was decided at some point so that's how it works with FFmpeg
[10:16:16 CEST] <JEEB> and has for more than 10 years by now I think
[10:19:10 CEST] <alone> JEBB hello
[10:19:51 CEST] <alone> i am still trying to understand, it's not possible to grab screen with right colors via nvenc
[10:19:57 CEST] <alone> but without success
[10:20:20 CEST] <alone> yes, i am understand nvenc can only 420p for Kepler Core
[10:20:35 CEST] <alone> this is meaning i can't recording right colors?
[10:25:35 CEST] <BtbN> nvenc is not involved with screen capture
[10:26:05 CEST] <alone> BtBn what you mean?
[10:26:12 CEST] <BtbN> nvenc is an encoder.
[10:26:19 CEST] <BtbN> It does not capture anything, it just gets fed frames
[10:26:20 CEST] <alone> yes, i know
[10:26:39 CEST] <bigx> Thanks JEEB , but I dont get it, look at this picture: https://developer.nvidia.com/sites/default/files/akamai/designworks/images/VCSDK_DEC_006.PNG
[10:26:45 CEST] <BtbN> And I never heard of anyone complaining about bad colors with nvenc. So I highly suspect it's something else messing up.
[10:27:09 CEST] <alone> thank you. but may be you know when, how can i grab screen with nvenc 264?
[10:27:24 CEST] <alone> for CPU my line is:
[10:27:25 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx264 -profile:v high444 -crf 0 -preset:v ultrafast E:\Screen.Capturing\%yyyymmhhmmss%.mkv
[10:27:31 CEST] <alone> it's perfect.
[10:27:50 CEST] <alone> for GPU:
[10:27:51 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:0:0 -c:v h264_nvenc -qp 0 -pix_fmt rgb0 h264-nVidia.mkv
[10:28:15 CEST] <alone> this have wrong colors.
[10:28:24 CEST] <BtbN> Use the lossless preset if you want lossless with nvenc.
[10:28:40 CEST] <alone> yes, but with Kepler Cores there is no lossless.
[10:28:44 CEST] <alone> only with Maxwell
[10:28:48 CEST] <BtbN> And I'd recommend against passing rgb to nvenc.
[10:28:51 CEST] <alone> from 1st generation.
[10:29:04 CEST] <BtbN> Just pass it normal yuv, ffmpeg is better at converting
[10:29:32 CEST] <BtbN> And how do you define "wrong colors"
[10:29:51 CEST] <alone> with yuv420p will be even worst, then with rgb0
[10:30:06 CEST] <alone> i tryed all - yuv420p nv12 p010le yuv444p yuv444p16le bgr0 rgb0 cuda
[10:30:28 CEST] <alone> 444p of course not working with Kepler cores ;-((
[10:30:48 CEST] <BtbN> yuv420 does not mess up colors.
[10:31:15 CEST] <alone> 420 only one colorspace for kepler ;(
[10:31:37 CEST] <alone> i have 32bit screen. with 16 bit screen is same.
[10:31:47 CEST] <BtbN> You still haven't even told me what is wrong...
[10:31:48 CEST] <alone> i have only 3 colors - red, green and white.
[10:31:56 CEST] <BtbN> That's not how screens work.
[10:32:16 CEST] <alone> BtbN, just a moment
[10:32:44 CEST] <BtbN> You mean there is no blue in the picture?
[10:32:49 CEST] <BtbN> But white, which contains blue?
[10:33:04 CEST] <alone> 1 sec
[10:33:06 CEST] <alone> i will show
[10:34:36 CEST] <alone> can u see this? https://ibin.co/3ZR3WwZgFZor.png
[10:35:12 CEST] <BtbN> I don't see anything that seems immdiately wrong
[10:37:12 CEST] <alone> https://ibin.co/3ZR4KtmGbiWU.png
[10:37:18 CEST] <alone> can u see this?
[10:37:28 CEST] <alone> first - with nvenc
[10:37:32 CEST] <alone> second - with CPU
[10:37:55 CEST] <alone> i know, my red = 255,0,0. My green - 0,255,0.
[10:38:18 CEST] <alone> with CPU this is will be same after grabbing. with nvenc - no.
[10:38:21 CEST] <BtbN> All the colors are there. It's just a lower quality encode.
[10:38:53 CEST] <alone> i thought about it. yes. this is not fully lossless.
[10:38:55 CEST] <alone> but
[10:39:16 CEST] <alone> ffmpeg -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx264 -profile:v high444 -crf 0 -preset:v ultrafast output.mkv
[10:39:24 CEST] <alone> this is via CPU encoding.
[10:39:36 CEST] <alone> this is perfect (#2 screen shot)
[10:39:44 CEST] <alone> HOW can i do SAME with NVenc?
[10:39:56 CEST] <BtbN> There is no color missing, and no color obviously swapped. I don't see anything wrong, except for the picture quality.
[10:40:49 CEST] <BtbN> And the quality hit in this case can very well come from the halved color resolution of yuv420 compared to 444
[10:41:32 CEST] <alone> yes, i am "understand" that, becouse 444 - this is profile with CPU and it's perfect
[10:41:47 CEST] <alone> but it's impossible to have this via nvenc?
[10:41:50 CEST] <alone> right?
[10:42:01 CEST] <BtbN> not on Kepler, no
[10:42:05 CEST] <alone> yes.
[10:42:08 CEST] <alone> guess same.
[10:42:22 CEST] <alone> thank you very much BtbN
[10:42:45 CEST] <alone> just 80% with CPU and 55% with GPU is different ;))
[10:42:54 CEST] <BtbN> 55% with nvenc is still way too much
[10:42:58 CEST] <BtbN> should be closer to 0
[10:43:05 CEST] <alone> why?
[10:43:15 CEST] <BtbN> Because it's full hardware offload
[10:43:23 CEST] <alone> well, i have GTX 640
[10:43:27 CEST] <BtbN> so?
[10:43:35 CEST] <BtbN> The encoding is still 100% offloaded to the card
[10:43:42 CEST] <alone> it's 2012 card. may be it's too old?
[10:44:00 CEST] <BtbN> I'd recommend just getting a 1050
[10:44:09 CEST] <BtbN> it's not expensive and has the best nvenc encoder around currently
[10:44:37 CEST] <alone> this is Maxwell 1st generation?
[10:44:42 CEST] <alone> processor?
[10:44:43 CEST] <BtbN> That's Pascal 2nd gen
[10:44:47 CEST] <alone> wow.
[10:45:59 CEST] <alone> 1 sec
[10:46:05 CEST] <alone> trying to search a tables
[10:46:23 CEST] <BtbN> A 1050 will _by far_ outperform your 640 in every possible aspect
[10:46:29 CEST] <alone> https://developer.nvidia.com/nvidia-video-codec-sdk
[10:46:30 CEST] <alone> this one
[10:47:15 CEST] <alone> ok, BtbN, of course i see you
[10:47:46 CEST] <alone> i guess same. i am not too familiar with cores, specs etc before yearsterday. sorry please for my.. unknowing
[10:48:46 CEST] <alone> this Pascal card
[10:48:53 CEST] <alone> can even do h265 lossless
[10:48:54 CEST] <alone> right?
[10:49:14 CEST] <BtbN> I think so, but hevc hardware encoding is pointless
[10:49:20 CEST] <alone> ffmpeg -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx265 -preset ultrafast -x265-params lossless=1 output.mkv
[10:49:23 CEST] <BtbN> It's not better then h264 at all
[10:49:40 CEST] <alone> i use this for h265, but it's 100%
[10:49:43 CEST] <alone> of CPU.
[10:49:46 CEST] <alone> of my ;)
[10:49:59 CEST] <alone> i can working with this, but.. 100%..
[10:50:19 CEST] <alone> 264 have NATIVE lossless mode?
[10:50:22 CEST] <BtbN> x265 needs 8 cores or more to be able to encode in realtime
[10:50:31 CEST] <alone> 8 corers of CPU?
[10:50:36 CEST] <alone> cores.
[10:50:48 CEST] <alone> GPU i guess - hunderents cores..
[10:50:49 CEST] <BtbN> My 8 core Ryzen can barely handle 1080p60 in realtime
[10:51:03 CEST] <BtbN> GPUs aren't useful for video encoding. It's a dedicated encoder chip.
[10:51:27 CEST] <furq> x265 lossless isn't particularly good is it
[10:51:29 CEST] <alone> well, to be honest, my only goal have a screen capturing what I AM doing with lossless and not big size
[10:51:43 CEST] <BtbN> I never bothered with lossless hevc.
[10:51:43 CEST] <furq> try ffv1 or x264 lossless
[10:51:57 CEST] <BtbN> Even when hardware encoded, I don't see the point over h264
[10:52:21 CEST] <alone> ffv1 have lossless too?
[10:52:27 CEST] <furq> ffv1 is lossless
[10:52:33 CEST] <alone> just a moment
[10:52:41 CEST] <BtbN> if you want player compatiblity, it's not the best idea though
[10:52:52 CEST] <furq> the same is true of x265 lossless though
[10:53:01 CEST] <alone> no, i am fun on mplayer, now  - on MPV
[10:53:02 CEST] <alone> ;)
[10:53:04 CEST] <alone> it's only for me.
[10:53:07 CEST] <furq> mpv will be fine
[10:53:12 CEST] <alone> for my post analisys.
[10:53:20 CEST] <alone> internal usage.
[10:53:53 CEST] <furq> also qtrle might be worth looking into for screen capturing
[10:53:54 CEST] <alone> yes, h265 not so.. distributed yet.
[10:54:05 CEST] <alone> ffmpeg -f gdigrab -i desktop -vf crop=1600:900:5:0 -vcodec qtrle -strftime 1 capture.mov
[10:54:12 CEST] <alone> for qrtle i have this line.
[10:54:16 CEST] <alone> this is working.
[10:54:17 CEST] <furq> qtrle will either be surprisingly good or total shit
[10:54:25 CEST] <furq> depending on what you're capturing
[10:54:33 CEST] <alone> but sizes..
[10:54:40 CEST] <furq> yeah if it's massive then stick with ffv1
[10:55:06 CEST] <alone> i mean megabyes, no - GIGAbytes. of course 7zip will be compressing qrtle files VERY VERY good - 10 times.
[10:55:42 CEST] <alone> ffv1 - dont know about it.
[10:55:45 CEST] <alone> thank you
[10:56:27 CEST] <alone> well, h265 lossless it's good ration with size. and after recording, i can always 7zip it to 1|2 or even 1|3
[10:56:36 CEST] <alone> it's OK but CPU!!!! 100%
[10:56:37 CEST] <alone> ;)
[10:56:43 CEST] <furq> it's probably not a good sign if you can compress it further
[10:57:46 CEST] <alone> ok, of course i would to have something other codec with ffmpeg for my 3-4 colors, but i dont know
[10:58:38 CEST] <alone> i guess ffv1 CAN be compressing VERY well with 7zip
[10:58:56 CEST] <furq> i should hope not
[10:59:10 CEST] <alone> hm...
[10:59:35 CEST] <alone> do u have working line for ffv1?
[11:00:56 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v ffv1 E:\Screen.Capturing\%yyyymmhhmmss%.mkv
[11:01:09 CEST] <alone> ;) it's generated MKV but ...
[11:01:39 CEST] <alone> oh!
[11:01:47 CEST] <alone> mpv does not read it properly
[11:01:52 CEST] <alone> my mplayer - does!
[11:01:59 CEST] <alone> but mplayer does
[11:02:21 CEST] <alone> mpv showing only gray and white squares ;)
[11:02:23 CEST] <alone> funy.
[11:02:27 CEST] <alone> funny.
[11:02:29 CEST] <furq> weird
[11:02:31 CEST] <furq> mpv should play it fine
[11:02:48 CEST] <alone> yes, but it's seems some times
[11:02:57 CEST] <alone> yes, i am agree. mpv - cool. but
[11:03:45 CEST] <alone> well, 4 sec - 18MB
[11:03:53 CEST] <alone> after 7zip - 8 mb
[11:04:55 CEST] <durandal_1707> alone: pastebin your mpv output of playing that file
[11:05:17 CEST] <alone> mpv myfile.mkv >123.txt
[11:05:19 CEST] <alone> so?
[11:06:15 CEST] <durandal_1707> alone: you dont know how to copy terminal output?
[11:06:37 CEST] <alone> i am at windows 7 64. but >123.txt it's ok?
[11:06:51 CEST] <durandal_1707> nope
[11:06:57 CEST] <furq> what mpv version
[11:07:04 CEST] <alone> https://pastebin.com/L4EPB3Yf
[11:07:11 CEST] <alone> just a moment
[11:07:47 CEST] <furq> bgra ffv1 works fine here in 0.26
[11:08:01 CEST] <alone> mpv --version?
[11:08:02 CEST] <furq> so probably upgrade if you're on an older build
[11:08:10 CEST] <furq> sure
[11:08:48 CEST] <alone> empty ontput ;( with mpv --version
[11:10:41 CEST] <alone> no!
[11:11:13 CEST] <alone> with LATEST (i am downloaded it 1 minutes ago) - this is same
[11:11:22 CEST] <alone> squres... white and gray
[11:11:24 CEST] <alone> really.
[11:12:35 CEST] <alone> well, may be windows issue
[11:12:38 CEST] <alone> i dont know
[11:15:03 CEST] <alone> BtbN, why 55% of CPU usage with nvenc?
[11:15:13 CEST] <alone> if it's dedicated chip for encoding?
[11:22:38 CEST] <alone> .
[11:23:38 CEST] <alone-y> BtbN, why 55% of CPU usage with nvenc?
[11:23:40 CEST] <alone-y> if it's dedicated chip for encoding?
[11:24:02 CEST] <BtbN> Because you're doing something else on the CPU, or are not actually using nvenc.
[11:24:56 CEST] <alone-y> but without ffmpeg it's 5-8%
[11:24:58 CEST] <alone-y> not more.
[11:25:15 CEST] <alone-y> with encoding 55%
[11:27:49 CEST] <alone-y> i am closing all , besides mIRC
[11:27:52 CEST] <alone-y> it's 25%
[11:27:56 CEST] <alone-y> i guess Mozilla
[11:29:55 CEST] <alone-y> interesting
[11:30:05 CEST] <alone-y> mozilla was even at OTHER monitor
[12:20:54 CEST] <wondiws> is it easy to update deprecated code? What do I need to use instead of avcodec_encode_audio2?
[12:26:17 CEST] <durandal_1707> its in headers
[12:26:44 CEST] <DHE> you use avcodec_send_frame and avcodec_receive_packet
[12:27:05 CEST] <wondiws> DHE, that is what I should use instead?
[12:27:50 CEST] <DHE> check the docs for details. the semantics have changed a bit since one end may accept multiple inputs/outputs or may block if overfilled
[12:31:48 CEST] <bigx> hello there, I have some troubles running a ffmpeg command
[12:32:00 CEST] <bigx> here it is : ffmpeg -y -i result.png -hwaccel cuvid -c:v vp8_cuvid -i test.webm -c:v h264_nvenc -b:v 10M -pix_fmt yuv420p -r 30 -an -filter_complex "[0:v][1:v]overlay=eval='init'[merge];[merge]lut3d=lut.cube" testResult.mp4
[12:32:42 CEST] <bigx> and here is the result: https://pastebin.com/hWyVvaaL
[12:34:25 CEST] <bigx> from what I see, it seems a function is not implemented (Failed to inject frame into filter network: Function not implemented)
[12:34:45 CEST] <jkqxz> bigx:  You asked for hardware surface output from the decoder but your filter graph is software.  Remove the "-hwaccel cuvid"
[12:36:07 CEST] <bigx> jkqxz: thanks I try asap, so I will end up in a case as mentinned here (partial hw transcode case here) https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNvDecode
[12:37:10 CEST] <bigx> thanks jkqxz it works
[12:37:26 CEST] <bigx> (but at 10fps on a Tesla M60 gpu :( )
[12:39:30 CEST] <bigx> one other stange thing is that: ffmpeg -y -hwaccel cuvid -c:v vp8_cuvid -i test.webm -c:v h264_nvenc -b:v 10M -pix_fmt yuv420p -r 30 -an testResult.mp4
[12:39:36 CEST] <bigx> raises the same error
[12:42:50 CEST] <jkqxz> -pix_fmt yuv420p is forcing a conversion in software.
[12:42:58 CEST] <jkqxz> Remove it if you don't want that.
[12:43:12 CEST] <bigx> yes just noticed it
[12:49:03 CEST] <bigx> darn, i feel sad, because I top at 10 fps because of the filters :(
[12:49:28 CEST] <bigx> does anyone see any improvements here ?
[12:49:36 CEST] <bigx> ffmpeg -y -i result.png -c:v vp8_cuvid -i test.webm -c:v h264_nvenc -preset llhq -filter_complex "[0:v][1:v]overlay=eval='init'[merge];[merge]lut3d=lut.cube" testResult.mp4
[13:15:54 CEST] <deepak> Hi! I am trying to understand this command ffmpeg -f concat -safe 0 -i mylist.txt -c copy output
[13:16:04 CEST] <deepak> I am unable to get what -f means
[13:16:08 CEST] <JEEB> demuxer
[13:16:18 CEST] <deepak> and what concat as a filter mean?
[13:16:28 CEST] <JEEB> so there's a special "demuxer" called "concat"
[13:16:36 CEST] <JEEB> it's not a filter :)
[13:16:41 CEST] <JEEB> although there's also a filter
[13:17:05 CEST] <JEEB> (there's like three different concat things in FFmpeg, all of which work for some specific use case)
[13:17:14 CEST] <JEEB> concat protocol, concat demuxer, concat filter
[13:17:18 CEST] <q66> concat filter lets you concat wildly different streams
[13:17:30 CEST] <q66> demuxer when the codec/params are the same
[13:18:02 CEST] <deepak> so how can I identify is the given command using it concat as demux/filter or protocol?
[13:18:26 CEST] <q66> by reading the wiki page
[13:18:28 CEST] <deepak> q66:thanks
[13:18:51 CEST] <q66> https://trac.ffmpeg.org/wiki/Concatenate
[15:39:03 CEST] <bigx> hello, it seems vp8_cuvid decoder doesnt handle transparency??
[15:39:30 CEST] <JEEB> not surprising. it's a specific feature of VPx formats and not required for the actual base YCbCr
[15:39:46 CEST] <JEEB> also HW decoders generally don't output data formats with alpha
[15:40:05 CEST] <JEEB> you either get 8bit YCbCr or 10bit YCbCr, 4:2:0
[15:40:31 CEST] <JEEB> so if you need the alpha from the encoded file, then SW decoding from libvpx I think is the only alternative?
[15:40:41 CEST] <JEEB> since I don't know if the libavcodec decoder supports the alpha stuff
[15:53:52 CEST] <bigx> JEEB: yes libvpx preserves alpha
[16:00:54 CEST] <alqemyst> hi, does anybody knows what 3.3.x changes to quick sync in comparison with 3.2.x?
[16:01:08 CEST] <alqemyst> e.g. ffmpeg -y -i udp://239.192.120.102:1234 -map 0:v:0 -map 0:a:0 -c:v h264_qsv -profile:v high -preset:v veryfast -b:v 2M -maxrate:v 2M -c:a libfdk_aac -b:a 64k -f rawvideo /dev/null
[16:01:25 CEST] <alqemyst> works with 3.2.7, but with 3.3.3 it throws
[16:01:33 CEST] <alqemyst> Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode.
[16:01:33 CEST] <alqemyst> Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[18:24:42 CEST] <thebombzen> alqemyst: why are you using -f rawvideo
[18:24:56 CEST] <thebombzen> I believe you're trying to use -f null -
[18:26:53 CEST] <alqemyst> yes, but that's not too important now
[18:27:04 CEST] <alqemyst> thanks for correction
[18:27:30 CEST] <thebombzen> either way
[18:27:36 CEST] <alqemyst> whatever you specify as output it will fail on 3.3.x
[18:27:56 CEST] <alqemyst> oki
[18:44:11 CEST] <alqemyst> 3.2.7: https://pastebin.com/XGbg1w02
[18:44:23 CEST] <alqemyst> 3.3.3: https://pastebin.com/WKTynFdL
[18:47:03 CEST] <c_14> set -look_ahead 0
[18:48:10 CEST] <alqemyst> then it seems like it is encoding, but console is filled with:
[18:48:11 CEST] <alqemyst> [h264_qsv @ 0x29db760] Warning during encoding: incompatible video parameters (5)
[18:49:34 CEST] <alqemyst> also
[18:49:36 CEST] <alqemyst> [h264_qsv @ 0x3934840] Warning in encoder initialization: partial acceleration (4)
[18:51:48 CEST] <c_14> can you bisect?
[18:52:02 CEST] <c_14> or try a git-master build
[18:52:13 CEST] <alqemyst> sure
[18:57:08 CEST] <alqemyst> with git master it is even worse
[18:57:11 CEST] <alqemyst> [h264_qsv @ 0x2da0ce0] No device available for encoder (device type qsv for codec h264_qsv).
[18:57:11 CEST] <alqemyst> [h264_qsv @ 0x2da0ce0] Encoder will work with partial HW acceleration
[18:57:12 CEST] <alqemyst> [h264_qsv @ 0x2da0ce0] Warning in encoder initialization: partial acceleration (4)
[18:57:27 CEST] <alqemyst> and then again filled with:
[18:57:29 CEST] <alqemyst> [h264_qsv @ 0x2da0ce0] Warning during encoding: incompatible video parameters (5)
[18:58:21 CEST] <c_14> Try a bisect between 3.3.3 and 3.2.7 and/or create a bugreport with as much information (and terminal output) as possible
[18:58:25 CEST] <c_14> seems like a regression
[18:59:01 CEST] <alqemyst> I thought so
[18:59:05 CEST] <alqemyst> it seems like
[18:59:06 CEST] <alqemyst> https://trac.ffmpeg.org/ticket/6418
[18:59:57 CEST] <c_14> 3 months ago might fit, if you can find the commit and add info to the tracker it should help
[19:00:21 CEST] <mozzarella> guys
[19:00:27 CEST] <alqemyst> thanks
[19:00:38 CEST] <mozzarella> why do I keep getting "Past duration too large"?
[19:11:51 CEST] <IchGucksLive> hi  what is the oposit argument to -shortest
[19:12:05 CEST] <mozzarella> -longest
[19:12:08 CEST] <IchGucksLive> -r 25 -filter:v "setpts=6*PTS"  -shortest
[19:12:55 CEST] <IchGucksLive> Unrecognized option 'longest'.
[19:16:13 CEST] <kepstin> IchGucksLive: the opposite to -shortest is to not use -shortest
[19:16:25 CEST] <kepstin> the default is to make the output the length of the longest stream
[19:16:55 CEST] <kepstin> (it won't extend any streams to that length, you have to use filters for that if desired)
[19:45:46 CEST] <Peste_Bubonica> Hi folks. I'm trying to stream rtsp through ffserver. The stream is a 1280x720 VP8, 30fps. In FFServer, i'm using webm format, with libvpx, with same resolution, but with 23fps. The problem is that its very slow. ffmpeg sends only 9fps to ffserver and many frames is lost. The connection with the rtsp source is good. I can watch the stream very well with mpv.
[19:46:45 CEST] <Peste_Bubonica> this is the feed configuration: https://pastebin.com/AgLgHuBi
[19:47:03 CEST] <Peste_Bubonica> and ffmpeg command line: ffmpeg -threads 8 -rtsp_transport tcp -i "rtsp://admin:1234@192.168.0.44:554" http://localhost:8090/feed.ffm
[20:09:22 CEST] <thunfisch> Peste_Bubonica: Is your machine capable of encoding to webm in realtime? last I checked it's pretty slow.
[20:09:55 CEST] <thunfisch> also ffserver is deprecated afaik
[20:10:07 CEST] <thunfisch> might want to take a look at nginx-rtmp or the likes
[20:10:44 CEST] <Peste_Bubonica> thunfisch, its a i7 4790 @ 3.6-4.0 ghz
[20:11:08 CEST] <Peste_Bubonica> do you think that its no capable to produce 23fps?
[20:12:30 CEST] <thunfisch> Peste_Bubonica: could very well be, afaik webm can only use a single core for encoding
[20:12:55 CEST] <thunfisch> have you tried just encoding a file with these specs and seeing if it can do realtime?
[20:13:16 CEST] <thunfisch> my i5-7200U @ 2.5ghz is doing 0.8x right now
[20:13:44 CEST] <Peste_Bubonica> thunfisch, thanks for the tip of nginx. I will check. Can I continue to use ffmpeg to send the stream to nginx?
[20:14:26 CEST] <thunfisch> Peste_Bubonica: yes, you can easily send the stream with ffmpeg. you can even use ffmpeg to transcode the incoming streams. the module allows to launch commands that read from the server, transcode to your desired format and push back
[20:15:54 CEST] <Peste_Bubonica> very nice. ffserver can't stream h264 right? This camera sends h264, so i'm in hope that I don't even need to transcode if possible
[20:16:10 CEST] <furq> ffserver can't really stream anything
[20:16:17 CEST] <Peste_Bubonica> lol :)
[20:16:28 CEST] <furq> but yeah you can just send h264 directly to nginx-rtmp
[20:16:37 CEST] <thunfisch> don't know. but with nginx-rtmp you don't reencode at all
[20:16:42 CEST] <thunfisch> it just spits out what it is given
[20:16:57 CEST] <Peste_Bubonica> I will try.
[20:16:59 CEST] <furq> x264 is much faster than libvpx anyway
[20:17:05 CEST] <furq> in case you need to reduce the bandwidth, filter etc
[20:17:05 CEST] <thunfisch> ^
[20:17:23 CEST] <furq> you can use multiple cores with libvpx but it's a nightmare getting it to work
[20:17:27 CEST] <thunfisch> yeah, x264 is just fine for streaming. you can fiddle around with the settings to reach desired bitrate
[20:27:09 CEST] <Peste_Bubonica> if I can, I will use x264. Its possible that some devices may not send h264. In this case, I will try to encode it using the nvidia encoder
[20:27:35 CEST] <thunfisch> why not using the cpu?
[20:27:39 CEST] <Peste_Bubonica> I will try with nginx now. i've already compiled it here with rtsp module..
[20:28:11 CEST] <Peste_Bubonica> thunfisch, in my tests, using my vga was faster
[20:28:42 CEST] <Peste_Bubonica> localtests of course, i was not using rtmp, only encoding some videos
[20:30:36 CEST] <Peste_Bubonica> using ffmpeg with hevc_nvenc I was able to produce 68fps converting a 4k h264, with 8000k bitrate, hq preset and 2pass
[20:30:46 CEST] <squarecircle>  ohai
[20:31:54 CEST] <squarecircle> as I have soon access to two Xeon Phi: Does is there a way to accellerate the video decoding with these coprocessors?
[20:33:35 CEST] <DHE> as I understand it they're not very good for that sort of thing. the Xeon Phi is supposed to be half way between a regular CPU and a GPU, but basically doesn't do either very well
[20:37:08 CEST] <furq> they're incredibly good at very specific workloads afaik
[20:37:14 CEST] <furq> and mediocre at everything else
[20:38:55 CEST] <squarecircle> They support openmp
[20:39:01 CEST] <squarecircle> and openCL
[20:39:09 CEST] <squarecircle> that sounds promising
[20:39:31 CEST] <squarecircle> as the normal ffmpag decoder is CPU based afaik
[20:39:42 CEST] <squarecircle> if not escpecially told to use a gpu
[20:40:47 CEST] <DHE> well ffmpeg doesn't have opencl or openmp for decoding or encoding. x264 opencl is weak at very best
[20:40:53 CEST] <JEEB> GPUs' actual computing parts are useful for either graphics, or heavily threadable and low sync ratio work
[20:41:02 CEST] <JEEB> and IIRC xeon phi is similar
[20:41:11 CEST] <JEEB> at least regarding the last part
[20:41:30 CEST] <DHE> yes, but as I recall it's just a ~72 core x86 CPU with some advanced AVX-type instructions. (including AVX-512)
[20:41:40 CEST] <JEEB> thus trying to expect any sort of magical result from them for use cases which don't have heavy threading or low sync ratio
[20:41:58 CEST] <JEEB> DHE: I think by now there's like multiple of them, too. the older was even more specific
[20:42:30 CEST] <JEEB> the newer might be like that, but video decoding or encoding is not necessarily something where many low-speed cores can help you a lot
[20:42:52 CEST] <JEEB> such things are very good with heavily threadable and NUMA-aware workloads
[20:42:53 CEST] <jkqxz> Xeon Phi is completely useless for video because all of its power is floating point.  Video is pretty much entirely fixed point.
[20:42:59 CEST] <JEEB> yes, that too
[20:44:01 CEST] <DHE> I just threw some E5-2698 v4 chips at my software video encoding and made sure my NUMA settings were good
[20:45:25 CEST] <furq> doesn't xeon phi use some weird custom simd format as well
[20:45:41 CEST] <furq> so any sse/avx stuff won't work
[20:46:18 CEST] <DHE> depends. the first generation of phi was actually a pentium1 modified with the advanced instructions, so I can imagine some old generation stuf like SSE 1 might not work
[20:46:25 CEST] <JEEB> yea
[20:46:30 CEST] <JEEB> the first gen was much more special
[20:46:35 CEST] <DHE> that and a further reading of the spec sheet turned me off it
[20:46:50 CEST] <JEEB> I had some general looks and quickly noticed it wouldn't help my use cases
[20:46:58 CEST] <JEEB> => no further detailed looks
[20:47:29 CEST] <jkqxz> Buying huge chips made to maximise floating point throughput to do video is really not a good idea.  This would apply to graphics cards as well, except that the consumer volume pushes the price down such that the small amount of video cicuitry on the side starts to look quite attractive even when you know that 95% of the chip will be idle.
[20:48:32 CEST] <JEEB> GPUs could actually be used for stuff like actual colorspace conversions and scaling - like they are used with players. of course also depends on how much time goes into up/download
[20:48:51 CEST] <JEEB> but video players clearly show that if you give actual image processing to a GPU it actually works :D
[20:48:56 CEST] <JEEB> compression, though, nope
[20:49:01 CEST] <JEEB> (other than the ASICs)
[20:51:23 CEST] <DHE> but isn't the nvenc chip one of said ASICs? (probably not a good one but still)
[20:51:29 CEST] <furq> wake me up when ffmpeg has opencl nnedi3
[20:51:31 CEST] <jkqxz> Yeah, the rest of the chip can be useful for peripheral things so it isn't completely idle, but generally that wasn't the bit which you were really optimising for in server-type applications.
[20:51:40 CEST] <JEEB> yup
[20:51:46 CEST] <JEEB> which is why FFmpeg doesn't have that stuff :)
[20:51:58 CEST] <JEEB> DHE: yes, nvenc uses the ASICs on the boards
[20:52:39 CEST] <DHE> oh you mean in the context of opencl encoding vs ASIC encoding
[20:53:04 CEST] <JEEB> no, I was speaking of stuff where the (f.ex. GPU) would actually be useful
[20:53:12 CEST] <JEEB> as opposed to trying to use it for actual encoding
[20:55:17 CEST] <DHE> I guess my question is, if someone wanted to build the "optimal" encoder farm for a site like Twitch.tv, what's the best way to go? Not xeons, not opencl GPUs, what's left?
[20:56:25 CEST] <furq> why not xeons
[20:56:44 CEST] <DHE> that should say xeon phis
[20:56:52 CEST] <jkqxz> It probably is densest normal Xeons.  (Or EPYC - that does look like it will be pretty good for this, though I don't know of any good benchmarks yet.)
[20:56:55 CEST] <furq> oh
[20:57:00 CEST] <furq> well yeah it is probably xeons then
[20:57:05 CEST] <furq> or EPYC THREADRIPPER
[20:57:14 CEST] <DHE> Epyc looks very appealing, but the site I normally buy servers from sold out of them recently...
[20:57:16 CEST] <DHE> dunno if that's good or bad
[20:58:03 CEST] <furq> i still can't believe they called it that
[20:58:17 CEST] <furq> i'm surprised it doesn't have rgb leds
[20:58:51 CEST] <furq> the die should be in the shape of a gun
[20:58:52 CEST] <DHE> I'm curious though. Someone needs to do a really in-depth review of an Epyc. right now all I have are like cinebench scores
[20:59:24 CEST] <DHE> Ryzen (Conusmer) is 2-channel RAM and has 1 Zen die. Threadripper is 4-channel memory and has 2 Zen dies. Epyc has 8-channels memory and 4 Zen dies.
[20:59:41 CEST] <DHE> so... is Epyc going to be a 4-way NUMA machine in each socket?
[21:00:19 CEST] <BtbN> I don't think it will behave like NUMA
[21:00:28 CEST] <BtbN> after all, they all still access the same memory
[21:00:39 CEST] <jkqxz> Certainly to some degree (not clear how much), but video is very amenable to NUMA so that's just fine.
[21:01:00 CEST] <BtbN> An Intel System with 4 Sockets is also not NUMA
[21:01:03 CEST] <DHE> BtbN: testing has shown an access latency penalty when communicating between the Zen dies
[21:01:17 CEST] <BtbN> why would a Zen one with 4 dies in one chip be any different?
[21:01:24 CEST] <DHE> BtbN: but a 2-socket Intel system is NUMA... (which is all I have access to)
[21:01:34 CEST] <BtbN> The ones I have are not
[21:01:35 CEST] <jkqxz> Er, what?  Yes it is.  What does NUMA even mean if you define that as not?
[21:01:56 CEST] <jkqxz> Clearly there are different regions of Memory to which the Access is Non-Uniform.
[21:02:29 CEST] <DHE> socket-to-socket is obvious. my question is, is core-to-core? it depends whether the chip is 4x 2-channel memory controllers, or a single 8-channel controller
[21:02:40 CEST] <DHE> http://imgur.com/a/1b9zd <-- Epyc with the heatspreader cover removed
[21:03:02 CEST] <BtbN> The memory controler is connected to the same infinity fabric as all the Chips. So it definitely could be a single big one
[21:03:19 CEST] <BtbN> but unless AMD or testing reveals it, nobody will know for sure
[21:03:42 CEST] <BtbN> The two CCXs in a single Zen die definitely have only one memory controler
[21:03:57 CEST] <furq> does epyc infinity fabric give +60 to cast speed
[21:04:13 CEST] <BtbN> depends on your RAM clock!
[21:07:57 CEST] <squarecircle> thanks
[21:08:25 CEST] <squarecircle> I'll still do the ffpmeg stuff on cpus
[21:08:45 CEST] <squarecircle> and search for some cool stuff I can fo with the Xeon Phis
[21:14:15 CEST] <DHE> furq: well, the inter-socket infinityfabric is made of 64 PCI-E lanes... so that's ballpark 64 GB/sec of data available there
[21:14:35 CEST] <DHE> I definitely want one
[21:15:45 CEST] <BtbN> How much does Intel have?
[21:15:55 CEST] <BtbN> Between Sockets I mean
[21:15:59 CEST] <BtbN> 9.6 something QPI
[21:17:14 CEST] <DHE> intel has a dedicated lane running at 9.6 giga-transactions per second. gotta find the size of a transaction though
[21:17:16 CEST] <DHE> also I think it's 2 lanes
[21:21:26 CEST] <BtbN> Will there be multi socket Epyc?
[21:21:32 CEST] <BtbN> And what will be between the sockets then?
[21:21:37 CEST] <DHE> dual sockets exist, yes
[21:21:37 CEST] <BtbN> Not 64 lanes I assume
[21:22:01 CEST] <DHE> each CPU supports 128 PCI lanes. In single socket you get them all for normal use (though there are limits to breaking them down, so you can't have 128 connections of 1x each)
[21:22:26 CEST] <DHE> or in dual socket, 64 lanes from each form their interconnect and you still get 128 total lanes available to the motherboard
[21:24:59 CEST] <BtbN> damn, that's pretty overkill
[21:26:08 CEST] <spalpeen> i would like to decode only a small crop of incoming stream, can someone point me to what section of code I should look at
[21:26:21 CEST] <BtbN> "decode a small crop"?
[21:26:28 CEST] <BtbN> You cannot crop the image before decoding.
[21:26:58 CEST] <spalpeen> i would like to decode only a small section of image
[21:27:12 CEST] <spalpeen> e.g. ignore all macroblocks outside a certain region
[21:27:21 CEST] <BtbN> that's not possible
[21:27:38 CEST] <spalpeen> i am willing to have some error on edge blocks
[21:27:52 CEST] <kepstin> AMD definitely has the memory controllers attached to specified dies; going to off-die memory requires going through the infinity fabric and has a latency hit.
[21:28:23 CEST] <spalpeen> somewhere in the decoding there is a loop over macroblocks i assume
[21:28:36 CEST] <spalpeen> i would like to recode this to only loop over macroblocks in ROI
[21:28:57 CEST] <kepstin> I've only seen details about threadripper, but I assume epyc is similar; they have both interleaved memory modes with consistent average latency for all ram and numa configurations there.
[21:29:17 CEST] <kepstin> (via bios switch)
[21:31:28 CEST] <kepstin> the linkage between sockets in epyc looks interesting; each die in one socket appears to get a 16 lane link to the corresponding die in the other socket, assuming I understand what I've read correctly.
[21:33:28 CEST] <kepstin> so it's a max of 2 hops from any particular die to the memory controller on any other die.
[22:03:03 CEST] <DHE> kepstin: that is correct
[22:31:51 CEST] <Peste_Bubonica> thunfisch, i'm trying to send a stream to nginx, but i receive got this error: handshake: unexpected RTMP version: 80
[22:32:12 CEST] <Peste_Bubonica> this error is from nginx. I can't find any tips googling it.
[22:33:20 CEST] <Peste_Bubonica> this is the error on ffmpeg: Error writing trailer of http://localhost:1935/mytv: Connection reset by peer
[22:36:51 CEST] <kepstin> Peste_Bubonica: You need to use an rtmp:// url in ffmpeg...
[22:37:26 CEST] <Peste_Bubonica> kepstin, oh man, sorry for this noob error
[22:37:45 CEST] <Peste_Bubonica> I was using http with ffserver, and keep usint if after switch to nginx
[22:37:57 CEST] <Peste_Bubonica> thanks for your answer
[22:51:51 CEST] <kiroma> Can you accelerate filters?
[22:53:17 CEST] <DHE> opencl is available for 2 filters. but that's all...
[22:57:31 CEST] <BtbN> it's also not very effective, due to heavy copying back and forth
[00:00:00 CEST] --- Thu Sep  7 2017