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

[burek]

[15:54:08 CEST] <alexmarkley> i'm now running ffmpeg 4.1.3 (provided by rpmfusion), latest fedora 30 with updates
[15:54:51 CEST] <alexmarkley> i'm still getting a process hang when doing something like $ pasuspender -- ffplay -f alsa -i 'sysdefault:CARD=BRIO'
[15:55:03 CEST] <alexmarkley> doesn't seem to matter what input i select
[15:57:22 CEST] <alexmarkley> SIGINT / SIGTERM don't have any effect, have to use SIGKILL
[15:57:32 CEST] <alexmarkley> gonna see if i can track down debug symbols
[16:04:04 CEST] <BtbN> You have to send SIGINT 3 times in quick succession to force it down
[16:16:58 CEST] <alexmarkley> BtbN, thanks for the info there
[16:17:05 CEST] <alexmarkley> brb
[16:23:08 CEST] <alexmarkley> so i'm learning that it's apparently quite difficult to discern the quality and capabilities of a USB-C <-> USB A (3.1?) cable just by examining the outside of it
[16:23:55 CEST] <alexmarkley> hardware glitches are dramatically complicating my troubleshooting effort here...
[16:35:24 CEST] <alexmarkley> so it appears to be locked up at alsa.c:304: snd_pcm_drain(s->h);
[16:35:35 CEST] <alexmarkley> in ff_alsa_close()
[16:40:27 CEST] <alexmarkley> oh interesting
[16:41:08 CEST] <alexmarkley> it's definitely not libav, it's a bug in alsa-plugins-pulseaudio
[16:41:58 CEST] <alexmarkley> if i select an audio device which is (apparently) presented by alsa-plugins-pulseaudio, i can trigger the issue... but if i select a real hardware device i can't reproduce the issue
[16:48:13 CEST] <alexmarkley> so, surprise surprise, the mystery is finally solved: pa is a garbage fire once again
[16:48:25 CEST] Action: alexmarkley shrugs
[16:51:22 CEST] <kepstin> alexmarkley: ffmpeg can input directly from pulseaudio rather than the alsa emulation...
[16:51:40 CEST] <alexmarkley> kepstin, true, and i appreciate you pointing that out
[16:51:54 CEST] <kepstin> and yes, if you suspend pulseaudio then attempt to read from a pulseaudio device that would cause a deadlock
[16:52:02 CEST] <alexmarkley> the problem i was / am running into is that libav's pulse support has wildly uncontrollably latencies
[16:52:25 CEST] <alexmarkley> kepstin, yeah i figured the pasuspend deadlock out as a separate issue
[16:52:56 CEST] <alexmarkley> i can reproduce the full backtrace if you're interested, but it's working fine while reading from the device, and locking up inside the pulseaudio code during shutdown
[16:53:08 CEST] <Lynne> ffmpeg -f pulse -fragment_size 512 -channels 2 -wallclock 0 -i default gives me a reliable low latency
[16:53:33 CEST] <pa[m]> I resent being called a garbage fire.
[16:53:50 CEST] <alexmarkley> uh oh, no offense intended pa[m]
[16:54:03 CEST] <alexmarkley> unless you are the personal embodiment of pulseaudio :-P
[16:54:15 CEST] <alexmarkley> in which case, some very small amount of offense might be warranted ;)
[16:54:24 CEST] <alexmarkley> Lynne, i will have to give that a try
[16:55:20 CEST] <alexmarkley> i mentioned last night, i'm working on a program which depends on libav* for media in and out ( https://github.com/markleybros/yer-face if anyone is interested )
[16:56:55 CEST] <alexmarkley> so in my demuxing code, what i observed is that often, while performing av_read_frame() on a pulseaudio format context ( https://github.com/markleybros/yer-face/blob/a4a2ec4e6341ce105441cdb0769a32c054299da8/src/FFmpegDriver.cpp#L838 ) the call will block for roughly 1200 milliseconds
[16:57:13 CEST] <alexmarkley> and i get back a huge audio chunk, but i want more frequent, smaller audio chunks
[16:57:52 CEST] <alexmarkley> so investigating THAT problem lead me to experimenting with ALSA which lead me to the lockup problem
[16:57:59 CEST] <alexmarkley> :-P
[17:00:49 CEST] <kepstin> alexmarkley: sounds like Lynne's suggestion -fragment_size is exactly what you wanted to adjust then. It's mentioned in the docs as affecting buffering latency in pulseaudio: https://www.ffmpeg.org/ffmpeg-devices.html#pulse
[17:01:04 CEST] <alexmarkley> yeah i think that sounds really promising
[17:01:25 CEST] <alexmarkley> i'll report back once i've chased down another smaller timing issue in my code
[17:03:10 CEST] <alexmarkley> (actually, harking back to an earlier conversational point, it was the pulse/pasuspend deadlock that first lead me to suspect i was inadvertently interacting with pulseaudio virtual PCMs instead of real PCMs)
[18:45:19 CEST] <alexmarkley> kepstin, Lynne, it looks like the fragment_size parameter may have had a significant effect and it's possible my issues with the pulse demuxer are gone
[18:45:31 CEST] <alexmarkley> still testing though
[20:38:28 CEST] <DanielTheFox> hello, where does -bufsize apply to? encoded video or decoded (raw) video side?
[20:39:22 CEST] <DanielTheFox> like, I have a video that targets 256 kbps and I set -bufsize 512k , will it wait two seconds between bitrate checks? or 16 seconds? or much less? (raw video is enormous)
[20:39:52 CEST] <DanielTheFox> (two video output seconds, not real seconds, unless encoding happened at realtime)
[20:50:57 CEST] <DHE> there's a virtual bucket of bits. when encoding, bits are drained from the bucket and written to file. the bucket is filled at a consistent 256k bits per second
[20:51:42 CEST] <DHE> or alternatively, a user with only 256k of bandwidth (assuming a pure video stream) would only need to buffer/cache for 2 seconds prior to being able to play the video cleanly
[20:52:07 CEST] <DanielTheFox> oh, ok
[20:52:09 CEST] <DanielTheFox> that explains my earlier issues
[20:52:11 CEST] <DanielTheFox> I set -bufsize too big
[20:53:01 CEST] <Thomas_J> What does this mean? "Unable to find a suitable output format for 'rtmp://127.0.0.1/live'
[20:53:01 CEST] <Thomas_J> rtmp://127.0.0.1/live: Invalid argument"
[20:53:32 CEST] <DanielTheFox> you can specify -f mp4 (or any container you want)
[20:53:44 CEST] <Thomas_J> Thanks
[20:53:45 CEST] <kepstin> Thomas_J: you'll typically want "-f flv" for rtmp
[20:53:47 CEST] <DanielTheFox> it has no extension, apparently ffmpeg wasn't able to guess
[20:54:18 CEST] <Thomas_J> I get i/o error with -f flv
[20:55:41 CEST] <Thomas_J> I get i/o error with -f mp4 also.
[21:01:11 CEST] <Thomas_J> ffmpeg i/o/error: https://pastebin.com/E4cVa2z0
[21:17:46 CEST] <kepstin> Thomas_J: looks like there's an issue where it can't connect to your rtmp server on localhost
[21:17:50 CEST] <kepstin> check server logs? :/
[21:19:02 CEST] <Thomas_J> you mean nginx log?
[21:28:32 CEST] <Thomas_J> My nginx logs: https://pastebin.com/YWv8Facn
[21:31:48 CEST] <kepstin> what are you using as an rtmp server? do you have the nginx-rtmp module set up?
[21:35:58 CEST] <Thomas_J> Yes. rtmp is the whole point of having nginx on this server. I use apache2 to host port 80.
[21:37:50 CEST] <Thomas_J> I've been using Apache for over 20 years and now I have to learn a new way of doing things. It has been a real struggle.
[21:44:10 CEST] <Thomas_J> IN nginx'x logs. the only entries that are valuable are the ones for this afternoon. I updated my config file a couple of hours ago. These logs don't show any queries from the local host.
[21:47:18 CEST] <kepstin> my guess is that there's a mismatch or configuration error in your nginx configuration for the rtmp endpoint.
[21:50:14 CEST] <kepstin> like, the last thing in your error log is a message saying it couldn't create the directory to store hls segments in :/
[22:05:59 CEST] <Thomas_J> Thanks for pointing that out. I have been trying to figure out what the root directory path is for nginx and how do I set the root. the ftmp module doesn't like the "root" command anyware in the rtmp {} config.
[22:07:23 CEST] <Thomas_J> And are you saying that the i/o error can be a result of being rejected by the receiving end?
[22:10:46 CEST] <Thomas_J> Also, I reloaaded nginx today. That log entry was entered yesterday. Why am I not seeing that error for today after reloading,
[22:11:44 CEST] <steve___> Thomas_J: these are nginx questions, try their channel
[22:12:38 CEST] <Thomas_J> ffmpeg i/o error can be a result of being rejected by the receiving end?
[22:15:38 CEST] <Thomas_J> Is there a list somewhere for error messages derived from interaction with the receiving end?
[22:20:28 CEST] <kepstin> well, i/o error's pretty much the only thing you'll see with rtmp
[22:20:42 CEST] <kepstin> since the usual error case is that the server just drops the connection on errors
[22:22:34 CEST] <Thomas_J> But it is good to know that this is in fact an output error as a result of not negotiating the ingest with the other end. and not a problem with my ffmpeg command line
[22:23:27 CEST] <Thomas_J> It gives me a place to start. So far I have been working blind in black boxes.
[23:05:14 CEST] <Thomas_J> Okay. I finely got nginz configured (not properly but it does run now) and my ffmpeg test string is rtmping to it. Thanks everyone for your help. I now have a start.
[23:06:04 CEST] <Thomas_J> It's the 4th and I am going AFK.
[00:00:00 CEST] --- Fri Jul  5 2019