Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2016

1 participants
62 discussions

ffmpeg-devel.log.20161030
by burek 31 Oct '16

31 Oct '16

[02:45:45 CET] <atomnuker> why does FFSIGN return -1 when the input is 0? [03:09:00 CET] <Zeranoe> jkqxz: I've now testing your patches on three machines and no issues. Plus I haven't had a hang yet. I'd love to see this applied upstream [08:58:35 CET] <durandal_1707> is git server down for everybody? [13:48:50 CET] <jkqxz> Zeranoe: RiCON: Thank you for your testing efforts! [13:49:11 CET] <jkqxz> So, is there any outstanding reason not to apply the series? [14:04:17 CET] <RiCON> jkqxz: no issues from me, but i'm not a heavy user of qsv [14:09:53 CET] <BtbN> how do I edit wiki pages? [14:11:14 CET] <jkqxz> Be logged in and press "edit this page"? [14:11:24 CET] <BtbN> I am logged in, can't edit the HWAccelIntro page [14:12:33 CET] <jkqxz> Works for me. What is going wrong? [14:12:46 CET] <BtbN> well, there simply is no such button. [14:13:06 CET] <BtbN> they are present on other pages though [14:13:49 CET] <BtbN> uBlock is getting rid of them oO [14:15:09 CET] <jkqxz> Weird. It's just a normal submit button with some styling. [14:16:32 CET] <cone-883> ffmpeg 03Michael Niedermayer 07master:042faa847fee: avcodec/8bps: Check side data size before use [14:16:33 CET] <cone-883> ffmpeg 03Michael Niedermayer 07master:121be3106078: avcodec/cinepak: Check side data size before use [14:20:56 CET] <BtbN> god damn there are more nvenc_h264 [14:20:58 CET] <cone-883> ffmpeg 03Mark Thompson 07master:e8634fb92e2f: openssl: Allow newer TLS versions than TLSv1 [14:24:19 CET] <jkqxz> BtbN: Better not try googling it... [14:24:39 CET] <BtbN> Well, it was the official name for quite a while [14:24:47 CET] <BtbN> And was only somewhat recently deprecated [14:26:07 CET] <DHE> so the syntax is $CODECNAME_$METHOD for consistency then? [14:26:38 CET] <BtbN> yes [14:29:17 CET] <jkqxz> Like h264_libx264. [14:32:16 CET] <sopparus> jkqxz, noticed the merge. Thanks for helping out. here is another ticket I noticed which you can close https://trac.ffmpeg.org/ticket/5905 [14:32:37 CET] <BtbN> libx264 doesn't offer multiple codecs though [14:32:45 CET] <BtbN> originally nvenc was called just nvenc, when it just supported h264 [14:36:50 CET] <jkqxz> sopparus: Yep; thank you! [14:40:34 CET] <JEEB> 9 [15:39:35 CET] <cone-883> ffmpeg 03Michael Niedermayer 07master:a2b8dde65947: avcodec/idcinvideo: Check side data size before use [15:39:36 CET] <cone-883> ffmpeg 03Michael Niedermayer 07master:2d99101d0964: avcodec/kmvc: Check side data size before use [15:47:08 CET] <atomnuker> YCOCG SUPPORT FOR VF_COLORSPACE! [15:47:30 CET] <atomnuker> does that mean the future is here? [15:47:39 CET] <JEEB> no, the future is in dolby's thing 8) [15:48:30 CET] <JEEB> ICt whatever it was [16:59:39 CET] <jkqxz> jamrial_: nevcairiel: I shall apply the qsv merge series. Ok? [16:59:48 CET] <jkqxz> (These six patches <http://ixia.jkqxz.net/~mrt/ffmpeg/qsv-merge/>, which includes one from Zeranoe to fix a Haswell failure.) [18:36:19 CET] <nevcairiel> jkqxz: i'll give it a final read later tonight or early tomorrow [18:38:53 CET] <Chloe> yay qsv merge is near :D [18:59:10 CET] <jkqxz> nevcairiel: Ok; thank you. [19:31:44 CET] <DHE> Going through the filter code, it looks like lavfi only supports threading on a per-filter basis. For example if I have a pipeline of 3 filters it's not possible to have each one execute a different frame in a separate thread. Does that sound right? Something that would be beneficial? [19:34:33 CET] <nevcairiel> that sounds right, but it would probably be quite complicated to sync everywhere [19:35:01 CET] <DHE> yeah, was thinking about that. there becomes a need for a blocking vs nonblocking buffersink operation and so on... [19:35:19 CET] <nevcairiel> i bet someone already had the idea :) [19:35:26 CET] <nevcairiel> the slice threading on a filter level was trivial in comparison [19:35:33 CET] <nevcairiel> so it was a low hanging fruit [19:36:47 CET] <DHE> I'm running '[0:v] split=4 [out1][out2][out3][out4]; ...' where each one then gets further processing. so threading there seems to make a lot of sense. but it still doesn't really answer what to do next... [19:37:25 CET] <DHE> I have a patch in the mailing list to allow users to limit the thread pool size. My machine has 80 CPUs and I don't think slice processing at that level is beneficial [19:53:07 CET] <philipl> BtbN: slow mailing list: https://github.com/philipl/FFmpeg/commit/76329c947ff535cccca0b4dce6ecc54307… [19:53:52 CET] <BtbN> I don't think it should be removed. [19:54:06 CET] <BtbN> First of all, it's essentialy a breaking change. [19:54:27 CET] <BtbN> And doesn't it just fail straight away anyway? [22:39:44 CET] <cone-078> ffmpeg 03Andreas Cadhalpun 07master:14e4e2655969: interplayacm: check for too large b [22:39:45 CET] <cone-078> ffmpeg 03Andreas Cadhalpun 07master:5540d6c1343e: interplayacm: validate number of channels [23:21:21 CET] <philipl> BtbN: it fails, but at least mpv doesn't fall back. It just grinds to a halt. [23:21:50 CET] <philipl> I'm not sure how it's really a breaking change if it never worked. [23:25:01 CET] <BtbN> does it automatically select it? If it's explicitly requested, sure, a hard fails seems about expected. [23:29:09 CET] <philipl> It will auto-select in mpv based on the logic in mpv. If it wasn't there, it would just use the regular decoder. [23:31:15 CET] <BtbN> Shouldn't that be fixed in some other way then? VP9 will have the same problem, if the user doesn't use a Pascal-Card. [23:38:40 CET] <philipl> BtbN: The hardware doesn't support it and has never supported it. I made a mistake. [23:39:02 CET] <philipl> I told it to use the mpeg4-asp decoder for h.263 [23:39:26 CET] <philipl> It doesn't fail at decoder creation because the decoder is valid. [23:40:25 CET] <BtbN> Oh, so there simply is no h263 decoder in cuvid. [23:40:30 CET] <iive> you know that mpeg4-asp and h263 are quite different? [23:40:32 CET] <philipl> right. [23:40:47 CET] <philipl> Yes, I do. late in the game, but yes. [23:41:38 CET] <BtbN> Yes, then it should be removed again, of course. [23:42:14 CET] <iive> if i remember correctly, mpeg4-asp could decode h263, there was something about short headers. [23:43:33 CET] <philipl> Well, it's possible that this is a limitation in the cuvid parser rather than decoder, but either way it doesn't work. [23:44:30 CET] <philipl> vdpau can do wmv3, which really should mean cuvid can too but the parser can't handle it, even if the decoder could. [23:45:15 CET] <philipl> BtbN: anyway, I' [23:45:17 CET] <philipl> ll push that [23:52:47 CET] <cone-078> ffmpeg 03Philip Langdale 07master:21b68cdbae65: avcodec/cuvid: Don't claim to decode h.263 (it doesn't) [00:00:00 CET] --- Mon Oct 31 2016

1 0

ffmpeg.log.20161030
by burek 31 Oct '16

31 Oct '16

[00:44:04 CEST] <Filarius> so it seems issue was in short set of test data and my software closing stream before pushing all data to pipe. I think, with coder h264 it just not send "bad" data after last keyframe. [01:12:53 CEST] <fgfhdwfh> hello [01:13:19 CEST] <fgfhdwfh> when i execute : ffmpeg -i rtmp://184.72.239.149/vod -c copy dump.flv [01:13:30 CEST] <fgfhdwfh> i got always a connection refused error [01:13:45 CEST] <fgfhdwfh> can you help cause i cant found any thing on doc [01:14:36 CEST] <fgfhdwfh> it's an open rtmp im testing [01:19:04 CEST] <BtbN> well, the rtmp server refuses the connection [01:21:01 CEST] <fgfhdwfh> thank you for your reply [01:22:56 CEST] <BtbN> Well, it's not something ffmpeg can do much about, so not sure what you'd expect. [01:23:09 CEST] <BtbN> Just make sure you are using the right IP and port. [01:24:25 CEST] <fgfhdwfh> ok i understand [01:24:35 CEST] <BtbN> also, rtmp is usually a two part url [01:24:41 CEST] <BtbN> so it should be /vod/something [01:24:45 CEST] <BtbN> and not just /vod [01:25:20 CEST] <fgfhdwfh> can i use http stream url ? [01:25:26 CEST] <fgfhdwfh> ffmpeg -i http://218tv.ddns.net/ -c copy dump.flv [01:25:38 CEST] <BtbN> sure, if the server serves something ffmpeg understands [01:25:50 CEST] <BtbN> if it's a website with some (flash) player on it, no [01:27:26 CEST] <fgfhdwfh> i understand that i have to ask simply for rtmp url for the live stream so i can use it with ffmpeg [01:28:02 CEST] <BtbN> if the website plays it with some flash player, you should be able to extract it. If not from the source of the site, wireshark will find it. [01:44:19 CEST] <fgfhdwfh> thank you :) [01:46:07 CEST] <fgfhdwfh> i tracked rtmp link but on my server i have again connection refused error. So ill juste ask the stream administrator to give permission to my server ip [01:46:15 CEST] <fgfhdwfh> thank s again [02:46:55 CET] <Keridos> how can i convert an RGB input video into yuv444p output? [02:47:18 CET] <Keridos> currently I got wrong colors in output (looks like it interprets the input as BGR??) [02:52:08 CET] <furq> paste your command line and output [03:00:46 CET] <Keridos> furq: currently cannot, using custom ffmpeg output with obs, cannot get the full command line it launches [03:01:18 CET] <Keridos> just trying to find out how I can select a specific pixel format to interpret the input? [03:02:09 CET] <Keridos> so I do not want to specify pix_fmt for the output, but tell ffmpeg to interpret the input as a specific pixel format, even if it autodetects another one [03:02:21 CET] <furq> specify -pix_fmt before -i [05:24:32 CET] <kanzure> pp/win 79 [06:02:04 CET] <Ekho> probably just being blind but I cant find what flags are needed during configure to compile with alsa support, can somebody point me in the right direction? all i can find is that I need libasound [06:14:38 CET] <furq> Ekho: it's enabled by default [06:15:21 CET] <furq> if you don't have asoundlib.h or libasound then it'll be automatically disabled [06:23:23 CET] <Ekho> I have both asoundlib.h and libasound [06:40:44 CET] <Ekho> ignore me I'm an idiot an had a typo character in my alsa-lib prefix so ffmpeg couldnt find them [12:41:08 CET] <Filarius> funny, FFMpeg not writing all frames from StdIn if StdOut and StdError not closed... [12:49:02 CET] <crst> I'm not being able to figure it out properly when searching google or reading docs. What is the practical best solution with latest ffmpeg to convert a mp3 of a voice recording as small as bearable and applying highest quality conversion for the small filesize? [12:58:28 CET] <StephenS> is there an issue with opus git? It seems I cant clone it with: git clone http://git.opus-codec.org/opus.git [13:00:51 CET] <StephenS> hmm seems to work now, just takes a lot of time heh [15:30:52 CET] <TAFB2> Thank you FFMPEG :) Live streaming of the event yesturday went FLAWLESS! Thank you apple for HLS streaming too. Time lapse Zombie video: http://www.skyviewelectronics.com/zombie-walk-brooklin [15:30:59 CET] <kerio> \o/ [15:50:39 CET] <SchrodingersScat> nice [16:32:48 CET] <paule32> hello, how can i stream X server screen from 800x600 to 640x480 video only compressed? to nginx server port rtmp 1935 ? [16:44:37 CET] <paule32> ffmpeg -f x11grab -maxrate 128k -video_size 800x600 -g 60 -bufsize 1024k -f mp4 rtmp://192.168.178.80:1935/live [16:44:50 CET] <paule32> Output #0, flv, to 'rtmp://192.168.178.80:1935/live': [16:44:50 CET] <paule32> Output file #0 does not contain any stream [16:50:40 CET] <jkqxz> You need to tell it where to get the input from. It's probably X display :0, so add "-i :0" after "-f x11grab". [16:51:24 CET] <BtbN> you also won't have much fun with a 128kbps video stream. [16:52:37 CET] <jkqxz> It would take a while to converge, but for a mostly-static PC stream it might only be an incomplete disaster. [16:54:46 CET] <kerio> i have some 1.8mbps songs [17:14:52 CET] <paule32> jkqxz: what do you can point 1024k ? [17:15:22 CET] <paule32> is ffserver needed? [17:16:02 CET] <furq> no [17:16:22 CET] <paule32> how then rtmp to nginx? [17:17:21 CET] <furq> ffmpeg -f lavfi -i testsrc -c:v libx264 -f flv rtmp://192.168.178.80:1935/live [17:17:32 CET] <furq> if that works then your problem is probably the thing jkqxz said [17:18:47 CET] <paule32> unknown encode libx264 [17:19:21 CET] <furq> well that's a great start [17:19:54 CET] <furq> you probably want to start by getting an ffmpeg binary that has an h264 encoder [17:21:22 CET] <paule32> D.V.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [17:21:22 CET] <paule32> jens@kallup:/media/sdb1/e-learning/mov$ ffmpeg -codecs | grep h264 [17:22:10 CET] <furq> so you probably want to start by getting an ffmpeg binary that has an h264 encoder [17:26:34 CET] <paule32> Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 1532 kb/s, 29.97 fps, 29.97 tbr, 30k tbn, 59.94 tbc (default) [17:38:43 CET] <paule32> runs [17:59:27 CET] <paule32> ./tests/../ffserver -f ffserver.conf [17:59:36 CET] <paule32> cancel running [18:02:13 CET] <paule32> https://paste.fedoraproject.org/465342/14778468/ [18:11:03 CET] <paule32> ok, ffmpeg works, for creating mp4 file [18:11:16 CET] <paule32> input is screen, output is file [18:11:28 CET] <paule32> so, how can i send to nginx? [18:11:42 CET] <paule32> or ffserver? [18:12:38 CET] <JEEB> never use ffserver unless you're ready to maintain or rewrite it [18:13:07 CET] <JEEB> if you want to stream, utilize a proper streaming server. icecast and a few others come to mind [18:13:40 CET] <paule32> i am under Linux [18:13:47 CET] <paule32> testing only, at the moment [18:14:26 CET] <paule32> i am c a programmer, so rewriting should not so hard ... [18:14:39 CET] <Mavrik> why on earth. [18:14:40 CET] <paule32> but i shall learn the basics .. [18:14:49 CET] <Mavrik> when you can use nginx-rtmp plugin. [18:15:04 CET] <JEEB> btw, did that thing support multiple profiles in any sane way? [18:15:13 CET] <JEEB> since flv IIRC is limited to a single thing or so? [18:15:39 CET] <Mavrik> nginx-rtmp? [18:15:39 CET] <bencoh> what is "that thing"? [18:15:45 CET] <Mavrik> or ffserver? :) [18:16:02 CET] <paule32> hold on guys [18:16:18 CET] <paule32> i test and then, i try to customize [18:16:21 CET] <bencoh> nginx-rtmp can stream out to hls, so ... yes, somehow [18:16:24 CET] <Mavrik> JEEB, nginx-rtmp supports HLS and DASH streaming which should be used instead of RTMP :P (yeah, dumb name I know :P ) [18:16:36 CET] <JEEB> yes, but the *input* is FLV in RTMP [18:16:47 CET] <JEEB> thus I'm not sure how you're supposed to input multiple video tracks to it [18:16:59 CET] <bencoh> JEEB: sure, but the point is you stream only one (highest) profile to it [18:17:01 CET] <paule32> ffmpeg -f x11grab -i :0.0+100,200 -framerate 7 -f mp4 /media/sdb1/e-learning/mov/feed1.mp4 [18:17:11 CET] <paule32> this create a mp4 file [18:17:17 CET] <Mavrik> JEEB, ahh, it's rather basic [18:17:23 CET] <Mavrik> it doesn't do switching IIRC [18:17:31 CET] <furq> JEEB: https://github.com/arut/nginx-rtmp-module/wiki/Directives#hls_variant [18:17:39 CET] <paule32> but i have to cut it (max size) to not override my hd [18:17:56 CET] <JEEB> furq: ahh [18:17:59 CET] <JEEB> that makes sense [18:18:16 CET] <bencoh> actually this hls_variant thing is far from being perfect, since GOP won't be aligned [18:18:40 CET] <JEEB> aligning GOPs isn't that hard anyways :P [18:18:43 CET] <bencoh> (unless you explicitely turn off scene cut) [18:18:54 CET] <paule32> guys, i am here :-) [18:19:14 CET] <furq> i'd expect to have to use fixed-size gops for adaptive streaming anyway [18:19:16 CET] <bencoh> JEEB: when using separate encoders it's not "hard" but it's kindof a waste ... but anyway :) [18:19:32 CET] <JEEB> furq: I don't but a lot of shit seems to expect it [18:19:48 CET] <JEEB> I was way too happy back with just HLS, where apple and others were all m'kay about it [18:19:52 CET] <bencoh> furq: you can do without it but you'll need synced encoders, somehow [18:19:54 CET] <JEEB> then I entered the lairs of the dragons [18:20:04 CET] <JEEB> and fuck those pieces of shit [18:20:27 CET] <JEEB> (excuse me for the language but that's what I got after interacting with certain vendors) [18:20:28 CET] <paule32> JEEB: i want to go the ffserver way [18:20:32 CET] <furq> streaming is fun [18:20:37 CET] <furq> please don't use ffserver [18:20:53 CET] <JEEB> paule32: which is pretty much "rewrite your own streaming server" [18:21:01 CET] <paule32> no [18:21:03 CET] <JEEB> because ffserver is dead and will not be alive [18:21:08 CET] <paule32> oh [18:21:08 CET] <furq> hopefully after 3.2 comes out i will never have to explain that again [18:21:18 CET] <furq> a beautiful dream~ [18:21:31 CET] <JEEB> a shot in the head and thrown into the back alley [18:21:37 CET] <paule32> so let me try the nginx way? [18:22:15 CET] <JEEB> paule32: just for your information - ffserver sounds probably good as a title but the thing would never work like you'd expect and you had to know its internals to do *anything*. also it required hacks all around because it liked to poke internals of the libraries instead of just utilizing them properly [18:22:25 CET] <furq> paule32: do you have libx264 yet [18:22:48 CET] <Mavrik> Is there anything cheaper than Wowza if you want to have a decent streaming server? [18:22:49 CET] <paule32> yes [18:22:59 CET] <paule32> ffmpeg is compiled and running [18:23:07 CET] <Mavrik> (set-it-and-forget-it variety with transcode and HLS/DASH/Smooth)? [18:23:11 CET] <furq> what's the problem then [18:23:24 CET] <JEEB> I am not sure if I would put transcode together with a media serving thing [18:23:29 CET] <paule32> i cant stream to my nginx server [18:23:36 CET] <JEEB> my preference is usually to separate the two [18:23:36 CET] <paule32> i get error [18:23:56 CET] <Mavrik> JEEB, yeah, mine too, but I get a lot of queries for smaller setups [18:24:12 CET] <Mavrik> Where people aren't really experts, have < 500 streams active and don't want too much hassle. [18:24:21 CET] <Mavrik> I usually recommended Wowza which works well enough for those cases. [18:24:25 CET] <JEEB> Mavrik: well nothing stops you from putting the two onto the same machine if you really want [18:24:55 CET] <JEEB> but yeah, I should start looking at solutions again [18:25:35 CET] <paule32> https://paste.fedoraproject.org/465427/77848319/ [18:25:37 CET] <paule32> look [18:26:12 CET] <BtbN> that's not a valid rtmp url. [18:26:23 CET] <BtbN> the name is missing [18:26:26 CET] <furq> that's also not the same x11grab invocation you just pasted [18:26:42 CET] <paule32> that differs, yes [18:26:50 CET] <paule32> that is, what i try, with nginx [18:29:19 CET] <paule32> https://paste.fedoraproject.org/465440/47784854/ [18:29:26 CET] <paule32> now, i get this [18:29:34 CET] <furq> -f flv [18:29:44 CET] <paule32> flash [18:29:45 CET] <paule32> ? [18:29:49 CET] <paule32> is dead [18:29:50 CET] <furq> rtmp uses flv [18:30:03 CET] <furq> also that's encoding to mpeg4, which is not x264 [18:30:34 CET] <paule32> can you give me correct cmd line? [18:30:36 CET] <paule32> thx [18:31:15 CET] <furq> replace -f mp4 with -f flv [18:31:28 CET] <furq> if you don't have x264 then it's going to encode to some garbage codec [18:31:38 CET] <paule32> ah ok [18:31:53 CET] <paule32> but the client players see mp4 ? [18:33:02 CET] <Mavrik> They shouldn't for live stream. [18:33:10 CET] <Mavrik> At least not for HLS. [18:33:43 CET] <paule32> https://paste.fedoraproject.org/465455/48792147/ [18:51:32 CET] <kerio> can't really livestream mp4 [18:52:17 CET] <JEEB> *objection* [18:52:33 CET] Action: JEEB inserts loads of text about segmented ISOBMFF [18:53:24 CET] <BtbN> in theory you don't even need to segment it. Just generate the moov atom early, and put it in the beginning. like DASH does [18:53:43 CET] <JEEB> DASH is just fragmented ISOBMFF [18:53:59 CET] <BtbN> it has one special element, which contains the header/moov atom. [18:54:00 CET] <JEEB> except you can have separate initialization segments with the parameter sets etc [18:54:11 CET] <BtbN> and if you cat header seg1 seg2 ... you get a valid file [18:54:14 CET] <JEEB> you could as well have them in the beginning of each normal segment [18:54:14 CET] <BtbN> so you can stream that [18:54:21 CET] <Mavrik> JEEB, can we agree on "streaming MP4 is a sin and DASH an abomination" ? :P [18:54:40 CET] <JEEB> no? it's less bad than HLS because MPEG-TS eats bandwidth? [18:54:41 CET] <kerio> long live hls [18:55:16 CET] <JEEB> and I still think fragmented ISOBMFF is the least bad ingest format for HTTP streaming remuxing [18:55:17 CET] <BtbN> that 1 or 2 % of overhead doesn't matter too much [18:55:52 CET] <paule32> hey BtbN nice to see you [18:56:14 CET] <kerio> how did we end up with https/ip [18:56:15 CET] <paule32> did you code in pascal, anymore? [18:56:28 CET] <JEEB> kerio: people wanted to use their HTTP infra [18:56:35 CET] <JEEB> like load balancers and caching [18:56:40 CET] <JEEB> so, uh, here we area [18:56:57 CET] <paule32> JEEB: is that output normal? [18:56:59 CET] <paule32> https://paste.fedoraproject.org/465455/48792147/ [19:01:17 CET] <paule32> the argument -b 128k does nothing [19:01:39 CET] <paule32> what is -crf 20 ? [19:04:15 CET] <paule32> and -vcodec libx264 [19:04:31 CET] <paule32> give me unknown codec 'libx264' [19:05:05 CET] <JEEB> then you built without x264 [19:05:06 CET] <JEEB> simple as that [19:10:12 CET] <paule32> when i remove the option, i get, muxer is not streamable [19:11:38 CET] <paule32> what means "past duration to large" ? [19:12:56 CET] <paule32> will this debug output store in log file? [19:13:24 CET] <paule32> haleyulja, then happy streaming [19:14:05 CET] <TheXzoron> how would I record from multiple audio input devices in ffmpeg [19:16:05 CET] <TheXzoron> ffmpeg -f alsa -ac 1 -ar 44100 -i webcamrate -f alsa -ac 2 -ar 48000 -i looprecvol /tmp/test.wav [19:16:21 CET] <TheXzoron> is what I'm trying but it does not get the webcam mic [19:16:34 CET] <TheXzoron> but it does individually [19:20:53 CET] <Filarius> -i input1 -i input2 -map 0 -map 1 output [19:21:47 CET] <Filarius> if you input is have several tracks, like video and audio, then -i input1 -i input2 -map 0:a -map 1:a output [19:22:52 CET] <Filarius> also works -map 0:0 -map 0:1 here u just how track number, audio must be 1 and more [19:23:00 CET] <Filarius> *show [19:24:46 CET] <TheXzoron> ffmpeg -i alsa -i alsa -map webcamrate -map looprecvol /tmp/test.wav this didn't work so [19:30:00 CET] <TheXzoron> ok I got it it was ffmpeg -f alsa -ac 1 -ar 48000 -i webcamrate -f alsa -ac 2 -ar 44100 -i looprecvol -map 0 -map 1 [19:34:51 CET] <TheXzoron> but [19:34:57 CET] <TheXzoron> no it wasn't [19:43:14 CET] <TheXzoron> it doesn't play properly [19:45:41 CET] <TheXzoron> oh I see [19:45:50 CET] <TheXzoron> one source is 1 channel and the other has 2 channels [19:46:02 CET] <TheXzoron> and it keeps trying to switch between channels for some reason [19:46:06 CET] <TheXzoron> why [19:46:23 CET] <Filarius> ffmpeg -f alsa -ac 1 -ar 48000 -i webcamrate -f alsa -ac 2 -ar 44100 -i looprecvol -map 0 -map 1 out.mkv [19:47:35 CET] <Filarius> and I do not see how you can put 2 audiostreams in one wav file [19:47:58 CET] <TheXzoron> I didn't know wave was mono only [19:48:29 CET] <Filarius> mono/stereo is audio track parameters [19:49:25 CET] <Filarius> and i'm not sure what FFMpeg will do if you try to mux 2 tracks to WAV without make it know what it is left and right channels [19:49:54 CET] <paule32> so, i have pipe the output 2> /dev/null [19:50:04 CET] <paule32> how can i see, if something wrong? [19:52:06 CET] <paule32> ah ok [19:52:06 CET] <TheXzoron> ok when I [19:52:17 CET] <paule32> i see [19:52:25 CET] <TheXzoron> Filarius: the audio of looprecvol is not present [19:52:49 CET] <paule32> have you /dev/video0 ? [19:53:28 CET] <TheXzoron> I'm using the webcam as a mic not a video source paule32 [19:53:41 CET] <Filarius> to make stereo from 2 mono -filter_complex "[0:a][1:a]amerge=inputs=2[aout]" -map "[aout]" output.wav [19:54:03 CET] <paule32> webcam are video sources (my has a mic in it [19:55:02 CET] <Filarius> okay, give me two examples of just recording audio from each source, separatly [19:55:26 CET] <paule32> have you try vlc before? it is easy to stream, play... it is universal knife, and you can select the source per mouse [19:56:03 CET] <paule32> -i input1 -i input2 -map out1 -map out2 [19:56:57 CET] <paule32> okay, i misunderstood [19:57:01 CET] <paule32> mic not video [19:57:03 CET] <paule32> sorry [19:57:34 CET] <Filarius> TheXzoron, first make examples how to record from each source one by one [19:58:50 CET] <TheXzoron> ffmpeg -f alsa -ac 1 -ar 44100 -i webcamrate out.ogg [19:59:20 CET] <TheXzoron> ffmpeg -f alsa -ac 2 -ar 48000 -i looprecvol out.ogg [20:00:35 CET] <paule32> ah [20:00:39 CET] <paule32> also [20:00:42 CET] <paule32> alsa [20:00:47 CET] <paule32> very old [20:01:05 CET] <paule32> pulseaudio is the replacement [20:01:43 CET] <paule32> on older linux boxes, pulse are on top of alsa, but please try to use pulseaudio [20:01:57 CET] <paule32> but don't say, i have say it to you :-) [20:02:34 CET] <TheXzoron> I have but it's very unstable [20:02:44 CET] <paule32> yes, old linux box [20:02:55 CET] <paule32> i use linux mint, and debian gnome [20:02:59 CET] <TheXzoron> no I was using pulseaudio 9 [20:03:08 CET] <TheXzoron> crashed randomly [20:03:11 CET] <paule32> gnome was a little instable, but mint is perfect [20:03:33 CET] <paule32> then is something wrong i ibus? [20:03:57 CET] <TheXzoron> I have alsa working the way I want without it and recording works in obs from both sources [20:04:06 CET] <paule32> yu can reset audio per "alsainit" [20:04:12 CET] <TheXzoron> I'm just trying to make a recording script [20:04:56 CET] <paule32> you can install "arecord/(a)play" - sorry, have very long not worked with also anymore [20:04:59 CET] <Filarius> ffmpeg -f alsa -ac 1 -ar 44100 -i webcamrate -f alsa -ac 2 -ar 48000 -i looprecvol out.mka - is it working ? [20:05:04 CET] <Filarius> i [20:05:31 CET] <Filarius> i'm not sure about how to handle more then one custom inputs [20:05:46 CET] <paule32> you can have many [20:05:53 CET] <paule32> 2^32-1 [20:05:56 CET] <paule32> :-) [20:06:01 CET] <Filarius> not about "can" but about "how" [20:06:08 CET] <TheXzoron> meta-l /window bare [20:06:14 CET] <TheXzoron> whoops [20:06:20 CET] <Filarius> is it needs "-f" every time or not [20:06:21 CET] <paule32> input1 = -i source1 [20:06:30 CET] <paule32> input2 = -i source2 [20:06:33 CET] <paule32> .. [20:06:45 CET] <paule32> -f is format [20:07:11 CET] <Filarius> i know, its not an answer ) [20:07:23 CET] <paule32> $ ../ffmpeg/ffmpeg -f x11grab -i :0.0+100,200 -framerate 5 -f flv rtmp://192.168.178.80:8585/live 2> /dev/null [20:07:29 CET] <TheXzoron> Filarius: yes that does not get the webcam and onlt gets the desktop [20:08:40 CET] <TheXzoron> I don't know why it doesn't error or something [20:08:43 CET] <paule32> you have to give over the /dev/devicenode [20:08:50 CET] <TheXzoron> because it completely ignores the first source [20:09:44 CET] <paule32> ok, so far [20:10:01 CET] <paule32> how can i scale the video output? [20:10:34 CET] <paule32> but before, why this error(s): https://paste.fedoraproject.org/465596/85394114/ [20:17:36 CET] <paule32> ah [20:17:48 CET] <paule32> where can i download asf codec driver? [20:20:48 CET] <bencoh> ? [20:26:24 CET] <Trump_2016> How do you reduce the key frame interval with mpeg2video? [20:26:46 CET] <Trump_2016> paule32, -s XxY sets the video size in the target [20:26:56 CET] <paule32> thx [20:27:00 CET] <paule32> i need a codec [20:27:04 CET] <paule32> for vlc [20:28:38 CET] <paule32> http://www.free-codecs.com/download/voxware_metasound_audio_codec.htm [20:29:03 CET] <paule32> here i can find only window stuff [21:22:58 CET] <pipo1> where can i find ffmpeglauncher ? [21:24:51 CET] <pipo1> commented here https://www18.atwiki.jp/live2ch/pages/419.html [21:26:19 CET] <BtbN> on some japanese page I'd guess. [21:27:24 CET] <pipo1> yes but where exactly [21:28:34 CET] <JEEB> you could have used google translated [21:28:36 CET] <JEEB> *translate [21:28:39 CET] <JEEB> https://www18.atwiki.jp/live2ch/pages/419.html#id_ef55d105 [21:29:29 CET] <JEEB> it then links to a nico community which contains the download links :P [21:30:11 CET] <JEEB> do note that this piece of software has nothing to do with FFmpeg or the ffmpeg command line tool, it's a thing someone completely unrelated made [21:31:07 CET] <pipo1> ok [21:41:47 CET] <pipo1> why ffmpeg dont stream to older versions of icecast ? [21:54:48 CET] <steve__> Hi, I just purchased a Garmin DashCam that encodes GPS inside the MP4 files it outputs. I believe its being stored using SEI messages. Does anyone know if/how I can use FFMPEG to export that data? [22:03:27 CET] <paule32> i can't find codec asf for vlc linux [22:03:54 CET] <paule32> i run into error on vlc client side: undf not supported [23:50:59 CET] <deweydb> fhey guys [23:51:02 CET] <deweydb> -f [23:57:09 CET] <deweydb> i've got a file that is in MTS format. usually my scripts use ffprobe -of json -show_streams ... to pull out metadata information, most importantly the number of frames in the video. i get this from a value in the video stream with the key 'nb_frames' but this MTS file doesn't have that populated. Is there some other way of getting the precise number of frames, maybe from sort of magical multiplication of ts and something [23:57:09 CET] <deweydb> else? this is the stream in questions metadata: http://pastebin.com/BRPDDEZi [23:57:57 CET] <deweydb> another stream (any non MTS file i have encountered looks like this, i.e. it has nb_frames): http://pastebin.com/ZrBhbygJ [23:58:25 CET] <c_14> Does your command have -count_frames ? [00:00:00 CET] --- Mon Oct 31 2016

