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

[burek]

[00:01:13 CEST] <BtbN> No, that's just some other script.
[00:01:27 CEST] <Z0ltans> thats all i use those 2 things
[00:01:48 CEST] <Z0ltans> thats what produces the stream
[00:02:03 CEST] <Z0ltans> which is coming up black with audio
[00:02:19 CEST] <BtbN> Sorry, can't fix your scripts for you. The issue is probably cause by it.
[00:02:28 CEST] <Z0ltans> not asking for you to fix
[00:02:41 CEST] <Z0ltans> just curious what i possible did wrong or what not
[00:03:12 CEST] <Z0ltans> using cpu encoding has - issues tho
[00:03:20 CEST] <Z0ltans> *0 issues
[00:03:45 CEST] <Z0ltans> maybe its on my sewrver end then
[00:06:06 CEST] <Z0ltans> maybe this is what ur loking for http://pastebin.com/xkZjJKye
[00:08:50 CEST] <DelphiWorld> Z0ltans: this is the output
[00:11:06 CEST] <Z0ltans> ok
[00:11:10 CEST] <zephod> is it possible to convert dsd to pcm with ffmpeg?
[00:14:16 CEST] <ianbytchek> durandal_1707: its bits and pieces all over the place. i'm gonna poke it a little more, see if anything comes out of it. thanks again for your help.
[00:14:40 CEST] <ianbytchek> durandal_1707: if not. will clean it up, post and share.
[00:16:09 CEST] <durandal_1707> zephod: yes
[01:06:36 CEST] <kevr> kepstin: thanks for your response, that helps a lot
[01:13:44 CEST] <fullstack> Hi. How do I seek into a mp4, play a number of frames, and then loop it indefinitely?  .... this does not work, (it doesn't loop) : ./ffmpeg -stream_loop 0 -ss 500 -i ~/input.mp4 -frames:v 500 -f xv display
[01:16:45 CEST] <durandal_170> fullstack: you want to loop 500 frames indefinitely?
[01:17:00 CEST] <fullstack> Yes, (that's just a number I picked)
[01:19:51 CEST] <durandal_170> fullstack: only if you trim input, and use stream loop in another pass, alternatively there is loop filter, but needs memory to cache all frames it needs to loop
[01:20:46 CEST] <fullstack> Ok, that sounds like a plan. How do I do that? Got an example? (Or can you tell me how to break that down into steps I can RTFM)
[01:22:14 CEST] <durandal_170> fullstack: trim video with trim filter, mux rawvideo into output
[01:23:24 CEST] <durandal_170> and then in second ffmpeg use stream loop and xv device as output
[01:26:45 CEST] <fullstack> How do I mux rawvideo into a second ffmpeg?
[01:27:41 CEST] <fullstack>  ffmpeg -i input.mp4 -vf trim=60:65 -f rawvideo - | ffmpeg -i - -stream_loop 0 ?
[01:28:20 CEST] <durandal_170> You need to seek with stream loop
[01:28:50 CEST] <durandal_170> you can't seek with pipe
[01:29:19 CEST] <durandal_170> save output to out.nut
[01:29:53 CEST] <durandal_170> and then use that as input for 2nd command
[01:30:33 CEST] <durandal_170> -c:v rawvideo out.nut
[01:31:35 CEST] <kevr> How can I figure out if an AVPacket is from a video frame or an audio frame? Does AVPacket.size == 1 if it's a video and > 1 if it's audio?
[01:33:28 CEST] <durandal_170> kevr: nope, from stream they belong to
[01:35:54 CEST] <kevr> durandal_170: via stream_index?
[01:36:01 CEST] <kevr> ah, that makes sense.
[03:40:37 CEST] <transhuman_> hi! is there a way to specify an output directory with ffmpeg (using perl)
[03:40:51 CEST] <transhuman_> any option ?
[03:42:59 CEST] <relaxed> transhuman_: ffmpeg -i input /path/to/output/dir/output
[03:46:02 CEST] <transhuman_> thanks it would be nice if there was a switch that could be used but I will work with it.
[11:39:20 CEST] <Sense23> I can't encode using NVENC (which I did enable in the build and shows up in the encoder list) It gives me this error: [hevc_nvenc @ 0x35d7900] Cannot load NvEncodeAPIGetMaxSupportedVersion < And this also happens for h.264, not only hevc. Later on it gives me this error: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[11:41:02 CEST] <Sense23> Also, I use NVENC in combination with OBS - I'm on Ubuntu by the way - And OBS gives me the same error (incorrect arguments)
[11:48:49 CEST] <Sense23> Oh, I also saw someone else have this problem: https://devtalk.nvidia.com/default/topic/904979/cuda-programming-and-performance/compiling-ffmpeg-with-nvec-support-fails-to-apply-patch/2 | Someone recommended applying a commit in the thread: b83c849e8797fbb972ebd7f2919e0f085061f37f but that didn't do very much for me
[12:32:34 CEST] <nick0> hi, does anyone have any examples of using the new API (avcodec_receive_frame) with swr_convert_frame? I'm trying to use it but I can't figure out why the output of swr_convert_frame is an empty frame, except for a few bytes near the start and a few near the middle. The input frame I'm giving it is correct
[15:47:08 CEST] <Hp> Hello
[15:47:12 CEST] <Hp> Guys i need some help
[15:47:25 CEST] <Hp> Anyone here ?
[15:49:00 CEST] Last message repeated 1 time(s).
[15:49:34 CEST] <Chloe> Hp: just ask your question
[15:50:40 CEST] <Hp> Okay so problem is i have a streaming website
[15:50:49 CEST] <Hp> and script does encoding of videos
[15:50:58 CEST] <Hp> ffmpeg is being used in it
[15:51:38 CEST] <Hp> I noticed some of my videos have flickering ,Lines etc Example video: http://vidlox.tv/nizwhww74p6y
[15:52:07 CEST] <Hp> If you will notice in first few seconds, there are lines being shown, specially when in start helicopter passes
[15:52:16 CEST] <Hp> i noticed this is with many videos
[15:52:45 CEST] <Hp> Problem is i cannot keep very high quality also cause this is streaming, lots of bandwidth is being used
[15:52:53 CEST] <Hp> so i need a balanced solution of settings
[15:53:08 CEST] <Hp> like what setting i should use for CRF and max bitrate
[15:53:35 CEST] <Hp> Video can be blurry like youtube has in lower quality but i don't want this lines and breaks
[15:53:40 CEST] <Hp> any help ?
[15:55:03 CEST] <redliondj> hi what would you suggest as codecs/containers to convert mpeg2/mp2 files ?
[15:56:06 CEST] <redliondj> not trying to get something optimized, any suggestion is welcome
[15:57:35 CEST] <Hp> please help anyone
[15:59:28 CEST] <DHE> assuming x264, loosely speaking I'd suggest a high bitrate that you can withstand and set the keyframe interval to something high like 150 to 300
[15:59:40 CEST] <DHE> if you have bitrate contraints, you don't want crf mode
[16:13:16 CEST] <redliondj> thx DHE
[16:18:48 CEST] <Spring> Hp's site looks like it's meant to be an intentionally misspelling of videox.tv
[16:31:44 CEST] <durandal_170> hmm? Why?
[16:34:13 CEST] <Spring> durandal_170, err, vidiox.tv rather
[16:34:36 CEST] <Spring> but who knows, could just be a coincidence
[16:43:14 CEST] <vans163> Sense23: Are you up to date on the nvidia drivers?
[16:43:20 CEST] <vans163> Sense23: And nvidia sdk?
[16:45:14 CEST] <vans163> It seems to lead to saying that NvEncodeAPIGetMaxSupportedVersion was added in video encode sdk 7.0
[16:45:32 CEST] <vans163> so if you dont have the 7.0 compiled shared library  (NvEnc.so or .dll)
[16:45:36 CEST] <vans163> it probably wont work
[17:44:30 CEST] <lord-carlos> Hi. I use ffmpeg static build under windows. Somehow my encoded are now a bit brighter then the source. http://pastebin.com/raw/2cxwCfwf
[17:44:44 CEST] <lord-carlos> I don't know what changed, but I never notice the incresed brightness before.
[17:53:16 CEST] <durandal_170> lord-carlos: what ffmpeg version you use?
[17:54:57 CEST] <lord-carlos> durandal_170: first ffmpeg-20160207-git-9ee4c89-win64-static and then I tried ffmpeg-20160915-6f062eb-win64-static
[17:55:58 CEST] <lord-carlos> not that visiable on the screenshot, but the left is the brighter encode, and the right is the source avi. https://i.imgur.com/lzT5mba.png
[17:56:10 CEST] <durandal_170> lord-carlos: and what is input pixel format?
[17:57:51 CEST] <lord-carlos> durandal_170: Not sure, does this help? Stream #0:0: Video: rawvideo, bgr24, 2560x1440, 60 fps, 60 tbr, 60 tbn, 60 tbc
[17:58:22 CEST] <lord-carlos> it's a raw export from After Effects
[17:59:33 CEST] <lord-carlos> In the past I often used .tga sequence files instead of an avi, maybe I should look into that.
[18:05:25 CEST] <durandal_170> the only problem may be bgr to yuv420 conversion
[18:14:25 CEST] <lord-carlos> removed it, made no difference
[18:14:32 CEST] <lord-carlos> I'm gonna try .tga files later
[18:21:38 CEST] <lord-carlos> What does the
[18:21:48 CEST] <lord-carlos> What does the thread_queue_size parameter do?
[18:22:21 CEST] <lord-carlos> nvm, found it
[18:23:06 CEST] <furq> lord-carlos: x264 will implicitly convert to yuv unless you use libx264rgb
[18:24:21 CEST] <lord-carlos> I can't remember where I found those options, but I wanted to make it better /  more fitting for youtube. I think I had trouble preserving red text? Can't remember the details.
[18:24:46 CEST] <furq> yeah red text will look like garbage with yuv420p
[18:25:00 CEST] <furq> there's no way round that on youtube though
[18:25:21 CEST] <furq> other than putting a black outline around it
[18:25:30 CEST] <lord-carlos> so -pix_fmt yuv420p is redundent?
[18:25:35 CEST] <furq> yeah
[18:25:39 CEST] <lord-carlos> thanks
[18:26:06 CEST] <furq> i'm not sure what it'll be converted to if bgr24 is the source, but it'll be some yuv
[18:26:10 CEST] <furq> and then youtube will convert it to yuv420p
[18:26:41 CEST] <furq> you could maybe try doing the colourspace conversion with zscale
[18:26:46 CEST] <furq> -vf zscale,format=yuv420p
[18:27:00 CEST] <furq> i think the new zeranoe builds have got zscale
[18:27:53 CEST] <furq> or you could use libx264rgb and let youtube do the conversion for you
[18:29:29 CEST] <lord-carlos> I get an error, no path beween colorspace. Or something like that.
[18:29:43 CEST] <lord-carlos> I'm gonna try .tga files again
[18:30:06 CEST] <furq> i take it you don't have the bandwidth to just upload the uncompressed avi
[18:30:21 CEST] <lord-carlos> 400 gigs?
[18:30:37 CEST] <furq> i'll take that as a no
[18:31:03 CEST] <lord-carlos> I think i gout around 40mbit/s here .. but I rather work out a workflow where I get a clean file
[18:31:42 CEST] <furq> fwiw if this is just for youtube then all the x264opts stuff is redundant
[18:32:58 CEST] <lord-carlos> I thought if it has similar options the youtube encoder would be less of a quality hit.
[18:34:03 CEST] <furq> there is a big official support page on google with bafflingly in-depth suggested encoder options
[18:34:11 CEST] <furq> but i don't understand how any of it can possibly make any difference
[18:34:26 CEST] <lord-carlos> I think that is what I used
[18:34:37 CEST] <furq> yeah i've never understood it
[18:34:49 CEST] <furq> unless youtube are doing something super weird then the only thing that matters is the picture quality after decoding
[18:35:25 CEST] <lord-carlos> maybe it's just so people don't use super shit settings :)
[18:37:46 CEST] <furq> it's weirdly indepth though
[18:41:09 CEST] <lord-carlos> wat .. ok. So I took my old script, old export method of tga files, old ffmpeg version. That combination worked.
[18:41:15 CEST] <lord-carlos> But it's slightly brighter
[18:42:21 CEST] <lord-carlos> I changed GPU, driver and got a bunch of windows updates. But that should not have any effect on ffmpeg, right?
[18:42:55 CEST] <furq> what player are you using
[18:43:04 CEST] <lord-carlos> oh ..
[18:43:06 CEST] <lord-carlos> mpv
[18:43:17 CEST] <lord-carlos> yeah, maybe it's playing the files differently
[18:43:17 CEST] <furq> that should be ok
[18:43:44 CEST] <furq> as long as you're using the opengl renderer
[18:44:26 CEST] <lord-carlos> oh wow. Not sure what I used as renderer
[18:44:29 CEST] <lord-carlos> but that's it
[18:44:37 CEST] <lord-carlos> both look fine with mpc
[18:44:39 CEST] <lord-carlos> kek
[18:44:55 CEST] <furq> mpv -vo=opengl file
[18:46:54 CEST] <lord-carlos> yup, was using direct3d
[18:47:21 CEST] <lord-carlos> thx4help, bro .. or whatever you young kids say those days :)
[18:48:34 CEST] <JEEB> that must have been one old version of mpv if it defaulted to direct3d :)
[18:49:06 CEST] <lord-carlos> no, I changed it in the config.
[18:49:12 CEST] <lord-carlos> I can't remember why though
[18:50:23 CEST] <lord-carlos> Anyhow, thank you all for debugging this with me.
[18:54:03 CEST] <nick0> anyone know why swr_convert_frame butchers my audio? the input is fine, the settings are fine, but the output is just a few (20 instead of 1000+) samples per frame, not anything close to what it should be
[18:54:27 CEST] <lord-carlos> I got a lot of ram, but read large files from an SSD, could I add -thread_queue_size to increase what should be read into the ram? Or did i missunderstood that option?
[19:37:07 CEST] <ManDay> Hi
[19:39:13 CEST] <ManDay> I have got a movie which reports a video of yuv420p and it doesn't play back correctly (it stutters and hangs enormously). I want to use ffmpeg to reencode it somehow such that it plays back. But most reencodes fail with an error saying "Could not find tag for codec ...." - can anyone explain what is the problem?
[19:40:48 CEST] <JEEB> full command line and terminal output in a pastebin-like thing of your choice. and then link it here
[19:40:56 CEST] <durandal_170> Which codec?
[19:43:02 CEST] <ManDay> durandal_170: for example I tried h263p
[19:44:28 CEST] <ManDay> JEEB: http://dpaste.com/2RA4EMQ
[19:45:16 CEST] <JEEB> [mp4 @ 0xe8a570] Could not find tag for codec h263p in stream #0, codec not currently supported in container
[19:45:31 CEST] <ManDay> Yes, that's the message I mean
[19:45:59 CEST] <JEEB> > "not currently supported in container" means you ain't gonna get it working in mp4 :P
[19:46:34 CEST] <JEEB> also why would you even re-encode aac audio to aac? use -c:a copy for that
[19:47:19 CEST] <ManDay> okay. But what container should I use then?
[19:47:35 CEST] <ManDay> 3gp doesn't work and mp4 should be able to hold h263 accroding to wiipedia
[19:49:26 CEST] <JEEB> why h263p btw
[19:49:33 CEST] <JEEB> have you tried just h263
[19:49:45 CEST] <JEEB> (also why h263, that thing is ancient as hell)
[19:49:47 CEST] <ManDay> yes, but it says the following then:
[19:49:55 CEST] <ManDay> JEEB: suggest anything please
[19:49:59 CEST] <ManDay> I just want to watch the video ;)
[19:50:22 CEST] <ManDay> "[h263 @ 0x2605420] The specified picture size of 1920x1080 is not valid for the H.263 codec.
[19:50:24 CEST] <ManDay> Valid sizes are 128x96, 176x144, 352x288, 704x576, and 1408x1152. Try H.263+."
[19:50:27 CEST] <JEEB> lol
[19:50:30 CEST] <furq> use libx264
[19:50:36 CEST] <furq> or get a player which can decode 1080p hevc
[19:50:40 CEST] <JEEB> furq: he has "--disable-libx264" in his configure line
[19:50:40 CEST] <JEEB> lol
[19:50:46 CEST] <furq> oh
[19:50:47 CEST] <furq> thanks gentoo
[19:50:53 CEST] <ManDay> well, i can change that :-P
[19:50:58 CEST] <JEEB> and it has faac enabled for no real reason
[19:51:05 CEST] <furq> it's 2.8.6
[19:51:07 CEST] <JEEB> which is like totally needed these years
[19:51:42 CEST] <furq> but yeah unless your computer is ancient you should be able to decode 1080p hevc
[19:51:48 CEST] <ManDay> i guess there is a reason i enabled it
[19:51:49 CEST] <furq> try a different player i guess
[19:52:07 CEST] <ManDay> furq: i tried mpv and parole (gst based), both can't cope with it
[19:52:17 CEST] <JEEB> both probably use libavcodec
[19:52:26 CEST] <JEEB> there's some patches you can apply to make it somewhat faster with modern CPUs
[19:52:38 CEST] <JEEB> which will not get into upstream FFmpeg because they're intrinsics
[19:53:01 CEST] <ManDay> its just that video is broken
[19:53:17 CEST] <JEEB> http://git.1f0.de/gitweb?p=ffmpeg.git;a=shortlog;js=1
[19:53:21 CEST] <ManDay> i have never had a problem with HD videos, this is the only and first one that stutters. that's why i simply wanted to reencode
[19:53:31 CEST] <JEEB> the "hevc: port intra pred SIMD from OpenHEVC" and "hevc: port intrinsic SSE2 IDCT from OpenHEVC"
[19:53:37 CEST] <JEEB> ones speed up HEVC decoding nicely
[19:54:00 CEST] <furq> some recent gpus have hardware hevc decode if mpv can make use of that
[19:54:01 CEST] <furq> i assume it can
[19:54:10 CEST] <JEEB> yes, but you do need a very recent GPU for it
[19:54:18 CEST] <ManDay> ... i'm really okay with just reencoding the video....
[19:54:29 CEST] <JEEB> I'd try with the openhevc based patches first
[19:54:51 CEST] <JEEB> if that's not good then you can just -c:v libx264 -crf 21 -preset fast -c:a copy it
[19:55:09 CEST] <furq> haswell has hevc decode doesn't it
[19:55:15 CEST] <JEEB> nope
[19:55:28 CEST] <JEEB> I don't think skylake has it either
[19:55:29 CEST] <lord-carlos> only very few CPU have hevc AFAIK
[19:55:38 CEST] <furq> https://software.intel.com/en-us/blogs/2015/12/11/codecs-are-they-slowing-you-down
[19:55:46 CEST] <JEEB> or wait, skylake might have HEVC main
[19:56:01 CEST] <JEEB> furq: they do let you get sw decoding through DXVA2 I think
[19:56:19 CEST] <JEEB> nvidia used to do that with some of their stuff too for... VC-1 or something?
[19:56:21 CEST] <furq> no vaapi?
[19:56:39 CEST] <JEEB> I think they added some support for kaby lake in vaapi although I'm not sure
[19:56:39 CEST] <furq> it's academic if he doesn't have a haswell or newer anyway
[19:56:46 CEST] <JEEB> yeah
[19:57:15 CEST] <JEEB> yeah, that blog entry says > HEVC Software decoder
[19:57:17 CEST] <JEEB> for haswell
[19:57:27 CEST] <JEEB> then broadwell had sw as well
[19:57:35 CEST] <JEEB> and skylake has main profile asic
[19:57:41 CEST] <JEEB> kaby lake should have 8bit and 10bit
[19:57:48 CEST] <JEEB> and vaapi is probably getting P010 support
[19:58:16 CEST] <ManDay> i do have a skylake computer, but that's not the one I want to watch the video on :-P
[19:58:28 CEST] <ManDay> i'm just going to reencode it with x264
[20:00:25 CEST] <JEEB> I'd recommend looking into the openhevc-based patches since usually it's less effort
[20:00:31 CEST] <JEEB> since they speed up the decoding by a nice amount
[20:00:38 CEST] <JEEB> too bad FFmpeg is not gonna take in any intrinsics
[20:00:43 CEST] <JEEB> so they will never go upstream
[20:01:45 CEST] <ManDay> JEEB: I just want to build with the package manager and not patch manually for a single video
[20:01:50 CEST] <ManDay> but thanks for the tip
[20:02:47 CEST] <JEEB> I think you could add additional patches with gentoo overlays or so
[20:03:45 CEST] <JEEB> but yeah, you'd have to maintain the patch then
[20:03:49 CEST] <JEEB> which is :effort:
[20:05:36 CEST] <lord-carlos> For uploading to youtube, would encoding with GPU still be a bad idea?
[20:06:03 CEST] <JEEB> well nowadays you can get lossless coding from nvidia
[20:06:10 CEST] <JEEB> so in theory that could be used
[20:06:16 CEST] <lord-carlos> uhh, neat
[20:06:46 CEST] <JEEB> just make sure your thing supports it
[20:06:59 CEST] <lord-carlos> gtx 1070, so probably yes
[20:07:10 CEST] <lord-carlos> could even do h265
[20:07:31 CEST] <JEEB> yeah, although 'tube won't touch that with a 10 feet stick
[20:08:15 CEST] <JEEB> just check how good perf you get with lossless coding with libx264 vs the nvidia thing
[20:08:33 CEST] <JEEB> so you can compare using CPU cycles vs how much you have to upload
[20:10:11 CEST] <lord-carlos> probably don't need lossless, because the source has large parts from an already GPU encoding video.  Game -> NVENC -> slight editing -> raw AVI -> ffmpeg / h264 -> youtube
[20:10:20 CEST] <lord-carlos> crazy world we live in
[20:10:45 CEST] <JEEB> you could just export avi with ut video lossless from the editor
[20:10:57 CEST] <JEEB> since ut video has plugins for pretty much all media frameworks
[20:11:33 CEST] <lord-carlos> I don't want to upload 300gb
[20:11:45 CEST] <ManDay> JEEB: :effort: - yes, for a single video that doesn't run for me right now. sorry for being selfish but at this very moment i really just want to watch that video and not create and publish and maintain an overlay for a single patch
[20:12:04 CEST] <JEEB> ManDay: completely understandable :)
[20:12:10 CEST] <ManDay> JEEB: thanks ;)
[20:12:52 CEST] <JEEB> and due to the licensing issues around HEVC I don't see it being used too much (plus the fact that the encoders for the format aren't yet always better in a meaningful way yet)
[20:13:09 CEST] <JEEB> I still remember being pumped up about HEVC in '13 :<
[20:15:30 CEST] <lord-carlos> is vp9 encoding still super super slow?
[20:15:50 CEST] <Spring> what do mean by lossless encoding with nvidia?
[20:16:10 CEST] <JEEB> Spring: it can encode 4:2:0 and 4:4:4 losslessly
[20:16:25 CEST] <Spring> there's some option?
[20:16:40 CEST] <Spring> as ShadowPlay sucks tbh
[20:16:45 CEST] <JEEB> see the libavcodec wrapper for how it's done :P
[20:16:52 CEST] <JEEB> I haven't touched it myself
[20:16:59 CEST] <JEEB> lord-carlos: it is + libvpx's rate control and psychovisual optimizations are what they are
[20:17:10 CEST] <JEEB> I hope AOM and with libaom improves those things
[20:17:20 CEST] <JEEB> since until now GOOG only cared about what it used
[20:20:35 CEST] <Spring> with VP9 it really depends what the encoding time is compared to. In my config vs h264 with the slower preset on a 1440p/60fps high bitrate source VP9 takes like 5 minutes vs h264's 2-3.
[20:21:25 CEST] <JEEB> that's fast as hell so I am not sure if you're actually gaining anything against libx264
[20:21:26 CEST] <BtbN> I think YouTube happily accepts HEVC?
[20:21:34 CEST] <JEEB> BtbN: that'd be news for me
[20:21:48 CEST] <BtbN> They will of course transcode it, but it should work as input file.
[20:22:01 CEST] <JEEB> esp. since they've been "in the middle of updating their FFmpeg" for like three years now
[20:22:03 CEST] <Spring> I should mention that's on a half-minute clip btw
[20:22:18 CEST] <JEEB> Spring: yeah but still. that means you've used one of the faster settings
[20:22:21 CEST] <lord-carlos> last time I tested it (1440p/60), vp9 got like ~1fps while h264 got about ~38fps. vp9 alomost did not use my cpu at all.
[20:22:25 CEST] <BtbN> I'll do a lossless hevc transcode of some test video and well, test it.
[20:22:34 CEST] <JEEB> BtbN: cool
[20:22:54 CEST] <Spring> JEEB, faster settings for VP9 or h264?
[20:22:57 CEST] <BtbN> what was the name of that neural-network deinterlacer again?
[20:23:03 CEST] <furq> nnedi
[20:23:13 CEST] <BtbN> going to test that as well
[20:23:17 CEST] <furq> lord-carlos: libvpx's multithreading sucks
[20:23:22 CEST] <JEEB> Spring: libvpx
[20:23:34 CEST] <furq> BtbN: if you want it to not be disgustingly slow then use it through avisynth/vapoursynth
[20:23:39 CEST] <Spring> there's a speed setting for VPx?
[20:23:42 CEST] <JEEB> yes
[20:23:46 CEST] <Spring> WHAT
[20:24:27 CEST] <Spring> oh wait, I think I've read of this.
[20:24:46 CEST] <JEEB> anyways, I can't habla the settings for libvpx since they're completely different from libx264. but I'm pretty sure they literally had a setting called speed
[20:24:47 CEST] <furq> actually libvpx should be able to use >8 threads at 1440p
[20:24:49 CEST] <Spring> I don't have it set though, and use two pass
[20:24:52 CEST] <furq> but you need to enable it manually
[20:24:57 CEST] <JEEB> and then you had either best/fast or something
[20:25:10 CEST] <furq> it's either -speed or -cpu-used in ffmpeg
[20:25:16 CEST] <JEEB> furq: I thought it was set automagically with newer versions?
[20:25:24 CEST] <furq> no idea tbh
[20:25:26 CEST] <JEEB> yeah, cpu-used was the other one
[20:25:27 CEST] <furq> it wasn't with 1.5
[20:25:29 CEST] <JEEB> ok
[20:26:07 CEST] <furq> as usual for a google product, the documentation is mostly in the form of blog posts full of outdated conjecture
[20:26:51 CEST] <Spring> I've gotta do me some testing of the speed setting for quality comparisons
[20:27:14 CEST] <Spring> must have encoded like 100 of the same clips each while testing
[20:28:36 CEST] <JEEB> just make sure you're testing in some meaningful way. like either selecting a speed you like and trying to match both against that and outputting the same file size (with either crf or 2pass bit rate). or pretty much maxing both out and seeing how they fare (with the same output file size)
[20:29:35 CEST] <furq> i can't imagine how long it took to encode 100 clips with libvpx
[20:29:52 CEST] <JEEB> I think you can get some speed from libvpx vp9
[20:30:06 CEST] <JEEB> of course, that doesn't mean it is actually worth it at that point
[20:30:28 CEST] <JEEB> I hear libaom might switch to theora's rate control
[20:30:34 CEST] <JEEB> which would be pretty hilarious
[20:30:44 CEST] <JEEB> but it also shows how bad libvpx's rate control is
[20:30:44 CEST] <furq> i was going to ask if that was particularly good, but i guess not
[20:30:52 CEST] <furq> it'd be hard to get much worse though
[20:31:05 CEST] <JEEB> yeah, it's just something that is available with a matching license
[20:31:13 CEST] <JEEB> and that is better than what libvpx has currently
[20:31:46 CEST] <JEEB> although I guess with theora the issues were mostly with how badly it compressed and thus they had frame dropping etc in there
[20:32:55 CEST] <Spring> re: libvpx thread count, here's the thing, on this very channel someone mentioned setting more threads than necessary can degrade quality. Now, that would be fine if it auto set the thread count but I've also read ffmpeg doesn't handle it properly unless manually set, so...
[20:33:27 CEST] <furq> there's a maximum number of threads you can use iirc
[20:33:32 CEST] <JEEB> how many threads are set by default are usually left to the encoder rather than anything else :P
[20:33:40 CEST] <furq> you can only have one slice per 256px video width
[20:33:53 CEST] <JEEB> f.ex. with the libx264 wrapper it's just libx264 handling it if you don't override it
[20:34:05 CEST] <JEEB> furq: oh right, it's slice based coding
[20:34:09 CEST] <furq> yeah
[20:34:16 CEST] <JEEB> if it's actually separate slices it will make the quality worse off :/
[20:34:27 CEST] <JEEB> it's the only way to do low-latency multilthreading of course
[20:34:34 CEST] <furq> yeah i guess they meant that enabling multithreading at all will degrade quality
[20:34:51 CEST] <JEEB> (since otherwise you have to handle N pictures at the same time, which raises the latency to >1 frame)
[20:34:52 CEST] <Spring> 3:42 minutes encoding 1440p 23 second clip to CRF 26 at speed 1
[20:35:34 CEST] <furq> i guess you should be able to get 10 slices with that
[20:37:34 CEST] <furq> try -tile-columns 3 -threads 8
[20:37:39 CEST] <furq> apparently that's all you need now
[20:38:04 CEST] <Spring> speed 4 same settings = 2:15
[20:41:18 CEST] <Spring> what does tile-columns affect?
[20:41:32 CEST] <xavier666> hello, everybody. I'm new to ffmpeg.
[20:42:23 CEST] <xavier666> I'm not able to solve a tiny problem using ffmpeg
[20:42:58 CEST] <Spring> there's apparently some worthwhile thread explaining it on gmane but it 404s :/
[20:43:03 CEST] <xavier666> I'm trying to stream a video from 1 host to another (point to point streaming)
[20:43:29 CEST] <xavier666> I'm using the rtp protocol
[20:44:43 CEST] <xavier666> this is the server command -> ffmpeg -re -i video_file.mp4 -vcodec libx264 -an -f rtp rtp://10.X.X.X:5004 -vn -acodec libtwolame -f rtp rtp://10.X.X.X:5005
[20:45:18 CEST] <c_14> Don't send out 2 rtp streams on ports directly next to each other
[20:45:31 CEST] <c_14> The ffmpeg implementation uses port_number+1 for RTCP
[20:45:53 CEST] <xavier666> ok....thank you sir/madam...I'll keep it in mind
[20:46:25 CEST] <xavier666> my problem is actually in receiving. I cannot record it on the client side
[20:46:57 CEST] <xavier666> I want to know what should be the appropriate record command on the client side
[20:47:18 CEST] <jkqxz> Spring:  Adding tile-columns encodes different parts of the picture independently.  It trades encode quality (you can't use make use of redundancy between different tiles) for increased parallelism (tiles can be encoded by different threads without any synchronisation).
[20:47:36 CEST] <xavier666> this is what i'm come up with -> ffmpeg -i rtp://10.X.X.X:5004 -vcodec libx264 -an -i rtp://10.5.19.244:5005 -acodec libtwolame -vn -t 00:00:35 downloaded.mp4
[20:48:01 CEST] <c_14> xavier666: you need the sdp file
[20:48:15 CEST] <c_14> ffmpeg will by default output it on afaik stdout, but you can specify the file directly with -sdp_file
[20:48:17 CEST] <Spring> jkqxz, so it's always a slight trade-off of quality vs speed?
[20:48:21 CEST] <c_14> Then feed that file on the client as input
[20:48:35 CEST] <c_14> (you can either copy it over directly or throw it on an http server or something)
[20:49:41 CEST] <xavier666> ok, i'm trying it out...i'll let you know
[20:49:56 CEST] <Spring> one guy on Github wrote that frame-parallel should always be disabled, so I guess I'll also be trying that
[20:49:58 CEST] <xavier666> on the client side, do I only mention the sdp file?
[20:50:15 CEST] <Spring> and /man/ does speed 0 take forever to encode
[20:50:15 CEST] <c_14> xavier666: yep
[20:50:19 CEST] <xavier666> or is anything else also required?
[20:50:26 CEST] <c_14> just the sdp
[20:50:41 CEST] <xavier666> ok....great! I'm trying it out right now
[20:50:43 CEST] <jkqxz> Spring:  Yes, though it differs how much you can make use of that.  If you only have one core then you lose quality and gain nothing.  If you have a lot of cores then it can be a minor decrease in quality for encode running a lot faster.
[20:52:53 CEST] <nick0> anyone know why swr_convert_frame butchers my audio? the resampled frame is much smaller and consists of a few samples and the rest is silence (zeros), with a few bytes in the middle of the silence set to to small values (~1-4). no errors reported
[20:53:01 CEST] <furq> Spring: afaik multithreading isn't possible at all without tile-columns
[20:53:16 CEST] <furq> so you should get a significant speedup, especially on >HD content
[20:54:36 CEST] <furq> and yeah frame-parallel isn't needed for multithreading any more and apparently it reduces quality
[20:55:59 CEST] <JEEB> o_O
[20:56:03 CEST] <JEEB> wtf
[20:56:13 CEST] <JEEB> someone implemented frame-threading in a really weird way then
[20:56:51 CEST] <xavier666> c_14 I generated the sdp file and sent it to the client. But how to use it? What should be the syntax?
[20:57:31 CEST] <c_14> I think it's just ffmpeg -i foo.sdp
[20:57:40 CEST] <furq> does libvpx even have frame threading
[20:57:44 CEST] <furq> i thought it only had slice threading
[20:58:00 CEST] <JEEB> well, frame-parallel sounds like that
[20:58:06 CEST] <JEEB> as opposed to slice-parallelism
[20:58:32 CEST] <Spring> shaved 20s using tile-columns 3 and frame-parallel disabled. The default tile-columns is 6 apparently.
[20:58:34 CEST] <furq> "enable frame parallel decodability features"
[20:58:59 CEST] <furq> how that would affect sliced encoding before 1.4 i have no idea, but apparently it did
[20:59:31 CEST] <xavier666> ok...trying
[20:59:44 CEST] <JEEB> furq: I'm just not gonna try to guess wtf they're doing there :D
[21:00:05 CEST] <furq> yeah by "how" i meant something more detailed than "libvpx is a fucking mess"
[21:00:18 CEST] <furq> i don't need help getting that far
[21:02:25 CEST] <TD-Linux> furq, frame parallel decodeability means that the next frame doesn't depend on probabilities from the previous one
[21:02:47 CEST] <TD-Linux> note that ffvp9 decodes all the symbols up front such that it can still do some of the frame in parallel
[21:02:50 CEST] <TD-Linux> *frames
[21:04:05 CEST] <TD-Linux> libvpx itself has no frame threading.
[21:04:40 CEST] <jkqxz> It turns out that dealing with codecs which try to make use of temporal redundancy beyond the frame data itself is hard.
[21:07:21 CEST] <BtbN> wow, nnedi is amazingly slow
[21:07:32 CEST] <BtbN> glorious 4fps
[21:08:20 CEST] <xavier666> c_14: This is what I did, I started recording on the client side. Then I started sending the video from the server. The client records data (a bit lossy). But the file cannot be played by VLC. I'm sending the exact commands.
[21:08:58 CEST] <xavier666> c_14: client side -> ffmpeg -i some_sdp.sdp -strict -2 lolfile.mp4
[21:09:03 CEST] <TD-Linux> <JEEB> yeah, it's just something that is available with a matching license <- that and we employ the author.
[21:09:44 CEST] <xavier666> c_14: server side -> ffmpeg -re -i Videos/SampleVideo_1280x720_5mb.mp4 -sdp_file some_sdp.sdp -strict -2 -vcodec libx264 -an -f rtp rtp://10.5.19.244:6004 -acodec libtwolame -vn -f rtp rtp://10.5.19.244:7004
[21:17:15 CEST] <c_14> xavier666: vlc won't be able to play that file until you stop recording
[21:18:13 CEST] <xavier666> i played the file after I stopped recording. I'm trying it out once more :)
[21:18:15 CEST] <JEEB> TD-Linux: cool
[21:18:55 CEST] <c_14> If it still doesn't work upload the output of an ffprobe on that file to a pastebin service
[21:19:13 CEST] <xavier666> ...ok will do
[21:22:45 CEST] <xavier666> c_14: one more query. I'm trying to kill the client after 40 seconds of recording (video is 30 sec long). Can it be a cause of the error?
[21:22:49 CEST] <Spring> woaaaah does multi-threading make a difference with vpx
[21:23:12 CEST] <Spring> without it the encode is 12:34
[21:30:27 CEST] <lord-carlos> and how much with?
[21:30:32 CEST] <c_14> xavier666: depends how you kill it, anything harder than TERM will make the mp4 unplayable yes
[21:34:30 CEST] <xavier666> c_14: I'm using ctrl+c (SIGINT). Is it ok?
[21:38:50 CEST] <BtbN> hm, the file it procudes is slightly too large to upload it to YT from home...
[21:39:52 CEST] <BtbN> so a very low cqp will have to do
[21:59:12 CEST] <TD-Linux> Spring, also I don't know if anyone mentioned it yet but -speed is equivalent to x264 presets
[22:07:13 CEST] <BtbN> I don't like the nnedi result. It looks weird and grainy
[22:07:24 CEST] <BtbN> and it took half an hour for a 1 minute video
[22:10:51 CEST] <furq> i've never used the one in ffmpeg
[22:11:19 CEST] <BtbN> and I just accidentially overwrote it with a yadif output for comparison...
[22:11:28 CEST] <furq> qtgmc is fantastic for sd mpeg2 sources but i have no idea how it does with higher quality sources
[22:11:31 CEST] <BtbN> so lets do that again
[22:11:32 CEST] <furq> it's also much faster
[22:12:19 CEST] <BtbN> "nnedi=../nnedi3_weights.bin:all:af"
[22:12:23 CEST] <BtbN> that's how I'm using it
[22:12:30 CEST] <furq> you could just use vapoursynth nnedi if you want multithreading
[22:13:13 CEST] <BtbN> I'm just curious how it looks
[22:13:19 CEST] <BtbN> if it's visually better then yadif
[22:17:19 CEST] <BtbN> and: youtube does not like HEVC...
[22:17:37 CEST] <BtbN> Didn't expect them to not support some well-known video format
[22:21:45 CEST] <JEEB> it isn't surprising since I think they're still on a 2011 version of FFmpeg
[22:22:29 CEST] <JEEB> licensing issue is probably the secondary reason, but they can't even get to that if they can't get their FFmpeg updated
[22:22:50 CEST] <BtbN> for pure backend decoding there shouldn't be any license issues
[22:23:06 CEST] <BtbN> encoding/offering HEVC is what they want money for
[22:23:13 CEST] <furq> how are they decoding vp9 with ffmpeg from 2011
[22:23:14 CEST] <JEEB> don't remember the licensing rules so can't comment on it :P
[22:23:23 CEST] <JEEB> furq: patches for libvpx?
[22:23:54 CEST] <furq> what's stopping them from patching it for hevc then
[22:24:26 CEST] <furq> other than the scorn which hevc deserves
[22:25:02 CEST] <BtbN> hevc is a ffmpeg native decoder
[22:25:10 CEST] <BtbN> that depends on a lot of internal changes that happend since 2011
[22:25:19 CEST] <BtbN> can't just patch that into an half-ancient version
[22:26:12 CEST] <JEEB> HEVC doesn't deserve scorn as a format, the business people who killed it halfborn do deserve it
[22:26:35 CEST] <BtbN> I remember the HEVC licensing situation to be better than for h264
[22:26:48 CEST] <BtbN> And it's already a success because of the hardware support
[22:26:53 CEST] <BtbN> that VP9 is still lacking
[22:28:59 CEST] <JEEB> wow, you have gotten really weird image of the HEVC licensing then
[22:29:14 CEST] <JEEB> because AVC had "OK" things and a single shop where you got the license, MPEG-LA
[22:29:25 CEST] <JEEB> with HEVC you have MPEG-LA, HEVC Advance and at least Technicolor
[22:29:41 CEST] <JEEB> because people decided that they didn't get enough money from AVC licensing
[22:32:32 CEST] <radia> Wich command is best to use: "ffmpeg -i input.mp4 -c:v libvpx -b:v 1M -c:a libvorbis output.webm" or "ffmpeg -i input.mp4 -c:v libvpx -crf 10 -b:v 1M -c:a libvorbis output.webm"?
[23:06:04 CEST] <BtbN> furq, ok, with propper settings I can't make out a visual difference between yadif and nnedi
[23:06:13 CEST] <BtbN> the nnedi file is slightly bigger though
[23:09:10 CEST] <furq> what's the source
[23:13:23 CEST] <BtbN> some test-file I'm using since ages, "What is Life credits roll"
[23:14:45 CEST] <BtbN> I'll upload a bunch of samples in a moment
[23:35:45 CEST] <BtbN> furq, https://btbn.de/images/test/deint/
[23:35:49 CEST] <durandal_170> nnedi is making out pixels from shit
[23:36:09 CEST] <BtbN> nnedi seems to be very slightly "better"
[23:36:17 CEST] <BtbN> But it's definitely not worth the 0.03x speed
[23:36:55 CEST] <durandal_170> its good for anime
[23:37:13 CEST] <BtbN> It took almost an hour converting a one minute video
[23:41:08 CEST] <TD-Linux> interlaced anime?
[23:41:10 CEST] <furq> like i said i've never used it by itself because it's so slow
[23:42:49 CEST] <furq> it makes a bigger difference with lower quality sources
[23:43:03 CEST] <furq> yadif does a perfectly fine job with good quality 1080i stuff
[23:44:23 CEST] <furq> qtgmc is noticeably better than yadif on most of the dvds i've used it for
[23:44:31 CEST] <furq> although how much of that is qtgmc and how much is nnedi i couldn't say
[00:00:00 CEST] --- Sun Sep 18 2016