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

[burek]

[00:01:40 CEST] <kyleogrg> I downloaded a .tar.gz of the latest ffmpeg source.  I have it in a virtual linux machine, and I want to compile it *for windows*
[00:02:02 CEST] <kyleogrg> I'm looking at https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[00:02:25 CEST] <kyleogrg> And it wants me to compile a cross-compiler
[00:02:27 CEST] <kepstin-laptop> kyleogrg, you want to be looking at https://trac.ffmpeg.org/wiki/CompilationGuide/CrossCompilingForWindows
[00:02:45 CEST] <kepstin-laptop> should be able to use the packaged mingw64 stuff in ubuntu
[00:02:56 CEST] <kyleogrg> sorry, that's actually what i meant to paste
[00:03:24 CEST] <DusteD> kyleogrg, you usually does not have to compile the cross compiler for windows yourself, mingw for 64 or 32 bit windows should be available in your linux distributions package repository
[00:03:33 CEST] <kyleogrg> hmmm
[00:03:35 CEST] <DusteD> So slow I am
[00:03:54 CEST] <kyleogrg> this is fairly complicated to me
[00:04:33 CEST] <kyleogrg> so since i'm using linux mint (which is ubuntu based), i don't need to set up anything with mingw64?
[00:04:46 CEST] <seasc> c_14, nope that doesnt work, ALSA is unable to open slave... ??
[00:04:51 CEST] <kepstin-laptop> kyleogrg, you'll have to install it, it's not installed by default.
[00:04:58 CEST] <kyleogrg> ok, how?
[00:05:25 CEST] <c_14> seasc: Is an X program accessing alsa perchance?
[00:05:34 CEST] <kepstin-laptop> I think it should be enough to install either mingw-w64-x86-64-dev or mingw-w64-i686-dev for win64 or win32 respectively
[00:06:02 CEST] <kepstin-laptop> maybe just the 'mingw-w64' metapackage is enough
[00:07:04 CEST] <seasc> c_14, root ps shows only: /usr/sbin/alsactl ...
[00:07:05 CEST] <kyleogrg> ok, thanks.  trying mingw-w64-x86-64-dev
[00:07:43 CEST] <c_14> seasc: lsof /dev/snd/pcm*
[00:08:32 CEST] <seasc> c_14, n/m/ i assume i borked my alsa build during my live test of a full ffmpeg re-build... i've got several alsamixer issues anyway, probably the same cause
[00:08:39 CEST] <seasc> thank you
[00:09:16 CEST] <kyleogrg> ok, got mingw-w64-x86-64-dev!
[00:09:44 CEST] <kyleogrg> after that, how can i cross-compile for windows?
[00:10:11 CEST] <kepstin-laptop> kyleogrg, read the section of the wiki page saying "compile ffmpeg" :)
[00:10:13 CEST] <kyleogrg> i'm hoping to enable 10-bit libx265 and libfdk_aac
[00:10:28 CEST] <kepstin-laptop> if you want x265 and stuff it's more complicated :/
[00:11:20 CEST] <kyleogrg> hmm, how much more complicated?  I'm willing to try, if you have the time
[00:11:22 CEST] <seasc> oh ya, writing at a script (linux) to build ffmpeg with several features... for 3 weeks now...
[00:11:24 CEST] <kyleogrg> otherwise, it's fine
[00:11:36 CEST] <seasc> good luck :)
[00:11:53 CEST] <kepstin-laptop> kyleogrg, each of the dependency packages has to be crosscompiled separately (and their build systems are all different, so it's different commands for each)
[00:12:13 CEST] <kepstin-laptop> then they have to be "installed", best to use some subdirectory of your home directory for that
[00:12:35 CEST] <kepstin-laptop> then set the PKG_CONFIG_PATH to find the pkg-config files for the dependencies, and try building ffmpeg with the appropriate options
[00:13:00 CEST] <kyleogrg> ok wow
[00:13:09 CEST] <kyleogrg> this is not for beginners
[00:13:29 CEST] <kyleogrg> still, if i put the time into it, i bet i can do it
[00:13:43 CEST] <kyleogrg> I just wish it was legal to download a nonfree ffmpeg
[00:14:46 CEST] <kyleogrg> but the newest ffmpeg comes with libx265 already, right?
[00:14:48 CEST] <kepstin-laptop> it's not so much illegal to download as illegal for someone to distribute to other people. but still, yeah.
[00:15:15 CEST] <kepstin-laptop> it's kind of annoying since it's all open-source software, just with incompatible licenses.
[00:15:39 CEST] <kyleogrg> what if i asked a friend to compile it for me, then send it to me?  is that considered distribution?
[00:16:26 CEST] <kyleogrg> haha, or am i splitting hairs?
[00:16:27 CEST] <kepstin-laptop> ask a lawyer.
[00:16:32 CEST] <kyleogrg> yeah.
[00:16:35 CEST] <DusteD> kyleogrg, why not just download the binaries from the website ?
[00:17:02 CEST] <kyleogrg> they don't have libfdk_aac nor 10-bit capability for libx265.
[00:17:12 CEST] <DusteD> oh, I see.
[00:17:24 CEST] <kepstin-laptop> is there some reason you *really* need aac?
[00:18:00 CEST] <kyleogrg> hmm, it's just the best version
[00:18:01 CEST] <kepstin-laptop> i mean, if you're just archiving this for yourself, you could use opus or something, or even just mp3 at a higher bitrate.
[00:18:08 CEST] <kyleogrg> right
[00:18:26 CEST] <kyleogrg> what about 10-bit?  i think it's supposed to be higher quality at the same bitrate.
[00:19:22 CEST] <DusteD> How could it be? :)
[00:19:29 CEST] <kyleogrg> i dunno
[00:19:30 CEST] <DusteD> I guess it'd be higher quality at a higher bitrate though
[00:19:45 CEST] <kyleogrg> someone said it was better quality
[00:19:52 CEST] <kyleogrg> maybe not, though?
[00:19:54 CEST] <seasc> with x265 you get better quality for same bitrate as x264
[00:20:24 CEST] <kyleogrg> sure, i know
[00:20:28 CEST] <seasc> otherwise as DusteD said, thats simply different mechanics
[00:21:06 CEST] <kyleogrg> so 10-bit won't necessarily provide a smaller file size?
[00:21:17 CEST] <kyleogrg> what do you mean by different mechanics?
[00:21:31 CEST] <kepstin-laptop> in theory, the 10bit stuff can give better encoding efficiency, depends on the source material. IIRC, it's because there's less accuracy loss in predicted frames.
[00:21:46 CEST] <c_14> You also lose less to quantization
[00:21:50 CEST] <kepstin-laptop> also, it makes gradients encode without banding, yeah
[00:22:13 CEST] <kepstin-laptop> ^ a visual sideeffect of the less quantization loss ;)
[00:22:24 CEST] <kyleogrg> Say my source video is NTSC DV-AVI (from a DV camera)
[00:22:44 CEST] <kyleogrg> Will there be a noticable visual improvement with 10-bit?
[00:23:16 CEST] <kyleogrg> or could that banding issue only show up in HD video, for instance...?
[00:23:31 CEST] <kepstin-laptop> kyleogrg, probably not, particularly with sd resolutions and real video rather than artificial/animated.
[00:24:01 CEST] <kyleogrg> yeah....
[00:24:03 CEST] <kyleogrg> ok then
[00:24:55 CEST] <kepstin-laptop> like, if your video is somewhat noisy and you're encoding with enough bitrate to keep the noise, then you probably don't care much about the small gain that 10bit might give you.
[00:25:31 CEST] <kepstin-laptop> although, if you could do it easily, you might as well
[00:25:36 CEST] <kyleogrg> right
[00:25:49 CEST] <kyleogrg> i would like to know how to build ffmpeg anyway
[00:25:53 CEST] <kyleogrg> i may just invest the time
[00:26:13 CEST] <kyleogrg> it's just surprisingly complicated
[00:26:43 CEST] <kyleogrg> it seems the simplest way is to cross-compile for windows.  do you agree?
[00:27:19 CEST] <kepstin-laptop> thats how i generally do it, but mostly because I don't like using windows for development.
[00:28:23 CEST] <kepstin-laptop> (as an amusing note, I found that the 'gdigrab' screen capture stuff is *faster* in wine on linux than on real windows when I was working on that)
[00:28:37 CEST] <kyleogrg> hahaha
[00:28:39 CEST] <kyleogrg> strange
[00:34:24 CEST] <kyleogrg> builds.x265.eu
[00:35:06 CEST] <kyleogrg> what does 64Bit-16bit mean?
[00:35:28 CEST] <c_14> Probably a 64-bit build that encodes 16bit video
[00:36:00 CEST] <c_14> The 64-bit being the processer architecture and the 16 bit being the video bit-depth
[00:36:05 CEST] <kyleogrg> ok, but i thought the options were either 8-bit or 10-bit
[00:37:41 CEST] <kyleogrg> so is 16-bit "better"?
[00:39:05 CEST] <kyleogrg> yeah.. i think "16-bit" uses 10 bits per pixel
[00:39:14 CEST] <c_14> x264 has 8 and 10 not sure what x265 has
[00:39:19 CEST] <c_14> Haven't built it in a while.
[00:39:21 CEST] <kyleogrg> so i *think* it's the same as 10-but
[00:39:22 CEST] <kyleogrg> bit
[00:39:23 CEST] <kyleogrg> sure
[00:39:28 CEST] <klaxa> i'm pretty sure 8, 10, 12 and 14 so far
[00:39:32 CEST] <klaxa> never heard of 16
[00:39:52 CEST] <klaxa> but i have no source for that handy
[00:40:03 CEST] <c_14> I mean, technically the more bits the less loss during quantization, but I don't know how well/far that scales.
[00:40:30 CEST] <klaxa> remove 14 and add 16 https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles
[00:40:52 CEST] <kyleogrg> huh
[00:41:09 CEST] <kyleogrg> so on that site, 16-bit probably really is 16-bit
[00:41:43 CEST] <klaxa> i can imagine that 8-bit has some whacky hacks to be faster
[00:42:17 CEST] <kyleogrg> yeah
[00:43:10 CEST] <kyleogrg> supposing i just encoded an x265 stream with the x265 binary...
[00:43:24 CEST] <kyleogrg> i wonder if it uses all cpu cores
[00:44:24 CEST] <c_14> iirc x265 threads
[00:44:38 CEST] <c_14> doesn't really make it fast though
[00:44:52 CEST] <kyleogrg> but technically a little faster
[00:44:53 CEST] <kyleogrg> right?
[00:45:20 CEST] <kyleogrg> i mean, maybe like 2 frames a second instead of 0.25 frames a second
[00:45:21 CEST] <kyleogrg> haha
[00:46:12 CEST] <c_14> Haven't tested in a whiiile, but last time I tried I couldn't get 1fps on my system. Granted I think I used profile veryslow
[00:47:15 CEST] <kyleogrg> yeah
[00:47:54 CEST] <kyleogrg> if i could find a simple way to encode the audio with libfdk_acc, i could mux it with the x265 streams made with this binary
[00:49:29 CEST] <kepstin-laptop> if you're running windows anyways and *really* want aac, you could even do something as silly as encode it with itunes.
[00:50:20 CEST] <kyleogrg> hmm
[00:50:35 CEST] <kyleogrg> well at any rate, the x265 encoding is by far the slowest part of the process
[00:50:49 CEST] <kyleogrg> very interesting
[00:50:52 CEST] <kyleogrg> i have to go now
[00:50:54 CEST] <kepstin-laptop> or you could just use opus, which has very comparable quality to aac.
[00:50:55 CEST] <kyleogrg> may be back later
[00:51:03 CEST] <kyleogrg> hmm all rightyy
[00:51:28 CEST] <klaxa> isn't opus supposedly even "better" than aac?
[00:51:34 CEST] <kepstin-laptop> if you're doing 10bit x265 it's not like you're worried about whether other people can decode it anyways
[00:51:44 CEST] <kyleogrg> yes, good point
[00:51:55 CEST] <kyleogrg> klaxa: do some say it's better?
[00:52:06 CEST] <kepstin-laptop> klaxa, it's very close; but most of the comparisons were done at pretty low bitrate.
[00:52:27 CEST] Action: c_14 compared aac and opus at 8k today
[00:52:28 CEST] <klaxa> most comparisons are probably also performed by opus advocates
[00:52:29 CEST] <c_14> opus won
[00:52:31 CEST] <c_14> my ears hurt
[00:52:39 CEST] <kyleogrg> okay
[00:52:44 CEST] <kyleogrg> well gotta go
[00:52:45 CEST] <kepstin-laptop> I mean, once you hit >128kbit in either opus or aac stereo, it's hard for a human to tell them appart from lossless either way...
[00:52:47 CEST] <c_14> But at higher bitrates there isn't _that_ much difference.
[00:52:50 CEST] <klaxa> well here's a chart http://www.opus-codec.org/comparison/quality.svg
[00:53:06 CEST] <kyleogrg> thanks
[00:53:07 CEST] <klaxa> aac and opus are pretty close
[00:53:11 CEST] <kyleogrg> see ya later, bye
[00:54:50 CEST] <klaxa> still somewhat frustrated google said android 5.x has opus support but their MediaPlayer api doesn't play opus files
[00:55:19 CEST] <kepstin-laptop> hmm. looks like most of the webrtc streams I'm looking at are around 40-50kbit mono, which is ridiculously high quality for a phone call :)
[00:55:42 CEST] <kepstin-laptop> klaxa, i guess they support the opus format but not the ogg opus container spec? :/
[00:56:08 CEST] <klaxa> you mean i could try to put opus in ogg?
[00:56:21 CEST] <klaxa> i haven't tried that yet, nothing to lose really
[00:56:22 CEST] <kepstin-laptop> klaxa, a standalone ".opus" file is opus in ogg.
[00:56:28 CEST] <klaxa> oh
[00:56:43 CEST] <klaxa> what
[00:56:47 CEST] <klaxa> why don't they support that
[00:56:53 CEST] <kepstin-laptop> no idea.
[00:57:04 CEST] <kepstin-laptop> the spec for it isn't final tho, it's still a draft :/
[00:57:18 CEST] <kepstin-laptop> but the basic stuff isn't gonna change at this point
[00:57:54 CEST] <benbro1> can I use ffmpeg to write a C application that mixes live audio and video RTMP streams?
[00:58:07 CEST] <benbro1> the streams will change dynimcally in a video conference
[00:58:59 CEST] <kepstin-laptop> benbro1, you could use ffmpeg to handle portions of the work required, but you'll obviously have to write some of your own stuff too.
[00:59:15 CEST] <benbro1> kepstin-laptop: how hard is it?
[00:59:32 CEST] <benbro1> I was trying to use gstreamer that is supposed to be good at this stuff
[00:59:40 CEST] <benbro1> but keep running into issues
[00:59:45 CEST] <kepstin-laptop> that's one of those "if you have to ask, then..." questions.
[00:59:49 CEST] <benbro1> so I thought maybe I can go to a lower level
[01:00:17 CEST] <benbro1> I mean, do I need to understand about threads, mutex, queues, buffering...
[01:00:32 CEST] <benbro1> or does ffmpeg have tools that do it for me
[01:01:47 CEST] <kepstin-laptop> my understanding (i could be wrong) is that the ffmpeg filter chain stuff doesn't handle dynamic rearrangement well, so you'd end up probably using ffmpeg to do the decoding/encoding and streaming, and you'd do the actual video mixing in your app.
[01:02:34 CEST] <benbro1> so I'll need to handle buffers, queues, threads, synching....
[01:02:57 CEST] <kepstin-laptop> using ffmpeg as a library is quite a bit different from using the command line tool; the tool handles a lot of things that you have to do yourself if you use the libraries.
[01:03:47 CEST] <benbro1> it's such a powerfull tool that I would expect it to expose this power to us in a library :)
[01:07:23 CEST] <klaxa> oh, looks like android supports opus in matroska
[01:07:34 CEST] <klaxa> what the actual fuck
[01:08:45 CEST] <kepstin-laptop> lol
[01:08:53 CEST] <kepstin-laptop> does it work if you rename your .opus file to .ogg?
[01:09:16 CEST] <klaxa> rename or remux? i mean ffprobe reports it as ogg anyway
[01:09:28 CEST] <c_14> rename, probably
[01:09:28 CEST] <kepstin-laptop> the matroska mapping for opus was under even more flux than the ogg mapping, since they had to add new stuff to matroska to handle the preroll required on seeking
[01:09:59 CEST] <klaxa> renaming opus to ogg does not work
[01:10:24 CEST] <kepstin-laptop> I think they might have put the opus in matroska stuff because they want to use opus+vp9 in the next webm version.
[01:11:27 CEST] <klaxa> well it's not like i really care about containers as much as codecs
[01:11:44 CEST] <klaxa> i'll just use matroska for the time being
[01:12:23 CEST] <kepstin-laptop> I hope when they do make a new version of webm, they call it something different, otherwise people will be going "it's a webm, and this player says it does webm, why doesn't it work?"
[01:13:00 CEST] <kepstin-laptop> half the point of the webm standard was to limit the codecs so much the files would be pretty much guaranteed to play.
[01:13:43 CEST] <klaxa> mkv is 50 kb larger than ogg
[01:13:47 CEST] <klaxa> i can live with that
[01:14:12 CEST] <klaxa> >Duration: 00:03:37.14, start: 0.000000, bitrate: 126 kb/s
[01:14:25 CEST] <klaxa> as a scale reference
[01:14:47 CEST] <klaxa> >3475550 Apr 21 01:10 test.mkv
[01:31:10 CEST] <hroi> hi
[01:31:47 CEST] <hroi> someone suggested I use ffmpeg to encode my avi raw file over to H264 using the CRF option
[01:32:08 CEST] <hroi> the suggestion is that the resulting file will play more smoothly on video players and youtube
[01:33:09 CEST] <klaxa> youtube will re-encode your video multiple times anyway
[01:33:43 CEST] <hroi> klaxa, ok, so essentially throwing the raw at youtube might be the best thing anyway
[01:34:00 CEST] <hroi> klaxa,  I hear that sending H264 to youtube will leave the encoding unchanged
[01:34:11 CEST] <klaxa> they encoded my h264 videos anyway
[01:34:13 CEST] <hroi> that must be a misunderstanding
[01:34:21 CEST] <hroi> klaxa, ok.
[01:34:46 CEST] <hroi> klaxa, hmm... so sending the raw to youtube will probably ensure best results by far
[01:34:48 CEST] <c_14> As long as the FrankenFFmpeg that Youtube uses can decode the raw, that would probably be the best bet, yes.
[01:35:10 CEST] <hroi> klaxa, c_14 :  thanks for clearing that up
[01:35:11 CEST] <klaxa> if you want to save bandwith you might also want to consider using a lossless format
[01:35:18 CEST] <klaxa> but that will take a while to encode maybe
[01:35:43 CEST] <hroi> my file is only 3GB in avi raw, so probably youtube wont complain
[01:37:00 CEST] <hroi> insidentally... my raw is 3GB for 50s of video, but on my current linux install 4 core phenom II processor, vlc does not keep up with buffering the video
[01:37:21 CEST] <c_14> It might be IO
[01:37:24 CEST] <hroi> maybe that is expected, but I was hoping my computer was more powerful than that
[01:38:46 CEST] <klaxa> it's like 500 mbps
[01:38:51 CEST] <hroi> c_14, I think it is maybe not disk IO because vlc buffers up to 3GB of memory usage
[01:39:00 CEST] <klaxa> how fast is ram?
[01:39:05 CEST] <hroi> lol
[01:39:14 CEST] <klaxa> actually should be faster than 500 mbps
[01:39:15 CEST] <hroi> 1.3GHz
[01:39:34 CEST] <hroi> dual channel 64bit data bus
[01:39:39 CEST] <klaxa> i would still guess it's io
[01:39:43 CEST] <hroi> or is it actually 128bit?
[01:40:43 CEST] <hroi> klaxa, yeah seems like that -- oh well.   I should run some benchmarks on my linux to test if all is ok
[01:40:58 CEST] <hroi> thanks for advice!
[01:41:06 CEST] <c_14> If it's really 3GiB for 50s, you can always just encode to a lossless format.
[01:41:18 CEST] <c_14> s/format/codec/
[04:31:59 CEST] <kyleogrg> yo
[04:32:04 CEST] <kyleogrg> help me out here please
[04:32:07 CEST] <kyleogrg> https://web.archive.org/web/20140819201525/http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html
[04:32:55 CEST] <kyleogrg> My processor is: Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz  2.20Ghz
[04:33:28 CEST] <kyleogrg> Basically I can choose one of these presets in my ffmpeg build
[04:34:08 CEST] <kyleogrg> Here's the ffmpeg autobuild tool I'm using: http://taer-naguur.blogspot.com/2013/10/ffmpeg-autobuild-tool-x64.html
[04:34:35 CEST] <kyleogrg> And I have the option to optimize it by giving it a custom cpu type... any input?  thanks
[09:57:11 CEST] <livee> hello chan
[09:57:27 CEST] <livee> still here with an audio/video desync
[09:57:43 CEST] <livee> just to know if anyone would know how to help me
[09:58:21 CEST] <livee> i give the link of the forum subject i posted but i try here because last time it was fast
[09:58:33 CEST] <livee> sorry for my english
[09:58:34 CEST] <livee> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=2056
[10:22:25 CEST] <livee> up
[12:11:46 CEST] <rszeno> i'm not sure if this is the right place to ask but i will, :)
[12:13:26 CEST] <rszeno> i use ffmpeg to extract the video part from a movie and is bigger then the original. Is not compressed?
[12:32:08 CEST] <BtbN> If you re-encode with a "higher" quality or use a less efficient container for the output, that's entirely possible.
[12:33:19 CEST] <rszeno> i used only -sameq and -an flags
[12:34:44 CEST] <rszeno> i use the libav port from debian in fact. From this point of view is any difference?
[12:34:58 CEST] <BtbN> From this point of view you're in the wrong channel.
[12:36:02 CEST] <rszeno> if ffmpeg, right? i didn't changed the name and actualy i found the difference accidentaly
[12:37:36 CEST] <rszeno> but the question remain. if i use ffmeg and not libav, is any difference in size?
[12:40:10 CEST] <BtbN> If you don't tell it to stream-copy, it will allways re-encode. And without furhter parameters, use the default ones, which might or might not result in a higher bitrate.
[12:41:33 CEST] <rszeno> ok, thank you BtbN, :)
[14:40:46 CEST] <ph8> hey all, i'm calling ffprobe from scala and getting an exit code of 1 - with no stderr and stdout just as {} - any idea how i can try and diagnose that? If i run the command from the CLI it's fine which is weird
[14:43:20 CEST] <spaam> maybe you didnt sent any input to ffprobe ?
[14:45:45 CEST] <cowai> Is it possible to apply fade in and fade out, video and audio, with stream copy on the parts of the video which are not edited?
[14:46:00 CEST] <cowai> If not, can I do it in 3-4 commands and still be frame accurate?
[14:50:56 CEST] <ph8> spaam, the command is: /usr/bin/ffprobe -v quiet -print_format json -show_format -show_streams "/home/george/repos/myproject/target/scala-2.11/test-classes/asset/testVideo.mp4"
[14:51:10 CEST] <ph8> which works fine from the cmd line but not when executed in scala, it claims an error code of 1 came back
[14:51:17 CEST] <ph8> and an output of {} which at least looks ffmpeg-y
[14:51:25 CEST] <ph8> i just have no idea how to debug any further
[14:51:49 CEST] <ph8> hahaaha got it
[14:51:52 CEST] <ph8> removing -v quiet helped :)
[14:51:57 CEST] <spaam> :)
[14:52:03 CEST] <ph8> it doesn't appear to like the quotes in the directory
[14:52:05 CEST] <ph8> which is mega odd
[15:08:58 CEST] <ph8> what i'm finding odd now is that ffmpeg always outputs a header to stderr
[15:08:59 CEST] <ph8> even on success
[15:11:09 CEST] <urmumstty> ffmpeg shits almost everything (everything?) to stderr
[15:11:27 CEST] <urmumstty> probably following the idea that there is no point in putting status information into stdout
[15:12:11 CEST] <urmumstty> if you were piping video data out of ffmpeg you wouldn't want status info coming through
[15:12:49 CEST] <seasc> urmumstty, try: ffmpeg -v quiet ....
[15:12:59 CEST] <urmumstty> seasc: was responding to ph8
[15:13:12 CEST] <seasc> erm, me too i guess :p
[15:13:58 CEST] <seasc> you want a silent ffmpeg with only the output you need/want? (on linux??)
[15:14:01 CEST] <seasc> @ ph8
[15:14:27 CEST] <ph8> thanks
[15:14:30 CEST] <ph8> i found a weird thing with ffmpeg
[15:14:51 CEST] <ph8> sorry with scala
[15:15:03 CEST] <ph8> and the way it treats quotes in command lines
[15:15:15 CEST] <ph8> those double quotes were really confusing scala but obviously ran fine from my bash prompt
[15:29:02 CEST] <__deivid__> Hi
[15:32:23 CEST] <seasc> hi
[15:39:29 CEST] <neXyon> hi
[15:40:57 CEST] <neXyon> does -qp only work for h264 or other video codecs as well?
[16:02:24 CEST] <t4nk264> How to deal with "double audio" on TGL's tops.
[16:02:36 CEST] <t4nk264> Can you please point out some links
[19:31:30 CEST] <kyleogrg> hey
[19:31:56 CEST] <kyleogrg> I have an ffmpeg command ready to convert avis to mp4s
[19:32:12 CEST] <kyleogrg> now i'd like to generate this command for every avi in a folder
[19:33:09 CEST] <kyleogrg> let's say the command is: ffmpeg.exe -i myfile.avi -c:v libx264 -c:a libfdk_aac myfile.mp4
[19:33:42 CEST] <kyleogrg> How can I change the command to take every avi and output an mp4 with the same name?  thanks
[19:55:22 CEST] <RobotsOnDrugs> shells have syntax for that kind of thing
[19:55:57 CEST] <kyleogrg> this looks helpful: http://forum.videohelp.com/threads/356314-How-to-batch-convert-multiplex-any-files-with-ffmpeg
[21:04:59 CEST] <Fyr> guys, I need assistance with LameXP.
[21:05:46 CEST] <Fyr> does anybody know something about this tool?
[21:30:09 CEST] <Fyr> it happened that my question is really about refalac/qaac, not about lamexp.
[21:56:04 CEST] <deb_> hi
[00:00:00 CEST] --- Wed Apr 22 2015