1 0

ffmpeg-devel.log.20161029
by burek 30 Oct '16

30 Oct '16

[00:56:48 CEST] <cone-812> ffmpeg 03Andreas Cadhalpun 07master:97792e85c338: fate: add apng encoding/muxing test [00:56:48 CEST] <cone-812> ffmpeg 03Andreas Cadhalpun 07master:890eb3d7c477: configure: make sure LTO does not optimize out the test functions [01:07:04 CEST] <Compn> jamrial : working together is the important part. a project will die if no one can work together... [04:57:58 CEST] <cone-472> ffmpeg 03Philip Langdale 07master:7c27da686c06: crystalhd: Reorder mspeg4 decoder after software decoders [05:05:12 CEST] <philipl> michaelni: I've pushed the decoder ordering fix. Would be most appreciative if you could repeat your testing with the crystalhd patches. [10:12:27 CEST] <michaelni> philipl, seems to pass fate fine now [10:19:46 CEST] <rcombs> michaelni: re: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201868.html did you apply the previous patches in the series? [10:20:14 CEST] <sopparus> is that henrik guy from ML here? [10:20:35 CEST] <rcombs> sopparus: nevcairiel? [10:21:24 CEST] <sopparus> hendrik leppkes [10:22:01 CEST] <rcombs> yeah that's your guy [10:22:36 CEST] <sopparus> ok thanks, ping @nevcairiel :) [10:22:44 CEST] <michaelni> rcombs, i thougt i did but ill retry [10:23:01 CEST] <rcombs> michaelni: that looks like the issue I'd expect you to get if the first patch in the series was missing [10:23:09 CEST] <rcombs> and I don't get that locally [10:23:24 CEST] <rcombs> but it could be something else broken, ¯\_(Ä)_/¯ [10:26:24 CEST] <nevcairiel> sopparus: whats up? [10:27:31 CEST] <sopparus> nevcairiel, Hi. I noticed you reviewd that openssl tls 1.2 patch, I cant respond to the ml, but here is a copy paste from that guide that made it [10:27:34 CEST] <sopparus> I think this patch from ffmpeg is not good. It works for you but all other users using TLS v1.0 will stay on dry with it because TLS v1.0 is not supported anymore. The problematic line is SSL_CTX_set_options which disables v1.0. Without this line both versions are supported but higher version has precedence (I think). You can write something on ffmpeg ml. [10:28:20 CEST] <nevcairiel> without that line it also allows sslv2/3, which we do not want [10:29:34 CEST] <jkqxz> After that line, the SSL context should have SSLv2 and SSLv3 disabled; TLSv1, TLSv1.1 and TLSv1.2 enabled. [10:30:04 CEST] <nevcairiel> all the docs I could find suggest that using the SSLv23_method and blacklisting v2 and v3 afterwards should allow TLS 1.0, 1.1 and 1.2 [10:31:25 CEST] <jkqxz> The method name is really quite unhelpful, but hysterical raisins and all that. [10:31:40 CEST] <rcombs> on newer OpenSSL versions you can use TLS_client_method [10:32:08 CEST] <sopparus> my build with jkqxz slightly modified tls 1.2 patch just finished and it does work with tls 1.0 [10:33:03 CEST] <nevcairiel> so nothing to worry about then [10:33:25 CEST] <jkqxz> rcombs: On 1.1, huh. I didn't know about that. Maybe in a few years... [10:33:35 CEST] <rcombs> curl does an #if around it [10:33:48 CEST] <nevcairiel> the current thing works, even if its unintuitive [10:34:14 CEST] <sopparus> yeah with that patch 1.0, 1.1 and 1.2 works [10:34:22 CEST] <sopparus> tested all three. without it only 1.0 works [10:34:31 CEST] <sopparus> thanks guys [10:35:01 CEST] <rcombs> yeah [10:36:47 CEST] <rcombs> "Version 1.0.2 will be supported until 2019-12-31 (LTS)." [10:36:47 CEST] <rcombs> fun [10:37:34 CEST] <jkqxz> I'll add a comment to the patch explaining what it's doing. [10:50:54 CEST] <michaelni> rcombs, http://pastebin.com/Fi38mBNF [10:51:44 CEST] <rcombs> &wacky [10:51:58 CEST] <rcombs> just the one packet, and consistent about it [10:52:44 CEST] <michaelni> probably some off by 1 error [10:53:00 CEST] <michaelni> rounding or so maybe ? [10:53:14 CEST] <rcombs> maybe? But everything involved should be bitexact, right? [10:53:47 CEST] <rcombs> is there a mode to do framecrc with -c copy [10:53:54 CEST] <michaelni> is this using float aac ? [10:54:15 CEST] <nevcairiel> its codec-copy [10:54:25 CEST] <rcombs> oh, I guess I can just stick `-c copy` on the end [10:54:39 CEST] <nevcairiel> or should be anyway [10:54:41 CEST] <rcombs> since fate-run.sh doesn't do anything too magical with it [10:54:48 CEST] <rcombs> there's precedent for it [10:56:43 CEST] <rcombs> michaelni: try this on top of the existing patch? https://gist.github.com/683b152feeef90678547586ec1c29f74 [10:57:12 CEST] <rcombs> removing the codecs from the test makes enough sense here [10:57:42 CEST] <nevcairiel> it actually wrote pcm into the mkv? [10:58:18 CEST] <nevcairiel> guess that involved quite a few conversion steps then [10:58:41 CEST] <rcombs> nah, it was just decoding on the way into framecrc [11:00:26 CEST] <nevcairiel> right, still float decoding and float -> pcm conversion [11:00:41 CEST] <nevcairiel> float -> int [11:00:42 CEST] <nevcairiel> i mean [11:01:32 CEST] <rcombs> in theory that can be bitexact reproducible! [11:01:49 CEST] <rcombs> (in practice, yeah, I highly doubt the bulk of lavc's float code is) [11:12:17 CEST] <fritsch> mmh, some of our users have dts wavs in flacs [11:12:29 CEST] <fritsch> we decode them, which ends up in floatp [11:12:34 CEST] <fritsch> and then output it as 32 bit int [11:12:39 CEST] <fritsch> and -> avr still gets dts :-) [11:12:46 CEST] <fritsch> so, not that bad as one could assume [11:13:04 CEST] <fritsch> the lavc's float code [11:14:55 CEST] <nevcairiel> why do you decode flac to float [11:15:08 CEST] <nevcairiel> its a lossless integer format [11:16:56 CEST] <rcombs> fuck those people, though [11:17:12 CEST] <fritsch> hehe, yeah [11:17:13 CEST] <nevcairiel> also that [11:17:36 CEST] <nevcairiel> i refuse to support double-packed formats like that [11:17:53 CEST] <nevcairiel> dts-in-wav is bad enough but you can just feed it through a decoder and it works [11:18:18 CEST] <nevcairiel> but two decoders for dts-in-flac .. well you can bit-exact stream it if you want, but thats all I give you =p [11:18:55 CEST] <michaelni> rcombs, when run from subdir it seems to fil with: reference file 'tests/ref/fate/segment-adts-to-mkv-header-all' not found [11:19:15 CEST] <michaelni> the patch fixed the previous issue though [11:19:21 CEST] <rcombs> I don't know how to fix that [11:19:51 CEST] <nevcairiel> maybe a different path somewhere? [11:20:04 CEST] <rcombs> oh wait, yes I do [11:21:07 CEST] <rcombs> https://gist.github.com/e6a084df159ecba15bfec73727240ab3 [11:21:52 CEST] <nevcairiel> that looks ok [13:08:07 CEST] <ubitux> [] subtitles decoding | [] subtitles filtering | [ ] subtitles encoding [13:08:09 CEST] <ubitux> @_@ [13:08:41 CEST] <ubitux> how do a/v encoders figure out their output packet size? [13:09:29 CEST] <nevcairiel> carefully [13:09:39 CEST] <nevcairiel> its a lot of guesswork [13:09:40 CEST] <ubitux> for subtitles we have the user hard code a large value, in ffmpeg.c it's 1024*1024... [13:10:02 CEST] <ubitux> nevcairiel: heuristics around bitrate etc? [13:10:31 CEST] <ubitux> is that done by the framework before the encode? of the encoder themselves? what happens in case of a two small allocated pkt data buffer? [13:10:42 CEST] <nevcairiel> the encoder has to take care of that [13:11:04 CEST] <nevcairiel> and the heuristic is probably part of every encoder itself, but i think they can realloc them? [13:11:30 CEST] <ubitux> OK so it's not up to the framework to figure out a potentially good enough packet size? [13:11:55 CEST] <nevcairiel> dont think so [13:12:36 CEST] <ubitux> ok, that's cool then [13:12:36 CEST] <ubitux> thanks [13:13:47 CEST] <nevcairiel> you can just call ff_alloc_packet2 with the size you want [13:15:14 CEST] <nevcairiel> there is also the option for an internal buffer in avctx->internal->byte_buffer for temporary writing, some encoders use that apparently [13:17:26 CEST] <ubitux> "some encoders" = mpegvideo? :p [13:27:48 CEST] <ubitux> yeah right we should get rid of that field and put it in mpegvideo [13:43:33 CEST] <ubitux> ...but in the meantime i'll use it temporarly for subtitles :° [15:26:16 CEST] <Sam_> hi there [15:27:11 CEST] <Sam_> i have downloaded the SimpleDLNA and added a video to test, but how to play it in VLC ? [15:27:56 CEST] <Sam_> using the http://IP Given: port give/mm-3/ ? [16:12:41 CEST] <DHE> Sam_: wrong channel [16:44:39 CEST] <fritsch> Short question, is there a documentation which public ffmpeg methods (like sws_scale, resample, and so on) need to use buffers allocated with av_malloc? [16:45:38 CEST] <fritsch> i sometimes run into alignment issues, especially with arm intrinsics used when e.g. format converting yuvj420p to e.g. rgba - and properly (manually) aligning buffers fixes these issues [16:47:31 CEST] <nevcairiel> if in doubt, all of them [16:47:31 CEST] <nevcairiel> :D [16:47:40 CEST] <fritsch> hehe and now without kidding? [16:47:44 CEST] <nevcairiel> i'm not [16:48:30 CEST] <fritsch> okay, there is no guarantee if I do uint8_t* buffer = new uint8_t[whatever]; [16:48:39 CEST] <nevcairiel> anything that deals with uncompresse data should ideally be aligned, because uncompressed is very good for SIMD [16:48:41 CEST] <fritsch> that this will heavily crash If I add that into ffmpeg? [16:48:46 CEST] <nevcairiel> compressed data is probably fine otherwise [16:48:53 CEST] <nevcairiel> so align AVFrame, dont care much about AVPacket [16:49:22 CEST] <nevcairiel> i dunno how much protection we have against this [16:49:29 CEST] <nevcairiel> swscale used to have some checks for aligned data [16:49:33 CEST] <nevcairiel> not sure if its complete [16:52:40 CEST] <fritsch> oki, I will carefully check :-( [16:52:41 CEST] <fritsch> thx [16:53:21 CEST] <nevcairiel> even if it has checks it'll massively cost you performance [16:53:33 CEST] <nevcairiel> because it'll likely go to a C path [17:31:41 CEST] <cone-966> ffmpeg 03Muhammad Faiz 07master:068653700227: avfilter/avf_showcqt: add bar_t option [17:44:20 CEST] <wm4> indeed, it's unfortunately just better to stick to ffmpeg's crap when feeding it data [17:44:57 CEST] <wm4> even AVPacket is very weird because it requires padding [18:14:41 CEST] <jkqxz> So, what do we want to do with qsv? [18:21:58 CEST] <wm4> drop it entirely [18:29:51 CEST] <jamrial_> jkqxz: commit your libav sync work and resume merges, obviously [18:33:46 CEST] <jkqxz> How do we become quorate to do that? [18:34:09 CEST] <jkqxz> There have been zero responses to anything I sent to the ML. [18:35:39 CEST] <jamrial_> jkqxz: not a lot of people can test it. i think RiCON is the only one that was able to so far [18:35:40 CEST] <nevcairiel> are there any known failures remaining? [18:35:53 CEST] <nevcairiel> other then the vc1 log spam, that is [18:36:10 CEST] <jkqxz> jamrial_: I assume you didn't get any response on Ivan Uskov? [18:36:15 CEST] <jamrial_> jkqxz: if this fourth version works and nobody finds new failures, then just push it [18:36:36 CEST] <jamrial_> jkqxz: no. i asked publicly, same as michaelni, and neither him or any other nablet dev replied [18:36:51 CEST] <nevcairiel> i think he was even specifically CCed to some of the threads [18:36:59 CEST] <jamrial_> cc'd him with the second ping, yeah [18:38:47 CEST] <jkqxz> I don't have any known failures, but I can only test on Linux. (Excepting a break of some hardware transcode cases in ffmpeg.c, which will get fixed a few patches on from the current merge point.) [18:39:36 CEST] <nevcairiel> the transcode case barely worked as it is due to the bbroken buffering in the current ffmpeg implementation [18:39:47 CEST] <nevcairiel> someone decided to buffer output surfaces instead of input data [18:39:56 CEST] <nevcairiel> nevermind that the surfaces are a far more limited resource [18:40:46 CEST] <jkqxz> Zeranoe: RiCON: Can either of you test qsv with the current proposed patches on Windows? [18:41:14 CEST] <nevcairiel> if all else fails i can probably dust off my laptop, it has an ivy bridge, assuming those are still supported =p [18:45:33 CEST] <jkqxz> Yeah, the transcode stuff is why we want the proper hwcontext implementation. Hacks in the current code just make some simple cases work badly. [19:37:22 CEST] <Zeranoe> jkqxz: I can [19:37:46 CEST] <Zeranoe> jkqxz: I haven't looked, but did you include those changes I suggested? I wont be able to test without them. [19:42:25 CEST] <jkqxz> <https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195544.html>? I have not, it should be a separate patch. [19:42:52 CEST] <Zeranoe> That's the one [19:43:21 CEST] <jkqxz> I agree it should be in, though. Let me rebase it on top of what I've got. [19:47:14 CEST] <cone-966> ffmpeg 03James Almer 07master:c4af48eb2716: configure: add missing fork() dependency to http_multiclient example [19:55:28 CEST] <DHE> what version of git is everybody using? I ask because my client seems to have... certain behaviours I feel are wrong. [20:02:27 CEST] <BtbN> whatever the package manager has. [20:03:32 CEST] <DHE> hmm... probably user error then [20:07:34 CEST] <BtbN> what are those certain behaviours? [20:07:56 CEST] <BtbN> Unless you are on some ancient 1.7 or 1.8, you should be fine. [20:32:06 CEST] <Zeranoe> jkqxz: Compiled fine with both patches. I'll do some testing now [20:37:17 CEST] <DHE> BtbN: I am actually [20:37:46 CEST] <DHE> what happened was it put a Date: header into the format-patch email which I didn't realize and I sent the patch to the mailing list dated 2 days ago. [20:37:46 CEST] <BtbN> those certain wrong behaviours might be still "by design" then [20:37:59 CEST] <DHE> 1.8.4.1 [20:38:18 CEST] <DHE> not huge, but still embarrassing [20:42:06 CEST] <Zeranoe> jkqxz: No issues with '-c:v h264_qsv -look_ahead 0 -an' yet. Is there anything specific you'd like me to test? [20:43:19 CEST] <jkqxz> Nothing specific, just everything :P [20:43:30 CEST] <jkqxz> Or at least, everything which you had working before. [20:44:36 CEST] <cone-966> ffmpeg 03Andreas Cadhalpun 07master:1e660fe88d2d: doc: fix spelling errors [20:45:35 CEST] <Zeranoe> jkqxz: I only have a 4790K to test with so I cannot do anything with lookahead [20:53:32 CEST] <Zeranoe> jkqxz: -q and -b:v both seem fine. No hangs yet [20:54:04 CEST] <Zeranoe> veryslow and veryfast presets seem fine. [20:54:38 CEST] <jkqxz> Do you normally have hangs when doing this? [20:55:19 CEST] <Zeranoe> Not on my 4790K normally [20:56:10 CEST] <Zeranoe> But who knows... I have yet to reproduce the hangs every time [20:58:30 CEST] <Zeranoe> Everything seems fine so far. If you'd like me to test anything else let me know. I can also provide the binary to anyone who wants to test on another CPU. [21:00:08 CEST] <BtbN> I'll make sure my next CPU won't have any QSV. Messed up stuff. [21:01:52 CEST] <RiCON> so, a zen? [21:02:20 CEST] <BtbN> Broadwell-E [21:02:49 CEST] <BtbN> Being an Early-Adopter for Zen doesn't seem overly tempting. [21:03:19 CEST] <Zeranoe> It seems like QSV is very disliked here. Why A) Was it included in the first place and B) is not removed from FFmpeg? [21:04:55 CEST] <jamrial_> disliked by a dev or two doesn't mean it has no merit [21:06:29 CEST] <jamrial_> not everyone has a discrete gpu after all [21:06:32 CEST] <RiCON> jkqxz: hadn't tested encoding yet, ivy doesn't like default rc either [21:06:52 CEST] <BtbN> It's just a bad API, with horrible issues. [21:07:19 CEST] <durandal_1707> what happened with irc log bot, it appears dead? [21:08:04 CEST] <jkqxz> It's the only way to get the best throughput out of the Intel codec hardware. I would certainly avoid it for cases which aren't maximise-throughput. [21:08:15 CEST] <jamrial_> durandal_1707: huh, you're right, logs haven't been posted for two days now [21:09:09 CEST] <jkqxz> RiCON: -b + -maxrate works? (The different modes there are not helpful.) [21:09:37 CEST] <RiCON> -look_ahead 0 works [21:10:36 CEST] <jkqxz> A difference against libav that I preserved was lookahead being on by default. Not sure where that came from, but someone might expect it. [21:11:06 CEST] <RiCON> hevc doesn't segfault anymore, which is nice [21:13:17 CEST] <jkqxz> Heh, that's the default plugin having been changed. A plugin which doesn't exist can't crash on you :) [21:16:19 CEST] <RiCON> not sure if i'm supposed to have a mpeg2 encoder available [21:18:12 CEST] <wm4> Zeranoe: because removing stuff from ffmpeg is almost impossible because those who don't have to deal with it resist against removal (that's how it usually goes) [21:19:05 CEST] <wm4> jkqxz: why is that, what restricts throughput with vaapi? [21:19:53 CEST] <fritsch> wm4: you already have dma buf support for hevc-10 bit vaapi implemented? [21:20:14 CEST] <fritsch> i started a bit today, but no hardware for the rendering part yet [21:20:32 CEST] <jkqxz> RiCON: Probably? I think the hardware has been there forever but drivers might not give access to you it. [21:21:24 CEST] <wm4> fritsch: no, but should be simple? [21:21:41 CEST] <fritsch> not really [21:21:45 CEST] <fritsch> P010 [21:21:51 CEST] <wm4> P010 is simple [21:22:07 CEST] <fritsch> you looked which R8G8 R8 transfer methods you have? [21:22:26 CEST] <wm4> shouldn't be any different from software P010 once you have the textzres [21:22:27 CEST] <wm4> *textures [21:22:32 CEST] <fritsch> i used 2 8s for Y and 2 8s for UV [21:22:43 CEST] <fritsch> which should work [21:22:51 CEST] <fritsch> from there creating the textures should be simple [21:22:55 CEST] <wm4> and DRM format support is of course a precondition [21:22:59 CEST] <fritsch> jep [21:23:04 CEST] <fritsch> we don't have that [21:23:09 CEST] <RiCON> jkqxz: anyway, hevc doesn't segfault, vc1 dec is still spammy with this sample but works, h264 enc/dec works, mpeg2 dec works, this on an ivy [21:23:09 CEST] <wm4> then fuck it [21:23:16 CEST] <fritsch> so trying to combine the given 8 bit versions [21:23:17 CEST] <jkqxz> wm4: Intel put more effort into optimising their proprietary stuff. The open-source drivers get bottlenecked on the render unit operations at the moment, so the codec blocks are idle for a significant amount of the time. [21:23:56 CEST] <wm4> fritsch: uh... oh yeah, let's implement ridiculous hacks to give the stupid consumer users theirt fucking bullshit [21:24:05 CEST] <fritsch> hehe [21:24:31 CEST] <fritsch> that's why I asked on how you gonna handle it [21:24:36 CEST] <wm4> jkqxz: makes sense (PS fuck intel) [21:24:40 CEST] <fritsch> the vaPutSurface way is "same" as before - as they convert internally [21:24:45 CEST] <wm4> fritsch: if it's going to be that way, not at all [21:25:02 CEST] <fritsch> yeah, will look in that part when capable hw appears [21:25:57 CEST] <wm4> what's missing is a DRM_FORMAT_R16 (and GR16) [21:28:29 CEST] <RiCON> jkqxz: according to wikipedia, mpeg2/vc1(?) only from haswell [21:28:33 CEST] <wm4> latest kernel still doesn't define such a format, but I was DRM_FORMAT_MOD_SAMSUNG_64_32_TILE, which is completely unrelated, but makes me physically sick [21:28:48 CEST] <wm4> excuse me while I vomit my dinner into the toilet in the name of technology [21:33:35 CEST] <jkqxz> RiCON: The i965 driver thinks it has an MPEG-2 encoder: <https://cgit.freedesktop.org/vaapi/intel-driver/tree/src/i965_device_info.c…>. [21:34:31 CEST] <jkqxz> It doesn't matter, though. Wanting to use that encoder is surely a very clear indicator of total insanity. [21:35:40 CEST] <fritsch> perhaps you can "check the workarounds" libyami does to get it behaving properly? [21:48:30 CEST] <Zeranoe> jkqxz: Testing on a Skylake now [21:52:37 CEST] <Zeranoe> jkqxz: Everything seems fine, along with look_ahead. Are any of your changes supposed to address hanging? [21:55:27 CEST] <jkqxz> Not directly, but the inner decode loop has changed significantly. [21:56:07 CEST] <Zeranoe> i havent got the hang yet [00:00:00 CEST] --- Sun Oct 30 2016

