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

[burek]

[00:03:48 CEST] <NoTiTo_> c_14: do you have  link to a fool proof guide to building / compiling your own ffmpeg
[00:03:50 CEST] <NoTiTo_> ?
[00:04:57 CEST] <NoTiTo_> c_14: thanks mate, the stream is working now, albeit not perfect. I didn't realise it was the 'broken' ffmpeg giving me issues
[00:08:46 CEST] <c_14> NoTiTo_: https://trac.ffmpeg.org/wiki/CompilationGuide
[00:28:42 CEST] <NoTiTo_> c_14: is there a way for ffmpeg to output a CBR MPEG TS?
[00:29:34 CEST] <c_14> ffmpeg -i video -b:v xk -minrate xk -maxrate xk -f mpegts out.ts
[00:30:13 CEST] <Mavrik> NoTiTo_, there's a muxrate parameter that stuffs MPEG-TS stream with NULL packets
[00:30:17 CEST] <Mavrik> but it's not always reliable
[00:30:43 CEST] <Mavrik> c_14, that won't necessarily make a properly compliant CBR TS stream :)
[00:31:04 CEST] <c_14> meh, compliancy
[00:31:11 CEST] <c_14> :P
[00:34:17 CEST] <NoTiTo_> Mavrik, thanks. I was just looking into that
[00:51:26 CEST] <NoTiTo_> thanks and catch you later peeps!
[02:47:21 CEST] <Norwack> Don't know if this is the right place to ask, but anyways; Is there any documentation available on librtmp? The man page isn't very detailed
[04:18:10 CEST] <jjohn> Ahoy, guys. I do have a problem with the amerge mixer in ffmpeg and thought that maybe you guys could help me out there.
[04:18:17 CEST] <jjohn> The problem: http://pastebin.com/R4KQ4yPd
[04:35:52 CEST] <klaxa> jjohn: i had a similar problem and resorted to using sox separately to ffmpeg
[04:37:38 CEST] <jjohn> klaxa no option here, though. The audio comes from two devices. No files.
[04:37:44 CEST] <klaxa> what you want is merge on the sox manpage (http://sox.sourceforge.net/sox.html)
[04:37:58 CEST] <klaxa> you could do it with pipes
[04:38:05 CEST] <klaxa> but i don't know how much delay would be added
[04:38:40 CEST] <klaxa> you could probably duplicate the mono input and generate a stereo input
[04:38:52 CEST] <jjohn> Also, the audio needs to be muxed into FLV as well.
[04:39:54 CEST] <jjohn> Am I not already doing this? Accoding to this site: https://trac.ffmpeg.org/wiki/AudioChannelManipulation
[04:40:13 CEST] <jjohn> Mono -> stereo: simply add -ac 2 to the output options.
[04:41:21 CEST] <klaxa> that is for the output stream though
[04:41:35 CEST] <klaxa> you could do this: https://trac.ffmpeg.org/wiki/AudioChannelManipulation#monostereo
[04:41:51 CEST] <klaxa> and then use amix
[04:42:02 CEST] <klaxa> to see if it makes it any better
[04:43:16 CEST] <jjohn> You mean, by first changing the volume of each stream separately, and then using amix?
[04:45:27 CEST] <klaxa> yes
[04:45:53 CEST] <klaxa> your filtergraph could look something like this: "[0:0]volume=0.20:precision=fixed[a0];[1:0]volume=6.0:precision=fixed[a1];[a1][a1]amerge=inputs=2[a2];[a0][a2]amix[aout]"
[04:53:47 CEST] <jjohn> Hm ... does not work out. "Stream specifier 'a1' in filtergraph description [0:0]volume=0.20:precision=fixed[a0];[1:0]volume=6.0:precision=fixed[a1];[a1][a1]amerge=inputs=2[a2];[a0][a2]amix[aout] matches no streams."
[05:03:48 CEST] <klaxa> that's weird
[05:04:28 CEST] <jjohn> Before you ask: I have the latest ffmpeg version installed. Freshly downloaded from git and even more freshly compiled and installed.
[05:06:43 CEST] <klaxa> i have to agree, it works not as i expected
[05:13:08 CEST] <fffan> AV_SAMPLE_FMT_S16 means singed 16 bit integer, and range is -32767 to +32767 and 0 means silence,  so, my question is what does negative value mean?
[05:13:37 CEST] <fffan> 0 means silence, what does -1 means?
[05:15:32 CEST] <fffan> more silent?
[05:20:49 CEST] <jjohn> fffan: my guess would be that the negative values are the 1's complement encoded values for the 32767 - 65534 range.
[05:22:15 CEST] <jjohn> -1 would be 65534 in the 1's complement system.
[05:27:57 CEST] <fffan> if so, why AV_SAMPLE_FMT_S16, why not AV_SAMPLE_FMT_u16
[05:28:45 CEST] <fffan> AV_SAMPLE_FMT_u16 is more intuitionistic
[05:29:12 CEST] <jjohn> Because hardware can be picky about what to understand, I'd say.
[05:30:21 CEST] <jjohn> u16 does not use any complement, so you get rid of the two-representations-for-0 problem in the 1's complement system and have a 65535 value available in u16.
[05:30:41 CEST] <fffan> you know there is a definition of another pcm type
[05:30:42 CEST] <fffan> AV_SAMPLE_FMT_U8,          ///< unsigned 8 bits
[05:32:59 CEST] <jjohn> u8 would be the same. Instead of your -127 - 127 range, you can have a 255 value (which is -128 in the 2's complement system which is not available in the 1's complement system).
[05:37:56 CEST] <fffan> one's complement system is rare
[05:39:19 CEST] <jjohn> Can be, but it's simple enough for hardware decoders.
[05:41:48 CEST] <fffan> thanks, I'll google details about pcm16.
[05:42:52 CEST] <jjohn> Also: http://wiki.multimedia.cx/?title=PCM
[05:43:30 CEST] <jjohn> Looks like I was wrong, it always uses 2's complement.
[05:43:40 CEST] <jjohn> > If the sample is unsigned, the sample range is 0..255 with a centerpoint of 128. If the sample is signed, the sample range is -128..127 with a centerpoint of 0. If a PCM type is signed, the sign encoding is almost always 2's complement.
[05:45:16 CEST] <fffan> AV_SAMPLE_FMT_S16 means always signed, so always 2's compement
[05:51:59 CEST] <jjohn> Anyhow: does anyone have an idea for this one? http://pastebin.com/R4KQ4yPd
[06:15:11 CEST] <k_sze[work]> Does zeranoe's builds for Windows make use of advanced Intel CPU features?
[07:37:16 CEST] <fffan> zeranoe's build sucks
[07:39:46 CEST] <k_sze[work]> fffan: as in they are hardly optimized?
[07:41:13 CEST] <fffan> I don't think so.
[08:32:57 CEST] <k_sze[work]> I wish I know how to build ffmpeg on windows.
[08:33:24 CEST] <k_sze[work]> I still haven't managed to get the mingw-w64 toolchain and everything working.
[08:33:44 CEST] <k_sze[work]> I kind need to make an optimized build for 4th gen Core i5
[08:34:31 CEST] <k_sze[work]> We're encoding 4 streams in real time simultaneously and the Core i5 can hardly catch up.
[09:04:41 CEST] <fffan> so k_sze, which country are you from?
[09:05:24 CEST] <jjohn> k_sze may I ask what you have been trying to do? Because I can cross-compile ffmpeg on my Linux box.
[09:06:45 CEST] <jjohn> OK, it cannot link the final file, because the linker of mingw32 seems to be broken and exists with a segfault, but I guess that's because my toolchain is outdated.
[09:06:58 CEST] <jjohn> But the libraries do compile.
[09:07:38 CEST] <jjohn> exits*
[10:12:53 CEST] <Mavrik> k_sze[work], yes, the most important encoders do.
[10:13:15 CEST] <Mavrik> compiling it yourself won't really add any performance
[10:15:04 CEST] <k_sze[work]> fffan: Hong Kong
[10:26:37 CEST] <k_sze[work]> Mavrik: I'm especially interested in H.264 and FFV1 encoding optimization.
[10:26:53 CEST] <Mavrik> H.264 uses libx264 library which always autodetects CPU features
[10:26:56 CEST] <k_sze[work]> but I guess those are already highly optimized in the default build?
[10:27:51 CEST] <k_sze[work]> I'm doing two H.264 streams, yuyv 1920x1080 and yuyv 1600x1200, 30fps
[10:27:52 CEST] <Mavrik> ffv1 encoder doesn't have any specific CPU optimizations though
[10:28:11 CEST] <k_sze[work]> the Core i5 can barely keep up using ultrafast preset.
[10:28:55 CEST] <k_sze[work]> I wonder if QSV will be any better.
[10:31:24 CEST] <jjohn> Does anyone have an idea for this problem? http://pastebin.com/R4KQ4yPd
[10:34:28 CEST] <Mavrik> jjohn, I think you're supposed to use amix, not amerge
[10:34:48 CEST] <Mavrik> jjohn, since amerge will create a 3 channel output
[10:34:58 CEST] <Mavrik> not a stereo output like you want
[10:35:12 CEST] <Mavrik> also try using HE-AAC profile which will improve quality for spoken voice
[10:36:41 CEST] <jjohn> It's not only spoken voice, though - only the second one.
[10:39:27 CEST] <jjohn> Also, I have now changed the filter to "[1:0]volume=0.20:precision=fixed[a0];[2:0]volume=6.0:precision=fixed[a1];[a0][a1]amix[aout]". But it still sounds metallic.
[10:40:12 CEST] <jjohn> Mavrik
[10:40:50 CEST] <Mavrik> did you actually check ffmpeg output to see what you're getting encoded? why are you forcing fixed precision?
[10:42:14 CEST] <jjohn> Because I only have s16 coming from the input ... shouldn't I do this?
[10:43:56 CEST] <jjohn> And yes, I checked the output. Input: two streams, first one: 0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s, second one: 1:0: Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s
[10:44:24 CEST] <jjohn> Output: one stream: amix (graph 0) -> Stream #0:0 (libfdk_aac)
[10:46:04 CEST] <jjohn> BTW, it also sounds bad if I increase the bitrate to 320 kbits/s - 320 kbits/s should be enough in every case, whether it's voice or not.
[10:46:16 CEST] <jjohn> Mavrik
[11:23:19 CEST] <jjohn> No idea?
[13:14:00 CEST] Last message repeated 1 time(s).
[14:05:58 CEST] <haxie> are palettegen and paletteuse only available in recent ffmpeg versions? do you need to set special flags for those?
[15:37:42 CEST] <captain-codec> Hello! I don't have not so much experience with codecs transcode ... my  question is: I have an Intel(R) Core(TM) i7-4600M CPU @ 2.90GHz. Is it possible to transcode a mkv movie and stream it over mpeg-ts with a bitrate about 4mbit. the cpus are at 20% but I get some dups. I think the dups are responsible for the artifacts / false pixel.   am i rig
[15:37:42 CEST] <captain-codec> ht that my hardware must be able to transcode and stream it?
[15:45:04 CEST] <Mavrik> you didn't really say which codecs and encoders you use
[15:45:17 CEST] <Mavrik> but that CPU should handle H.264/AAC encode for a single stream yeah
[15:54:10 CEST] <captain-codec> input codec is h256 and the output stream uses mpeg2
[15:54:51 CEST] <captain-codec> when i tried h264/aac I had 100% cpu utilization
[16:00:51 CEST] <Mavrik> And that's a bad thing?
[16:01:18 CEST] <captain-codec> well yes cause my stream is laggy then
[16:01:27 CEST] <captain-codec> and I have some dups
[16:02:01 CEST] <captain-codec> that's my command line ffmpeg -re -i file.mkv -vcodec libx264 -s 1280x720 -r 25 -b:v 8M -acodec libfaac -ac 2 -b:a 192k -f mpegts udp://239.0.0.1?pkt_size=1316
[16:02:27 CEST] <RobotsOnDrugs> x264 has some tuning options for streaming
[16:03:30 CEST] <Mavrik> What are these dups you're talking about?
[16:04:24 CEST] <captain-codec> dup
[16:04:34 CEST] <captain-codec> I think dup are duplicated pictures
[16:04:55 CEST] <captain-codec> for instance : "frame=  324 fps= 25 q=2.0 Lsize=    7104kB time=00:00:13.45 bitrate=4325.8kbits/s dup=13 drop=0  "
[16:13:21 CEST] <captain-codec> @RobotsOnDrugs are this tuning options minrate maxrate and bufsize ?
[16:15:19 CEST] <RobotsOnDrugs> those are a few that might be helpful
[16:15:28 CEST] <RobotsOnDrugs> there's also -tune zerolatency
[16:15:42 CEST] <RobotsOnDrugs> (i forget how to map that to ffmpeg though)
[16:16:42 CEST] <c_14> -tune zerolatency
[16:16:54 CEST] <captain-codec> well with this cmd then the stream is more unstable than without :/
[16:20:04 CEST] <captain-codec> ok i wil lgive it a try with zerolatency
[16:20:58 CEST] <captain-codec> how would you stream a h265 over h264 ?
[16:21:38 CEST] <c_14> ^what
[16:26:21 CEST] <captain-codec> I meant, how would you stream a file which has a codec h265 over multicast with codec h264/aac ?
[16:31:16 CEST] <c_14> The same way I'd stream any other file?
[16:31:45 CEST] <c_14> ffmpeg -i file -c:v libx264 -c:a aac -strict -2 -f matroska udp://wheeee
[16:32:29 CEST] <captain-codec> so and there might be no problems ?
[16:32:34 CEST] <captain-codec> with artifacts
[16:33:23 CEST] <captain-codec> or shouldn't i transcode while streaming?
[16:33:24 CEST] <c_14> Unless the udp borks, no.
[16:33:35 CEST] <c_14> As long as you can decode/encode at realtime it shouldn't be a problem.
[16:34:39 CEST] <Mavrik> -tune zerolatency will fuckup quality
[16:34:55 CEST] <Mavrik> for no reason since you don't need zerolatency when reading a FILE
[16:35:11 CEST] <Mavrik> you're getting artifacts probably due to issues on UDP layer, try using TCP
[16:35:14 CEST] <Mavrik> and fixing network
[16:37:00 CEST] <captain-codec> well i am streaming over my private network laboratory. I cant see any drops or crc on the interfaces
[16:37:40 CEST] <captain-codec> well maybe the iptv boxes can be crap.... but when i try it with my iptv provider i dont have any issues
[16:38:37 CEST] <Mavrik> you're not going to get artifacting on encoder layer without explicit error messages
[16:38:44 CEST] <Mavrik> "dup" isn't really important in your context
[16:39:03 CEST] <Mavrik> so if you're getting blocking artifacts (missing parts of new picture) you're losing data on a network layer or ordering is getting messed up
[16:56:07 CEST] <jasonwhite> Hi guys, I am having a problem and I hope some guru here could help me :D  I want to compare bitrate,file size ... of two Xvid and H.264 videos of the same quality. With x264, I only know -crf option (default 23) to set quality ( I dont know -qp, quantization param, since the official guide did not mention). With Xvid I know -qscale option. My question is, since -crf range is 0-51, -qscale range is 0-31, what is the proper value o
[16:56:19 CEST] <jasonwhite> and -qscale to have those 2 videos the same quality?
[16:56:40 CEST] <jasonwhite> Oopss. Sorry. Split line... I will post my question again.
[16:56:43 CEST] <jasonwhite> #######################
[16:56:47 CEST] <jasonwhite> Hi guys, I am having a problem and I hope some guru here could help me :D  I want to compare bitrate,file size ... of two Xvid and H.264 videos of the same quality. With x264, I only know -crf option (default 23) to set quality ( I dont know -qp, quantization param, since the official guide did not mention). With Xvid I know -qscale option.
[16:56:53 CEST] <jasonwhite> My question is, since -crf range is 0-51, -qscale range is 0-31, what is the proper value of -crf (or -qp if possible ) and -qscale to have those 2 videos the same quality?
[17:04:15 CEST] <ps-auxw> jasonwhite: There isn't one, really. You'll need to try a bunch of values and visually compare the results to see if they are sufficiently close. It's subjective of course. IMHO it would be better to encode the to have the same bitrate using 2 pass encoding and then compare quality. Depending on what you are going for, try to match encoding speed too. That's much easier to do in a fair way.
[17:07:06 CEST] <jasonwhite> ps-auxw: First, you are my favorite command :D Second, I have done the test with constant bit rate and now try to do with varying bit-rate. As you said, I must have try bunch of value, and then I can do PSNR test instead of subjectively judge 2 videos, right ?
[17:07:33 CEST] <captain-codec> thank you guys. I will try it again! bye
[17:12:23 CEST] <ps-auxw> jasonwhite: Hehe. :) If you are going to go with an objective measurement, I would recommend SSIM rather than PSNR. It's not perfect, but it's closer to human perception than PSNR. Also, you'll want to use the ssim tune for x264, as the psy optimizations (which make things look better, but lower PSNR and SSIM) will reduce SSIM otherwise.
[17:14:38 CEST] <ps-auxw> You can also take a look at this for things to avoid when doing a comparison: http://x264dev.multimedia.cx/archives/472
[17:16:23 CEST] <jasonwhite> ps-auxw: I dont know about psy optimizations part, seems like needing a lot of reading ...  The link sounds fun. Thanks for your information !
[17:21:04 CEST] <ps-auxw> You're welcome. :)
[17:27:39 CEST] <jjohn> Does anyone have an idea for this problem? http://pastebin.com/R4KQ4yPd
[20:10:25 CEST] <jjohn> Noone?
[20:11:41 CEST] <llogan> jjohn: you didn't provide the complete console outputs
[20:17:53 CEST] <jjohn> llogan there you go: http://pastebin.com/ABgSiX1F
[20:22:51 CEST] <seasc> jjohn, whats the question? just loged in after you asked 'noone'?
[20:23:09 CEST] <seasc> erm, just before :p
[20:23:49 CEST] <jjohn> seasc this one: http://pastebin.com/R4KQ4yPd
[20:25:10 CEST] <jjohn> Thee reason why in the previous pastebin the command has a bitrate of 320kbits/s was to show that it's not an issue due to the lossy encoding of AAC.
[20:25:26 CEST] <seasc> jjohn, by merge, you mean join as in 'append'?
[20:25:59 CEST] <jjohn> No, as in "Both audio sources play at the very same time".
[20:27:08 CEST] <jjohn> Both amerge and amix are capable of doing that. But the quality loss is just huge - I don't expect transparency here, but we are talking about AAC 128 kbits/s here.
[20:29:23 CEST] <jjohn> Such quality loss is not acceptable - and please note that the loss is even there at 320 kbits/s, so the bitrate can't be the culprit.
[20:32:29 CEST] <seasc> why are you using microphone and loop_out as inputs?
[20:33:06 CEST] <seasc> and i'm confused to see 'mono' and 'stereo' as input-files
[20:34:06 CEST] <seasc> jjohn, saying, the command looks too long to my eyes, thinking that ffmpeg automaticly reckognizes the stream/file as mono/stereo, but either way, this is too complex for me, sorry
[20:34:11 CEST] <jjohn> mono = microphone, stereo = loop_out. I meant to change it for clearity (so that you can see what's what), but because I am stupid I did the job only to 50%. :(
[20:34:35 CEST] <seasc> :) no worries, thought so, its just confusing a bit
[20:35:20 CEST] <jjohn> What do you mean with "too long for your eyes"? Something's bothering you?
[20:51:19 CEST] <jjohn> c_14 got that?
[20:56:28 CEST] <c_14> Can you create input files that this happens with? Cause I just tested with a stereo + mono file I had lying around and I can't notice any quality loss exceeding that caused by lossy reencoding. (though I used opus instead of aac, but if the problem is really the mixing that shouldn't matter)
[20:57:09 CEST] <jjohn> Gimme a second, I'll try.
[20:57:59 CEST] <jjohn> Input files in FLAC format?
[20:58:54 CEST] <c_14> Sure, doesn't really matter as long as it's reproducible.
[21:05:34 CEST] <jjohn> Why, that's strange. I did as you said - create one stereo and one mono file (stereo.flac and mono.flac), and if I don't grab it directly from the ALSA interfaces, the audio in the output file is fine, even with 128 kbits/s.
[21:06:30 CEST] <jjohn> That is, if I just exchange the ALSA grabbing parameters with stereo.flac and mono.flac, I don't have any problems.
[21:08:07 CEST] <c_14> Can you trie getting rid of the -channel_layout input options?
[21:08:19 CEST] <c_14> *try
[21:08:48 CEST] <jjohn> Already did so since seasc said to drop them.
[21:09:10 CEST] <c_14> oh, right
[21:09:33 CEST] <c_14> how about the thread_queue_size ?
[21:11:31 CEST] <jjohn> Got rid of the parameters for both streams. Now I have the warning "Thread message queue blocking; consider raising the thread_queue_size option (current value: 8)" showing up twice, and the output sounds bad again.
[21:12:58 CEST] <c_14> no clue. Try grabbing the streams from alsa in one ffmpeg process and then piping them as pcm (inside wav or something) to another ffmpeg process that does the filtering?
[21:22:15 CEST] <jjohn> c_14 hm. I did that. The quality loss is gone ... but it seems that there is either an echo now, or the stereo channel are not in sync anymore, because I hear the sound from the stereo source twice.
[21:23:16 CEST] <jjohn> I created the pipes with mknod stereo p and mknod mono p and started two more ffmpeg processes that would grab from each ALSA interface.
[21:24:13 CEST] Action: c_14 was thinking of `ffmpeg -f alsa -i 1 -f alsa -i 2 -c:a pcm_s16le -f wav pipe:1 | ffmpeg -i pipe:0 -filter_complex '
[21:24:58 CEST] <jjohn> Lol didn't know it was possible like that. I will try that out.
[21:30:42 CEST] <jjohn> Can I grab both audio streams with only one ffmpeg process? Because now I have:  /opt/local/ffmpeg/bin/ffmpeg -threads 7 -thread_queue_size 4096 -f alsa -ac 2 -i loop_out -f alsa -ac 1 -i microphone -f wav -c:a pcm_s16le pipe:1 | /opt/local/ffmpeg/bin/ffmpeg -threads 7 -i pipe:0 -filter_complex "[1:0][1:0]amerge=inputs=2[a1];[0:0]volume=0.20:precision=fixed[a0];[a1]volume=6.0:precision=fixed[a2];[a0][a2]amix
[21:30:48 CEST] <jjohn> [aout]" -map [aout] -c:a libfdk_aac -cutoff 15000 -b:a 128k -f flv /home/jjohn/test_recording.flv, but it only seems to grab one stream.
[21:31:46 CEST] <c_14> eh, add -map 0 -map 1 to the first ffmpeg process
[21:33:32 CEST] <jjohn> Blech. "[wav @ 0x1b7d1e0] WAVE files have exactly one stream". That's what it's giving me right now.
[21:33:45 CEST] <c_14> use matroska
[21:33:49 CEST] <c_14> -f matroska
[21:34:35 CEST] <seasc> c_14, for audio only ?
[21:34:48 CEST] <c_14> why not
[21:34:57 CEST] <c_14> Know of another format that eats 2 streams of raw pcm?
[21:35:09 CEST] <seasc> afiu: he doesnt want to 'switch' streams,but mix them?
[21:35:12 CEST] <seasc> nah
[21:35:19 CEST] <seasc> oh wait, webm? :p but i get you
[21:35:54 CEST] <c_14> Don't think you can put pcm in webm
[21:36:00 CEST] <c_14> Think it only accepts vorbis and opus
[21:36:21 CEST] <jjohn> Doesn't matter. Because ... it does work, but the audio sounds bad again. :)
[21:36:39 CEST] <c_14> meh
[21:36:51 CEST] <c_14> Is the act of having ffmpeg grab more than one alsa stream making it sound bad?
[21:36:55 CEST] <jjohn> Just a "meh"? I'd rather say "bloody hell".
[21:37:11 CEST] <jjohn> I don't know TBH.
[21:37:22 CEST] <seasc> did you upchannel the mono thing yet as source?
[21:37:40 CEST] <c_14> try `ffmpeg -f alsa -i foo -c:a pcm_s16le -f matroska pipe:1 | ffmpeg -i pipe:0 -f alsa -i bar -f matroska -map 0 -map 1 pipe:1 | ffmpeg -i pipe:1 -filter_complex '
[21:37:41 CEST] <jjohn> seasc: opt/local/ffmpeg/bin/ffmpeg -threads 7 -thread_queue_size 4096 -f alsa -ac 2 -i loop_out -f alsa -ac 1 -i microphone -map 0 -map 1 -f matroska -c:a pcm_s16le pipe:1 | /opt/local/ffmpeg/bin/ffmpeg -threads 7 -i pipe:0 -filter_complex "[0:1][0:1]amerge=inputs=2[a1];[0:0]volume=0.20:precision=fixed[a0];[a1]volume=6.0:precision=fixed[a2];[a0][a2]amix[aout]" -map [aout] -c:a libfdk_aac -cutoff 15000 -b:a 1
[21:37:47 CEST] <jjohn> 28k -f flv -y /home/jjohn/test_recording.flv
[21:37:52 CEST] <seasc> or make them as other streams, like dunno if that is any better, wav or mp3?
[21:38:41 CEST] <seasc> its above my understanding, just trying to put some ideas
[21:39:13 CEST] <jjohn> c_14 I'll try it out.
[21:44:24 CEST] <jjohn> Holy shit. Quoting myself here: The quality loss is gone ... but it seems that there is either an echo now, or the stereo channel are not in sync anymore, because I hear the sound from the stereo  source twice.
[21:44:46 CEST] <jjohn> /opt/local/ffmpeg/bin/ffmpeg -threads 7 -thread_queue_size 4096 -f alsa -ac 2 -i loop_out -c:a pcm_s16le -f matroska pipe:1 | /opt/local/ffmpeg/bin/ffmpeg -threads 7 -thread_queue_size 4096  -i pipe:0 -thread_queue_size 4096 -f alsa -ac 1 -i microphone -f matroska -map 0 -map 1 pipe:1 | /opt/local/ffmpeg/bin/ffmpeg -threads 7 -i pipe:0 -filter_complex "[0:1][0:1]amerge=inputs=2[a1];[0:0]volume=0.20:precision
[21:44:52 CEST] <jjohn> =fixed[a0];[a1]volume=6.0:precision=fixed[a2];[a0][a2]amix[aout]" -map [aout] -c:a libfdk_aac -cutoff 15000 -b:a 128k -f flv -y /home/jjohn/test_recording.flv
[21:44:56 CEST] <jjohn> What a monster.
[21:47:42 CEST] <c_14> eeeeh, try using asetpts to set the timestamps to RTCTIME (using time(0) or something)
[21:48:05 CEST] <jjohn> Wha?!
[21:48:07 CEST] <c_14> for each of the 2 processes capturing from alsa on the stream that the process is capturing
[21:48:37 CEST] <c_14> (I'm thinking that the "echo" is coming because one of the two processes is starting slightly delayed from the other so the timestamps don't match up perfectly)
[21:48:53 CEST] <c_14> By swapping the timestamps out with your computer's time, that should go away
[21:48:55 CEST] <c_14> (hopefully)
[21:49:45 CEST] <c_14> basically something like -filter_complex '[0:0]asetpts=time\(0\)[out]' -map '[out]' <- just make sure that you only apply that to the stream you're currently capturing and that the second process maps both stream
[21:49:55 CEST] <c_14> In this case, you could probably go back to your old setup with the fifos though
[21:50:00 CEST] <c_14> That might make it easier
[21:50:06 CEST] <c_14> Since your last command produced the same result
[21:51:35 CEST] <jjohn> So ... only apply the asetpts filter to the ffmpeg process that is mixing both sources ... correct?
[21:51:54 CEST] <c_14> No, to each of the source processes
[21:51:59 CEST] <c_14> The ones capturing from alsa
[21:52:16 CEST] <jjohn> OK, I'll try.
[21:55:48 CEST] <jjohn> >[libfdk_aac @ 0x1ba49c0] Trying to remove 1024 samples, but the queue is empty
[21:55:50 CEST] <jjohn> >[flv @ 0x1ba3ba0] Encoder did not produce proper pts, making some up.
[21:55:55 CEST] <jjohn> >av_interleaved_write_frame(): Immediate exit requested
[21:56:20 CEST] <jjohn> With this command: /opt/local/ffmpeg/bin/ffmpeg -threads 7 -thread_queue_size 4096 -f alsa -ac 2 -i loop_out -c:a pcm_s16le -filter_complex '[0:0]asetpts=time\(0\)[aout]' -map [aout] -f matroska pipe:1 | /opt/local/ffmpeg/bin/ffmpeg -threads 7 -thread_queue_size 4096  -i pipe:0 -thread_queue_size 4096 -f alsa -ac 1 -i microphone -filter_complex '[1:0]asetpts=time\(0\)[aout]' -f matroska -map 0 -map [aout] pi
[21:56:26 CEST] <jjohn> pe:1 | /opt/local/ffmpeg/bin/ffmpeg -threads 7 -i pipe:0 -filter_complex "[0:1][0:1]amerge=inputs=2[a1];[0:0]volume=0.20:precision=fixed[a0];[a1]volume=6.0:precision=fixed[a2];[a0][a2]amix[aout]" -map [aout] -c:a libfdk_aac -cutoff 15000 -b:a 128k -f flv -y /home/jjohn/test_recording.flv
[21:57:01 CEST] <jjohn> ... should we just cancel it off as a bug in ffmpeg? :/
[21:59:37 CEST] <c_14> You'd probably have to (in the third command) find the first common pts and cut all samples before that, then reset the PTS to start from zero
[21:59:39 CEST] <c_14> or something
[22:00:09 CEST] <jjohn> How?
[22:01:45 CEST] <c_14> An excellent question, I was hoping it'd happen automatically but apparently it didn't.
[22:01:57 CEST] <c_14> though
[22:02:11 CEST] <c_14> Can you try outputting to pcm_s16le into a wav file?
[22:02:29 CEST] <c_14> Cause if that doesn't error we could just hang another ffmpeg onto the back
[22:02:50 CEST] <jjohn> After the first or the second process?
[22:03:02 CEST] <c_14> the third one
[22:03:16 CEST] <c_14> so after the second
[22:03:25 CEST] <c_14> But try outputting to a file first
[22:04:26 CEST] <jjohn> I thought wav wouldn't function with two pcm_s16le streams?
[22:04:39 CEST] <jjohn> Shouldn't I use mkv then?
[22:04:41 CEST] <c_14> Well, this is after you mix them
[22:04:46 CEST] <c_14> so there's only 1 stream left
[22:07:14 CEST] <jjohn> Just let me get this straight: first process records stereo, pipes it to second process, second process takes the data from the first process, records mono, saves both streams into a mkv container, and pipes the data to the third process. The third process now should mix them and write them (without encoding, as I always did before) to the disk as a single WAV.
[22:08:10 CEST] <c_14> Well, it's still encoded. It's just encoded as raw pcm
[22:08:32 CEST] Action: c_14 is hoping that that isn't as picky with the timestamps and will just write it out.
[22:08:44 CEST] <jjohn> OK, without lossy encoding then.
[22:14:53 CEST] <jjohn> OK ... I changed it to "/opt/local/ffmpeg/bin/ffmpeg -threads 7 -i pipe:0 -filter_complex "[0:1][0:1]amerge=inputs=2[a1];[0:0]volume=0.20:precision=fixed[a0];[a1]volume=6.0:precision=fixed[a2];[a0][a2]amix[aout]" -map [aout] -c:a pcm_s16le -y /home/jjohn/test_recording.wav" - it maps to "amix -> Stream #0:0 (pcm_s16le)" ... but then it just hangs. The last ffmpeg process just comes to a halt.
[22:15:20 CEST] <jjohn> pressing "q" does not do anything. Pressin CTRL + C gives me "Could not write header for output file #0 (incorrect codec parameters ?): Immediate exit requested".
[22:16:01 CEST] <jjohn> And to be honest - this is just too big a workaround for something as simple as recording two streams and mixing them properly.
[22:16:45 CEST] <c_14> q doesn't do anything because it's already using stdin for input, and yeah no idea why recording from 2 alsa sources causes that quality loss
[22:19:44 CEST] <jjohn> So ... ?
[22:22:35 CEST] <c_14> The only other thing I could put out there would be to do all the mixing alsa side, and then only capture that with ffmpeg
[22:22:40 CEST] <c_14> Something like https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplicationwhilealsoroutingtheaudiotoanoutputdevice
[22:22:51 CEST] <c_14> just with a bit of volume changing first
[22:23:02 CEST] <c_14> hmm
[22:23:14 CEST] <c_14> actually iirc you should just have to change the ttable values
[22:23:32 CEST] <c_14> Though you'd have to duplicate the mono to stereo
[22:26:12 CEST] <jjohn> And what is the common approach to dublicate the channel in ALSA?
[22:27:12 CEST] <c_14> mhm, actually you should only have to modify that ttable and the slaves.a.channels a bit
[22:27:20 CEST] <c_14> sec
[22:29:58 CEST] <c_14> http://pb.c-14.de/t/kng.CHYLtA
[22:30:25 CEST] <c_14> except I just deleted the wrong lines
[22:30:36 CEST] <c_14> http://pb.c-14.de/t/kng.ZG5sSg
[22:31:17 CEST] <jjohn> .de domain? Also auch ein Deutscher? ;)
[22:32:03 CEST] <c_14> Nur wenn keiner hinschaut.
[22:51:40 CEST] <jjohn> Hm ... that config just gives me the error messages "Invalid or missing schannel for channel 0" and "cannot open audio device multi (Invalid argument)".
[22:56:44 CEST] <c_14> eh, right
[22:56:47 CEST] <c_14> got the order mixed up
[22:57:06 CEST] <c_14> at least I think I ded
[22:57:08 CEST] <c_14> *did
[22:57:29 CEST] <c_14> swap all the .numa.numb in the ttable so its .numb.numa
[22:58:54 CEST] <jjohn> table.0.0 6; ttable.0.1 6; ttable.2.0 0.2; ttable.3.1 0.2; ? Doesn't work either.
[23:00:36 CEST] <c_14> Hmm, try asking #alsa maybe. My alsa really isn't up to par.
[00:00:00 CEST] --- Thu May  7 2015