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

[burek]

[00:06:04 CEST] <FurretUber> Hi, I am trying to capture the screen and the sound on Xubuntu 17.04, with the ffmpeg snapshot from three days ago. I am using VA-API to record video and it is working fine, but I am having troubles to record the sound.
[00:07:18 CEST] <FurretUber>  Initially I have tried with alsa, but then I could hear nothing while it was being recorded. Then I tried with pulse, but the result was horrible. Now I am using OpenAL, and this is by far the best
[00:08:19 CEST] <FurretUber> However, when recording from a bluetooth device, the capture volume is being influenced by the bluetooth's device volume
[00:08:29 CEST] <FurretUber> Which don't happen with the internal sound
[00:09:10 CEST] <FurretUber> Here is the output of the command: https://pastebin.com/2xzEkdJz
[00:22:54 CEST] <algun_> My -audiofile gets out of sync with video, how can I adjust only the video speed?
[00:43:37 CEST] <ArsenArsen> After upgrading to 17.04 it works! Thanks!
[01:32:34 CEST] <podman> hi there! anyone have any experience sandboxing ffmpeg?
[01:33:11 CEST] <JEEB> make minimal builds regarding features you need, and only give it access to things it needs to have access to
[01:33:42 CEST] <podman> for instance, if someone were to craft a malicious m3u8 manifest that attempted to access files... what would be a good way to deal with that (assuming hls support is still required)
[01:33:54 CEST] <podman> JEEB: in more practical terms?
[01:34:54 CEST] <JEEB> well first of all put it in its own kernel namespace, then additionally limit things with whatever security system you like, and only build FFmpeg with protocols, demuxers, decoders, encoders and muxers that you need
[01:35:00 CEST] <JEEB> can't really say much more than that
[01:38:40 CEST] <podman> and how would one go about that? the actual sandboxing?
[01:52:36 CEST] <__deivid__> Hi! I'm transcoding THOUSANDS of videos (distributed across multiple computers) and ffmpeg is currently showing ~50% cpu usage and 40% 'nice' usage. Can this be because I'm reading/writing to NFS?
[02:09:52 CEST] <c3-Win> __deivid__: The best way to know would be to copy a file locally and test with the same settings.
[02:11:03 CEST] <c3-Win> And you can get even deeper into your testing by trying not only locally/locally but also locally/NFS and NFS/locally to see if it's reading or writing that's the slowest part... or both.
[02:16:35 CEST] <__deivid__> c3-Win. I'll test it when this batch finishes
[02:32:41 CEST] <DHE> multi-threading doesn't scale perfectly. coordination between threads is a thing. if you truly want 100.00% CPU usage, run your jobs in single-threaded mode and bound to a single CPU, with 2 jobs per CPU
[02:40:06 CEST] <__deivid__> DHE: Yeah I have a few monster servers running multiple transcodings, tested with 1 to 8 threads and you do get diminishing returns. 4 was the sweet spot.
[02:40:53 CEST] <__deivid__> But 4 threads gets me ~35fps downscaling 1080p to 720p when encoding x264 in (high profile, 4.0)
[02:41:21 CEST] <__deivid__> I'm guessing the IO from nfs is killing it
[02:42:03 CEST] <DHE> __deivid__: I've done similar on a dual socket E5-2698v4 (20 cores + hyperthreading). One job uses 800% of a possible 8,000% CPU availability. You'd think 10 instances would do it. But if I run 16 instances each slows a bit I see ~92% total utilization. Raising to 20 did nothing to total utilization
[02:43:51 CEST] <DHE> each of the x264 threads are firing up, doing work, and going back to sleep. but on linux even if a job isn't actually running it still has a "home" CPU and moving it incurs a migration cost. as such tons of threads running and sleeping all the time just doesn't max out CPU
[02:44:30 CEST] <DHE> or maybe linux isn't able to push a thread to an idle CPU when one is available quickly enough. I don't know the specifics. I just know you can't reach 100% usage like this.
[02:44:37 CEST] <__deivid__> DHE: I have exactly the same cpu (and 4 servers)
[02:45:06 CEST] <DHE> oh... and running that many ffmpeg instances isn't ideal either
[02:45:23 CEST] <DHE> I thought you might have ryzen 7 or something
[04:37:48 CEST] <aletorrado> [DirectShow] hey! is it possible to select the tv tuner channel when transcoding from a directshow tuner device?
[05:14:14 CEST] <buu> So
[05:14:22 CEST] <buu> I've got a chromecast(ultra?) in a vizio md55-0
[05:14:34 CEST] <buu> it will play x264
[05:14:36 CEST] <buu> but not 264
[05:14:38 CEST] <buu> *5
[05:15:10 CEST] <buu> Is this A) not really an ultra B) a problem with ffmpeg's x265 output C) something else
[05:16:01 CEST] <buu> https://support.vizio.com/s/article/ka61a000000DWXDAA4/M55-D0-Model-Information-ext?language=en_US
[05:40:15 CEST] <buu> hm
[05:40:22 CEST] <buu> How do I even tell which chromecast I have?
[06:31:31 CEST] <buu> Also.. why doesn't -b:v set the bitrate?
[06:31:56 CEST] <buu> Oh, maybe it is
[06:34:55 CEST] <buu> I see this is a popular channel
[06:35:40 CEST] <buu> Ok, how do I get more than 2.5fps encoding vp9?
[07:00:01 CEST] <Threads> you get a better computer
[07:12:12 CEST] <c3-Win> You use Google to search for better settings?
[07:12:38 CEST] <c3-Win> You wait for someone to write a better implementation?
[07:12:48 CEST] <c3-Win> You write one yourself?
[07:52:51 CEST] <buu> Threads: if only that were possible =[
[07:54:37 CEST] <buu> Although since it is single threaded maybe an over clocked 7700k or something
[08:52:20 CEST] <c3-Win> If I assemble an avfilter (the buffer+context+Sink+etc, etc) can i update the values in the the actual filter, or do I need to destroy everything and re-create it again?
[10:04:28 CEST] <ArsenArsen> If anyone uses MXE, what do I need to compile in order to use libav* to Windows? I tried `make ffmpeg' in MXE and it compiled ffmpeg, but there is alot of undefined references afterwards when crosscompiling my project. https://hastebin.com/elaxubufig.swift
[11:42:24 CEST] <superware> I'm using ffmpeg library to av_read_frame frames from a live h264 stream, when I'm dispaying each frame at it comes (without any synchronization) - the video is a little jittery, but since I must keep low-latency playback how can I still keep the rendering rate as close to the frames rate as possible?
[11:46:13 CEST] <bencoh> respect pts when displaying pictures I'd say
[12:01:30 CEST] <ArsenArsen> yeah you're probably not respecting it
[12:07:40 CEST] <ArsenArsen> Hmm, while using the libs I don't seem to write out all the frames, a few are skipped on the end
[12:09:02 CEST] <ArsenArsen> I use the new send/receive API, and before writing the trailer and closing the file output stream I receive all packets and scale their timestamps and write them, and frames are still missing. I am in a single thread environment so it's not race conditions
[12:28:09 CEST] <superware> bencoh: according to my understanding pts is being used for synchronization of separate elementary streams, and not playback...
[12:28:20 CEST] <ArsenArsen> presentation timestamp
[12:33:20 CEST] <BtbN> of course they are used for playback
[12:33:30 CEST] <BtbN> That's the whole point of timestamps
[12:40:20 CEST] <superware> so it's not a good idea to get the frame rate and calculate a delay after each frame render?
[12:41:06 CEST] <BtbN> why would you do that? You have the timestamps
[12:41:57 CEST] <superware> which represent time in conjuction with the time_base?
[12:45:57 CEST] <superware> BtbN: and how can I maintain low-latency playback? for exammple, should I always keep only the two latest frames in the render queue?
[12:46:28 CEST] <BtbN> you always need some buffer
[12:46:37 CEST] <BtbN> a few frames is probably enough
[12:47:14 CEST] <BtbN> Can probably make it very small, and just present things the moment they come in, if enough time has passed
[12:50:47 CEST] <superware> "if enough time has passed"?
[12:51:36 CEST] <superware> I'm currently showing frames as they come, but then the video seems a bit jumpy since packets aren't arriving at FPS rate
[12:51:51 CEST] <superware> the video isn't smooth, that is
[12:53:27 CEST] <BtbN> well, that's what happens if you ignore their timestamps
[12:53:47 CEST] <BtbN> don't present them before it's their time
[12:53:59 CEST] <BtbN> that's the whole point of having presentation timestamps
[12:58:58 CEST] <superware> something like: av_rescale_q(av_gettime_relative(), av_get_time_base_q(), _output_ctx->streams[stream_index]->time_base) ?
[15:04:33 CEST] <aletorrado_> Any idea how to choose tv tuner channel using DirectShow? Thanks :)
[15:11:15 CEST] <BtbN> I don't think TV tuners use DirectShow
[15:11:22 CEST] <BtbN> There is a whole diffrent API for that stuff
[15:11:27 CEST] <BtbN> Which ffmpeg does not support
[15:21:28 CEST] <aletorrado_> Yes it uses directshow! It's listed as a dshow device in ffmpeg, but i cannot choose the channel
[15:23:09 CEST] <aletorrado_> Capturing video&audio works fine though
[16:04:58 CEST] <ChocolateArmpits> aletorrado_, you followed thet dshow tutorial page ?
[16:06:05 CEST] <aletorrado_> ChocolateArmpits: yeap, it doesn't mention how to choose the channel
[16:12:29 CEST] <c3-Win> I don't think changing the channel is a part of dshow. The Video output part (i.e. the card AV interface) is usually Dshow, but not the command list/structure.
[17:00:00 CEST] <superware> BtbN: I'm still struggling with low-latency playback, I have a thread dequeuing frames as they come from avcodec_receive_frame, how should I calculate the delay between two dequeued frames?
[17:00:51 CEST] <BtbN> check the timestamps, if enough time has passed, present the frame, if not, wait
[17:03:17 CEST] <superware> for example, frame->pts increment by 3600, time_base is 1/90000 so each frame is 40 ms (25 fps), how should this be synced with the real time clock?
[17:03:45 CEST] <BtbN> those are 40 real milliseconds
[17:04:15 CEST] <superware> right, but I need a reference to the real time timestamp
[17:04:23 CEST] <BtbN> real time stamp?
[17:04:35 CEST] <BtbN> The time stamps are arbitrary, usually starting at 0
[17:04:39 CEST] <BtbN> not related to wall clock
[17:06:34 CEST] <superware> but I must also measure real time, else how can I know how much time passed since last frame?
[17:06:49 CEST] <BtbN> yes, use whatever precise API you have
[17:07:34 CEST] <BtbN> just save the precise system time when playing the first frame, and the offset from it to the frame timestamps
[17:07:45 CEST] <BtbN> then you can always calculate for every frame if it should have been presented already
[17:09:08 CEST] <superware> but then if the first frame was late by 300 ms from the live stream, then latency will never be less than 300 ms
[17:09:54 CEST] <BtbN> you can't have no latency at all
[17:10:02 CEST] <superware> minimal
[17:10:12 CEST] <BtbN> I'd say 300ms is very minimal
[17:10:24 CEST] <JEEB> I don't remember how low some people doing medical equipment with libx264 got the latency
[17:10:32 CEST] <JEEB> but it was IIRC pretty darn low
[17:11:06 CEST] <BtbN> you need some buffer to get smooth playback, otherwise every tiny network jitter or CPU spike that slows encoding will be visible
[17:12:38 CEST] <BtbN> can probably dynamically decrease that offset until you start getting frames too late, and then increase it a bit again, so that you still have wait times, but they are minimal
[17:14:32 CEST] <superware> do you know of an existig example of such playback logic?
[17:15:16 CEST] <ChocolateArmpits> I think x264+lan+mplayer had the latency of about 80-120ms in my case.
[17:15:22 CEST] <JEEB> (very) low latency is such a specific requirement that you'd have to poke quite a bit to find some examples of that on the playback side
[17:15:42 CEST] <superware> JEEB: I'm doing libav directly, I have my own queues ;)
[17:15:44 CEST] <JEEB> some existing software can be configured for lower latency but the switches are often not known :P
[17:17:33 CEST] <BtbN> Even Steam-Inhome has a noticable delay, and I'd assume that to be pretty tunes
[17:17:36 CEST] <BtbN> *tuned
[17:18:50 CEST] <furq> https://lists.debian.org/debian-devel/2017/06/msg00308.html
[17:18:51 CEST] <furq> nice
[17:45:29 CEST] <podman> I'm running into an interesting issue compiling FFMPEG on ubuntu 14.04 (yes i know it's old). It seems to be unable to find certain libraries, for example, I get the following error:  'libass not found using pkg-config', even thought libass-dev is installed using apt-get
[17:45:56 CEST] <JEEB> check config.log
[17:46:09 CEST] <JEEB> it could just be a case of not new enough version or so
[17:47:42 CEST] <podman> JEEB: that would be interesting. I'm using a specific version of FFMPEG and a chef cookbook to install it. Worked without any issues in mid Feb but isn't working anymore. The only thing I can think of right now is that a newer version of chef is doing something weird? I'll see if I can find the config.log
[17:49:06 CEST] <JEEB> dunno, in any case config.log's got the actual check and what happened
[17:50:48 CEST] <podman> JEEB: ok, so it shows: "Package libass was not found in the pkg-config search path."
[17:51:13 CEST] <JEEB> and the specific check is there, too
[17:51:19 CEST] <JEEB> but yes, that pretty much says it all
[17:51:31 CEST] <JEEB> pkg-config <something> didn't give a proper result
[17:52:31 CEST] <podman> right, but if I run that check manually, it does exist
[17:52:41 CEST] <podman> pkg-config --exists --print-errors libass
[17:54:07 CEST] <JEEB> check what exactly it checks for
[17:54:11 CEST] <JEEB> it should show up in config.log
[17:54:43 CEST] <podman> that is exactly what is in config.log
[17:54:58 CEST] <JEEB> ok
[17:55:08 CEST] <JEEB> then when that ran pkg-config didn't get what you expected
[17:55:48 CEST] <podman> maybe it's being run as a different user and for some reason that user doesn't have access to that library or the search path?
[17:57:13 CEST] <podman> of for some reason PKG_CONFIG_PATH isn't set properly when it used to be?
[18:14:20 CEST] <podman> JEEB: well, that's interesting. manually specifying PKG_CONFIG_PATH fixes it as far as I can tell. still waiting for it to finish. not sure why it wasn't able to find that
[18:20:48 CEST] <podman> JEEB: well, that did it. ¯\_(Ä)_/¯ thanks for helping me solve that
[18:59:15 CEST] <sfan5> ffmpeg can't read vapoursynth scripts directly can it?
[19:01:57 CEST] <JEEB> nope, that's why you have vspipe
[19:03:09 CEST] <sfan5> ;_;
[19:10:50 CEST] <ChocolateArmpits> just use vapoursynth standalone
[19:14:10 CEST] <JEEB> that's what vspipe is
[19:14:23 CEST] <JEEB> basic vs client that passes video through
[19:27:23 CEST] <sfan5> yeah i settled on vspipe with -y piped to ffmpeg -f yuv4mpegpipe -i -
[20:32:32 CEST] <sfan5> is x265 supposed to look inferior to x264 at the same crf?
[20:33:18 CEST] <BtbN> The crf values are arbitrary and implementation defined
[20:33:38 CEST] <sfan5> what the ffmpeg wiki says is total bullshit then
[20:33:42 CEST] <sfan5> but i remember someone mentioning that
[20:33:43 CEST] <furq> in practice, no
[20:34:01 CEST] <sfan5> (referencing the bullet points here https://trac.ffmpeg.org/wiki/Encode/H.265#ConstantRateFactorCRF)
[20:34:06 CEST] <furq> the default x265 crf is 28, so i assume the same x265 crf setting maps to a higher quality than the same one in x264
[20:34:21 CEST] <furq> but yeah that's the most concrete comparison you'll get
[20:34:31 CEST] <furq> they're just arbitrary numbers
[20:34:36 CEST] <sfan5> x265 has more noticable blocking compared to x264 (both crf=21)
[20:34:53 CEST] <sfan5> at least for the source material i have here rn
[20:37:51 CEST] <JEEB> the CRF numbers are most likely completely different between the two encoders, just like they are somewhat different between settings and bit depths within x264
[20:38:38 CEST] <sfan5> fps=6.3 this reminds me of libvpx
[20:38:54 CEST] <furq> at least it's using all your cores
[20:38:58 CEST] <sfan5> true
[20:39:04 CEST] <JEEB> and probably better rate control than libvpx
[20:39:10 CEST] <JEEB> given that libvpx is completely bonkers
[20:39:21 CEST] <sfan5> x265 [info]: Main profile
[20:39:27 CEST] <furq> so what are the filesizes
[20:39:28 CEST] <JEEB> I mean, libaom was going to put in *theora*'s rate control
[20:39:30 CEST] <sfan5> wait shouldn't it default to High or some shit?
[20:39:37 CEST] <JEEB> sfan5: HEVC has no high profile
[20:39:40 CEST] <sfan5> oh
[20:39:51 CEST] <furq> and also what presets are you using
[20:39:53 CEST] <JEEB> it has main, main 10 and then various main X for 4:4:4 etc
[20:39:59 CEST] <furq> i assume a good one if it's running at 6fps
[20:40:10 CEST] <sfan5> -c:v libx265 -preset slower -crf 21
[20:40:20 CEST] <furq> what about x264
[20:40:51 CEST] <sfan5> same with s/265/264/
[20:41:25 CEST] <furq> shrug
[20:41:28 CEST] <furq> x265 should compress better
[20:41:42 CEST] <furq> obviously those settings won't even remotely target the same filesize though
[20:41:53 CEST] <sfan5> it's true that the file is smaller but it also looks worse
[20:42:11 CEST] <furq> lower the crf then
[20:43:41 CEST] <furq> JEEB: people keep saying that as if we're supposed to remember how good theora's rate control was
[20:43:50 CEST] <JEEB> it's shit
[20:43:57 CEST] <furq> noted
[20:44:05 CEST] <JEEB> the joke is that they were replacing it because it was less shit than libvpx's
[20:44:13 CEST] <furq> i got that much
[20:44:20 CEST] <furq> everyone knows how shit libvpx's is
[20:44:43 CEST] <JEEB> no idea if they went through it, though. since AV1 wasn't finished I just haven't looked into it too much
[20:47:57 CEST] <sfan5> i think what i'm hitting here is just an edge case of x265's deblock not being good for low-brightness areas
[20:51:18 CEST] <kerio> what's the equivalent of opus for video?
[20:51:26 CEST] <sfan5> since everything else looks fine
[20:51:38 CEST] <sfan5> this alone however makes x265 unworthy of using for me
[21:02:04 CEST] <JEEB> sfan5: I will note that since most HW decoders for HEVC handle 10bit that pretty much should be the standard for HEVC. of course that makes the encode even slower ^_^
[21:02:21 CEST] <JEEB> also all this reminds me that I should probably make another test of x265
[21:03:01 CEST] <sfan5> i guess that means i will not encode H.265 in the next 3 years
[21:06:27 CEST] <JEEB> I only encode HEVC when absolutely needed
[21:06:34 CEST] <JEEB> because any sane presets will go slooow
[00:00:00 CEST] --- Mon Jun 26 2017