1 0

ffmpeg.log.20161029
by burek 30 Oct '16

30 Oct '16

[00:06:09 CEST] <nyuszika7h> I have multiple WebVTT subtitles in a m3u8 playlist, how do I get ffmpeg to merge them into one file without repeating the WebVTT header, and delay each subsequent file appropriately as they all restart time codes from 00:00? [00:06:53 CEST] <nyuszika7h> https://i.imgur.com/hY7x5a9.png [00:07:22 CEST] <nyuszika7h> hmm that output file is not even all of the subtitles [00:07:38 CEST] <klaxa> mux the individual files first to video + sub then concat the individual files? [00:08:32 CEST] <nyuszika7h> well I only have one video since it's from a different source [00:08:55 CEST] <nyuszika7h> can't get the video from where I got the subtitles because I'm missing the decryption key [00:09:14 CEST] <nyuszika7h> (and that's a separate playlist anyway) [00:26:08 CEST] <nyuszika7h> I've got all the files now, trying -f concat but it gives me an error [00:26:12 CEST] <nyuszika7h> [webvtt @ 000000000246ca40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 41 >= -102481816076876 [00:26:52 CEST] <nyuszika7h> https://ptpb.pw/Ja0- [00:28:25 CEST] <c_14> Use the concat protocol [00:29:22 CEST] <c_14> That's the -i concat:foo|bar one [01:47:54 CEST] <Phi> alright, anyone know anything about h264? [01:48:54 CEST] <Phi> well not him [01:50:30 CEST] <Phi> not him either [02:00:17 CEST] <DHE> can you be more specific? [02:00:46 CEST] <DHE> I know a number of things as long as I don't have to decode the raw bits (yet) [02:02:32 CEST] <bibble> what abouts it ? :D [02:03:02 CEST] <bibble> think it's closed source [02:05:49 CEST] <bibble> libebml v1.3.1 + libmatroska v1.4.2 Duration: 00:22:09.17, start: 0.000000, bitrate: 5058 kb/s Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709), 1916x1076 [SAR 1:1 DAR 479:269], 23.98 fps, 23.98 tbr, 1k tbn, 2k tbc (default) [02:06:10 CEST] <bibble> for some reason, I can't resize this mkv [02:06:32 CEST] <bibble> can use -s 640:380, but not -vf scale=640:-1 [02:07:04 CEST] <bibble> strange [02:07:08 CEST] <furq> 640:-2 [02:07:18 CEST] <bibble> hmm, interesting [02:08:17 CEST] <bibble> furq: you're a genius !! [02:08:27 CEST] <bibble> don't understand it though [02:08:59 CEST] <bibble> what's the difference between -1 & -2 ? [02:09:42 CEST] <bibble> oh.. 380 bound box, rather than 640 [02:11:16 CEST] <bibble> nope, still don't get it :) [02:11:40 CEST] <bibble> but working wonderfully... [02:18:21 CEST] <Phi> the issue is the timing on my video [02:18:49 CEST] <Phi> I have an RTSP stream, I want to read timing info from it and output to a video [02:19:23 CEST] <Phi> output playing at normal speed, basically, framerate not really relevant as long as it's the same visual speed [02:20:58 CEST] <Phi> I either get a video that plays very slowly, or one that plays one frame and never updates, or one that plays at about 10x speed [02:21:15 CEST] <Phi> dependent on what I set the codec timebase to (as libx264 requires that be set) [02:22:24 CEST] <Phi> the input is a variable framerate, so I'm not sure what I should do with packet dts/pts [02:22:29 CEST] <Phi> if I do nothing it breaks :p [02:26:10 CEST] <kepstin> bibble: that video is using yuv420p, which is a subsampled chroma format. Oniy sizes that are multiples of two are allowed. If you do "-vf scale=640:-2", it automatically rounds to a multiple of 2. [02:27:18 CEST] <bibble> oh, thank you kepstin [02:45:31 CEST] <Phi> "4 fps, 30 tbr, 90k tbn, 8 tbc" [02:45:31 CEST] <Phi> what [03:24:56 CEST] <s0126h> what do you people think about this picture? is this legit? http://www.flatpanelshd.com/pictures/superpls-1l.jpg [03:46:29 CEST] <Phi> DHE, I have an MP4 playing at double speed [03:46:44 CEST] <Phi> it's doing 8 fps although the RTSP goes at ~4fps [03:49:00 CEST] <DHE> sure you got the time base correct? [03:49:43 CEST] <Phi> I copy it straight from the RTSP's one [03:50:07 CEST] <Phi> video_file_stream->time_base = rtsp_vidstream->time_base; video_file_stream->codec->time_base = rtsp_vidstream->codec->time_base; [03:50:33 CEST] <Phi> (before avcodec_open2 on the video file stream) [03:55:21 CEST] <Phi> I'm showing 4 fps, 30 tbr, 90k tbn, 8 tbc [03:55:27 CEST] <Phi> all of those copied to destination stream [04:00:16 CEST] <Phi> any idea DHE? [04:02:24 CEST] <DHE> rtsp isn't my strong suit. I do most of my work in mpegts [05:23:14 CEST] <Phi> hmm [05:23:20 CEST] <Phi> my MP4 isn't seekable, any idea how to fix? [05:24:29 CEST] <Phi> I tried lowering the gop_size, but that didn't do anything [05:39:08 CEST] <Phi> what's weirder, if I open the stream in RTSP, I get a still image [05:40:29 CEST] <Phi> (in VLC) [06:31:55 CEST] <Phi> I fixed that issue, VLC doesn't like a RTSP with a framerate lower than 6 [06:33:41 CEST] <Phi> now I have a dilemma, if I do a DTS/PTS increment +1 manually, I get a MP4 file that plays at double speed [06:33:48 CEST] <Phi> but seeking in that file works fine [06:34:08 CEST] <Phi> if I multiply the PTS by 2, I get a normal speed, but seeking doesn't work at all [06:34:30 CEST] <Phi> VLC just keeps losing the frames until it hits the end of the file [09:47:43 CEST] <sopparus> how can I respond ona thread without being registred? [09:49:49 CEST] <sopparus> jkqxz, peter who made that patch wanted to add this [09:49:51 CEST] <sopparus> I think this patch from ffmpeg is not good. It works for you but all other users using TLS v1.0 will stay on dry with it because TLS v1.0 is not supported anymore. The problematic line is SSL_CTX_set_options which disables v1.0. Without this line both versions are supported but higher version has precedence (I think). You can write something on ffmpeg ml. [10:28:01 CEST] <jkqxz> sopparus: I don't understand what you mean. SSLv2 and SSLv3 are disabled; TLSv1, TLSv1.1 and TLSv1.2 are not? [10:28:25 CEST] <sopparus> neither do I, thats that he wrote [10:29:23 CEST] <sopparus> just tested it, it does indeed work with tls 1.0 [10:29:27 CEST] <sopparus> sorry for noice then [10:29:28 CEST] <sopparus> :) [13:33:01 CEST] <nyuszika7h> 00:28:25 <c_14> Use the concat protocol [13:33:16 CEST] <nyuszika7h> I think that will just concat the files, no? the problem is each subtitle file restarts timing at 00:00 [13:33:55 CEST] <c_14> nyuszika7h: I've used the concat protocol for .srt files and it fixed the timestamps [13:34:18 CEST] <klaxa> it will remux them into a new file [13:34:59 CEST] <nyuszika7h> oh nice [13:35:27 CEST] <nyuszika7h> will try that, though I have a LOT of segments, I wonder if it will cause an argument length error [13:41:08 CEST] <nyuszika7h> c_14: nope, the output file is still messed up [13:41:34 CEST] <nyuszika7h> it also repeats the WebVTT header still [13:42:43 CEST] <nyuszika7h> https://i.imgur.com/yNAqyp4.png [13:44:02 CEST] <c_14> hmm [13:45:03 CEST] <nyuszika7h> here's the original m3u8, if that helps: http://content-aeuf2.uplynk.com/82103317c22d4c03a9395d1bee07cdb5/sub3.m3u8 [13:45:44 CEST] <nyuszika7h> they usually also have it as a single TTML but that link is 404 for this episode >_> [13:53:54 CEST] <c_14> If you only need this done once, it might be easiest to take the output from the concat protocol and use sed or something to delete the WEBVTT header lines [13:55:51 CEST] <nyuszika7h> wait, I had the segments in the wrong order [13:58:35 CEST] <nyuszika7h> the time codes are still off though because each segment restarts timestamping at 00:00 [13:58:55 CEST] <nyuszika7h> there are things like X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:95911680 but I can't make sense of those numbers [14:00:15 CEST] <furq> that doesn't work for me with srt either [14:03:08 CEST] <c_14> Oh yeah, it just interleaved the subtitles. I never actually tested the subs I just looked at the event numbers [14:11:51 CEST] <nyuszika7h> trying with mkvtoolnix now, it doesn't offset the timestamps despite the documentation saying it shoukd :/ [14:11:54 CEST] <nyuszika7h> *should [14:16:07 CEST] <nyuszika7h> okay, this is not even as simple as adjusting the timecodes like that because it gets horribly desynced [14:16:17 CEST] <nyuszika7h> there's supposed to be an offset somewhere but I can't find where [14:19:42 CEST] <nyuszika7h> hmm there's an EXT-X-DISCONTINUITY which returns the timestamps relative to the time I request the m3u8 file [14:20:07 CEST] <nyuszika7h> it also returns the initial date, good [14:20:19 CEST] <nyuszika7h> I'll try to write a script to handle this [14:31:32 CEST] <furq> isn't the extinf in the m3u8 the segment duration [14:37:35 CEST] <nyuszika7h> furq: hmm it might be [14:37:41 CEST] <nyuszika7h> it's always #EXTINF:4.0107 [14:37:53 CEST] <nyuszika7h> well except the last one [14:38:05 CEST] <nyuszika7h> that might be helpful too [14:38:46 CEST] <nyuszika7h> I guess that means if the last subtitle doesn't end at 4.0107 in the segment I need to add a delay, makes sense [17:42:55 CEST] <Filarius> Hello, pls help with erro while piping raw RGB frames via StdIn http://pastebin.com/q2w5dJ4y [17:45:26 CEST] <Filarius> I sending data with much lower parts then error show [17:45:40 CEST] <SouLShocK> why the "n" after -c:a ? are you trying to do -an? [17:46:38 CEST] <Filarius> well, its was like "this do not works, lets try some shit, oh it works!, oh, I changed something and its stop working" [17:48:39 CEST] <Filarius> -an same result [17:49:45 CEST] <Filarius> it make file with about 5600 bytes, looks like just header [17:56:04 CEST] <SouLShocK> rgb24 does not look like it is a supported pixel format [17:56:49 CEST] <furq> that's an input option [17:58:06 CEST] <Filarius> processing of file with same data is works okay, if I just replace "-i -" with "-i rgb.raw" [17:58:30 CEST] <furq> are you sure the thing you're piping from is working correctly [17:58:58 CEST] <furq> i guess that's probably where you got rgb.raw from [17:59:59 CEST] <Filarius> i just wrote my data to file [18:00:33 CEST] <Filarius> just writing wrapper for ffmpeg on C# [18:02:57 CEST] <Filarius> I need ise github next time [18:06:02 CEST] <Filarius> any explain what messages from log means ? [18:55:15 CEST] <Phi> Well, I fixed my double-speed MP4 issue [18:55:36 CEST] <Phi> the trick is to do av_rescale_ts() on the packet, then multiply BOTH the output pts/dts by 2 [18:55:53 CEST] <Phi> then you get a normal speed MP4 with seeking and duration working properly [18:56:04 CEST] <Phi> (oddly doubling packet->duration doesn't appear to do anything) [18:58:09 CEST] <DHE> depends on the format. and it answers questions like how long to show the last frame on-screen of a video [19:09:16 CEST] <Phi> I would've thought RTSP H264 -> MP4 H264 wouldn't change that [19:15:14 CEST] <Phi> I think it happened with the copy thing as well [19:15:40 CEST] <Phi> the issue with the profile staying High was I was basically taking the received network frame and chucking it at the MP4 [19:16:33 CEST] <Phi> now I have to do "receive network frame, pass to decoder, read frames in loop from decoder and pass each one to encoder, read packets in loop from encoder and pass to MP4 [19:16:37 CEST] <Phi> " [19:16:42 CEST] <Phi> which is slightly more complicated... [19:17:05 CEST] <Phi> and not very obvious, since all the examples I saw didn't even mention it [19:17:35 CEST] <Phi> still weird RTSP H264 -> MP4 H264 makes a double-speed MP4 [19:17:43 CEST] <Phi> but eh, ciao [21:39:29 CEST] <kerio> something only marginally related to ffmpeg - what's the best way of compressing grayscale 16bpp video? [21:40:28 CEST] <fritsch> lossless? [21:40:32 CEST] <kerio> yes [22:09:02 CEST] <klaxa> ffv1 would be a start at least [22:27:46 CEST] <Filarius22> I found there is 5 y.o. forum thread about ffv1 not support grayscale 16 bpp pixel format [22:28:55 CEST] <klaxa> >klaxa@neu ~> ffmpeg --help encoder=ffv1 [22:28:55 CEST] <klaxa> >[...] [22:28:55 CEST] <klaxa> > Supported pixel formats: yuv420p yuva420p yuva422p yuv444p yuva444p yuv440p yuv422p yuv411p yuv410p bgr0 bgra yuv420p16le yuv422p16le yuv444p16le yuv444p9le yuv422p9le yuv420p9le yuv420p10le yuv422p10le yuv444p10le yuva444p16le yuva422p16le yuva420p16le yuva444p10le yuva422p10le yuva420p10le yuva444p9le yuva422p9le yuva420p9le gray16le gray gbrp9le gbrp10le gbrp12le gbrp14le ya8 gbrp16le rgb48le [22:29:24 CEST] <klaxa> gray16le should be 16 bpp [22:31:54 CEST] <Filarius22> I was curious about "le" part of gray16le, its "little engian", maybe you know it already [22:45:05 CEST] <klaxa> *little endian [22:45:19 CEST] <klaxa> it's about byte order, and i never get that right [22:48:38 CEST] <DHE> x86 is little-endian, so that's a native 'short' type integer on an intel CPU [22:48:54 CEST] <DHE> it shouldn't matter much if you're just using ffmpeg on the commandline [00:00:00 CEST] --- Sun Oct 30 2016

