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

[burek]

[00:00:48 CEST] <Zucca> ffv1 is great for general archiving. But as todays tests showed different material compresses differently on different codecs. And for screencasting I think I'll keep them in zlib. About 50% of the size of ffv1. :o
[00:01:20 CEST] <JEEBsv> great? the last time I checked it the encode wasn't exactly fast and the decoding was atrociously slow
[00:02:56 CEST] <JEEBsv> http://fushizen.eu/samples/hevc/ <- the reference-decoded things in avi I for whatever reason encoded in ffv1. and now I want to strangle myself for it.
[00:03:15 CEST] <Zucca> I was suprised too. Although small resolution I got somewhere close to 130fps decoding+encoding zlib.
[00:03:46 CEST] <JEEBsv> tl;dr I will probably just use lossless AVC instead
[00:05:54 CEST] <Zucca> I haven't tested VP8/9 at all. Do those support lossless?
[00:06:28 CEST] <JEEBsv> I think either one of them had a 4:2:0 lossless thingy, but I'd generally guess it's not fast enough or gives good enough compression to be comparable to x264
[00:06:32 CEST] <c_14> vp9 does, not sure about vp8
[00:07:17 CEST] <Zucca> Google is developing vp10 already iirc.
[00:07:24 CEST] <JEEBsv> On2's shit has generally been rather lackluster, even if they are good at copying features out of ISO/IEC|ITU-T specifications
[00:07:38 CEST] <kepstin-laptop> huh, letting libx264 use predicted frames (instead of intra-only) with lossless capture really speeds it up if you're doing e.g. desktop captures with large static areas.
[00:08:01 CEST] <JEEBsv> and long gops really bolster compression ratios, news at eleven!
[00:08:19 CEST] <JEEBsv> I think even ffv1  by default nowadays does non-intra coding?
[00:08:34 CEST] <kepstin-laptop> i expected the compression ratio increase, but not as much the speed change
[00:08:39 CEST] <kepstin-laptop> i guess encoding less data = faster
[00:08:42 CEST] <kepstin-laptop> :)
[00:08:49 CEST] <JEEBsv> yup, less stuff goes through the CABAC coder
[00:08:54 CEST] <Zucca> kepstin-laptop: Gotta keep that in mind when I test x264.
[00:09:41 CEST] <kepstin-laptop> to get 30fps 1080p on this machine with intra-only i had to use ultrafast, which iirc disables cabac.
[00:10:02 CEST] <JEEBsv> CAVLC would be even more fun
[00:10:11 CEST] <JEEBsv> moar datas for everyone :P
[00:10:19 CEST] <Zucca> The problem with these screencasting things is that the setting, codec and pixsel format combinations are almost endless.
[00:10:56 CEST] <JEEBsv> well if you are compressing for local you generally want screen being captured as RGB, and then if you ever have to distribute it you convert it to YCbCr at that point
[00:11:17 CEST] <Zucca> Yeah.
[00:11:21 CEST] <JEEBsv> if you are actually streaming to actual service providers there's not much you can do other than YCbCr :P
[00:11:33 CEST] <JEEBsv> because no proprietary decoder supports more than 4:2:2 YCbCr
[00:12:05 CEST] <JEEBsv> (ok, I lie. according to what pegasys says there is a proprietary 4:4:4 10bit YCbCr intra AVC decoder)
[00:12:22 CEST] <JEEBsv> (but that is not used in any of those things that decode your streams)
[00:13:27 CEST] <Zucca> zlib chose bgr24 when I didn't specify any.
[00:13:53 CEST] <JEEBsv> is zlib intra or inter?
[00:13:54 CEST] <Zucca> I don't even know what formats it can take.
[00:15:32 CEST] <Zucca> JEEBsv: Intra it seems.
[00:28:54 CEST] <foonix> dirty test: utvideo: 201 Mbps, libx264 (-c:v libx264 -preset ultrafast -qp 0): 191 Mbps, ffv1: 109 Mbps
[00:29:28 CEST] <foonix> but cant measure encoder performance, since the machine is pretty loaded
[00:30:06 CEST] <foonix> JEEBsv: this combination gives me I and P frames, was my setting correct for avc lossless?
[00:32:07 CEST] <kepstin-laptop> foonix, yes, "-qp 0" is correct to get x264 lossless.
[00:32:14 CEST] <JEEBsv> of course it will, x264 will only do intra only if you specifically say you want it. also I'm pretty sure x264 at ultrafast is damn fast so you will probably want to match against something speed-wise
[00:32:32 CEST] <JEEBsv> also I'm pretty sure ffv1 is a) slower than ultrafast and b) not intra only
[00:32:55 CEST] <kepstin-laptop> switching from ultrafast to something (even slightly slower) should provide a noticable bitrate improvement.
[00:32:57 CEST] <JEEBsv> also you will want to see what is the way to do the thing that --keyint infinite does with x264 cli
[00:33:39 CEST] <JEEBsv> that will make x264 only use intra pictures when it makes sense, instead of having an arbitrary maximum number around which it will try to put an intra pic there
[00:33:50 CEST] <JEEBsv> also make sure you're testing all of them with the same pix_fmt
[00:34:40 CEST] <kepstin-laptop> if you're doing rgb screen captures, note that to get rgb in x264 you have to use '-c:v libx264rgb'
[00:35:25 CEST] <foonix> JEEBsv: default ffv1 (-c:v ffv1) gives I only output
[00:35:57 CEST] <JEEBsv> I think that was just a simpler way to set the default pix_fmt since the libx264 wrapper by default sets 4:2:0
[00:36:00 CEST] <JEEBsv> foonix: hmm
[00:37:05 CEST] <kepstin-laptop> hmm, the default I see is that it converts rgb to yuv444p.
[00:38:07 CEST] <kepstin-laptop> yeah, even if you manually specify an rgb pic_fmt, it rejects it unless you use 'libx264rgb'
[00:38:12 CEST] <kepstin-laptop> pix_fmt*
[00:38:35 CEST] <foonix> i think to match ffv1 it needs preset veryslow or smth very cpu intensive
[00:39:09 CEST] <JEEBsv> whatever is avctx->gop_size by default :P
[00:44:18 CEST] <kepstin-laptop> JEEBsv, looks like "-x264opts keyint=infinite" does that, I guess that overrides the -g option somehow.
[00:59:38 CEST] <foonix> btw, perf stat on that dirty test: http://fpaste.org/221723/57866143
[01:09:13 CEST] <foonix> 511 Mbps [bgr24]       / 748,190,461,125 instructions (-c:v zlib)
[01:09:51 CEST] <foonix> ^^ out of curiosity, but diff colorspace etc and pretty intensive for specified source material
[02:47:06 CEST] <yvear> I'm getting [Parsed_pan_0 @ 0000000002fcbf20] Syntax error near "*1+FR*0+"   with    -af "pan=stereo|FL=FL*1+FR*0+FCE*0.7071+LFE*1+BL*0.7071+BR*0+FCL*0.7071+FCR*0|FR=FL*0+FR*1+FCE*0.7071+LFE*1+BL*0+BR*0.7071+FCL*0+FCR*0.7071"   anyone know why?
[11:24:45 CEST] <tjvc> I have a 64 core CPU and I want to use ffmpeg to transcode a number of large video files (using libx264). What would be the most efficient way of doing this? Should I run the jobs sequentially, or use GNU parallel to run several simultaneously?
[11:27:54 CEST] <JodaZ> gnu parallel sounds like an idea, mind to optimize your disk io
[11:38:11 CEST] <tjvc> I'm reading/writing to a network share, so I'm guessing that will be the bottleneck in this case.
[11:59:45 CEST] <killer> i have a video of 30 minutes but i want to exatract a video from 00:09:23 to 00:25:33. how i can do it ?
[12:15:29 CEST] <Nitori> with -ss and -to
[12:17:42 CEST] <killer> with this ? ffmpeg -ss 00:09:23 -i test.mp4 -t 00:25:33
[12:17:43 CEST] <killer> ?
[12:21:23 CEST] <saste> killer: no use the -to option and read docs
[12:29:57 CEST] <efesto> Hi all, I'm having some truble with the file paths under windows, is there anyone able to help me out ?
[13:00:33 CEST] <efesto> I have a command which is giving me problem on pastebin
[13:00:40 CEST] <efesto> is there anyone willing to have a look ?
[13:00:45 CEST] <efesto> is a path issue with windows
[13:00:47 CEST] <efesto> thanks
[13:01:14 CEST] <relaxed> paste the link
[13:01:18 CEST] <efesto> http://pastebin.com/df1Y9ZsF
[13:01:22 CEST] <efesto> is quite a complex one
[13:01:27 CEST] <efesto> works fine under linux
[13:01:42 CEST] <efesto> the problem comes from the lut3d path
[13:01:48 CEST] <efesto> which doesn't seems to want to work
[13:01:53 CEST] <efesto> I can paste the error as well
[13:02:25 CEST] <efesto> here is the error : http://pastebin.com/zGLhm2yS
[13:02:53 CEST] <relaxed> that's a wall of text!
[13:02:58 CEST] <efesto> yeah I know
[13:03:01 CEST] <efesto> is a complex command
[13:03:20 CEST] <efesto> I can explain what is going on though
[13:03:30 CEST] <efesto> 2 inputs, a static image and an image sequence
[13:03:40 CEST] <efesto> on both there's some text
[13:03:50 CEST] <efesto> but on the second input, there's a chain of 3dluts
[13:04:03 CEST] <efesto> to move the original plate (dpx) from cineon to slog
[13:04:08 CEST] <efesto> then a lut get applied
[13:04:16 CEST] <efesto> and anoter bring it from log to srgb
[13:04:27 CEST] <efesto> I can try to take out the text if it simpler to look at
[13:06:33 CEST] <efesto> here a simpler one : http://pastebin.com/HgHSHQXR
[13:06:41 CEST] <efesto> same error
[13:08:18 CEST] <relaxed> I'm getting ready to leave work. Stick around and someone will probably help you, or I will try when I get home.
[13:08:28 CEST] <efesto> thanks man
[13:08:42 CEST] <efesto> weird is that under linux there's no porblem what so ever
[13:08:56 CEST] <efesto> have a good one
[13:18:26 CEST] <bigsky> hi all
[13:18:32 CEST] <efesto> hey
[13:21:59 CEST] <bigsky> anybody here who use ffplay on windows?
[13:22:13 CEST] <bigsky> ffplay seems occupies too much cpu, what's wrong?
[13:25:21 CEST] <efesto> jnot much
[13:25:24 CEST] <efesto> mainly on linux
[13:25:41 CEST] <efesto> have you been trying passing -threads 0 ?
[13:26:02 CEST] <efesto> alsom try setting -v debug or verbose to have some more info about what's going on
[15:14:38 CEST] <asimas> Hello. I'm using ffmpeg's concat demuxer to merge multiple mp4 files. However, only the first one listed is played. The other one is all grayed out when playing. Here are the commands used: http://pastebin.com/3YVPQxsu Is there something wrong with the input files? They do have the same fps, codec, and resolution.
[17:23:52 CEST] <hid> hi
[17:24:30 CEST] <hid> say that i have a 6min song called song.mkv
[17:25:00 CEST] <hid> sorry
[17:25:05 CEST] <hid> say that i have a 6min video called video.mkv
[17:25:27 CEST] <hid> and a 5min song called song.m4a
[17:25:39 CEST] <hid> i'd like the video to fit the audio
[17:26:12 CEST] <hid> and i'd like it not to be encoded a lot
[17:26:16 CEST] <hid> how to?
[17:26:30 CEST] <hid> i did
[17:26:30 CEST] <hid> :
[17:27:11 CEST] <hid> ffmpeg -i video.mkv -i song.m4a output.mkv
[17:27:37 CEST] <hid> but i have 1min of 'blank' (no music)
[17:33:14 CEST] <c_14> Do you want the video to fit the song or the song to fit the video?
[19:00:51 CEST] <maslen> I converted a whole bunch of VHS's into MP4's using the following command: ffmpeg -f pulse -i alsa_input.pci-0000_00_14.2.analog-stereo -thread_queue_size 512 -async 12 -i /dev/video0 -strict -2 -q:v 1~/Desktop/out.mp4 . How can I now re-encode them so that they don't lose any additional quality, but it takes up a lot less space?
[19:03:01 CEST] <c_14> You can't. You might be able to reencode them so that they take less space and look like they haven't lost quality.
[19:03:06 CEST] <c_14> https://trac.ffmpeg.org/wiki/Encode/H.264
[19:04:22 CEST] <maslen> I just care about what would be easily visible
[19:04:24 CEST] <maslen> Thank you
[19:04:42 CEST] <maslen> Is there any benefit to re-encoding the audio ?
[19:05:03 CEST] <c_14> no
[19:05:11 CEST] <RobotsOnDrugs> i would recommend looking at denoising
[19:05:43 CEST] <RobotsOnDrugs> though it can eat up your time trying to get the settings right
[19:05:54 CEST] <c_14> (well, there might be a benefit to reencoding the audio, but since the  audio codec is already lossy at a relatively low bitrate it won't make much of a difference)
[19:09:29 CEST] <maslen> RobotsOnDrugs: Any specific references?
[19:10:25 CEST] <RobotsOnDrugs> c_14: afaik, the best filter ffmpeg has is hqdn3d
[19:10:48 CEST] <RobotsOnDrugs> ffmpeg docs have info on it, and you can find more stuff around since it's not unique to ffmpeg
[19:12:17 CEST] <RobotsOnDrugs> it does a decent job of taming 'dancing spots', and improves compressibility
[19:13:33 CEST] <RobotsOnDrugs> but at a certain point, it smooths out the picture too much
[19:13:57 CEST] <RobotsOnDrugs> it's subjective and depends a lot on your source material
[19:22:36 CEST] <maslen> c_14: Looking at the H264 page, is there a command you'd recommend? Right now, I'm considering using: ffmpeg -y -i input -c:v libx264 -preset veryslow  -b:v 2200k -pass 1 -c:a copy -f mp4 /dev/null && ffmpeg -i input -c:v libx264 -preset veryslow  -b:v 2200k -pass 2 -c:a copy output.mp4
[19:23:33 CEST] <c_14> unless you're trying to target a specific size, using a crf is usually better than two-pass. I usually just pick one between 20  and 24ish depending on my content
[19:23:57 CEST] <maslen> oh
[19:25:38 CEST] <maslen> So, ffmpeg -i input -c:v libx264 -pix_fmt yuv420p -preset slow -crf 20 -c:a copy output.mp4 should work?
[19:25:49 CEST] <c_14> sure
[19:26:00 CEST] <maslen> Time to test on a 5-minute segment
[19:29:13 CEST] <maslen> Hmm, I'm getting an error that the option "preset" is not recognized
[19:45:14 CEST] <maslen> Same problem and solution as here: http://stackoverflow.com/questions/20035338/ffmpeg-on-heroku-unrecognized-option-preset
[21:20:41 CEST] <jbmcg> hey there - I was wondering if anyone on here might know what the most efficient (encoding-time-wise) way to crossfade two videos together using the ffmpeg command line tool. I know I could acheive the effect I want by shaving a piece off the begginning / end of both videos, adding them as overlays to a blank/black video, do the crossfade, export the merged video, and concat the final video together. This seems like a lot of work for such a
[21:20:41 CEST] <jbmcg>  simple effect but I can't come up with any other way to do it.
[23:29:03 CEST] <wode> Wow lots of people
[23:31:21 CEST] <wode> I'm trying to downsize long videos on a mobile device (Android) prior to upload and the different flags I've tried all take a very long time
[23:32:02 CEST] <wode> The best I've gotten is from ie ffmpeg -i in.3gp -preset ultrafast -f mp4 -r 12 -s 640x480 -strict -2 out.mp4
[23:33:11 CEST] <wode> Is there any good direction to follow to get some downsizing quickly?
[23:33:42 CEST] <wode> The line I pasted takes about 2 minutes per 1 minute of input to complete
[23:34:22 CEST] <wode> The input is ie Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 16841 kb/s, 29.70 fps, 30 tbr, 90k tbn, 180k tbc (default)
[23:34:48 CEST] <wode> I don't have much control over that, thus the problem in the first place
[23:34:53 CEST] <wode> thanks for any guidance
[00:00:00 CEST] --- Fri May 15 2015