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

[burek]

[00:14:50 CET] <xtina> i'm trying to find a way to record AND encode audio in 1 step, so don't have to pass it between commands?
[00:17:47 CET] <thebombzen_> xtina: that definitely sounds fishy
[00:18:11 CET] <xtina> thebombzen_: which part sounds fishy?
[00:19:22 CET] <thebombzen_> teh fact that you're claiming ffmepg can't process your audio fast enough but video is fine
[00:19:29 CET] <thebombzen_> the amount of data for audio is significantly lower than for video
[00:20:25 CET] <xtina> thebombzen_: but i'm passing ffmpeg encoded video and raw audio
[00:20:31 CET] <xtina> i'm generating like 20MB of raw audio a minute
[00:20:58 CET] <xtina> if not more
[00:21:39 CET] <kepstin> xtina: you could do something like have one ffmpeg do the audio capture and audio encoding, then pipe into another ffmpeg that just does muxing
[00:21:43 CET] <furq> yeah 32-bit stereo pcm is probably going to be bigger than a 720p webcam h264 stream
[00:21:47 CET] <kepstin> no idea if that would work for you
[00:22:01 CET] <furq> i have no idea why the fifo would keep growing though
[00:22:12 CET] <xtina> furq: i think the FIFO must be growing because ffmpeg isn't taking it
[00:22:28 CET] <xtina> my raw audio FIFO is 100's of MBs after a minute or two, while video FIFO is 0 bytes
[00:22:39 CET] <xtina> oh right.. ffmpeg itself can capture + encode
[00:22:48 CET] <xtina> kepstin: your idea sounds feasible. i might try that
[00:23:06 CET] <kepstin> i'm still wondering if there might be an audio/video speed mismatch - since ffmpeg will try to keep the a/v in sync, so if the video framerate is wrong it could read audio slower than realtime
[00:23:17 CET] <furq> that cpu shouldn't have any issue encoding aac in realtime
[00:23:59 CET] <furq> my pi 2 is clocked at 1ghz and aac runs at 3x
[00:24:12 CET] <furq> and nothing else in your command should be hitting the cpu
[00:24:32 CET] <xtina> furq:
[00:24:55 CET] <xtina> hmm, i don't know....
[00:25:11 CET] <xtina> kepstin: how might i diagnose an a/v mismatch?
[00:25:31 CET] <furq> i take it you've given up on trying to capture with ffmpeg instead of piping into it
[00:25:37 CET] <xtina> yes i gave up
[00:25:54 CET] <xtina> i mean
[00:26:00 CET] <xtina> the following cmd causes buffer overruns just by itself:
[00:26:42 CET] <xtina> http://pastebin.com/mA5qsasV
[00:26:52 CET] <xtina> (single line cmd - arecord to LAME)
[00:27:00 CET] <xtina> no ffmpeg
[00:27:13 CET] <xtina> my system is unable to take raw audio from arecord, pass it to LAME, and encode it in realtime
[00:27:51 CET] <furq> can it encode aac in realtime
[00:28:25 CET] <xtina> furq: i can try a alsa aac audio-only ffmpeg command
[00:35:38 CET] <xtina> no overrun problems with alsa aac-only ffmpeg command! now let me try piping THAT into my streaming ffmpeg cmd...
[01:06:45 CET] <xtina> hmm, how can i make ffmpeg write to a named pipe?
[01:08:46 CET] <xtina> the following doesn't work..
[01:08:46 CET] <xtina> ffmpeg -loglevel debug -f alsa -acodec pcm_s32le -i mic_sv -acodec aac pipe:1 > /tmp/temp_audio.m4a
[01:24:56 CET] <xtina> what is the correct format (-f) for a m4a output?
[01:27:47 CET] <xtina> i'm trying to find the write format for aac encoded audio output
[01:27:49 CET] <xtina> right*
[01:27:53 CET] <xtina> mp4 is wrong..
[01:28:08 CET] <furq> mp4 and m4a are the same
[01:28:19 CET] <xtina> ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -acodec aac -f ??? pipe:1 > /tmp/temp_audio.m4a
[01:28:24 CET] <xtina> what's the ??? supposed to be?
[01:28:32 CET] <llogan> probably "ipod"
[01:28:57 CET] <llogan> but piping mp4....
[01:29:01 CET] <llogan> *m4a
[01:29:22 CET] <xtina> er.. i'm not sure what format to pipe, but i want to pipe aac encoded audio to another FFMPEG command
[01:29:29 CET] <xtina> i'll try ipod
[01:30:17 CET] <furq> neither will work to a pipe
[01:30:21 CET] <furq> just use -f adts
[01:30:39 CET] <xtina> furq: thanks, so: ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -acodec aac -f adts pipe:1 > /tmp/temp_audio.m4a
[01:31:12 CET] <furq> or just -c:a aac /tmp/fifo.aac
[01:31:23 CET] <furq> you don't need to route it through a pipe
[01:31:31 CET] <furq> you'll need -y as well though
[01:33:05 CET] <xtina> furq: i don't want to write it to a file because then the file will grow as i keep streaming
[01:33:23 CET] <xtina> hence i want to pass the audio and video as named pipes
[01:33:58 CET] <xtina> 1. ffmpeg alsa -> named pipe -> ffmpeg muxing. 2. raspivid -> named pipe -> ffmpeg muxing
[01:35:04 CET] <xtina> oh sorry, i misunderstood you
[01:36:29 CET] <xtina> this is the error msg i get when i try your suggestion:
[01:36:30 CET] <xtina> [flv @ 0x1e63000] Malformed AAC bitstream detected: use the audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg)
[01:36:40 CET] <iive> xtina: try "nut"
[01:37:07 CET] <iive> mp4 is bad for piping as it needs to seek back to write some data
[01:37:29 CET] <furq> did you change the pipe name to end in .aac
[01:37:45 CET] <xtina> furq: yes i did
[01:37:50 CET] <xtina> codec aac -y /tmp/temp_audio.aac
[01:37:55 CET] <furq> weird
[01:37:59 CET] <xtina> whole thing: ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -acodec aac -y /tmp/temp_audio.aac
[01:38:07 CET] <furq> you shouldn't need that bsf for that
[01:38:31 CET] <xtina> hmmm
[01:38:40 CET] <xtina> iive: i can try NUT
[01:38:42 CET] <furq> add -f adts
[01:41:13 CET] <xtina> furq: same error
[01:41:14 CET] <xtina> ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -acodec aac -y -f adts /tmp/temp_audio.aac
[01:41:23 CET] <xtina> giving NUT a shot now
[01:41:33 CET] <furq> no idea what's going on there
[01:41:35 CET] <furq> that works fine for me
[01:41:51 CET] <xtina> huh, really..
[01:42:36 CET] <xtina> i did
[01:42:37 CET] <xtina> mkfifo /tmp/temp_audio.aac
[01:42:44 CET] <xtina> ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -acodec aac -y -f adts /tmp/temp_audio.aac
[01:42:54 CET] <xtina> and then i passed /tmp/temp_audio.aac as input to my muxing ffmpeg cmd
[01:43:07 CET] <furq> oh are you getting that message in the second ffmpeg
[01:43:35 CET] <xtina> furq: yep i am
[01:43:35 CET] <furq> that makes sense then
[01:43:49 CET] <furq> just add that bitstream filter
[01:43:55 CET] <furq> to the second ffmpeg
[01:44:48 CET] <furq> fwiw if you just want to test throughput you can just cat /tmp/temp_audio.aac > /dev/null
[01:52:43 CET] <xtina> furq: great news, that seemed to do the trick, no errors and the stream is up!
[01:53:01 CET] <xtina> however, my FPS is really low
[01:53:06 CET] <xtina> i'm wondering if it's because of the added filter
[01:53:13 CET] <xtina> (remember how i'm trying to do as little transformation/processing as possible)
[01:54:34 CET] <xtina> my CPU usage is super high (90%)
[01:54:44 CET] <xtina> (when I was doing arecord -> ffmpeg, CPU usage <20%)
[01:56:08 CET] <xtina> So, now ffmpeg is doing recording + encoding + filter (90% CPU), vs. previously arecord doing recording and passing to ffmpeg for encoding (low CPU)
[02:03:09 CET] <xtina> iive: i'm trying NUT now. working way better for some reason! high FPS and bitrate. but still, CPU usage is so high :(
[02:03:36 CET] <xtina> does ffmpeg alsa take more CPU than arecord alsa?
[02:06:17 CET] <xtina> (with NUT, i don't need that bitrate filter, so my 2nd ffmpeg cmd is only muxing, and the 1st is only recording and encoding)
[02:11:42 CET] <iive> is 90% on one core or all cores total?
[02:11:53 CET] <furq> it's a pi zero, it only has one core
[02:12:01 CET] <xtina> one core
[02:12:03 CET] <iive> oh, arm
[02:12:17 CET] <xtina> but still - what's the diff between arecord -> ffmpeg encoding and ffmpeg alsa?
[02:12:23 CET] <iive> it's mirracle it is 90% only :D
[02:12:27 CET] <xtina> doesn't make sense that my CPU usage has skyrocketed when i'm doing the same stuff?
[02:12:50 CET] <xtina> previously my CPU usage never went above 20%
[02:12:59 CET] <furq> when encoding to aac?
[02:13:05 CET] <iive> do you have `perf top` on your system?
[02:13:23 CET] <xtina> furq: previously i did arecord and passed WAV to ffmpeg, which encoded in aac
[02:13:43 CET] <xtina> i've replaced that with a ffmpeg cmd doing record and encoding in aac
[02:13:50 CET] <xtina> but yes, AAC encoding both times
[02:14:13 CET] <furq> weird
[02:14:32 CET] <iive> were you arecording with s32le ?
[02:14:39 CET] <xtina> yes, s32le both times
[02:15:09 CET] <iive> if the format is not native... and i doubt it is... then the conversion might be the cause
[02:15:50 CET] <xtina> iive: can you elaborate? which format is not native?
[02:16:45 CET] <xtina> (also if it makes a diff, i was previously recording arecord to WAV, then WAV -> aac encoding. now, pcm s32le -> aac)
[02:17:10 CET] <xtina> actually, hole on
[02:17:12 CET] <xtina> hold on
[02:17:25 CET] <xtina> i'm AAC encoding to a NUT file
[02:17:35 CET] <xtina> then passing NUT to my ffmpeg muxing command, following iive's suggestion
[02:17:47 CET] <xtina> this performs really really well, but is NUT the problem?
[02:18:13 CET] <xtina> ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -acodec aac -y -f nut /tmp/temp_audio.nut
[02:19:15 CET] <xtina> additionally - i just watched the stream, and the audio is incredibly stuttering
[02:19:26 CET] <xtina> which is the same thing i've experienced every time i tried ffmpeg -alsa :(
[02:19:43 CET] <xtina> https://www.youtube.com/watch?v=7lAWA8Qy-Jg
[02:20:13 CET] <xtina> never experienced this with arecord, but 100% of the time i try ffmpeg -alsa i get full audio stuttering..
[02:24:23 CET] <iive> one thing at a time
[02:24:47 CET] <iive> nut is probably not the problem, high cpu load might cause stutter
[02:25:02 CET] <xtina> sorry for the confusion, haha
[02:25:08 CET] <iive> most wav files are s16le
[02:25:32 CET] <iive> also, aac encoder is probably using floats.
[02:26:13 CET] <xtina> i see, iive
[02:26:22 CET] <xtina> hm, do you have any suggestions?
[02:26:50 CET] <xtina> i guess i want to reduce CPU first and then see if there is still stuttering
[02:26:51 CET] <iive> well, first try /dev/null as output
[02:27:03 CET] <relaxed_> and omit -acodec pcm_s32le
[02:27:13 CET] <iive> then try to skip the encoder
[02:27:22 CET] <iive> then ommit s32le
[02:27:39 CET] <iive> then try aac again.
[02:28:14 CET] <iive> btw... there was some recent option to make ffmpeg native aac encoder faster, as it is much slower than the other aac encoders
[02:28:47 CET] <xtina> i have always used ffmpeg's aac encoder though, even when my CPU usage was at 20%
[02:28:53 CET] <xtina> so the aac encoding is not the proble
[02:29:12 CET] <iive> well, `perf top` might give us more clues
[02:29:17 CET] <iive> if it works on arm
[02:29:43 CET] <iive> `perf` is tool that comes with kernel source.
[02:29:53 CET] <xtina> perf is not recognized by my system
[02:30:23 CET] <iive> apt-get install perf ?
[02:30:24 CET] <xtina> i can install
[02:30:26 CET] <llogan> iive: perhaps "-aac_coder fast"
[02:31:57 CET] <xtina> i still don't know how aac encoding can be the issue because i have always used aac encoding. i'm installing perf now, i'll let you know what i get
[02:32:28 CET] <iive> llogan: perhaps...
[02:33:00 CET] <iive> sorry gtg
[02:33:11 CET] <xtina> iive: thanks for all of the help, i appreciate it
[02:33:14 CET] <xtina> hopefully i will figure it out :)
[02:33:28 CET] <iive> try to just capture raw pcm and see if cpu is still high
[02:33:39 CET] <xtina> OK, will do
[02:33:44 CET] <xtina> thanks again
[02:42:55 CET] <xtina> i'm trying to go from basics
[02:43:01 CET] <xtina> and just write raw PCM
[02:43:09 CET] <xtina> ffmpeg -i mic_sv -f s32le -acodec pcm_s32le output.raw
[02:43:12 CET] <xtina> this command exits immediately
[02:43:30 CET] <xtina> is something wrong with it?
[02:45:43 CET] <relaxed_> ffmpeg -f alsa -i mic_sv -f s16le out.pcm
[02:46:27 CET] <xtina> relaxed_: https://trac.ffmpeg.org/wiki/audio%20types
[02:46:32 CET] <xtina> i took the last command from that page
[02:46:38 CET] <xtina> and it exits immediately...
[02:47:29 CET] <xtina> the one u suggested also gives an error:
[02:47:29 CET] <xtina> [alsa @ 0x2750400] cannot set sample format 0x10000 2 (Invalid argument)
[02:47:46 CET] <xtina> (ffmpeg -f alsa -i mic_sv -f s32le out.pcm)
[02:48:38 CET] <relaxed_> run my command and pastebin your console output if it fails
[02:49:11 CET] <xtina> sure: http://pastebin.com/4iuSg4gt
[02:51:03 CET] <relaxed_> try, ffmpeg -f alsa -channels 1 -i mic_sv -f s16le out.pcm
[02:51:35 CET] <xtina> this gives me the same error
[02:51:48 CET] <xtina> (if it matters my mic is s32le)
[02:52:15 CET] <relaxed_> you captured from your mic using ffmpeg before?
[02:52:18 CET] <xtina> (this is my original cmd, which works /home/pi/special/ffmpeg/ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -acodec aac test.m4v)
[02:52:24 CET] <xtina> no problem with my ffmpeg/alsa
[02:53:20 CET] <relaxed_> then add -acodec pcm_s32le before the -i
[02:54:15 CET] <xtina> you're right, this does work:
[02:54:16 CET] <xtina> ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -f s16le out.pcm
[02:54:20 CET] <xtina> but 95% of my CPU??
[02:55:26 CET] <xtina> just recording s32le and converting to 16bit uses up my entire CPU.. how is that possible
[02:56:03 CET] <xtina> meanwhile, if i record s32le and convert to 16bit WAV with arecord, it uses 5% CPU:
[02:56:10 CET] <xtina> arecord -Dmic_sv -c2 -r48000 -fS32_LE -twav /tmp/temp_audio.v &
[02:57:39 CET] <relaxed_> what about? ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -c copy out.wav
[02:58:51 CET] <xtina> this still uses 95% of my CPU...
[02:59:04 CET] <xtina> here's my full console output:
[02:59:12 CET] <xtina> http://pastebin.com/LLJCSung
[03:00:16 CET] <xtina> thanks for looking into this with me, btw
[03:00:54 CET] <xtina> this is also 95% of CPU: ffmpeg -f alsa -acodec pcm_s32le -i mic_sv out.wav
[03:01:28 CET] <xtina> this is 5% CPU: arecord -Dmic_sv -c2 -r48000 -fS32_LE -twav /tmp/temp_audio.v &
[03:01:30 CET] <xtina> this MUST be a bug..??
[03:02:49 CET] <xtina> FWIW, that arecord command above "overruns"
[03:05:11 CET] <relaxed_> xtina: https://www.raspberrypi.org/forums/viewtopic.php?t=43738&p=348942
[03:05:24 CET] <xtina> yes, i've read that thread over and over :(
[03:05:47 CET] <xtina> no proposed solutions worked for me
[03:06:01 CET] <relaxed_> hah, you tried xfs?
[03:06:08 CET] <xtina> i am using /tmp so fully from memory
[03:06:24 CET] <xtina> i still feel like this is a ffmpeg bug
[03:06:30 CET] <xtina> how can this take 5% CPU: arecord -Dmic_sv -c2 -fS32_LE -twav test.wav
[03:06:42 CET] <relaxed_> you're probably right
[03:06:44 CET] <xtina> and this takes 95% CPU: ffmpeg -f alsa -acodec pcm_s32le -i mic_sv out.wav
[03:06:48 CET] <xtina> it's literally the same command
[03:07:06 CET] <xtina> been fighting ffmpeg for 3 weeks
[03:07:09 CET] <xtina> *headdesk*
[03:07:26 CET] <xtina> furq: do you think this is a bug?
[03:09:01 CET] <xtina> i added -ac 2 to ffmpeg, so now it is the *exact* same command in arecord/ffpeg
[03:09:14 CET] <xtina> using ffmpeg for audio recording+encoding was my last hope.
[03:09:33 CET] <debianuser> xtina: Does writing nowhere consumes 95% CPU too? `ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -f null -`
[03:10:10 CET] <xtina> debianuser: yes, this is 95%
[03:10:58 CET] <llogan> not that it matters, but you don't need "--enable-nonfree" since you didn't enable any nonfree stuff
[03:11:16 CET] <xtina> llogan: i see
[03:11:30 CET] <xtina> did i build ffmpeg + alsa wrong or something?
[03:11:46 CET] <xtina> is there a different library I can use to do both audio capture + aac encoding?
[03:12:20 CET] <xtina> is this hogging tons of CPU for other people?
[03:12:21 CET] <xtina> ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -f null -
[03:13:02 CET] <llogan> i don't have mic_sv
[03:13:15 CET] Action: debianuser guesses that ffmpeg could be selecting incorrect buffer size, or at least different from arecord, but has no idea how to make ffmpeg print its buffer size...
[03:18:28 CET] <xtina> debianuser: this is the debug report... if it helps... http://pastebin.com/Xsw1dBAR
[03:25:06 CET] <xtina> any thoughts?
[03:26:41 CET] <debianuser> xtina: there's a complex way to build our own small hook and inject it into alsa chain... If you want we can try that. Do you have compiler and alsa-dev headers installed there?
[03:27:30 CET] <xtina> debianuser: i would love to try anything :)
[03:28:54 CET] <xtina> i have ffmpeg compiled with these instructions: http://vpaste.net/cXV9F
[03:28:58 CET] <xtina> is that what you mean?
[03:34:01 CET] <debianuser> xtina: Create some empty dir, http://pastebin.com/3cj2PfPu -- save this as libalsadumphook.c, build it: `gcc -shared -fPIC -DPIC -O3 -s -o libalsadumphook.so libalsadumphook.c -lasound`, http://pastebin.com/Vw0qghDW -- save this as dumpasoundrc, then copy output of `ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:./dumpasoundrc ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -f null -` to some pastebin.
[03:34:19 CET] <n1cky> apologies if this is offtopic. I want to digitize my parent's home videos. Has anyone done this? Looking for something supported by v4l or libuvc, retaining quality is my biggest concern.
[03:34:54 CET] <debianuser> xtina: Ah, don't forget to edit "dumpasoundrc" file - replace /FULL/PATH/TO/libalsadumphook.so there with actual full path to the libalsadumphook.so you built.
[03:35:25 CET] <xtina> debianuser: oh thanks so much - trying now
[03:36:13 CET] <llogan> n1cky: old tapes?
[03:37:05 CET] <n1cky> llogan: yeah, home videos of the 90's, completely analog
[03:38:54 CET] <debianuser> xtina: ah, sorry, the command should be `ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:./dumpasoundrc ffmpeg -f alsa -acodec pcm_s32le -i michooks -f null -` I mean you need to record from "michooks" pcm to load the hooks. :)
[03:39:06 CET] <llogan> n1cky: you'll need some digitizing hardware to accept the s-video or composite video cables and audio and to computer via firewire, usb, etc. do you already have this?
[03:39:43 CET] <kepstin> n1cky: the good news is that if they're vhs tapes, it's really hard to screw up the capture enough that they look any worse ;)
[03:40:08 CET] <n1cky> llogan: No, that's what I'm looking to purchase. I came across the STK1160, you can buy them for $9 on Amazon, but looking at youtube the quality looks awful
[03:40:21 CET] <n1cky> then again I don't know how much i trust the average Call of Duty 4 player to properly encode their stuff.
[03:40:24 CET] <llogan> what's your budget?
[03:40:48 CET] <llogan> win/lin/macos?
[03:41:04 CET] <n1cky> llogan: i mean within reason, but home videos are more or less priceless. Don't care about cost so much.
[03:41:18 CET] <n1cky> llogan: linux-- v4l support (or libuvc) is a bonus
[03:41:31 CET] <n1cky> i'll use windows if necessary though
[03:41:42 CET] <llogan> oh, i already forgot you mentioned v4l2 before...
[03:42:41 CET] <xtina> debianuser: thank again, i am getting an error with alsadumphook: http://pastebin.com/gfvzgyFG
[03:43:40 CET] <kepstin> I'd expect the STK1160 devices would probably be fine for SD analog capture, a "name brand" tv signal decoder might get slightly better results, but it would be hard to tell, especially for VHS source.
[03:44:27 CET] <kepstin> looks like that'll get you raw video, so you can process it in software as you like for deinterlacing, etc.
[03:45:58 CET] <llogan> i just used an old canopus advc110 for some VHS because it was already in the office. it outputs DV...no lossless output but honestly with such a shitty input nobody could tell.
[03:46:38 CET] <kepstin> if you can find a capture card with s-video input you can avoid some types of artifacts... but again, with a vhs source... :/
[03:46:46 CET] <llogan> the digital archive geeks have a few docs that may be interesting regarding the capture hardware:
[03:46:48 CET] <llogan> https://docs.google.com/document/d/1oJvr8zCMK4
[03:46:56 CET] <llogan> https://docs.google.com/document/d/12aZv3QDCcQSkVmHjmwAgywOgDeV41bt8kAlBhiQ6XZo/
[03:47:33 CET] <debianuser> xtina: Ah, oops, I was wrong. The "install" option is a function name, not library name. Replace "install alsadumphook" with "install my_hooks_install_func" in the "dumpasoundrc" file.
[03:47:38 CET] <n1cky> llogan: that's a great link, thank you!
[03:47:52 CET] <llogan> once you decide on hardware we can provide some example ffmpeg commands to deinterlace and denoise, etc
[03:49:14 CET] <xtina> sorry for being dense.. literally "install my_hooks_install_func"?
[03:49:42 CET] <xtina> or do i replace my_hooks_install_func with something?
[03:50:35 CET] <debianuser> xtina: literally "install my_hooks_install_func", that's the name of the function in http://pastebin.com/3cj2PfPu :) Well, you can rename it in the source if you want.
[03:50:38 CET] <llogan> n1cky: ff then rewind tapes before recording. look out for mold in tapes. clean the heads in the player before starting.
[03:51:14 CET] <llogan> (the mold can infect other tapes after playing it)
[03:52:35 CET] <xtina> debianuser: all right, i did change it to '  install my_hooks_install_func', but i still get ALSA lib dlmisc.c:142:(snd_dlsym_verify) unable to verify version for symbol _snd_pcm_hook_alsadumphook_install ALSA lib pcm_hooks.c:436:(snd_pcm_hook_add_conf) symbol _snd_pcm_hook_alsadumphook_install is not defined inside [builtin]
[03:53:25 CET] <llogan> n1cky: and find a backup VHS deck. sometimes if a tape doesn't play in one will be better in the other. preferrably one that doesn't have an annoying tracking OSD that will get recorded.
[03:54:49 CET] <n1cky> llogan: this is great information to know about-- i hadn't even thought about something like mold
[03:54:58 CET] <n1cky> they've been kept in a basement so i wouldn't rule it out
[03:55:14 CET] <llogan> my last batch had it
[03:55:55 CET] <debianuser> xtina: can you copy your current "dumpasoundrc" file to some pastebin?
[03:57:14 CET] <xtina> debianuser: http://pastebin.com/LkiYPsfA
[03:57:34 CET] <xtina> that is ./dumpasoundrc
[03:58:02 CET] <xtina> here is my .asoundrc: http://pastebin.com/hf6EiyEM
[04:06:03 CET] <debianuser> xtina: Ah, right, one more fix. Replace "pcm_hook_type.my_debug_hook" with "pcm_hook_type.alsadumphook"
[04:08:45 CET] <xtina> debianuser: great, no more errors. still 95% CPU usage. here is the full console output: http://pastebin.com/hm6tpG2w
[04:14:29 CET] <debianuser> xtina: Ok. period_size : 512, buffer_size : 65536. That's what I was looking for. Now let's compare that to the arecord. Can you also copy the output of `arecord -v -Dmic_sv -c2 -fS32_LE -twav /dev/null` to a pastebin? (arecord can print its capture chain with "-v" option, we don't need hooks for it)
[04:15:40 CET] <xtina> debianuser: yea, here it is! http://pastebin.com/bbJH2JTP buffer_size  : 4000   period_size  : 1000   period_time  : 125000
[04:15:57 CET] <xtina> wow, very small buffer from arecord....
[04:17:28 CET] <debianuser> Ah, `rate : 8000`, we forgot to set the rate. Try: `arecord -v -r48000 -c2 -fS32_LE -Dmic_sv -twav /dev/null`
[04:18:41 CET] <xtina> oh, right you are :) http://pastebin.com/hMgU5xrk buffer_size  : 24000   period_size  : 6000   period_time  : 125000
[04:19:31 CET] <debianuser> How much cpu does `arecord -v -r48000 -c2 -fS32_LE -Dmic_sv -twav /dev/null`  use by the way? Is it still 5% CPU?
[04:20:02 CET] <xtina> not even - 3%!
[04:20:22 CET] <xtina> ffmpeg still at 95%
[04:20:44 CET] <xtina> the settings are quite different - period size is a lot higher from arecord than ffmpeg..
[04:22:38 CET] <debianuser> xtina: I don't know how to change buffer size for ffmpeg... But we can try it the other way around - set the same sizes for arecord and see if it goes 95% after that. Try this: `arecord -v -r48000 -c2 -fS32_LE --period-size=512 --buffer-size=65536 -Dmic_sv -twav /dev/null`, check how much cpu it uses, and copy its output to a pastebin.
[04:23:22 CET] <xtina> sounds reasonable. aha, that makes arecord go to 95%!!
[04:23:45 CET] <xtina> hmm, it looks like we need to change buffer size and period size for ffmpeg!
[04:24:08 CET] <xtina> here's the pastebin:http://pastebin.com/rJ1Niwmh
[04:25:25 CET] <xtina> this is very illuminating
[04:25:35 CET] <xtina> now i'm trying to find how to set buffer/period size in ffmpeg..
[04:26:24 CET] <debianuser> xtina: Yeah, same settings as in ffmpeg hooks dump. Looks like your driver doesn't like small periods. But I have no idea how to set period/buffer size for ffmpeg. :(
[04:26:28 CET] <xtina> debianuser: i wonder if i can set it inside ./dumpasoundrc?
[04:26:55 CET] <debianuser> xtina: no, that's just a hook, to print current settings, it doesn't affect the settings, just prints those...
[04:27:07 CET] <xtina> oh... :(
[04:27:23 CET] <xtina> a quick google search of ffmpeg period size turns up nothing at all..
[04:27:32 CET] <xtina> must be set/read from somewhere that i can change...
[04:27:50 CET] <xtina> anyone in here happen to know how we can change ffmpeg period and buffer size?
[04:28:07 CET] <debianuser> well, we're in #ffmpeg channel, the smartest ffmpeg people are here! maybe someone knows how to do that.
[04:29:27 CET] <xtina> hmm wait, i define mic_sv in .asoundrc, and ffmpeg reads from there to recognize it.. maybe i can put buffer/period size in there too?
[04:32:37 CET] <debianuser> Hm... We can try... In your "pcm.mic_hw" definition add two lines:
[04:32:40 CET] <debianuser>   period_time 125000
[04:32:41 CET] <debianuser>   buffer_time 500000
[04:33:25 CET] <debianuser> (that would probably not work, but try it just in case)
[04:34:56 CET] <debianuser> xtina: you can test it with command `arecord -v -r48000 -c2 -fS32_LE -Dmic_sv -twav /dev/null`. If it fails it'd print some config error
[04:35:26 CET] <xtina> debianuser: yea, those args are not being recognized, but let me keep experimenting with this for a few..
[04:35:28 CET] <xtina> it seems possible
[04:37:30 CET] <xtina> i think i need to use something called 'dmixer'..
[04:40:15 CET] <debianuser> xtina: Try adding those to a slave. For example add them to "pcm.mic_sv" definition like this:
[04:40:17 CET] <debianuser>   slave.period_time 125000
[04:40:19 CET] <debianuser>   slave.buffer_time 500000
[04:41:18 CET] <xtina> mm no luck with that
[04:42:19 CET] <debianuser> What does `arecord -v -r48000 -c2 -fS32_LE -Dmic_sv -twav /dev/null` say if you add those lines?
[04:42:40 CET] <xtina> (whole .asoundrc: http://pastebin.com/50avehKR)
[04:42:48 CET] <xtina> ALSA lib pcm.c:6973:(snd_pcm_slave_conf) Unknown field period_time
[04:43:02 CET] <xtina> reading docs here: http://www.sabi.co.uk/Cfg/ALSA/asound.conf
[04:43:05 CET] <xtina> period_time is a legit field
[04:45:30 CET] <JeffATL> i know ffmpeg has a filter for this but anyone know if it's possible to make a conexant capture card output video in grayscale?
[04:48:35 CET] <debianuser> xtina: Yes. But it's probably only legit for dmix/dsnoop. And you can't use those if your hardware doesn't support MMAP mode (and it probably doesn't if you had to add "type mmap_emul" into the chain). :( We can check that. Copy the output of `arecord --dump-hw-params -Dhw:memsmic /dev/zero` to some pastebin
[04:49:15 CET] <xtina> debianuser: here it is http://pastebin.com/Phej9rmx
[04:49:51 CET] <xtina> looking at it.. seems like it doesn't..?
[04:56:34 CET] <debianuser> yeah, "ACCESS: RW_INTERLEAVED". If it supported mmap it'd look like "ACCESS: RW_INTERLEAVED MMAP_INTERLEAVED"
[04:57:49 CET] <xtina> oh no...
[04:58:59 CET] <debianuser> xtina: you said you built ffmpeg yourself, right?
[04:59:54 CET] <xtina> correct
[05:00:10 CET] <xtina> i did this: http://vpaste.net/cXV9F but without the aac lib
[05:00:35 CET] <debianuser> xtina: do you still have that directory where you've built it?
[05:02:42 CET] <xtina> debianuser: sure, i think so
[05:03:07 CET] <xtina> i have everything in my dir, '/home/pi/special/ffmpeg'
[05:09:59 CET] <debianuser> xtina: Let's check a small hack. Go to ffmpeg clone dir, edit "libavdevice/alsa.c" file, find line "if (!period_size)" there and replace it with "//if (!period_size)" (adding two slashes "//" would comment it out), then still in ffmpeg dir run `make -j2 ` and `make install` (skip the previous steps like "configure", it'll automatically rebuild only those files that changed, that'd save some time).
[05:13:31 CET] <xtina> debianuser_ trying now. thanks for the patience and help, really grateful
[05:14:26 CET] Action: debianuser doesn't really like instructions suggesting "make install" step, it's always better to build a packate or at least copy required files manually to e.g. ~/bin, but since you've done that anyway doing it again won't make it worse.
[05:14:43 CET] <xtina> yea, fair enough..
[05:20:17 CET] <xtina> debianuser: make -j2 is slow. i'll let you know when done
[05:31:30 CET] <xtina> debianuser: i finished recompiling after commenting out that 1 line
[05:32:42 CET] <debianuser> xtina: Try `ffmpeg -f alsa -acodec pcm_s32le -i michooks -f null -`  how much cpu it uses now?
[05:35:32 CET] <xtina> debianuser: it is still 95% CPU
[05:35:35 CET] <debianuser> :(
[05:35:52 CET] <xtina> also get a strange error i haven't seen before: [null @ 0x343b730] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 154945 >= 154518
[05:36:08 CET] <xtina> http://pastebin.com/A2hghNuX
[05:36:22 CET] <xtina> these were my arecord stats: buffer_size  : 4000    period_size  : 1000    period_time  : 125000
[05:36:42 CET] <xtina> my period size in the ffmpeg output is 16K
[05:36:46 CET] <xtina> it's too big, isn't it?
[05:37:08 CET] <xtina> shouldn't i be trying to set the ffmpeg buffer/period size identical to arecord's?
[05:38:16 CET] <debianuser> Hm... Does arecord with those params take 95% CPU too? Try: `arecord -v -r48000 -c2 -fS32_LE --period-size=16384 --buffer-size=65536 -Dmic_sv -twav /dev/null`
[05:38:43 CET] <dysfigured> i have a file transcoding on another computer, when it's done i'm gonna rsync it back to this computer, but i'm wondering if i can have it send over the network while it's transcoding? something like `ssh user at host 'ffmpeg -y -i myfile.mkv -vcodec libx264 -acodec copy -' | ffmpeg -i - myfile.avi`  ?
[05:38:56 CET] <xtina> debianuser: no that uses like 0%
[05:39:53 CET] <xtina> i'm trying to keep track. now we know with arecord, period_size of 512 is 95% CPU. period size of 16K is 5% CPU
[05:40:24 CET] <debianuser> xtina: Can you also copy the output of `arecord -v -r48000 -c2 -fS32_LE --period-size=16384 --buffer-size=65536 -Dmic_sv -twav /dev/null` to a pastebin?
[05:41:08 CET] <xtina> here it is: http://pastebin.com/gqhSkTWL
[05:41:55 CET] <xtina> and here is the pastebin for the ffmpeg command: http://pastebin.com/RBQDeeVw
[05:42:09 CET] <xtina> i will try to compare them...
[05:43:29 CET] <xtina> i see 0 differences..
[05:44:30 CET] <debianuser> They look same... :( Are you sure that `arecord -v -r48000 -c2 -fS32_LE --period-size=16384 --buffer-size=65536 -Dmic_sv -twav /dev/null` uses 0% while `ALSA_CONFIG_PATH=/usr/share/alsa/alsa.conf:./dumpasoundrc  /home/pi/special/ffmpeg/ffmpeg -f alsa -acodec pcm_s32le -i michooks -f  null -` uses 95% CPU? Can you check them both again just in case?
[05:46:14 CET] <xtina> debianuser: i'm sure. i just pasted both of those commands into my terminal, ran them and watched TOP for 15 seconds.
[05:46:18 CET] <xtina> arecord is at 5%, ffmpeg is at 95%.
[05:46:24 CET] <xtina> @_@
[05:47:48 CET] <xtina> is there something different about the way ffmpeg and arecord convert 32bit to 16bit?
[05:48:37 CET] <xtina> the PCM configs in stdout are the same but arecord doesn't print out the stream conversion info, and ffmpeg does..
[05:50:14 CET] <xtina> i don't really know what all this stuff is.. Duration: N/A, start: 1487306487.586316
[05:50:18 CET] <xtina> (from ffmpeg)
[05:55:52 CET] <xtina> ffmpeg alsa works for other people, clearly... what is different about my setup? my mic_sv device is only a volume boosted regular mic
[05:56:24 CET] <xtina> admittedly i'm on a zero and that's unusual for audio processing..
[05:56:37 CET] <xtina> but then arecord handles it fine
[05:57:16 CET] <debianuser> Does recording directly from hardware make any difference? Try `ffmpeg -f alsa -acodec pcm_s32le -i hw:memsmic -f  null -`  does it still use 95% CPU?
[05:58:09 CET] <xtina> debianuser: still does
[05:58:24 CET] <xtina> i've also started getting this new error since recompiling: [null @ 0x27d5440] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 340036 >= 340036
[05:58:30 CET] <debianuser> then it's not because of volume boosting...
[05:58:32 CET] <xtina> so i dont know if my ffmpeg is a bit borked, hmm
[05:59:18 CET] <debianuser> That's just a warning, should not be a problem, I hope...
[05:59:36 CET] <xtina> i've never seen it until i recompiled ffmpeg
[05:59:55 CET] <xtina> but, ok
[06:00:11 CET] <xtina> anyway, this uses 95% /home/pi/special/ffmpeg/ffmpeg -f alsa -acodec pcm_s32le -i hw:memsmic -f null -
[06:00:25 CET] <xtina> any thoughts about 32bit -> 16bit conversion in ffmpeg vs. arecord?
[06:00:35 CET] <xtina> or any other differences you can think of?
[06:02:08 CET] <xtina> has anyone else compared arecord and ffmpeg alsa CPU usage? i've read threads online that are a bit similar: http://raspberrypi.stackexchange.com/questions/1466/live-audio-stream-using-ffmpeg
[06:03:29 CET] <debianuser> Don't know... And I'm not sure how ffmpeg waits for alsa input. Arecord uses snd_pcm_wait(), but there's no such function in ffmpeg sources, so... what does ffmpeg do when there's no audio input yet?
[06:04:32 CET] <debianuser> (xtina: on my PC both ffmpeg and arecord use ~0% cpu when capturing alsa to "null", but it's definitely more powerful than rpi)
[06:05:25 CET] <xtina> OTOH, i wanted to use arecord -> LAME encoding -> ffmpeg since arecord works so well
[06:05:31 CET] <xtina> but if I use arecord, i just can't avoid those overrun errors
[06:05:47 CET] <xtina> no command (Lame or ffmpeg) seems to be able to take arecord raw audio quickly enough
[06:06:08 CET] <xtina> it looks like i need a single cmd for record + encoding, and the only one i know is ffmpeg, if not for these problems
[06:07:48 CET] <xtina> debianuser: maybe i will wait a bit, perhaps someone else in the room knows the fine intricacies of ffmpeg/arecord alsa processing?
[06:07:57 CET] <debianuser> xtina: That's certainly a bug somewhere either in ffmpeg, or in your driver, or both. I'm just not sure where it is. I can help debugging alsa side, but I need help with ffmpeg side, I don't know ffmpeg sources good enough. :(
[06:08:19 CET] <xtina> debianuser: why would there be a bug in my driver, if my driver works fine for arecord?
[06:08:30 CET] <xtina> and no problem, you have been a huge huge help
[06:08:38 CET] <xtina> :o)
[06:08:43 CET] <xtina> just hope we can find this bug...
[06:08:52 CET] <xtina> otherwise i might have to give up the project
[06:11:59 CET] <debianuser> (Actually it has problems with arecord too, since it goes 95% CPU when used with a smaller buffer - that should not happen, but that may be a different/unrelated bug, not sure... I need to know what ffmpeg does when there's no data, what does it do when read_packet() returns AVERROR(EAGAIN).
[06:13:28 CET] <xtina> oh yea, arecord went to 95% with a small buffer.. but if there is a setting that works for arecord, ffmpeg should be capable o fit too..
[06:18:48 CET] <xtina> debianuser: hmm.. should i file a bug report?
[06:19:00 CET] <debianuser> xtina: That'd be stupid workaround, but can you also check cpu usage of: `ffmpeg -re -f alsa -acodec pcm_s32le -i michooks -f  null -` (added -re option)?
[06:20:09 CET] <xtina> debianuser: OMG that drops it to 5-10%....
[06:20:11 CET] <xtina> ???
[06:20:29 CET] <xtina> i thought that was the wrong way to use -re
[06:20:36 CET] <debianuser> It is the wrong way
[06:20:47 CET] <xtina> does it work..?
[06:20:52 CET] <xtina> why would this cause CPU to plummet?
[06:21:32 CET] <xtina> it isn't quite as low as arecord's 5%, but it's <10%
[06:22:25 CET] <debianuser> It still means there's some bug in ffmpeg, or alsa, or your driver, which doesn't properly wait for data. The "-re" option is just a workaround, that inserts artificial sleeps into ffmpeg forcing it to wait before asking for more data.
[06:28:29 CET] <xtina> debianuser: is that a legitimate runaround? when i use that in my workflow, i get alsa buffer xruns and like 1kbps audio bitrate
[06:29:53 CET] <debianuser> Yes, you may have xruns because of "-re" option, but at least you won't have 95% CPU usage.
[06:30:22 CET] <debianuser> (it is a stupid workaround, yes, but it's something you can use while we're looking for a better option)
[06:31:54 CET] <xtina> '[alsa @ 0x2ab7460] ALSA buffer xrun.rate=   0.3kbits/s speed=   1x    '
[06:32:21 CET] <xtina> i indeed have <5% CPU
[06:32:36 CET] <xtina> i've streamed 3KB of audio so far, lol
[06:32:42 CET] <xtina> after a minute
[06:33:12 CET] <xtina> cmd: http://pastebin.com/bMLe3QxH
[06:34:28 CET] <xtina> debianuser: no joy with the audio. almost nothing is coming through (there should be sound here): example stream https://www.youtube.com/watch?v=QrVqnm2pAk8
[06:34:37 CET] <xtina> consistent with the 3kb audio sent haha
[06:36:12 CET] <debianuser> xtina: it seems you're sending silence...
[06:36:42 CET] <xtina> i'm not, i had music on. the ffmpeg alsa command was reporting a rate of 0.3kb/s
[06:36:57 CET] <xtina> console output: http://pastebin.com/Paka0F5w
[06:37:15 CET] <debianuser> xtina: Does recording to a file work? Run `ffmpeg -re -f alsa -acodec pcm_s32le -i mic_sv test.wav`  for some time, then stop it and play test.wav - is there a sound?
[06:39:13 CET] <xtina> debianuser: no, that doesn't work
[06:39:24 CET] <xtina> i recorded for 15s and it generated a 14kb file with one loud click in it
[06:40:00 CET] <xtina> there were like 15 xrun errors
[06:40:02 CET] <xtina> one every second
[06:41:42 CET] <xtina> this works perfectly /usr/bin/arecord -Dmic_sv -c2 -r48000 -fS32_LE -twav test.wav
[06:42:28 CET] <xtina> console output of alsa to .wav: http://pastebin.com/mUwQkTQp
[06:49:05 CET] <xtina> let me make sure i understand the issue.. ffmpeg seems to have an issue waiting for alsa packets, doing it differently from arecord, but we aren't sure where the code is
[06:49:07 CET] <xtina> is that right?
[06:51:13 CET] <debianuser> Yes. Ffmpeg has issues waiting for alsa packets in default mode, and has (different) issues waiting for them in "realtime" mode (-re option). I wonder why...
[06:52:16 CET] <xtina> debianuser: thanks. it's nice to pinpoint the issue, at least
[06:52:26 CET] <pinPoint> hey
[06:52:34 CET] <xtina> it looks like the -re option isn't feasible =/
[06:52:42 CET] <xtina> hmmmm.... should i file a bug report?
[06:53:10 CET] <xtina> i'm not sure who will be able to reproduce, if it doesn't show up on more powerful computers. i know very few ppl have audio input for their Zeros
[06:53:12 CET] <debianuser> xtina: One more stupid check. Can you copy to the pastebin the output of this command:    for i in `seq -w 100`; do time sleep .$i; done
[06:53:29 CET] <xtina> i like these stupid checks :)
[06:53:52 CET] <xtina> yea, one sec. i turned off my Zero, it was getting really hot
[06:55:33 CET] <debianuser> (I thought maybe your timer/sleep functions are weird and sleep for some random time. It's not a good check, as I don't really know what ffmpeg uses, but that's at least something to try...)
[06:55:41 CET] <xtina> debianuser: http://pastebin.com/FG60uzfU
[06:55:52 CET] <xtina> yea, i see your point
[06:57:22 CET] <debianuser> (expected output: http://pastebin.com/psCVJymW )
[06:57:46 CET] <xtina> errr
[06:57:47 CET] <xtina> whoa
[06:58:03 CET] <xtina> doesn't look right....
[06:58:36 CET] <xtina> what does this mean..?
[06:58:59 CET] <xtina> is something wrong with my Zero?
[07:00:48 CET] <debianuser> Well, not necessary wrong, maybe it has some powersaving feature affecting that. Or maybe it's just a misconfiguration. But it's weird... It looks like 1ms sleep actually sleeps for 30ms. That's a lot.
[07:01:47 CET] <xtina> my Pi is being powered by a 1000C powerboost/li-po battery. i'm communicating with it via wifi (SSHed in from desktop)
[07:01:51 CET] <xtina> my wifi's power management is on
[07:01:54 CET] <xtina> don't know if any of this is relevant
[07:02:17 CET] <xtina> i don't know if the pi itself has powersaving on
[07:04:19 CET] <xtina> but it should be set at default
[07:07:50 CET] <debianuser> I don't know either. :( I don't know much about RPis, and don't know what sleep types does ffmpeg use when waiting for data, if any.
[07:08:11 CET] <xtina> i still think something is wrong with ffmpeg
[07:08:25 CET] <xtina> whatever is going on with my driver, it's not a problem for raspivid or arecord
[07:08:29 CET] <xtina> and video streaming is 100% OK
[07:08:37 CET] <xtina> even though video is bigger than audio
[07:08:52 CET] <xtina> :/
[07:11:32 CET] <xtina> debianuser: going to take a shower and clear my head, haha. i'll be back in 15. thanks again for sticking around :>
[07:11:43 CET] <xtina> feel free to suggest any other hacks haha
[07:12:25 CET] <debianuser> They're probably not using sleeps. (at least arecord uses snd_pcm_wait() which is based on file descriptors polling) So _if_ ffmpeg uses sleeps, and _if_ those sleeps it uses sleep for some unexpected amount of time - that could explain ffmpeg behavior.
[07:12:47 CET] <xtina> good point, good point
[07:13:12 CET] <xtina> we need to find the ffmpeg code where it waits for alsa packets and see what's in there.. any sleeps..
[07:14:19 CET] <debianuser> xtina: Maybe try asking someone in #raspberrypi channel (or whatever channel of your distro) if someone there also has 95% CPU usage for ffmpeg, of if their sleeps (for i in `seq -w 100`; do time sleep .$i; done) look better. Maybe it's some known issue among rpi users...
[07:15:05 CET] <xtina> debianuser: yea. well, i want to know if sleeps are involved in this chunk of ffmpeg code
[07:15:31 CET] <xtina> does anyone in the channel know where the ffmpeg code that waits for ALSA packets lives?
[07:16:12 CET] <xtina> i will try putting my SD card into a different Zero..
[07:18:53 CET] <xtina> furq: ^^
[07:18:56 CET] <xtina> kepstin: ^^
[07:19:07 CET] <xtina> quick pings in case you know, guys. thanks :)
[07:31:53 CET] <xtina> debianuser: ive been trying to find the source code
[07:32:04 CET] <xtina> it seems like this class deals with alsa audio packets https://github.com/FFmpeg/FFmpeg/blob/415f907ce8dcca87c9e7cfdc954b92df399d3d80/libavdevice/alsa_dec.c
[07:32:18 CET] <xtina> audio_read_packet()
[09:33:18 CET] <jokke> hi
[09:33:32 CET] <jokke> i need to add a black frame to the start and end of a video
[09:33:34 CET] <jokke> ffmpeg -f lavfi -i color=c=black:s=1920x1080:r=25:d=1 -i ~/Sync/Oneplus\ 3\ Photos/Camera/VID_20160709_095029.mp4 -filter_complex "[0:v]trim=start_frame=1:end_frame=2[black];[black][1:v]concat=n=2:v=1:a=0[out]" -map "[out]" /tmp/test.mp4
[09:33:39 CET] <jokke> i tried this ^
[09:33:51 CET] <jokke> but it discards any audio
[10:11:13 CET] <xtina> hey guys. i believe there's some bug in alsa.
[10:11:19 CET] <xtina> This command takes 5% CPU:   /usr/bin/arecord -Dmic_sv -c2 -r48000 -fS32_LE -twav /tmp/temp_audio.v
[10:12:17 CET] <xtina> this command takes 95% CPU: ffmpeg -f alsa -acodec pcm_s32le -i mic_sv /tmp/temp_audio.wav
[10:12:42 CET] <xtina> as far as we can tell, ffmpeg is waiting for ALSA packets differently than arecord
[10:12:45 CET] <xtina> i'm on a pi zero
[10:12:51 CET] <xtina> can anybody help? should i file a bug report?
[10:13:03 CET] <xtina> sorry, i believe the bug is in ffmpeg***
[10:39:49 CET] <sam> xtina: can you use "perf record -a" on the pi? it'll show where the CPU time is spent
[10:48:01 CET] <xtina> sam: i don't have perf and have had a hell of a time trying to install it
[10:48:09 CET] <xtina> i'm only running one command, ffmpeg
[10:48:26 CET] <xtina> or is it more granular than that?
[10:48:27 CET] <xtina> so wouldn't it just tell me the CPU time is being spent on ffmpeg?
[11:08:18 CET] <hiihiii> hi
[11:10:29 CET] <hiihiii> will I lose quality if I mix down a stereo audio stream to mono using a lossless codec?
[11:11:13 CET] <hiihiii> say "-i stereo.flac -ac 1 mono.flac"
[11:11:32 CET] <JEEB> you will lose the fact that the input is stereo
[11:11:39 CET] <JEEB> you cannot get two tracks out of it again
[11:11:48 CET] <JEEB> so in that sense you are losing something
[11:11:58 CET] <hiihiii> If that's all then I have no problems
[11:13:05 CET] <hiihiii> I'm not interested in reconstructing stereo out of mono but I'm worried about quality loss if I went from stereo to mono
[11:14:49 CET] <JEEB> that is up to the quality of the resampler, which should be good
[11:15:21 CET] <furq> you can use the sox resampler if you're paranoid
[11:15:31 CET] <hiihiii> I'm not sure I understand that sentance
[11:15:43 CET] <hiihiii> JEEB: ^
[11:15:56 CET] <JEEB> well, the resampler component is doing the stereo’mono mixing
[11:16:08 CET] <JEEB> and that should be the only thing doing changes to your audio data
[11:16:15 CET] <JEEB> thus if there is any loss of anything it's there
[11:16:27 CET] <JEEB> and as far as I know, swresample works "good enough"
[11:16:34 CET] <JEEB> so you shouldn't have issues :P
[11:16:48 CET] <hiihiii> ok
[11:17:36 CET] <hiihiii> please excuse the noob questions. what's sox resampler?
[11:18:11 CET] <hiihiii> sounds like swresample is the default
[11:18:58 CET] <furq> http://sox.sourceforge.net/sox.html
[11:19:20 CET] <furq> ffmpeg can use the resampler from that but only if you compile with --enable-libsoxr
[11:20:01 CET] <JEEB> swresample and avresample are included in FFmpeg, and for various reasons there's also an audio filter that uses the sox library's resampling
[11:20:23 CET] <JEEB> swresample is what gets used when you do audio resampling/remixing in ffmpeg.c
[11:20:41 CET] <furq> i believe sox is better but i don't know that you'd actually be able to hear the difference
[11:20:56 CET] <JEEB> pretty sure swresample has those lulzy options as well :D
[11:21:09 CET] <JEEB> I think the sox thing is mostly for comparison purposes etc
[11:21:14 CET] <JEEB> at least for developers
[11:21:17 CET] <furq> http://src.infinitewave.ca/
[11:21:20 CET] <furq> there's a comparison with an old ffmpeg there
[11:21:26 CET] <JEEB> well yeah, old FFmpeg
[11:21:28 CET] <furq> idk if swresample has improved since then
[11:21:39 CET] <JEEB> also there's the placebo parameters which you have to manually enable
[11:21:51 CET] <furq> either way i doubt it's worth rebuilding for
[11:22:21 CET] <furq> you might as well use it if you already have it, but swresample is pretty much fine
[11:23:16 CET] <furq> or you could just downmix with sox foo.flac bar.flac channels 1
[11:25:41 CET] <hiihiii> ok that sounds good
[11:32:41 CET] <hiihiii> is there any lossless audio codecs that can be muxed into an mp4 container?
[11:33:13 CET] <hiihiii> I've read about Apple lossless but don't know if that's even in ffmpeg
[11:33:22 CET] <BtbN> Isn't there some draft for flac? But nobody implements that yet.
[11:34:12 CET] <furq> there is an alac encoder in ffmpeg
[11:35:59 CET] <furq> not that i'm recommending you use it
[11:37:49 CET] <kerio> why not
[11:38:12 CET] <kerio> it's open source and royalty-free
[11:40:16 CET] <JEEB> there's also the MPEG-4 Audio's lossless audio format if we're talking about mp4 (I think it was called ALS or something?)
[11:41:30 CET] <furq> there's no encoder for that is there
[11:41:34 CET] <furq> or am i thinking of sls
[11:44:43 CET] <hiihiii> there's a decoder
[11:56:46 CET] <hiihiii> I've looked into their list of encoders. no encoder for alac
[11:57:13 CET] <hiihiii> I mean ALS
[11:58:08 CET] <furq> nobody uses that anyway
[11:59:29 CET] <hiihiii> I'll be using H.264 and flac contained in mkv then
[12:00:26 CET] <xtina> hey guys. i know i sound like a broken record. but i'm really trying to understand why FFMPEG alsa takes 95% of my CPU and produces unusable audio, while the exact same command in arecord takes 5% CPU.
[12:00:32 CET] <xtina> i just sent an email to ffmpeg-users
[12:01:08 CET] <xtina> after a long chat with debianuser, we believe something may be wrong with how FFMPEG waits for ALSA packets
[12:01:15 CET] <xtina> at the very least, it's happening differently than arecord
[12:01:29 CET] <xtina> i've ensured that the PCM settings (buffer size, period size, etc.) are identical in my FFMPEG and Arecord commands
[12:02:15 CET] <xtina> any suggestions, ideas, criticism is welcome. ffmpeg chat.. you're my last hope lol
[12:04:08 CET] <xtina> for the curious, this one takes my entire CPU: ffmpeg -f alsa -acodec pcm_s32le -i mic_sv temp.wav
[12:04:15 CET] <xtina> this one takes 5% CPU: arecord -Dmic_sv -c2 -r48000 -fS32_LE -twav temp.wav
[12:10:20 CET] <xtina> there must be someone here familiar with ALSA x FFMPEG?
[12:33:40 CET] <kerio> i find myself having to kludge a video writing
[12:34:03 CET] <kerio> is there a way to pass a list of timestamps in a file to ffmpeg and apply that to a preexisting video file?
[12:44:05 CET] <kerio> apparently mkvtoolnix can do it
[13:35:18 CET] <acamargo> hello. doesnt option hls_start_number_source work? I'd like to use epoch but I'm getting Unrecognized option 'hls_start_number_source'.
[13:36:06 CET] <JEEB> I think the HLS muxer maintainer recently removed some option because he added another one which did that kind of thing better, I think?
[13:36:38 CET] <acamargo> I read hls_wrap was deprecated
[13:36:49 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#Options-38
[13:37:07 CET] <acamargo> It's in the source code https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1475
[13:37:15 CET] <JEEB> ok, it's there in the current documentation so I would guess you're trying to use a too old version of FFmpeg?
[13:38:15 CET] <acamargo> nope... 3.2.4 here
[13:39:08 CET] <acamargo> hmmm I must set hls_flags append_list?
[13:40:15 CET] <acamargo> nope...  ehehe
[13:40:18 CET] <acamargo> ok then
[13:45:43 CET] <JEEB> I wouldn't be surprised if that was added after 3.2.x :P
[14:01:07 CET] <lazarus477> Howdy
[14:01:36 CET] <lazarus477> How can I find out what the default settings are for the command line options of ffmpeg?
[14:07:22 CET] <JEEB> the defaults are usually specific to an encoder (or decoder), so you'd have to see the code
[14:08:14 CET] <furq> -h muxer=foo will show the default codecs for a muxer
[14:08:35 CET] <furq> that's about it though
[14:17:04 CET] <lazarus477> JEEB: Ah, nice to see you helping me here as well (earlier at #x265).
[14:17:51 CET] <lazarus477> I think I got the answer I was looking for. Shall go try that out.
[14:18:45 CET] <lazarus477> Another question. Are there like any RAM buffers I can adjust to improve performance during transcoding?
[14:19:35 CET] <lazarus477> I have a shit load of video to transcode and would like to speed the process up as much as I can. I might even build from source, which I already have looked up and know how to do.
[14:26:43 CET] <furq> it probably won't make any difference
[14:27:11 CET] <furq> maybe the newest gcc/clang, fto etc will make a small difference
[14:27:28 CET] <furq> s/fto/lto/
[14:27:30 CET] <tmatth> lazarus477: you may want to use a ramdisk if disk I/O is a bottleneck for you
[14:27:44 CET] <furq> if you're using x265 then i doubt it
[14:29:10 CET] <furq> i forget how much of a bump i got for x264 with lto but it was maybe one or two percent at best
[14:29:19 CET] <furq> probably not enough to cover the time it took to rebuild
[14:31:21 CET] <kepstin> yeah, they've already got assembly optimization for all the hot loops, so lto really doesn't have much it can do.
[14:32:08 CET] <furq> i guess maybe x265 is less well-optimised in that regard but i still wouldn't expect much
[14:32:26 CET] <furq> and stuff like -mtune doesn't help much by all accounts
[14:32:33 CET] <furq> that stuff should all be detected at runtime anyway
[15:04:03 CET] <lazarus477> I think I will agree with those statements.
[15:04:32 CET] <lazarus477> I do not think disk IO is an issue. I can easily read a hell of a lot faster than I can encode.
[15:05:19 CET] <lazarus477> SATA disks in RAID1, mirror, and ZFS with mirror and striping.
[15:06:30 CET] <lazarus477> I am kinda toying with the idea of pulling out a rack server for running ffmpeg on. If I recall correctly it has dual octal core xeons and plenty of ram.
[15:07:26 CET] <lazarus477> On another note. What if any are the downsides to using variable bitrate? I have seen mentioned that it can cause playback issues...
[15:07:35 CET] <furq> there are none
[15:07:45 CET] <furq> vbr audio can cause issues on very old audio players
[15:07:53 CET] <lazarus477> Aha
[15:07:53 CET] <BtbN> it can cause issues with streaming, due to the sudden bursts and inconsistent speed
[15:08:05 CET] <furq> yeah
[15:08:23 CET] <lazarus477> Ah, the bursting explains what they ment in the docs I read about how it was bad for streaming, thanks for clearing it up for me.
[15:08:25 CET] <furq> x264's cbr mode exists solely for blu-ray compatibility, it's hidden behind a big old nest of flags so you don't turn it on for any other reason
[15:08:31 CET] <furq> idk if x265 even has a cbr mode
[15:09:03 CET] <BtbN> x264 has a non vbv buffer based cbr mode?
[15:09:23 CET] <lazarus477> furq: I think I encoded a vid with cbr yesterday, not much space savings. Redoing it without cbr brought a 1.1 GB file down to 133MB.
[15:09:35 CET] <kepstin> nah, all the cbr mode does is add padding to the vbv stuff so it doesn't go below a min bitrate, iirc?
[15:09:55 CET] <furq> --nal-hrd cbr
[15:10:09 CET] <furq> and yeah it just pads each nal to a fixed size for bd compatibility
[15:10:20 CET] <BtbN> OBS also sets that...
[15:10:21 CET] <lazarus477> bd?
[15:10:25 CET] <furq> blu-ray
[15:10:29 CET] <lazarus477> thought so.
[15:10:56 CET] <furq> BtbN: streaming stuff sets a lot of stupid flags
[15:11:05 CET] <furq> cf. -tune zerolatency
[15:11:08 CET] <lazarus477> So cbr is in other words a giant waste of space for offline video not being put to blue ray...
[15:11:37 CET] <furq> pretty much
[15:12:26 CET] <BtbN> https://github.com/jp9000/obs-studio/blob/master/plugins/obs-x264/obs-x264.c#L476
[15:12:28 CET] <BtbN> that's what it does
[15:13:07 CET] <lazarus477> I have been studying up like crazy on ffmpeg and x265. One thing that bugged me was that Windows app from x265.com that is for batch converting video files to x265. The program is said to be free but trying to download it, I see it comes with a $ purchase price.
[15:13:21 CET] <lazarus477> Is that site a rip off/scam?
[15:13:38 CET] <furq> the official site is x265.org
[15:13:43 CET] <furq> no idea what x265.com is
[15:14:15 CET] <kepstin> I think twitch recommends using cbr mode, because they're streaming video over tcp, and varying video bitrates causes issues with the TCP streams :/
[15:14:24 CET] <furq> the number of exclamation marks and slightly strange language on there makes me think that it's bullshit
[15:14:43 CET] <BtbN> kepstin, yes, Twitch does not like bandwidth fluctuations.
[15:14:55 CET] <BtbN> And the cbr mode does achive the output bitrate to be consistent :/
[15:15:55 CET] <DHE> consistency just makes things better. means the player can choose between low,medium,high more consistently, etc
[15:16:28 CET] <lazarus477> The x265 Encoder application combines a user-friendly interface with the x265 encoder library, making it easy for anyone to convert MP4 files to HEVC.
[15:16:43 CET] <lazarus477> That is the link at x265.org directing to x265.com
[15:16:49 CET] <furq> oh
[15:16:50 CET] <furq> fun
[15:16:54 CET] <BtbN> Yeah, if the "Source" quality is actually at 3.5Mbit/s, but due to low motion is only at like 1.5 the whole time, and then it suddenly bursts, people with a slow connection will suffer.
[15:17:04 CET] <DHE> ffmpeg doesn't have a pretty user-interface and runs on the commandline, but it's free and incredibly flexible.
[15:17:46 CET] <lazarus477> DHE: I know and I have no issue with that, haha.
[15:18:03 CET] <lazarus477> The thing is the lack of batch processing that takes batch output into account.
[15:18:20 CET] <lazarus477> As far as I know I will have to script my own for loop and what not.
[15:18:27 CET] <DHE> that is true, yes
[15:18:36 CET] <Diag> Si
[15:18:39 CET] <BtbN> well, that's what you have a shell for
[15:18:41 CET] <furq> half the reason i have msys installed is so i don't ever have to write batch scripts
[15:18:49 CET] <lazarus477> Not a big deal since I am a programmer but my bash is rusty as heck.
[15:19:13 CET] <Diag> lazarus477 what languages do you know
[15:19:43 CET] <DHE> sure, but it can be other languages as well. or indirectly. I've done batch encoding using a script in perl to launch ffmpeg, and xargs to launch many instances of the perl script at once (-n 1 -P $numinstances)
[15:20:06 CET] <lazarus477> C, C++, PHP, various forms of VisualBasic, JS, Bash (used it for 1 project.).
[15:20:34 CET] <Diag> Do you know basic++
[15:20:51 CET] <lazarus477> Never even heard of basic++.
[15:21:04 CET] <Diag> Tibasic?
[15:22:17 CET] <lazarus477> Diag: Nope.
[15:22:27 CET] <Diag> Wooooow
[15:23:07 CET] <lazarus477> I used to work on a MS Access project in which I had to put together a whole set of input and output forms and code macros and event handles. That I did in Visual Basic.
[15:23:22 CET] <lazarus477> Next I dabble in LibreOffice Basic for the same reasons.
[15:23:50 CET] <lazarus477> My C and C++ background come from my original interest in programming which was to make games and simulations.
[15:23:56 CET] <furq>  /bin/sh ought to be enough for anyone
[15:24:02 CET] <lazarus477> That evolved into database programming.
[15:24:24 CET] <lazarus477> I use JS and PHP in my web projects, naturally.
[15:24:56 CET] <lazarus477> As for Bash. Only used it once to write a plugin for Bacula (a networked backup system).
[15:25:42 CET] <lazarus477> I have used these languages in other areas such as fiddling with broken app code to make shit work...
[15:27:35 CET] <lazarus477> Hmm. Now I remember. Back in the 90s I got this free Linux CD, Redhat Linux. I remember getting it installed, heading to the CLI to mount a CD and saying to myself "This shit is way to complicated..." I then decided to put Linux on hold till I learn programming. Then I taught myself C.
[15:28:03 CET] <lazarus477> Before I knew it I was tutoring people for their school exams, over IRC.
[15:28:32 CET] <lazarus477> This  led to me meeting my future wife, on IRC... Now I am married with 2 kidds...
[15:28:56 CET] <lazarus477> Hmm. Perhaps I should have stuck with MS Windows...
[15:35:27 CET] <lazarus477> Diag: If you want a full list of what I have been into then check my linked in profile. The list is so long I cannot keep track of it in my head...
[16:27:49 CET] <esby> hello, i have a 7 min 21 video encoded with h264 and aac for the audio, when i extract the sound track, it gets me a 7 min 48 audio track... (meaning the audio is slowed apparently) is there anything that could cause that ?
[16:28:18 CET] <esby> when i try to mux my video with another one, i get sync issue too
[16:28:41 CET] <Diag> 721 to 748?
[16:29:07 CET] <furq> esby: is it actually slower or is there a gap at the end
[16:29:08 CET] <esby> 441s to 468s
[16:29:30 CET] <Diag> spoopy
[16:30:16 CET] <esby> furq: the mp3 last up to 468s when i check it in audacity / audacious
[16:30:40 CET] <esby> so i assume it is not played at the correct 'speed'
[16:30:56 CET] <esby> i obtained by merging a lot of other files with concat
[16:31:03 CET] <esby> (for the original video)
[16:33:21 CET] <Diag> idunno
[16:34:23 CET] <esby> i am wondering if it could similar to the 48khz 44.1khz, but i don't see a reason for this to happend
[16:36:45 CET] <esby> could be that, my original samples seem to be a 48khz, my current sample is a 44.1 khz
[16:50:10 CET] <xeche> Hi. Are there any usage examples for writing container + encoded data to file that don't rely on deprecated functionality?
[16:51:23 CET] <JEEB> check if the deprecation warnings come from say, the docs/examples (as in, API user itself) or from inside the libraries themselves
[16:54:04 CET] <esby> furq: that was a 48khz 44.1khz issue
[17:03:01 CET] <DHE> xeche: the biggest pitfall these days is using the AVStream->codec field, which you don't need if you're not doing stream copying anyway
[17:03:21 CET] <DHE> *not doing stream transcoding
[17:03:41 CET] <ssalenik> Hi, if receiving two RTP streams defined by a .sdp with ffmpeg (one audio, one video) and then putting the result into an mkv. Is there any synchronization done between the two streams using their RTP timestamps?
[17:04:57 CET] <DHE> not by default. if they're two live streams then they may be written out of sync with whichever one is the "first" stream starting ahead of the second for example
[17:05:42 CET] <ssalenik> is there a way to enable this in ffmpeg, or does this need to be implemented by the user?
[17:07:49 CET] <DHE> not 100% sure off the top of my head. I'd need to experiment. I might suggest starting by saving the two streams to disk first and then you can work with them freely.
[17:08:14 CET] <ssalenik> ok, thanks, I'm experimenting as well :)
[17:19:54 CET] <xeche> DHE: I'm encoding raw RGB24 frames. And yes, I'm trying to heed what's deprecated. That's why I'm asking this question in the first place. I use the headers to avoid deprecated functions
[17:20:38 CET] <xeche> JEEB: if the library itself prints the deprecation warnings, should I ignore them??
[17:20:47 CET] <xeche> version 3.2.2 on windows, if relevant
[17:21:02 CET] <DHE> if you mean during 'make' then yes. if you mean to the av_log (stderr) then you should fix the program
[17:21:43 CET] <JEEB> xeche: so if they come from within the library and not from your usage of the lib, then it's a problem internal to FFmpeg and not your usage of the APIs
[17:28:18 CET] <xeche> JEEB: I see. Thanks for the clarification. :)
[18:25:09 CET] <olaf_> Is there a way to download a stream for a limited amount of time? youtube-dl saves the live stream to a *.m3u8.part file, and it never knows when to stop, appearently.
[18:25:56 CET] <olaf_> I see the ffmpeg call with all its options. Most likely I can tweak it to record just for 60 minutes or so. What would be the cmdline option for that?
[18:31:35 CET] <klaxa> -t 3600
[18:31:51 CET] <klaxa> olaf_: ^
[18:32:03 CET] <olaf_> -t 2 keeps going :-(
[18:32:04 CET] <Rembo> hello everyone, i'm getting 0 bytes file if i run http://www.vidmix.ro/tester/ff.php , can someone help?
[18:32:41 CET] <klaxa> where are you applying -t ? at youtube-dl?
[18:32:41 CET] <Rembo> ffmpeg version 2.2.1 , i'm using centos 6
[18:32:52 CET] <klaxa> obviously that won't automagically get passed down to ffmpeg
[18:32:54 CET] <olaf_> and -timelimit 2 does not work either.
[18:33:12 CET] <olaf_> but maybe -t 22, lets see.
[18:33:43 CET] <olaf_> ffmpeg -y -timelimit 22 -headers Acc...
[18:34:04 CET] <olaf_> frame= 2006 fps= 40 q=-1.0 size=   35716kB time=00:01:20.74 bitrate=3623.8kbits/s speed=1.61x    , still keeps going. :(
[18:34:27 CET] <klaxa> that is weird
[18:34:34 CET] <olaf_> most likely not the correct tool for the job, which starts in about 24 Minutes!
[18:34:40 CET] <olaf_> damn
[18:35:15 CET] <klaxa> well what is your complete command?
[18:35:18 CET] <olaf_> ffmpeg -y -timelimit 22 -headers Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7? Accept-Language: en-us,en;q=0.5? Accept-Encoding: gzip, deflate? Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20150101 Firefox/47.0 (Chrome)?  -i https://br_hdslive-f.akamaihd-staging.net/i/bfssued_worldwide@119891/master.m3u8 -c copy -f mp4 -bsf:a aac_adtstoasc file:Lives
[18:36:24 CET] <olaf_> it seems youtube-dl is not able to just record jsut for a few minutes.
[18:36:40 CET] <klaxa> maybe try moving -t after -bsf:a aac_adtstoasc
[18:36:49 CET] <Rembo> anyone can help me with this issue? http://www.vidmix.ro/tester/ff.php
[18:36:59 CET] <olaf_> at some point it did stop.
[18:37:12 CET] <olaf_> video is 3:28 long.
[18:37:23 CET] <klaxa> huh
[18:37:40 CET] <olaf_> vlc can play it. hmm.
[18:38:01 CET] <olaf_> and audio has an offset. ARGH
[18:38:08 CET] <olaf_> not in sync
[18:38:36 CET] <klaxa> Rembo: sorry, with so little input nobody can really help, track down the problem to a failing ffmpeg command
[18:39:01 CET] <klaxa> as in, the command your php-script calls that fails
[18:39:40 CET] <Rembo> klaxa, how can i test ffmpeg using command line?
[18:40:03 CET] <klaxa> by using the command line?
[18:40:28 CET] <klaxa> or do you mean like, a sample command?
[18:41:07 CET] <klaxa> ffmpeg -f lavfi -i testsrc -t 30 -pix_fmt yuv420p testsrc.mp4
[18:41:09 CET] <Rembo> i have a test.avi and i want to make output out.avi
[18:41:11 CET] <klaxa> maybe like that?
[18:41:21 CET] <klaxa> ffmpeg -i test.avi out.avi
[18:57:17 CET] <Rembo> klaxa, using command line work, but when i try using php script it write 0 bytes file
[18:58:09 CET] <Rembo> Command send to server: ffmpeg -i test.avi -vcodec libx264 -s 640x360 -threads 4 -movflags faststart test.mp4
[18:58:26 CET] <Rembo> FFmpeg output array(0) {}int(1)
[18:58:59 CET] <klaxa> is that maybe stdout of the system() call?
[18:59:08 CET] <klaxa> what about the file test.mp4
[18:59:28 CET] <olaf_> unbelievable. have to go back to years old analog physical video recorder to record that stuff. so sad...
[18:59:37 CET] <olaf_> and have to configure it first..
[19:04:37 CET] <Rembo> klaxa test.mp4 has 0 bytes
[19:05:04 CET] <klaxa> either remove test.mp4 before calling again or make the php script use -y
[19:05:13 CET] <klaxa> the file already exists and is thus not overwritten
[19:11:35 CET] <Rembo> klaxa: http://pastebin.com/gUNUMiiA
[19:12:28 CET] <klaxa> <klaxa> is that maybe stdout of the system() call?
[19:12:31 CET] <klaxa> <klaxa> either remove test.mp4 before calling again or make the php script use -y
[19:12:31 CET] <klaxa> <klaxa> the file already exists and is thus not overwritten
[19:13:12 CET] <Rembo> klaxa i have removed .mp4 and i tried again
[19:20:14 CET] <Rembo> klaxa: http://i67.tinypic.com/24670ug.jpg
[19:53:09 CET] <ChocolateArmpits> n
[19:54:46 CET] <Diag> i
[20:31:51 CET] <kota1> Is there a way to make ffmpeg transcode in real time when concatenating several input files at different framerates via the concat filter?
[20:43:43 CET] <c_14> use the realtime filter
[21:53:58 CET] <byumark> We use ffmpeg to concat a slate (mp4) to the end of a video file (mp4) and most the time it work great but occasionally, like 20% of the time, maybe, the slate will have a video glitch 2 or 3 seconds into it
[21:54:19 CET] <byumark> it appears to go black for one frame
[21:54:26 CET] <byumark> this is very intermittent
[21:57:25 CET] <byumark> if we add a frame or two to the first file before concatenating then it resolves the issue
[22:10:30 CET] <ssalenik> DHE: fyi, it seems that if you setup the rtcp SR correctly, then two RTP live streams will get synced (should have read the rfc :P)
[22:15:14 CET] <JEEB> ;) always fun to find such little things
[22:17:13 CET] <nohop> I'm using libavodec to endoce a video stream using nvenc. How do i make this lossless ? is there a 'preset' for is ?
[22:17:16 CET] <nohop> *it
[22:21:14 CET] <sfan5>   -preset            <int>        E..V.... Set the encoding preset (from 0 to 11) (default medium)
[22:21:20 CET] <sfan5>      lossless                     E..V....
[22:21:59 CET] <nohop> yeah.. hmm.. does that work with av_opt_set*() ?
[22:22:02 CET] <DHE> note that lossless is not supported on all GPUs
[22:23:00 CET] <DHE> av_dict_set(&dictptr, "preset", "lossless", 0);  avcodec_open2(avctx, nvenc_codec, &dictptr);
[22:23:30 CET] <DHE> try it once with ffmpeg and watch the output. if lossless isn't supported on your GPU it will print an error and fail
[22:23:55 CET] <nohop> ah, alright. Thank you very much. I'll give that a show :)
[22:25:25 CET] <baldgeek_> hello
[22:26:30 CET] <baldgeek_> I'm trying to encode to hevc  main profile 3.0, I know ffmpeg doesn't support profiles for 265 like 264, does anyone have any ideas of where I can look to find out what options to set
[22:28:07 CET] <sfan5> see what x265 --help says, you can pass those to -x265-params
[22:30:01 CET] <DHE> a quick source skim of the x265 library doesn't look promising
[22:30:28 CET] <sfan5>    --level-idc <integer|float>   Force a minimum required decoder level (as '5.0' or '50')
[22:30:31 CET] <sfan5> what about that?
[22:31:38 CET] <DHE> profile must be done by the caller (ffmpeg) using the x265_param_apply_profile. I don't see any way in the x265 code to do it another way
[22:32:35 CET] <sfan5> ¯\_(Ä)_/¯
[22:32:41 CET] <baldgeek_> sfan5: what's the command for the x265 help? forgive me, I'm still treading water, literally only been playing ffmpeg for a couple of weeks
[22:33:03 CET] <sfan5> x265 --help
[22:33:04 CET] <DHE> it's the x265 library's own command-line tool
[22:33:07 CET] <sfan5> is the help of x265 itself
[22:33:13 CET] <sfan5> ffmpeg -h encoder=libx265
[22:33:18 CET] <sfan5> are the options ffmpeg offers for x265
[22:35:29 CET] <DHE> you can use -x265-params to specify options manually from the x265 --help output
[22:38:49 CET] <baldgeek_> so like this: -x265-params profile=3.0
[22:39:27 CET] <sfan5> it looks like x265 doesn't take a "profile" param, so no that wont work
[22:40:19 CET] <DHE> x265 source (source/common/param.cpp) doesn't appear to accept profile or preset. but it does accept level
[22:45:18 CET] <baldgeek_> so would this be valid : -x265-params profile=main:level-idc=3.0
[22:46:35 CET] <sfan5> probably
[00:00:00 CET] --- Sat Feb 18 2017