1 0

ffmpeg-devel.log.20161028
by burek 29 Oct '16

29 Oct '16

[00:48:57 CEST] <cone-511> ffmpeg 03Stephen Hutchinson 07n3.3-dev:HEAD: avisynth: fix Planar RGB output [02:00:15 CEST] <cone-511> ffmpeg 03Andreas Cadhalpun 07master:940b8908b944: apng: use side data to pass extradata to muxer [03:26:59 CEST] <jamrial_> fflogger seems to be glitching... [12:32:31 CEST] <cone-969> ffmpeg 03Michael Niedermayer 07master:077939626eea: avformat/flvdec: Fix regression loosing streams [19:32:15 CEST] <Compn> hehe [19:32:22 CEST] Action: Compn tosses a pebble at jamrial [19:33:40 CEST] <Compn> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199686.html [19:33:44 CEST] <Compn> you guys all ignoring this thread? [19:33:48 CEST] <Compn> anyone contact him ? [19:34:20 CEST] <Compn> >I would like to step in to make ffserver maintainable and distributable again, especially because of the many users depending on ffserver - including myself. [19:34:35 CEST] <Compn> doesnt happen very often :) [19:34:41 CEST] <atomnuker> Compn: god damn it compn, the more we leave ffserver the more we're stuck [19:34:48 CEST] Action: Compn chuckles [19:35:05 CEST] <Compn> atomnuker : my point was, get new maintainer to agree , and then is ok [19:35:19 CEST] <atomnuker> Compn: nobody maintains it [19:35:31 CEST] <Compn> maybe he is working on his own repo... [19:35:40 CEST] <Compn> who knows, thats why we need to contact him [19:35:53 CEST] <atomnuker> nobody has done shit, okay [19:35:59 CEST] <Compn> then we had ffm discussions too [19:36:04 CEST] Action: Compn remembers ffm thread [19:36:58 CEST] Action: Compn hides under his rock [19:38:27 CEST] <Compn> atomnuker : i think we all agree, did you setup new repo for ffserver only ? [19:38:43 CEST] <Compn> and get it over there ? [19:39:13 CEST] <atomnuker> Compn: nope, lets do that after it's removed [19:39:21 CEST] <atomnuker> BECAUSE WE'RE NEVER GOING TO FUCKING GET RID OF IT OTHERWISE [19:41:00 CEST] <Compn> :) [19:41:50 CEST] Action: Compn almost comes close to saying four letter word starting with v, but refrains [19:42:25 CEST] <Compn> ok i need to escape from computer. cya [19:43:08 CEST] <jamrial> no Compn, not ignoring it. that thread simply wont change the outcome of the decission [19:44:50 CEST] <jamrial> Compn: writing a reply to your email. and sorry, but this ship has sailed [19:45:02 CEST] <atomnuker> 4 letter word starting with v... very, vase, vine, volt, the rest is mostly giberrish? [19:45:20 CEST] <jamrial> atomnuker: calm down. no point getting angry [19:45:33 CEST] <Compn> jamrial : atomnuker is cool, hes my friend :) [19:45:39 CEST] <Compn> atomnuker : 'vote' [19:46:47 CEST] <Compn> now if you will excuse me, i have to decide between hillary clinton and donald trump to run the world. [19:49:01 CEST] <atomnuker> have fun [19:54:00 CEST] <BBB> Compn: happy voting! [19:54:21 CEST] <BBB> as for the ffserver thing, I 100% support removing it [19:56:57 CEST] <BBB> isnt it funny that veto and vote are anagrams? [19:58:14 CEST] <reynaldo> atomnuker: It't not true there's no maintainer, it has been a few months since I put time to it but Im still doing it. An I'm working on the new repo already, being doing it since yesterday [19:59:34 CEST] <reynaldo> if a 1y hiatus is enough to declare a file unmaintained we are in dire straits [19:59:58 CEST] <reynaldo> anyway, working on a solution. I hope to have something ready to show in the comming days [20:03:13 CEST] <nevcairiel> maintained or not, ffserver is essentially in a delete-worthy state [20:06:52 CEST] <atomnuker> reynaldo: does it involve keeping ffserver in the repo? [20:08:46 CEST] <reynaldo> did you read my email? [20:08:52 CEST] <reynaldo> it does not [20:09:22 CEST] <reynaldo> I try for them to be very brief so the point is clear. Thought what I was suggesting was clear [20:10:05 CEST] <atomnuker> which one? [20:10:05 CEST] <reynaldo> the email I didnt get is the one with the references to the discussion and related desicion you(?) were sending yesterday. Can you point me to it? [20:10:23 CEST] <atomnuker> yes, jamrial did [20:10:47 CEST] <reynaldo> atomnuker: the first one I sent yesterday [20:11:22 CEST] <reynaldo> stated my reasons for oppossing and supported the alternative of moving ffserver and possibly the rest of the apps progressively to another repo [20:11:25 CEST] <reynaldo> starting with ffserver [20:11:36 CEST] <reynaldo> this has always been my take [20:12:06 CEST] <atomnuker> well, we're killing time, lets do it [20:12:15 CEST] <reynaldo> I was explicit: Im not rejecting the patch, I would like to hold on it there's an alternative and theres one working now but I want to make it a bit better [20:12:38 CEST] <reynaldo> it wont take a lot of time, few days top [20:12:57 CEST] <atomnuker> okay, what kind of an alternative? [20:12:59 CEST] <reynaldo> and note, usually destructive changes came with a solution attached, the only reason Im doing this now is because theres ppl using it [20:13:11 CEST] <reynaldo> otherwise I'd demand it as an attachment to your patch [20:14:23 CEST] <atomnuker> I mean I said I'd wait a few days and I'm waiting [20:14:26 CEST] <reynaldo> atomnuker: one in the lines I presented, ffserver (possibly latter other ffmpeg cmd line apps) on an "applications" repo and out of ffmpeg/ [20:14:30 CEST] <reynaldo> perfect [20:14:34 CEST] <reynaldo> appreciated [20:14:40 CEST] <jamrial> reynaldo: i'm fine waiting until you come up with this separate repo for ffserver. we already missed the 3.2 release so no real hurry for a few weeks [20:14:52 CEST] <reynaldo> jamrial: brilliant [20:14:58 CEST] <reynaldo> then we are all in the same page [20:14:58 CEST] <jamrial> but ffserver will be gone from the main tree before the next release [20:16:50 CEST] <atomnuker> but please don't take more than a few days, make it better and post it ASAP [20:18:21 CEST] <jamrial> and as others pointer, separate repo for ffmpeg/ffplay/ffprobe would be a massive PITA and not really worth the trouble [20:18:41 CEST] <reynaldo> Im not gona include those in [20:18:47 CEST] <reynaldo> but leave the door open is my plan [20:19:12 CEST] <reynaldo> and discuss it properly latter on if time allows [20:19:19 CEST] <jamrial> all three applications use public api only, so the whole "private api, bad practice" argument is null for htem [20:19:21 CEST] <reynaldo> leaving/ [20:19:23 CEST] <jamrial> only ffserver was abusing it [20:19:28 CEST] <jamrial> later [20:19:49 CEST] <reynaldo> no, I meant s/leave/leaving/g ;) [20:26:19 CEST] <sopparus> I added a proposed patch in there (not mine) is that ok? or must I go to the ML [20:26:58 CEST] <jamrial> sopparus: ml for patches, yes [20:27:27 CEST] <sopparus> ok [20:32:10 CEST] <reynaldo> btw, is there any rationalle behind our uninstaled pkg-config files not being named blah-uninstalled.pc as usual ? [20:33:00 CEST] <reynaldo> it makes PKG_CONFIG_LIBDIR/PKG_CONFIG_PATH trickery a bit harder [20:33:28 CEST] <reynaldo> (than expected. Not rocket-science-harder) [20:35:43 CEST] <jamrial> don't think there's any reason other than whoever implemented it forgot or didn't think it was necessary [20:43:19 CEST] <reynaldo> yeah, figured that much [20:43:27 CEST] <reynaldo> will send patch [21:10:30 CEST] <Compn> im glad you guys worked it out :) [21:12:54 CEST] <reynaldo> +1 [21:15:01 CEST] <jamrial> Compn: can't say it made a difference since ffserver is still being deleted. reynaldo just asked time so his separate repo can be up before the removal [21:15:16 CEST] <jamrial> and since we missed the 3.2 deadline, there's no reason to say no to that request [21:18:45 CEST] <jamrial> reynaldo: you know this separate ffserver repo can't depend on the ffm mux/demuxer, right? those will be deleted in an upcoming major bump since they are using deprecated api [21:21:35 CEST] <reynaldo> I'm aware it can depend on it up till when ffm is removed. I wont de-ffm ffserver in just a few days [21:23:44 CEST] <jamrial> reynaldo: i know, just making sure you're aware it's not just a matter of removing the usage of internal lavf functions in the long term [21:24:55 CEST] <reynaldo> Quite. There are other problems and several possible solutions ;) [21:25:13 CEST] <reynaldo> jamrial: thanks for the warning all the same. [00:00:00 CEST] --- Sat Oct 29 2016

1 0

ffmpeg.log.20161028
by burek 29 Oct '16

29 Oct '16

