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

[burek]

[09:25] <arpu> hello in the comman dline the bitrate= 406.9kbits/s  is this video and audio bitrate ?
[11:16] <amccloud> Has anyone been able to get screen recording to work with mountain lion? x11grab is complaining about not being able to find my display. "Could not open X display." I'm passing -f x11grab -i ":0.0"
[11:27] <amccloud> [x11grab @ 0x7fbafa006600] device: :0.0+0,0 -> display: :0.0 x: 0 y: 0 width: 640 height: 480 Could not open X display.
[13:38] <killown> amaurea, are you doing it as root?
[13:39] <killown> sorry amaurea I mean amccloud
[17:04] <amaurea> killown: ah, here I thought somebody had finally seen my question. Oh well
[17:07] <killown> amaurea, was you executing ffmpeg as root?
[17:07] <killown> or local user?
[17:31] <uffo> anyone knows why ffmpeg writes maxrate info in audio section not in video where it belongs? http://trixarian.net/paste/1da52
[18:44] <jordan__> if i use ffmpeg to convert to h264 i have to gpl my app?
[18:47] <JEEB> if you link to ffmpeg that links to libx264 (GPL'd), yes. Calling out a command line is less obvious IIRC, but you'll still have to distribute the source code in that case.
[18:47] <JEEB> (of the ffmpeg + libx264 and friends, at the very least)
[18:47] <JEEB> also, libx264 /can/ be licensed non-GPL as well, if you want
[18:47] <JEEB> http://www.x264licensing.com/
[18:52] <jordan__> perhaps there is a codec that is on par with x.264 that sidesteps all this legal trouble
[18:54] <JEEB> not really, but you could license x264 commercially via the ways I linked :) And then you could use ffmpeg just to decode/convert colorspaces (LGPL). In that case you'd just have to release the sources for the ffmpeg so that the thing that LGPL stands for can be kept ("User can switch the LGPL library if he or she wants")
[18:55] <JEEB> it's really not surprising that many companies that were using MainConcept are now switching to commercially licensing x264 :)
[18:56] <jordan__> are there other implementations of it
[18:56] <JEEB> of what?
[18:56] <jordan__> of a h.264 codec that isn't gpl'ed
[18:56] <JEEB> encoder? commercially licensed x264?
[18:57] <JEEB> otherwise there's the other commercial encoders, but those are much more costly
[18:57] <JEEB> as I said, if you don't want to have GPL in your app, I recommend licensing x264
[18:58] <JEEB> the x264 API def. isn't too hard
[18:58] <JEEB> that way you only need to give your possible changes to x264 to the main developer of it, and he will then decide whether it's worth it to put into the GPL version
[18:59] <JEEB> (f.ex. fixstars implemented MVC on top of x264, but that never got merged as the compression really wasn't better)
[18:59] <JEEB> the patches are naturally around tho, as they were linked on the development channel
[19:03] <JEEB> personally I'd probably just have an LGPL ffmpeg around for input, audio and/or muxing f.ex.. and would have the sources for every release's ffmpeg around so that if people really want to use their own, they can (dynamic linking would make you do that with LGPL, that's it). Because licensing MainConcept's or someone's decoder components would probably wind up rather pricy >_>
[19:06] <jordan__> JEEB consider i'm going to be using really low quality when i convert to h.264
[19:07] <JEEB> what?
[19:07] <JEEB> you should probably reword that :P
[19:07] <jordan__> low resolution, low fps
[19:07] <JEEB> and?
[19:09] <jordan__> i'm saying if there are other h264 codecs that are free perhaps there isn't much of a difference to x264
[19:09] <JEEB> nope
[19:10] <JEEB> if you are going to be selling your thing or whatever, I'm pretty sure you can take a commercial license for x264 :)
[19:11] <jordan__> i'm just exploring right now, but sure i could, just i'm worried about their min unit thing
[19:11] <JEEB> I'm pretty sure if you have questions like that you could ask CoreCodec, which is their biggest reseller of licenses
[19:12] <JEEB> or well, use the contact form :)
[19:12] <jordan__> what is the best codec that is LGPL in FFmpeg
[19:13] <JEEB> not sure, you probably speak of lossy compression right?
[19:13] <jordan__> yes
[19:13] <JEEB> could be mpeg4 (MPEG-4 Part 2 [aka what XVid and DivX follow])
[19:13] <jordan__> for my needs maybe i don't need x264 i'm thinking low res and low fps
[19:14] <JEEB> http://x264dev.multimedia.cx/wp-content/uploads/2009/08/quality_chart1.png
[19:14] <JEEB> this is /very/ old, but yeah
[19:14] <JEEB> with all settings up to eleven, ffmpeg's mpeg4 is the best'ish
[19:14] <jordan__> the problem i've found is i need to be able to seek my video fast, some video's i seek there is like a 2 second delay on seeking around
[19:15] <JEEB> depending on the format you really can't do much about that unless you've made the file yourself
[19:15] <JEEB> because most modern encoders by default have a GOP (Group Of Pictures) of 10 seconds' worth of frames or more
[19:15] <jordan__> that's why i need to keep the input files consistent which means converting
[19:16] <JEEB> I'd probably use something like ut video or ffvhuff for that
[19:16] <JEEB> lossless, but fast and intra
[19:16] <jordan__> cool that's what i'm looking for really
[19:16] <JEEB> (intra = every frame is encoded separately)
[19:16] <jordan__> why do the GOP's make it slow
[19:17] <jordan__> it has to decode the whole GOP
[19:17] <jordan__> oh i see
[19:17] <JEEB> basically if you seek into the middle of a GOP
[19:17] <JEEB> you need to find the first frame of the GOP, an IDR frame
[19:17] <jordan__> yea i understand
[19:17] <JEEB> (IDR = keyframe)
[19:17] <JEEB> and then decode all the way to the frame you wanted, yeah
[19:17] <jordan__> so i want every frame to be a key frame?
[19:18] <JEEB> more or less, most people at max like three frame GOPs for editing
[19:18] <jordan__> good information
[19:18] <jordan__> but i don't necessarily need x264 for that
[19:18] <JEEB> anyways, if you're looking for lossless, I kind of recommend Ut Video, as that has input modules for all available operating systems
[19:19] <JEEB> I implemented an encoder in ffmpeg
[19:19] <JEEB> then the original creator has VFW/DS components and an OS X component
[19:19] <JEEB> so this way it works on all operating systems
[19:42] <jordan__> would making a GOP of size 3 going to make the starage much higher?
[19:43] <jordan__> so it's either fast seeking and high storage, or slow seeking and low storage
[19:43] <JEEB> more or less, yes
[19:44] <JEEB> of course on sources that have, like, completely random noise on them probably would have less of a difference
[19:44] <JEEB> unfortunately such sources aren't the norm :)
[19:44] <jordan__> i really need fast seeking and low storage, the resolution and fps can suffer
[19:46] <jordan__> with those objectives what is the best codec for the job?
[19:47] <JEEB> unfortunately in most cases the "best" thing around is x264 >_>
[19:48] <jordan__> even with low res and fps?
[19:48] <jordan__> what is 1/(1-SSIM)?
[19:48] <JEEB> yes, the resolution and fps don't really matter
[19:49] <JEEB> x264 is pretty much the best thing in town for almost everything
[19:49] <jordan__> really
[19:49] <JEEB> yes, really
[19:49] <JEEB> SSIM is the better-than-PSNR mathematical way of seeing how much pictures differ
[19:50] <JEEB> (PSNR loved blur, so blurring things would end up "scoring" better)
[19:50] <jordan__> so the higher SSIM the better?
[19:51] <JEEB> yes
[19:54] <jordan__> how come the res and fps don't matter to my objectives?
[19:55] <JEEB> because those two really don't matter when comparing stuff on the same level, unless an encoder has problems with specific resolutions or frame rates o_O
[19:57] <jordan__> but the comparison levels off at those settings right, i mean you may see a marked difference for something with high resolution levels between codecs, but not so much at low quality settings
[19:57] <JEEB> uhhh
[19:58] <JEEB> let's just say that i'm not sure what exactly you're not understanding about testing encoder efficiency, but let's just say that if you held proper testing you'd find out the same thing that I'm telling you.
[19:59] <JEEB> I'm actually not sure if there even are any cases where x264 is worse than some other encoder available via open source >_>
[19:59] <JEEB> (HM could be better but it's a reference implementation that takes minutes per frame, and doesn't match the current specification)
[19:59] <JEEB> (HM = the HEVC reference implementation)
[20:04] <jordan__> ok two troubling things i see for using ffmpeg for me, The LGPL does not incorporate several options and optimizations, 2 in my EULA I cannot put a prohibition of reverse engineering.
[20:06] <jordan__> i don't know if these options/optimizations are going to apply to me, and i don't really care for ppl reverse engineering my work
[20:10] <JEEB> the only GPL things are the little things from libmpeg2 IIRC
[20:11] <JEEB> and some other stuff
[20:11] <JEEB> so I would pretty much have no problems using an LGPL build myself
[20:11] <JEEB> the only "problem" with LGPL is to keep to shared libraries (on windows, DLL) and release sources for ffmpeg used for every version
[20:12] <JEEB> in other words, the optimizations are really minor and I wouldn't care much about them on modern systems
[20:12] <JEEB> everything important is LGPL
[20:21] <jordan__> am i reading correctly for the revere engineering part?, they can now reverse engineer my entire app becuase of ffmpeg lgpl?
[20:24] <jordan__> or just the ffmpeg dll
[20:27] <JEEB> I think that reading of it would be correct, that you can't put an anti-RE clause there. Not 100% sure though, but that's how I've seen several people read it.
[20:28] <JEEB> that said, in the US people can do "clean room" RE anyways
[20:28] <JEEB> and in Europe you tend to have even more freedom regarding it
[20:34] <uffo>  anyone knows why ffmpeg writes maxrate info in audio section not in video where it belongs? http://trixarian.net/paste/1da52
[21:20] <amaurea> killown: sorry for the late reply. But I was not asking about anything to do with running ffmpeg. I had a question about swscale, which I gather is a part of ffmpeg. x264 has a colorspace bug which they claim they can't fix because of limitations in swscale.
[21:21] <amaurea> killown: My quesiton was: When asking about a color matrix bug in #x264 they pointed me here. According to them, x264 does not correctly convert from RGB to bt709 because swscale does not allow one to set the colormatrix correctly for the RGB -> YCbCr conversion, only the other way around. Is that correct?
[21:48] <penyulap> I'd love help with a magic spell...wait,. I mean I want help with a linux command line. I take apart some videos into single frames, and work on them in gimp. Sometimes I assemble frames I make with blender into an avi. Now I want to do something combines the two but I can't. I take apart the video, because I only want to work on part of the video. There are 1333 frames in the video, but I just want everything after frame 00626.png I want to assemble from 62
[21:48] <penyulap> or is there a linux command to mass rename the files ?
[22:01] <Tjoppen> a small shell script could do it
[22:03] <jordan__> intel MediaSDK is free, encodes mpeg2, h.264, and VC-1
[22:03] <JEEB> jordan__, doesn't that only work with intel stuff?
[22:03] <jordan__> i suppose so
[22:03] <JEEB> I think there's a SW implementation as well tho
[22:04] <JEEB> not sure though
[22:04] <JEEB> also the encoder's really simple
[22:04] <JEEB> but yeah, those APIs are there if you /really/ want them
[22:04] <JEEB> they can be all kinds of hell to work with tho
[22:04] <jordan__> why
[22:05] <JEEB> they remind me of certain older APIs
[22:05] <JEEB> that's all
[22:05] <JEEB> feel free to test them, they should in theory work if all you need is low-quality 4:2:0 H.264 f.ex. :)
[22:07] <penyulap> is the shell script something that uses api?
[22:08] <penyulap> surely there is a simpler way
[22:09] <jordan__> yea, i don't know if i can just restrict to intel
[22:40] <burnt> hi can someone help me please
[22:41] <burnt> i stupidly uninstalled ffmpeg
[22:41] <tdr> burnt, you can't just re-install it?
[22:41] <burnt> dont ask, this is on ubuntu 12.04
[22:41] <burnt> no it gives me this error
[22:41] <burnt> gstreamer0.10-ffmpeg : Depends: libavcodec53 (< 5:0) but 6:0.10.4-0ubuntu0jon2 is to be installed or libavcodec-extra-53 (< 5:0) but it is not going to be installed
[22:42] <burnt> tried updating repositories
[22:42] <burnt> everything
[22:42] <burnt> went through about 5 tutorials
[22:42] <burnt> sigh
[22:42] <tdr> did you update your packages, apt-get upgrade   or whatever?
[22:42] <burnt> yep
[22:42] <burnt> about 5 times
[22:42] <burnt> fried said looks like a debian issue ?
[22:44] <tdr> burnt, of course, it's a deb issue not an ffmpeg issue, weird dep graph
[22:44] <tdr> burnt, does your apt (or synaptic or whatever package manager you use) allow you to specify versions?
[22:45] <burnt> synaptic might
[22:45] <burnt> apt doesnt i dont think
[22:45] <tdr> burnt, thats what i'd shoot for.  its wanting earlier versions than the newest available in your repos
[22:46] <burnt> yeah i thought somthing like that from forums
[22:47] <burnt> wonde if ffmpeg on git hub would have em?
[22:47] <tdr> have "em" ... not sure what you mean there
[22:48] <tdr> burnt, your package manager should also have a log file somewhere that would show which versions of packages were removed.  that would show you which versions you should be able to put back on your system
[22:49] <burnt> ah
[22:49] <burnt> you is wize!
[22:56] <burnt> no luck, giving up
[23:00] <tdr> burnt, nothing in your /var/lib/dpkg or similar named file?  (not sure of the exact location)
[23:01] <burnt> no :(
[23:01] <burnt> thanks for the time and helo tdr
[23:01] <burnt> help
[23:01] <burnt> full wipe tommorrow
[23:01] <burnt> been at this now for 7 hours
[23:17] <amccloud> I've been searching and searching. Is there anyway to capture the desktop/screen (with ffmpeg) on os x.
[00:00] --- Mon Sep 17 2012