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

[burek]

[00:03:22 CEST] <Hello71> Or are on a shit mobile CPU and can only encode 2 fps
[00:07:31 CEST] <nicolas17> I'm encoding an image sequence into a video file and I *suspect* the bottleneck is decompressing the original JPEGs, is there any way to make it parallel? decode multiple images at the same time and queue them?
[00:07:57 CEST] <nicolas17> ffmpeg is using only one core
[00:15:16 CEST] <nicolas17> yeah I'm now transcoding to "-vcodec rawvideo /dev/null" and still getting 27fps, bottleneck is definitely decoding JPEGs
[00:18:20 CEST] <atomnuker> if you have vaapi or cuda you can decode them in hardware
[00:18:45 CEST] <nicolas17> now that's an idea
[00:19:03 CEST] <nicolas17> I only have an Intel integrated GPU but in my experience it still helps
[00:23:11 CEST] <nicolas17> atomnuker: yeahhh it's now 63fps with the input in the disk cache, I think for cold cache the disk will be the bottleneck now
[00:23:14 CEST] <nicolas17> thanks!
[00:26:39 CEST] <nicolas17> or not
[00:26:56 CEST] <nicolas17> if I encode into a real thing (rather than null output) I'm getting a 100% green image
[00:29:01 CEST] <nicolas17> ok decoding works, scale_vaapi doesn't
[00:35:19 CEST] <ballefun> youtube has live sending. How do they do that. They can't transcode for a few million ppl RT. There is not enough time to make DASH or HLS and have a latency of 200ms...
[00:36:55 CEST] <nicolas17> are you sure youtube has that latency?
[00:37:40 CEST] <ballefun> Yes a friend of mine was doing a live pod. I was watching him speak and watching on YT as a monitor
[00:38:04 CEST] <furq> they use hls and they don't have 200ms latency
[00:38:22 CEST] <furq> 20000 maybe
[00:38:27 CEST] <ballefun> furq, so they encode hls streams RT?
[00:39:10 CEST] <c_14> ballefun: why not?
[00:40:02 CEST] <c_14> encoding h264 real-time isn't really a big deal, plus since input is controlled (more or less) anyways, they could just make hls without reencoding
[00:40:26 CEST] <ballefun> c_14, take a look how many parallel steams they offer. Not sure about 4k but everything under that I would think they offer.
[00:40:29 CEST] <c_14> twitch reencodes millions of livestreams as hls all the time
[00:41:15 CEST] <nicolas17> c_14: and under at least 4 formats, for popular streams
[00:41:48 CEST] <c_14> 1080p 720p 480p 360p from what I've seen
[00:41:52 CEST] <ballefun> yeah
[00:41:56 CEST] <c_14> I don't think live youtube offers more
[00:42:15 CEST] <c_14> (well, maybe 4k but w/e)
[00:42:32 CEST] <nicolas17> for less popular streams twitch only shows you the 'source' format which afaik is just the input stream sliced into pieces, not reencoded
[00:42:55 CEST] <ballefun> Just try doing that will some home video on your pc =P
[00:43:04 CEST] <ballefun> with*
[00:43:32 CEST] <nicolas17> bleh
[00:43:41 CEST] <nicolas17> scale_vaapi results in a static green image
[00:44:17 CEST] <nicolas17> doing hwdownload of the full size, 45fps
[00:44:29 CEST] <nicolas17> doing hwdownload of the full size and the 'scale' filter in software, 37fps
[00:45:33 CEST] <ballefun> anyway what is a safer bet. DASH or HLS for streaming to HTML5 browsers. x264 acc I assume is what I should be using too?
[00:46:02 CEST] <ballefun> some people actually use Apple products it turns out ;)
[00:59:22 CEST] <ballefun> Can I implement HLS into a software that is under the Debians DFSG ?
[01:10:33 CEST] <nicolas17> I don't see why not
[01:13:06 CEST] <garyserj> I have a video aa.3gp how do I rotate it 180 degrees?
[01:14:23 CEST] <nicolas17> transcode it with -vf hflip,vflip
[01:17:38 CEST] <furq> or just -c copy -metadata:s:v:0 rotate=180
[01:17:54 CEST] <furq> or rotate=0 if it's a phone camera that's flipped it because your phone was upside down
[01:18:14 CEST] <garyserj> ffmpeg -i aa.3gp -vf "hflip,vclip" output.3gp <-- Only 8000Hz sample rate supported . Error initializing output stream 0:1 -- Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height
[01:19:09 CEST] <nicolas17> it's trying to transcode the audio and failing; maybe you want -acodec copy
[01:19:52 CEST] <garyserj> is a phone.. furq, this works- ffmpeg -i aa.3gp -c copy -metadata:s:v:0 rotate=0 output.3gp works.
[01:20:15 CEST] <nicolas17> oh nice
[01:20:22 CEST] <BtbN> I doubt 3gp supports that
[01:20:23 CEST] <garyserj> nicolas17- furq's thing works, but out of curiosity i'll try your suggestion
[01:20:24 CEST] <BtbN> get rid of 3gp
[01:20:47 CEST] <garyserj> oh my phone saves video as 3gp
[01:20:50 CEST] <furq> yeah the ffmpeg 3gp muxer defaults to h263 and amr_nb
[01:20:57 CEST] <furq> but you should probably just remux to mp4
[01:21:36 CEST] <furq> 3gp is some kind of subset of isobmff anyway
[01:23:03 CEST] <garyserj> hmm actually is still upside down.. whether rotate=0 or rotate-180
[01:23:17 CEST] <BtbN> Use mp4
[01:23:18 CEST] <garyserj> so yeah maybe i'll try to reencode it as mp4
[01:23:24 CEST] <BtbN> *remux
[01:23:42 CEST] <nicolas17> with -c copy it won't reencode, just stick the existing video and audio streams into an mp4 container
[01:25:08 CEST] <garyserj> i'm going to do -acodec libmp3lame -vcodec libx264
[01:25:15 CEST] <BtbN> why?
[01:25:17 CEST] <BtbN> just copy
[01:26:05 CEST] <garyserj> okay i will try -c copy
[01:56:29 CEST] <garyserj> Does mp4 container support AVC video, AAC audio?
[01:58:58 CEST] <furq> it sure does
[02:29:07 CEST] <nicolas17> I'm speeding up a video with the simple setpts=PTS/4 thing
[02:29:24 CEST] <nicolas17> does ffmpeg have anything to speed up a video interpolating frames? I want some motion blur
[03:41:05 CEST] <ahoo> wow.
[03:41:16 CEST] <ahoo> x265 is impressively efficient
[04:24:49 CEST] <DHE> av1 is even better, although it takes like 15 minutes per frame today at 1080p (varying by CPU of course)
[04:26:06 CEST] <nicolas17> seriously?
[04:37:03 CEST] <DHE> well, last I tried, which was a few months ago. I don't expect it to have improved by that much in the intervening time...
[04:37:18 CEST] <DHE> certainly not remotely realtime... maybe 5 minutes per frame. I should check on how that's going.
[04:51:12 CEST] <nicolas17> how's x265?
[04:58:24 CEST] <DHE> it can do realtime if you scale it way back... or you can invest the CPU time and get a really good image compared to h264
[04:59:12 CEST] <DHE> they say h265 can get a ~40% bitrate reduction compared to h264 with about the same human-eye-perception quality. but it definitely takes CPU power to do it
[06:10:31 CEST] <ahoo> incredible.
[06:10:41 CEST] <ahoo> 1 hour HD video compresses to 180MB
[07:02:24 CEST] <kerio> how do you compare human eye perception, tho?
[07:02:43 CEST] <kerio> is there a table of matching CRF values?
[07:02:55 CEST] <kerio> (for libx264/libx265)
[07:52:50 CEST] <mixfix41> ah i launched ffplay in console and i think it enabled sdl2 framebuffer
[07:53:04 CEST] <mixfix41> so the video ended and my keyboard keys are missing
[07:54:27 CEST] <mixfix41> but i see in show keys that the input is a bit lower level and i tried loading a keymap through ssh to no avail
[07:55:24 CEST] <mixfix41> i see in a thread kbd_mode -a to add in scripts/ or sdl2 apps to prevent this but not sure how to use that with ffplay even
[10:50:02 CEST] <yuken> So, I'm planning on mass-transcoding media and I don't care about how accurate it is to the source, so long as it still looks good. Think default settings are good, just defining which codec & bitrate I want?
[10:50:27 CEST] <yuken> specifically, H264 transcoded to VP9 (or AV1 once available)
[11:08:37 CEST] <Nacht> Well, AV1 is 'available'
[11:09:24 CEST] <yuken> Is it now? I know it was getting locked somewhere around now.
[11:09:38 CEST] <Nacht> But I wouldn't really use it other then to laugh at how slow it is
[11:09:38 CEST] <furq> the default vpx settings (other than bitrate) are about as good as you'll get in terms of quality
[11:09:58 CEST] <furq> but they're not quick, to say the least
[11:10:10 CEST] <yuken> Nacht, I did use it once, compiled it before it was in ffmpeg, 0.2FPS for 1080p on a 4790k.
[11:10:14 CEST] <yuken> so I guess you're right there :p
[11:10:29 CEST] <furq> yeah libaom is still a reference encoder at this point
[11:10:40 CEST] <furq> you're lucky it was that fast honestly
[11:10:56 CEST] <yuken> VP9 and H265 were about the same for me though, and VP9 is more web-friendly and such, so I'm leaning towards that.
[11:11:17 CEST] <furq> if you're not doing this for licensing reasons then i would leave them as they are
[11:11:29 CEST] <yuken> More space reasons.
[11:11:39 CEST] <yuken> I can halve the size of a lot of my media while retaining quality and getting better web compatibility.
[11:11:57 CEST] <furq> nothing has better web compatibility than h264
[11:12:06 CEST] <yuken> Really?
[11:12:11 CEST] <furq> and you'll be very lucky to halve the size and keep the quality
[11:12:38 CEST] <furq> and yeah everything supports h264
[11:12:40 CEST] <yuken> Well, I've definitely done that with a lot of my media, which were high-quality x264 encodes of blu-rays.
[11:12:45 CEST] <furq> including pretty much every hardware decoder
[11:13:03 CEST] <furq> apple stuff doesn't support vp9 at all and only new devices support it in hardware
[11:13:28 CEST] <yuken> Bringing x265 into the mix and lowering audio bitrate from 1.5Mbps to 192Kbps (384 for 7.1ch), 1.5GB down to 550MB. Comparing stills & moving clips shows a couple pixels of difference @ 1080p.
[21:13:06 CEST] <barhom> What nvresize removed from ffmpeg or something or was it never a part of it?
[21:14:27 CEST] <c_14> scale_npp ?
[21:16:01 CEST] <barhom> do I have to enable that when compiling ffmpeg?
[21:17:00 CEST] <furq> --enable-libnpp
[21:17:34 CEST] <furq> nvresize was always a thirdparty patch
[21:19:19 CEST] <barhom> furq: thanks, trying to compile libnpp right now
[21:19:20 CEST] <barhom> ERROR: libnpp not found
[21:19:30 CEST] <barhom> Im including the nv-codec-headers already
[21:22:48 CEST] <barhom> I found something called CUDA toolkit 9.2, 1.7g!? is that whats needed for libnpp...
[21:23:32 CEST] <barhom> I did not expect to download 1.7g of bloatware to get a new filter
[23:09:25 CEST] <barhom> Anyone know if the scale filter is skipped completely i.e. (not using cpu time) when I set it to "scale=-2:'min(720,ih)" (the input is 720x576) ?
[23:09:53 CEST] <barhom> From my testing, it seems that even though it wasnt resized the scale filter seems to still take cpu power
[23:11:13 CEST] <barhom> Im trying to make it "if conditional", i.e. if height is less than 720 then dont add the scale filter at all
[23:13:45 CEST] <furq> i'm pretty sure it's a no-op but you can check with -v debug
[23:29:02 CEST] <chauffer> hey there, i have an usecase where i need to get a few seconds of video&audio from HLS, i have an m3u8 file remotely which works fine -- input seeking seems to work for about half of the timesets i need to download, haven't investigated as to why, when it doesn't work it logs no error and the file is 4KB big, output seeking works well but it takes al ong time if the start of the video i need is towards the
[23:29:03 CEST] <chauffer> end - i am using ffmpeg 3.4 on alpine
[00:00:00 CEST] --- Tue Sep  4 2018