[00:45:25 CEST] <TheXzoron> still trying to make a general record script but I'm running into issues with audio still https://dpaste.de/5fTk [00:45:39 CEST] <TheXzoron> example http://thex.oniichan.me:1600/i/vlcsnap-2016-10-27-17h43m19s666.mp4 [00:48:42 CEST] <TheXzoron> please excuse profanity in that I forgot to cleanse it [00:50:01 CEST] <klaxa> ah, the dreaded alsa xrun [00:50:13 CEST] <klaxa> i have yet to see someone "solve" that [00:51:07 CEST] <klaxa> if you ran pulse you would not run into this problem [00:51:13 CEST] <TheXzoron> recording in obs works [00:51:21 CEST] <klaxa> but using pulse is quite the "hefty workaround" [00:51:54 CEST] <TheXzoron> so I'm sure there is a way in ffmpeg [00:54:17 CEST] <klaxa> are you sure obs is also using alsa? [00:54:41 CEST] <TheXzoron> I have the yes [00:54:46 CEST] <TheXzoron> *yes [00:57:41 CEST] <TheXzoron> https://a.desu.sh/zehdjm.mp4 [00:58:33 CEST] <TheXzoron> klaxa: [00:59:13 CEST] <klaxa> ok [00:59:16 CEST] <klaxa> hmm... [01:00:44 CEST] <klaxa> what made you use -thread_queue_size 67? [01:01:24 CEST] <TheXzoron> it kept asking me to increase it and I was grasping at straws even thouhg it did not make sense [01:01:56 CEST] <iive> do you have pulse audio on your system? [01:02:42 CEST] <iive> usually pulse solves problem, that pulse have caused itself... e.g. it intercepts alsa [01:03:08 CEST] <TheXzoron> I do have it on my system but I have chosen to get rid of it due to instability [01:03:11 CEST] <TheXzoron> it crashes often [01:03:21 CEST] <TheXzoron> right now it it marked unexecutable [01:03:28 CEST] <TheXzoron> so that it does not start up out of nowhere [01:03:41 CEST] <iive> ok [01:04:46 CEST] <klaxa> in the video it sounds like ffmpeg is reading from alsa too fast [01:05:04 CEST] <klaxa> must -ar be used with -f alsa? [01:05:18 CEST] <klaxa> would adding -re change anything? [01:05:34 CEST] <iive> he have ar, but it is in the codec section. [01:05:43 CEST] <iive> position does matter [01:05:59 CEST] <klaxa> no, it's in the input section for the audio input [01:06:13 CEST] <klaxa> [...] -f alsa -ac 2 -ar 48000 -thread_queue_size 67 -i looprec [...] [01:06:15 CEST] <iive> klaxa: i do agree with you [01:06:34 CEST] <klaxa> oh, yes, codec == coder/decoder [01:06:41 CEST] <klaxa> nevermind me :) [01:08:44 CEST] <debianuser> TheXzoron: does simple recording from just alsa works fine? Try `arecord -v -Vstereo -fdat -Dlooprec somefile.wav` and copy whatever it prints to some pastebin. Also check if the audio file it recorded is fine. [01:09:50 CEST] <debianuser> ("-fdat" is a shorcut for "-fS16_LE -r48000 -c2") [01:12:28 CEST] <TheXzoron> https://a.desu.sh/krjnhi.wav [01:12:38 CEST] <TheXzoron> it seems to record just fine with alsa [01:14:04 CEST] <TheXzoron> http://thex.oniichan.me:1600/i/vlcsnap-2016-10-27-18h08m18s666.mp4 I cleaned up the ffmpeg command line to just ffmpeg -f x11grab -s "$W"x"$H" -i :0.0+$X,$Y -f alsa -i looprec /tmp/$TIMESTAMP [01:14:11 CEST] <TheXzoron> and it still does that [01:16:09 CEST] <iive> TheXzoron: try without capturing the screen (x11grab) [01:18:13 CEST] <TheXzoron> https://a.desu.sh/ongmnz.mp4 [01:18:19 CEST] <debianuser> good idea. try just alsa, but with ffmpeg: `ffmpeg -f alsa -i looprec anotherfile.wav` [01:18:31 CEST] <TheXzoron> I get an xrun in the begining [01:18:35 CEST] <TheXzoron> but then it's smooth [01:18:47 CEST] <TheXzoron> ffmpeg -f alsa -i looprec /tmp/test.mp4 [01:21:07 CEST] <debianuser> Maybe just not enough cpu for encoding, so ffmpeg doesn't process incoming data fast enough, thus it doesn't read alsa fast enough, and that causes buffer overrun? [01:22:39 CEST] <iive> possible, [01:22:52 CEST] <iive> i don't see encoder, so it might be hdd io blocking [01:23:12 CEST] <iive> try with /dev/null output. -f null is a thing too, i think [01:23:51 CEST] <TheXzoron> I have a 4790k [01:24:02 CEST] <TheXzoron> I'm pretty sure the cpu is ample enough [01:24:07 CEST] <iive> also, somebody had hight cpu usage when captuing its intel video card. [01:24:22 CEST] <iive> he had to set some acceleration mode in xorg.conf.d/ [01:24:55 CEST] <TheXzoron> I'm recording to /tmp [01:25:00 CEST] <TheXzoron> which I have tmpfs mounted to [01:25:21 CEST] <TheXzoron> I also use a gtx 970 [01:28:42 CEST] Action: debianuser doesn't know what's the fastest ffmpeg encoding... Try something like: `ffmpeg -f x11grab -r 15 -s 320x240 -i :0 -f alsa -ac 2 -ar 48000 -i looprec -vcodec libx264 -preset ultrafast -tune zerolatency -acodec libvorbis somefile.mkv` Encoding 320x240 should be fast :) [01:30:30 CEST] <iive> TheXzoron: uncompressed hdtv video could eat your space pritty quickly. [01:31:16 CEST] <TheXzoron> I have mounted put 12GB of space in tmpfs [01:31:41 CEST] <TheXzoron> interestingly debianuser's ffmpeg options do not cause a single xrun [01:31:58 CEST] <TheXzoron> while recording audio only got 1 xrun in the begining [01:32:16 CEST] <iive> well, at 155mb/s it would take you 77 seconds to fill it all up [01:32:53 CEST] <TheXzoron> well I'm not recording at that quality :p [01:33:05 CEST] <iive> don't you? [01:33:47 CEST] <TheXzoron> don't I what? [01:33:54 CEST] <debianuser> :) [01:34:13 CEST] <iive> record at that quality... [01:34:27 CEST] <iive> you don't have -vcodec or -c:v [01:34:39 CEST] <TheXzoron> so far all my recirding have been arround 10-60mb with 60mb going on for a good 5 to 10 minutes [01:34:51 CEST] <TheXzoron> *recordings [01:35:00 CEST] <iive> ok [01:35:09 CEST] <iive> let's say you got mpeg4 asp [01:36:57 CEST] <debianuser> TheXzoron: that command captures 15fps of 320x240, it should be rather fast, but not too useful. Try to increase those values, first try to increase image size e.g. -s 800x600: `ffmpeg -f x11grab -r 15 -s 800x600 -i :0 -f alsa -ac 2 -ar 48000 -i looprec -vcodec libx264 -preset ultrafast -tune zerolatency -acodec libvorbis somefile.mkv` If that would still work - try higher fps (`-r 25` or `-r 30`). [01:37:22 CEST] <furq> i don't think tune zerolatency increases throughput [01:39:40 CEST] <TheXzoron> iive: actually all my recordings that I have not deleted since I decided to try to make this script total to 64mb... [01:40:02 CEST] <iive> strange [01:40:29 CEST] Action: debianuser doesn't know if zerolatency makes it faster either... [01:40:45 CEST] <iive> furq: it disables a lot of complicated stuff [01:41:27 CEST] <furq> i just tested and it's noticeably slower [01:41:57 CEST] <furq> it disables frame multithreading which is a very bad idea for throughput [01:42:13 CEST] <furq> it also disables cabac, but preset ultrafast already does that [01:44:24 CEST] <iive> hum... disabling mt actually increases latency [01:44:41 CEST] <furq> well it switches to slice multithreading, which is slower [01:44:54 CEST] <furq> but it means you're not buffering $threads input frames [01:45:26 CEST] <furq> but yeah in general don't use zerolatency unless you actually need zero latency [01:45:56 CEST] <TheXzoron> so [01:46:10 CEST] <TheXzoron> what's causing the xruns exactly [01:47:15 CEST] <iive> at playback they are caused when the sound cards play all the data but cpu doesn't supply new one [01:47:45 CEST] <iive> at recording i guess it might be when cpu doesn't take all the data in time. [01:48:07 CEST] <iive> but then bigger buffers should help. [01:49:24 CEST] <TheXzoron> so if I want to record a quick mp4 on the fly I should increase the buffer [01:49:33 CEST] <TheXzoron> what settings tune this [02:01:01 CEST] <TheXzoron> https://a.desu.sh/rrdjyo.mp4 [02:01:03 CEST] <TheXzoron> this works [02:01:15 CEST] <TheXzoron> so I guess I needed to specify more stuff [02:01:43 CEST] <TheXzoron> although the xrun in the begining is odd [02:07:38 CEST] <TheXzoron> now I need to look into why browser are being poopy and not playing the file [02:07:54 CEST] <TheXzoron> and decide on what codec will work for everyone's special and cool browser [02:09:32 CEST] <tontonth> TheXzoron: nice windows dance :) [02:10:56 CEST] <TheXzoron> thank you I apreciate that someone can see nice things in my workflow [02:14:47 CEST] <TheXzoron> ok so acc works in both firefox and chrome [02:14:53 CEST] <TheXzoron> so that is what I will use then [02:16:41 CEST] <TheXzoron> thank you guys [02:28:58 CEST] <TAFB2> I love ffmpeg :) [02:31:52 CEST] <TheXzoron> same [02:41:45 CEST] <TAFB2> and I love HLS streaming!!! With my up and down internet, I could never stream properly without HLS! Now it's flawless [02:56:36 CEST] <klaxa> well you actually have to thank apple for that [04:37:26 CEST] <hamsheet> hi i downloaded bunch of youtube videos but they are hd and huge files like couple gigs each. Any recommendations for keeping the resolution same but opotimizing the file size a bit? I d onot care about the sound quality much [04:38:47 CEST] <hamsheet> 94 files, 98 gbs [04:43:08 CEST] <klaxa> youtube already does pretty good encoding [04:43:52 CEST] <klaxa> you can decrease sound quality though, but i'm not sure how much that will help [04:44:27 CEST] <klaxa> to do so do: ffmpeg -i input.mkv -c copy -c:a aac -b:a 96k output.mkv [04:44:46 CEST] <furq> download them in webm [04:45:00 CEST] <klaxa> that might be better [04:45:16 CEST] <hamsheet> furq: some videos are not avail in webm? [04:51:09 CEST] <furq> the audio will probably be 128k aac if these are mp4, so reencoding the audio is barely going to make a dent [04:51:34 CEST] <furq> if these are 1080p then i would probably just use 720p instead [04:51:40 CEST] <furq> youtube's 1080p looks pretty crap anyway [04:52:03 CEST] <dl2s4> youl could reencode the video as well, i cant imagine that reencode audio will save good space [04:52:36 CEST] <furq> you could but it probably won't achieve much [04:52:42 CEST] <hamsheet> dl2s4: i can reencode sure, any recommendation for the cli? [04:52:54 CEST] <dl2s4> like idk -c:v x264 -crf 30 or something [04:53:04 CEST] <furq> youtube videos are already heavily optimised for low bitrate [04:53:13 CEST] <dl2s4> ok [04:53:27 CEST] <hamsheet> furq: so i should redownloaded in webm? [04:53:34 CEST] <furq> i would probably redownload in 720p [04:53:38 CEST] <furq> webm if you can get it [04:53:45 CEST] <hamsheet> i use oyutube dl, I acn do that it is just that i will have to download gigs of data again [04:53:48 CEST] <dl2s4> yeah i never tried it for youtube videos, but furq could be right [04:54:10 CEST] <furq> 720p webm is normally about half the size of 1080p mp4 [04:54:14 CEST] <furq> and it looks roughly the same [04:54:48 CEST] <hamsheet> furq: thanks I will try that [04:55:17 CEST] <hamsheet> the reason I want to optimize is that I serv the videos over my upnp server via the wireless [04:55:23 CEST] <hamsheet> and save space a bit [04:55:58 CEST] <hamsheet> the server can transcode but withtranscode i loose some playback features [04:56:07 CEST] <hamsheet> it uses ffmpeg for the transcode backend [04:58:11 CEST] <furq> http://vpaste.net/1S60u [04:58:47 CEST] <hamsheet> furq: do you know if youtube creates the webms on demand? [04:59:09 CEST] <furq> it's google so it's a bit of a mystery [04:59:20 CEST] <furq> at least on my channel it seems to be videos uploaded after a certain date that have >150 views [04:59:21 CEST] <hamsheet> for instance if the video does not have a webm format, does it create the webm once it is requested? [04:59:24 CEST] <hamsheet> I see [04:59:35 CEST] <dl2s4> i would try 136 [04:59:46 CEST] <hamsheet> I see makes sense, they measure the effort [04:59:56 CEST] <furq> get 247 if you can, otherwise 136 is fine [04:59:56 CEST] <hamsheet> dl2s4: thanks I will try [05:00:12 CEST] <furq> iirc you can tell youtube-dl to try multiple formats [05:01:22 CEST] <hamsheet> furq: I did not know that [05:01:33 CEST] <dl2s4> why do you prefer 246? i dont know much about vp9 [05:01:42 CEST] <hamsheet> I just see that the webm version of a 4gb movie file is like 1.98gb, already better [05:02:15 CEST] <furq> -f 247+251/136+140 [05:02:18 CEST] <furq> that should do it [05:02:27 CEST] <furq> dl2s4: he wants to save as much space as possible [05:02:35 CEST] <hamsheet> ahh that is nice [05:02:48 CEST] <furq> youtube webm is normally smaller than the corresponding mp4 [05:02:56 CEST] <dl2s4> ah right that was the goal ;) [05:02:56 CEST] <hamsheet> yeah that is for sure [05:03:05 CEST] <dl2s4> this* [05:03:33 CEST] <furq> but yeah youtube denoise everything so aggressively that there's not much difference between 720p and 1080p [05:03:51 CEST] <furq> 720p normally looks better to me [05:03:58 CEST] <furq> although granted i'm not watching on a big screen [05:07:51 CEST] <hamsheet> furq: they know what they are doing i guess [05:08:27 CEST] <hamsheet> it is a remarkable piece of achievment I mean serving and storing crazy amouunt of data in realtime, which serves to billions [05:08:46 CEST] <hamsheet> a bit fucked up [05:32:57 CEST] <bibble> got some massive .mkv files, 40min each. looking for ffmpeg command to reduce size whilst keeping as much quality as possible. don't mind doing 2pass [05:35:03 CEST] <bibble> currently done "ffmpeg -i "$v" -c:v copy -c:a copy out/"$v".mp4", which reduced each file from 2G to 1.6G really quickly. but looking to get them under 700M each. [05:37:10 CEST] <kepstin> hamsheet: note that youtube creates two different webms - they make a vp8 one on all videos (presumably for compat reasons), then a vp9 webm later/after some view threshold. [05:42:18 CEST] <furq> bibble: you'll struggle to get them that small without quality loss [05:42:37 CEST] <furq> you probably want to use -preset veryslow [05:43:43 CEST] <kepstin> bibble: do you have an exact target size you need, or just "smaller than they are now"? [05:43:45 CEST] <furq> the default crf is 23 which is already pretty high [05:44:17 CEST] <furq> actually nvm i can't read [05:44:43 CEST] <furq> just get rid of -c:v copy and see how big they turn out [05:44:43 CEST] <TAFB2> crf 0 veryslow ftw :) [05:45:07 CEST] <bibble> ah, ok furq kepstin , thanks. just smaller, as too large to stream currently. [05:45:46 CEST] <kepstin> tbh, I'm surprised the file size that much at all with -c copy; did the original have multiple audio tracks maybe? (That command would only copy the first) [05:46:02 CEST] <furq> either that or the source is mpegts [05:46:51 CEST] <kepstin> bibble: do something like ffmpeg -i "$v" -c:v libx264 -preset veryslow -crf 23 -c:a copy out/"$v".mp4 [05:47:03 CEST] <bibble> yeah, good point, thought was strange too that 400M had been reduced [05:47:12 CEST] <kepstin> bibble: use smaller crf if file looses too much quality, use bigger crf if file is too big. [05:47:15 CEST] <bibble> ok, will do kepstin [05:47:34 CEST] <kepstin> (range of around 18-28 or so is useful) [05:47:41 CEST] <bibble> used "ffmpeg -i in.mkv -vcodec libx264 -crf 20 out.mp4", and got 1.1G file [05:48:28 CEST] <furq> crf 23 is probably about right then [05:48:33 CEST] <kepstin> bibble: the 'veryslow' (default is medium) improves compression efficiency a bit, other than that, just play with crf. [05:48:41 CEST] <bibble> great :) [05:48:50 CEST] <furq> the preset doesn't normally have much effect on filesize, it'll just retain more quality at a given crf [05:51:32 CEST] <ossifrage> Is there a way to draw the frame size on the image with the drawtext vf? The docs mention pict_type, pts, n, etc... [05:52:39 CEST] <furq> if you mean dimensions then w and h [05:52:47 CEST] <Elronnd> do you lose any quality converting a lossy audio format to a lossless one? [05:53:08 CEST] <ossifrage> I tried to use metadata:pkt_size but no love [05:53:34 CEST] <Elronnd> I have a song only in mp3, and I want to convert it to flac for consistency [06:08:06 CEST] <TD-Linux> Elronnd, no, you don't lose any quality (but you don't gain any either) [06:13:07 CEST] <Elronnd> thanks [06:17:48 CEST] <fa0> Hello all [06:19:05 CEST] <Elronnd> hey [06:19:40 CEST] <fa0> with libfaac removed from 3.2, is libfdk-aac the only aac support? [06:20:42 CEST] <fa0> Actually, I'm compiling ffmpeg against everything it needs without them installed, so from what I can tell at the moment making this happen with libaacplus is not working [06:21:30 CEST] <furq> fa0: there's a builtin aac encoder now [06:22:12 CEST] <furq> it's not as capable as fdk but it's better than faac and vo-aacenc [06:22:24 CEST] <fa0> actually I think it's building against libaacplus, from what I can tell --enable-libaacplus is for non free code [06:22:57 CEST] <furq> i thought libaacplus was deprecated now [06:23:16 CEST] <furq> either way you should use fdk if you don't mind having a non-free binary [06:23:30 CEST] <furq> assuming you need he-aac support [06:23:33 CEST] <fa0> Ahh yes 3.0; libaacplus and libvo-aacenc support removed [06:23:46 CEST] <furq> faac was removed in 3.0 as well [06:24:08 CEST] <furq> fdk is the best oss library anyway [06:24:11 CEST] <fa0> actually faac in 3.2 [06:24:14 CEST] <furq> it's just slightly gpl incompatible [06:25:09 CEST] <fa0> Ok wait, I'm starting to get aac confused wheeee LOL [06:25:16 CEST] <fa0> So it's good to keep fdk-aac? [06:25:21 CEST] <furq> yeah [06:25:34 CEST] <furq> the builtin aac encoder is fine if you just want cbr lc-aac [06:25:47 CEST] <furq> if you want he-aac then use fdk [06:25:48 CEST] <fa0> ok, I'm hacking through a compile script someone else created that didn't keep this thing updated... [06:25:54 CEST] <furq> that sounds about right [06:26:00 CEST] <fa0> ok [06:30:40 CEST] <fa0> is libass still used for something? [06:33:50 CEST] <fa0> furq: if you might know, these are the extra libs/deps I was compiling before for 3.1x; http://dpaste.com/0YA91FK [06:34:11 CEST] <fa0> Not sure there's anything else there not needed for 3.2, but looking over the Changlog I don't see anything I'd need to remove, no longer needed... [06:34:43 CEST] <fa0> Or if anyone else knows if these libs are all still ok for 3.2? [06:45:12 CEST] <furq> looks ok to me [06:50:42 CEST] <fa0> ok [06:51:03 CEST] <fa0> wasn't sure if anything good to add in too... hmm [06:52:03 CEST] <fa0> Like I see there's openh264 [06:52:12 CEST] <furq> you probably want libvorbis and libvpx [06:52:54 CEST] <furq> openh264 is only really useful if you're encoding h264 commercially [06:53:39 CEST] <fa0> These are my comppile flags for it; http://dpaste.com/1SARVWR [06:55:29 CEST] <fa0> I just do small time stuff with ffmpeg, personally, most of the time, for videos, I just re-encode them for low volume is pretty much all I mess with it at the moment [06:56:00 CEST] <fa0> Like this; [06:56:02 CEST] <fa0> urxvt -g 150x40 -e ffmpeg -i "$i" -vcodec copy -acodec aac -ar 48000 -ab 133k -af volume=15dB "$OUTPUT/${i%.*}.mp4" [06:56:19 CEST] <fa0> 99.9% off all I do LOL [06:56:24 CEST] <fa0> off/of... [06:56:35 CEST] <furq> you can often use replaygain for that [06:56:38 CEST] <furq> depends what player you're using [06:56:42 CEST] <furq> mpv definitely supports it [06:57:01 CEST] <fa0> This is when watching on the HDTV [06:57:14 CEST] <furq> ah [06:57:28 CEST] <fa0> never thought about replaygain [06:57:41 CEST] <fa0> but this works easy enough [06:58:10 CEST] <fa0> do you think those compile flags I had for 3.1x I just showed are still good for 3.2? [06:58:23 CEST] <furq> http://vpaste.net/jDUue [06:58:26 CEST] <furq> that's all i build with [06:58:53 CEST] <fa0> hmm [06:59:06 CEST] <furq> maybe lame as well [06:59:27 CEST] <fa0> Well to be honest, not sure what you know of Slackware, this is taken from alienbob's slack build script I've been hacking on; [06:59:29 CEST] <fa0> http://www.slackware.com/~alien/slackbuilds/ffmpeg/build/ [06:59:50 CEST] <fa0> So he's the one that made it with all those build options, and I'm no real pro to know the reasons why hehe [07:00:24 CEST] <fa0> But on the URL I just showed, it's somewhat dated, so I re did it for the 3.1x [07:00:48 CEST] <fa0> I guess for now until someone says otherwise I'll keep it as is... [07:00:49 CEST] <furq> i use my own build script on desktop and freebsd ports on my nas, so it's easy enough to pick what i want [07:00:58 CEST] <furq> there's no harm in having everything other than build time [07:01:31 CEST] <furq> libzimg is probably the only thing i actually use that you don't have [07:01:43 CEST] <furq> https://github.com/sekrit-twc/zimg/ [07:01:58 CEST] <fa0> If you looked at that .SlackBuild script he made, I like how it just compiles against everything at run time and no need to have it all installed [07:02:45 CEST] <furq> fwiw libmp3lame isn't non-free [07:02:46 CEST] <furq> it's gpl [07:03:01 CEST] <fa0> Can't say I know much about zimg, if I'm doing some basic encode jobs is this being taken advantage of, used? [07:03:18 CEST] <furq> you can use it instead of swscale [07:03:39 CEST] <furq> if you're not resizing stuff or doing colourspace conversions then it's not used [07:03:46 CEST] <fa0> ok [07:04:26 CEST] <fa0> hmm not sure why he has lame as nonfree then... [07:05:43 CEST] <fa0> libfdk-aac is non-free? [07:05:55 CEST] <furq> yeah [07:06:26 CEST] <furq> https://github.com/mstorsjo/fdk-aac/blob/master/NOTICE#L51-L58 [07:06:30 CEST] <furq> that clause is gpl incompatible iirc [07:06:36 CEST] <fa0> actually lame is LGPL [07:06:41 CEST] <furq> close enough [07:06:44 CEST] <fa0> hehe [07:06:59 CEST] <fa0> sheesh to be honest I haven't been paying attention to this stuff in years [07:07:13 CEST] <furq> you've not been missing much [07:07:33 CEST] <fa0> So to be technically correct, I'd remove lame from that non-free section and just add it to the ffmpeg compile flags section? [07:07:38 CEST] <furq> yeah [07:07:42 CEST] <fa0> ok thanks [07:08:22 CEST] <furq> the only gpl incompatible libs are cuda, cuvid, libnpp, fdk and openssl [07:09:35 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L5069-L5090 [07:10:59 CEST] <fa0> ok [07:30:09 CEST] <fa0> thanks for the help furq [07:38:38 CEST] <fa0> WoOt got the compile script reconfigured and it compiled and here's the options; [07:38:40 CEST] <fa0> http://dpaste.com/3JE46R1 [07:38:49 CEST] <fa0> looking good, thanks again, I'm happy :) [07:40:22 CEST] <fa0> later... :) [09:26:57 CEST] <k_sze[work]> What's the surest way to probe the version of the ffmpeg command? [09:27:16 CEST] <k_sze[work]> I mean programmatically, something I can extract and do a simple comparison of in a bash script. [09:28:26 CEST] <k_sze[work]> Is the output of `ffmpeg -version` supposed to be machine parsable? [09:45:06 CEST] <relaxed> k_sze[work]: ffmpeg -version | awk '/^ffmpeg/ {print $3}' [09:45:14 CEST] <relaxed> would that work? [09:45:53 CEST] <k_sze[work]> let me try [09:46:36 CEST] <k_sze[work]> hmm, maybe [09:46:51 CEST] <k_sze[work]> let me try another ffmpeg verison [09:47:19 CEST] <k_sze[work]> oh, btw [09:47:24 CEST] <k_sze[work]> since when was the 'n' dropped? [09:47:47 CEST] <k_sze[work]> e.g. back then I see "n2.5.3", now I only see "3.1.5" [09:49:17 CEST] <relaxed> ffmpeg -version | awk '/^ffmpeg/ {sub(/n/,"");print $3}' [09:50:19 CEST] <relaxed> ^^ should remove the "n" from the version [09:50:46 CEST] <sopparus> anyone know if rtmpdump is involded in parsing m3u8? in this case for kodi [09:52:36 CEST] <relaxed> k_sze[work]: er, change "sub" to "gsub" [11:01:14 CEST] <sopparus> anyone knows hat ffmpeg[45A153A0]: [tls] error:00000000:lib(0):func(0):reason(0) means? [11:01:54 CEST] <flux> no, but it would seem like an instance of the famous "Error: Success".. [11:03:50 CEST] <sopparus> :) [11:08:08 CEST] <jkqxz> sopparus: That message is coming from openssl, which is notoriously helpful. [11:08:21 CEST] <jkqxz> Is something actually going wrong? [11:08:33 CEST] <sopparus> yes, I cant play the file [11:08:38 CEST] <sopparus> its from within kodi actually [11:09:29 CEST] <sopparus> https://valizadeh.se/sassatv/index.m3u8 is the file, works with vlc [11:09:39 CEST] <sopparus> ffmpeg is compiled --enable-openssl [11:09:46 CEST] <sopparus> openssl being libressl in this case [11:24:11 CEST] <jkqxz> It works for me on 3.1 but not on current git. [11:26:22 CEST] <jkqxz> I'm not sufficiently familiar with it to say anything useful about why, though. Maybe make a bug report? Or wait for someone who actually knows how that works here... [11:34:29 CEST] <sopparus> kodi uses 3.1.5 [11:35:32 CEST] <sopparus> did you test with ffplay? [11:37:47 CEST] <jkqxz> Just ffmpeg, using the 3.1 build in debian testing. [11:38:10 CEST] <jkqxz> Ah, which is built against gnutls rather than openssl. [11:38:46 CEST] <sopparus> I see [11:38:53 CEST] <sopparus> sounds like that could be the thing [11:39:38 CEST] <jkqxz> Yeah, that's a much more interesting difference. [11:42:52 CEST] <sopparus> on freebsd the package is compiled with gnutls and it work [11:43:00 CEST] <sopparus> how does it look for you when it doesnt work? [11:43:43 CEST] <BtbN> are you sure ffmpeg is compatible with libressl? [11:43:49 CEST] <jkqxz> Exactly the same error as you have above. [11:44:30 CEST] <sopparus> BtbN, yes https://github.com/LibreELEC/LibreELEC.tv/blob/master/packages/multimedia/f… [11:44:31 CEST] <sopparus> ok [11:44:52 CEST] <sopparus> oh sorry [11:44:54 CEST] <jkqxz> And I am using openssl, not libressl. [11:44:55 CEST] <sopparus> misread question [11:45:00 CEST] <sopparus> hm [11:45:22 CEST] <sopparus> that im not sure of, but there is very little difference. most programs that supports openssl works right away with libressl [11:45:33 CEST] <BtbN> There's a patch on the ML, claiming to make ffmpeg master compatible with libressl [11:45:40 CEST] <BtbN> So I'd guess it currently is not compatible with it. [11:45:43 CEST] <sopparus> hm [11:45:46 CEST] <sopparus> do you have the link? [11:46:05 CEST] <BtbN> https://patchwork.ffmpeg.org/patch/1212/ [11:46:11 CEST] <furq> fwiw you can build the ffmpeg port on freebsd with openssl [11:46:21 CEST] <furq> it's still 2.8 though so it's probably not much use for bug hunting [11:46:51 CEST] <sopparus> thanks [11:46:59 CEST] <sopparus> ill see if I can build libreelec with that patch [11:47:55 CEST] <sopparus> jkqxz, but you have original openssl where it also didnt work right? [11:48:51 CEST] <jkqxz> Yes, (1.0.2). [11:49:54 CEST] <sopparus> ok [11:57:23 CEST] <sopparus> ill try gnutls vs openssl on ubuntu then [12:42:52 CEST] <sopparus> compiled with openssl on ubuntu, same error [12:42:57 CEST] <sopparus> gnutls up next.. [13:16:13 CEST] <sopparus> this computer sure sucks for compiling... [13:20:01 CEST] <iive> ccache might help [13:20:23 CEST] <sopparus> I rarely compile, no big issue [13:20:35 CEST] <sopparus> think im close to done now... :) [13:22:35 CEST] <furq> you could just use the static linux builds if you want to test with gnutls [13:23:12 CEST] <sopparus> but now its the same git version [13:23:16 CEST] <sopparus> same os everything [13:23:26 CEST] <sopparus> only change is gnutls/openss [13:23:28 CEST] <sopparus> l [13:23:39 CEST] <furq> are you running make -j [13:23:46 CEST] <sopparus> no [13:23:51 CEST] <sopparus> ok done [13:24:42 CEST] <sopparus> yep works [13:24:55 CEST] <sopparus> I guess its confirmed then that something goes wrong when using openssl [13:29:59 CEST] <sopparus> note that other programs such as curl and wget linked with openssl works [13:30:09 CEST] <sopparus> on the same site, its nothing special with it [13:32:20 CEST] <sopparus> so should I do a bug report then? [13:43:50 CEST] <sopparus> if only the register on trac wasent broken... :) [13:45:06 CEST] <sopparus> ok it was just really slow [13:53:09 CEST] <sopparus> made one, https://trac.ffmpeg.org/ticket/5915#ticket [13:53:11 CEST] <sopparus> see what happens [15:12:39 CEST] <sopparus> jkqxz, do you think you could post complete output when using openssl linked binary? [15:12:51 CEST] <sopparus> i needed that for the ticket, but I prefer not to compile again.. :) [15:46:09 CEST] <jkqxz> sopparus: I'll add it to the ticket. [15:46:24 CEST] <sopparus> thanks! [15:51:58 CEST] <jkqxz> sopparus: Done. [15:52:06 CEST] <sopparus> thanks alot [18:29:15 CEST] <t4nk465> Hello, I had a small question. Does ffmpeg lose data when it converts rgb to yuv444 colorspace? (Or is it perfectly lossless?). [18:30:17 CEST] <t4nk465> I I used the following command with x264: ffmpeg -i $INPUT -c:v libx264 -qp 0 -pix_fmt yuv444p $OUTPUT [18:31:03 CEST] <t4nk465> and wanted perfectly lossless, but there seems to be some difference, as the framehash of the individual frames does not match the x264 video frames [19:14:46 CEST] <DHE> t4nk465: I don't think it's lossless. colourspace conversion rarely is. I don't think even 8->10 bit conversion and back is guaranteed to be clean [19:22:32 CEST] <c_14> I have achieved a lossless (according to checksums) by converting from iirc rgb to yuv444p16le and back with ffmpeg [19:22:39 CEST] <c_14> But I wouldn't bet on it [19:25:32 CEST] <klaxa> it is theoretically possible, wait... yuv444p16le is 12 samples for 2x2 at 16 bit per sample? [19:27:27 CEST] <c_14> wait, it was rgba to yuva444p16le [19:27:38 CEST] <c_14> so 32bpp to 64bpp and back [19:28:33 CEST] <klaxa> did you use the whole rgba spectrum? [19:29:30 CEST] <c_14> I used testsrc (or smptehdbars) can't remember which [19:33:20 CEST] <sopparus> jkqxz, http://pastebin.com/raw/Tags85Xp [19:33:25 CEST] <sopparus> a libreelec developer made that [19:33:37 CEST] <sopparus> and then it worked [19:33:41 CEST] <sopparus> compiling myself to extra sure [20:31:17 CEST] <jkqxz> sopparus: Right, the server rejects anything before TLS 1.2: <https://www.ssllabs.com/ssltest/analyze.html?d=valizadeh.se>. [20:31:42 CEST] <sopparus> yes, but I removed that as a test [20:31:53 CEST] <sopparus> tried force 1.1, 1.0 [20:31:56 CEST] <sopparus> and no force [20:32:22 CEST] <sopparus> http://vpeter.libreelec.tv/tmp/ffmpeg-tls-1.2.patch here is the patch that applies cleanly [20:32:33 CEST] <sopparus> tested it myself now too, it works [20:36:20 CEST] <jkqxz> Using TLSv1_client_method there goes back a long way. <http://git.videolan.org/?p=ffmpeg.git;a=commit;h=92db95e9ca5f8249e69e5ef7e1…> [20:37:40 CEST] <sopparus> hehe [20:37:58 CEST] <jkqxz> Not sure where the motivation for restricting that came from, but it's certainly worth discussing on the ML. The SSLv23_client_method case should probably be given SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 to block it from using the older protocols. [20:38:00 CEST] <sopparus> are you a dev? do you want to take care/review it or should i send to ML? [20:46:38 CEST] <jkqxz> sopparus: I can do it. [20:46:55 CEST] <sopparus> ok, thanks again [20:47:16 CEST] <sopparus> now I just sent it, but it doesnt seem it got through [20:47:20 CEST] <sopparus> i never registered [20:47:29 CEST] <jkqxz> If you haven't registered it ends up in a moderation queue. [20:47:47 CEST] <sopparus> ok [20:48:14 CEST] <sopparus> it can be removed then [21:03:07 CEST] <sopparus> can I close the stream now or do you want it up for a while for some extra testing? [21:04:56 CEST] <jkqxz> I've sent an email, but it hasn't appeared on the archive yet. Other people might be interested in trying it, though I imagine they can make their own TLSv1.2-only servers if necessary. [21:05:53 CEST] <sopparus> ill keep it up for a while then [21:05:55 CEST] <sopparus> no problem [21:09:29 CEST] <jkqxz> Here you go: <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-October/201918.html>. [21:10:05 CEST] <sopparus> thanks [21:14:25 CEST] <sopparus> if this gets merged which I guess it will be how likely is it that it ends up in 3.1.6? [21:14:32 CEST] <sopparus> i was thinking of kodi17 :) [00:00:00 CEST] --- Sat Oct 29 2016

