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

[burek]

[00:00] <JodaZ> hmm, i see
[00:00] <JodaZ> so whats that fancy new 10bit stuff ?
[00:01] <Mavrik> good question... I think the guys on #x264 are better equipped to answer that, since x264 is prbably the only one that supports 10bit :)
[00:32] <Mavrik> man, ffmpeg makes a mess of VP8 encoding
[00:35] <darkstarbyte> I would say so
[00:35] <darkstarbyte> I wanted to use it once
[00:35] <darkstarbyte> I decided to just use x264
[00:35] <darkstarbyte> since they are related
[00:36] <Mavrik> x264 is better in every aspect
[00:36] <Mavrik> but... clients wanna have what they wanna have -_-
[00:36] <darkstarbyte> yeah
[00:38] <teratorn> in every aspect except that it's proprietary
[00:38] <darkstarbyte> High school of the dead
[00:39] <darkstarbyte> The encoder is free
[00:39] <darkstarbyte> You just have to pay royalties for the converted content after 2016
[00:39] <Mavrik> teratorn, that argument is only valid once we see what vp8 is.
[00:39] <Mavrik> teratorn, plus, x264 is GPL ;)
[00:39] <darkstarbyte> vp8 and h264 are related
[00:40] <darkstarbyte> The techniques are patented
[00:40] <teratorn> GPL is a problem for a lot of folks
[00:40] <JEEB> x264 has a commercial license if one is needed >_>
[00:40] <darkstarbyte> frame prediction stuff is patented
[00:40] <teratorn> darkstarbyte: you're saying vp8 is patent-encumbered?
[00:41] <darkstarbyte> There are patents on it, but google bought them
[00:41] <JEEB> orly
[00:41] <JEEB> I think no-one actively said that it's "safe to use"
[00:41] <JEEB> it's taken for granted :)
[00:41] <darkstarbyte> Hi JEEB
[00:42] <cbreak> it's software
[00:42] <darkstarbyte> and?
[00:42] <cbreak> which countries accept software patents?
[00:42] <darkstarbyte> US
[00:42] <cbreak> just only sell in the others
[00:43] <darkstarbyte> Japan might, but I have never looked into it.
[00:43] <JEEB> anyways, IANAL and if you're thinking about officially using pretty much any tech I recommend you visit a lawyer >_>
[00:43] <cbreak> anyway, patents are a national thing anyway
[00:43] <cbreak> they are only worth anything in the country that granted them.
[00:43] <Mavrik> of course
[00:43] <Mavrik> but if you get killed off of a 200 mil market online... that's quite a hit
[00:44] <darkstarbyte> I think copyrights work the same way
[00:44] <Mavrik> especially since covering rest of the world is annoying
[00:44] <cbreak> copyrights aren't granted on request
[00:44] <cbreak> they are granted for everything
[00:44] <Mavrik> darkstarbyte, I think most of the world consders copyright a default
[00:44] <cbreak> and they are recognized with some agreements between countries
[00:44] <ptriller> is it possible that libvo_aacenc is unable to encode 5.1 6 channel audio, I can't get conversion from AC3 5.1 to AAC 5.1 to work
[00:45] <cbreak> if I write a Poem or make a picture, then those have my copyright, and most countries accept that
[00:45] <darkstarbyte> vorbis might
[00:45] <JEEB> ptriller, I think I remember someone saying that it has limitations with >2ch
[00:45] <ptriller> JEEB, thanks, at least now I know I am not just incompetent :)
[00:45] Action: cbreak would not compress ac3 further
[00:45] <JEEB> yeah
[00:45] <JEEB> diminishing returns
[00:46] <cbreak> at least not without converting to stereo or something
[00:46] <JEEB> aye
[00:46] <darkstarbyte> I am sure vorbis will do it, but I will check
[00:46] <cbreak> (for devices like iThings)
[00:46] <cbreak> then you could hard code something like hrtf
[00:47] <darkstarbyte> It says vorbis is not good for multichannel
[00:47] <darkstarbyte> Its good for
[00:47] <darkstarbyte> <3ch
[00:48] <darkstarbyte> I for that from a form 6 years old
[00:48] <darkstarbyte> for = got*
[01:26] <EOF-sensei> I built ffmpeg against libx264
[01:26] <EOF-sensei> but it doesn't seem to be able to find my libx264.so.120
[01:27] <EOF-sensei> even though it's clearly in /usr/local/lib
[01:27] <EOF-sensei> what might I[t] be doing wrong?
[01:38] <EOF-sensei> bumpe
[01:39] <EOF-sensei> ffmpeg: error while loading shared libraries: libx264.so.120: cannot open shared object file: No such file or directory
[01:46] <Mavrik> hmm
[01:46] <Mavrik> EOF-sensei, either you didn't run "ldconfig" yet or you're trying to load a x86 lib to a x64 process
[01:46] <Mavrik> EOF-sensei, do run "ldd ffmpeg" and see if it finds the .so
[01:48] <relaxed> EOF-sensei: sudo echo "/usr/local/lib" >> /etc/ld.so.conf; sudo ldconfig
[01:49] <EOF-sensei> needed to run ldconfig
[01:49] <EOF-sensei> remembered a few minutes ago
[01:49] <relaxed> ok
[01:49] <EOF-sensei> I wish that sort of thing were automated
[01:50] <EOF-sensei> caching and indexing daemons should really try to be transparent if they exist at all
[01:50] <EOF-sensei> in my humble opinion...
[01:50] <relaxed> well, your package manger does that when installing libs
[01:51] <relaxed> manager*
[01:52] <EOF-sensei> I guess I haven't used shared libraries right after compiling them frequently enough to remember to run ldconfig
[03:40] <chcha> Is there anyone has some information about build ffmpeg with stagefright?
[03:40] <chcha> I don't know how to do that exactly...
[05:53] <EOF-sensei> chcha: ./configure --enable-libstagefright
[07:21] <chcha> <EOF-sensei> chcha: ./configure --enable-libstagefright is that all?
[07:32] <EOF-sensei> if libstagefright is all you want
[07:33] <EOF-sensei> if you don't know what I'm talking about then yes
[08:11] <chcha> Actually I was using ffmpeg on android phone to use custom codec based on h.264 codec over rtsp.
[08:16] <chcha> For the performance issue, we decided to use standard h.264 codec but, some Android phone don't show rtsp stream with Android Multimedia Framework.
[08:17] <chcha> So, I'd like to know It's possible switching between ffmpeg and stagefright according to the phone's capability.
[08:17] <chcha> Anyway, libstagefright is not all I want :)
[08:18] <EOF-sensei> hmm
[08:18] <EOF-sensei> well
[08:18] <EOF-sensei> rather
[08:18] <EOF-sensei> what I meant is
[08:18] <EOF-sensei> of the libraries that ffmpeg is capable of linking in
[08:18] <EOF-sensei> s/libraries/extra libraries/
[08:19] <EOF-sensei> is libstagefright the only one you want?
[08:19] <EOF-sensei> considering you could be wanting to use say, x264
[08:19] <EOF-sensei> or work with jpeg2000 sequences
[08:19] <EOF-sensei> ;p
[08:20] <EOF-sensei> chcha: there should be a way to switch between libstagefright and the standard h.264 codec
[08:20] <EOF-sensei> but I don't know it
[08:20] <EOF-sensei> ;p
[08:20] <EOF-sensei> I'm a noob
[08:20] <darkstarbyte> ¿pyPoqŽÝž Žo e‡1 ƒuoy s1 ‡PeM
[08:22] <EOF-sensei> darkstarbyte: yeh, good luck...
[11:19] <burek> halp :)
[11:20] <burek> http://pastebin.com/S7yYzq3G
[11:20] <burek> libass says it cannot create track from .ass file
[11:21] <burek> I've created .ass file with subtitleeditor, using File - Save As... (and selected .ass extension)
[11:22] <burek> this is the .ass file: http://pastebin.com/3iB9HsL9
[11:27] <cbsrobot> burek: this does not look like an ass file.
[11:29] <burek> hm, ok
[11:29] <burek> thx
[11:32] <cbsrobot> burek: http://en.wikipedia.org/wiki/SubStation_Alpha
[11:32] <sacarasc> Yeah, that looks like basic SRT.
[11:33] <burek> yes, i was suspecting on that :)
[11:33] <burek> i've used subtitle composer to save as .ass and now it works :)
[11:33] <burek> thanks guys :beer: :)
[11:57] <eakin> hi all, I have a windows media player plugin embedded in my html, I am referencing an mp4 video from an external website, the video plays but the progress bar doesn't move, any idea why or how to resolve this?
[12:04] <jermy> Can I typically speed up decoding of interlaced H.264 content that I intend to then scale anyway by only decoding a single field?
[12:05] <jermy> Or are fields often dependent on each other?
[12:05] <Tjoppen> I susepct the answer to that question is "it depends"
[12:05] <JEEB> other field can very well be dependant on the other one
[12:05] <JEEB> thus, no
[12:06] <jermy> fair enough
[12:06] <jermy> I really do despise interlacing
[12:06] <nifan> When i try to use "-strict experimental" ffmpeg says "Invalid value 'strict' for option 'experimental'" using ffmpeg version 0.8.9 any idea what i'm doing wrong ?
[12:07] <jermy> Tjoppen/JEEB: I guess it depends on if the top field ever has dependencies on the bottom field of the previous frame
[12:08] <JEEB> jermy, or the other way, H.264 can have biprediction
[12:08] <jermy> Indeed
[12:10] <jermy> In any case, if I am going to throw away half the picture, is there anything less work I could make a decoder do?
[12:11] <jermy> (this is more of a theoretical question than a ffmpeg-specific one)
[12:12] <JEEB> not really
[12:12] <JEEB> calculating if a frame's parts depend on other parts will mostly end up making you do MORE work >_>
[12:17] <jermy> I guess I'll have to see if I can make sure I'm not passing anything I don't need into the filtering stage
[12:21] <jermy> any also try to work out why the h264 decoder segfaults when we ask it to run with multiple threads
[12:22] <jermy> s/any/and/
[12:33] <isset_> why doesn't ffmpeg show me the duration while converting
[12:34] <jlue> what's the syntax for image2 input, please? Using "ffmpeg -y -an -i "Plate28_1/Plate28_1.0000%d.jpg" -f image2 -vcodec libx264 -b:v 1024k -vpre slow Plate28_1.mp4" fails in version 0.9.1.
[12:38] <eakin> ok the seek bar works for my mp4 video via VLC but not with windows media player, any idea why?
[12:39] <cbreak-work> what are plausible pts/dts values for passing into an AVPacket?
[12:39] <cbreak-work> 0, 1, 2, 3, 4, 5 and so on?
[12:50] <Tjoppen> any values where dts monotonically increases and pts >= dts
[13:35] <ph1b> hey. I wanna crop a video using -vf but how can I find out the right coordinates of the area to be cropped? Just made a screenshot using totem but now the screenshot is bigger than the original video (764 vs 720)
[13:36] <Mavrik> is it anamorphic?
[13:36] <ph1b> what that means?
[13:37] <Mavrik> ph1b, do a ffprobe on the video and see if PAR/DAR/SAR values are different than 1:1
[13:37] <Mavrik> that means that pixels aren't square in video
[13:37] <ph1b> 16:15
[13:38] <ph1b> so i just have to correct my cropping results by this factor?
[13:38] <Mavrik> ph1b, hmm, probably not
[13:38] <Mavrik> you should just use the coordinates from Totem screenshot (the bigger one)
[13:38] <Mavrik> if I remember correctly the decoded images aren't anamorphic and video filters work on decoded images
[13:40] <ph1b> That what leads me to this forum. I tried a
[13:40] <ph1b> ffmpeg -i kkurz.vob -vcodec libx264 -acodec libvo_aacenc -b 1024 -ab 128k -vf '749:574:13:0' -ss 50 -t 30 output.mkv
[13:40] <ph1b> but result is:
[13:40] <ph1b> [buffer @ 0x1b20ec0] w:720 h:576 pixfmt:yuv420p
[13:40] <ph1b> No such filter: '749:574:13:0'
[13:40] <ph1b> Error opening filters!
[13:40] <Mavrik> ph1b, yeah, you didn't specify the video filter
[13:40] <Mavrik> -vf crop=749:574:13:0
[13:41] <Mavrik> the -vf is in form of
[13:41] <Mavrik> -vf [filter1]=[filter1parameters],[filter2]=[filter2parameters]...
[13:41] <ph1b> Ah, thanks.
[13:41] <ph1b> [buffer @ 0xc3fec0] w:720 h:576 pixfmt:yuv420p
[13:41] <ph1b> [crop @ 0xc41380] w:720 h:576 -> w:748 h:574
[13:41] <ph1b> [crop @ 0xc41380] Invalid too big or non positive size for width '748' or height '574'
[13:41] <ph1b> Error opening filters!
[13:42] <Mavrik> um yea
[13:43] <Mavrik> why are you trying to crop an image from coordinates 749,574 when your video is only 748x574 big? :)
[13:44] <Mavrik> ph1b, http://ffmpeg.org/libavfilter.html#crop
[13:44] <ph1b> the screenshot says:768x576
[13:45] <Mavrik> hmm
[13:45] <Mavrik> ph1b, you'll have to multiply by 15/16 then to get right size
[13:45] <Milos> If I have a stream at http port 4242 at URI /herp/derp how can I grab this and restream it on another port etc?
[13:45] <Milos> Is this possible with ffmpeg alone?
[13:46] <Mavrik> ph1b, I guess I was wrong about decoder fixing anamorphic images
[13:46] <Mavrik> Milos, ffmpeg can grab UDP and simillar streams, I'm not sure if it can do HTTP downloads
[13:46] <Milos> I see
[13:47] <Mavrik> but I somehow doubt you have a HTTP stream on 4242 port ;)
[13:48] <Milos> I do
[13:48] <Milos> that's why I asked
[13:48] <Milos> o-o
[13:48] <Milos> fail
[19:27] <DrSlony> Hey, which do you recommend I use when ripping a DVD, MPEG-1 layer III, or AC3?
[19:29] <JEEB> for LCPM DVDs and stuff with ridiculously high bitrate DTS/AC3 (2ch with 400+kbps f.ex.) there's neroaacenc/aotuv's vorbis, I'd usually leave 5.1ch AC3 stuff as-is
[19:29] <llrcombs> AC3
[19:30] <llrcombs> you might be able to get away without transcoding at all
[19:30] <llrcombs> just reencapsulate
[19:30] <newl> use vobcopy -> avi
[19:30] <llrcombs> that also works
[19:30] <llrcombs> what do you intend to play this on, anyway?
[19:31] <llrcombs> if you can get away with just reencapsulating and/or merging VOBs, do that. Otherwise, there are a few things that might have to be done here...
[19:32] <DrSlony> llrcombs probably not on dvd players, just computers
[19:33] <llrcombs> DrSlony: what player, though? Not all players like MPEG2/AC3 AVIs
[19:33] <JEEB> why the avi love?
[19:33] <llrcombs> also, I usually prefer MKVs
[19:33] <DrSlony> i want to deinterlace, fix colors, etc
[19:34] <JEEB> you can properly do deinterlacing/IVTC and re-encode to H.264 in mkv, audio codecs by what I said first
[19:34] <llrcombs> yep
[19:34] <llrcombs> if you want to adjust colors and deinterlace, H.264->MKV is the way to go
[19:34] <JEEB> over-high-bitrate stuff you can deal with neroaacenc or aotuv's vorbis, and then the normal-bitrate stuff you can just remux as I said
[19:34] <llrcombs> usually if it's AC3 audio, you should just remux into the MKV
[19:34] <llrcombs> JEEB: ^5
[19:35] <JEEB> llrcombs, unless it's 400kbps+ AC3 for stereo
[19:35] <DrSlony> why mkv and not mp4?
[19:35] <llrcombs> JEEB: what then?
[19:35] <JEEB> DrSlony, more freedom of choice with video/audio codecs
[19:35] <JEEB> llrcombs, then re-encoding it to vorbis/aac with a good encoder is somewhat viable
[19:35] <JEEB> as well as subtitles
[19:36] <JEEB> oh, and chapters
[19:36] <llrcombs> MKV's overall a better encapsulation format, as you can pack just about anything into it, and it hints well for web. Also, subs. Still, if you can't play MKVs in your player, then MP4s and MOVs are still an option
[19:38] Action: newl plays whatever he gets 
[19:38] <newl> my tv card gives me avi so i like avis
[19:39] <newl> the best from youtube is webm/mkv so i play that :)
[19:39] <DrSlony> do you know of any GUIs that would let me use x264 and deinterlace and optionally show a preview of the video so that i can crop?
[19:39] <newl> kino?
[19:39] <JEEB> I would probably use avisynth + AvsPmod
[19:39] <JEEB> and then command line x264
[19:39] <JEEB> of course, this is in no way the easy path :P
[19:40] <JEEB> but usually quite worth it if you want to do something "properly"
[19:40] <DrSlony> using avisynth in liux is meh
[19:40] <JEEB> well, yes
[19:40] <newl> why the x264 love?
[19:40] <JEEB> newl, I would rather ask why not
[19:40] <JEEB> > easy to use > currently the best compression ratio and speed available
[19:40] <DrSlony> why not the x264 love
[19:40] <DrSlony> heh exactly
[19:41] <DrSlony> hm
[19:41] <JEEB> avs on linux via wine is a bit of a meh, but IIRC AvsPmod has been fixed
[19:41] <JEEB> or well
[19:41] <DrSlony> methink i'll use avidemux2
[19:41] <JEEB> "suddenly started working after we updated the base"
[19:41] <newl> webm is best size and quality ?
[19:41] <JEEB> lol
[19:41] <JEEB> webm is a container format
[19:41] <JEEB> vp8 is a video codec
[19:41] <JEEB> vorbis is an audio codec
[19:42] <JEEB> and libvpx that encodes vp8 is unfortunately A) slow B) worse off than baseline x264 still
[19:42] Action: newl still has no clue why they make this container format distinction - just to separate us who know little from those who actually know
[19:42] <llrcombs> new1: actually, YouTube's highest-quality file is currently an MP4 with H.264
[19:43] <llrcombs> http://en.wikipedia.org/wiki/YouTube#Quality_and_codecs
[19:43] <newl> mp4 with h.264 is the best but on a 650Mhz it don't play
[19:43] <newl> it is huge too
[19:43] <llrcombs> the MPEG4 goes up to 2304p
[19:43] <llrcombs> (AAC audio)
[19:43] <JEEB> the libavcodec vp8 decoder is newly coded and somewhat faster than the H.264 one, yes
[19:44] <llrcombs> the WebMs go up to WUXGA (1080p), though
[19:45] <JEEB> but vp8 does not compress better than x264 generally, youtube does use crappy settings so the comparison isn't exactly valid by just checking youtube stuff >_> (and still H.264 usually ends up looking better)
[19:45] <JEEB> newl, they pretty much called a subset of matroska "webm" to limit the features people would have to support + to have their own buzzword .-.
[19:47] <DrSlony> which fine overpaid body of people come up with these resolution combination names like WUXGA?
[19:47] <llrcombs> that's pretty much it, yeah
[19:47] <llrcombs> I think there are like 2 added features, both related to web streaming hinting
[19:47] Action: newl doesn't want to actually admit that he get the crap youtube flvs and only better formats if he wants to save something like http://www.youtube.com/watch?v=OYpwAtnywTk
[19:48] <llrcombs> Widescreen Ultra Extended Graphics Array
[19:52] <DrSlony> how do i do video stabilization with ffmpeg, is there an official version with that filter or is it only in git?
[19:55] Action: newl the only video he knows that was stabilized was the zapruder film
[19:55] <DrSlony> avidemux shows "mpeg-4 avc", is that an alternate name for H.264?
[19:56] <JEEB> yes
[19:56] <JEEB> H.264/AVC
[19:56] <JEEB> mpeg-4 part... 10 IIRC
[19:56] <DrSlony> thx
[19:56] <DrSlony> newl ...
[20:16] <isset_> why doesn't ffmpeg show the duration in the status prompt?
[20:37] <khali> does anyone know what output method ffplay uses? xv? opengl?
[21:17] <DrSlony> I have the following choice of audio codecs: mp3 (LAME), AC3 (Aften), AC3 (Lav), AAC (Faac). Which of those do you recommend?
[21:22] <khali> DrSlony: really depends on your (hardware) target and goals
[21:22] <khali> and video codec
[21:23] <khali> it's usual to go for mp3 with xvid, ac3 with mpeg2 and AAC with x264
[21:23] <khali> for hardware playback compatibility
[21:24] <DrSlony> h.264 for computer playback
[21:24] <DrSlony> mkv or mp4, not sure which
[21:24] <DrSlony> was told earlier mkv offers more options
[21:25] <khali> mkv is certainly better but mp4 is more portable in my experience
[21:25] <khali> with h.264 I'd do AAC for audio and mp4 for container
[21:26] <khali> this should play on pretty much everything
[21:26] <DrSlony> is AAC from FAAC better than the others?
[21:27] <DrSlony> i know nero is recommended
[21:29] <j-b-r> You don't really ever want to encode AC3 unless it's hardware specific
[21:29] <j-b-r> The only reason you see encodes with AC-3 is because the AC-3 audio came directly from a source, and it was better to keep it intact than to re-encode it
[21:30] <j-b-r> You don't really want to use mp3 if you have a more modern option like AAC, but Faac really is pretty bad (you're correct, Nero would be the best choice, if possible)
[21:31] <j-b-r> I'd just use Faac and not care too much, unless you're working in a situation where you're transcoding some other audio source, in which case I'd see about keeping the original audio intact
[21:31] <DrSlony> the original is AC-3 48000Hz 224kbps
[21:32] <DrSlony> not sure converting it to AAC using the nero encoder @ say 160kbps 41000 would be worth it
[21:34] <j-b-r> If I was encoding for personal use I'd probably just go with the AAC, but if it was for distribution I'd probably keep the original audio unless it has way too many channels or something
[21:34] <newl_> DrSlony: no ogg?
[21:34] <JEEB> DrSlony, 224kbps is so low that you might as well remux it
[21:34] <JEEB> as-is
[21:35] <DrSlony> well this is for personal use, but im also wondering what works best for when i do screencasts for youtube
[21:35] <newl_> 224kbps low? - i guess you don't want to listen to my 32kpbs :)
[21:35] <DrSlony> JEEB low?
[21:35] <DrSlony> newl_ no, shit support
[21:35] <JEEB> DrSlony, "low enough that you won't be getting major gains from re-encoding"
[21:36] <newl_> mp3 is kinda universal
[21:36] <JEEB> 1400kbps LPCM -> ~200kbps AAC is still quite figurable f.ex.
[21:36] <newl_> DrSlony: ^^
[21:39] <DrSlony> btw is the term muxing reserved for DVDs/BluRays etc, or is it used simply for putting an audio and video stream into mkv or avi as well?
[21:41] <JEEB> muxing is generally used to refer putting streams into a container
[21:42] <DrSlony> thx
[21:56] <newl_> oh muxing i thought it said muffing  nvm
[22:54] <GuySoft> hi all, i need to encode a blender video i just made, its 1920x1080 , and needs to stay high quality. does anyone have a way to encode it?
[22:56] <khali> GuySoft: well... ffmpeg is exactly what you need, and obviously you know that, otherwise you wouldn't be there?
[22:57] <GuySoft> khali, yes, but i am not sure what flags to give, so something that large would stay in a decent quality
[22:58] <JEEBsv> is this for end users?
[22:58] <JEEBsv> or is this just you wishing to compress a lossless more for archival?
[22:59] <JEEBsv> :3
[23:02] <khali> GuySoft: just pass high quality flags to ffmpeg (there are good suggestions in the FAQ)
[23:03] <JEEBsv> khali: maybe you should actually wait until he tells you whatever he really wants
[23:03] <khali> GuySoft: if you do bitrate-based encoding, use a high bitrate; if quality based, use a high quality setting
[23:03] <JEEBsv> .-.
[23:03] <khali> JEEBsv: you're right, GuySoft did not provide enough information for me to reply anything useful
[23:03] <khali> that's what I'm writing bullshittish generalities for now ;)
[23:04] <JEEBsv> in any case, GuySoft -- make sure you have as new as possible ffmpeg built with libx264 and possibly with some other aac encoder than ffaac (internal)
[23:04] <JEEBsv> and do answer my question about what exactly will this encode be fore
[23:04] <khali> JEEBsv: is there anything else than faac? I didn't know
[23:05] <JEEBsv> libvo_aacenc
[23:05] <JEEBsv> and libaacplus, but that is for HE-AAC only IIRC
[23:05] <JEEBsv> libaacplus and faac are both non-distributable
[23:05] <JEEBsv> libvo_aacenc is a'OK as long as you build ffmpeg with GPLv3
[23:05] <JEEBsv> :)
[23:06] <khali> it's getting late, good nigh guys
[23:06] <GuySoft> khali, JEEBsv  i have a 1920x1080 mjpeg avi that takes up 2GB, and need to compress is somehow
[23:07] <newl_> boy those guys at fsf legal sure have suceeded putting the fear of legal into people without even one lawsuit
[23:07] <JEEBsv> GuySoft: which once again says nothing
[23:08] <newl_> 2GB = 2hours?
[23:08] <JEEBsv> is it for "end users" AKA "for people to watch on their PCs"? Or do you just want to compress that as much as possible losslessly?
[23:08] <GuySoft> newl_, no its made up of mjpeg files from blender
[23:09] <GuySoft> its around 800 frames
[23:09] <JEEBsv> Also, I do want to remind you that you'd probably want to use ffvhuff instead of MJPEG
[23:09] <JEEBsv> because MJPEG is not lossless the last I checked
[23:09] <GuySoft> JEEBsv, with 2GB i need to be losy now
[23:10] <JEEBsv> why can't you just say what exactly are you aiming at .-.
[23:10] <GuySoft> JEEBsv, er because i was hoping technical info would help.. but sure
[23:11] <GuySoft> JEEBsv, I have a blender animation, its 1920x1080 and takes up 2GB for 800 frames, and i need to sent it to the BBC
[23:11] <JEEBsv> to be further processed there?
[23:11] <GuySoft> JEEBsv, I don't know
[23:12] <GuySoft> JEEBsv, I think it wont be, they didn't specify a format
[23:12] <JEEBsv> so do they just want to take a look at it, or put it through their broadcast and thus re-encode it again?
[23:12] <cbreak> x264 has a lossless mode
[23:12] <GuySoft> JEEBsv, put it though a broadcast
[23:13] <JEEBsv> ok
[23:13] <cbreak> (or some very small loss settings)
[23:13] <cbreak> expensive to encode though
[23:13] <JEEBsv> so you want it to be as good as possible
[23:13] <GuySoft> JEEBsv, yep
[23:13] <JEEBsv> I'd just recommend you take that MJPEG then
[23:13] <JEEBsv> and put it onto a USB stick
[23:13] <JEEBsv> and take it there
[23:13] <JEEBsv> A) there's a big chance their systems will be able to read it and B) you certainly don't want to make it become any more lossy
[23:14] <GuySoft> JEEBsv, yes, but they wanted me to drop it in their dropbox.. now 2GB is a problem :)
[23:14] <GuySoft> JEEBsv, hmm, i just ran ffmpeg -i /mnt/sdc1/hawking_bbc0001_0800.avi -s 1920x1080 final_video.mp4 and it does not look like it was that lossy
[23:14] <GuySoft> its 20MB now
[23:15] <cbreak> 2gb is a problem?
[23:15] <cbreak> takes a few hours at most
[23:15] <JEEBsv> GuySoft: it is... it is very lossy :<
[23:15] Action: cbreak would not rescale
[23:15] <JEEBsv> also, seriously... dropbox for master clips...
[23:15] <JEEBsv> wtf
[23:15] <JEEBsv> (IIRC it had lulzy limits file size wise)
[23:16] <JEEBsv> of course, they might be paying for more space
[23:16] <JEEBsv> in any case, it's only 2GB and it's already lossy
[23:16] <GuySoft> JEEBsv, ah, didnt think of that
[23:16] <JEEBsv> general thought in a case like this would be: leave it as it is
[23:17] <JEEBsv> you've already raped it as MJPEG
[23:17] <JEEBsv> (it's not lossless)
[23:17] <cbreak> jpeg is quite lossy
[23:17] <cbreak> especially if your source was RGB 4:4:4
[23:17] <GuySoft> JEEBsv, its also not well compressed
[23:17] <JEEBsv> yes
[23:17] <GuySoft> JEEBsv, my PC can hardly display it like that
[23:18] <JEEBsv> well, I just wonder what exactly the BBC will be able to read from the lossless compression formats
[23:18] <JEEBsv> of course if they have ffmpeg or something available there they'd be capable of then converting to whatever they want on their side
[23:18] <JEEBsv> lossless H.264 with libx264 would most probably compress that thing nicely
[23:19] <JEEBsv> but that isn't supported by anything else but libavcodec
[23:19] <JEEBsv> (and CoreAVC)
[23:19] <GuySoft> JEEBsv, I am not sure how to get blender to produce that kind of stuff
[23:19] <cbreak> just tell them to get mplayer :)
[23:19] <JEEBsv> cbreak: seems like it's going into airing
[23:19] <JEEBsv> so it needs to be possible to get into their workflow
[23:19] <cbreak> well... mplayer can pipe out yuv4mpeg
[23:20] <JEEBsv> and ffmpeg can do a lot as well
[23:20] <cbreak> and ffmpeg can pipe out anything
[23:20] <JEEBsv> no need to bring mplayer out
[23:20] <JEEBsv> that's what I meant
[23:20] <JEEBsv> one tool needed only
[23:20] <newl_> a bbc technician getting advice here ?
[23:20] <JEEBsv> more like someone who was told to send his stuff up there
[23:20] <GuySoft> newl_, no, i got approached by them
[23:21] <JEEBsv> in any case, unless your internet really sucks
[23:21] <JEEBsv> I'd probably stick to just uploading the 2GB
[23:21] <JEEBsv> if you know they have some saner way of opening whatever you send there
[23:22] <JEEBsv> then you'd have some options for extra compression
[23:23] <JEEBsv> (basically if they don't have anything sane, the pretty much only sane'ish compressed formats would be exactly what you chose, which is, I think, MJPEG in AVI with WAV audio, or PNG in MOV for the quicktime users >_>)
[23:26] <cbreak> quicktime supports motion jpeg
[23:26] <cbreak> (3 versions even, last time I checked)
[23:27] Action: cbreak would compress the audio at least with something like FLAC, if they can decode that
[23:27] <JEEBsv> yeah, that's the problem
[23:27] <cbreak> didn't BBC develop their own video codec? Something super wavelet based? Snow :)
[23:27] <JEEBsv> we have no idea how they're equipped there
[23:27] <JEEBsv> nah, snow was separate
[23:27] <JEEBsv> BBC has Dirac
[23:27] <cbreak> right
[23:27] <JEEBsv> but even that has highly limited usage
[23:28] <JEEBsv> anyways, gonna say that sending out that MJPEG is probably currently the best idea if it's meant to go to some pipeline
[23:28] <JEEBsv> we have no idea what they support on the other side
[23:28] <JEEBsv> BBC seems like a capable house
[23:28] <JEEBsv> but derp
[23:28] <JEEBsv> we have NFI if we're dealing with the capable people or the button-pushers
[23:38] <newl_> JEEBsv: impossible for me to get any downloads from them
[23:38] <newl_> their site is horrendous too
[23:43] <EOF-sensei> JEEBsv: I wish dirac were worked on
[23:45] <EOF-sensei> though Dirac is nice for going between filtering setups
[23:45] <EOF-sensei> because it prefers correctness over perceived quality
[23:46] <EOF-sensei> (right now at least)
[23:46] <JEEBsv> is that... another weird way of saying 'it only has a lossless mode'
[23:46] <EOF-sensei> hmm?
[23:47] <EOF-sensei> it has lossy modes
[23:47] <EOF-sensei> they're just more psnr than ssim
[23:47] <EOF-sensei> which is probably not the best way to tune things for encoding consumer final render video
[23:47] <JEEBsv> you really do make no sense
[23:47] <JEEBsv> it's not the best way to tune ANY encoder
[23:47] <JEEBsv> that is lossy
[23:47] <JEEBsv> period
[23:48] <JEEBsv> PSNR = blurriness galore
[23:48] <EOF-sensei> it's the best way to tune a codec if you're going between mathematical operations that benefit from correctness and consistency more than perceived visual 'quality'
[23:48] <JEEBsv> SSIM has been found to be a much more better metric generally
[23:48] <JEEBsv> ok, you're making no sense so I'll just stop here
[23:49] <EOF-sensei> ssim has been found to be a better metric for perceived quality
[23:49] <JEEBsv> because if you think that PSNR is better than SSIM you're already having pants on your head
[23:49] <EOF-sensei> if you think either is 'better' you're obviously in way over your head
[23:49] <JEEBsv> they're just different ways of calculating "how close to original"
[23:50] <EOF-sensei> psnr is the overall correctness
[23:50] <JEEBsv> and PSNR has generally been shown to just love blurriness
[23:50] <EOF-sensei> it's a measure of error for well-aligned pixels
[23:50] <JEEBsv> which isn't gonna help with your mezzanine either
[23:50] <EOF-sensei> ssim is a measure of Structural SIMilarity
[23:51] <JEEBsv> I don't see any reason why I'd rather use a PSNR-optimized codec for a mezzanine than a SSIM optimized
[23:51] <EOF-sensei> you're thinking that all processes are used for the same things
[23:51] <JEEBsv> I just can't think why I'd rather have a blurred off picture
[23:51] <EOF-sensei> bbc needed a lossless or slightly lossy codec for production
[23:51] <EOF-sensei> and they work with some loss in their studios
[23:51] <JEEBsv> VS a picture with more details in it
[23:52] <EOF-sensei> it's better to have slightly blurrier images with better-aligned pixel values
[23:52] <EOF-sensei> than one with misaligned pixels and sharper details that may or may not be there
[23:53] <EOF-sensei> it's not PSNR versus SSIM
[23:53] <EOF-sensei> it's a matter of situation
[23:54] <JEEBsv> Yet encoder developers always cry at projects that have optimized for PSNR only and still do
[23:54] <JEEBsv> I really don't see why exactly in the end a PSNR-optimized one would be better off
[23:54] <JEEBsv> even for that limited use case
[23:54] <EOF-sensei> for distributing massive amounts of video that looks to the human eye 'sharp' over ultra-cheap consumer lines in a country with poor infrastructure (i.e. the U.S.) you generally use a DCT-based codec with optimizations targeting general sharpness rather than correctness
[23:55] <EOF-sensei> it's not about which one is universally better
[23:55] <EOF-sensei> psnr is a really good metric for correctness of pixels
[23:55] <EOF-sensei> ssim is a really good metric for perceived similarity when focusing on contrast
[23:56] <EOF-sensei> it's not about favoring one or the other either
[23:56] <EOF-sensei> because if you just optimized for ssim
[23:56] <EOF-sensei> that's all you'll get
[23:56] <EOF-sensei> higher ssim numbers
[23:57] <EOF-sensei> Dirac doesn't optimize for PSNR
[23:57] <EOF-sensei> it has good psnr by nature
[23:57] <EOF-sensei> because of the nature of the discrete wavelet transform
[23:57] <JEEBsv> glad to hear that they weren't completely bonkers :P
[23:58] <EOF-sensei> they wouldn't be if they went after psnr
[23:58] <EOF-sensei> if they optimized the hell out of psnr
[23:58] <EOF-sensei> there's a chance their ssim would be better as well
[23:58] <JEEBsv> AQ and similar things will lower SSIM, of course I have no idea how this applies to wavelets
[23:59] <EOF-sensei> you've been reading too much of Dark_Shikari 's blog by the way
[23:59] <EOF-sensei> you sound like a fucking parrot
[23:59] <EOF-sensei> try exploring the world of the discrete wavelet transform
[00:00] --- Tue Jan 17 2012