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

[burek]

[00:04:33 CET] <smirky> great
[00:38:59 CET] <debianuser> dsl420: Yeah, but what makes it limit to 15 fps? Is that a CPU limit? It's not for me. I have 4 cores, and ffmpeg only uses one core with that command. Also try `./ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -t 30 -f null -` - it easily gives 60fps for me taking just 5% CPU.
[00:45:31 CET] <dsl420> debianuser, did you try to set --threads?
[00:46:52 CET] <m_wynn> I'm using ffmpeg's Windows builds (unfortunately), and it is putting an "Unlicensed Copy" logo in the top right corner of my video.  Any clue how this could happen?  I thought ffmpeg was free.
[00:47:00 CET] <dsl420> -threads even
[00:47:16 CET] <c_14> m_wynn: Which builds?
[00:47:18 CET] <c_14> Where did you get them?
[00:47:34 CET] <m_wynn> c_14: ffmpeg.org links to http://ffmpeg.zeranoe.com/builds/
[00:47:55 CET] <c_14> Really now, they shouldn't be doing that.
[00:47:58 CET] <c_14> What's your commandline?
[00:48:43 CET] <m_wynn> ffmpeg -rt buffsize 2000M -f dshow -i video="IP Camera [JPEG/MJPEG]
[00:48:53 CET] <BtbN> That logo propably comes from your IP Camera thing.
[00:49:02 CET] <c_14> probably
[00:49:14 CET] <m_wynn> I'm not having this issue with Adobe Flash Media Live Encoder
[00:49:29 CET] <BtbN> ffmpeg does not add watermarks unless you tell it to do so
[00:49:41 CET] <c_14> do you have a random video lying around that you can use 'ffmpeg -i file outfile.mkv' on to test?
[00:50:06 CET] <m_wynn> perhaps.  I'm teamviewered in to a windows machine, so give me a second
[00:51:04 CET] <debianuser> dsl420: yes, tried "-threads 0" and "-threads 4" - still same 100% cpu, i.e. one core. That's why I asked if it works for anyone at all, to check if it's my issue only, or ffmpeg bug somewhere :)
[00:51:35 CET] <dsl420> try -threads 8 or 16
[00:55:29 CET] <m_wynn> Okay, there was no watermark on this.  I wonder how Adobe is able to get around it.  Could it be dshow?
[00:55:31 CET] <debianuser> dsl420: Just tried, ffmpeg output: http://pastebin.com/KWVMRnyb Same ~100% cpu and 39fps instead of 60. :(
[00:55:43 CET] <BtbN> debianuser, have you tried xcbgrab instead? Shouldn't change much, but worth a try.
[00:56:29 CET] <debianuser> BtbN: Unknown input format: 'xcbgrab' :( (static git build from http://johnvansickle.com/ffmpeg/)
[00:58:32 CET] <debianuser> m_wynn: Do you have other devices for capture? `ffmpeg -list_devices true -f dshow -i dummy`
[01:01:12 CET] <m_wynn> debianuser: unfortunately none that work.
[01:04:10 CET] <m_wynn> I wouldn't be surprised if directshow is putting that there.  Maybe Windows isn't genuine.
[01:14:32 CET] <m_wynn> nvm, it's the camera's software
[02:07:21 CET] <Jonas__> how do I use the -thread_message_queue option=
[02:07:35 CET] <Jonas__> wherever I put it, it complains about it being unrecognized :(
[02:40:39 CET] <Jonas__> duh, the option was -message_queue_size :)
[03:03:19 CET] <edman007> does ffmpeg support openMAX? and if not has anyone actually looked into it? I'm thinking of writing an app that will require openMAX, and I'm wondering how much work that might be, and if it would be worth it to just try writing an ffmpeg driver for it if not already done...
[03:06:24 CET] <edman007> actually...that's probably more of a devel question, I'll ask there...
[09:20:09 CET] <koz_desktop> I would like to use ffmpeg to convert an mkv containing AVC and AAC into a webm containing VP9 and Opus. What command should I use?
[09:33:23 CET] <sfan5> koz_desktop: ffmpeg -i file.mkv -c:v libvpx-vp9 -c:a libopus -b:a 128k out.webm
[09:33:47 CET] <koz_desktop> sfan5: Thanks for that!
[09:34:26 CET] <sfan5> koz_desktop: you need to set a bitrate for vp9 though, i did not find a reference for vp9 but here is one for vp8 https://trac.ffmpeg.org/wiki/Encode/VP8
[09:36:22 CET] <koz_desktop> I'll test with the settings given there and see how it looks.
[09:36:25 CET] <koz_desktop> Thanks for all your help.
[09:36:51 CET] <koz_desktop> Is there a way I can tell ffmpeg to use both of my cores?
[09:36:56 CET] <koz_desktop> It seems to only be using one of them
[10:14:31 CET] <RobotsOnDrugs> koz_desktop: perhaps the video codec implementation doesn't support multithreading very well or at all
[10:14:52 CET] <koz_desktop> RobotsOnDrugs: I see.
[10:15:00 CET] <RobotsOnDrugs> unlikely to be the fault of ffmpeg itself (i can peg all cores with it using libx264)
[10:15:39 CET] <koz_desktop> I believe there's a command-line argument I have to pass to it for it to use multiple threads, right?
[10:16:54 CET] <RobotsOnDrugs> if there is, it's specific to the encoding library
[10:17:07 CET] <koz_desktop> RobotsOnDrugs: I see. Thanks.
[10:17:29 CET] <RobotsOnDrugs> i don't pass any extra flags for libx264
[11:55:02 CET] <galex-713> When I play some video (which was huge before I lower bitrate with ffmpeg), mplayer say « YOUR SYSTEM IS TOO SLOW TO PLAY THIS », even as I keep reducing the bitrate& what other factor could make expansive the reading of this video?
[11:56:39 CET] <relaxed> galex-713: how are you encoding the video?
[11:56:50 CET] <galex-713> With the two-pass thing
[11:57:01 CET] <galex-713> Im just lowering the bitrate for the moment
[11:57:24 CET] <relaxed> using libx264?
[11:57:35 CET] <galex-713> yes
[11:57:43 CET] <galex-713> Originally its a .mov
[11:58:13 CET] <relaxed> add -tune fastdecode
[11:58:28 CET] <galex-713> ok thx
[11:58:54 CET] <relaxed> along with -profile:v main -level 31
[12:00:35 CET] <galex-713> what does this mean?
[12:04:56 CET] <relaxed> http://en.wikibooks.org/wiki/MeGUI/x264_Settings
[12:06:59 CET] <relaxed> actually, https://trac.ffmpeg.org/wiki/Encode/H.264
[12:42:32 CET] <RobotsOnDrugs> galex-713: what gave you the idea that bitrate would affect decoding speed?
[12:44:08 CET] <RobotsOnDrugs> unless disk i/o speed is incredibly bad or the bitrate is insanely high, the effect is insignificant
[12:45:17 CET] <RobotsOnDrugs> relaxed: nice, i never knew that page was on wikibooks
[12:45:29 CET] <RobotsOnDrugs> the original isn't always up
[12:46:42 CET] <galex-713> RobotsOnDrugs: I dont know, more data to process
[13:37:41 CET] <galex-713> relaxed: it says: x264 [error]: baseline profile doesn't support 4:2:2
[13:37:41 CET] <galex-713> [libx264 @ 0xad3eaa0] Error setting profile baseline.
[13:37:41 CET] <galex-713>  
[13:37:49 CET] <galex-713> err, *main
[13:38:03 CET] <galex-713> (I tested baseline just after, but main gives the same error
[13:38:04 CET] <galex-713> )
[13:38:40 CET] <Mavrik> and?
[13:38:47 CET] <Mavrik> The message is pretty clear :)
[13:38:51 CET] <galex-713> ?
[13:38:53 CET] <galex-713> So what?
[13:39:08 CET] <galex-713> I cant do what he said& so I cant read this video using ffmpeg?
[13:39:20 CET] <galex-713> I dont even know what is 4:2.
[13:39:23 CET] <galex-713> *4:2:2
[13:40:01 CET] <Mavrik> what do you mean read.
[13:40:09 CET] <Mavrik> You're trying to encode a video into baseline H.264 profile
[13:40:15 CET] <Mavrik> which does not allow YUV 4:2:2 video
[13:40:23 CET] <Mavrik> ffmpeg is telling you he can't do what it wants
[13:40:38 CET] <galex-713> So what should I do?
[13:40:46 CET] <galex-713> (to get a smaller and readable video)
[13:46:40 CET] <galex-713> I have to go, sorry, Ill come back ^^
[14:46:24 CET] <SmokedCheese> sup gyus
[14:46:33 CET] <SmokedCheese> there is any "profiler" for ffmpeg?
[14:50:48 CET] <SmokedCheese> reencode of live hls stream is slower than reencode of offline file and uses less cpu
[14:50:51 CET] <SmokedCheese> why?
[14:52:39 CET] <SmokedCheese> (if w/ downscale less then stream fps)
[14:53:36 CET] <SmokedCheese> cpu AMD Opteron 63xx class CPU
[15:40:05 CET] <wolfman2000> Morning/afternoon. I'm on a team that is using (allegedly) version 2.1.3 of ffmpeg. I know 2.6 is out, but I think we are somewhat afraid to upgrade/change part of the code. Is there a way to cleanly check out that specific version for build automation purposes? I don't like how we presently keep that source code in our repo.
[15:40:54 CET] <azk> You could check out the commits by tag.
[15:41:01 CET] <azk> checkout*
[15:42:03 CET] <wolfman2000> Are you still using subversion like you were previously, or have you switched?
[15:44:22 CET] <wolfman2000> nevermind, found that out. git now...time to hope the tag I want is in there
[15:44:47 CET] <azk> Oh sorry, I meant git tag.
[15:45:18 CET] <wolfman2000> Forgive me here. I thought our team was still using some very old 0.4.8-ish build
[15:47:09 CET] <azk> The oldest I can see in git tag is n0.5.10
[15:48:00 CET] Action: wolfman2000 attempsts to compile ffmpeg on that build manually before trying to integrate it in cmake
[15:48:37 CET] <azk> Godspeed.
[15:52:58 CET] <wolfman2000> question. I know what YASM is: it's an assembly program. What is the STRIP program I'm seeing in the compilation output? As well as AR?
[15:53:34 CET] <wolfman2000> ls
[15:53:34 CET] <c_14> strip removes debugging information
[15:53:40 CET] <wolfman2000> ...wrong window there
[15:54:07 CET] <c_14> ar is an archive program
[15:54:55 CET] <wolfman2000> I can compile and make that build. Don't need to make install it due to it being localized, but this is definitely a solid point for me.
[15:55:14 CET] <wolfman2000> Maybe I can finally make the transition to a more modular repo possible. Thank you.
[16:01:48 CET] <debianuser> SmokedCheese: It's kind of expected actually. It's encoded an 60 seconds per minute speed :) I mean ffmpeg can't encode live stream faster than it streams. :)
[16:03:49 CET] <SmokedCheese> but if encoding w/ downscaling is slower than source fps
[16:04:12 CET] <SmokedCheese> even if ultrafast
[16:05:28 CET] <debianuser> Encoding speed depends on other options as well. By the way, about ultrafast...
[16:05:40 CET] <debianuser> Can anyone get 50-60 fps fullscreen with ffmpeg+x11grab+x264? Command `time ./ffmpeg -y -f x11grab -r 60 -s 1280x1024 -i :0 -vcodec libx264 -preset ultrafast -pix_fmt yuv420p -t 30 out.flv` does <40fps for me and uses just one core. Looks like a bug in ffmpeg somewhere limiting it to 1 core only.
[16:18:06 CET] <SmokedCheese> did you tried -threads option?
[16:21:26 CET] <debianuser> Yeah, tried "-threads 0", "-threads 4" even "-threads 16". Still same 100% of one core. :( Here's an example of command and its output: http://pastebin.com/KWVMRnyb
[18:38:08 CET] <relaxed> debianuser: Are you looking at `htop`'s output? I've tested my builds on multiple computers and they use all threads.
[18:41:06 CET] <debianuser> relaxed: Yeah, when I encode some regular recordings into x264 it uses all cores. But in that case (x11grab) it seems to be taking one core only. It's easy to check, just run `time ./ffmpeg -y -f x11grab -r 60 -s 1280x1024 -i :0 -vcodec libx264 -preset ultrafast -pix_fmt yuv420p -t 30 out.flv`
[18:42:40 CET] <relaxed> x11grab is most likely the bottleneck
[18:43:29 CET] <relaxed> to apply threads for decoding the input you must specify it before the input
[18:44:01 CET] <relaxed> in the case of x11grab I'm not sure if it will make any difference
[20:32:24 CET] <debianuser> relaxed: Hm... But a command `./ffmpeg -f x11grab -r 60 -s 1280x1024 -i :0 -t 30 -f null -` gives 60fps for me easily taking just 5% CPU.
[21:55:28 CET] <sagax> why in you command key -f writed twice?
[21:55:51 CET] <sagax> in first and finish
[21:56:11 CET] <pzich> x11grab is the input, and null is the output (which he's discarding)
[21:56:41 CET] <pzich> since he's not specifying a file as output the extension can't hint which format to use
[21:58:09 CET] <sagax> i understand, thanks
[22:22:47 CET] <debianuser> sagax: ffmpeg is like `ffmpeg <input1-options> -i <input1> <input2-options> -i <input2> ... <inputN-options> -i <inputN> <output-options> <outfile>`. The "-i" option is like a separator. So in my case first "-f" is option for input1 and second is output option "null".
[22:24:56 CET] <sagax> debianuser, thanks, i understand this now better
[22:58:49 CET] <t4nk703> i want to set the size of a "color" filter input based on another video input's size, is it possible: http://pastebin.com/v3ScuCJi
[22:59:04 CET] <t4nk703> or failing that, generate some black frames based on the input video size
[00:00:00 CET] --- Mon Mar  9 2015