1 0

ffmpeg-devel.log.20161027
by burek 28 Oct '16

28 Oct '16

[00:13:22 CEST] <atomnuker> jamrial_: huh, I thought url_feof was just forgotten to be removed since it's been more than 2 years [00:13:28 CEST] <atomnuker> oh well [00:14:15 CEST] <jamrial_> atomnuker: it was less than 2 years old back during the last major bump, so it was postponed [00:14:23 CEST] <jamrial_> should be gone in the next [00:18:35 CEST] <jamrial_> atomnuker: i also meant the whole libavformat.v change, not just url_feof [00:19:30 CEST] <jamrial_> stopping exporting all those functions is an abi break [00:20:59 CEST] <jamrial_> if you for example try to run ffserver from 3.1 with libavformat from 3.2, which is a valid scenario, it would crash and burn if you remove those exports [00:21:31 CEST] <jamrial_> although you're also removing ffm de/muxer, mmh [00:21:49 CEST] <jamrial_> guess those can't go until the next major bump either... [00:22:03 CEST] <nevcairiel> the avformat changes should probably be tied to a major bump [00:22:09 CEST] <jamrial_> yeah [00:25:55 CEST] <jamrial_> just remove ffserver and its references in documentation and build system. leave the ffm de/muxers and the ffmpeg_opt.c stuff as is [00:26:44 CEST] <llogan> atomnuker: nit: missed "@item FFM (FFserver live feed) @tab X @tab X" in doc/general.texi [00:27:35 CEST] <jamrial_> llogan: not if the libavformat stuff is going to be left in place :p [00:28:36 CEST] <jamrial_> sucks we forgot about this until the very last minute... [00:28:52 CEST] <llogan> i just saw "delete mode 100644 libavformat/ffmdec.c" and assumed it was going away... missed your "can't go" message [00:31:50 CEST] <atomnuker> jamrial_: so -override_ffserver can't be removed either? [00:33:19 CEST] <jamrial_> it's an ffmpeg.c option, to help "demuxing" ffm files, right? [00:34:32 CEST] <atomnuker> I guess, yeah [00:34:50 CEST] <jamrial_> then yeah, can't be removed until ffm de/muxer are removed [00:36:14 CEST] <jamrial_> someone else with more knowledge about all this ffserver stuff should chime in, anyway [00:38:41 CEST] <llogan> the problem is that there is nobody who knows ffslerver [00:41:02 CEST] <jamrial_> michaelni: ^ would that ffmpeg_opt.c code work or be of use if we remove ffserver but leave ffm de/muxer (since that can't be removed without a major bump)? [00:41:25 CEST] <jamrial_> hell, who knows if it's even working right now after the codecpar conversion... [01:41:38 CEST] <Chloe> does the avfoundation screen capture not work for anyone else on sierra? [01:45:30 CEST] <Chloe> oh no, looks like it was mpv being broken not ffmpeg [01:47:32 CEST] <wm4> yay [01:53:45 CEST] <Chloe> seems backwards :P a git pull + recompile seemed to fix it though [03:23:09 CEST] <cone-045> ffmpeg 03Rodger Combs 07master:f53c26c694c9: lavfi/vf_overlay: support NV12 and NV21 [04:20:13 CEST] <Zeranoe> jkqxz: How goes the QSV stuff? [04:25:57 CEST] <rcombs> looks like I broke autobsf in the segment muxer for some use-cases [04:26:22 CEST] <rcombs> oops [04:26:29 CEST] <rcombs> how can I make tests for this thing [04:39:14 CEST] <cone-045> ffmpeg 03Stephen Hutchinson 07master:bf1439363555: avisynth: fix Planar RGB output [08:16:42 CEST] <rcombs> OK, wrote some tests for segment.c [11:24:58 CEST] <BtbN> that hls playlist indeed looks ok. Did someone break hls? [11:29:42 CEST] <nevcairiel> hls breaks all the time [11:31:43 CEST] <BtbN> granted, the mpegts it points to looks very broken. But it doesn't even seem to try looking at that [12:13:03 CEST] <DHE> the .ts file doesn't appear to start on a proper keyframe boundary. that seems to make my local copy of ffmpeg unhappy... [12:13:24 CEST] <DHE> at least I think so... [14:50:24 CEST] <RiCON> jkqxz: hevc is crashing ffmpeg/mpv [14:52:10 CEST] <RiCON> h264/mpeg2/vc1 are working fine but at least with that sample vc1 is still spamming "[ffmpeg/video] vc1_qsv: A decode call did not consume any data" [14:57:42 CEST] <jkqxz> Hmm. Backtrace for crash? [14:57:42 CEST] <jkqxz> Yeah, VC-1 gives me that spam as well. Demoting the message or a hacky workaround (ignore very small packets?) might be the way to go, but it would be helpful if a VC-1-knowing person (assuming any exist) could have a look at it and determine where the disagreement about the frame boundaries is coming from. [15:53:57 CEST] <RiCON> i'd never installed any sdk explicitely [15:54:09 CEST] <jkqxz> I'm not sure what to do with this. The plugin must have loaded successfully to get there, but then it crashes when you try to use it? [15:59:59 CEST] <jkqxz> Maybe we can call MFXVideoDECODE_Query() before _Init(), but I don't see why that should behave any differently. (It's not like _Init() is documented as invoking undefined behaviour if any of the parameters are incorrect - it even explicitly says that it checks for support.) [16:06:38 CEST] <RiCON> is there any way to change the SDK location? [16:17:43 CEST] <RiCON> the sw plugin is only installed with the sdk, while the hw one with the drivers? [16:19:02 CEST] <nevcairiel> that sounds about right, the sw one doesnt come with drivers [16:26:21 CEST] <RiCON> the sw.dll should actually be found in the PATH, so i'm stumped why it's still trying hw.dll with -load_plugin hevc_sw [16:29:08 CEST] <jkqxz> Put a breakpoint on MFXVideoUSER_Load() and have a look at the uid argument? [16:52:30 CEST] <michaelni> atomnuker, ive a headache today, so really i probably wont do to much on the computer except maybe doing the release as i said yesterday but my oppinion is to not remove ffserver. But whatever you do you should talk with reynaldo who is maintainer of ffserver [16:58:58 CEST] <atomnuker> michaelni: fair enough, I'll apply it some time after the release unless someone else (you or reynaldo) have something to say about the patch on the ML [16:59:31 CEST] <jkqxz> RiCON: Yes, but without the "()". [17:28:58 CEST] <jamrial> if "after thorough deliberation" we decided to drop it and even write a news entry about this, i'm kinda baffled we forgot to actually make it effective [17:29:46 CEST] <atomnuker> blame me for not bothering to make a patch :/ [17:29:59 CEST] <atomnuker> could it say "release 3.3" instead? [17:33:27 CEST] <jamrial> atomnuker: release numbers are not decided until they are made [17:33:27 CEST] <jamrial> it could be 4.0, or 3.3 [17:42:04 CEST] <atomnuker> jamrial: then just append "(delayed for after the release of 3.2)" or similar? [18:04:04 CEST] <atomnuker> jamrial: yeah, that makes good sense, wouldn't have to edit the previous news item [18:04:08 CEST] <atomnuker> (though still someone has to write one, and since usually no one does it I'll wait until after the release and write one) [18:25:57 CEST] <cone-511> ffmpeg 03Stephen Hutchinson 07n3.2:HEAD: avisynth: fix Planar RGB output [20:22:49 CEST] <atomnuker> reynaldo: see what me and jamrial wrote, also since it won't be getting removed in 3.2 but in master and eventually in the release after 3.2 there'll be plenty of chance to hear from people using it, if any [20:27:35 CEST] <reynaldo> atomnuker: Im following the thread and would' rather reply there as needed. My point in case its not clear enough is: move yes but no removal before it happens, the patch fixes nothing and breaks master for anyone using ffserver [20:27:49 CEST] <reynaldo> there are users offering to help as recently as september this year iirc [20:29:16 CEST] <jamrial> reynaldo: why wasn't this brought up when it was discussed, when the news entry patch was sent to the ML, and when it was commited? [20:31:14 CEST] <BtbN> Aparently nobody is willing to maintain ffserver. So the only logical next step is to get rid of it. [20:31:37 CEST] <BtbN> If somebody still wants it, it can be easily recovered from git history [20:31:42 CEST] <reynaldo> jamrial: it was brought up I think [20:32:36 CEST] <wm4> reynaldo: the whole problem with ffserver is that it's extremely intrusive and in its current form has specific code in libavformat [20:32:42 CEST] <jamrial> reynaldo: where? i at least don't see it in the news entry patch thread [20:32:48 CEST] <wm4> so I'm not sure how you'd move that to public API [20:37:28 CEST] <reynaldo> wm4: I know about the problem but I honestly thing the work behind it can be put to some use [20:37:37 CEST] <reynaldo> think/ [20:38:05 CEST] <reynaldo> it is my intention to put time on it, seems michael is willing to help too [20:38:33 CEST] <wm4> well this has been going on for moths... [20:38:38 CEST] <wm4> months even [20:38:53 CEST] <BtbN> there was even some highly motivated guy planning to revive ffserver [20:38:59 CEST] <BtbN> haven't heard of him since [20:39:41 CEST] <reynaldo> BtbN: that was barely a month ago and he wasnt meet with encouragement [20:39:47 CEST] <reynaldo> 2 months maybe [20:40:12 CEST] <reynaldo> wm4: the project for a decade+_ and we are still here ;) [20:40:50 CEST] <reynaldo> besides, I relly like the general idea of having the apps on a separate repo [20:41:04 CEST] <reynaldo> there can be an staging area there for apps that still need porting work [20:41:16 CEST] <reynaldo> (which might help the transition happen faster) [20:41:41 CEST] <atomnuker> reynaldo: then what's the problem with removing it from master and in the meanwhile do the work of putting it in a separate repo [20:41:43 CEST] <reynaldo> I just oppose the removal while that is not in place [20:41:59 CEST] <reynaldo> atomnuker: you just dont do things that way, you are breaking master without a solution [20:42:02 CEST] <reynaldo> while would you do that [20:42:02 CEST] <atomnuker> that way thing sill move faster, and we could finally work on improving lavf and removing the ffm muxer/demuxer [20:42:06 CEST] <reynaldo> whats there to gain [20:42:07 CEST] <reynaldo> ? [20:42:24 CEST] <atomnuker> lavf [20:42:27 CEST] <reynaldo> atomnuker: looks at my "staging tree" idea over there ^ [20:42:46 CEST] <reynaldo> looks/look/ [20:42:59 CEST] <atomnuker> besides, master may be broken but the most up to date release wouldn't be [20:43:24 CEST] <atomnuker> and no one in their right minds would use an unstable release for a serious day to day streaming [20:43:26 CEST] <reynaldo> theres no justification in place, you are breaking master for no apparent gain [20:43:41 CEST] <wm4> how come the pressure is always on those who don't want to keep ffserver, instead of those who want to keep it [20:43:47 CEST] <reynaldo> atomnuker: we are talking ffmpeg, there are indded ppl using master [20:43:49 CEST] <atomnuker> reynaldo: breaking master so we can start improving libavformat [20:44:03 CEST] <atomnuker> otherwise we're stuck and we're never going to do anything [20:44:09 CEST] <ubitux> i'm against moving the tools outside the repository for now [20:44:15 CEST] <ubitux> it will make life harder for the merges [20:44:16 CEST] <jamrial> broken how? [20:44:19 CEST] <ubitux> which is already a PITA [20:44:26 CEST] <ubitux> btw, ffserver is hindrance to the merge too [20:44:38 CEST] <ubitux> so i'm fine with having it dead in another repository [20:44:45 CEST] <atomnuker> ubitux: that's why we start doing them one at a time, with ffserver which doesn't have an analogue in libav [20:44:49 CEST] <reynaldo> so the merges, libav merges ? [20:44:53 CEST] <reynaldo> ubitux ^ [20:44:56 CEST] <ubitux> yes libav merges [20:45:20 CEST] <reynaldo> now thats a real argument for the rmeoval of ffmpeg :) [20:45:34 CEST] <reynaldo> "libav did it before" [20:45:38 CEST] <mateo`> oh come on [20:45:43 CEST] <reynaldo> ffserver, I mean [20:45:46 CEST] <wm4> durr [20:45:46 CEST] <ubitux> it's not about copying libav [20:45:53 CEST] <ubitux> it's about making the merges work [20:46:12 CEST] <ubitux> i'm not even sure ffserver still works with the move to codecpar [20:46:19 CEST] <reynaldo> I cant continue this right now, will be around latter though and keep an eye on the thread [20:46:26 CEST] <reynaldo> thanks for keeping it cool guys [20:46:28 CEST] <jamrial> this discussion is months late... [20:46:35 CEST] <ubitux> we're not going to keep ffserver reynaldo [20:46:41 CEST] <reynaldo> hope we can make it to the end without sting rays [20:46:44 CEST] <ubitux> the discussion already happened [20:46:50 CEST] <wm4> indeed we've already decided ffserver is to be removed [20:46:56 CEST] <wm4> (unless someone "updates" it) [20:47:02 CEST] <wm4> (which didn't happen) [20:47:14 CEST] <reynaldo> leaving but can someone point here to when was that decided? [20:47:19 CEST] <reynaldo> leaving for real now [20:47:49 CEST] <ubitux> look at the news [20:47:49 CEST] <ubitux> on ffmpeg.org [20:47:49 CEST] <jamrial> reynaldo: i replied with a couple links [20:47:51 CEST] <jamrial> there were discussion also here on irc, months ago as well [21:05:21 CEST] <DHE> No patch suggestions, or should I just post it to the mailing list to see what people think? [21:10:08 CEST] <jamrial> DHE: can't that be achieved with the option added in commit 4493390? [21:10:21 CEST] <jamrial> in any case, sending the patch to the ml is always the best idea [21:29:45 CEST] <DHE> jamrial: That's for per-filter threads. but the filter pipeline as a whole has its own thread count and that's where it hurts [21:33:45 CEST] <DHE> and I've experimented and wasn't able to find a way to get option into the pipeline [21:46:55 CEST] <jamrial__> DHE: as i said, send it to the ml. it will get more exposure there [00:00:00 CEST] --- Fri Oct 28 2016

1 0

ffmpeg.log.20161027
by burek 28 Oct '16

28 Oct '16

