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

[burek]

[04:19] <slavik262> Stupid question - I'm trying to upload sample files to the FTP server to go along with a bug report, but I keep getting "553 Can't open that file: Permission denied"
[04:20] <slavik262> am I going about it the wrong way?
[08:22] <DMJC> is there a really good tutorial for implementing a video player using libavformat etc?
[08:23] <DMJC> I'm trying to fix the homeworld 1 sourcecode. Someone's implemented an avformat based video player for BINK animations but it's crashing when trying to run.
[08:24] <DMJC> I think it's got something to do with the code that determines the format of the file.
[08:57] <DMJC> ok I've now got video playback working
[08:57] <DMJC> but when I try to play a second video it fails
[08:57] <DMJC> debug output it looks like the second run through isn't working
[09:22] <DMJC> completely stumped
[09:37] <DMJC> can I put a log file up for someone  to look at?
[09:42] <DMJC> http://filebin.ca/g1uUgyVaMSl/homeworld.log
[09:42] <DMJC> it's a 1.6mb xml format log from valgrind
[10:55] <DMJC> Fixed it :D
[10:55] <DMJC> someone forgot to initialise to zero... bad programmer..
[11:01] <zap0> someone still writes C code like its 80's ?
[14:25] <alex88_> hi guys, someone ever tried to open a vsd file?
[14:25] <alex88_> It's from a security camera
[15:55] <yns> I'm wondering where to find documentation on ffmpeg's -bufsize flag?
[15:56] <JEEB> it sets the vbv bufsize (that is then used in conjunction with the vbv maxrate)
[15:57] <JEEB> it is the amount of buffer over which the maxrate is calculated, and thus has to preferably match between the encoder and the decoder
[15:57] <yns> thanks for your answer but iew, newbie here
[15:57] <yns> vbv?
[15:58] <JEEB> vbv is a model basically, techy stuff that you really don't have to know that much about in most cases
[15:58] <yns> okay
[15:58] <yns> basically I'm trying to change the datarate of a video
[15:58] <yns> so -b:v
[15:58] <yns> but quicktime doesn't play the video anymore afterwards
[15:59] <yns> tought bufsize could help maybe
[15:59] <JEEB> then it's most probably up to something else. maxrate and bufsize are mostly used when you are making something for consumption over a limited amount of bandwidth (such as networks or removal discs)
[16:00] <JEEB> post a full pastebin with the actual command you used, and the terminal output
[16:00] <JEEB> and link it here
[16:00] <yns> okay
[16:01] <yns> http://pastebin.com/ZvjCgtgJ
[16:02] <JEEB> I have this lingering thought that QuickTime just doesn't support MJPEG like that :P
[16:03] <yns> No it does :)
[16:03] <yns> Or doesn't it support *this kind* of MJPEG?
[16:03] <yns> Other MJPEG's played back, without fiddling with the -b:v tag?
[16:04] <yns> -?
[16:04] <JEEB> so you have created MJPEG videos with this exact setup and played it with QT?
[16:05] <yns> Without the -b:v part yes
[16:05] <JEEB> it's also rather short of a test, but I am pretty sure libavcodec's MJPEG encoder isn't exactly applying your rate control at all :P
[16:05] <JEEB> yns, same container output?
[16:05] <yns> ah no sorry
[16:05] <JEEB> yeah
[16:05] <yns> that was different yess
[16:05] <yns> it was .mov
[16:05] <JEEB> yeah, I'm pretty sure that's it :P
[16:05] <yns> don;t need the mp4 anyway
[16:05] <yns> oh ok :)
[16:05] <yns> So basically:
[16:06] <yns> I'm trying to use the video as a source for some creative programming, and I think my HDD speed is too slow (the video playback lags). So I thoght to reduce the datasize (which I assumed must be bitrate)
[16:06] <yns> -b:v is the way to go you think?
[16:06] <JEEB> umm
[16:06] <JEEB> while that is a 20mbps source, I'm pretty sure it's not your HDD that is being the bottleneck
[16:07] <JEEB> also looking at those 31 frames' log the -b:v isn't doing /anything/
[16:07] <yns> Oh :(
[16:07] <yns> Actually I'm playing more video's at once
[16:07] <yns> So therefore I thought it could be my HDD
[16:08] <JEEB> also if you want to make the thing less HDD-intensive I have NFI why you're re-encoding it into a format that is less CPU-intensive while can be huge as hell for certain rather obvious reasons
[16:09] <JEEB> anyways, I'd recommend you check playback with a few apps and see what exactly is your bottleneck :P
[16:09] <yns> hm, well with apps it all works fine
[16:09] <yns> and using h.264 I had the idea CPU was the problem
[16:10] <JEEB> "with a few apps" I meant that if you're having trouble with playing something back, try that scenario with various other playback apps (mpv/VLC f.ex.) and then monitor your system to see what exactly is your bottleneck :P
[16:11] <yns> hm ok
[16:13] <yns> Well yeah turns out to be like I thoght
[16:14] <yns> h.264 takes a little more that 50% CPU usage, so playing 2 could be problematic, HDD usage is really low
[16:14] <yns> And MJPEG is liek 10% CPU but 60% HDD usage
[16:17] <yns> So I guess trying to lower the HDD usage is what I'd like to try
[16:18] <yns> But since -b:v doesn't work, what can I try to lower datarate?
[16:25] <JEEB> yns, setting the compression "quality" lower, I guess?
[16:26] <yns> -qscale:v ?
[16:27] <JEEB> or just -q:v , the values go from 1-31 it seems
[16:27] <JEEB> higher is higher quantizer
[16:27] <JEEB> and thus more compression, less quality
[16:28] <yns> thanks, where did you find that info? documentation says "The meaning of q is codec-dependent" is there a list of codecs with meanings of q somewhere?
[16:29] <JEEB> from a random post on the internet, you would probably have to dive into the source code or the specification of a format to find the actual limits of quantizer values :)
[16:30] <yns> hehe okay
[16:30] <yns> I'll just see what 1-32 gives me:)
[16:32] <yns> Data rate stays pretty high (11Mb/s) with -q:v 8, the video starts to look ugly already. Other ways to go?
[16:34] <JEEB> use formats that compress better, like H.264? there you would use the -crf option instead of -q btw. possibly use -tune fastdecode with the libx264 encoder
[16:35] <yns> hm okay
[16:39] <yns> any documentation on the -crf flag?
[16:40] <JEEB> there was a way to pull out the libx264-specific help, but I don't remember it :P
[16:40] <JEEB> it's a straight mapping to the libx264's crf parameter
[16:40] <JEEB> which is the closest we have to "constant quality" right now with video encoders afaik
[16:41] <JEEB> values go from 1 to 51 (actually higher than that, but the last ones are 51 + filtering for exceptional cases)
[16:41] <JEEB> you can start from 23 or so
[16:42] <yns> the lower the better quality?
[16:42] <JEEB> yes
[16:42] <yns> and the libx264 encoder is automatically being used when converting to h264?
[16:42] <JEEB> there is no other encoder for H.264 in libavcodec atm
[16:43] <yns> okay just being a newbie here :)
[16:45] <yns> I get really ugly results when reducing the dimensions with h264 (with -s), that something normal with h264?
[16:48] <yns> Doing this ffmpeg -i /Users/yns/Image/Samples/SpoutingHorn-720.mp4 -s 854x480 -vcodec h264 -g 1 /Users/yns/Image/Samples/SpoutingHorn-480_h264_kfrm.mp4
[16:48] <yns> Lowering quality after this should be disastrous
[16:51] <JEEB> ugh @ -g 1
[16:51] <JEEB> why are you using that?
[16:51] <JEEB> also why aren't you setting a -crf value (23 should be default)?
[16:51] <JEEB> (and then you should be able to turn it up and down)
[16:51] <JEEB> I mean, if you want to compress I'm pretty sure intra-only compression isn't exactly the best thing to do :P
[16:53] <yns> hm, I'm using -g 1 so I can acces random points in the video quickly, for the creative coding stuff
[16:53] <yns> intra-only compression?
[16:55] <yns> Ah yeah, even not resizing the dimensions makes it ugly as hell. Is that the -g 1?
[16:55] <JEEB> show me the full log :P
[16:55] <yns> :P
[16:56] <JEEB> I just want to see what the hell you're doing badly
[16:56] <JEEB> so another pastebin pl0x
[16:57] <JEEB> also make sure you're not only testing with quicktime, as many versions of it have bugs with decoding completely valid H.264, although it shouldn't really be "ugly as hell"
[16:57] <JEEB> also, no. If you were doing it right -g 1 would only bloat your bit rate
[16:57] <JEEB> crf would more or less control the quality
[16:57] <yns> http://pastebin.com/TUhUcrns
[16:59] <JEEB> generally seems fine, crf gets used and set to the default of 23...
[16:59] <JEEB> if it really just looks bad, then lower the crf value
[16:59] <yns> hm
[17:00] <yns> Well yeah but I wanted to compress :(
[17:00] <JEEB> then drop the fucking -g 1 or set a slower -preset
[17:00] <JEEB> http://mewiki.project357.com/wiki/X264_Settings#preset list of presets
[17:01] <JEEB> medium is the default
[17:01] <yns> Hm okay, Maybe it doesn't look that "bad as hell" it just looks grainly, like there are small dots all over the screen
[17:02] <JEEB> also I'm pretty damn sure you don't want to re-encode the audio in that file
[17:02] <JEEB> might want to set -c:a copy
[17:03] <yns> http://postimg.org/image/u11q0ecgv/
[17:03] <yns> no wait
[17:04] <yns> no the screenshot is accurate
[17:04] <yns> it's just less anoying when the image aint moving
[17:05] <yns> but -c:a is not going to do anything for video q right?
[17:05] <JEEB> no, it will not
[17:05] <JEEB> it will just tell ffmpeg to copy over the audio, and not re-encode
[17:05] <yns> hm
[17:06] <yns> Well I guess I should conclude h264 is not that much better in compression :)
[17:06] <JEEB> ...
[17:06] <JEEB> I don't know where to start to comment on that sentence
[17:06] <yns> haha
[17:06] <yns> sorry
[17:07] <JEEB> ok, you have a baseline 1280x720 file that most probably is not all-intra and depending on how sane the encoder was that did it, either looks somewhat better or somewhat worse
[17:07] <JEEB> you hit it with crf 23 and a one-frame GOP
[17:07] <JEEB> with preset medium
[17:08] <JEEB> and haven't even encoded with it to the end to know the full result
[17:08] <JEEB> (to know the full end average rate you got with that crf value)
[17:09] <yns> okay that seems logical indeed. what do you mean by that last sentence? that i havent tried everything yet?
[17:10] <yns> -crf looks fine indeed
[17:10] <JEEB> you are basically cutting the hands and legs off the format (making it intra-only), and not even checking the slower presets, and then crying that it doesn't compress automagically better than a relatively compressed file that by all means that I know of isn't all-intra
[17:10] <JEEB> and then you fucking cry out that "H.264 is not that much better in compression"
[17:11] <JEEB> until we get good HEVC encoders, H.264 (esp. with libx264) is going to be the best compression you're going to get from anything :P
[17:11] Action: sacarasc gives JEEB a hug.
[17:12] <yns> oh sorry man didn't mean to offend you. I'm just a huge newbie when it comes to video
[17:12] <JEEB> you didn't offend me per se, I'm just facedesking with all of my might at some of this stuff
[17:13] <yns> well anyway I'm sorry.
[17:13] <yns> what's all-intra, and intra-only
[17:14] <JEEB> same thing, if all is intra then it is also intra-only, and it means that you are not using inter prediction at all (predicting between frames)
[17:14] <JEEB> ffmpeg -i welp.input -c:v libx264 -crf 23 -preset veryslow -g 30 -c:a copy out.file , try this at least :P
[17:14] <yns> okay :)
[17:16] <yns> trying
[17:17] <yns> the all-intra is a result from adding keyframes to every frame with -g 1?
[17:17] <JEEB> -g 1 means that your GOP is of length of one frame, and then after that one frame at max you have to put out another random access point (usually in case of libx264, an IDR frame)
[17:18] <yns> which results in all-intra?
[17:18] <JEEB> well, since your GOP is of length one frame then you can't really have any inter frames if the next frame is going to be of another GOP already :P
[17:19] <yns> hehe ok :)
[17:19] <JEEB> which leads to all frames being intra-only because there's zero frames that then predict from them
[17:19] <yns> ah ok
[17:19] <yns> i see the veryslow preset is indeed very slow :)
[17:20] <yns> wat else is it trading of for the higher quality?
[17:20] <JEEB> anyways, I'm not sure what you need is attainable within your needs, partially because I'm tired as hell to try and guide you through it. If you need something that's quickly decode'able, then use something like that (ffvhuff, mjpeg, ut video, whatever). But do expect that if you already have somewhat compressed stuff, you're not going to *compress* them as well
[17:20] <yns> or is it just compressing slower?
[17:21] <JEEB> or heck, x264 as well, but in any case you're not going to get any magical pixie dust compression
[17:22] <yns> okay well thanks a lot for your help, i've learned a lot! basically setting the preset to veryslow makes it encode slower? (which is actaually no problem for me)
[17:22] <JEEB> yes, it will use slower algorithms and more data to compress
[17:22] <JEEB> in other words, better decisions are made
[17:23] <yns> okay
[17:23] <JEEB> and also of course it enables the use of certain features in certain cases in case they were decided to be disabled with faster presets
[17:23] <yns> the file is really small indeed (just saw the result of your suggested command) but it lags a bit even when playing it back in quicktime?
[17:24] <yns> (the quality of the file looks marvelous as well by the way)
[17:25] <JEEB> dunno why it'd lag unless quicktime sucks a dique, or your CPU sucks *shrug*
[17:25] <yns> hehe
[17:25] <yns> well it's not that bad, 2.4Ghz Core2Duo
[17:26] <yns> cpu usage is also only about 20%
[17:26] <yns> well anyway
[17:26] <yns> thanks a lot for your help
[17:26] <yns> maybe one day I find the compression settings that do it for me :)
[17:26] <JEEB> anyways, QuickTime *does* indeed have random bugs and other crap
[17:27] <JEEB> so if you're limited to it I wish thee good luck
[17:27] <JEEB> you'll most probably have to cut off a lot of alternatives just because "QuickTime doesn't like it"
[17:28] <yns> Well I'm using openFrameworks which uses QuickTime API to playback videos, like most creative coding environments on OSX
[17:28] <yns> I don;t have the luxury of "just the desire to watch a nice movie"
[17:29] <JEEB> I wasn't even noting that, I'm just noting that you'll have "plenty of fun" with the QT itself and its framework :P
[17:29] <yns> hehe :P
[17:29] <JEEB> and any good result you might find might not be optimal purely by the reason of "QuickTime decided to pee on your legs"
[17:29] <JEEB> just keep that in mind
[17:30] <yns> it is what it is. actually I'm at the point of giving up video, concludng my computer is just too slow
[17:31] <sacarasc> What specs is your computer/
[17:31] <JEEB> 20% CPU usage does sound like you should be able to do more, though. But suit yourself :)
[17:31] <yns> 2.4Ghz Core2Duo, 5400RPM HDD, 4GB RAM
[17:31] <yns> 256MB VRAM
[17:33] <JEEB> I'd probably use something like ffvhuff or Ut Video or something if I had to make an app that shows multiple clips at the same time, but neither are supported by QT so (´
[17:34] <yns> Hm
[17:35] <yns> I was told MJPEG is the way to go for fast scrubbing and stuff
[17:35] <yns> The thing is that playing back the video is just a little beginning in what I want to do
[17:36] <JEEB> anything that is intra-only or has short GOPs is fast to seek in
[17:36] <yns> I want to acces the pixels change their rgb values, look at what coordinates there are all-white pixels and do somehting with that. that kind of stuff
[17:36] <JEEB> not in any way limited to MJPEG
[17:37] <yns> No but since I wan't to that crazy stuff I really need something that is super easy on CPU for just playing back the file
[17:37] <JEEB> then all of those I mentioned go as well
[17:37] <yns> those things I describe eat CPU like hell, and HDD is not much of a problem in that case
[17:37] <JEEB> that said, HDD and "what is supported by lolQT" become the problem
[17:37] <yns> yes but they are not supported by QT :)
[17:37] <JEEB> Ut Video actually is
[17:38] <yns> which == "no option"
[17:38] <JEEB> it has a decoding component for the QT framework
[17:38] <yns> oh ok
[17:38] <yns> ok than I'll have to look into that
[17:38] <yns> But I have spent DAYS already converting stuff
[17:38] <yns> I'm tired of it
[17:38] <JEEB> it's a lossless format that's all-intra and consists of simple huffman coding
[17:39] <JEEB> will eat space (much less than raw video naturally), but should otherwise be within your area :P
[17:39] <yns> okay :)
[20:24] <Astin> Hello
[20:24] <Astin> I installing ffmpeg on ubuntu
[20:24] <Astin> why ERROR: libass not found
[20:25] <Astin> I installed libass-dev
[20:25] <Astin> T.T
[20:25] <JEEB> see the config.log
[20:25] <Astin> Thank you
[20:26] <Astin> I saw it
[20:26] <Astin> but
[20:26] <Astin> just ./configure ~~~~ _decoder
[20:28] <Astin> last
[20:28] <Astin> gcc -Wl,--as-needed -o /tmp/ffconf.Ke9NC7MQ /tmp/ffconf.zVyCDmHn.o -lm -pthread -lz -lrt
[20:28] <Astin> check_pkg_config libass ass/ass.h ass_library_init
[20:28] <Astin> ERROR: libass not found
[20:28] <JEEB> pastebin the whole config.log
[20:28] <JEEB> and link here
[20:29] <Astin> yes
[20:29] <Astin> I delete and
[20:29] <Astin> I reconfigure
[20:29] <Astin> I installed libass-dev on ubuntu T.T
[20:31] <Astin> I'm trying http://forum.serviio.org/viewtopic.php?f=7&t=9511
[20:32] <JEEB> why can't you just post on the pastebin the config.log when you configure with --enable-libass :P
[20:32] <JEEB> and then link it here
[20:33] <Astin> okay
[20:34] <Astin> Thank you
[20:34] <Astin> I don't know about pastebin
[20:34] <Astin> but i got it now T.T sorry
[20:34] <JEEB> pastebin is a type of site nowadays, the most well-known is pastebin.com
[20:34] <JEEB> you can post pieces of text that aren't just a single line in there :P
[20:35] <Astin> http://pastebin.com/EkBUuGEe
[20:35] <Astin> here T.T
[20:35] <Astin> and Thank you
[20:36] <JEEB> :s
[20:36] <JEEB> oh, it just checks with pkg-config?
[20:36] <Astin> pkg-config?
[20:37] <JEEB> if you try to run pkg-config --version in a terminal, does it say that you don't have such a thing, or does it properly show a version?
[20:37] <Astin> 0.025
[20:38] <Astin> 0.25
[20:38] <JEEB> ok
[20:38] <JEEB> well, all I can say is that the libass-dev package should have the .pc file :s
[20:39] <JEEB> what Ubuntu are you on?
[20:39] <Astin> 12.04
[20:39] <Astin> Thanks for your answer .
[20:40] <Astin> Um .. When I installing libass manually
[20:40] <Astin> configure: error: Package requirements (freetype2 >= 9.10.3) were not met:
[20:40] <Astin> No package 'freetype2' found
[20:40] <Astin> Consider adjusting the PKG_CONFIG_PATH environment variable if you
[20:40] <Astin> installed software in a non-standard prefix.
[20:40] <Astin> Alternatively, you may set the environment variables FREETYPE_CFLAGS
[20:40] <Astin> and FREETYPE_LIBS to avoid the need to call pkg-config.
[20:40] <Astin> See the pkg-config man page for more details.
[20:41] <JEEB> means that you don't have freetype's development stuff :P
[20:41] <Astin> How can I ..
[20:42] <Astin> googling T.T
[20:48] <Astin> I don't have freetype2.pc
[20:48] <Astin> on /usr/lib/pkgconfig
[20:50] <Astin> Thanks JEEB
[20:50] <Astin> with your help
[20:50] <Astin> I got it
[22:40] <mapreduce> I've compiled ffmpeg from the latest on github, and calling avcodec_find_decoder_by_name("mjpeg") gives me NULL.  How can I see what codecs ffmpeg was compiled with?
[22:46] <c_14> ffmpeg -codecs
[00:00] --- Mon May  6 2013