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

[burek]

[00:00:23 CET] <Mavrik> pinPoint, you shouldn't, because that would mean they're even worse :)
[00:00:32 CET] <pinPoint> lol
[00:00:39 CET] <Mavrik> My point is, comparing on filesize alone when you tell the encoder what filesize you want isn't really productive :)
[00:01:03 CET] <Mavrik> If you set same filesize then you have to compare visual quality.
[00:01:08 CET] <pinPoint> it is true though when it comes to comparison vs h264. H264 @ 4000kpbs @ 2160p looks crappy vs VP9 @ 2000kpbs @ 2160p
[00:01:35 CET] <pinPoint> Mavrik: I wasn't aware ffmpeg could be told to spit out a specific filesize
[00:01:51 CET] <Mavrik> pinPoint, uh, what did you think setting bitrate is?
[00:02:06 CET] <pinPoint> the quality of the image
[00:02:07 CET] <Mavrik> You're literally telling the encoder "Use 2000 kbit for each second of video."
[00:02:07 CET] <Mavrik> :)
[00:02:11 CET] <pinPoint> not the final size
[00:02:17 CET] <Mavrik> it doesn't matter.
[00:02:21 CET] <Mavrik> if you're encoding the same file.
[00:02:28 CET] <Mavrik> and you're telling the encoder it should use 250KB/s
[00:02:33 CET] <Mavrik> what do you think it'll happen? ;)
[00:02:48 CET] <pinPoint> I guess it makes sense now
[00:02:53 CET] <pinPoint> its a math game
[00:04:48 CET] <pinPoint> when I do the math-a-roo i get around ~154.78
[00:05:13 CET] <pinPoint> the video is 10mins,34secs
[00:06:17 CET] <furq> pinPoint: -crf sets the image quality
[00:06:28 CET] <Mavrik> Yeah, so VP9 is terrible at keeping the requested bitrate :)
[00:06:43 CET] <Mavrik> Small discrepancy is expected, but not... that :)
[00:06:56 CET] <furq> did you try 2-pass
[00:06:59 CET] <Mavrik> CRF is closer to quality yeah, but CRF is also something arbitrary as a value for each encoder :)
[00:07:08 CET] <furq> and yeah crf values aren't comparable between encoders
[00:07:32 CET] <pinPoint> and it is different for each encoder. 23 on h264 is like 28 on h265
[00:07:40 CET] <furq> also i hope you're not still using x264 ultrafast
[00:08:22 CET] <pinPoint> furq: those were just testing things. I did a veryfast a veryslow and nothing on all of them.
[00:08:31 CET] <pinPoint> ultrafast*
[00:08:38 CET] <furq> again, though, you can't compare the presets by name because x264 is so much faster
[00:09:00 CET] <Mavrik> (Bottom line, comparing encoders is really hard.)
[00:09:08 CET] <pinPoint> and there are no presets on vp9 either.
[00:09:16 CET] <pinPoint> just -speed parameter
[00:10:00 CET] <furq> i guess -speed is pretty similar to -preset
[00:10:01 CET] <pinPoint> Mavrik: I did a quick hack job on my post. http://wideopenbokeh.com/AthenasFall/?p=172
[00:10:23 CET] <furq> but yeah if you're going to do a like-for-like comparison then it should probably be at the same encoding speed
[00:10:32 CET] <furq> which is going to take some trial and error to figure out
[00:10:52 CET] <pinPoint> veryslow for x265/x265 and -speed 4 for vp9
[00:11:13 CET] <pinPoint> either way, h264 still gets smoked in quality by the other two
[00:11:29 CET] <furq> or just assume that chart is correct and compare x264 veryslow to x265 fast
[00:11:31 CET] <pinPoint> at the expense of compute time encoding and decoding in 265/vp9
[00:11:34 CET] <furq> since those are apparently about the same speed
[00:11:46 CET] <pinPoint> furq: still h264 gets beat
[00:12:16 CET] <Mavrik> same encoding speed, same filesize :)
[00:12:32 CET] <Mavrik> and then a proper visual quality comparison
[00:12:36 CET] <pinPoint> i did 2000k
[00:12:43 CET] <Mavrik> Preferrably several times over several speeds and sizes.
[00:12:50 CET] <pinPoint> infact since I have some time encoding time here while I netflix
[00:13:12 CET] <pinPoint> I will do x264 veryslow vs x265 fast @ 2000kbps
[00:13:21 CET] <pinPoint> some*
[00:13:38 CET] <Mavrik> And how are you going to compare the result?
[00:13:53 CET] <pinPoint> looking with my eyes like before. :D
[00:15:10 CET] <pinPoint> I don't have that moscow university analyzer for $900 a pop.
[00:17:16 CET] <pinPoint> furq: ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v libx264 -preset veryslow -b:v 4000k -minrate 4000k -maxrate 4000k -an BBB_H264_VERY_SLOW_2000k.mkv
[00:17:32 CET] <furq> that's not 2000k
[00:17:49 CET] <pinPoint> i know. I decided to give h264 a fighting chance. LOL
[00:17:56 CET] <pinPoint> it will die anyways
[00:18:54 CET] <pinPoint> should I be seeing this: frame=  669 fps=5.3 q=41.0 size=   14069kB time=00:00:19.40 bitrate=5940.7kbits/s     ???
[00:19:08 CET] <pinPoint> why is the bitrate so high at the beginning?
[00:19:11 CET] <furq> it's not cbr
[00:19:14 CET] <furq> 4000k is the average bitrate
[00:19:23 CET] <pinPoint> i gave it max/min no?
[00:19:43 CET] <furq> minrate and maxrate don't really work how you'd expect
[00:19:49 CET] <furq> there is no way to do a true cbr encode with x264
[00:20:03 CET] <pinPoint> :/
[00:20:09 CET] <furq> i don't see why that's a problem though
[00:20:26 CET] <pinPoint> its dropping to 4.5 now
[00:20:30 CET] <furq> cbr is pretty much worthless
[00:21:20 CET] <pinPoint> is it just a limitation of the codec itself or ffmpeg?
[00:21:51 CET] <furq> the codec
[00:22:04 CET] <furq> i've not tried but i doubt that vp9 or x265 will do cbr either
[00:23:01 CET] <pinPoint> ok its down to 4014 now
[00:23:46 CET] <pinPoint> why is vp9 encoding so slow? is it only ment to be used in huge system areas?
[00:23:55 CET] <pinPoint> meant*
[00:24:10 CET] <furq> we've been spoiled by how fast x264 is
[00:24:32 CET] <pinPoint> but we have strong muscle computers nowadays. :)
[00:24:43 CET] <pinPoint> well at least what a hexa can do
[00:25:03 CET] <furq> fwiw i would expect x264 veryslow @ 4mbit to smoke x265 fast @ 2mbit
[00:25:10 CET] <furq> you should probably compare them at the same bitrate
[00:25:18 CET] <pinPoint> frame= 2461 fps=4.8 q=34.0 size=   38058kB time=00:01:19.13 bitrate=3939.8kbits/s
[00:25:33 CET] <pinPoint> that line ^^ q=34 is that the cfr?
[00:26:04 CET] <furq> that's the current quantiser
[00:26:15 CET] <pinPoint> furq: that is giving too much power to h265 if I compare them both @ 4000k
[00:26:22 CET] <furq> it really isn't
[00:26:47 CET] <furq> x265 doesn't start to show big gains over x264 until you get to the slower presets
[00:27:48 CET] <pinPoint> alright. I'll give 4000k to x265 @ veryslow. But i'm afraid x264 will still loose... it should be interesting to watch.
[00:27:50 CET] <furq> i've barely touched x265 yet because it's just not worth it for my use case
[00:28:13 CET] <furq> at the same bitrate x264 will probably lose, but not by much
[00:28:25 CET] <pinPoint> furq: I use it many times to remove 4k videos from youtube to put them on my UHD displays at work.
[00:28:43 CET] <pinPoint> they only play x265 w/aac at UHD. Nothing else
[00:29:03 CET] <furq> well i mean i've got a bunch of x265 stuff, but i've only encoded a couple of test files
[00:29:08 CET] <pinPoint> at first I was using handbrake. Now I don't touch it as much
[02:02:41 CET] <pinPoint> furq: the h264 just finished and I can barely notice any blocking on it.
[02:02:58 CET] <pinPoint> interesting... this is going to be very difficult to compare with h265.
[02:03:19 CET] <basisbit> why that?
[02:03:30 CET] <pinPoint> with the naked eye
[02:05:16 CET] <basisbit> if you have two excact same 4k screens, play the videos in parallel and compare scene for scene. that is how we do quality control for our video-streaming service
[02:06:13 CET] <basisbit> pinPoint, so how was encoding time of h265 compared to h264?
[02:06:46 CET] <furq> he's comparing x264 veryslow with x265 fast
[02:06:58 CET] <furq> which afaik should be roughly the same in terms of speed
[02:08:37 CET] <pinPoint> basisbit: for veryslow(h265) its very sloow. 0.7fps
[02:09:40 CET] <pinPoint> encoding-wise.
[02:09:58 CET] <pinPoint> basisbit: i have a dci lg 31 here. I'll do a side by side.
[02:10:40 CET] <furq> did you do a 2-pass encode
[02:10:42 CET] <pinPoint> furq: the tests on my post were real. It is possible to get away with h265 at lower bitrate
[02:10:52 CET] <pinPoint> furq: no. just a 1 pass
[02:11:11 CET] <furq> you'll get better results with 2-pass if you're using a fixed bitrate
[02:11:19 CET] <furq> i expect that's also true of x265 though
[02:12:19 CET] <pinPoint> that means utilizing lower kbps and getting roughly the same quality. bandwidth management and all
[02:12:31 CET] <furq> sure, i don't doubt that
[02:12:33 CET] <basisbit> so, for real-time streaming, expensive new hardware will be needed to get the higher quality at same bitrate (-> h265). sadly no christmas present there
[02:12:59 CET] <furq> if you don't mind encoding at 0.7fps then i'm sure x265 gives much better results than x264 can
[02:13:03 CET] <pinPoint> basisbit: it seems a quadcore is needed. so new set top boxes are a must
[02:13:49 CET] <pinPoint> basisbit: http://wideopenbokeh.com/AthenasFall/?p=172   --- i talked about it there.
[02:14:01 CET] <basisbit> pinPoint, or more likely some hardware implementation in graphics chipset of the set top box
[02:14:01 CET] <pinPoint> I'll take feedback too for changes/etc
[02:14:18 CET] <pinPoint> like the new nvidia k1
[02:14:27 CET] <furq> my issue with x265 is that i see a lot of people using it with the faster presets where it barely outperforms x264, if at all
[02:14:51 CET] <pinPoint> http://www.nvidia.com/object/tegra-k1-processor.html
[02:16:02 CET] <pinPoint> h265 needs more muscle to playback where-else vp9 does not. Vp9 is vastly adopted by many browsers... ~50%
[02:16:30 CET] <furq> it's a shame vp9 is slower and worse quality than x265
[02:16:34 CET] <furq> or than HEVC rather
[02:16:49 CET] <furq> wait i got that backwards
[02:16:54 CET] <furq> it's a shame libvpx is slower and worse quality than x265
[02:20:33 CET] <basisbit> pinPoint, nice article, that basically answers 95% of my questions regarding h265 currently :D
[02:21:45 CET] <basisbit> (switching the sides on the comaprison-pictures was evil...) :D
[02:21:56 CET] <pinPoint> its a novice's observation, i'm sure I can make it better. :) thanks
[02:22:18 CET] <pinPoint> basisbit: its to make sure you're aware and awake. :D
[02:22:41 CET] <pinPoint> so this 5%... what is missing?
[02:25:05 CET] <basisbit> details about how well the current decoding implementations do on older hardware (no avx,...) and what "cheap" hardware-decoders are available already (if any)
[02:25:29 CET] <basisbit> but I'll google that. don't want to steal all your time :D
[02:26:45 CET] <pinPoint> i don't even think software decoding is an option is it?
[02:27:55 CET] <basisbit> depends on speed and hardware requirements :D
[02:27:58 CET] <pinPoint> basisbit: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Testing-the-Vitec-MGW-Ace-and-MGW-D265-for-HEVC-Encode-Decode-107963.aspx
[02:28:08 CET] <pinPoint> encode/decode hardware
[02:29:54 CET] <furq> software decoding on what platform
[02:30:08 CET] <basisbit> exactly
[02:30:30 CET] <pinPoint> so zero
[02:32:11 CET] <basisbit> one use case is a karaoke game which runs on about any hardware whcih supports opengl 1.2 and which can fluently play 30fps 720p h264 videos @ ~2Mb/s using ffmpeg
[02:33:02 CET] <basisbit> the other use case of me is for streaming sattelite TV signal to customers over the internet with almost "no latency"
[02:33:29 CET] <pinPoint> youtube already uses vp9 and h264 fluently
[02:33:52 CET] <basisbit> for the first use case, h265 most likely won't be a good idea because of increase in cpu-requirements for same quality?
[02:34:24 CET] <basisbit> but switching from h264 to vp9 would most likely make sense, right?
[02:35:08 CET] <pinPoint> you can probably do 720p,30fps,h265 @ ~1Mb/s for a lesser connection. But more compute time is required
[02:35:18 CET] <pinPoint> vp9 makes more sense yes
[02:35:21 CET] <furq> basisbit: https://blogs.gnome.org/rbultje/files/2015/09/ffmpeg-libvpx-openhevc-decoder-mt.png
[02:36:00 CET] <furq> that's at 4mbit
[02:36:46 CET] <Nosomy> VP9 encode time = HEVC encode time
[02:37:02 CET] <pinPoint> vp9 is slower actually from my experience here
[02:37:05 CET] <Nosomy> then no make sense use VP9.
[02:37:10 CET] <pinPoint> even using -threads infinity. :D
[02:37:17 CET] <furq> it might make sense if decoding is the bottleneck
[02:37:44 CET] <furq> personally i'd stick with x264 until the newer codecs mature a bit more
[02:37:49 CET] <pinPoint> agreed, while vp9 sucks on encoding. decoding is cheap on hardware almost h264 cheap
[02:38:06 CET] <furq> no harm in experimenting though
[02:38:19 CET] <basisbit> Nosomy, the first use case is an offline game whcih contains lots of video stuff. encoding the files may take a long time as long as decoding is not slower then compared to h264.
[02:39:19 CET] <basisbit> so with VP9 I get better quality at roughly the same decoding hardware requirements
[02:39:21 CET] <Nosomy> HEVC 8bpp decode requirements = H264 10bpp decode requirements
[02:39:24 CET] <pinPoint> furq: do you use some sort of tool to compare two different encodes?
[02:39:29 CET] <pinPoint> something free?
[02:39:32 CET] <furq> my eyes
[02:39:36 CET] <pinPoint> lol
[02:39:44 CET] <furq> although those aren't really free because i have to pay for glasses
[02:40:33 CET] <pinPoint> Nosomy: without specifying in ffmpeg any usage of libx265 defaults to 8bit yes?
[02:40:41 CET] <furq> i'm not aware of any better way of doing it with newer codecs with psy and whatnot
[02:40:48 CET] <TD-Linux> you can use metrics too, like the metrics in the daala repo, but eyes are always better
[02:41:03 CET] <Nosomy> yes
[02:41:14 CET] <pinPoint> TD-Linux: and if its too close to notice with eyes? :/
[02:41:24 CET] <furq> then pick the one which is faster
[02:41:48 CET] <Nosomy> ffmpeg only have libx264 and libx264 as 8bpp, this is defined in compile time.
[02:41:56 CET] <Nosomy> *libx265
[02:42:21 CET] <TD-Linux> pinPoint, well the metrics will tell you something. but yeah pick based on something else
[02:42:32 CET] <Nosomy> HEVC is much more blur than H264, VP9 ratecontrol is suck.
[02:42:33 CET] <TD-Linux> I recommend a free codec of course :)
[02:43:07 CET] <furq> i like x264. it's good
[02:43:11 CET] <furq> i don't know if that comes across
[02:44:55 CET] <TD-Linux> btw there are new licensing terms for HEVC. you no longer have to pay 0.5% of your revenue
[02:45:00 CET] <pinPoint> i also notice @4000kbps scanning through for areas h265 gets blocky for second. the processor/hardware is compensating...
[02:45:12 CET] <TD-Linux> instead you have to pay 2.5 cents per video (regardless if it's HEVC or not)
[02:45:23 CET] <TD-Linux> (from HEVC advance that is, MPEG-LA is unchanged)
[02:45:43 CET] <furq> you have to pay 2.5 cents for videos which aren't HEVC?
[02:45:44 CET] <pinPoint> TD-Linux: that price went up no?
[02:45:50 CET] <furq> how does that work
[02:45:52 CET] <pinPoint> for non-hevc?
[02:45:56 CET] <TD-Linux> furq, only if you use HEVC anywhere
[02:46:03 CET] <furq> well that's insane
[02:46:03 CET] <TD-Linux> obviously they can't enforce it if you don't use HEVC at all
[02:46:09 CET] <pinPoint> what the frell!?
[02:46:19 CET] <pinPoint> sounds like highway robery
[02:46:27 CET] <TD-Linux> pinPoint, well before you had to pay 0.5% of your revenue, which was worse.
[02:46:38 CET] <pinPoint> before hevc ?
[02:46:48 CET] <TD-Linux> with the old HEVC Advance rules
[02:47:00 CET] <TD-Linux> which is 1 of the 2 people you need to buy a HEVC license from
[02:47:20 CET] <pinPoint> so if netflix has one hevc video and 99.99999% h264 videos they have to pay all as hevc?
[02:47:26 CET] <TD-Linux> yes
[02:47:43 CET] <pinPoint> frell
[02:47:44 CET] <Nosomy> lol
[02:47:59 CET] <furq> if only i was rich enough to buy some codec patents
[02:48:07 CET] <TD-Linux> actually I might be reading this wrong
[02:48:29 CET] <TD-Linux> I think that's true for the "per subscriber" rate but not the "individual video" rate. I'm not totally sure.
[02:48:29 CET] <pinPoint> no wonder there is this: http://aomedia.org/
[02:48:33 CET] <TD-Linux> http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/HEVC-Advance-Releases-Revised-Licensing-Terms-108230.aspx
[02:48:59 CET] <pinPoint> uh, that is today
[02:49:21 CET] <TD-Linux> yup. they just changed them today.
[02:49:43 CET] <furq> They provide a royalty credit of $25,000, essentially a de minimis exception for low-quantity use.
[02:49:48 CET] <furq> well at least that's nice
[02:50:05 CET] <pinPoint> heh
[02:50:35 CET] <TD-Linux> furq, yeah, so a lot of small users will probably be ok.
[02:50:55 CET] <TD-Linux> it's a bit of a trap though. hope your small business doesn't come successful :^)
[02:51:05 CET] <pinPoint> vp10 cannot get here soon enough. or something else better
[02:51:11 CET] <furq> so tell me more about vp9
[02:51:31 CET] <pinPoint> TD-Linux: which is the ambition of all businesses
[02:51:36 CET] <pinPoint> how unfortunate
[02:52:18 CET] <furq> if it's .025 per video then that's a million videos
[02:52:29 CET] <furq> although i'm sure there's plenty of other ways to get charged
[02:53:01 CET] <pinPoint> furq: mobile
[02:53:36 CET] <pinPoint> so if you own a mobile device, a stb, and a uhd set. Manufactures will pass that down to ya
[02:54:02 CET] <pinPoint> oh you want 4k service for your tv? New box cost another $10 buckaroos
[02:56:05 CET] <furq> i can't tell if this is .025 per video available or per video watched
[02:56:48 CET] <pinPoint> overall though TD-Linux. It will cost providers like netflix/amazon even more $$$.
[02:57:26 CET] <pinPoint> "For this reason, the subscription license starts at $0.005 per month, one fifth the final $0.025 rate, with an intermediate stop at $0.015 in 2018-2019."
[02:57:43 CET] <TD-Linux> furq, per watched I think? here is their official PDF http://www.hevcadvance.com/pdf/RoyaltyRatesSummary.pdf
[02:57:49 CET] <furq> yeah i'd have thought so
[02:58:14 CET] <furq> i doubt netflix have a million videos available
[02:58:18 CET] <TD-Linux> yeah so netflix is a bit better off because they fit in subscription. so they pay per user per month, not per title.
[02:58:55 CET] <furq> so they'd only pay $1.25MM per month
[02:58:57 CET] <furq> bargain!
[02:59:11 CET] <basisbit> I am really happy that software patents are not valid in Europe :)
[02:59:31 CET] <furq> enjoy it while it lasts
[02:59:35 CET] <Nosomy> The problem is VP8/VP9 isn't good enough as video codecs.
[02:59:54 CET] <pinPoint> Nosomy: how long before it gets better?
[03:00:06 CET] <pinPoint> you think alliance of open media have a chance?
[03:00:17 CET] <basisbit> as long as we don't sell/use any of our stuff in the USA/Canada, there is no need to pay for h265 patent license feels^^
[03:00:18 CET] <pinPoint> "Day one founding members are Amazon, Cisco, Google, Intel Corporation, Microsoft, Mozilla and Netflix."
[03:01:00 CET] <pinPoint> I read that they will be cracking down hard on h265 usage also.
[03:01:09 CET] <furq> isn't VP9 supposed to be royalty-free
[03:01:16 CET] <pinPoint> so if you're a small timer better stay with h264
[03:01:23 CET] <pinPoint> furq: ya
[03:01:33 CET] <basisbit> or move outside of north america :D
[03:01:57 CET] <furq> then why is this alliance not called the alliance to make libvpx suck less
[03:02:06 CET] <TD-Linux> basisbit, hate to break it to you but their patent list has a lot of european patents.
[03:02:18 CET] <Nosomy> The problem is VPX specification.
[03:02:22 CET] <TD-Linux> furq, well it might be, it's pretty new.
[03:02:26 CET] <pinPoint> and many in the Asian region too!
[03:02:27 CET] <TD-Linux> and yeah the lack of a spec is not hot
[03:03:11 CET] <pinPoint> furq: they are probably cooking something. maybe google will offer what they have in vp10 into the group so they can work together?
[03:03:24 CET] <TD-Linux> pinPoint, that's exactly what's happened.
[03:03:26 CET] <furq> it says that's what they're doing
[03:03:47 CET] <pinPoint> it does?
[03:03:50 CET] <pinPoint> where? LOL
[03:03:57 CET] <furq> https://en.wikipedia.org/wiki/Alliance_for_Open_Media
[03:04:03 CET] <furq> The project will release free software under the Apache 2.0 license and will use elements from Daala, Thor, and VP10.
[03:04:22 CET] <pinPoint> oh what the frell! the wiki of course
[03:05:10 CET] <pinPoint> sounds like game over for hevc yes?
[03:05:56 CET] <furq> "we're going to release an amazing video codec based on daala in 2017" isn't a promise i'd invest anything in
[03:06:21 CET] <pinPoint> oh noes
[03:06:42 CET] <pinPoint> hevc is everywhere on my TV sets at work.
[03:07:25 CET] <pinPoint> and Apple and Samsung are on the patent pool for hevc. :/
[03:09:01 CET] <furq> http://www.hevcadvance.com/
[03:09:15 CET] <furq> i like how they illustrate "advanced video compression" with a 1300kbps 1080p h264 video
[03:09:45 CET] <pinPoint> at 1300 h264 is dead unfortunately.
[03:10:20 CET] <furq> i also like how they've covered up the logo on the front of their Brand X (r) Computers
[03:11:52 CET] <Nosomy> 56% at 720p?
[03:11:55 CET] <Nosomy> lol
[03:12:23 CET] <Nosomy> i need to do a new encode compare test
[03:12:57 CET] <TD-Linux> furq, well as long as VP9 can tide us over it'll be OK
[03:13:18 CET] <pinPoint> but who is using it out in the industry really TD-Linux ?
[03:13:29 CET] <TD-Linux> the largest video site in the world
[03:13:35 CET] <pinPoint> youtube
[03:14:04 CET] <TD-Linux> also wikipedia
[03:14:22 CET] <TD-Linux> but yeah, more adoption would be a lot better.
[03:16:09 CET] <Nosomy> VP9 is "beatiful" in teory, in pratice very slow to encode something into VP9.
[03:16:09 CET] <pinPoint> furq: using fast on h265 vs veryslow on h264. I cannot see a difference.
[03:16:21 CET] <Nosomy> lol
[03:26:22 CET] <pinPoint> well it is a doozy trying to compare these two. wow
[03:26:44 CET] <Nosomy> In my last tests (long time ago), same CRF, same preset (medium), same bpp (8bpp), HEVC went only 22% lower than H264, 0.78*(H264 Filesize)=(HEVC Filesize)
[03:27:09 CET] <Nosomy> in
[03:27:14 CET] <Nosomy> 720p
[03:27:21 CET] <TD-Linux> you can't compare CRFs across encoders.
[03:27:30 CET] <TD-Linux> it is not a measure of absolute quality.
[03:27:32 CET] <furq> or presets
[03:27:37 CET] <Nosomy> why not? the scale is the same.
[03:27:47 CET] <furq> because of the thing he just said
[03:27:48 CET] <TD-Linux> no it's not.
[03:28:16 CET] <pinPoint> crf of 23 on h264 is ~ 28 on h265 fyi
[03:28:26 CET] <pinPoint> to compare
[03:28:37 CET] <Nosomy> very old h264 default crf is crf 28 too
[03:28:44 CET] <Nosomy> and then?
[03:30:57 CET] <Nosomy> crf h264 todays is only a redefinition by dev convention.
[03:33:50 CET] <Nosomy> the scale is the same, both starts on 1 and ends in 51.
[03:33:51 CET] <kepstin> crf in x264 is vastly different between 8 and 10bit even
[03:34:05 CET] <Nosomy> if both is 8bpp
[03:34:06 CET] <kepstin> (in 10 bit, it's 0-63 or 64 iirc)
[03:34:48 CET] <kepstin> in vpx I think it's a log scale rather than linear?
[03:36:34 CET] <ethe> I spoke to someone here about FFmpeg with JACK input on OSX last week, I compiled jack with --enable-indev=jack but when I do `./ffmpeg_g -f jack -i ffmpeg -y out.wav` I just get `Unknown input format: 'jack'`
[03:36:47 CET] <ethe> I compiled FFmpeg*
[03:37:49 CET] <Nosomy> kepstin, crf scale in x264 8bpp and 10bpp is the same, although exists CRF Negative values, the dev talks this, only quantizers values are diffs
[03:38:39 CET] <pinPoint> furq: veryslow h265 2000k VS veryslow h264 4000k almost identical. I know they said 50% but I do not think the codec is there. I can see h264 winning at some places
[03:39:02 CET] <pinPoint> maybe 20-30% reduction in bitrate but not half(50%)
[03:39:04 CET] <furq> 50% would be 2mbit vs 3mbit
[03:39:22 CET] <Nosomy> pinPoint , ssim teste comparing with source
[03:39:26 CET] <kepstin> pinPoint: how long did the encode of each take? 'veryslow' in x265 is a lot slower than x264, so they're not really comparable :)
[03:39:29 CET] <Nosomy> which is better?
[03:39:34 CET] <Nosomy> i bet in h264
[03:39:53 CET] <kepstin> Nosomy: only if you run x264 with -tune ssim, of course ;)
[03:40:16 CET] <Nosomy> yep
[03:40:18 CET] <pinPoint> furq: then 20%
[03:40:36 CET] <Nosomy> x265 and x264 running ssim test encodes.
[03:40:39 CET] <pinPoint> ssim test? is there an application to test then videos?
[03:41:13 CET] <Nosomy> the encode provides the tests
[03:41:15 CET] <furq> is there much point to that
[03:43:17 CET] <pinPoint> ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v libx265 -preset fast -b:v 4000k -minrate 4000k -maxrate 4000k -an BBB_H265_VERY_SLOW_2000k.mkv
[03:43:25 CET] <pinPoint> encoded 19036 frames in 2115.39s (9.00 fps), 3964.30 kb/s, Avg QP:29.76
[03:44:42 CET] <pinPoint> I guess that is my next adventure. compare same parameters on different codecs and see the running times
[03:45:19 CET] <pinPoint> this folder is getting bigger. I'm up to 9.5GB already
[03:47:19 CET] <Nosomy> ffmpeg -i video -c:v libx265 -pass 1/2 -b:v 2M -x265opts ssim=1 nul/videoout.hevc
[03:47:42 CET] <Nosomy> ops
[03:47:56 CET] <Nosomy> is forgot tune
[03:48:24 CET] <pinPoint> -pass 1/2 will actually work?
[03:49:07 CET] <Nosomy> only in diffs cmdlines.
[03:49:38 CET] <pinPoint> this is waht I did on win10: ffmpeg -y -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v libx265 -preset veryslow -b:v 7501k -minrate 7501k -maxrate 7501k -pass 1 -an -f matroska NUL && ffmpeg -i bbb_sunflower_2160p_30fps_normal.mp4 -c:v libx265 -preset veryslow -b:v 7501k -minrate 7501k -maxrate 7501k -pass 2 -an BBB_HEVC_VERYSLOW_NOAUDIO_2PASS_7501k.mkv
[03:51:29 CET] <pinPoint> can ffmpeg be made to generate a log after finishing an encode?
[03:51:34 CET] <pinPoint> --report?
[03:51:47 CET] <pinPoint> with running time/etc
[03:53:14 CET] <Nosomy> http://x265.readthedocs.org/en/default/lossless.html#near-lossless-encoding some good tests to do.
[03:57:40 CET] Action: Nosomy waiting a CRC32 of 215GiB Tar file to sleep.
[03:57:46 CET] <Nosomy> lol
[04:07:17 CET] <pinPoint> huh?
[04:33:52 CET] <pinPoint> -report did not print duration of encode. :/
[04:34:18 CET] <xintox> anyone know how to play this? rtmpe://162.253.130.82:1935/hfufdxdrh/llive9
[04:41:39 CET] <wobble> new to the project.  I have a need to consume as of yet unspecified audio files and produce g.711 bitstreams, am I in the right place?
[05:47:11 CET] <pianoBrad> greetings!  Is anyone able to offer some insight into the compilation of a static version of ffmpeg?  Im on a mac and am running into some issues, primarily with the snappy hap encoding library
[08:47:03 CET] <xintox> pinPoint: sure
[08:47:09 CET] <xintox> woops
[08:47:12 CET] <xintox> wrong nick
[10:33:46 CET] <paule32_> hello
[10:33:53 CET] <paule32_> what means: [alsa @ 0x388ddc0] sample format 0x15001 is not supported
[10:33:55 CET] <paule32_> ?
[10:34:02 CET] <paule32_> how can i fix it
[10:48:35 CET] <paule32> hello
[10:48:55 CET] <paule32> how can i add sound from pcm hardware (sound card)?
[10:48:57 CET] <paule32> http://fpaste.org/303100/45051847/
[10:49:01 CET] <paule32> -i ha
[10:49:09 CET] <paule32> -i hw:... ?
[13:17:08 CET] <ethe> I compiled jack with --enable-indev=jack but when I do `./ffmpeg_g -f jack -i ffmpeg -y out.wav` I just get `Unknown input format: 'jack'`. Am I using the wrong command to get input from jack?
[13:27:35 CET] <JEEB> ./ffmpeg_g -formats |grep 'jack'
[13:27:53 CET] <JEEB> although not 100% sure how indevs showed up
[13:27:56 CET] <droid909> ethe: what is jack?
[13:28:05 CET] <JEEB> droid909: audio thing
[13:28:07 CET] <droid909> ethe: does it allow you to record from the mic?
[13:28:09 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-devices.html#jack
[13:28:36 CET] <droid909> ethe: is it accecible on mac?
[13:28:49 CET] <droid909> accessible*
[13:28:58 CET] <droid909> JEEB: is it?
[13:29:03 CET] <ethe> yes
[13:29:11 CET] <JEEB> I think he was working on that, and now it isn't working after he fixed compilation :P
[13:29:26 CET] <JEEB> ethe: does it show up in the list?
[13:29:29 CET] <ethe> nah, it's 100% working now
[13:29:31 CET] <ethe> https://gist.github.com/joshdekock/e471c2e66016cfe927a5
[13:29:34 CET] <droid909> JEEB: can i record audio from the mic with it?
[13:29:39 CET] <ethe> droid909: yes
[13:30:04 CET] <JEEB> ethe: so does it show up as a format in the format listing?
[13:30:11 CET] <ethe> you should be able to. I tested JACK independently from FFmpeg and it records audio fine
[13:30:15 CET] <JEEB> not sure if listing indevs is separate
[13:30:43 CET] <JEEB> ok, dshow is there too
[13:30:53 CET] <droid909> ethe: i was using avfoundation, but it involves installing xcode and i wanted to avoid that
[13:31:00 CET] <JEEB> so ./ffmpeg_g -formats |grep 'jack' should show it
[13:31:16 CET] <JEEB> if it isn't there then something else was fucked :P
[13:31:39 CET] <ethe> droid909: JACK uses a waf build system so (I think) it doesnt require xcode
[13:31:42 CET] <JEEB> like, with dshow I get " D  dshow           DirectShow capture" as output
[13:31:43 CET] <droid909> JEEB: don't see jack installed on my system
[13:31:54 CET] <ethe> droid909: you have to install it >.<
[13:32:08 CET] <JEEB> ethe: does it show up?
[13:32:16 CET] <ethe> no
[13:32:18 CET] <droid909> ethe: i guess i have to give my homebrew more params than just brew install ffmpeg
[13:32:37 CET] <JEEB> ok, then you have enabled it on the configure line but it isn't really built in :P
[13:32:43 CET] <JEEB> bug report time I guess
[13:33:23 CET] <droid909> ethe: where to get 'jack' binary for mac os?
[13:34:25 CET] <droid909> dshow is only for windows ... :(
[13:34:33 CET] <JEEB> that was just an example
[13:34:43 CET] <JEEB> of how capture "formats" should show up
[13:34:50 CET] <droid909> i see
[13:35:03 CET] <droid909> JEEB: do you know where i can get 'jack' binary for mac os?
[13:35:03 CET] <JEEB> ethe: I guess it's time for you to poke that trac thread :P
[13:35:12 CET] <ethe> droid909: it's in dev atm
[13:35:30 CET] <ethe> You *could* get it, but it's not gift wrapped.
[13:35:43 CET] <droid909> ethe: well, i found bins http://jackaudio.org/downloads/
[13:36:01 CET] <ethe> yeah those dont work with ffmpeg
[13:36:05 CET] <ethe> those are *so* old.
[13:36:10 CET] <droid909> ohh :(
[13:36:20 CET] <ethe> https://github.com/joshdekock/jack2-fork/tree/merger-branch you could try compile this
[13:36:28 CET] <ethe> JEEB: okie dokie
[13:36:35 CET] <droid909> ethe: do you by any chanse know avfoundation alternatives for mac os
[13:36:39 CET] <droid909> chance*
[13:36:52 CET] <droid909> ethe: i need to record audio on mac os from the mic
[13:37:19 CET] <JEEB> no
[13:37:21 CET] <droid909> ethe: avfoundation works but i don't wanna have xcode on my system
[13:37:27 CET] <JEEB> nothing else that is currently tested :P
[13:37:34 CET] <droid909> i see, thanks
[13:37:53 CET] <JEEB> IFF ethe gets his stuff working, then that is an alternative. but only at that point, and not earlier
[13:38:07 CET] <JEEB> also don't you get all the compilers etc from xcode anyways
[13:38:25 CET] <JEEB> at least that's how you used to get all the development shit on OS X
[13:38:58 CET] <ethe> yeah Xcode has all the dev tools
[13:39:19 CET] <ethe> you could use the CLI tools package, but that's stripped down, and I dont think it has all the dev tools needed
[13:39:29 CET] <droid909> JEEB: well, yes, homebrew requires xcode, i just want to remove xcode after it got install, but i guess avfoundation got removed too with the xcode
[13:39:35 CET] <droid909> installed*
[13:39:57 CET] <ethe> you could always just extract avfoundation
[13:40:15 CET] <droid909> ethe: just extract from xcode?
[13:40:17 CET] <JEEB> ethe: don't recommend things to people that could lead to lulzy breakage :P
[13:40:28 CET] <JEEB> just let them have a normal development setup
[13:40:29 CET] <ethe> droid909: yeah ignore me XD
[13:40:34 CET] <droid909> fuck no :)
[13:40:40 CET] <droid909> ethe: please continue :D
[13:40:56 CET] <JEEB> I don't want to support anything that can be randomly fucked up
[13:41:09 CET] <ethe> nah, on second thought, I'm not going to tell you how to break your computer :)
[13:41:17 CET] <ethe> potentially*
[13:41:19 CET] <droid909> JEEB: well, i don't do dev with ffmpeg, i just want it working without fatty xccode on my system
[13:41:44 CET] <droid909> ok :D
[13:41:58 CET] <droid909> thanks guys, you a great :D
[13:42:16 CET] <droid909> i understand your point
[13:42:53 CET] <droid909> ethe: i know how can i extract it, i just not yet know how to connect ffmpeg with it ...
[13:46:27 CET] <droid909> JEEB: "lulzy breakage" :D
[14:02:26 CET] <paule32> i have this config in my system: http://fpaste.org/303100/45051847/
[14:03:04 CET] <paule32> but i don't know, how to stream desktop audio (mic/pcm) to ffmpeg and broadcast it
[14:03:21 CET] <paule32> desktop is ok, but without sound
[15:11:21 CET] <sylvain> hi
[15:12:24 CET] <Guest26812> how can i limit the output bitrate with libx265 ? if i use b:v  -bufsize -bitrate and -maxrate it seems working with x264 but not x265
[20:10:20 CET] <MachinaeWolf> Can you record from a mic line in with ffmpeg and alsa?
[20:10:48 CET] <c_14> if it's listed as an alsa input device, sure
[20:12:04 CET] <MachinaeWolf> How do I check that?
[20:18:23 CET] <c_14> arecord -l
[20:21:29 CET] <MachinaeWolf> http://dpaste.com/2GJHWV2
[20:22:55 CET] <c_14> assuming your mic is on card 0, sure. ffmpeg -f alsa -i hw:0,0,0
[20:26:05 CET] <MachinaeWolf> that worked, thanks :)
[20:37:47 CET] <DrJ> ffmpeg -i http://ip:8000/stream -acodec copy -t 60 out.mp3
[20:38:12 CET] <DrJ> I have that command which works great.  I'm wondering if it is possible though to modify it so "silent" periods of audio are not written to out.mp3
[20:38:38 CET] <DrJ> I'm currently removing them after the fact via: sox out.mp3 final.mp3 silence 1 0.1 1% -1 0.1 1%
[20:38:59 CET] <DrJ> if possible I would like to consolidate that though to one command with ffmpeg
[20:40:23 CET] <c_14> you'll have to reencode, but -af silenceremove should do it
[20:40:28 CET] <c_14> might need to set the options for it though
[20:40:52 CET] <c_14> https://ffmpeg.org/ffmpeg-filters.html#silenceremove
[20:46:52 CET] <DrJ> so it has to be a seperate command regardless
[20:47:03 CET] <waressearcher2> DrJ: ffmpeg -i http://ip:8000/stream -acodec copy -t 60 - | sox - final.mp3 silence 1 0.1 1% -1 0.1 1%      ?
[20:47:37 CET] <DrJ> waressearcher2: hmm, let me see if that works
[20:47:43 CET] <c_14> DrJ: ffmpeg -i http://ip:8000/stream -af silenceremove -t 60 out.mp3
[20:48:55 CET] <durandal_1707> you need to set options if you want same output as sox
[20:50:57 CET] <DrJ> waressearcher2: doesn't work
[20:51:19 CET] <DrJ> sox FAIL formats: can't determine type of  `-'
[20:51:55 CET] <durandal_1707> it can't work with acodec copy, unless sox recognize that codec
[20:52:30 CET] <DrJ> well, sox does know how to handle the final output of that command
[20:52:35 CET] <DrJ> that already works
[20:52:46 CET] <DrJ> just not sure if it can be piped in
[20:52:53 CET] <durandal_1707> ffmpeg have same filter
[20:53:14 CET] <durandal_1707> silenceremove
[20:53:42 CET] <durandal_1707> Otherwise you need to pipe pcm to sox IIRC
[20:53:59 CET] <paule32> hello
[20:54:59 CET] <paule32> is it possible to stream screen 0 and desktop x in time, where the streamer is using an other desktop than x? if then so, how can i do it?
[20:55:24 CET] <durandal_1707> you can use sox -t sox and change ffmpeg to pipe sox format
[20:55:47 CET] <durandal_1707> if you want to use sox
[21:05:46 CET] <durandal_1707> DrJ: tried sox -t sox or you need exact command line?
[21:27:09 CET] <paule32> what is the best audio codec to stream a+v ?
[21:27:16 CET] <paule32> i have only a noise
[21:27:42 CET] <furq> if this is over rtmp/hls then your only real choice is aac
[21:28:16 CET] <paule32> how can i add it -c:v aac  ?
[21:45:19 CET] <paule32> ok, thank you furq
[21:45:31 CET] <paule32> i use gnome
[21:45:47 CET] <paule32> so nearly all desktop managers have virtual desktops
[21:46:03 CET] <paule32> how can i access these virtual desktops
[21:46:05 CET] <paule32> ?
[21:46:39 CET] <paule32> what i want is: work on vd 1, and stream content on vd 2
[21:53:38 CET] <c_14> virtual desktops aren't rendered by X
[21:53:52 CET] <c_14> therefore you can't (at least not via x11grab or xcbgrab)
[21:56:51 CET] <paule32> ok
[23:14:49 CET] <ethe> c_14: I finally got jack fully working on OSX, so now I can try to get ffmpeg to work with it. I tried using your rebased patch, but from what I can see, it's not actually getting compiled in. (I've updated ticker #43)
[23:14:53 CET] <ethe> ticket*
[23:16:20 CET] <c_14> ethe: can I see the config.log output?
[23:17:00 CET] <ethe> https://gist.github.com/joshdekock/db487721d120d60d8ed5
[23:17:44 CET] <ethe> jack is in the list of indevs, and if I remove the jack installation then ffmpeg complains about jack's sharedlib not being there
[23:21:32 CET] <c_14> Is it listed in ffmpeg -devices ?
[23:22:06 CET] <ethe> no :(
[23:22:28 CET] <JEEB> ooh, thanks for reminding me of that option, I tried "indevs" and then thought it just wasn't there :)
[23:23:11 CET] <ethe> avfoundation, lavfi, qtkit, and sdl are the only ones there
[23:28:25 CET] <c_14> When configure finishes, is it listed in the output under Enabled Indevs?
[23:33:35 CET] <ethe> no
[23:34:46 CET] <ethe> no /14
[23:34:47 CET] <c_14> then there might be something missing in the patch
[23:34:57 CET] <ethe> err oops
[23:42:15 CET] <c_14> ethe: can you try applying this on top of the current patch? https://pb.c-14.de/t/kng.kycmfM
[23:42:37 CET] <c_14> then again checking if it's listed as enabled under the indev_deps
[23:47:10 CET] <ethe> It's an enabled indev now, according to configure
[23:48:58 CET] <c_14> right, try building and using it
[23:49:03 CET] <c_14> so it was that... hmm
[23:57:12 CET] <ethe> c_14: https://gist.github.com/joshdekock/28b62ddc4d0d638e1f6e so it's exactly the same error as previously seen
[00:00:00 CET] --- Sun Dec 20 2015