[00:04:20 CEST] <Phi> I keep getting non-existing PPS 0 referenced [00:04:26 CEST] <Phi> any way to check if PPS 0 exists? [00:08:20 CEST] <Phi> You've earned the "Tumbleweed" badge (Asked a question with zero score, no answers, no comments, and low views for a week) for "FFMPEG RTSP stream to MPEG4/H264 file using libx264". [00:38:26 CEST] <Phi> furq: any idea how to detect PPS 0 [01:36:58 CEST] <Phi> anyone alive? [01:37:21 CEST] <Phi> https://bpaste.net/show/3c788ccfd33e [01:46:47 CEST] <Phi> really? [01:46:50 CEST] <Phi> No one is actually online? [01:47:04 CEST] <Phi> well, apart from c_14 who's probably trolling me [02:03:25 CEST] <DHE> it's a rather narrow niche the channel deals with. there's not as much expertise with the libs as there is with the commandline. calm down and be patient [04:04:56 CEST] <Phi> that's actually odd tho [04:05:07 CEST] <Phi> and I'm perfectly calm :p [04:20:10 CEST] <TheXzoron> yo I'm having a problem with my record script where the last 3 seconds of audio get cut off when I stop the recording https://dpaste.de/wmsx [04:20:28 CEST] <TheXzoron> example but the site appears down so I'm reupping it someplace else https://a.desu.sh/uralmp.mp4 [04:22:50 CEST] <TheXzoron> https://a.pomf.cat/uceeeb.mp4 [04:49:09 CEST] <Zeranoe> TheXzoron: Why not specify the record time? [04:52:01 CEST] <TheXzoron> what do you mean? [04:52:16 CEST] <TheXzoron> this is to be called upon for random records [04:54:48 CEST] <TheXzoron> is this unavoidable without a set endpoint then? [05:31:05 CEST] <Mad7Scientist> TheXzoron, how are you terminating ffmpeg? [05:38:50 CEST] <babadoc> hey guys [05:39:12 CEST] <babadoc> anyone know anything about ffmpeg and ASF Extended Content Encryption? [05:39:30 CEST] <babadoc> is there some package in ffmpeg that can remove those? [05:42:41 CEST] <babadoc> any paid package that can accomplish this [06:09:45 CEST] <thebombzen> hey, I'm looking to extract the contents of a chapter from a matroska file I have. Specifically I want to isolate chapter 0:1. Transcoding it is fine. is there a way to do this without using ffprobe and copy/pasting the timestamps? [06:17:52 CEST] <TAFB> I have an aac audio file I want to loop over a live rtmp (video only) stream, possible? [06:19:44 CEST] <thebombzen> TAFB: if you're sending the AAC file to the RTMP streaming server with ffmpeg, you can use ffmpeg -loop -1 -1 input.m4a [06:19:54 CEST] <thebombzen> sorry I mean ffmpeg -loop -1 -i input.m4a [06:21:30 CEST] <thebombzen> I apologize again haha. It's -loop 1 with ffmpeg, but -loop -1 with ffplay. [06:21:53 CEST] <TAFB> Option loop not found. [06:22:14 CEST] <Phi> a:loop? [06:22:36 CEST] <furq> loop is a demuxer-specific option [06:22:54 CEST] <furq> -stream_loop -1 should work with anything iirc [06:23:32 CEST] <thebombzen> really? [06:23:47 CEST] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#image2-1 [06:23:52 CEST] <thebombzen> I'm behind on the times haha [06:24:01 CEST] <thebombzen> cause it works in ffplay with -1 [06:25:18 CEST] <thebombzen> by "it didn't work" I mean the output froze at some point. of a sequence of images. [06:26:02 CEST] <TAFB> ffmpeg -stream_loop -1 -i musictest.flac -c copy test.flac [06:26:04 CEST] <TAFB> ^^ works [06:26:18 CEST] <TAFB> now how do I merge it with my rtmp stream? [06:27:01 CEST] <thebombzen> well that depends on how you're broadcasting it. [06:27:14 CEST] <TAFB> 1 sec for command [06:27:41 CEST] <furq> ffmpeg -stream_loop -1 -i musictest.flac -c:a aac -f flv rtmp://abc.de:1935/live/fgh [06:27:53 CEST] <furq> er [06:28:00 CEST] <furq> you probably want -re as well [06:28:02 CEST] <TAFB> I have an incoming rtmp stream (video only) that I need to inject the audio into [06:36:56 CEST] <TAFB> If I do "ffmpeg -stream_loop -1 -i musictest.flac -i input.mp4 -c:a aac test.mp4" then it puts the audio over the video, but the audio doesn't repeat, just plays once :( [06:43:46 CEST] <TAFB> could I use concat to do it? [06:45:08 CEST] <thebombzen> how does using -ss interact with -r as an input option? [07:10:53 CEST] <squ> -r is framerate? [07:16:06 CEST] <SouLShocK> yes [07:22:50 CEST] <squ> then it doesn't interact with -ss [07:28:59 CEST] <TAFB> i got it working :) One ffmpeg to play the video over udp, one ffmpeg to stream_loop the audio over udp, and one ffmpeg to combine the two udp and stream it as rtmp :) works great. [07:35:39 CEST] <TAFB> if anyone would like to checkout the result :) I promise good tunes! http://www.skyviewelectronics.com/zombie-walk-brooklin [07:36:28 CEST] <squ> better paste config, ffmpeg commands to setup it [07:37:05 CEST] <squ> and this page doesn't show anything [07:37:55 CEST] <TAFB> the one I linked? if it isn't buffering just click the seek bar button just a hair ahead of behind :) [07:38:46 CEST] <squ> it loaded [07:38:56 CEST] <squ> took 2 minutes to load [07:39:12 CEST] <TAFB> what country are you in? [07:39:53 CEST] <TAFB> oh crap, I forgot our webserver is on the same internet as the upload streaming!!! hmmmmm. could be bad :( [07:40:07 CEST] <squ> I know that song [07:40:10 CEST] <TAFB> 10mbps upload internet, video/audio stream is probably around 7mbps :( [07:40:50 CEST] <TAFB> it's got a really great halloween themed playlist :) [07:42:06 CEST] <squ> can you put one song for me [07:42:33 CEST] <TAFB> sorry, they are all pre-recorded :( [07:47:12 CEST] <squ> downloading your stream takes 1.2 mb/s [07:47:39 CEST] <TAFB> it downloads it in 60 seconds chunks so the speed might not be accurate [07:48:25 CEST] <squ> exactly 1.2 mb/s [07:49:20 CEST] <TAFB> it's cbr bitrate (both video and audio) so it'll always be exactly the same :D [07:52:11 CEST] <squ> TAFB: http://i.imgur.com/nggOOXF.png [07:52:47 CEST] <squ> that's your graph [07:52:57 CEST] <TAFB> nice nice :) it's streaming from my server in new york, not sure what internet connection it's got [07:53:54 CEST] <squ> can you play with buffering parameters and we see how graph will change [07:54:23 CEST] <squ> how much of 1.2 mb/s users server can do? [07:54:37 CEST] <TAFB> not sure, I never use this server for nothin so dunno capacity [07:54:54 CEST] <TAFB> if it gets too overloaded I'll throw it on my one in montreal (canada), 10 gigabit upload dedicated :) [07:55:24 CEST] <TAFB> i can't mess with the stream much right now, just e-mailed out the link to a bunch of peeps to test [07:55:35 CEST] <squ> I see [07:55:53 CEST] <squ> let's wait it starts dropping users [07:56:01 CEST] <TAFB> thanks for testing it for me :D [07:57:56 CEST] <squ> just saw a car [07:57:59 CEST] <squ> :) [07:58:10 CEST] <TAFB> nice! almost 2am here, small town, not much action [07:58:50 CEST] <squ> yep no action at all [07:59:55 CEST] <TAFB> you can occasionally see a leaf fall off a tree [08:00:00 CEST] <squ> my time is 8:59:19, your time is 01:52:11 [08:00:14 CEST] <squ> 7 minute lag [08:00:14 CEST] <TAFB> wow! I should get some sleep [08:00:29 CEST] <TAFB> it might be drifting a bit, set for 5 minute buffer [08:00:50 CEST] <TAFB> (1 min encoding, 1 min streaming, 3 min in the flash player) [08:01:03 CEST] <squ> which of the trees has most probability for seeing falling leaf? [08:01:11 CEST] <squ> so I can focus on it [08:01:27 CEST] <TAFB> the dark one just behind the yellow sign [08:01:42 CEST] <squ> on the left? [08:01:44 CEST] <TAFB> yep [08:02:01 CEST] <squ> ok, I'm focused and full attention for action [08:02:01 CEST] <TAFB> it's fall here, so all the leaves are falling off :) [08:02:37 CEST] <squ> can you shake that tree for me [08:02:48 CEST] <TAFB> that's my work, I'm at home at the moment :) [08:20:49 CEST] <squ> TAFB: do you know about new ffmpeg encoders which allow encoding on gpu [08:21:11 CEST] <TAFB> I do not, never done gpu encoding except with OBS [08:21:34 CEST] <squ> 1 min encoding can be reduced to 10 seconds [08:21:49 CEST] <squ> have a look at nvenc [08:21:58 CEST] <TAFB> the live stream quality was worse when using the GPU encoding [08:22:14 CEST] <TAFB> like it uses "ultrafast" preset or something, I usually use medium or slow with my monster CPU's [08:22:30 CEST] <squ> but you can tweak parameters for gpu enconding same as for cpu encoding [08:22:45 CEST] <TAFB> yep, but always uses ultrafast preset [08:23:06 CEST] <squ> look at its manual, you can choose quality there [08:23:08 CEST] <TAFB> to achive the same quality with gpu encoding it was 1.5x the bandwidth [08:29:16 CEST] <squ> TAFB: lost connection [08:29:40 CEST] <TAFB> still workin for me :) [08:30:18 CEST] <squ> 9 minute lag [08:30:41 CEST] <TAFB> still 6 minutes for me. you can click your seek bar a bit ahead :) [08:30:58 CEST] <squ> no, I like that song [08:31:01 CEST] <squ> :) [08:31:05 CEST] <TAFB> lol [08:31:27 CEST] <TAFB> 1hr20mins of music then repeats [08:31:33 CEST] <squ> :( [08:31:36 CEST] <squ> not much [08:31:58 CEST] <TAFB> it's the "top 25 halloween songs" :D [08:32:37 CEST] <squ> did you know signal from Mars to Earth takes 10 minutes [08:33:14 CEST] <TAFB> not bad at all [08:33:50 CEST] <squ> I thought it was bad, before your live broadcast with 9 minute lag [08:34:23 CEST] <TAFB> hahaha! I'm using HLS streaming, normally only has a 9 second buffer, but it never ever works for me. Supposed to only use 3 second chunks too, not my 60 second :D [08:36:39 CEST] <squ> graph changed [08:37:09 CEST] <squ> or no :) [08:37:53 CEST] <TAFB> the buffering will change a bit when it gets to 2 hours [08:41:49 CEST] <TAFB> love the song at 2:35:50 [08:42:43 CEST] <squ> not yet started here [08:42:54 CEST] <squ> cranberries zombie here [08:43:01 CEST] <TAFB> also good song [08:44:05 CEST] <squ> I've read how wall street traders used latency lag to gain profits [08:44:40 CEST] <squ> some companies located far in latency terms received outdated data later than others [08:45:13 CEST] <squ> those who received it faster were kinda in future compared to ones with later data [08:46:13 CEST] <squ> there was a movie about it [08:54:24 CEST] <TAFB> I think it repeated at 2:28:20, yay, it works!!!!!!! [08:54:35 CEST] <TAFB> 2:48:20 [09:53:13 CEST] <squ> TAFB2: what song was at 3:41 [10:39:26 CEST] <admineg> Hi [10:42:19 CEST] <admineg> How to in install ffmpeg in Manjaro Linux [12:43:18 CEST] <serard_> hello [12:43:48 CEST] <serard_> is it possible to get informations from one mp4 file (that work on my raspi) to convert another file with very same infos ? via command line (like automating it) [12:59:07 CEST] <squ> isn't that called copying [12:59:26 CEST] <squ> command line would be: cp file1 file2 [14:13:17 CEST] <avalon_> hello, guys [14:13:49 CEST] <avalon_> i have one simple question: Is there a way to get filename from concat demuxer for use in drawtext ? [14:14:07 CEST] <avalon_> actually from -f concat -i list.txt videos list [14:15:36 CEST] <DHE> you want to get the filename currently being processed in order to draw it on screen? [14:15:45 CEST] <avalon_> yes [14:15:58 CEST] <DHE> I strongly suspect you can't... [14:16:12 CEST] <avalon_> there is no way? [14:16:31 CEST] <DHE> not without, say, re-processing videos so each has its own label on it, then concatenate those [14:16:49 CEST] <avalon_> :( [14:17:06 CEST] <DHE> if you're willing to get messy, there's this: https://ffmpeg.org/ffmpeg-filters.html#concat [14:17:31 CEST] <avalon_> i did try lot of docs [14:17:35 CEST] <avalon_> but no luck [14:19:00 CEST] <furq> you might as well use the concat filter if you're already reencoding [14:19:33 CEST] <avalon_> okay, i'll try that [14:19:41 CEST] <furq> it's less flaky at the cost of being slightly more annoying to automate [14:20:42 CEST] <avalon_> i think i already reencoded all that music videos prev [14:20:46 CEST] <DHE> the concat filter would let you do a drawtext for each source independently, then concatenate in the filter pipeline [14:20:47 CEST] <avalon_> previously [14:21:04 CEST] <furq> well you can't use drawtext without reencoding [14:21:11 CEST] <avalon_> oh [14:21:15 CEST] <furq> or any filters [15:38:42 CEST] <TAFB2> with my unstable internet connection rtmp NEVER works [15:38:48 CEST] <furq> granted i'm serving hls through an rtmp server so the hard work is already done [15:38:49 CEST] <TAFB2> HLS on the other hand, flawless 24/7 [15:39:12 CEST] <TAFB2> ahhh, hls through rtmp server, nice. [15:39:15 CEST] <TAFB2> might give that a go for closer to "live" [15:41:29 CEST] <TAFB2> some projects 3 minutes isn't acceptable [15:46:02 CEST] <furq> well if your upstream is the problem then that won't help [15:46:02 CEST] <furq> unless you mean it's an issue for watching the stream [15:46:02 CEST] <TAFB2> upstream problem is completely solved by HLS :D [15:46:02 CEST] <furq> well yeah it's an rtmp server that remuxes to hls for output [15:46:02 CEST] <furq> you still have to send it an rtmp stream [15:46:02 CEST] <TAFB2> ohhh, I thought you meant hls to rtmp, not the other way around, wouldn't work for me then :( [15:46:02 CEST] <furq> the nice thing is that you can provide an rtmp link for people who have mpv and don't want to be 30 seconds behind [15:46:02 CEST] <TAFB2> alright, I'm off to work :) If you find a good player that works with that .m3u8 link I gave ya let me know so I can use it :) [17:24:33 CEST] <sopparus> TAFB2, awesome. using your cam with acdc to test [17:24:33 CEST] <sopparus> almost zero cpu usage and all is well [18:09:26 CEST] <alienz> I'm using -tee to push a stream back out to rtmp endpoints and getting a weird pause where the speed is 1x but it seems to freeze up and then dump all the frames quickly all at once [18:09:26 CEST] <alienz> not seeing an excessive CPU or memory usage, under 10% overall, curious if anyone has seen anything similar [18:13:30 CEST] <BtbN> alienz, what's the source? [18:14:10 CEST] <alienz> @BtbN another RTMP stream. I actually [18:14:30 CEST] <BtbN> bursts sounds like hls or dash or something like that. [18:15:13 CEST] <BtbN> if the overall framerate is normal, I wouldn't worry about it [18:16:15 CEST] <alienz> I actually ran the command on a slightly newer machine and it runs flawlessly. [18:16:19 CEST] <alienz> Yeah I wasn't too worried until someone showed me the output and it pauses and then all of sudden plays back in like 2x speed until it catches up [18:16:41 CEST] <BtbN> Does just playing the original stream behave the same? [18:17:27 CEST] <alienz> BtbN: original stream looks totally fine. Definitely on the re-encode. [18:19:21 CEST] <alienz> Actually might be the periscope endpoint I just added. It's just an RTMP but something must be funky with it because I remove it an the other endpoints start behaving again [18:19:32 CEST] <BtbN> yes, ffmpeg in itself is strictly single threaded. So all the outputs are processed in sequence for every packet going out [18:19:32 CEST] <BtbN> So if one of them is slow, it will mess with all the others [18:19:32 CEST] <BtbN> Just use multiple ffmpeg processes, one per destination. [18:20:07 CEST] <alienz> BtbN: thanks, I'll give that a try. Thanks for helping out, much appreciated [18:40:53 CEST] <alienz> BtbN: definitely a persicope issue, guessing their server isn't accepting the packets fast enough [18:41:05 CEST] <BtbN> It might just be enforcing their bitrate constraints, so it doesn't read faster than it has to [19:51:02 CEST] <alienz> BtbN: oooo good point [20:35:27 CEST] <Substring> evening guyz [20:36:22 CEST] <Substring> i'm trying to use the h264_omx encoder for the pi, but most of times the result is just ugly. I also don't know which "options" are available with that encoder. How can i find them ? [20:50:55 CEST] <DHE> Substring: ffmpeg -h encoder=h264_omx (or whatever the -c:v parameter is for that codec) [20:51:09 CEST] <Substring> that's the good one [20:51:14 CEST] <Substring> thank you DME [20:51:18 CEST] <DHE> note that the generic encoder options like -b:v will not be listed here, just the codec-specific stuff [20:56:29 CEST] <Substring> DHE, thank you ... it hardly has any option ... too bad [20:56:58 CEST] <DHE> so you probably have to use the standard parameters, like -b:v to set the bitrate [20:57:45 CEST] <Substring> ok, will give it asap [20:58:02 CEST] <DHE> ... you're not setting the bitrate are you? [21:17:22 CEST] <Elronnd> I want to get everything *after* the first 12 seconds of an audio file. How would I accomplish this? [21:17:47 CEST] <c_14> ffmpeg -ss 12 -i audio -c copy outfile [21:18:57 CEST] <Elronnd> thanks [00:00:00 CEST] --- Fri Oct 28 2016

1 0

ffmpeg-devel.log.20161026
by burek 27 Oct '16

27 Oct '16

[00:04:33 CEST] <ubitux> what's the status of qsv? is it going to be applied? [00:23:25 CEST] <nevcairiel> still issues w ith current patch [02:11:43 CEST] <cone-567> ffmpeg 03Tobias Rapp 07master:03a6feb2137d: fate: Add MXF D10/DNXHD/DV25 probe tests [02:29:04 CEST] <cone-567> ffmpeg 03Suman- 07master:a81494b60337: lavf/flvdec: init AVPacket::pos to FLVTAG offset [03:25:49 CEST] <cone-567> ffmpeg 03Michael Niedermayer 07master:20182e79f9c2: doc/APIchanges: Fill in some missing things [05:16:07 CEST] <rcombs> https://patchwork.ffmpeg.org/patch/1176/ where's durandal_1707 anyway [08:26:15 CEST] <durandal_1707> michaelni: how many opw applicants do we have right now? [11:57:41 CEST] <michaelni> durandal_1707, 3, you can see them at https://outreachy.gnome.org/?q=manage_projects&prg=7&o=96 [13:22:48 CEST] <durandal_1707> michaelni: so we have money to fund only one student? [13:25:31 CEST] <michaelni> durandal_1707, yes, but outreachy might fund a 2nd one if we have 2 we want to accept. [13:33:18 CEST] <durandal_1707> michaelni: all they have their qualification task? [13:36:15 CEST] <durandal_1707> durandal_1707: i had been contacted by one of student, interested in working on xpm encoder [13:37:04 CEST] <durandal_1707> so how it develops, i may give student more work to do, like xpm decoder [13:37:19 CEST] <durandal_1707> michaelni: ^ [13:46:51 CEST] <michaelni> durandal_1707, 2 are doing qualification tasks according to: https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12-Qualis [13:47:07 CEST] <wm4> shouldn't a xpm encoder be like 10 lines of code (not including boilerplate) [13:50:39 CEST] <michaelni> durandal_1707, yes you tell a student what (s)he should do and then decide if (s)he is qualified or not / if you want to mentor her/him .. [13:52:35 CEST] <durandal_1707> wm4: its more than that, its about picking all available colors in image efficiencly [13:53:26 CEST] <durandal_1707> its about understanding how things works [13:53:29 CEST] <wm4> wouldn't it just accept pal8 [13:53:50 CEST] <durandal_1707> wm4: pal8 is dumb stupid, this is about more [13:53:54 CEST] <wm4> ? [13:54:24 CEST] <michaelni> s/student/applicant/ [14:04:11 CEST] <michaelni> durandal_1707, also if we want to ask outreachy for funding a 2nd student that should be marked in the web interface by 27th (aka tomorrow) [14:05:21 CEST] <michaelni> durandal_1707, the choice for who to accept of the 3 applicants must be done by 3rd nov at the latest [14:07:44 CEST] <durandal_1707> michaelni: and end time for qualification task to be accepted? [14:09:41 CEST] <michaelni> durandal_1707, your choice but the deadline we have to make a choice is 3rd nov. outreachy tends to be much more tolerant than google though ith deadlines so theres a chance but not certain that we might still be able to adjust it a day later or so [14:10:56 CEST] <durandal_1707> well i guess, I will just wait what applicant will contribute [18:56:41 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:25ab1a65f3ac: avcodec/dvdsubdec: Fix buf_size check [19:27:48 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:ded5c885281a: configure: Remove --enable-incompatible-libav-abi from the help output [19:27:49 CEST] <cone-568> ffmpeg 03Vodyannikov Aleksandr 07master:9445e7e6d562: swresample/rematrix: Fix float part of swr_set_matrix() [19:40:32 CEST] <cone-568> ffmpeg 03Michael Behrisch 07master:c5ac86256bd9: lavu: remove comma at final enumeration items to fix pedantic warnings [19:48:24 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:4045a8d73e81: doc/patchwork: Document the patchwork states [19:48:25 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:d88a6bedb9bc: avformat/isom: Fix old API regression with exporting max bitrate [19:48:26 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:e936c8d176ef: avformat/utils: Discard huge timestamps which would cause overflows if used in basic computations [20:12:21 CEST] <wm4> michaelni: you can't push such changes without review [20:12:40 CEST] <wm4> who would even dare to push this without reviews [20:12:58 CEST] <wm4> well I guess technically it's ok [20:13:03 CEST] <wm4> you waited 3 days or so [20:13:10 CEST] <michaelni> wm4, which commit ? [20:13:14 CEST] <wm4> actually a month [20:13:19 CEST] <wm4> "avformat/utils: Discard huge timestamps which would cause overflows if used in basic computations" [20:13:40 CEST] <JEEB> at least it's int64 min [20:13:52 CEST] <JEEB> I first read that one as uint [20:13:57 CEST] <JEEB> and raised my eyebrows [20:13:58 CEST] <wm4> if I understand this right, this suddenly adds an undocumented allowed range to timestampos [20:14:04 CEST] <wm4> which is applied only at this point [20:14:09 CEST] <wm4> and which also is arbitrary [20:14:50 CEST] <wm4> not really what you'd expect - I probably assumed that this ignores the timestamps only for the purpose of utils.c calculations or something [20:15:09 CEST] <wm4> and just because a patch is ignored it's not ok [20:15:49 CEST] <wm4> ok back to not caring [20:20:12 CEST] <michaelni> wm4, a patch ignored for a week is ok, litterally so, its written that way in the developer policy. "1 week for big patches" and its not even big and i waited a month [20:21:18 CEST] <michaelni> that said i can revert if people want me to revert, is no problem for me [20:24:20 CEST] <wm4> which is why I said "technically ok" [20:24:42 CEST] <wm4> so what happens if I don't use libavformat for demuxing and e.g. feed libavfilter with huge timestamps? [20:26:31 CEST] <michaelni> the patch was only intended to cut the timstamps for libavformat down from the a little less than 64bit may before to half that instead of lots of checks everywhere, i didnt intend to assume anything outside libavformat [20:27:18 CEST] <michaelni> libavfilter certainly has issues with larger timestamps too but that patch was not intended to fix that [20:28:42 CEST] <michaelni> if people dislike that patch ill revert or if theres a actual file needing timestamps in the range ill revert too, is there anything using such large timestamps ? [20:29:29 CEST] <wm4> it's hard to argue for reverting a patch that fixes "some" (unspecified number) of overflow issues, I'm just asking for cleaner practices [20:29:49 CEST] <wm4> instead of implicitly suddenly constraining the range of valid timestamps [20:30:49 CEST] <michaelni> ok, ill revert, lets restar this cleanly after 3.2 [20:32:51 CEST] <wm4> I'm not forcing you [20:35:29 CEST] <BtbN> Seems like a ok solution to me. [20:35:39 CEST] <BtbN> Losing essentialy one bit isn't that horrible [20:35:50 CEST] <BtbN> you'd still need one hell of a long video to get there [20:35:59 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:c92f55847a3d: avcodec/dvdsubdec: Fix off by 1 error [20:36:00 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:38e5a4f3bbe9: Revert "avformat/utils: Discard huge timestamps which would cause overflows if used in basic computations" [20:37:30 CEST] <wm4> BtbN: video length isn't really an argument [20:37:38 CEST] <wm4> timestamps could for example reflect some sort of clock time [20:37:48 CEST] <wm4> or just start at an arbitrary offset [20:38:16 CEST] <nevcairiel> mpegts broadcast recordings start at arbitrary high offsets, but of course mpegts is limited to 33 bits so it wont get that high [20:38:19 CEST] <wm4> either handling overflows explicitly or documenting the allowed timestamp range in general would probably be better [20:38:35 CEST] <BtbN> Timestamps larger than 4611686018427387904? [20:38:45 CEST] <nevcairiel> there is no reason not to [20:38:47 CEST] <nevcairiel> its arbitrary [20:39:00 CEST] <BtbN> well, it will eventually run into the limits of 64bit [21:10:01 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:3f3025205ff3: Bump minor versions for 3.2 [21:10:02 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:36ecf30cbc20: doc/APIchanges: add 3.2 Cut marker [21:10:03 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:e84d58761348: Changelog: Add 3.2 [21:10:04 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:1609935b6cbe: Bump minor versions after 3.2 branchpoint to seperate release [21:10:05 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:efa89a841941: Changelog: Add back next marker [21:10:06 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07master:e1b30c8a0109: RELEASE: Update for past 3.2 branch [21:11:54 CEST] <jamrial> michaelni: do you mind if i apply my matroska crc32 fix for 3.2? it didn't get a review yet but i'd like it to be in the release since it's a muxer regression [21:17:37 CEST] <michaelni> jamrial, feel free to apply any patch you like, ill make the release branch in a moment and people can then still backport to it before the release [21:18:42 CEST] <nevcairiel> regressions are generally fine to be fixed in re lease branches [21:19:15 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07release/3.2:HEAD: RELEASE: Update for past 3.2 branch [21:23:24 CEST] <jamrial> michaelni: ok, thanks. will do [21:24:45 CEST] <jamrial> michaelni: are you sure you branched it at the right commit? both version bump commits are now in 3.2 [21:25:03 CEST] <michaelni> jamrial, no iam off by 1 i just noticed too [21:25:14 CEST] <jamrial> ah ok [21:25:22 CEST] <michaelni> ill revert that one in a moment [21:25:45 CEST] <jamrial> ok, will wait for that before pushing my fix [21:27:51 CEST] <cone-568> ffmpeg 03Michael Niedermayer 07release/3.2:660229d64774: Revert "Bump minor versions after 3.2 branchpoint to seperate release" [21:29:39 CEST] <philipl> What's the appropriate version bump for moving a decoder from the old API to the new API (and dropping support for the old API)? [21:31:28 CEST] <jamrial> philipl: minor i guess [21:32:36 CEST] <wm4> "old" API users suddenly won't be able to use the decoder anymore, so it's a breaking change [21:32:51 CEST] <philipl> Except it's crystalhd so no-one cares :-P [21:32:52 CEST] <wm4> though not sure if this counts because the old API is deprecated [21:33:25 CEST] <philipl> yeah, it's technically a breaking change, but I don't think it's what we mean for a major bump to be used for. [21:33:40 CEST] <wm4> (and there's a history of APIs intentionally stopping working even if they're only deprecated...) [21:34:02 CEST] <jamrial> major bump would remove the old api from the tree altogether, not just from a decoder [21:34:24 CEST] <philipl> Ok. minor it is. [21:34:28 CEST] <jamrial> you said cristalhd doesn't work with the old api, right? it's not like you're breaking anything then :p [21:35:13 CEST] <philipl> Well, I did technically get it to where it mostly worked most of the time. [21:35:41 CEST] <philipl> but we can ignore that. [21:53:00 CEST] <jkqxz> RiCON: Another iteration for you: your MPEG-2 stream now works, and H.265 should be in a better state. More testing welcome :) [22:06:19 CEST] <cone-568> ffmpeg 03James Almer 07master:eabbc64728c2: avformat/matroskaenc: fix cue relative position values when CRC32 is enabled [22:06:20 CEST] <cone-568> ffmpeg 03James Almer 07release/3.2:e6f35a9cd849: avformat/matroskaenc: fix cue relative position values when CRC32 is enabled [22:40:11 CEST] <jamrial> Helmut is right, ffserver was scheduled to be removed with this release, and not once we do a 4.0 or a major bump happens [22:42:59 CEST] <cone-568> ffmpeg 03James Almer 07master:7400f6421111: configure: remove missing incompatible_libav_abi references [22:43:00 CEST] <cone-568> ffmpeg 03James Almer 07master:bf709098c9ee: avcodec: remove missing incompatible_libav_abi references [22:43:01 CEST] <cone-568> ffmpeg 03James Almer 07release/3.2:e554c667bd78: configure: remove missing incompatible_libav_abi references [22:43:02 CEST] <cone-568> ffmpeg 03James Almer 07release/3.2:548242d1a1ec: avcodec: remove missing incompatible_libav_abi references [22:44:20 CEST] <atomnuker> jamrial: so is it too late to post a patch to the ML? [22:47:23 CEST] <jamrial> atomnuker: probably not. the release wont be tagged until tomorrow [22:47:38 CEST] <BBB> is the VP9 AMD workaround in the 3.2 branch? [22:48:20 CEST] <BBB> (yes it is) [00:00:00 CEST] --- Thu Oct 27 2016

