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

[burek]

[00:33:57 CEST] <james999> oh sorry i was afk
[00:34:26 CEST] <james999> well wikipedia says that async is the concept of multiple things happening at same time
[00:34:35 CEST] <james999> which is what i thought threads do
[00:35:17 CEST] <kms_> ffmpeg -i rtsp://EEEE -vcodec copy -acodec libmp3lame -ar 44100 -f flv -y 1.flv    dont readable result file
[00:35:28 CEST] <kms_> but stream in vlc is ok
[00:53:41 CEST] <sikilikis> yo, is furq or kepstin on?
[00:54:04 CEST] <furq> i am always online
[00:54:05 CEST] <kepstin> nope, i'm off doing something else right now.
[00:54:06 CEST] <furq> and i'm nice on there
[00:54:18 CEST] <sikilikis> so remember my complaining earlier?
[00:54:23 CEST] <furq> how could i forget
[00:55:02 CEST] <sikilikis> so I may have fixed it. Haven't fully tested yet. But I'm not sure what I did
[00:55:05 CEST] <sikilikis> or why
[00:55:15 CEST] <sikilikis> one, I did a firmware update on the raspberry pi
[00:55:47 CEST] <sikilikis> but at the same time when I was testing ffmpeg (before the update) I kept googling stuff and ran into the vcdbg reloc command
[00:56:03 CEST] <sikilikis> know what that does?
[00:56:20 CEST] <furq> it dumps the heap for debugging
[00:56:26 CEST] <furq> according to this thing i just googled
[00:56:38 CEST] <sikilikis> okay, so when I did that I noticed that it said something about heap corruption
[00:56:46 CEST] <sikilikis> only when running ffmpeg
[00:57:17 CEST] <furq> well vc is only for decoding and encoding
[00:57:23 CEST] <furq> so it's not going to be doing anything when you're not running ffmpeg
[00:57:54 CEST] <sikilikis> is that something that can get fucked up, even between OS installations? I mean its just memory allocation right?
[00:58:03 CEST] <furq> shrug
[00:58:18 CEST] <furq> if you weren't on the latest firmware then that could potentially cause issues
[00:58:21 CEST] <sikilikis> yeah I know it sounds stupid since memory is volatile but
[00:58:30 CEST] <furq> ffmpeg presumably expects a recent firmware
[00:58:42 CEST] <sikilikis> I'm just trying to piece together why updated firmware fixed it if it was working fine before
[00:59:02 CEST] <furq> did you install new firmware after reinstalling
[00:59:10 CEST] <sikilikis> yes
[00:59:14 CEST] <furq> no idea then
[00:59:18 CEST] <sikilikis> no the first time
[00:59:20 CEST] <sikilikis> not*
[00:59:27 CEST] <furq> well yeah i mean before this time
[00:59:44 CEST] <furq> depending on how you installed it, you could've ended up with old firmware
[00:59:46 CEST] <sikilikis> no I didnt. First time just installed the OS and eventually got it working
[00:59:59 CEST] <furq> i'd be inclined to blame that then
[01:00:01 CEST] <sikilikis> I'm using the same OS image I used the first time
[01:00:12 CEST] <furq> yeah i'm guessing you ran rpi-update on the old setup but didn't on the new one
[01:00:28 CEST] <furq> i was running quite old firmware when i first tried to get vc to work and it wouldn't even start encoding
[01:00:31 CEST] <sikilikis> I never ran rpi-update on the old setup and just ran it on this one
[01:00:45 CEST] <sikilikis> but it worked on the old setup for like a month straight
[01:00:46 CEST] <furq> shrug
[01:00:50 CEST] <furq> that's my best guess
[01:01:06 CEST] <sikilikis> I mean it's possible that its still broken. I only tested for like 2 minutes
[01:01:13 CEST] <furq> omx.c in ffmpeg hasn't been updated in a few months
[01:01:21 CEST] <sikilikis> but before it would start getting buffer overruns immediatly
[01:02:40 CEST] <sikilikis> anyway thought you would want to know
[01:08:38 CEST] <gabinante> Hi friends, looking for some direction on segment and concatenate used in sequence, per my question on the ffmpeg forums: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=3643 . I get tiny, near-imperceptible skips in my audio track when I use this method. Anyone have a clue why?
[01:11:40 CEST] <haroldp> Anyone feel like helping me add HLS or Dash support to an otherwise working nginx + ffmpeg setup? :)
[01:18:08 CEST] <Fenrirthviti> haroldp: In theory, you just make a new application block and use exec_push to send the stream there
[01:18:39 CEST] <haroldp> yeah, I have been copy & pasting examples I've found, but not having too much luck
[01:19:09 CEST] <Fenrirthviti> What isn't working?
[01:19:18 CEST] <Fenrirthviti> Can you share what you have now?
[01:19:23 CEST] <haroldp> Dash or HLS :)
[01:19:53 CEST] <haroldp> my RTMP setup is really trivial
[01:20:20 CEST] <haroldp> it just takes a shitty webcam that doesn't have any decent web support, and uses ffmpeg to convert it
[01:21:17 CEST] <haroldp> that works but I can't get RTMP working *reliably* in a browser
[01:22:40 CEST] <Fenrirthviti> well, the rtmp part is easy
[01:22:59 CEST] <Fenrirthviti> you just have to use flash to play it in a browser, no other way around that
[01:23:04 CEST] <haroldp> I was using Flowplayer in the browser
[01:23:25 CEST] <Fenrirthviti> dunno about that, I use video.js and have no issues with rtmp itself
[01:23:40 CEST] <haroldp> hmm, maybe I should try that
[01:23:44 CEST] <furq> er
[01:23:47 CEST] <furq> you don't need to use exec
[01:23:54 CEST] <furq> just add "hls on" to your existing rtmp block
[01:24:20 CEST] <Fenrirthviti> and you need the path
[01:24:27 CEST] <haroldp> don't i need an HTTP block to suppport HLS's meta info requirements too?
[01:24:42 CEST] <Fenrirthviti> and the http location, and doing hls on; disables rtmp playback for that block
[01:24:51 CEST] <furq> no it doesn't
[01:25:32 CEST] <furq> https://gist.githubusercontent.com/qruf/cbd22ebe6afed9cccc0481074aa6e309/raw/1e24220ced9533c75a83667a78f1c7c76c578cc7/nginx.conf
[01:25:35 CEST] <furq> that's more or less what i use
[01:26:05 CEST] <Fenrirthviti> and both rtmp and hls playback work from that?
[01:26:07 CEST] <furq> yeah
[01:26:10 CEST] <haroldp> thanks.  looking.
[01:26:12 CEST] <furq> you need worker_processes 1 iirc
[01:26:28 CEST] <Fenrirthviti> yeah that's true across the board for nginx-rtmp
[01:26:39 CEST] <Fenrirthviti> unless you're on sergey's fork where they sort of fixed multi-worker setups
[01:26:47 CEST] <furq> i'm not
[01:26:56 CEST] <furq> i need to update really
[01:27:06 CEST] <furq> i built this ages ago and i've not touched it since
[01:27:16 CEST] <Fenrirthviti> His fork fixes a ton of stuff, but breaks some key features I use, like recorder blocks
[01:27:35 CEST] <Fenrirthviti> And my HLS issue is not present on his branch, btw, from earlier
[01:27:46 CEST] <furq> i don't see why you'd need multiple workers really
[01:27:52 CEST] <furq> unless you're ingesting thousands of rtmp streams
[01:27:53 CEST] <Fenrirthviti> load balancing I guess?
[01:27:56 CEST] <haroldp> what''s up with the lua configs in your example?
[01:28:00 CEST] <furq> that's for auth
[01:28:01 CEST] <furq> you can ignore that
[01:28:08 CEST] <haroldp> thank you
[01:28:56 CEST] <haroldp> the HTTP examples I've seen include a lot of CORS stuff
[01:29:08 CEST] <Fenrirthviti> You need it depending on how your site is configured.
[01:29:25 CEST] <haroldp> it will be cross domain, so i guess I need that
[01:29:31 CEST] <furq> you don't need it for now
[01:29:41 CEST] <furq> access-control-allow-origin should just disable that
[01:29:42 CEST] <Fenrirthviti> The examples usually do a "allow everything from everywhere" just to bomb the issue out of existence
[01:29:44 CEST] <Fenrirthviti> so try it first without
[01:29:45 CEST] <furq> obviously don't do that in production
[01:30:39 CEST] <haroldp> roger that
[01:30:46 CEST] <furq> there is also no need to serve the fragments from your rtmp nginx
[01:31:01 CEST] <furq> i don't actually run that config, that's just for demonstration
[01:31:08 CEST] <haroldp> Imma see if I can adapt this to my setup.  Thanks again for the example
[01:32:13 CEST] <furq> but yeah all you strictly need is hls on and hls_path
[01:32:35 CEST] <furq> everything else is more or less optional
[01:33:16 CEST] <haroldp> should be ok to omit server_name in the http block until i get a real hostname pointed at it right?
[01:34:01 CEST] <furq> use an ip
[01:34:05 CEST] <haroldp> k
[01:34:27 CEST] <furq> or "_"
[01:35:41 CEST] <haroldp> you just picked 1953 as the HTTP port right?  Could be anything so long as hls_base_url, and on_publish point to it correctly?
[01:35:57 CEST] <Fenrirthviti> adding hls to my normal live block definitely breaks normal RTMP playback.
[01:35:59 CEST] <Fenrirthviti> Just tested it.
[01:36:01 CEST] <furq> on_publish is more auth stuff, you can ignore that
[01:36:15 CEST] <furq> Fenrirthviti: shrug
[01:36:17 CEST] <furq> works for me
[01:36:26 CEST] <furq> i specifically tested that because it was broken with multiple workers
[01:36:43 CEST] <Fenrirthviti> Wonder if it's a bug introduced in later versions then :\
[01:36:55 CEST] <furq> iirc it would actually break hls playback when i connected through rtmp
[01:37:00 CEST] <Fenrirthviti> I'm on latest master from arut
[01:37:08 CEST] <furq> yeah my build is probably a year old at this point
[01:37:37 CEST] <furq> good job it's not actually running or that would be a security concern
[01:37:45 CEST] <Fenrirthviti> haha
[01:37:57 CEST] <furq> although i disabled pretty much everything anyway
[01:37:59 CEST] <Fenrirthviti> HLS playback is working smoother though, when streaming right to the block itself
[01:38:09 CEST] <Fenrirthviti> wonder if push is breaking the stream somehow when it copies it.
[01:38:36 CEST] <furq> what ffmpeg version is that
[01:38:58 CEST] <Fenrirthviti> just nginx push directive, not exec_push
[01:39:00 CEST] <Fenrirthviti> but I'm on...
[01:39:07 CEST] <furq> oh right
[01:39:10 CEST] <furq> probably doesn't matter then
[01:39:11 CEST] <Fenrirthviti> 2.6.9
[01:39:24 CEST] <furq> worth upgrading anyway
[01:39:24 CEST] <Fenrirthviti> for ffmpeg, either method seems to break the playback. very frustrating.
[01:39:40 CEST] <furq> 2.6 is pretty old
[01:40:02 CEST] <Fenrirthviti> yeah, all I used it for on this box was taking screenshots, because the record blocks were broken
[01:40:17 CEST] <furq> https://www.johnvansickle.com/ffmpeg/
[01:40:22 CEST] <furq> assuming your distro isn't packaging anything newer
[01:40:26 CEST] <Fenrirthviti> but I patched those and now I haven't really used it for anything, until I started trying to get mobile playback working
[01:40:29 CEST] <Fenrirthviti> it's debian 8
[01:40:36 CEST] <Fenrirthviti> so not likely
[01:40:43 CEST] <furq> backports has 3.2.4
[01:41:11 CEST] <furq> i've heard fun things about installing ffmpeg from backports though
[01:41:14 CEST] <furq> although mostly on desktop systems
[01:41:22 CEST] <Fenrirthviti> yeah.... I've had nightmares about that.
[01:41:30 CEST] <Fenrirthviti> I can just compile, it's not a hassle
[01:41:36 CEST] <furq> just use the static builds
[01:41:50 CEST] <furq> if you don't have esoteric library requirements then they're perfectly good
[01:42:06 CEST] <Fenrirthviti> I don't really, just x264 is all I need
[01:46:41 CEST] <Fenrirthviti> Let's see if the new version helps any...
[01:47:28 CEST] <haroldp> does this look sane: https://pastebin.com/6Pc9pBRD
[01:47:29 CEST] <Fenrirthviti> furq: ffmpeg -re -i rtmp://stream.rachni.com/live/$name -c copy -f flv rtmp://stream.rachni.com/dash/$name Anything seem off about that for a simple pass-through?
[01:48:05 CEST] <furq> you don't need -re for live sources
[01:48:22 CEST] <Fenrirthviti> ah right, missed that
[01:52:49 CEST] <haroldp> can I test HLS with VLC?
[01:53:46 CEST] <Fenrirthviti> yes
[01:53:48 CEST] <haroldp> looks like I can.  What will the URLs look like?
[01:53:58 CEST] <Fenrirthviti> http://yoursite/hls/name.m3u8
[01:53:58 CEST] <furq> open the m3u8
[01:54:07 CEST] <Fenrirthviti> or whatever you have the path set to
[01:56:06 CEST] <damdai> what is better? i7-3770k  or  ryzen5-1400 (without overclocking on both) ?
[01:56:47 CEST] <haroldp> so in VLC with RTMP I was using: rtmp://my.public.ip/live/cam1
[01:56:50 CEST] <Fenrirthviti> Hm. That command appears to be doing nothing. That's annoying.
[01:57:18 CEST] <haroldp> I should change that to http://my.public.ip:1953/live/cam1.m3u8 ?
[01:57:52 CEST] <Fenrirthviti> hls/cam1.m3u8 is your location you set
[01:58:03 CEST] <haroldp> duh, sorry
[01:59:28 CEST] <damdai> what is better? i7-3770k  or  ryzen5-1400 (without overclocking on both) ?
[01:59:40 CEST] <Fenrirthviti> damdai: Spamming your question is a really bad way to get an answer.
[01:59:49 CEST] <damdai> ok sorry
[01:59:54 CEST] <Fenrirthviti> Also this is a really weird place to be asking something like that.
[02:00:12 CEST] <damdai> not really, because  i am asking what is better for doing ffmpeg related things
[02:00:29 CEST] <Fenrirthviti> Maybe you should include that in your question, with a better explanation on what you're trying to do.
[02:00:49 CEST] <damdai> what is better? i7-3770k  or  ryzen5-1400 (without overclocking on both)  for doing ffmpeg related things?
[02:01:09 CEST] <Fenrirthviti> ...
[02:01:38 CEST] <haroldp> Getting this in my nginx logs: 2017/05/15 16:58:25 [error] 61664#101145: *14 open() "/tmp/hlscam1-36.ts" failed (2: No such file or directory)
[02:02:37 CEST] <haroldp> that file path looks weird
[02:03:14 CEST] <haroldp> it's complaining about no such file "/tmp/hlscam1-36.ts" but /tmp/hls/cam1-36.ts" *does* exist
[02:03:27 CEST] <haroldp> er
[02:03:32 CEST] <haroldp> no it doesn't
[02:03:53 CEST] <haroldp> but /tmp/hls/cam1-58.ts does
[02:04:44 CEST] <haroldp> looks like it in continually creating new files there
[02:04:52 CEST] <Fenrirthviti> yes, that's how HLS works
[02:04:59 CEST] <Fenrirthviti> you have the playlist, and then a rolling set of .ts fragments
[02:05:01 CEST] <furq> you're missing part of the path
[02:05:02 CEST] <haroldp> that path with the missing / is odd tho
[02:05:11 CEST] <furq> oh right
[02:05:19 CEST] <furq> i guess hls_path needs the trailing slash
[02:05:30 CEST] <haroldp> that was my first guess too
[02:05:31 CEST] <Fenrirthviti> doesn't on mine, weird.
[02:05:36 CEST] <furq> yeah mine doesn't have that either
[02:05:44 CEST] <Fenrirthviti> I just checked when I saw, and works fine without it
[02:05:47 CEST] <haroldp> tried it with a trailing /, but i get teh same result
[02:07:19 CEST] <haroldp> is "root /tmp" right in the HTTP block if I have "hls_oath /tmp/hls/ in the RTMP block?"
[02:07:59 CEST] <Fenrirthviti> yes
[02:08:10 CEST] <Fenrirthviti> because your location is /hls, with root of /tmp
[02:08:53 CEST] <haroldp> haha
[02:09:02 CEST] <haroldp> I tried it and the result was this error: 2017/05/15 17:08:36 [error] 63765#100621: *2 open() "/tmp/hls/hls/cam1.m3u8" failed (2: No such file or directory)
[02:09:15 CEST] <haroldp> pretty sure its just fucking with me now.  :)
[02:14:12 CEST] <Fenrirthviti> urg, starting to get really annoyed at vlc locking up on me on these broken hls streams.
[02:15:07 CEST] <james999> Fenrirthviti: i've force quit VLC so many times on xbox and pc and phone I've lost track
[02:15:24 CEST] <james999> now i just sort of assume that's the default way of closing it
[02:15:29 CEST] <Fenrirthviti> hah
[02:15:46 CEST] <Fenrirthviti> I normally use mpc-hc, but vlc seems to do better with network stuff
[02:16:04 CEST] <Fenrirthviti> and I'm pretty sure it's in part due to the errors in the hls stream being sent there, but still annoying :\
[02:18:57 CEST] <haroldp> Working!  It was hls_base_url that was missing a trailing slash.
[02:20:33 CEST] <haroldp> Would you recommend video.js to embed an HLS stream in a web page?
[02:20:45 CEST] <Fenrirthviti> Ah damn, I am going to need to compile myself. The static ffmpeg binaries don't have libfaac :(
[02:26:29 CEST] <james999> Fenrirthviti: what system/kernel?
[02:27:14 CEST] <Fenrirthviti> debian 8
[02:27:16 CEST] <furq> Fenrirthviti: you don't need libfaac any more
[02:27:26 CEST] <furq> the builtin aac encoder is better now
[02:27:32 CEST] <furq> not that that's difficult, faac was always shit
[02:27:36 CEST] <Fenrirthviti> oh is it? neat.
[02:27:57 CEST] <Fenrirthviti> So far I'm still getting the CC errors, but playback is working a little better with the updated binaries
[02:28:12 CEST] <furq> you'd need to rebuild for fdk-aac because that's nonfree
[02:28:17 CEST] <furq> but you only really need that for he-aac
[02:29:57 CEST] <Fenrirthviti> argh I don't fucking understand this. the command is running, it works fine when run via CLI, but when invoked from nginx it does nothing
[02:29:59 CEST] <furq> have they still not released debian 9
[02:30:09 CEST] <Fenrirthviti> april 17th I think it was released
[02:30:13 CEST] <furq> it's still not out
[02:30:30 CEST] <furq> all my boxes are on testing, so they've had frozen packages for three months now
[02:30:50 CEST] <Fenrirthviti> or maybe 15th? something happened on the 15th
[02:31:05 CEST] <Fenrirthviti> Ah wait, I'm thinking ubuntu, not debian, disregard.
[02:31:08 CEST] <furq> oh
[02:31:15 CEST] <furq> the 15th was the last status update
[02:31:17 CEST] <furq> coincidentally enough
[02:31:35 CEST] <Fenrirthviti> yeah I remember hearing something, and then ubuntu updated as well around the same time, got them mixed up
[02:32:06 CEST] <Fenrirthviti> and friggin stdout routing of course doesn't work reliably in nginx
[02:32:22 CEST] <mccc> Hi, for the last couple days I've been asking about a problem where my recorded audio has been playing about 5%-10% slower than it should - I think this was a hardware problem, when I swapped the soundcard it started recording at the correct speed.  Thanks for those looking at it :)  I've got HLS now working using MPEG2-TS and AAC, I think my next project is going to be getting HLS or DASH
[02:32:22 CEST] <mccc> working with fMP4.
[02:32:45 CEST] <furq> stdout routing?
[02:32:53 CEST] <furq> mccc: i wouldn't bother with fmp4 for hls
[02:32:57 CEST] <Fenrirthviti> for exec directives
[02:33:04 CEST] <furq> oh
[02:33:07 CEST] <furq> ffmpeg outputs on stderr
[02:33:13 CEST] <Fenrirthviti> you should be able to route stdout/stderr
[02:33:15 CEST] <Fenrirthviti> neither really works.
[02:33:18 CEST] <furq> fair enough
[02:33:26 CEST] <Fenrirthviti> &>> log.log does nothing
[02:33:29 CEST] <Fenrirthviti> very frustrating.
[02:34:04 CEST] <furq> does it have the right permissions
[02:34:15 CEST] <mccc> furq - why not, just because mpeg2-ts works for HLS so why bother?  I'm also looking at using DASH instead where mpeg2-ts isn't supported on some platforms.
[02:34:29 CEST] <furq> mccc: yeah it's only worth doing if you want to use the same fragments for hls and dash
[02:34:35 CEST] <Fenrirthviti> it does, yeah
[02:34:38 CEST] <furq> but there isn't really much point using dash for live streams
[02:34:44 CEST] <furq> even youtube uses hls
[02:34:51 CEST] <furq> and they're the biggest user of dash
[02:36:21 CEST] <mccc> furq - sure, I'm pretty happy I've gotten this working fine with hls :) I do have a combination of on-demand and live content though and dash seems to offer more options - one in particular is specifying that only part of the last segment in a playlist should actually play out.
[02:36:26 CEST] <james999> furq: how long are package updates frozen with debian testing?
[02:36:33 CEST] <furq> until it becomes stable
[02:36:43 CEST] <furq> which has been "any day now" for about a month
[02:37:04 CEST] <james999> ok
[02:37:12 CEST] <haroldp> Holy!  I have a working web cam in the browser!
[02:37:32 CEST] <furq> i bet you've got some world-class latency on it as well
[02:37:37 CEST] <haroldp> furq & Fenrirthviti: thanks so much for your help.
[02:37:53 CEST] <Fenrirthviti> probably around 20s on top of whatever else, yeah
[02:38:19 CEST] <haroldp> It's a dumb customer who bought dumb cams but still wants them embedded in his public web page
[02:38:46 CEST] <furq> well then who cares about the latency
[02:38:52 CEST] <haroldp> not me :)
[02:41:05 CEST] <Fenrirthviti> $name.m3u8
[02:41:05 CEST] <Fenrirthviti>  wat.
[02:41:10 CEST] <Fenrirthviti> nginx has forgot how2variable
[02:41:15 CEST] <furq> noice
[02:41:35 CEST] <Fenrirthviti> That would explain why the command was failing in nginx, but not CLI
[02:44:07 CEST] <haroldp> wow, works in crome, ff and safari.
[02:44:20 CEST] <haroldp> dod I dare try IE? :)
[02:44:24 CEST] <Fenrirthviti> hls should work on most devices these days
[02:45:17 CEST] <DHE> anything that doens't do HLS natively should work with HLS.js
[02:45:39 CEST] <haroldp> Anyway, Imma go make dinner now.  Seriously though, thanks again!  Huge help.
[02:53:44 CEST] <Fenrirthviti> Well I have no idea what to do from here. Debugging nginx not parsing its own variable for some reason is well outside my abilities :(
[02:59:53 CEST] <james999> well Fen
[03:00:10 CEST] <james999> I couldn't even get an rtsp thing to ork in nginx after I searched for an hour to find a version fo nginx with rtmp support!
[04:32:59 CEST] <furq> https://pbs.twimg.com/media/C_6goddWAAAl8rR.jpg
[04:33:01 CEST] <furq> i changed my mind
[04:33:03 CEST] <furq> interlacing is good now
[04:33:37 CEST] <james999> @_@
[04:33:50 CEST] <james999> Hey furq speaking of eccentric politicians
[04:33:56 CEST] <james999> what do you think of this philip davies guy?
[04:34:10 CEST] <furq> i think i just had to google him
[04:34:35 CEST] <james999> ah ok. he got himself elected or something to a gender and equality committe in parliament
[04:34:38 CEST] <furq> also that was an excellent segue
[04:35:00 CEST] <james999> thanks
[04:35:16 CEST] <james999> I mean say what you will good or bad about trump
[04:35:20 CEST] <james999> he likes his steak well-done
[04:35:25 CEST] <furq> with ketchup
[04:35:25 CEST] <james999> which is pretty odd in my book
[04:35:37 CEST] <james999> yes.. lol
[04:36:02 CEST] <furq> my favourite thing about that was all the #MAGA people on twitter suddenly deciding that that was a manly way to eat steak
[04:36:30 CEST] <james999> lol sounds like that silly twitter meme about milk being racist
[04:36:35 CEST] <james999> but who knows maybe it's real
[04:39:03 CEST] <james999> By the way, an excellent method of finding overviews of technical stuff on google is with a search like "pci intro filetype:pdf site:.edu"
[04:39:22 CEST] <james999> even though you'll get a lot of crappy power point slides masquerading as pdfs. T_T
[06:51:42 CEST] <hanna> james999: it's even more fun when you have home HOME on NFS
[06:51:48 CEST] <hanna> pull cable -> entire desktop locks up, including all programs
[06:52:05 CEST] <hanna> that was re: blocking filesystem on linux
[07:07:44 CEST] <james999> hah wow
[07:08:28 CEST] <hanna> Oh and heaven help you if you try using anything that enumerates block devices while in the process of issuing an ATA secure erase
[07:08:34 CEST] <hanna> once had a system with load 200 due to it :D
[07:08:41 CEST] <james999> yeah that convo was me trying to see if anybody had a good book on writing concurrent programs
[07:08:50 CEST] <james999> but now with my new google fu mb i'll find one myself
[07:09:02 CEST] <hanna> james999: http://chimera.labs.oreilly.com/books/1230000000929 language specific but contains a lot of knowledge
[07:09:16 CEST] <hanna> free online
[07:09:36 CEST] <james999> hmm well i wasn't too sure about that concept
[07:09:41 CEST] <james999> but now i think i'm more open to it
[07:10:01 CEST] <hanna> also one of the best books about haskell ever written :p
[07:10:44 CEST] <james999> haha ok
[07:11:15 CEST] <james999> the one thing that seems to be constant in computers is constant new hardware and constant new languages
[07:11:23 CEST] <james999> without there necessarily being a relationship there
[07:12:09 CEST] <hanna> constant innovation is a human property
[07:12:13 CEST] <james999> there was a mathematician who wrote on his blog about some java app to draw diffeq graphs...
[07:12:23 CEST] <james999> he asked can he just write a program and have it work for all time
[07:12:24 CEST] <hanna> we're too curious/creative for our own good
[07:12:36 CEST] <james999> yeah
[07:12:56 CEST] <james999> i mean you could specify an abstract machine with xyz properties to run your code on
[07:13:08 CEST] <james999> but you have no guarantee anybody will emulate that machine
[07:13:19 CEST] <hanna> wow you're already thinking like a haskell programmer :^)
[07:13:41 CEST] <james999> lol more like 86box programming. been hanging out here for a few days
[07:13:51 CEST] <james999> i'm stunned how much knowledge of windows alone is in here
[07:14:23 CEST] <hanna> know your enemy, huh
[07:14:53 CEST] <damdai> what is better? i7-3770k  or  ryzen5-1400 (without overclocking on both)  for doing ffmpeg related things?
[07:15:32 CEST] <hanna> TD-Linux ought to know this ^
[07:17:04 CEST] <TD-Linux> the CPU choice question?
[07:17:21 CEST] <james999> hanna: oh lol sorry i said it in wrong channel
[07:17:35 CEST] <james999> yeah i'm a secret undercover double agent or something. XD
[07:18:10 CEST] <hanna> TD-Linux: yes
[07:18:14 CEST] <TD-Linux> i7-3770k
[07:18:17 CEST] <hanna> (am also curious)
[07:18:27 CEST] <hanna> isn't it pretty old
[07:18:31 CEST] <TD-Linux> probably look it up to see
[07:18:32 CEST] <hanna> and the ryzen pretty new and hip
[07:18:42 CEST] <hanna> oh ryzen 5 not ryzen 7
[07:18:45 CEST] <TD-Linux> that was gut instinct
[07:18:49 CEST] <TD-Linux> 4c vs 4c
[07:18:51 CEST] <hanna> AKA the poor one
[07:31:03 CEST] <c3r1c3-Win> You're better getting the 6-core Ryzen 5.
[07:42:41 CEST] <c3r1c3-Win> Yeah, mark my last comment up for the "Captain Obvious" award of the year.
[11:47:32 CEST] <dystopia_> morning
[11:47:48 CEST] <dystopia_> ffmpeg.exe -i in.ts -c:v copy -c:a mp2 out.ts
[11:48:07 CEST] <dystopia_> trying to lower the bitrate of audio from 384 kbps to 192 kbps
[11:48:22 CEST] <dystopia_> what should i add to the "-c:a mp2 " ?
[11:48:43 CEST] <james999> i'm not sure i want to work in an office where people start out by saying "good morning. Can you execute ffmpeg -i ...."
[11:48:45 CEST] <james999> XD
[11:48:57 CEST] <furq> why would you use mp2
[11:49:08 CEST] <dystopia_> it already is mp2 furk
[11:49:15 CEST] <dystopia_> i just want to lower it's bitrate
[11:49:16 CEST] <furq> so use the opportunity to make it something better
[11:49:26 CEST] <dystopia_> i will need to do the same with ac3 later
[11:49:27 CEST] <dystopia_> well
[11:49:49 CEST] <dystopia_> this is a 1 second video, that will be appended on to the front of another video
[11:49:51 CEST] <james999> isn't it reencoding either way?
[11:50:00 CEST] <dystopia_> i just want to maintain encoding settings in a file
[11:50:08 CEST] <dystopia_> because the file i append to will be cut after encode
[11:50:38 CEST] <dystopia_> and loose it's settings
[11:50:58 CEST] <dystopia_> anyway :p
[11:51:13 CEST] <dystopia_> how should i issue the command
[11:51:49 CEST] <james999> I used -b before but i think it was total bitrate not audio alone
[11:54:26 CEST] <dystopia_> that did it james999
[11:54:30 CEST] <dystopia_> -b:a 192k
[11:54:32 CEST] <dystopia_> thank you
[11:57:43 CEST] <james999> np
[11:58:18 CEST] <james999> hey furq, apparently merkel is willing to sacrifice the german car industry in the talks
[11:58:26 CEST] <james999> does that mean no more cheap german cars for you guys?
[11:58:58 CEST] <durandal_170> offtopic
[14:52:40 CEST] <saulotoledo> Hello all :D   I need some help with MPEG2 Transport Stream. Is there somebody here that can help me?  I want to understand how the TS works, and I do not know where I can get some help about. I do not understand how the descriptors are transferred inside the PMT table. Can somebody help me? If this is off-topic, please send me a PM. Thanks in advance.
[14:55:01 CEST] <DHE> the descriptors are stream metadata, such as the language identifier for the audio. can you be more specific about what you need?
[17:14:29 CEST] <alexpigment> does anyone know if it's possible to have an LGPL version of FFMPEG link to a commercially licensed copy of x264 and use it as if it were a natively included copy?
[17:15:02 CEST] <alexpigment> i'd like to try and avoid creating elementary streams and muxing at the end of the process if possible
[17:20:39 CEST] <furq> alexpigment: there's nothing legally wrong with it but you'd have to patch configure yourself
[17:21:16 CEST] <alexpigment> furq: yeah, i was looking at this link earlier: https://ffmpeg.org/pipermail/ffmpeg-devel/2010-December/083754.html
[17:21:17 CEST] <furq> there was an ml thread about adding support in configure a while back and it seems to have gone nowhere (imagine that)
[17:21:20 CEST] <alexpigment> i assume that's what you're talking about
[17:21:20 CEST] <furq> yeah that's the one
[17:21:26 CEST] <alexpigment> k
[17:21:41 CEST] <alexpigment> just wanted to make sure there wasn't an easier solution since then
[17:21:44 CEST] <alexpigment> thanks
[17:22:05 CEST] <furq> i'm not really an expert on the matter
[17:22:09 CEST] <furq> it should be a simple fix though
[17:23:05 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L1505
[17:23:10 CEST] <furq> i think you'd just have to remove that line
[17:23:29 CEST] <alexpigment> oh gotcha
[17:23:32 CEST] <alexpigment> well that makes it easy :)
[17:23:37 CEST] <alexpigment> thank you furq
[17:23:47 CEST] <furq> obviously i am not a lawyer and what you do with this information is your own legal responsibility
[17:23:51 CEST] <furq> i'm pretty sure it's fine though
[17:25:02 CEST] <alexpigment> no worries, i'm very familiar with the "i'm not a lawyer" clause :)
[17:25:29 CEST] <alexpigment> anyway, thanks again
[18:05:44 CEST] <amosbird> hello
[18:05:50 CEST] <amosbird> how can I fix this https://la.wentropy.com/JAB5  ?
[18:05:58 CEST] <amosbird> is it due to deprecate argss
[18:06:00 CEST] <amosbird> ?
[18:13:54 CEST] <amosbird> what does this mean   Past duration 0.800468 too large   ?
[18:19:51 CEST] <dystopia_> [17:13:56] <amosbird> what does this mean   Past duration 0.800468 too large   ?
[18:20:02 CEST] <amosbird> huh?
[18:20:05 CEST] <dystopia_> your encoding at a diff frame rate than the video actually is
[18:20:21 CEST] <amosbird> so is it harmful?
[18:20:32 CEST] <dystopia_> no but you may have a dupe frame
[18:21:09 CEST] <dystopia_> i guess your encoding 23.97 stuff at 25fps or somthing like that
[18:24:20 CEST] <amosbird> um
[18:24:39 CEST] <amosbird> is it due to incorrect args? or because my cpu is slows
[18:24:41 CEST] <amosbird> ?
[18:26:18 CEST] <dystopia_> incorrect input settings
[18:27:50 CEST] <amosbird> thanks!
[19:11:25 CEST] <kepstin> I most often see that when ffmpeg misdetects the input framerate - if you have a file that ffmpeg detects as 24fps, but it has sections at 30fps, you'll get that message on the 30fps seconds and it'll drop frames.
[19:12:10 CEST] <kepstin> (particularly on vfr containers like mkv)
[19:38:13 CEST] <sikilikis> yo furq
[19:38:33 CEST] <sikilikis> quick question about the alsa buffer xrun stuff. Do you think it could be caused if I run ffmpeg at too low of a frame rate?
[19:56:01 CEST] <BtbN> sikilikis, as long as ffmpeg is running at 1x speed, it should be fine
[19:57:23 CEST] <ChocolateArmpits> Are filters threaded in any other way other than slice threads? I've built a pretty extensive filter graph and it's not keeping up realtime even though the cpu utilization is only around 7%
[19:58:51 CEST] <BtbN> pretty sure ffmpeg.c works the decoder->filters->encode graph in order, in a single thread
[19:59:16 CEST] <DHE> ChocolateArmpits: no, it's not.
[19:59:22 CEST] <DHE> (believe me, i want to fix that)
[19:59:42 CEST] <ChocolateArmpits> so all frames are sequenced rather than get processed out of order and then ordered correctly on output ?
[19:59:59 CEST] <BtbN> even with threads, you can't re-order them
[20:00:44 CEST] <DHE> I think at best you could pipeline them - have each filter run in its own thread, but still processing them in order
[20:00:51 CEST] <DHE> but that's still some major work
[20:01:20 CEST] <ChocolateArmpits> DHE, I used this prior, but it's additional stability risk to run several processes
[20:02:06 CEST] <DHE> it also introduces a lot of overhead for uncompressed frame copying between processes
[20:04:47 CEST] <ChocolateArmpits> In my case, the HD input of a capture card gets split across two filtergraphs, both deinterlacing and scaling to appropriate resolutions. The single input audio track gets split into 4 channels and each gets the loudness adjusted using loudnorm.
[20:05:36 CEST] <ChocolateArmpits> Processing of SD input is doing good, but the higher amount of data with HD makes it hard to achieve realtime processing
[20:06:05 CEST] <ChocolateArmpits> I'll probably have to drop loudnorm, doing simpler video filtering isn't enough
[20:06:20 CEST] <DHE> well, you might get better results with a single deinterlace filter and then rescale the output twice
[20:06:30 CEST] <DHE> not miracle worker levels, but a good first easy step
[20:06:44 CEST] <ChocolateArmpits> yeah it sort of works, until the audio processing step gets introduced
[20:09:42 CEST] <satinder___> Hi can we get microblock infomartation using ffmpeg
[20:10:08 CEST] <DHE> macroblock?
[20:10:25 CEST] <satinder___> yes
[20:10:36 CEST] <DHE> well, there's this: https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVectors
[20:10:37 CEST] <satinder___> DHE : macroblock
[20:10:53 CEST] <satinder___> ok
[20:14:06 CEST] <satinder___> DHE :  thanks for share this link
[20:14:54 CEST] <satinder___> but can I do these things using api and compare each frame with reference frame
[20:15:01 CEST] <satinder___> Is that possible
[20:48:02 CEST] <saulotoledo> DHE: hi. Thank you for your response about the descriptors. I need to understand how they are transmitted. They are in the ES loop inside the PMT. Each loop item contains one ElementaryPID and a loop of descriptors. I also know that the descriptors are transmitted in the DSM-CC. SO the elementatyPID in the PMT loop points to a future TS Packet containing the DSM-CC?
[20:50:01 CEST] <saulotoledo> DHE: Also, what is the difference between the descriptor loop in the PMT body (PMT.descriptors) and the descriptor loop inside the each stream loop (PMT.streamLoop[n].descriptors)?
[20:50:10 CEST] <DHE> have you considered saving a .ts file to disk and opening it in wireshark? it can dissect it for you with a lovely GUI
[20:50:51 CEST] <DHE> no really. do it.
[20:50:55 CEST] <zerodefect> I am able to broadcast an mpeg-2v encoded (no audio) transport stream using the ffmpeg api.  I can render the stream using ffplay. I was wondering how to configure avformat_alloc_output_context2(..) to encapsulate the ts stream within RTP instead of UDP.  Is that possible?
[20:52:00 CEST] <saulotoledo> DHE: I was using a TS analyzer tool, but I am not sure about these questions :(
[20:52:24 CEST] <saulotoledo> DHE: I am still unable to understand the difference between the descriptors
[20:53:17 CEST] <DHE> if you are interested in the wire protocol (and it sounds like you are), playing with it in wireshark can be very useful. it will break the mpeg-ts into its 188 byte chunks and break down each stream's headers, descriptors and all the rest.
[20:56:29 CEST] <zerodefect> I've tried avformat_alloc_output_context2(&oc, NULL, "mpegts", rtp://127.0.0.1:5500), but the output errors with 'Data doesn't look like RTP packets.'  It's fine with udp://127.0.0.1:5500 though.
[20:56:39 CEST] <zerodefect> It makes me think I'm using the wrong muxer?
[21:03:21 CEST] <saulotoledo> DHE: Thanks. I am already checking using Wireshark and I will come back here if I have more doubts. :)
[21:12:33 CEST] <kepstin> zerodefect: 'mpegts' is not rtp, so yes?
[21:14:31 CEST] <kepstin> zerodefect: rtp is a network protocol that directly contains codec data, so you need to encapsulate using the 'rtp' muxer for it to work
[21:17:00 CEST] <zerodefect> Thanks kepstin. If I used the 'rtp' muxer then the rtp payload would only contain the video essence (not any of the container)?
[21:18:05 CEST] <kepstin> zerodefect: rtp contains the video (and audio, etc.) streams directly, it does not transport other container formats.
[21:18:43 CEST] <kepstin> if you just want to transport mpeg-ts over udp, that's what the 'udp://' protocol is for.
[21:19:06 CEST] <zerodefect> Ok. As I suspected. Then what muxer do I use to encapsulate TS in RTP?
[21:22:41 CEST] <DHE> he literally just said you don't
[21:24:34 CEST] <zerodefect> So can I draw the conclusion that it's not possible?
[21:24:46 CEST] <BtbN> rtp _is_ a container.
[21:25:24 CEST] <zerodefect> Ok. That is where the confusion is coming in from my part :(
[21:27:08 CEST] <faLUCE> hello. Do you know any library for demuxing mpeg-ts in async way?
[21:28:32 CEST] <__jack__> libav ?
[21:28:51 CEST] <faLUCE> __jack__: it doesn't provide an async API for demuxing
[21:29:06 CEST] <zerodefect> Looking through the source, I've come across the 'rtp_mpegts' option which can be specified as a 'format name' to the aforementioned function.
[21:29:15 CEST] <__jack__> what do you mean by "async" (please be specific)
[21:29:17 CEST] <zerodefect> That looks to do as it says on the tin
[21:29:29 CEST] <__jack__> are you talking about things like asyncio ?
[21:29:41 CEST] <zerodefect> I'll give that a try
[21:30:34 CEST] <faLUCE> __jack__: I mean that it doesn't support non-blocking I/O.
[21:30:45 CEST] <faLUCE> and I need a non-blocking av_read_frame()
[21:34:42 CEST] <zerodefect> So 'avformat_alloc_output_context2(&oc, NULL, "rtp_mpegts", rtp://127.0.0.1:5500)' is encapsulating the TS stream in RTP packets.
[21:34:58 CEST] <zerodefect> That is what I needed.
[21:35:20 CEST] <kepstin> zerodefect: wait, that's actually a defined format?
[21:35:29 CEST] <kepstin> that's really weird, huh.
[21:35:51 CEST] <BtbN> why would you ever need that?
[21:35:56 CEST] <BtbN> Some weird destination or something?
[21:36:02 CEST] <zerodefect> Looks to work :)  It plays fine from FFPlay and VLC :)
[21:36:25 CEST] <kepstin> i mean, what's the benefit in doing that over just putting the a/v directly in rtp?
[21:36:35 CEST] <BtbN> putting mpegts into rtp seems redundant to me
[21:36:35 CEST] <kepstin> or putting the mpegts directly in udp?
[21:36:57 CEST] <kepstin> I guess you have rtcp so it can do retransmits and stuff, so it's better than directly in udp, but...
[21:36:59 CEST] <BtbN> well, rtp can actually handle packet loss. mpegts in udp can't nearly as well
[21:37:12 CEST] <BtbN> But it can do so fine without mpegts
[21:37:15 CEST] <zerodefect> I was writing a bit of code to test a proprietary IRD. One of the formats it accepts is TS in RTP.
[21:37:36 CEST] <zerodefect> I have no affiliation with the manufacturer of the IRD (for the record).
[21:37:48 CEST] <BtbN> does it not accept normal rtp?
[21:38:49 CEST] <zerodefect> Not seen that listed yet, but it may be an option.
[21:39:07 CEST] <zerodefect> If you were using DVB, could RTP then have any added benefit?
[21:41:23 CEST] <BtbN> you're not putting a container into a container
[21:41:43 CEST] <BtbN> If you need some features mpegts supports but rtp doesn't, I can see it being useful
[21:41:59 CEST] <BtbN> Can also see why emdeded devices use it, as all they process is mpegts
[21:42:45 CEST] <zerodefect> What about FEC?
[21:43:00 CEST] <zerodefect> Could that have an impact of choice of protocol?
[21:43:20 CEST] <BtbN> I'm not aware of any fec in mpeg-ts
[21:43:28 CEST] <BtbN> It's just error-resilient by design
[21:43:47 CEST] <kepstin> you could probably use e.g. the rfc 5109 generic fec with it, but I doubt anything supports that :)
[21:43:47 CEST] <zerodefect> I see
[21:44:17 CEST] <BtbN> you rarely have actual transport errors over the internet anyway
[21:44:21 CEST] <BtbN> you lose packets whole
[21:44:58 CEST] <kepstin> well implemented fec (like in opus) can hide lost packets, which is kinda neat
[21:45:39 CEST] <zerodefect> Does it use a Row x Column matrix?
[21:45:54 CEST] <kepstin> I have no idea how that works, but opus fec is designed explicitly to fill in lost packets, rather than handle corrupt packets
[21:48:13 CEST] <zerodefect> Well, thanks for your help all.
[21:48:59 CEST] <kepstin> I suppose one of the benefits of mpegts in rtp is that it only needs one port for a+v, but many modern rtp implementations can do multiple rtp+rtcp muxed on a single port (RFC 5761)
[21:50:21 CEST] <zerodefect> Yes. Throwing it in mpegts instad of separate streams probably also makes lip sync easier?
[21:53:16 CEST] <kepstin> nah, rtp has a timestamping system that handles that just fine.
[21:53:31 CEST] <__jack__> faLUCE: I quick read the code, there is this: "One such case is when you want to use custom functions for reading input data instead of lavf internal I/O layer. To do that, create your own AVIOContext with avio_alloc_context(), passing your reading callbacks to it. Then set the @em pb field of your AVFormatContext to newly created AVIOContext."
[22:12:37 CEST] <phishy> Imagine my dismay when I used 92 physical cores for my ffmpeg command and it wasn't fast. https://www.packet.net/bare-metal/servers/type-2a
[22:15:46 CEST] <ChocolateArmpits> phishy, are you sure io isn't bottlenecking ?
[22:16:40 CEST] <phishy> ChocolateArmpits: does it get better than SSD?
[22:16:48 CEST] <kepstin> even with a codec like x264 which has pretty good thread scaling, you're not gonna be able to use all those cores with one ffmpeg command...
[22:17:02 CEST] <kepstin> and arm cores, so each individual cores is gonna be slow... :/
[22:17:29 CEST] <ChocolateArmpits> I think the troubles start with multiple processors
[22:17:39 CEST] <phishy> kepstin, I'm just bummed because I can't get anywhere near the performance that my friend can get on his Mac
[22:18:00 CEST] <phishy> I'm kinda wondering if there is more to it than CPU and disk
[22:18:01 CEST] <ChocolateArmpits> Then you have to turn on sliced threading and some additional parameters for the process if you're on windows
[22:18:25 CEST] <ChocolateArmpits> phishy, can't you check ssd utilization ?
[22:18:36 CEST] <DHE> phishy: how do I purchase such a machine and have it shipped to my location? :)
[22:19:07 CEST] <phishy> DHE, I think the guys at that web site will sell you their old ones
[22:19:13 CEST] <Mista_D> Has anyone tried muxing SCC Scenarist files with newest FFmpeg? What is the command please?
[22:21:37 CEST] <kepstin> phishy: basically, intel cpu cores (and recent amd ones) are really, really fast compared to the individual arm cores on that box, and x264 is much better optimized for them, so...
[22:22:15 CEST] <phishy> kepstin, thanks for that info. damned computer science, always getting in the way
[22:22:58 CEST] <kepstin> and video encoding multithreading is one of those diminishing returns with more cores kind of things... the slower settings and larger the video frames you're encoding, the more cores it can potentially use
[22:36:36 CEST] <ChocolateArmpits> try out slices, really
[22:41:12 CEST] <cryptodechange> could encoding with no audio, then muxing audio in from source produce an out of sync result?
[22:41:37 CEST] <ChocolateArmpits> cryptodechange, well does it ?
[22:41:44 CEST] <cryptodechange> haven't tried :P
[22:42:03 CEST] <cryptodechange> but in theory it shouldn't, right?
[22:42:08 CEST] <ChocolateArmpits> well yeah
[22:42:23 CEST] <ChocolateArmpits> Unless you do fast seeking
[22:42:34 CEST] <ChocolateArmpits> That may introduce problems
[22:42:59 CEST] <cryptodechange> is that a parameter?
[22:43:11 CEST] <cryptodechange> seeing as i haven't heard of it/used it, it shouldn't be a problem
[22:43:18 CEST] <ChocolateArmpits> well if you don't need to seek the file, then it shouldn't be of any bother
[22:43:48 CEST] <cryptodechange> I would like to with the end result
[22:44:47 CEST] <faLUCE> __jack__: I well know how to create a custom read callback linked to a custom I/O context. But this doesn't solve anything, nor it gives an asynchronous way of demuxing packets
[22:57:29 CEST] <rictan> Is there a way to configure ffmpeg binary to support only fragmented mp4 to mp4?
[22:58:31 CEST] <rictan> Something such as ./configure --disable-everything <parameters_to_enable fragmented mp4 to mp4>
[23:01:53 CEST] <cryptodechange> Is there any documentation on aq-mode=3?
[23:02:24 CEST] <faLUCE> anyway, I found that: https://github.com/frejoel/tsdemux . It supports async demuxing
[23:02:45 CEST] <cryptodechange> I am getting 'Too many packets buffered for output stream 0:1.' when trying to copy a TrueHD stream
[23:14:50 CEST] <kepstin> rictan: there's a few things that you can't disable while still having the ffmpeg cli work at all, and the mp4 muxer/demuxer can't be limited to just that use case, but you certainly can cut out a lot of the other stuff you don't need...
[23:34:07 CEST] <sikilikis> anyone know if I can increase the alsa buffer size on ffmpeg?
[23:34:37 CEST] <blue_misfit> hey guys! When using -ss and -to I normally have no issues, but when doing a job with 2 outputs ffmpeg seems to not respect the -to flag and encodes until the end of the file - how can I avoid this?
[23:35:10 CEST] <furq> -to is an output option
[23:35:14 CEST] <furq> you need to specify it for every output
[23:35:27 CEST] <blue_misfit> I see
[23:35:46 CEST] <blue_misfit> so if I'm doing -to 28 for video
[23:35:56 CEST] <blue_misfit> and I have a jpeg sequence also outputting at .1 fps
[23:36:07 CEST] <blue_misfit> do I need to make that 2.8?
[23:36:14 CEST] <furq> it should be the same
[23:36:15 CEST] <blue_misfit> or... hmm guessing no
[23:36:17 CEST] <blue_misfit> yeah
[23:36:18 CEST] <blue_misfit> ok
[23:36:21 CEST] <blue_misfit> let's see..
[23:36:28 CEST] <furq> or you could just use -t as an input option
[23:36:39 CEST] <kepstin> blue_misfit: -to takes a value in seconds, using a different framerate doesn't change how fast time passes ;)
[23:36:47 CEST] <blue_misfit> of course :)
[23:37:16 CEST] <Threads> nice to see someone from disney stop by
[23:37:23 CEST] <blue_misfit> hello! :)
[23:37:28 CEST] <furq> what if i use a really high negative framerate
[23:37:31 CEST] <furq> like in superman 1
[23:37:32 CEST] <blue_misfit> brilliant that totally works
[23:37:40 CEST] <blue_misfit> lol!
[23:37:46 CEST] <Threads> hello
[23:41:07 CEST] <sikilikis> Is there some way to increase the alsa buffer size? I'm still getting alsa xruns and I'm at my limit. At this point I figure I could just increase the buffer size and hope that it tanks any performance hits
[23:42:03 CEST] <durandal_170> isnt that becuse off high cpu usage
[23:42:24 CEST] <sikilikis> you'd think so but that isnt whats happening
[23:42:33 CEST] <BtbN> you're either fast enough to keep up, or you aren't
[23:42:36 CEST] <BtbN> no buffer can fix that
[23:43:03 CEST] <sikilikis> they dont happen constantly though. It's random
[23:43:23 CEST] <sikilikis> sometimes its often and sometimes its not
[23:45:02 CEST] <Cracki> cheers. looking for python bindings. what's the most advisable project/package/repo for that?
[23:45:53 CEST] <Cracki> I need to decode whole GOPs at a time, mostly.
[23:48:48 CEST] <debianuser> sikilikis: Have you checked ffmpeg CPU usage in `top` when that happens? Do you have xruns if you save to /dev/null instead of streaming it? Also, do you have xruns if you capture with `arecord` instead of `ffmpeg`?
[23:50:58 CEST] <sikilikis> ffmpeg uses between like 100% and 130% (4 cores)
[23:51:40 CEST] <sikilikis> haven't tried saving to /dev/null nor arecord. this is streaming live so im hesitant to just take it down
[23:52:52 CEST] <kepstin> sikilikis: it is probably limited by the speed of a single core on your system :/
[23:53:02 CEST] <Cracki> grml I remember asking this question before. someone pointed me to vlc's huge wrapper script that looks manually maintained.
[23:53:11 CEST] <Cracki> I'll just ust ctypes then...
[23:53:21 CEST] <sikilikis> it seems to be using each core fairly equally
[23:53:26 CEST] <sikilikis> each one is around 20-40%
[23:55:09 CEST] <sikilikis> maybe I should just try overclocking it a bit
[23:55:26 CEST] <sikilikis> though its using the hardware encoder
[00:00:00 CEST] --- Wed May 17 2017