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

[burek]

[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