1 0

ffmpeg.log.20161026
by burek 27 Oct '16

27 Oct '16

[00:00:17 CEST] <llogan> i assumed it was a typo [00:00:43 CEST] <NapoleonWils0n> just off to make some tea [00:01:29 CEST] <Substring> i made the .asoundrc as suggested. I'm not familiar with alsa, do i need to reboot or restart sthg so that it's used ? [00:11:17 CEST] <ATField> (test) [00:18:43 CEST] <Phi> alright folks, can someone explain the 0s [00:18:44 CEST] <Phi> http://pastie.org/private/adlzhhuinnmn3xwb8jl1q [00:19:07 CEST] <Phi> I use avcodec_copy_context and avcodec_parameters_copy [00:19:21 CEST] <Phi> but the RTSP vid and output mp4 vid are different [00:20:17 CEST] <debianuser> Substring: .asoundrc is read when applications start, so you don't have to reboot, just restarting the apps playing sound should be enough. But reboot will work too, as it'd certainly restart all apps. :) [00:21:01 CEST] <Substring> debianuser, yeah thanks for the tip ! I don't mind sparing myself from a reboot ;) [00:21:01 CEST] <llogan> Phi: are you still using Libav's libav* or FFmpeg's libav*? [00:21:11 CEST] <Phi> ffmpeg's [00:21:24 CEST] <Phi> I did a make from git.ffmpeg.org yesterday [00:21:51 CEST] <llogan> ok. well, you're at least in the right channel now. [00:22:42 CEST] <Phi> maximum sass [00:23:05 CEST] <Phi> but help would also be cool [00:23:09 CEST] <Phi> I'm full already [00:29:27 CEST] <Substring> thank you all for the help; time to sleep. Nite nite everyone [00:32:21 CEST] <Phi> oyasumi [00:32:38 CEST] <Phi> so llogan any idea? [00:32:44 CEST] <Phi> do you want codes? [00:43:12 CEST] <Phi> hmm [00:43:29 CEST] <Phi> klaxa: what's with your example? [00:43:40 CEST] <Phi> it allocates a CodecCtx, but never uses it [00:44:13 CEST] <klaxa> it does [00:44:25 CEST] <klaxa> in line 203, it uses codec_ctx->codec [00:44:42 CEST] <klaxa> i leak it too, yeah i fixed that locally already haven't pushed it yet [00:44:52 CEST] <Phi> yea, but you could just use the codec on its own [00:45:08 CEST] <klaxa> from where? [00:45:26 CEST] <klaxa> AVStream's codec is deprecated is it not? [00:45:58 CEST] <klaxa> it's not even present in trunk anymore [00:46:13 CEST] <Phi> avcodec_find_encoder(in_stream->codecpar->codec_id) ? [00:46:36 CEST] <klaxa> oh that's how you use it [00:46:40 CEST] <klaxa> thanks [00:47:02 CEST] <Phi> [citation needed] [00:47:08 CEST] <Phi> [many citations and tests needed] [00:47:14 CEST] <Phi> [who knows what they keep in codec_id] [00:48:24 CEST] <Phi> and I haven't got my code working so if your way works, roll with it :p [00:59:51 CEST] <debkad> furq: mission completed, thanks all works! [01:58:27 CEST] <Phi> welp they came for him [02:17:19 CEST] <marcurling> Please remind me the other way to pass '-vcodec copy' [02:18:48 CEST] <Phi> that doesn't make any sense [02:19:09 CEST] <Phi> is av_log_set_level busted? I'm getting AV_LOG_TRACE messages when I've set it to AV_LOG_INFO [02:21:17 CEST] <Phi> don't see how it can be busted [02:22:50 CEST] <Phi> weird that custom callbacks are meant to filter the level themselves [02:23:00 CEST] <Phi> seems like there's pointless verbosity in there [02:27:04 CEST] <SchrodingersScat> marcurling: does -vc work? [02:27:16 CEST] <furq> -c:v copy [02:27:28 CEST] <SchrodingersScat> i see [03:15:37 CEST] <marcurling> ty [03:16:30 CEST] <marcurling> and can you -c:v:a copy ? furq [03:16:57 CEST] <klaxa> and what would that do? [03:17:16 CEST] <klaxa> you can do -c:a copy -c:v copy or if you only have audio and video anyway just do -c copy [03:17:34 CEST] <klaxa> -c copy will copy all streams [03:17:57 CEST] <marcurling> Ha, nice, ty more [03:18:24 CEST] <furq> -c copy will copy all streams but not all of them will necessarily end up in the output file [03:18:38 CEST] <furq> if you have multiple streams of the same type then use -c copy -map 0 [03:19:55 CEST] <marcurling> Got it all! [04:15:00 CEST] <k_sze[work]> Is there a way to show what x264 options (or preset) were used to encode a file, maybe using ffprobe? [04:15:15 CEST] <k_sze[work]> (given that the video file was encoded through ffmpeg) [04:18:04 CEST] <marcurling> Well, 'ffmpeg -i filename' gives you info but I'm not sure it will give all you want [04:23:47 CEST] <Phi> k_sze[work]: ffprobe will tell you [04:26:37 CEST] <k_sze[work]> Phi: I tried ffprobe -show_streams [04:28:49 CEST] <k_sze[work]> but I couldn't see anything related to x264 options. [04:29:05 CEST] <k_sze[work]> no qp, no crf, no preset [04:30:42 CEST] <k_sze[work]> I mean, quality-wise, I see level=40, and that's about it. [04:32:43 CEST] <furq> k_sze[work]: mediainfo [04:33:38 CEST] <marcurling> hmmm, don't know about ffprobe (you could try encoding a file with param you want to see and then probe it) but I'm pretty sure MediaInfo will tell you (free but not related to ffmpeg) [04:34:06 CEST] <furq> ffprobe didn't have it last time i checked [05:07:59 CEST] <Phi> ffprobe did for me [05:08:30 CEST] <Phi> but x264 options are metadata, so they may not be written [05:12:04 CEST] <furq> http://vpaste.net/pX9cd [05:12:06 CEST] <furq> it shows that? [05:14:22 CEST] <furq> it's also not metadata, it's written into the SEI NAL in the video bitstream [05:14:47 CEST] <furq> at least if you're using the cli tools you have to patch x264 to get rid of it [05:16:01 CEST] <Phi> I keep getting messages about unrecognised SEI from my RTSP stream [05:17:51 CEST] <furq> you can probably ignore it [05:18:19 CEST] <Phi> probably [05:18:31 CEST] <Phi> since they fill up my log I have to drop the messages [05:18:42 CEST] <Phi> and RTSP is massively verbose in ffmpeg for some reason [05:18:56 CEST] <furq> i assume it's some application-specific data that ffmpeg can't do anything with [05:19:57 CEST] <Phi> mm [05:20:04 CEST] <Phi> 1) receive frame from RTSP [05:20:09 CEST] <Phi> 2) pass frame to decoder [05:20:20 CEST] <Phi> 3) read frame from decoder [05:20:29 CEST] <Phi> 4) pass frame to encoder [05:20:35 CEST] <Phi> 5) read frame from encoder [05:20:46 CEST] <Phi> 6) pass frame to file container [05:20:50 CEST] <Phi> ._. [05:22:37 CEST] <furq> http://vpaste.net/Bmgta [05:22:41 CEST] <furq> i guess you can get it without mediainfo [05:36:10 CEST] <Phi> furq, to clarify, to write a frame to an AVFormatContext I have to encode it manually? [05:37:40 CEST] <k_sze[work]> crap [05:37:50 CEST] <k_sze[work]> looks like MediaInfo doesn't understand .nut files. [05:41:40 CEST] <Phi> neither do I [06:01:35 CEST] <k_sze[work]> Is it expected that the x264 encoding preset also affects decoding performance? [06:03:35 CEST] <k_sze[work]> (putting aside the fact that superfast would produce a smaller file than ultrafast, hence possibly requiring less I/O for decoding) [06:16:42 CEST] <furq> k_sze[work]: to an extent, yes [06:16:56 CEST] <furq> obviously cabac vs cavlc will make a big difference [06:17:16 CEST] <k_sze[work]> I see. [06:17:24 CEST] <furq> bframes and refs will make a difference as well [06:19:22 CEST] <Phi> hmm [14:19:44 CEST] <Polochon_street> Hi everyone! Just wanted to know, what's the difference between libavresample and libswresample? [14:24:26 CEST] <nonex86> Polochon_street: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-April/123746.html [14:24:56 CEST] <Polochon_street> nonex86: I've found it, but 2012 is 4 years from now. Is it still valid? [14:29:30 CEST] <nonex86> not sure exactly, but if you open https://ffmpeg.org/documentation.html [14:29:47 CEST] <nonex86> you dont find libavresample in libraries documentation [14:30:19 CEST] <nonex86> so looks like nothing changes since that post [14:30:35 CEST] <Polochon_street> okay, thanks :) [14:30:47 CEST] <JEEB> it's there and changes that come from libav get merged into it. and you can build it if you enable-avresample in the config [14:30:59 CEST] <JEEB> but the one that's actively developed in FFmpeg is swresample [14:32:18 CEST] <Polochon_street> because I need to maintain some package that uses libswresample for both ubuntu 16.04 and arch, and since there has been a change in ffmpeg api not so long ago, it isn't in Ubuntu 16.04 [14:32:30 CEST] <Polochon_street> so I'm considering using avresample for ubuntu 16.04 instead [14:35:03 CEST] <JEEB> the APIs should be quite similar [14:35:37 CEST] <Polochon_street> but now I think I'm just going to do something like « if(LIBSWRESAMPLE_VERSION < 2) » and adapt the code accordingly [14:35:40 CEST] <Polochon_street> thank you! [15:37:21 CEST] <ATField> If the goal is to make a small audio-video fragment using the video-stream of INPUT.mkv and the audio-stream of INPUT.ogg without re-encoding either stream, then is this a proper instruction formula for that task? [15:37:23 CEST] <ATField> ffmpeg -ss [STARTPOINT] -i "INPUT.mkv" -t [DURATION] -ss [STARTPOINT] -i "INPUT.ogg" -t [DURATION] -map 0:0 -map 1:0 -c copy output.mkv [15:41:12 CEST] <arin0v> how to enable frame when i capture the screen? [16:33:58 CEST] <NapoleonWils0n> hi all [16:34:07 CEST] <NapoleonWils0n> i see automatic bitstream filtering in the changelog for version 3 [16:34:37 CEST] <NapoleonWils0n> when i run fmpeg -bsfs i dont see auto bitstream filters in 3.1.5 [16:35:07 CEST] <NapoleonWils0n> is it a compile time option [16:36:50 CEST] <NapoleonWils0n> its not an option listed in the config options for my build of ffmpeg [16:40:04 CEST] <NapoleonWils0n> looked at git build or my distro and dont see any compile time flags for auto bitsream filters [16:41:18 CEST] <DHE> ./configure --list-bsfs [16:42:50 CEST] <NapoleonWils0n> DHE im using arch and dont see any options in the pkgbuild [16:51:20 CEST] <NapoleonWils0n> so i could download ffmpeg git head and run ./configure --list-bsfs and see if anything shows up [16:54:49 CEST] <DHE> you could, but to save time here's what I get: http://pastebin.com/rnrXn2xk [16:56:51 CEST] <Mad7Scientist> How can I watch a downloaded youtube video with separate audio and video? Run two player instances at the same time? I do know that I can encode them with ffmpeg and probably use the -copy codec [16:58:04 CEST] <DHE> depends on the player. mpv has an --audio-file option to select which file contains the audio track [16:58:23 CEST] <bencoh> mplayer has something like that as well ... I'd suspect vlc has one too [16:58:24 CEST] <Mad7Scientist> thanks [16:58:34 CEST] <DHE> correction, mpv [16:58:40 CEST] <DHE> sorry, old habit [16:58:45 CEST] <Mad7Scientist> with ffmpeg I tried .mp4 .avi .mov and finally .vob would contain both streams [16:59:17 CEST] <DHE> $ ffmpeg -i video.mp4 -i audio.mp3 -c copy combined.mkv [16:59:54 CEST] <bencoh> you might need to play with -map 0 as well [17:00:37 CEST] <Mad7Scientist> I did -vcodec copy -acodec copy [17:01:48 CEST] <NapoleonWils0n> DHE i see the dump_header bsfs options in git version, but no dump_headers in my build [17:02:05 CEST] <Mad7Scientist> the .vob file didn't work. mplayer said that the video dimensions were aut of range [17:02:13 CEST] <NapoleonWils0n> wondering what auto bitstream filters would be listed as [17:03:33 CEST] <Mad7Scientist> yeah I do need -map [17:03:48 CEST] <Mad7Scientist> It did this and I have no audio: [17:03:49 CEST] <Mad7Scientist> Stream mapping: [17:03:49 CEST] <Mad7Scientist> Stream #0:0 -> #0:0 (copy) [17:03:49 CEST] <Mad7Scientist> Stream #1:0 -> #0:1 (copy) [17:05:22 CEST] <Mad7Scientist> I see videos on file download sites but most of them don't have surround sound or subtitles or multiple languages like the original DVD had [17:06:34 CEST] <DHE> bencoh: by default the files genuinely contain only audio and only video, my command works. if that's not the case, then yes some use of -map may become necessary [17:06:46 CEST] <Mad7Scientist> Oh the 48,000Hz audio that I downloaded can't be played. Cannot find codec 'libopus' in libavcodec... [17:07:04 CEST] <NapoleonWils0n> Mad7Scientist have you looked at using Kodi which has lots of high quality videos [17:07:12 CEST] <Mad7Scientist> I haven't [17:07:33 CEST] <NapoleonWils0n> i have some ffmpeg scripts that can record pretty much any video from Kodi [17:07:42 CEST] <NapoleonWils0n> https://github.com/NapoleonWils0n/kodi-playercorefactory [17:07:50 CEST] <NapoleonWils0n> https://www.youtube.com/channel/UCriRR_CzOny-akXyk1R-oDQ [17:08:16 CEST] <NapoleonWils0n> the scripts automatically restart recording if the stream cuts out [17:08:44 CEST] <NapoleonWils0n> works on windows, mac and linux [17:09:14 CEST] <bencoh> DHE: doesn't ffmpeg default to at most 1 audio and 1 video? [17:09:51 CEST] <NapoleonWils0n> MadScientist7 have a look at Kodi and the Phoenix addon [17:09:53 CEST] <NapoleonWils0n> https://seo-michael.co.uk/how-to-install-phoenix-for-xbmc/ [17:12:42 CEST] <Mad7Scientist> Is Kodi a media streaming Internet service? [17:13:25 CEST] <NapoleonWils0n> Md7Scientist its a Media player that has thousands of addons to stream videos from loads of place on the internet [17:13:31 CEST] <NapoleonWils0n> https://kodi.tv/ [17:13:57 CEST] <NapoleonWils0n> works on windows, mac, linux, android and mobile devices [17:15:07 CEST] <NapoleonWils0n> you can find pretty much any film, tv or live tv streams you want [17:42:07 CEST] <ATField> (reposting the question) If the goal is to make a small audio-video fragment using the video-stream of INPUT.mkv and the audio-stream of INPUT.ogg without re-encoding either stream, then is this a proper instruction formula for that task? ffmpeg -ss [STARTPOINT] -i "INPUT.mkv" -t [DURATION] -ss [STARTPOINT] -i "INPUT.ogg" -t [DURATION] -map 0:0 -map 1:0 -c copy output.mkv [17:42:27 CEST] <BtbN> It's not very likely you can remux mkv to ogg [17:42:48 CEST] <BtbN> or vice versa [17:43:00 CEST] <ATField> what do you mean? And you can replace .ogg with .ac3, because Ive tried with an .ac3 audio stream as well [17:44:49 CEST] <ATField> The problem is that it works (cutting out a fragment without re-encoding that wont have any audio syncing problems) when I first make a new .mkv container with the video-stream from original video-file and the audio-stream from the .ac3 stream. But if I do all that in one go, it ends up with messed up audio-stream in one way or another. [17:44:57 CEST] <ATField> So I thought maybe the command formula I was using was wrong. [20:07:57 CEST] <pomaranc> hello, does anyone know if this has been solved: https://trac.ffmpeg.org/ticket/1679 [20:09:24 CEST] <DHE> the state of the ticket implies No... [20:11:26 CEST] <pomaranc> I know [20:12:05 CEST] <pomaranc> but here http://forum.videohelp.com/threads/352391-FFMPEG-Ability-to-identify-progre… someone says that it's been solved [20:13:46 CEST] <pomaranc> and I don't have any sample to test with [20:27:36 CEST] <pomaranc> I looked at the source code and it sets interlaced_frame according to ct_type, so in theory it should work [20:28:09 CEST] <pomaranc> but my h264 knowledge is limited [00:00:00 CEST] --- Thu Oct 27 2016

1 0