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

Mon Oct 29 03:05:01 EET 2018

[00:28:29 CEST] <Rathann> hi, can anyone provide a working FFmpeg command line that uses Intel QSV via lu-zero's libmfx to encode a H.264 stream?
[00:33:04 CEST] <JEEB> did that need anything special? other than IIRC the intel drivers etc being extra finicky?
[00:33:21 CEST] <JEEB> I think vaapi was the more generally working interface
[00:33:34 CEST] <JEEB> (for encoding as well if you checked with vainfo
[00:37:46 CEST] <Rathann> it works via vaapi
[00:38:12 CEST] <JEEB> I'd generally recommend that. I remember the QSV crap needing special drivers etc
[00:38:17 CEST] <Rathann> I just wanted to test libmfx code path
[00:39:07 CEST] <Rathann> https://paste.fedoraproject.org/paste/9tc81EMYdK-WtdIQQUxnRQ <- here's the command and ffmpeg output
[00:39:40 CEST] <c_14> Rathann: did you patch and recompile the kernel?
[00:39:42 CEST] <Rathann> searching for the error message on the web reveals a couple of similar posts but no resolution
[00:39:45 CEST] <c_14> and reboot of course
[00:40:03 CEST] <JEEB> yea, that's what I meant with it being a PITA
[00:40:09 CEST] <JEEB> QSV needs a patched kernel
[00:40:13 CEST] <Rathann> c_14: why would I do that? which kernel and which patch?
[00:40:13 CEST] <JEEB> and all that jazz
[00:40:22 CEST] <c_14> Rathann: the qsv patchset from intel
[00:40:24 CEST] <c_14> it's a royal pain
[00:40:28 CEST] <Rathann> huh
[00:40:29 CEST] <jkqxz> Are you using the open-source libmfx or the proprietary media SDK?
[00:40:32 CEST] <c_14> especially when the patches don't apply and you have to fix them
[00:40:38 CEST] <Rathann> jkqxz: libmfx
[00:40:39 CEST] <JEEB> jkqxz: the lu_zero thing
[00:40:54 CEST] <jkqxz> Open-source libmfx should work normally on current kernels.
[00:41:00 CEST] <JEEB> ok
[00:41:18 CEST] <jkqxz> (Without crazy patching, which is required for the proprietary one.)
[00:42:44 CEST] <jkqxz> Hmm, "Unsupported".  Does you system actually support it?  (Is one of the platforms on <https://github.com/intel/media-driver>.)
[00:44:53 CEST] <Rathann> jkqxz: I have a Haswell CPU
[00:45:12 CEST] <Rathann> why would I look there to decide if it's supported or not?
[00:45:45 CEST] <JEEB> that probably was supposed to be a "where"
[00:45:49 CEST] <JEEB> and not "why"
[00:46:01 CEST] <jkqxz> Haswell is not supported by libmfx at all any more.
[00:46:13 CEST] <JEEB> alright, that explains it :)
[00:46:25 CEST] <jkqxz> Well, it is on Windows with old drivers.  But the open-source one doesn't.
[00:51:58 CEST] <Rathann> oh? where does the code say that?
[00:56:47 CEST] <jkqxz> "Supported Platforms" on that page.
[00:57:42 CEST] <Rathann> I'm guessing this is the line that gives the error: https://github.com/lu-zero/mfx_dispatch/blob/master/src/main.cpp#L216
[00:58:08 CEST] <Rathann> jkqxz: but VAAPI works just fine? I don't understand, libmfx seems to depend on VAAPI
[00:58:51 CEST] <JEEB> it IIRC uses other interfaces which might have been already left out or never supported in the standard open source drivers for this hardware
[00:59:04 CEST] <JEEB> at least for encoding
[00:59:23 CEST] <JEEB> vaapi on the other hand is just VAAPI (dec and enc)
[00:59:40 CEST] <JEEB> and clearly intel seems to be putting more interest there than QSV for a lot of things
[01:00:10 CEST] <Rathann> well, ok, I'll defer to you guys then
[01:00:23 CEST] <Rathann> thanks for trying to help
[01:00:33 CEST] <jkqxz> libmfx uses the iHD VAAPI driver rather than the i965 one, which doesn't support older platforms at all.
[01:01:35 CEST] <JEEB> looking at the va_glue file all it seems to do is initialize a VA-API display and pass it to the MXFVideoCORE
[01:02:26 CEST] <Rathann> ok
[01:03:39 CEST] <Rathann> JEEB: indeed, I can see that
[01:13:09 CEST] <analogical> how do I download a geo-blocked video from youtube?
[01:15:10 CEST] <Rathann> jkqxz: can you point me to some definitive upstream information that it requires the iHD driver?
[01:15:27 CEST] <Rathann> analogical: that is rather independent from ffmpeg ;)
[01:16:08 CEST] <Rathann> analogical: I'd suggest accessing the video via a proxy in a location that is not blocked
[01:16:17 CEST] <analogical> ok thanks
[01:17:04 CEST] <Rathann> I used to do that with Netflix US, but they started blocking whole US datacenters where people ran their own proxies
[01:17:14 CEST] <Rathann> so I stopped paying them ;)
[01:17:59 CEST] <Rathann> local Netflix catalogue is like 10% of the US one
[01:21:19 CEST] <jkqxz> Rathann:  <https://github.com/Intel-Media-SDK/MediaSDK>, "System requirements".
[01:22:05 CEST] <Rathann> jkqxz: got it, thanks a lot
[04:26:40 CET] <pzy> I have a streaming input file with 8 stereo audio channels, how can I amerge that into 16 mono PCM tracks?
[04:28:16 CET] <pzy> -filter_complex "join=inputs=8:channel_layout=8[aout]" ends up with a "hexadecagonal" layout that doesn't really work haha
[04:33:38 CET] <pzy> actually my bad, been using -filter_complex "[0:a]amerge=inputs=8[aout]"
[04:37:02 CET] <furq> pzy: -map_channel 0.0.0 out0.wav -map_channel 0.0.1 out1.wav -map_channel 1.0.0 out2.wav -map_channel 1.0.1 out3.wav ...
[04:37:20 CET] <pzy> I am outputting them to another stream
[04:38:44 CET] <pzy> right now it's something like: ffmpeg -i http://127.0.0.1/bigstream.ts -filter_complex "[0:a]amerge=inputs=8[aout]" -map 0:v -map "[a]" -c:v copy -c:a pcm_s16le -f mpegts -
[04:39:09 CET] <pzy> err except that'd be -map "[aout]"
[04:43:16 CET] <pzy> ffmpeg -i "http://127.0.0.1/bigstream.ts" -map_channel 0.0.0 [a1] -map_channel 0.0.1 [a2] -map_channel 1.0.0 [a3] -map_channel 1.0.1 [a4]
[04:43:20 CET] <pzy> is that the right idea?
[04:43:28 CET] <furq> you probably want amerge=inputs=8,channelsplit
[04:43:57 CET] <pzy> oh snap
[04:44:04 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#channelsplit
[04:44:58 CET] <pzy> hmmmm
[04:46:22 CET] <pzy> yeah that wasn't working for me, just gave me one LFE stream
[04:54:34 CET] <pzy> -filter_complex "[0:a]channelsplit,amerge=inputs=8[aout]"
[04:54:39 CET] <pzy> just splits the first audio stream's channels
[05:12:44 CET] <pzy> same thing if I put it after inputs=8
[05:19:49 CET] <tomf> when converting FLAC to ALAC, is there a way to preserve the artwork (I believe its at -map 0:1)?
[06:26:19 CET] <Foone> Hello! So I have a tool I'm building that wraps ffmpeg, and it needs to take a movie film and split it into lots of individual smaller files. so like seconds 1-5, 5-10, 10-15, etc.
[06:26:31 CET] <Foone> I've got working code that does this in the simple way: seek, only extract X seconds, save
[06:26:42 CET] <Foone> but the problem is that the accurate seeking gets slower and slower as you go farther in the film
[06:27:09 CET] <Foone> is there a way to do this in one pass (so one movie file into a bunch of sub-files) or should I focus on doing a hybrid keyframe + accurate seek?
[06:43:15 CET] <tomf> Foone: look into segment -segment_time -- you can do segment -segment_time 5 to get 5 second chunks, for instance
[06:43:35 CET] <tomf> for ten minutes, you could use ffmpeg -i S24E05.mkv -acodec copy -f segment -segment_time 600 -vcodec copy -reset_timestamps 1  OUTPUT%d.mp4
[06:57:23 CET] <Foone> ahh. I need mine at non-uniform times but it looks like I can specify a list with segment_times. Thanks!
[06:57:37 CET] <Foone> I'm rapidly going to run into command line length limits but this is a start
[16:29:06 CET] <illuminated> lol i just used ffmpeg to create an avi file with an x264 video stream and an ac3 audio stream.  I just thought it would be cool to put that in an avi cuz it supports it, and it's uncommon.
[17:39:27 CET] <furq> you have a strange definition of cool
[18:00:20 CET] <bencoh> :]
[18:34:44 CET] <mango_99> Hi -vcodec copy and -acodec copy while slicing MP4s output does not play quite right in most players such as Chromium video element. Clip length/timeline gets messed up and beginning doesn't play. Reencoding works fine. Is there anything else I can play with for this command to give better output or figure out what's going wrong with it?
[18:36:45 CET] <mango_99> https://pastebin.com/3BJWiDxW
[18:48:27 CET] <mango_99> I tried with latest git
[18:51:03 CET] <furq> mango_99: you can't do exact cuts with -c copy
[18:51:13 CET] <mango_99> exact cuts?
[18:51:19 CET] <furq> the cut section has to start on a keyframe, so it'll just seek to the nearest keyframe
[18:51:28 CET] <mango_99> oh
[18:51:34 CET] <mango_99> is there anything wrong with the command then?
[18:51:39 CET] <furq> no
[18:52:07 CET] <mango_99> when I try to play it it says it's a 20 second clip. and the progress bar is all messed up, it starts halfway through video
[18:52:46 CET] <furq> try moving -ss before -i
[18:53:23 CET] <mango_99> ah
[18:53:30 CET] <mango_99> different result, now it's a 30 second clip
[18:53:39 CET] <mango_99> better than before
[18:53:45 CET] <mango_99> are keyframes that far apart?
[18:53:53 CET] <furq> x264 defaults to 250 frames
[18:54:01 CET] <furq> so it's probably something around that
[18:54:15 CET] <mango_99> cool!
[18:54:23 CET] <mango_99> thanks but why does putting -ss before work?
[18:54:52 CET] <mango_99> and why does -ss after work as long as it's reencode
[18:55:17 CET] <furq> they're just two different seeking methods
[18:55:28 CET] <furq> same with -t/-to before/after -i
[18:56:32 CET] <furq> i forget exactly how it all works but the issue you were having was that it was cutting the audio at the point you requested but then cutting the video at the next keyframe
[18:56:43 CET] <furq> so the video was a few seconds delayed
[18:58:17 CET] <mango_99> awesome, really appreciate the quick response thank you
[19:00:35 CET] <mango_99> is there any way to tell it to round up/down when looking for nearest keyframe?
[19:02:18 CET] <mango_99> seems to round down, 3s starts at 0s keyframe 10s rounds up
[19:02:21 CET] <mango_99> looks like
[20:44:30 CET] <teratorn> is there any docs for getting NTP timestamps from RTSP stream (RTCP SR report NTP timestamp) and syncing that to RTP packets?
[21:43:58 CET] <TheSashmo> does anyone know if the 2110-20 has been added to any ffmpeg builds or any other open source solutions?
[22:41:13 CET] <asterismo_l> hi, i'm running a mastodon instance that uses ffmpeg to convert gifs to mp4. After a migration from Debian 8 to Debian 9 that conversion is not working anymore, and i get this error line in the log: ffmpeg: common/cpu.c:251: x264_cpu_detect: Assertion `!(cpu&(X264_CPU_SSSE3|X264_CPU_SSE4))' failed
[22:41:55 CET] <asterismo_l> do i have to manually compile ffmpeg? the server runs this CPU: http://paste.debian.net/1049440/
[22:44:55 CET] <durandal_1707> probably
[22:54:11 CET] <asterismo_l> is there any tutorial on how to compile ffmpeg in debian 9 stretch from source?
[22:54:36 CET] <asterismo_l> and overcome that issue?
[23:00:37 CET] <furq> asterismo_l: what are you running that on
[23:01:22 CET] <asterismo_l> running what?
[23:01:39 CET] <furq> ffmpeg
[23:01:44 CET] <furq> what system are you running it on
[23:02:27 CET] <furq> or to put it another way, are you launching qemu/kvm yourself or is it just a vps or cloud hosting or something
[23:03:20 CET] <asterismo_l> it is a VPS
[23:03:30 CET] <asterismo_l> debian 9 stretch
[23:03:54 CET] <asterismo_l> it is a vps cloud hosting
[23:04:11 CET] <furq> i guess you just need to rebuild and cross your fingers then
[23:04:31 CET] <furq> x264's cpu detection is (was?) broken sometimes in qemu if you don't pass the right -cpu flag
[23:04:53 CET] <furq> idk if they fixed it but they've definitely updated that code since the version in debian 9
[23:34:49 CET] <asterismo_l> http://paste.debian.net/1049446/
[23:40:33 CET] <asterismo_l> is there any tutorial oh compiling ffmpeg in debian 9?
[23:44:30 CET] <jkqxz> To build the ffmpeg utility just run "srcdir/configure" and the defaults are sensible.  Most people want to add "--enable-libx264 --enable-gpl", but generally the other options are only for particular use-cases.
[23:53:55 CET] <furq> asterismo_l: it's an x264 bug so you'll need to rebuild that and then build ffmpeg with it
[23:54:21 CET] <furq> but you can just use the prepackaged debian libs for anything else you want
[23:55:52 CET] <furq> https://www.johnvansickle.com/ffmpeg/
[23:55:55 CET] <furq> alternatively you can just use these
[00:00:00 CET] --- Mon Oct 29 2018