[02:50] <aro> anyone use flowplayer? [04:15] <aro> we are using version N-41485-g1321e6e-syslint [04:15] <aro> my encode string is: /usr/local/bin/ffmpeg -y -i {$in} -vcodec libx264 -acodec libfaac -ab 128k -ac 2 -b 300 -threads 4 -flags +loop -cmp +chroma -partitions 0 -subq 1 -trellis 0 -refs 1 -coder 0 -bufsize 10M -qcomp 0.6 -qmax 22 -qdiff 4 -level 30 {$out} [04:16] <aro> when we play it thru flash based players, it plays audio but no video - any idea why? [04:16] <aro> however, it is fine on desktop apps [05:18] <cogdog> Hi I just wrote a script to do HQ 2 pass encoding (veryslow). I got a pm that I should add this -x264opts frameref=15:fast_pskip=0 ... what on earth does this do? [05:19] <cogdog> pass 1 looks like this [05:19] <cogdog> ffmpeg -i Transformers.3.Dark.of.the.Moon.VOB -an -vcodec libx264 -pass 1 -preset veryslow -threads 0 -b 3000k -x264opts frameref=15:fast_pskip=0 -f rawvideo -y /dev/null [05:19] <cogdog> is the -x264opts stuff really going to make this nicer? [07:46] <crass> anyone know if the later ffmpeg versions demux srt subs into valid srt files (that is with timecodes)? [14:04] <Peace-> isnt in ffmpeg an option to get the same bitrate of a video or an audio ? [14:05] <JEEB> I would say that kind of an option would be utterly and completely useless [14:05] <JEEB> there is absolutely no reason to want the output bit rate the same as the input bit rate [14:07] <Peace-> JEEB: mmm what? i want the same quality for the video [14:08] <JEEB> same bitrate != same quality [14:09] <Peace-> so there is not relation between bitrate and quality? [14:09] <JEEB> There is a relation with lossy encoders, yes. [14:09] <JEEB> as in, usually more bit rate gets you a picture closer to the input [14:10] <JEEB> all that I said is that "the same output bitrate as the input bit rate does not give you an output of the same quality" [14:11] <Peace-> i need to perform a convertion that is quite similar to input but with another codec [14:11] <JEEB> of course you asking for the same quality is already impossible to begin with lossy encoders, the best you can get is a "close to visually lossless" output [14:11] <JEEB> Peace-, yes -- and for that just copycat'ing the input bit rate is very much useless [14:12] <JEEB> if you are using libx264 for H.264 encoding, I recommend just trying to find the highest crf value that still looks good to you [14:12] <JEEB> start from 23 or something [14:12] <Peace-> i am very easy guy [14:12] <Peace-> i don't need the perfection [14:13] <Peace-> if there is an option to get something that is similar ok [14:13] <JEEB> I'm not talking about perfection [14:13] <Peace-> if not ok there is not [14:13] <JEEB> no there isn't [14:13] <JEEB> we don't have thousands of chinese children in sweat shops testing out your video [14:13] <JEEB> there is no algorithm to get you "similar quality" [14:13] <Peace-> eh? [14:13] <JEEB> the best you have is libx264's crf [14:14] <JEEB> and you just can test out 23, and if it looks good enough you can go with that [14:14] <JEEB> if it looks bad, you try a bit lower [14:14] <JEEB> if it looks good, you try a bit higher [14:14] <JEEB> you find that value once and you can then use it [14:14] <JEEB> (the highest one that still looks good for you) [14:14] <Peace-> JEEB: exvideobitrate="$($probe "$2" 2>&1| awk '/Duration:/ { print ( $(NF-1) ) }')k" [14:15] <Peace-> that is what i am doing right now [14:15] <Peace-> to get something of similar [14:15] <JEEB> ok [14:15] <JEEB> let me give you an example [14:15] <JEEB> you have a source that is a losslessly compressed clip that compresses really well, with, say libx264's lossless compression [14:15] <JEEB> now you copy cat the bit rate from that [14:15] <JEEB> for some lossy encoder [14:16] <JEEB> you will get a very bad result yet the source was "perfect" [14:16] <JEEB> on the other hand you can get yourself a prores source or something [14:16] <JEEB> which is 100mbps [14:16] <JEEB> are you just going to re-encode that as 100mbps? [14:16] <Peace-> JEEB: i did a very large script [14:16] <Peace-> and i have profiles into [14:16] <Peace-> but i would not bother people so much so i have made a decision [14:16] <JEEB> end line: copy-cat'ing the input bit rate is not good [14:17] <Peace-> or get something like that it could work [14:17] <Peace-> or bother users [14:17] <JEEB> use a "constant quality"'ish setting with a value you have selected [14:17] <JEEB> like libx264's -crf [14:18] <JEEB> find a value that looks good for you, a bit lower for SD as that usually gets upscaled on screens, and a bit higher on HD as that usually can take a bigger hit (as it isn't usually upscaled when viewed as much) [14:18] <Peace-> JEEB: :S http://nowardev.files.wordpress.com/2012/08/ffmpegservicemenu3.jpg [14:18] <JEEB> I don't give a single derp [14:19] <JEEB> I'm just trying to tell you that copy-cat'ing the input bit rate is not good [14:19] <JEEB> see my last three-four lines [14:20] <Peace-> JEEB: what about mp2 or mp3 or oga ? [14:20] <Peace-> for example [14:20] <Peace-> i have already done the profiles hq lq and etc [14:20] <JEEB> you can just have "generally acceptable bit rates" or "generally acceptable quality settings" set for audio [14:21] <JEEB> the input bit rate does not really matter, as you're going to be re-encoding that anyways [14:22] <Peace-> well but generally 10k is shit and 320k is good [14:22] <Peace-> for audiooo [14:22] <JEEB> re-read my lines [17:22] <annatar> hi, how do I encode a static image into a video that shows that one image for one minute? I tried -loop 1, but the quality is awful, and it takes a long time [17:40] <Guest66630> hello, I need help with compiling ffmpeg under OS X, I got compiler crashed [17:40] <Guest66630> file: dsputil_mmx.c [17:42] <Guest66630> i'm trying to compile 32bit version of ffmpeg under 64bit OS, because I need it for simulator (iOS) [17:46] <Guest66630> here are details: [17:46] <Guest66630> libavcodec/x86/dnxhd_mmx.o libavcodec/x86/dnxhd_mmx.c gcc -DHAVE_AV_CONFIG_H -I. -I"/Users/ivan_ushakov/Documents/Projects/iFrameExtractor/ffmpeg" -m32 -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DPIC -m32 -std=c99 -fomit-frame-pointer -fPIC -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite [17:46] <Guest66630> libavcodec/x86/dsputil_mmx.c:3021: internal compiler error: Abort trap: 6 [18:11] <Sidious> 1. MP4 more compatibility, MKV better quality [18:11] <sacarasc> That makes no sense. [18:11] <Sidious> yes it does if it's true [18:12] <Sidious> 1. MP4 more compatibility, MKV better quality ; is this true? [18:12] <JEEB> you're comparing containers [18:12] <JEEB> they depend on what's inside them [18:12] <Sidious> jeeb yes i am [18:13] <JEEB> you can put more stuff into matroska, but you can stuff H.264 into both, as well as AAC and friends [18:13] <Sidious> friends? [18:13] <JEEB> "and so forth" [18:13] <JEEB> "and other stuff" [18:13] <Sidious> oh [18:14] <Sidious> why can't i playback with mp4 without encoding being finished? is that mean mp4 cannot be streamed [18:14] <Sidious> with mkv i can [18:14] <JEEB> standard mp4 needs an index, and index can only be created when the file is ready otherwise [18:14] <JEEB> matroska can have an index, but it doesn't _have_ to [18:14] <Sidious> so mp4 cannot be streamed? [18:14] <Sidious> and mkv can? [18:15] <JEEB> also there's a feature called "fragments" that lets you open an mp4 file as-is while it's being written [18:15] <JEEB> Sidious, what do you mean with "streamed" [18:15] <JEEB> progressive download? you just need to put the index into the beginning after encoding or use fragments [18:15] <Sidious> able to watch without finish downloading; example youtube [18:15] <JEEB> then that's progressive download [18:15] <JEEB> see my line just now [18:16] <JEEB> youtube just creates indexes every time you seek, although they are also pushing rtmp a lot by now instead of "simple" http [18:16] <Sidious> does youtube use flv? [18:17] <Mavrik> Sidious, there's a "qt-faststart" utility which moves mp4 index to start of file so it can be streamed. [18:17] <Mavrik> you need to run it on an encoded mp4 file. [18:17] <JEEB> youtube uses flv for VP6+mp3 files, and everything else is mp4, except for when they use rtmp [18:18] <JEEB> anyways, as I said -- you can even do live streaming with mp4 + fragments [18:18] <JEEB> and then you can put the index to the beginning with f.ex. qt-faststart [18:18] <JEEB> plenty of ways [18:18] <Sidious> so how do i playback mp4 file when encoding is not finished [18:20] <JEEB> use fragments [18:20] <Sidious> what player support fragments [18:20] <JEEB> everything that is based on libavcodec, and probably some other ones [18:21] <JEEB> depending on how old the players are you might have an easier case with mkv or flv tho :P [18:22] <JEEB> because fragments support was added within a year+ or so [18:22] <Sidious> [09:20] <bogo_lode> Sidious, you can't. [18:22] <Sidious> [09:20] <Sidious> bogo_lode i was told it's possible: not to mention youtube uses mp4 [18:22] <Sidious> [09:20] <bogo_lode> you can stream it once it's finished encoding if it was optimized for streaming [18:22] <Sidious> [09:20] <bogo_lode> but you can't playback an incompletely written file. [18:22] <JEEB> that person has no idea about the fragments feature in the format then [18:23] <JEEB> if you encode an mp4 file with the fragments feature, you can play it right away [18:23] <JEEB> (as long as the parser/player supports fragments) [18:24] <JEEB> it's not surprising because many people don't use fragments (youtube uses already done files, and creates a new index every time you seek if I recall correctly, not fragments) [18:30] <Sidious> ffplay cannot play [18:30] <Sidious> [mov,mp4,m4a,3gp,3g2,mj2 @ 02b41d80] moov atom not found [18:30] <Sidious> a.m4v: Invalid data found when processing input [18:31] <JEEB> did you enable fragments [18:31] <Sidious> how do i do that [18:31] <JEEB> no idea about how to do it in ffmpeg, I just remember bc added the feature after L-SMASH did [18:34] <jeremyagost> Hey, I'm wondering if anyone knows the state of OpenCL support for encoding in FFmpeg? [18:34] <JEEB> none [18:34] <JEEB> GPUs aren't exactly usable for encoding unless you specifically design the format around GPUs [18:34] <Sidious> does flv good as mp4/mkv? [18:35] <JEEB> you can put H.264+AAC into flv, yes. But you're going to have fun with it if you try to stuff something else there [18:35] <Sidious> but does flv support all the features of h264 [18:35] <JEEB> yes [18:35] <Sidious> i was avi doesn't [18:35] <Sidious> i was told avi doesn't [18:35] <jeremyagost> that's correct [18:35] <JEEB> yes, AVI doesn't because it can't handle b-frames [18:36] <JEEB> you have to do awful hacks to put b-frames into H.264 [18:36] <Sidious> does flv support subtiles and multiple audio [18:36] <jeremyagost> it's possible to shove h.264 into AVI but it makes things breal [18:36] <jeremyagost> break* [18:36] <JEEB> multiple audio, probably yes. Subtitles, no idea -- probably not [18:36] <JEEB> not like mp4 subtitle support is any better tho [18:37] <JEEB> jeremyagost, ATi/AMD decided to blow a lot of money into putting a company develop OpenCL lookahead for x264, the results so far aren't anything great, the GPU algorithm is not on par quality-wise and it's only faster with high-end new GPUs [18:37] <jeremyagost> matroska is the best all-around container for multiple audio/sub streams [18:37] <Sidious> is there video/audio codec that mkv does not support [18:37] <jeremyagost> ah I was about to say that I've seen numerous tech articles talking about the benefits of GPU computing in terms of h.264 encoding [18:37] <JEEB> Sidious, probably many [18:38] <Sidious> is there popular video/audio codec that mkv does not support [18:38] <JEEB> what do you count as popular? [18:38] <jeremyagost> nothing that you're likely to use [18:38] <JEEB> it supports all of the stuff that's worth using in most cases [18:38] <jeremyagost> I mean I suppose you probably can't use some of the RealMedia codecs in an MKV, but why would you want to [18:39] <Sidious> does mkv support dolbyplus [18:39] <JEEB> EAC3? [18:39] <JEEB> or what do you mean as dolby plus? [18:39] <Sidious> no [18:39] <Sidious> something that bluray use [18:39] <jeremyagost> Dolby Digital Plus is also known as E-AC3 [18:39] <JEEB> so yes, E-AC3 [18:40] <Sidious> oh [18:40] <Sidious> does mkv support that [18:40] <jeremyagost> and yes, mkv supports it [18:40] <Sidious> and i am guessing mp4/flv does not [18:40] <JEEB> mp4 most probably does have a spec somewhere [18:41] <JEEB> it has for AC-3 after all [18:43] <Sidious> oh i also forgot .mov [18:43] <Sidious> how good is .mov compared to mp4/mkv [18:43] <JEEB> mov is what mp4 is based on, more or less [18:43] <JEEB> it's basically the "AVI" of Mac OS [18:44] <JEEB> mp4 itself is a limited subset of mov, with various stuff added [18:44] <JEEB> so you take parts of mov, and then add new features [18:44] <Sidious> jeeb so mp4 is newer/better than mov [18:44] <Sidious> jeeb so mp4 is newer/better version of mov? [18:45] <Sidious> i remember this feature mov had which was amazing: want to know what that feature was [18:45] <JEEB> I dunno, they're all just a big clusterfuck imho. usability-wise you can probably stick more into mov, but mp4/iso media container is an actual standard [18:45] <Sidious> jeeb do you want to know? [18:45] <Sidious> it's amazing feature [18:45] <JEEB> I really most probably don't [18:46] <Sidious> amazing feature was: when i minimized / just running backgrounnd it was smart enough to NOT to use cpu usage; (i tested with video that uses lot of cpu usage) [18:47] <JEEB> that is not a container feature [18:47] <JEEB> that is a player feature [18:47] <Sidious> jeeb only mov was able to do that [18:47] <JEEB> has absolutely nothing to do with the container [18:48] <Sidious> i used other files and it didn't do that [18:48] <Sidious> only mov [18:49] <jeremyagost> yes and mov always lets you have the bigger Gee Bees [18:49] <JEEB> <JEEB> has absolutely nothing to do with the container [18:49] <Sidious> jeeb that's amazing feature though; most player will still use up the cpu usage even if it's minimized [18:49] <JEEB> it's a fucking player feature damn it [18:49] <JEEB> <JEEB> has absolutely nothing to do with the container [18:49] <Sidious> jeeb it was quicktime player and that only worked with .mov [18:50] <JEEB> I don't give a fuck, <JEEB> has absolutely nothing to do with the container [18:50] <jeremyagost> JEEB, are you aware of FFmpeg having any hardware acceleration features whatsoever? [18:50] <jeremyagost> just out of curiosity... [18:50] <Sidious> jeeb if that feature has nothing to do with container then what player support that on all video files [18:50] <JEEB> jeremyagost, some hardware decoding stuff but I'd really not use that [18:51] <JEEB> Sidious, I have no effing idea [18:53] <jeremyagost> jeeb, I've noticed that when encoding to h.264 on my mac, QuickTime is significantly faster than FFmpeg [18:53] <jeremyagost> of course I typically prefer FFmpeg for its customizability [18:53] <JEEB> jeremyagost, quicktime's H.264 encoder is a piece of crap that doesn't utilize any real features or give compression [18:53] <Sidious> jeremyagost who cares about faster encoding speed [18:53] <JEEB> while I have no idea what ffmpeg/libx264 settings you are using [18:54] <JEEB> libx264 can be _very_ fast [18:54] <saschagehlich> hey, does ffmpeg still have a fixed color palette for .gif? [18:55] <JEEB> jeremyagost, pastebin your command line as well as the ffmpeg's output when you're encoding [18:55] <Sidious> is quicktime encoder any good? [18:55] <JEEB> Sidious, it's not [18:55] <JEEB> it's one of the crappiest you'll find [18:55] <JEEB> and I'm dead serious [18:56] <Sidious> that's hard to believe; it's made by apple [18:56] <JEEB> so? [18:56] <Sidious> i heard apple's aac encoder is best [18:56] <jeremyagost> personally, I've found that the newer QT's encoder does a lot better [18:56] <JEEB> yes, it's licensed from DTS [18:56] <JEEB> or was it dolby? [18:56] <JEEB> don't remember [18:56] <Sidious> what does dts have to do with aac [18:56] <JEEB> the company [18:56] <jeremyagost> lol [18:57] <JEEB> and yes, QT's aac encoder is great [18:57] <JEEB> the H.264 encoder on the other hand is locally made [18:57] <JEEB> and crap [18:57] <Sidious> so apple's aac encoder is not made by apple? [18:57] <JEEB> it's licensed from either dolby or dts [18:57] <JEEB> probably dolby [18:57] <Sidious> i didn't know that [18:57] <JEEB> they did pick a good one tho [18:57] <Sidious> why is apple taking credit for it [18:58] <JEEB> why not? [18:58] <JEEB> they've licensed it [18:58] <JEEB> it's their encoder [18:58] <jeremyagost> what do you mean taking credit? [18:58] <Sidious> why isn't dolby taking credit [18:58] <JEEB> because they've sold a license and are happy that their licensee is happy? [18:58] <JEEB> for the normal people it's Apple's encoder [18:58] <Mavrik> Sidious, they're taking money, better than credit ;) [18:59] <Sidious> why doesn't x264 sell their license then [18:59] <JEEB> they do [18:59] <JEEB> they've had nonfree licensing for more than a year now [18:59] <JEEB> http://x264licensing.com/ [18:59] <Sidious> if x264 sell their license, why does x264 take credit for it: not the licensee? [18:59] <jeremyagost> haven't you hear any of the ruckus about x264 non-free-ness? [19:00] <JEEB> jeremyagost, the nonfree license still makes the makers give out their changes to the library itself, and QT etc. do have double licensing as well [19:00] <JEEB> it's one of the better double licensing schemes [19:00] <JEEB> Sidious, uhh -- most people who license x264 do say it, but no-one is making them say it [19:01] <JEEB> And x264 just releases their new licensees if they are allowed to by the contract with that licensee [19:01] <JEEB> *releases info on their new licensees [19:01] <Sidious> JEEB you are the first person who gave dolby credit for apple aac encoder [19:01] <jeremyagost> let me rephrase, I was referring to the patent encumbrance [19:01] <aro> im having a problem with a video - when i encode it, it doesnt play in flash based players - but it plays in desktop apps fine [19:01] <aro> my encode string is: /usr/local/bin/ffmpeg -y -i {$in} -vcodec libx264 -acodec libfaac -ab 128k -ac 2 -b 300 -threads 4 -flags +loop -cmp +chroma -partitions 0 -subq 1 -trellis 0 -refs 1 -coder 0 -bufsize 10M -qcomp 0.6 -qmax 22 -qdiff 4 -level 30 {$out} [19:01] <JEEB> well, everything is patent-encumbered [19:02] <JEEB> Sidious, because it's that many people who know that it's actually a licensed library, and I'm not giving dolby credit for it [19:02] <JEEB> I'm just saying that it's a licensed library and that's one of the reasons why it's good [19:02] <Sidious> why can't apple who has all the best coders make better h264 encoder [19:02] <aro> apple sucks [19:02] <JEEB> http://x264dev.multimedia.cx/wp-content/uploads/2009/08/quality_chart1.png this is an old test, but shows more or less where the Apple's H.264 encoder stands [19:03] <aro> the only thing worse than apple, is apple fanboys [19:03] <Sidious> jeeb i see; but that link could be biased [19:03] <JEEB> it isn't [19:03] <JEEB> you can recreate it yourself if you want [19:03] <JEEB> all tests that are correct let you recreate it with your own hands if you want [19:03] <Sidious> what is "snow" i never heard of it [19:04] <JEEB> http://x264dev.multimedia.cx/archives/102 <- the actual text, with settings and so forth [19:04] <Sidious> and b ink [19:04] <jeremyagost> hah, bink [19:05] <Mavrik> what's the deal with bink btw? [19:05] <Sidious> wtf is snow and bink? [19:05] <Mavrik> why did so much game companies use it? [19:05] <JEEB> Mavrik, they provide an easily usable lib for it [19:05] <JEEB> for game makers [19:05] <JEEB> which is why many end up using it [19:05] <Sidious> JEEB i dont' see "VC1" in that list [19:05] <Mavrik> it's a proprietary codec right? [19:06] <JEEB> yes [19:06] <JEEB> Sidious, yes VC-1 was missing from that test [19:06] <Sidious> and what happened to real? they used to be popular [19:06] <JEEB> real just started copying H.264, like On2 [19:07] <jeremyagost> they weren't popular so much as they used to be the only ones with actually decent streaming technology [19:07] <jeremyagost> but they kept all their formats proprietary [19:07] <Sidious> jeeb just? 2012? [19:07] <jeremyagost> also they sucked at writing player software [19:07] <JEEB> Sidious, not the time-related "just" [19:08] <Sidious> jeeb real existed before h264 [19:08] <JEEB> I know [19:08] <JEEB> you misunderstood the sentence then [19:08] <Mavrik> and boy did we love Real [19:08] <JEEB> the latest X real formats are more or less H.264 knock-offs [19:08] <JEEB> just like VP7/8 [19:08] <JEEB> (from On2) [19:08] <JEEB> that's what I meant [19:08] <jeremyagost> yup, turns out making video codecs is HARD! [19:08] <JEEB> and in most cases worse than H.264 [19:08] <Sidious> what is "snow"? [19:09] <JEEB> Sidious, http://wiki.multimedia.cx/index.php?title=Snow [19:09] <JEEB> one of the wavelet video compression tests [19:09] <Sidious> oh lossless [19:09] <JEEB> both lossy and lossless [19:09] <JEEB> I'm pretty sure lossy mode was used in that test [19:10] <Sidious> ffmpeg invented snow? [19:10] <JEEB> yes, it's a format that spung off of ffmpeg [19:11] <Sidious> so snow is ffmpeg trying to challenge h264 [19:11] <JEEB> no [19:11] <JEEB> snow was just people playing with wavelets [19:11] <JEEB> and it shows you why wavelets are hard [19:11] <JEEB> see where it is quality-wise [19:12] <Sidious> why is vc1 missing in that list [19:12] <JEEB> because the guy who made the test didn't have Expression Encoder on hand and didn't thus have a way of running the test? [19:12] <saschagehlich> guys, is there anything i can do to get a good quality gif with 256 colors instead of 128? [19:12] <Sidious> isn't there free version of expression encoder [19:13] <JEEB> yes [19:13] <JEEB> the source should be available on that page so if you really want to check, you could do the test yourself [19:13] <JEEB> naturally it'd be fair to redo the whole test with newer versions of everything if you really wanted [19:14] <Sidious> i wonder if x264 one of the first h264 encoders [19:14] <Sidious> or it came much later [19:15] <JEEB> Started in 2004, which is a year after the first official spec. I remember people using Nero and friends for H.264 at the beginning [19:15] <JEEB> (which was in 2005 or so) [19:15] <Sidious> oh, so nero is one of the first ones, huh [19:15] <JEEB> no idea [19:16] <jeremyagost> h.264 was a pain in the ass back then [19:16] <Sidious> nero is not in the list either [19:16] <Sidious> jermyagost why you say that [19:16] <JEEB> Sidious, a single guy or so made that test, it can't have everything [19:16] <JEEB> also I think Nero might have just licensed something nowadays [19:16] <JEEB> no idea [19:17] <JEEB> wouldn't be surprised if they just licensed MainConcept like the rest [19:17] <Sidious> jeeb then you should different qualitychart that has bigger list for reference [19:17] <jeremyagost> because it took forever to encode compared to xvid or somesuch [19:17] <JEEB> if you want to compare current H.264 encoders check out MSU's test [19:17] <Sidious> jeremyagost i see; you really seem to care about encoding speed [19:18] <JEEB> http://compression.ru/video/codec_comparison/h264_2012/ [19:18] <jeremyagost> yes, it's definitely a factor in comparing codecs [19:18] <Sidious> jeremyagost why? that's the last thing i care about [19:19] <JEEB> Sidious, for various reasons [19:19] <JEEB> stop asking stupid questions like that [19:19] <JEEB> also x264 can be _very_ fast if you just use one of the faster presets [19:19] <Sidious> jeeb who cares about 1-5 minute faster [19:19] <JEEB> uhhh [19:19] <JEEB> you should really compare --preset superfast and --preset veryslow in x264 [19:20] <jeremyagost> yeah, why don't you go do that now [19:20] <jeremyagost> in fact, don't report back until you've done several tests with veryslow [19:20] <Sidious> jeeb i just use handbrake; how do i do that in handbrake [19:20] <JEEB> Sidious, handbrake afaik doesn't let you select the preset still for some dumb reason [19:20] <JEEB> even though it's an internal x264 thing [19:20] <dericed> Hey all. I have to give a presentation on the efficiency (or not) of jpeg2000 and am looking for opinions on this codec. Any quotes? [19:21] <jeremyagost> well in the advanced tab you can probably add it [19:21] <jeremyagost> I've never tried [19:21] <jeremyagost> there's an additional command line options box [19:21] <JEEB> the last I remember reading from their forums you had to manually recreate them or something [19:21] <JEEB> dericed, I think D_S made some stuff regarding jpeg2000 a few years ago [19:22] <jeremyagost> I've seen it used a lot for low-framerate video [19:22] <jeremyagost> in embedded devices and the like [19:22] <Sidious> jeeb your second list does not even have qt [19:22] <dericed> JEEB: gotta citation? [19:22] <JEEB> Sidious, because it's awful and Apple didn't provide anything for the test [19:23] <JEEB> dericed, http://x264dev.multimedia.cx/archives/317 [19:23] <Sidious> i wonder why is apple letting that happen; they have a lot of $$$ [19:23] <JEEB> because they don't give a <beep> [19:23] <JEEB> the last time someone asked they just told the guy to upload to youtube and have it encode it [19:24] <Sidious> they should, apple is all about multimedia [19:24] <JEEB> it's not a priority [19:24] <jeremyagost> no, not really [19:24] <Sidious> i forgot about youtube; what encoder do they use [19:24] <JEEB> they had a custom one written by one guy at the beginning of H.264 usage with flash, then they quickly switched to x264 [19:25] <Sidious> jeeb wow really? [19:26] <JEEB> yes? [19:26] <Sidious> even google gave up on h264? [19:26] <sacarasc> IIRC, YouTube uses a modified ffmpeg too, doesn't it? [19:26] <JEEB> uhh, if there's a better alternative for free [19:26] <JEEB> why not use it? [19:26] <Sidious> what is up with all these $$$ companies cannot even make decent encoder [19:27] <JEEB> because it's really hard and not worth it if there's an already capable one? [19:27] <Sidious> jeeb sure google could use symbian too ; but they made their own android [19:27] <JEEB> symbian became open source way after android came out :P [19:27] <JEEB> and they happened to buy the company that was developing android IIRC [19:28] <Sidious> jeeb why did apple make IOS then? [19:29] <Sidious> if you are going to use that logic [19:29] <JEEB> because they wanted to? [19:29] <JEEB> I'm not pushing any weird logic here [19:29] <Sidious> jeeb and they are capable of making it too [19:30] <Sidious> <JEEB> the last time someone asked they just told the guy to upload to youtube and have it encode it [19:30] <Sidious> lol that's funny [19:31] <Sidious> can you actually use youtube as x264 encoder [19:31] <JEEB> only for what they do [19:32] <JEEB> btw, MS made their own H.264 encoder too for MEE3 [19:32] <JEEB> they removed it and switched to MainConcept with MEE4 [19:32] <JEEB> it was that bad [19:32] Action: JEEB tested it once [19:33] <Sidious> jeeb how do you know all this? how did you know they used mainconcept [19:34] <JEEB> because the old H.264 encoder library was taken away and you have MainConcept's encoder libraries there instead? [19:34] <JEEB> because an MS person on doom9 talked about how they updated the MC encoder library at one point within the 4.x MEE? [19:34] <Sidious> why didn't mee4 use x264 libraries [19:34] <JEEB> why don't you ask MS that? [19:34] <JEEB> many people who were/are using MainConcept are switching to x264 tho [19:34] <Sidious> maybe mainconcept is better than x264 [19:34] <JEEB> in general, it isn't [19:35] <JEEB> check the MSU test PDF [19:35] <JEEB> MainConcept just used to be the only "cheap" H.264 encoder/decoder library available for a very long time [19:35] <JEEB> so everyone started licensing it [19:36] <Sidious> i see; and who is most expensive [19:37] <JEEB> dunno, probably one of those "pro" blu-ray encoders for non-hardware encoders [19:37] <JEEB> blu-code and so forth [19:38] <Sidious> how expensive is x264? is it more expensive than mainconcept [19:38] <JEEB> I would guess in most/all cases it's cheaper than mainconcept [19:39] <JEEB> http://www.x264licensing.com/ [19:39] <JEEB> "We charge on average less then $1.00 USD per unit with a required minimum of 5,000 to 10,000 units." [19:39] <Sidious> if that is true, there must be a reason mee4 uses mainconcept over x264 [19:39] <JEEB> because the license deal was done before x264 had double licensing? [19:40] <JEEB> because MS would prefer to deal with mainconcept than open source? [19:40] <JEEB> x264 was cheaper and thus wasn't selected? [19:40] <JEEB> I mean, plenty of reasons why not, and not like we know [19:40] <Sidious> if x264 is better and cheaper, then it's no brainer [19:41] <JEEB> yes, if that's all you care about [19:41] <JEEB> companies are companies [19:41] <JEEB> also I'm pretty sure the licensing deal was made before x264 had double licensing [19:41] <Mavrik> OpenSource aversion is a serious problem [19:41] <JEEB> but hell do I know [19:41] <Mavrik> I had to constantly battle uphill when I was driving adoption of x264 in my previous company [19:41] <Sidious> "double" licensing? [19:41] <Mavrik> :\ [19:42] <JEEB> Sidious, GPL for open source, and nonfree licensing for people who don't want to follow the GPL [19:42] <JEEB> just like Qt f.ex. which has LGPL, GPL and nonfree [19:42] <Sidious> oh [19:43] <JEEB> plenty of companies are beginning to license x264 tho [19:43] <Sidious> why did it took so long for x264 to have double license [19:44] <JEEB> Because no-one thought of it at first? They had to start an LLC? Because when the licensing was changed everyone whose code was in had to agree? [19:45] <Sidious> x264 is pretty good right now but 2 years ago it sucked really bad [19:45] <JEEB> no [19:45] <JEEB> two years ago it was already best of its class [19:46] <JEEB> check older MSU tests if you don't believe me, and the damn picture I showed was from 2009 [19:46] <Sidious> because all the video that has handbrake 0.9.3 tag is all bad [19:46] <JEEB> it is not the tool, it is how that tool was used [19:46] <sacarasc> Blaming an encoder for a front end is bad. :p [19:46] <Sidious> every handbrake 0.9.3 encoded video sucked [19:46] <dericed1> JEEB: I remember Jason's post on how to run a bad visual quality evaluation [19:47] <Sidious> handbrake 0.9.3 = x264 core 65 [19:47] <dericed1> basically with the digital audiovisual archiving community, it's all about jpeg2000 and there's only a handful using ffv1, so i'm presenting on this [19:47] <Sidious> how old is x264 core 65 [19:47] <JEEB> from around 2008 or so? not surer [19:48] <JEEB> but it should still give relatively good results [19:48] <JEEB> if set properly [19:49] <Sidious> jeeb all handbrake 0.9.3 video sucked [19:49] <JEEB> so? [19:50] <Sidious> handbrake 0.9.3 = x264 core 65 [19:50] <JEEB> so? [19:50] <JEEB> <sacarasc> Blaming an encoder for a front end is bad. :p [19:50] <JEEB> <JEEB> it is not the tool, it is how that tool was used [19:50] <Sidious> x264 core 65 = sucks [19:50] <JEEB> good conclusions, yo [19:50] <Sidious> it's fair conclusion [19:51] <JEEB> it really isn't [19:51] <JEEB> a couple of releases after 0.8.6 in VLC had x264 built with a bad compiler [19:51] <JEEB> do you blame x264 for the result of a badly compiled binary? [19:51] <JEEB> seriously guy, get a fucking grip [19:51] <Sidious> huh vlc is player not encoder [19:52] <JEEB> it is an encoder as well [19:52] <JEEB> it can stream [19:52] <Sidious> i dont' know anybody who use vlc to encode video [19:52] <JEEB> I've streamed from a computer in Japan to myself in Finland just fine with it [19:52] <JEEB> it's the easiest way of doing live streaming [19:53] <Sidious> oh okay [19:53] <JEEB> (you can pretty much couple-click yourself an mpeg-ts stream via http) [19:53] <Sidious> i can blame x264 for handbrake 0.9.3 sucking [19:53] <JEEB> no, you can't [19:54] <Sidious> unless it's not a h264 video [19:54] <JEEB> a highly limited frontend, and no idea why exactly it sucked [19:54] <JEEB> you're comparing and making logical lines where you shouldn't [19:56] <Sidious> but it's still using x264 as video; as you said earlier container has nothing do with video quality [19:56] <JEEB> is it that hard to understand that you have no idea why exactly the video quality sucked? [19:56] <JEEB> neither do I [19:57] <JEEB> heck, it could even be something like what happened with VLC once, they just kept packaging a BROKEN X264 BINARY in there [19:57] <JEEB> but I'm more likely to blame just crappy settings [19:57] <Sidious> Writing library : x264 core 65 [19:57] <Sidious> Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:1.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-4 / threads=12 / nr=150 / decimate=1 / mbaff=0 / bframes=6 / b_pyramid=1 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / keyint=30 / keyint_min=16 / scenecut=40(pre) [19:57] <Sidious> / rc=2pass / bitrate=1136 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00 [19:58] <Sidious> does that help [19:59] <JEEB> not really, I'd prefer actual x264 command line -wise settings, f.ex. parsing the "analyse" part is derp, and it's just harder to read [19:59] <JEEB> that said [19:59] <JEEB> that actually looks newer than I thought [19:59] <JEEB> it has psy-rd and friends [20:00] <JEEB> > keyint 30 [20:00] <JEEB> wat [20:00] <Sidious> what is that? [20:00] <Sidious> is that bad [20:01] <JEEB> well, some of those settings are OK. But I really can't read them all, like the analyse one which isn't really human-readable [20:01] <JEEB> keyint is the maximum distance between keyframes [20:01] <JEEB> also I can't read what direct=3 is [20:02] <JEEB> also, I have no idea if those various ratios are default or not [20:03] <JEEB> anyways, sorry I don't have any will to drag on this dumb discussion with you [20:03] Action: JEEB has some work to finish [20:03] <Sidious> it got better in core 80 [20:03] <Sidious> Writing library : x264 core 80 [20:03] <Sidious> Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.0:0.0 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / mbaff=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=1 [20:03] <Sidious> / wpredb=0 / wpredp=2 / keyint=300 / keyint_min=30 / scenecut=40 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 [20:04] <JEEB> see at keyint [20:04] <JEEB> then you have switched to crf from bitrate-based [20:04] <JEEB> you probably want to compare them on an even ground, but I bet you won't be able to do that :P [20:04] <JEEB> anyways, off [20:23] <saschagehlich> guys, is there anything i can do to get a good quality gif with 256 colors instead of 128? [21:23] <Ganymede> I'm interested in thumbnailing hundreds of video files. It's pretty trivial to make a thumbnail using ffmpeg but my only question is how do I choose a good value for -ss? What are other people doing in order to make sure it chooses an interesting and meaningful frame (rather than just a black screen)? I am interested in either making 1 thumbnail or about 3 thumbnails per video. Another concern is that the [21:23] <Ganymede> videos are of variable length and may be as short as 1 minutes so just blindly doing -ss 1:30 may go out-of-bounds for some videos. [21:36] <saste> Ganymede: check select filter, and the scene variable [22:12] <gmarkall> hi - i was trying to cut the first 3 seconds off a video with: ffmpeg -ss 00:00:03 -i video.mpg -acodec copy -vcodec copy video-cut.mpg -- however, the output begins with a grey screen and then a few frames are messed up. [22:13] <gmarkall> I got a warning about the video not beginning with a key frame - i presume this is the problem. Would someone be able to guide me as to what to do please? Is there a way to cut at the neareest key frame to a specific time? Many thanks in anticipation [22:22] <Ganymede> I must be missing something here: "ffmpeg -i dbz249-l.mp4 -vf select='gt(scene\,0.4)',scale=160:120,tile -frames:v 1 preview.png" results in the error: [select @ 0x6c4400] [Eval @ 0x7fff2221c0d0] Undefined constant or missing '(' in 'scene,0.4)' [select @ 0x6c4400] Error while parsing expression 'gt(scene,0.4)'. The ffmpeg documents use this as an example. I can't see any escaping issues here. [22:24] <Ganymede> gmarkall: To split videos, when other programs didn't cut smoothly, I've had success with mkvmerge: "mkvmerge infile.mpg --split timecodes:0:3 outfile.mkv". However, then your output will be in MKV format. [22:53] <gmarkall> Ganymede: thanks - do you mean there might also be something slightly wrong with my source video? [23:05] <Ganymede> gmarkall: Sorry, I don't know. [23:07] <Ganymede> gmarkall: Oh, there's also "mencoder -oac copy -ovc copy -ss 3" or something like that. From what I recall, mencoder automatically seeks towards frames where it can cut smoothly. [23:07] <Ganymede> gmarkall: If you don't NEED to do this on the command line, avidemux can cut videos visually but I use it largerly for AVI / DivX/ Xvid and haven't used it for .mpg files. [23:20] <gmarkall> Ganymede: thanks I'll give mencoder/avidemux a try [00:00] --- Sun Aug 12 2012