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

[burek]

[01:19] <kingsob> does encoding H.264/AVC using ffmpeg benefit from GPU's? I'm trying to determine if it would be beneficial to use Amazon's GPU optimized instances...
[01:20] <relaxed> no
[01:48] <iive> kingsob: ffmpeg uses libx264 library, so you can also ask there. afaik, you'll get the same answer.
[02:02] <Zeranoe_> I'm trying to get better playback out of libvpx, but it still seems to be steaming at like 1fps. I'm not even seeing full CPU usage
[02:03] <llogan> VP8 or 9?
[02:03] <GEEGEEGEE> I have a live video stream that has x264 video and aac audio, and I want to keep the same video data, but change the protocol to rtmp and -f flv. Is there a way to do this, or would I need to transcode it? I want x264 and aac as the output, but in flv and being sent to my rtmp server.
[02:03] <Zeranoe_> llogan, What does -c:v libvpx default to
[02:04] <llogan> vp8
[02:04] <kingsob> iive: yeah thanks, google seems to say no as well  :(
[02:05] <Zeranoe_> llogan, vp9 is no better, except now I get realtime buffer overflow messages
[02:06] <Zeranoe_> Command is: ffmpeg -f dshow -pix_fmt yuyv422 -s 640x480 -r 30 -i video="USB 2.0 UVC HD Webcam" -r 30 -c:v vp9 -an -f webm - | ffplay -
[02:06] <Zeranoe_>  
[02:06] <c_14> GEEGEEGEE: ffmpeg -i input -codec copy -f flv rtmp://url should do the trick
[02:07] <llogan> Zeranoe_: vp9 is too slow to be usable last time i checked more than a month ago
[02:07] <Zeranoe_> vp8? Is theora any better?
[02:07] <llogan> no
[02:08] <llogan> how do you know it's not the input device that is the issue?
[02:08] <Zeranoe_> I've seem some examples of people streaming live through html, I have it working but the codec speeds are killing me
[02:08] <Zeranoe_> llogan, ffplay handles it fine without lag
[02:08] <Zeranoe_> ?
[02:09] <Zeranoe_> No need for pb
[02:09] <llogan> you must be new here
[02:11] <llogan> i'm referring to your libvpx encoding speed issue. not the "ffplay can play input device just fine".
[02:12] <Zeranoe_> lol im not new here
[02:12] <llogan> i know.
[02:12] <llogan> but without your actual command i don't know what you're doing
[02:14] <Zeranoe_> Well i already said the command, just not the output. I'll add
[02:14] <llogan> your command had vp9. which is uselessly slow.
[02:15] <Zeranoe_> ffmpeg -f dshow -pix_fmt yuyv422 -s 640x480 -r 30 -i video="USB 2.0 UVC HD Webcam" -r 30 -c:v vp8 -an -f webm - | ffplay -
[02:17] <Zeranoe_> im really just looking for guidelines to improve vp8 encoding speed
[02:18] <llogan> i guess if you don't give a shit about quality you can add the private option "-quality realtime", but I'm fairly ignorant of this encoder.
[02:20] <llogan> there is http://trac.ffmpeg.org/wiki/vpxEncodingGuide but it does not go into details about encoding speed
[02:21] <GEEGEEGEE> c_14, thanks
[02:21] <GEEGEEGEE> would mp4 give better view quality at all? its looking a little blurred :/
[02:21] <llogan> Zeranoe_: also -speed option. i guess i should learn how to use this encoder.
[02:22] <llogan> GEEGEEGEE: are you stream copying with -codec copy?
[02:22] <GEEGEEGEE> yes
[02:22] <GEEGEEGEE> it should look the smae right
[02:22] <llogan> yes
[02:23] <GEEGEEGEE> oh i was on a SD channel instead of HD lol
[02:23] <GEEGEEGEE> nvm
[02:26] <llogan> Zeranoe_: http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-speed
[02:32] <Zeranoe_> llogan, Thats helpful, can I pass some of those options direct to libvpx though FFmpeg, or will I need to look into pipes
[02:36] <llogan> Zeranoe_: you can use it via ffmpeg, but the option named may be different. see "ffmpeg -h encoder=libvpx"
[08:25] <esperegu> I reinstalled my pc and when I run an old script&binary I now get the error: Specified probe size value 32 cannot be < 2048. I thought 32 is the minimum. anybody an idea what might cause this?
[11:21] <Katharsis> i have two notebooks with the same Debian version system (updated / upgraded)
[11:21] <Katharsis> one of them has ffmpeg 0.8.10, another ffmpeg 1.0.9
[11:22] <Katharsis> (i don't know why)
[11:22] <sacarasc> Are you using different repos?
[11:22] <Katharsis> nope
[11:22] <Katharsis> I check it
[11:22] <Katharsis> but this is not a proble
[11:22] <Katharsis> not a problem*
[11:22] <Katharsis> the problem is with recording screen with voice
[11:22] <sacarasc> Different mirrors of the same repo?
[11:22] <Katharsis> i used the same command on two of them
[11:23] <Katharsis> and one notebook (with ffmpeg 1.0.9) gives me mp4 with voice delay
[11:23] <Katharsis> i show you my command
[11:24] <Katharsis> ffmpeg -f alsa -i pulse -f x11grab -r 30 -s 1366x768 -i :0.0 -vcodec libx264 -r 25 -preset ultrafast -threads 4 -y -sameq $1
[11:26] <Katharsis> delay is not much when i used:
[11:26] <Katharsis> ffmpeg -f alsa -i pulse -f x11grab -s 1366x768 -i :0.0 -vcodec libx264 -preset ultrafast -threads 0 -r:v 30 -vsync 2 -async 1 $1
[11:26] <Katharsis> but it is still not the same result like in first notebook
[14:40] <sdfgsdfh> Does anybody know the difference between rgb24 and rgb0?
[14:40] <sdfgsdfh> Is rgb0 really 0 bpp?
[14:44] <klaxa|work> that sounds only useful for blank videos
[14:44] <klaxa|work> is it listed in ffmpeg -pix_fmts?
[14:45] <sdfgsdfh> well, FFV1 wants to default to it
[14:46] <sdfgsdfh> I was joking about the 0 bpp thing
[14:46] <sdfgsdfh> there is no way it's hat
[14:46] <sdfgsdfh> *that
[14:47] <klaxa|work> is it listed in ffmpeg -pix_fmts though?
[14:47] <klaxa|work> that should give you some clue maybe
[14:47] <sdfgsdfh> so we've got... 0rgb, rgb0, 0bgr, and bgr0, all listed
[14:48] <sdfgsdfh> they are listed as 24 bpp
[14:49] <sdfgsdfh> and 3 channels
[14:49] <sdfgsdfh> WTF, that's like the same as RGB24, BGR24, etc.
[14:49] <sdfgsdfh> same flag too
[14:50] <sdfgsdfh> but I don't know what kind of subsamplin they might have
[14:50] <sdfgsdfh> I don't get the "0" part
[14:50] <sdfgsdfh> FFV1 does not supportthe "24" formats for some reason
[14:51] <sdfgsdfh> I am actually avoiding FFV1 right now for that reason
[14:56] <sdfgsdfh> this pixel format limitation has been bugging me for days
[14:56] <sdfgsdfh> I would like to get a definitive answer on FFV1's pixel format limitations
[14:56] <sdfgsdfh> I do not know who to ask
[14:57] <sdfgsdfh> I need to sleep but the chat will fill up so fast...
[14:59] <relaxed> sdfgsdfh: ffvhuff does
[15:00] <sdfgsdfh> ffvhuff?
[15:00] <sdfgsdfh> not huffyuv?
[15:01] <JEEB> sdfgsdfh, if you really want to see what pix_formats a video format supports, you can check the encoder definition in the matching libavcodec/***.c file
[15:01] <relaxed> that too
[15:01] <JEEB> it has a list of the supported pix_fmts
[15:01] <sdfgsdfh> I can't understand code
[15:01] <JEEB> it's a simple list :P
[15:01] <sdfgsdfh> ahg
[15:01] <relaxed> ffmpeg -h encoder=ffv1
[15:02] <sdfgsdfh> I'll try that, but that doesn't tell me wat the formatsactually are
[15:03] <sdfgsdfh> ok so there's bgr0 and bgra
[15:03] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/ffv1enc.c#L1336
[15:03] <JEEB> is this really that hard to see as a list :P
[15:03] <JEEB> the AV_PIX_FMT_* listing
[15:03] <JEEB> NONE being the "end" of the list
[15:04] <JEEB> but yes, if -h encoder=xxx outputs the same
[15:04] <JEEB> that's probably simpler :P
[15:04] <sdfgsdfh> well almost
[15:04] <sdfgsdfh> the constants are more descriptive
[15:05] <sdfgsdfh> very telling actually
[15:05] <sdfgsdfh> it looks like FFV1 has to pad out 32 bits per pixel, period
[15:05] <JEEB> anyways, the difference between huffyuv and ffvhuff is that the former IIRC tries to be compatible with "Ye Olde Huffman"
[15:05] <JEEB> while ffvhuff adds features etc
[15:06] <sdfgsdfh> of course huffyuv is old
[15:06] <sdfgsdfh> I don't use it because of bad compression ratios, but it makes a good fallback
[15:06] <relaxed> ffv1 is much slower to encoder/decode
[15:06] <sdfgsdfh> I care more about decoding speed
[15:06] <sdfgsdfh> for playability
[15:06] <sdfgsdfh> so utvideo is awesome
[15:07] <sdfgsdfh> not triedffvhuff yet
[15:07] <sdfgsdfh> didn't know it existed
[15:07] <sdfgsdfh> I assume it supports various pixel formats
[15:08] <sdfgsdfh> not as many, but the important ones are there
[15:08] <sdfgsdfh> including rgb24
[15:08] <relaxed> yes, see ffmpeg -h encoder=ffvhuff
[15:08] <JEEB> libx264's RGB encoding might be useful, too (as lossless). Try out whatever can do well enough on your hardware
[15:08] <JEEB> ffvhuff/ut video are going to be pretty damn fast since they're so simple
[15:09] <sdfgsdfh> I heard libx264 with RGB is a minefield
[15:09] <JEEB> depends in what way
[15:09] <sdfgsdfh> well, taking a RGB24 source
[15:09] <JEEB> yes?
[15:09] <sdfgsdfh> putting it straight into a libx264 mkv
[15:09] <sdfgsdfh> trying to be 100% lossless
[15:09] <sdfgsdfh> jut something I read on stackoverflow
[15:10] <JEEB> yes, by default it will use pix_fmt yuv420p unless you use the RGB-specific encoder name
[15:10] <JEEB> which is libx264_rgb or so
[15:10] <sdfgsdfh> ORLY
[15:10] <JEEB> for playback compatibility with hardware devices and such :P
[15:10] <JEEB> yarly
[15:10] <sdfgsdfh> I am learing so much
[15:10] <sdfgsdfh> so that's like 2 or 3 other encoders I can use
[15:10] <JEEB> and then with 8bit libx264 just use -crf 0 (or quantizer zero) to set lossless
[15:11] <sdfgsdfh> I know
[15:11] <JEEB> quantizer zero also works with >8bit libx264
[15:11] <JEEB> okies
[15:11] <sdfgsdfh> well, there is no libx264_rgb
[15:12] <relaxed> libx264rgb
[15:12] <sdfgsdfh> why yes
[15:12] <sdfgsdfh> and what a long description of functionality it gives me
[15:13] <sdfgsdfh> is it strictly lossless or both lossy and lossless? Does it default to RGB24?
[15:13] <relaxed> -crf 0 -pixfmt rgb24
[15:13] <JEEB> there's only one type of RGB in libx264
[15:13] <relaxed> -crf 0 -pix_fmt rgb24
[15:14] <sdfgsdfh> it looks like there's bgr24 as well
[15:14] <JEEB> and as always, there's speed/compression presets and you can encode both lossy and lossless
[15:14] <sdfgsdfh> I do prefer faster decoding than encoding
[15:14] <sdfgsdfh> but I tend to shy away from those speed presets
[15:15] <JEEB> well, decoding will anyways be pretty fast
[15:15] <JEEB> the presets are just if you need to either make the encoding faster (f.ex. in realtime scenarios) or if you need to compress more
[15:15] <sdfgsdfh> I see
[15:16] <sdfgsdfh> but I assume the compression ratio is pretty much the best ffmpeg has to offer
[15:16] <sdfgsdfh> libx264 with 4:2:0 gave me some amazing lossless compression
[15:16] <sdfgsdfh> -crf 0 actually makes a file smaller than -crf 3
[15:17] <sdfgsdfh> for some werd reason
[15:17] <sdfgsdfh> *weird
[15:17] <JEEB> with specific kinds of sources it indeed is better to code something lossless than with high bit rate lossy
[15:17] <sdfgsdfh> I'm not going to ask why :P
[15:22] <sdfgsdfh> Encoding now...
[15:22] <sdfgsdfh> BTW, I am operating under the assumption that wavpack defaults to lossless
[15:23] <sdfgsdfh> WB telex
[15:30] <sdfgsdfh> wow, that seemed to do away with 1/3 of the file size VS utvideo
[15:36] <sdfgsdfh> OK so that libx264rgb (rgb24) video is unplayable in VLC and glitches out in smplayer
[15:36] <sdfgsdfh> in VLC it's all green
[15:37] <sdfgsdfh> I can't believe I pulled an all-nighter for codecs and pixel formats
[15:39] <klaxa|work> happens all the time
[15:39] <c_14> True words, true words.
[15:40] <sdfgsdfh> especially considering those who frequent this channel :)
[15:43] <JEEB> sdfgsdfh, probably old versions of things.
[15:43] <JEEB> everything current should be fine with it
[15:43] <JEEB> as in, current since... a year or two ago
[15:43] <JEEB> I think 4:4:4 and RGB first got used around ~2011 or so
[15:44] <sdfgsdfh> these are he latest stabe builds of VLC and smplayer
[15:44] <sdfgsdfh> I think VLC is the more up-to-date version
[15:45] <sdfgsdfh> as of like 2 months ago
[15:45] <sdfgsdfh> smplaer may be a year old
[15:45] <sdfgsdfh> and I think RGB has been around for some time in the form of uncompressed AVIs
[15:46] <sdfgsdfh> I used that format all the time when exporting from Blender back in high school
[15:46] <JEEB> ugh, there's a commit from april in VLC that fixes planar RGB :V
[15:46] <JEEB> yeah, it's mostly a case of players thinking that H.264 can only be either YCbCr or 4:2:0 YCbCr
[15:46] <JEEB> and mplayer can just be old in any case
[15:47] <sdfgsdfh> all true
[15:47] <sdfgsdfh> regarding that commit
[15:47] <JEEB> if you try a recent build of mpv or in DirectShow's LAV Filters it should just work though
[15:47] <sdfgsdfh> is there a specific day
[15:47] <JEEB> http://git.videolan.org/gitweb.cgi?p=vlc.git;a=commit;h=0e10c9d6bf06785eb3990786d7c1e3217eadf601
[15:47] <JEEB> anyways, I use mpv as a "reference" in many cases
[15:48] <sdfgsdfh> Mar 20
[15:48] <sdfgsdfh> well
[15:48] <sdfgsdfh> I don't know what mpv is
[15:48] <JEEB> mplayer -> mplayer2 -> mpv
[15:48] <JEEB> http://mpv.io/
[15:50] <spaam> mpv is the new black?
[15:50] <JEEB> well, mplayer2 pretty much died :P
[15:51] <JEEB> since everyone but uau moved to mpv
[15:51] <JEEB> and mplayer, while still being kept on life support, is pretty much a lost cause in my opinion
[15:51] <spaam> why? so people dislikes uau ?
[15:51] <JEEB> mostly because uau wasn't really co-operative at the time
[15:51] <JEEB> it took like two years of things to people to fork
[15:52] <JEEB> so chances were given and various people did ragequit before a fork was made
[15:55] <sdfgsdfh> Well, ffvhuff is a disaster when it comes to file size so I won't be using that again
[15:58] <sdfgsdfh> Wow, MPV has a .com file
[15:58] <sdfgsdfh> what is this, 1985?
[15:59] <JEEB> no
[15:59] <JEEB> it's so that you don't get a command prompt
[15:59] <JEEB> in certain ways you launch it
[15:59] <sdfgsdfh> I did not know that
[16:00] <JEEB> well, the COM binary basically just is a "GUI" binary so it doesn't spawn a command prompt
[16:00] <JEEB> the exe one is a "cli" binary that spawns a command prompt
[16:00] <JEEB> and I think one of them, com or exe, comes before the other in the listing of executable things in PATH
[16:00] <sdfgsdfh> the COM is 13 KB, the EXE is 26 MB and has an icon
[16:00] <JEEB> yes
[16:00] <JEEB> the COM just calls the exe
[16:01] <sdfgsdfh> I see
[16:01] <JEEB> it's a hack to not get a command prompt under certain circuimstances, basically
[16:01] <sdfgsdfh> so since there is no built-in GUI (right?) I open my videos wth said program?
[16:02] <JEEB> there's the on-screen controls, but that's it
[16:02] <sdfgsdfh> I'm fine with that
[16:04] <sdfgsdfh> well, it plays everything perfectly
[16:04] <sdfgsdfh> amazing
[16:05] <sdfgsdfh> kind of laggy on a 720p libx264rgb file though
[16:05] <sdfgsdfh> I think it may be the format
[16:05] <JEEB> or the video renderer
[16:05] <JEEB> there can be plenty of reasons
[16:06] <sdfgsdfh> the video renderer that is built into MPV?
[16:07] <sdfgsdfh> oh yeah looks like t
[16:07] <JEEB> yeah, the one that gets used by default. depending on your hardware
[16:07] <sdfgsdfh> it's slower to play utvideo!
[16:07] <sdfgsdfh> about smplayer speeds
[16:07] <sdfgsdfh> unsurprisingly
[16:07] <JEEB> well naturally :P ut video is simple huffman
[16:07] <JEEB> anyways, you can make H.264 faster to play back in various ways
[16:08] <JEEB> -tune fastdecode being probably the thing that works in all presets
[16:08] <sdfgsdfh> what I mean is that VLC handles utvideo better
[16:08] <JEEB> well, of course :P it didn't have a bug with handling it :P
[16:09] <sdfgsdfh> OK so basically MPV is faster with x264 for some reason
[16:10] <sdfgsdfh> does fastdecode do things like disable deblocking and drop B frames or whatever?
[16:10] <sdfgsdfh> it has to be "fast" somehow
[16:10] <JEEB> it disables deblocking and CABAC
[16:10] <JEEB> b-frames aren't used in lossless to begin with
[16:10] <sdfgsdfh> CABAC?
[16:11] <sdfgsdfh> there still is lossy x264
[16:11] <sdfgsdfh> I don't know what CABAC is
[16:11] <JEEB> yes, but we were talking about lossy, no? :P
[16:11] <JEEB> CAVLC and CABAC are the two modes of compression you have in H.264
[16:11] <sdfgsdfh> I'm just trying to cover my ignorance :P
[16:11] <JEEB> in HEVC they removed CAVLC
[16:11] <JEEB> and left only CABAC
[16:11] <JEEB> CABAC is basically slower to encode/decode, but compresses better
[16:11] <JEEB> CAVLC is more like huffman in a way
[16:12] <sdfgsdfh> so you can encode or decode in either one arbitrarily without problems?
[16:13] <sdfgsdfh> I heard HEVC/x265 is indeed slower for some reason
[16:13] <JEEB> well, it is designed 10 years later :P
[16:14] <JEEB> also you can still make a fast (and crappy) HEVC encoder, just like you could with H.264
[16:14] <JEEB> it just has more features that can be harder on the encoder
[16:14] <JEEB> decoder-wise it shouldn't be much slower
[16:14] <klaxa|work> i did some encodes with libx265 on my server
[16:15] <klaxa|work> 90 seconds 1080p anime source took like 30 minutes with 8 threads, filesize was like ~150 mb with x264 to ~37 mb with x265
[16:15] <sdfgsdfh> I assume they turned out well
[16:15] <klaxa|work> i don't think i remember the settings
[16:15] <klaxa|work> but decoding in real-time on my crappy laptop was impossible
[16:15] <JEEB> klaxa, that sounds like the incorrect type of testing :P I mean, the CRF values are not and probably never will be the same
[16:16] <JEEB> but currently x265 only wins in very very low rate scenarios
[16:16] <klaxa|work> heh yeah pretty much pointless waste of cpu time
[16:16] <JEEB> I mean, in cases where both files look crappy
[16:16] <klaxa|work> but the server is in idle most of the time anyway
[16:16] <JEEB> but the HEVC encode looks a bit better
[16:17] <klaxa|work> i couldn't see a visual difference between the encodes though
[16:17] <klaxa|work> http://dedi.klaxa.eu/public/op_x264.mkv vs. http://dedi.klaxa.eu/public/op_hevc.mkv
[16:17] <JEEB> then you were testing in a bad way
[16:18] <klaxa|work> most likely
[16:18] <JEEB> anyways, match up file sizes (x265 is slower so encode with CRF with it first) and basically max out both encoders (preset placebo, ref/bframes 16)
[16:18] <JEEB> I think around crf 32 was pretty good for this for x265 in february or so
[16:19] <klaxa|work> it was more a test to satisfy my curiosity as to how low the filesize can go with x265 with no noticeable difference
[16:19] <klaxa|work> which is absolutely subjective in the first place
[16:20] <JEEB> that's OK too
[16:24] <sdfgsdfh> so what if you wanted to compress a 2hr long movie at 640x360 to 20 MB with x265?
[16:25] <sdfgsdfh> I've done some tests with x264 and I can say that I am OK with crf 35 in many cases
[16:25] <sdfgsdfh> I have seen worse bitrate abuse
[16:26] <sdfgsdfh> and I assume some day there will be x266 which understands the context of video and encodes subjective information based on human consciousness
[16:28] <JEEB> the CRF values between x264 don't match
[16:28] <JEEB> *between x264 and x265
[16:28] <JEEB> so you can't really compare them
[16:28] <JEEB> but with some random 720p animoo I tested in february CRF 32 was ~415kbps
[16:28] <JEEB> which was quite nice to see good/bad points of both encoders
[16:31] <sdfgsdfh> I am not realy concerned with the CRF values of x265, but the artifacts that crop up with x264 do bother me, especially at super low bitrates
[16:32] <sdfgsdfh> there is a jump at each keyframe transition because there is no blending, for instance
[16:33] <sdfgsdfh> x265 is still under development so it's probablytoo early to judge anyways
[16:44] <sdfgsdfh> it looks like mpv does no have a -tune option
[16:44] <klaxa|work> why should it have one?
[16:45] <sdfgsdfh> because apparetly mplayer has it or something
[16:45] <sdfgsdfh> JEEB suggested using it
[16:45] <klaxa|work> -tune is used for encoding, mpv does decoding
[16:45] <JEEB> uhh
[16:45] <JEEB> it's an encoder option, yes
[16:45] <JEEB> for ffmpeg
[16:45] <sdfgsdfh> h
[16:45] <sdfgsdfh> oh
[16:46] <JEEB> mpv does also encode, but it uses lavf/lavc on the background, and using it will make you read some documentation :P
[16:46] <sdfgsdfh> that would make moe sense
[16:46] <sdfgsdfh> I wasn't really planing on using mpv as an encoder at this point
[16:46] <klaxa|work> oh? they put the mencoder parts back into mpv?
[16:46] <JEEB> no
[16:46] <JEEB> it's new code
[16:46] <klaxa|work> ah
[16:47] <sdfgsdfh> so how does -tune fastdecodework with lossless?
[16:47] <JEEB> it switches from CABAC to CAVLC
[16:48] <JEEB> and some other things that make compresson efficiency somewhat worse
[16:48] <JEEB> but that speed up decoding
[16:48] <sdfgsdfh> how much worse?
[16:48] <JEEB> depends on the stuff, and depends on a whole lot of things
[16:48] <sdfgsdfh> well, in a typical use case
[16:48] <JEEB> I can't just come up with a random number :P
[16:48] <sdfgsdfh> ok
[16:48] <JEEB> in any case, it should still be better than ut video for example
[16:49] <JEEB> for various reasons
[16:49] <sdfgsdfh> oh wow ok
[16:49] <sdfgsdfh> well, ut video is still way better than huffman
[16:49] <JEEB> because ut video is in the end so simple :P
[16:49] <sdfgsdfh> it was made by one Japanese guy, so it would have to be: :)
[16:49] <JEEB> well ut video is just huffman with a simple median prediction in most cases :P
[16:49] Action: JEEB wrote the avcodec ut video encoder
[16:50] <sdfgsdfh> you actually re-implemented utvideo all yourself for ffmpeg?
[16:50] <JEEB> yes
[16:50] <sdfgsdfh> you are a hero!
[16:51] <sdfgsdfh> you did a wonderful thing
[16:51] <sdfgsdfh> it's such a reliable codec compared to others
[16:51] <sdfgsdfh> it's got lots of pixel formats, a good compression ratio, and fast decoding
[16:52] <sdfgsdfh> and you didn't even invent it, so I can imagine it was lots of work
[16:52] <Venti> cabac produced like 20% better bitrate for hevc back when cavlc was still being proposed
[16:53] <JEEB> yeah, it was and still is (?) in HM, too
[16:53] <JEEB> at least leftovers of the code were all around HM at one point
[16:53] <sdfgsdfh> HM?
[16:54] <JEEB> ther reference implementation of HEVC
[16:55] <Venti> I think the decoder side still has them.. no idea if it works though
[16:55] <JEEB> wouldn't be surprised if it didn't
[16:55] <JEEB> also at this point removing CAVLC just makes sense
[17:06] <MrNaviPacho> RPM Fusion is listed on the downloads page for CentOS, however, it looks like they are on 0.x, is there somewhere I can get RPMs for 2.x?
[17:08] <relaxed> MrNaviPacho: if it's 64bit then http://johnvansickle.com/ffmpeg/
[17:08] <relaxed> which is a static build, not an rpm
[17:12] <MrNaviPacho> relaxed: that's fine, not sure how I missed that
[17:12] <MrNaviPacho> thanks
[17:23] <MrNaviPacho> relaxed: does this not have aac support? (Unknown encoder 'libfaac')
[17:24] <sdfgsdfh> you can use the built-in experimental aac encoder
[17:28] <MrNaviPacho> ok, thanks
[17:28] <sdfgsdfh> np, sorry I couldn't come up with the command line
[17:32] <sdfgsdfh> x264 with fastdecode played smoother than anything, to bad VLC is a little behind right now
[17:33] <sdfgsdfh> no color loss either so that's good
[17:58] <svm_invictvs> Can ffmpeg do chroma key postprocessing?
[18:04] <sdfgsdfh> maybe through a series of steps with libavfilter or something, but it's complicated
[18:05] <sdfgsdfh> I'm not sure if there's any pre-mae keying filter
[18:06] <sdfgsdfh> if you want to do keying or compositing manually, I would recommend Blender. If you need it in real-time, I'm afraid I can't be of much help.
[18:30] <iive> sdfgsdfh: ffmpeg should support alpha channel
[18:44] <sdfgsdfh> I'm feeling shell shocked from al these angry neighbors slamming doors
[18:45] <sdfgsdfh> some kind of domstic dispute going on for sure
[18:45] <sdfgsdfh> time for a nap
[18:46] <sdfgsdfh> iive: ffmpeg does support encoding videos with alpha channels, but I don't know anything other than that
[18:46] <iive> that's almost as much as I know too.
[18:46] <iive> some filters might support it :)
[18:46] <sdfgsdfh> yes I suppose so
[18:47] <sdfgsdfh> I've never used filters with ffmpeg
[18:47] <sdfgsdfh> there's probably an overlay filter
[18:47] <sdfgsdfh> if real-time keying is an issue though, an alpha channel is the least of your concerns
[18:48] <sdfgsdfh> rather, you'll need per-pixel math to blend one video frame into another
[18:48] <iive> there is definitely and overlay filter.
[18:48] <iive> and/an
[18:48] <sdfgsdfh> cool
[18:48] <iive> that's why I am talking about alpha channel
[18:49] <iive> it is a whole plane with an alpha value for each and every pixel.
[18:49] <sdfgsdfh> yep
[18:49] <blippyp> that's basically what I did once - I had to make an algorithm to get the keying to work - I think frei0r has a filter for it though (haven't tried it yet)
[18:52] <sdfgsdfh> a good start would be something like A=(R+B)/2-G
[18:53] <sdfgsdfh> I don't know if it would be more efficient to use the alpha channel or to peek and poke the pixels directly
[18:54] <sdfgsdfh> one trick you could do is using a lower-resolution image to generate your alpha map if you're using HD
[18:54] <blippyp> probably an alpha channel - I think in the end, that's how I went about it - I first started with an algorithm and then migrated to alpha channel approach - it's been a while since I did it, so I honestly don't remember exactly how I did it. But it worked reasonably well. An actual filter designed to do the job is probably better tbh....
[18:55] <blippyp> Yeah - I also generated a low res image as well - and decreased the colors to simplify to generate the mask i think....
[18:55] <sdfgsdfh> decreased the color bitrate?
[18:56] <sdfgsdfh> the edges mightget weird
[18:57] <blippyp> it worked for me... not sure why - I'm no expert on this kind of thing - all I know is that I was pretty happy with the result - and it was much faster than analyzing each pixel...
[18:57] <sdfgsdfh> I'm sure
[18:58] <sdfgsdfh> an the filtering probably helped to blur the edges a bit, which one might do anyways
[18:58] <blippyp> also, my wants were simple - I was converting the image into a 'cartoon' in the end anyways... for a real-time image the approach I took probably isn't very useable...
[18:58] <svm_invictvs> sdfgsdfh: I'm not trying to do it in real time
[18:59] <blippyp> I'd look at the green screen technique used in the frei0r filter - it will likely give you the details you want for a much better green screening
[18:59] <svm_invictvs> sdfgsdfh: What about just decomposing the video into frames, then i can write code to dot he chromakey myself?
[18:59] <blippyp> oops - didn't mean real-time - more of a 'real life' image
[18:59] <blippyp> with many colors and high res etc....
[19:00] <blippyp> that could work, but is also probably quite slow - if you're willing to code - I would seriously take a look a frei0r - it will probably help you tons
[19:07] <sdfgsdfh> I can't stay here any more
[19:07] <sdfgsdfh> I'm sorry
[19:36] <mjuszczak> Can anyone recall a bug fixed in ffmpeg where you would pass a filename on the command line, particularly for srt files, and it would say "file not found", yet if you copied the same exact path and ran stat/ls on it, it's listed?  This would have been a very old bug.
[19:38] <pzich> http://stackoverflow.com/questions/8672809/use-ffmpeg-to-add-text-subtitles ?
[22:01] <midzer> hi nypenick
[22:01] <nypenick> hi midzer
[22:05] <nypenick> hey ffmpeg guys.. i've got a simple question. I'm trying to seek while decoding audio. So i'm calling av_seek_frame and after that I go on decoding with av_read_frame and avcodec_decode_audio4.
[22:06] <nypenick> this code works but the seeking is not very precise
[22:07] <nypenick> it always ~1 sec befor or behind the actual seek position
[22:11] <pzich> nypenick: can you use -ss?
[22:12] <nypenick> what does -ss mean?
[22:12] <pzich> it's an ffmpeg flag to seek, and depending on whether you place it before or after your input files (with '-i') it seeks quickly or precisely
[22:12] <pzich> https://trac.ffmpeg.org/wiki/Seeking%20with%20FFmpeg
[22:12] <c_14> pzich: He's using the library not the binary.
[22:13] <nypenick> correct I#m using the library
[22:13] <pzich> ah, right
[23:02] <sad> hi guys! is there a way to recompile just the libavcodec in ffmpeg?
[23:11] <sad> if i modify source code from mjpegdec.c, is there a way to compile/build only this part of libavcodec?
[23:25] <iive> if you run make second time, it would only compile the changed .c file and then link again all that depend on it.
[23:25] <iive> that is, libavcodec, ffmpeg/play/server etc.
[00:00] --- Thu May 22 2014