[00:24:15 CEST] <Coder206> Hi! I hope you are doing well! I am trying to install FFmpeg as a dependency using Terminal in Fedora 24 and I received an error saying that it was not found. How do I install this without going through RPM fusion? [00:25:34 CEST] <c_14> Your only other bet (on Fedora) is to compile manually. [00:25:53 CEST] <Coder206> c_14: Thanks. [00:25:57 CEST] <llogan> If you only need the cli tool binary just use http://johnvansickle.com/ffmpeg/ [00:26:22 CEST] <c_14> Because he said dependency, I assumed he meant the libs. but if you only need the cli that'll work, yes. [00:28:13 CEST] <Coder206> c_14, llogan: I just need libavutil, libavformat and libavcodec, is it possible to do this without RPM or compiling? [00:30:06 CEST] <Coder206> *RPM Fusion [00:30:21 CEST] <c_14> None I know of. [00:30:30 CEST] <drv> what do you need them for? presumably there will be compiling involved anyway if you need the libs [00:31:15 CEST] <llogan> you can compile and simply not install anything to avoid package management mess [00:33:33 CEST] <Coder206> drv: They are a new requirement for the Mozilla Servo project. [00:34:26 CEST] <Coder206> lllogan: The project is trying to avoid compiling for this dependency. [00:34:36 CEST] <Coder206> * llogan: ^ [00:34:41 CEST] <Coder206> Sorry! [00:35:01 CEST] <drv> you could choose a distro that actually includes ffmpeg :) but otherwise, it will require compiling or a third-party repository [00:36:33 CEST] <Coder206> drv: So Fedora doesn't have it included? [00:37:02 CEST] <drv> I believe Fedora (Red Hat) doesn't include ffmpeg for patent concerns [00:38:23 CEST] <Coder206> drv: Thanks! [00:38:41 CEST] <Coder206> We are going with the compiling and not installing proposal by llogan [00:42:24 CEST] <Coder206> Thanks everyone [02:30:06 CEST] <nukke> having some problems with ffserver/ffmpeg. for ffserver I'm using the OGG example config at the bottom of this page: https://trac.ffmpeg.org/wiki/ffserver [02:30:53 CEST] <llogan> ffserver is going away. [02:31:15 CEST] <nukke> noooooooooooooooo [02:31:22 CEST] <nukke> any alternatives? :( [02:31:32 CEST] <nukke> trying to find a way to webcam with my cat over my weekend trip. [02:32:03 CEST] <llogan> http://ffmpeg.org/index.html#ffserv [02:33:00 CEST] <nukke> well, that's interesting. weirdest timing. [02:36:19 CEST] <nukke> ok VLC works. thanks llogan o_O [04:48:24 CEST] <funfunctor> Howdy [04:49:30 CEST] <funfunctor> Does ffmpeg have the ability to use the GPU's IP cores for dealing with codec? [05:14:54 CEST] <Sashmo_> can anyone suggest what the best way is to get the audio levels across separate PCM channels from a file? I'm trying to detect what volume if any per channel [05:25:46 CEST] <furq> Sashmo_: -filter_complex "channelsplit[left][right];[left]volumedetect;[right]volumedetect" [05:26:01 CEST] <Sashmo_> thanks furq Ill try that [05:36:24 CEST] <Sashmo_> furq: but I dont need to split the channels, they are already split into 8 mono channels 0:1->0:8 [05:37:36 CEST] <furq> -filter_complex "[0:1]volumedetect;[0:2]volumedetect... [05:37:49 CEST] <Sashmo_> hmm I tried that but let me try it again.... [05:38:51 CEST] <Sashmo_> furq: you're right... I misstyped it! [05:38:55 CEST] <Sashmo_> thanks again [11:05:58 CEST] <kdehl> What do "baseline @ L 10" and "baseline @ L 30" mean when I use file(1) on my two H.264 files? [11:06:24 CEST] <furq> kdehl: [11:06:31 CEST] <kdehl> The difference between the two videos is only that one is 90 pixels high, the other is 100. [11:06:38 CEST] <furq> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles and https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels [11:06:39 CEST] <kdehl> furq: Yes? :) [11:07:18 CEST] <kdehl> furq: Right, I know baseline, but what do 30 and 10 stand for? [11:07:27 CEST] <furq> presumably level 1.0 and 3.0 [11:07:34 CEST] <kdehl> Ahhh. [11:07:37 CEST] <furq> or 1 and 3, since there is no .0 [11:07:57 CEST] <kdehl> Right. [11:08:18 CEST] <kdehl> Confusing output, really. Maybe one should file a bug report. [11:08:48 CEST] <jkqxz> file is just telling you the contents of the level_idc field at the beginning of the SPS. (It doesn't have any capability to do much more than that.) [11:09:16 CEST] <furq> i'm impressed that it even does that really [11:09:18 CEST] <kdehl> Is the SPS always the first NAL? [11:09:26 CEST] <kdehl> Heh. [11:09:34 CEST] <kdehl> file is impressive. [11:09:54 CEST] <furq> i forget what it was now but i remember it being completely wrong a few times [11:10:02 CEST] <furq> it's normally pretty good though [11:10:16 CEST] <jkqxz> No, though it usually is in raw streams. [11:10:37 CEST] <kdehl> jkqxz: Right. [11:11:05 CEST] <kdehl> The ones I've seen always have it as the first one. Then comes a PPS. [11:11:24 CEST] <kdehl> (That being said, I've only played around with this for a week.) [11:16:29 CEST] <jkqxz> The only (relatively) common case where it isn't is when you have a stream with AUD NAL units in. [11:23:00 CEST] <kdehl> Audio? [11:25:52 CEST] <kdehl> Ah. Access Unit Delimiter. [15:04:29 CEST] <akr> hello [15:04:32 CEST] <akr> anyone around? [15:05:13 CEST] <DHE> just ask/say what you want [15:05:46 CEST] <akr> I'm trying to stream my desktop over udp [15:05:59 CEST] <akr> here is the command line: ffmpeg -f x11grab -s 1600x900 -r 15 -i :0.0 -vcodec libx264 -an -f mpegts "udp://127.0.0.1:8554/" [15:06:23 CEST] <akr> when I try to play back the stream in ffplay, I get no image and loads of errors: "no frame!" [15:06:39 CEST] <akr> and I can't figure out what's wrong :) [15:08:27 CEST] <akr> I also tried to stream over rtsp, rewriting '-f mpegts' to '-f rtsp' and "udp://&" to "rtsp://&", but then I an error from ffmpeg: Could not write header for output file #0 (incorrect codec parameters ?): Connection refused [15:09:25 CEST] <akr> What I am trying to do, (in case these is some better ffmpeg setup for this), is to stream my desktop to serviio [15:13:32 CEST] <akr> serviio supports http, mmsh, mmst, rtp, and rtsp [15:15:08 CEST] <akr> I also tried streaming from vlc, but I was getting something like 1/60 fps and glitches [15:19:41 CEST] <DHE> well, you need an endpoint to receive the data. otherwise you get errors. rtsp requires a server, udp requires something to listen. [15:19:49 CEST] <DHE> for the latter you can get away with a multicast-based target [15:21:16 CEST] <akr> So you're saying it's impossible to stream using ffmpeg and receive using ffplay? [15:22:02 CEST] <akr> (I'm using ffplay only to test the stream btw) [15:23:50 CEST] <akr> anyway, my server is serviio [15:24:16 CEST] <akr> but I have trouble creating a stream in ffmpeg that even fflay can listen to [15:24:16 CEST] <DHE> the udp method should work if you launch ffplay first and wait for ffmpeg to start sending [15:24:30 CEST] <akr> hmm [15:24:32 CEST] <akr> will try [15:24:59 CEST] <DHE> also, just noticed this, I don't use a trailing / on the URL for udp:// [15:27:52 CEST] <akr> Okay, you were right about having to launch ffplay first when trying to stream through udp [15:28:09 CEST] <akr> the trailing / doesn't seem to matter [15:30:08 CEST] <DHE> you can also try the multicast method. set the destination IP to something in the 239.x.x.x range [15:30:52 CEST] <akr> I don't think serviio can listen to udp, though :( [15:31:04 CEST] <akr> So I need to get rtp or rtsp or mmsh working [15:32:34 CEST] <akr> rtp is weird, ffplay says it needs a config file to receive it, so how des serviio receive it? [15:32:45 CEST] <akr> serviio uses ffmpeg internally as well I think [15:33:14 CEST] <c_14> akr: it wants the sdp file [15:33:43 CEST] <c_14> when you use ffmpeg to create an rtp stream it outputs the sdp info to stdout, you can also use -sdp_file to write it to a file [15:33:49 CEST] <c_14> Then feed that to ffplay [15:33:55 CEST] <akr> Yeah I saw that [15:34:09 CEST] <akr> but then I do "ffmpeg -protocol_whitelist file -i stream.sdp" [15:34:22 CEST] <akr> and I get "Protocol not on whitelist 'file'!" [15:34:44 CEST] <akr> *ffplay [15:37:02 CEST] <akr> Also, any idea what's wrong with my rtsp command line? [15:37:47 CEST] <akr> that is: ffmpeg -f x11grab -s 1600x900 -r 15 -i :0.0 -vcodec libx264 -an -f rtsp "rtsp://127.0.0.1:8554/" [15:38:20 CEST] <akr> oh, do I have something running on the other side with rtsp as well? [15:38:31 CEST] <akr> have to have* [15:39:16 CEST] <akr> Doesn't seem like it [15:40:09 CEST] <c_14> akr: playing the sdp file in mpv seems to work, so it's probably just a bug in the ffmpeg/ffplay commandline programs [15:42:02 CEST] <jokke> hey [15:42:20 CEST] <jokke> i'm trying to find good settings for encoding screencasts with vp8 [15:42:32 CEST] <jokke> so far everything looks pretty crappy [15:43:14 CEST] <jokke> i tried playing around with -crf going down as far as 4 and -b:v upto 2M [15:43:42 CEST] <c_14> akr: rtsp needs a server listening on the other side [15:46:20 CEST] <akr> c_14: hm, but I get 'connection refused' when I try to start ffplay first, pointing it to an rtsp url [15:46:42 CEST] <c_14> akr: you need -rtsp_flags listen [15:47:27 CEST] <akr> Ah. [15:47:51 CEST] <akr> But now I get "Invalid data found when processing input" in ffplay once I try to start the stream. [15:48:01 CEST] <akr> and ffplay exits [15:52:00 CEST] <karklud> is it possible to get ffprobe to output the duration of file, solely based on information found in the file header - and not by looking at the actual size of the file? [15:52:19 CEST] <karklud> i need to retrieve the duration of a file which is in the progress of being transferred to my machine [15:52:27 CEST] <karklud> so the file isn't complete [15:52:41 CEST] <karklud> and ffprobe is giving me the wrong results [15:53:10 CEST] <DHE> sounds like that information isn't directly available. different formats have different requirements and may involve seeking to the end to read timestamps, etc. [15:53:10 CEST] <karklud> i'm using the arguments -show_streams -show_format [15:53:39 CEST] <karklud> yeah, so i guess a general solution can't exists, but there's no way of getting the information out IF it exists? [15:54:15 CEST] <karklud> the use case will mostly be WAV's and AIFF files anyway, so more often than not the information will be available after having received less than 1kb of data [16:06:37 CEST] <Mandevil> What's wrong with this commandline: ffmpeg.exe -i src.mov -c:0:0 copy -c:0:1 aac dst.mov [16:06:43 CEST] <Mandevil> It says 'aac' is invalid codec. [16:07:26 CEST] <DHE> old version that doesn't have the aac encoder? [16:07:26 CEST] <Mandevil> Any coded I choose is rejected as invalid. [16:07:37 CEST] <Mandevil> It's on the -codecs list! [16:07:44 CEST] <DHE> with the 'E' flag? [16:07:49 CEST] <Mandevil> Yes. [16:07:57 CEST] <c_14> -c:0:0 and -c:0:1 aren't valid mappings (in this context) [16:07:58 CEST] <Mandevil> If I put some pcm there it will say the same thing. [16:08:18 CEST] <c_14> I assume you want -c:0 and -c:1 [16:08:34 CEST] <furq> or -c:v and -c:a [16:08:41 CEST] <Mandevil> OK, let me try. [16:08:46 CEST] <c_14> the mappings for the -c flag refer to the output streams per-output [16:09:27 CEST] <Mandevil> It works. [16:09:32 CEST] <Mandevil> Ah, ok. [16:09:34 CEST] <furq> i wonder what -c:0:0 even does [16:09:40 CEST] <furq> it's not a valid stream specifier [16:11:17 CEST] <Mandevil> Thank you for help :) [16:24:37 CEST] <Mandevil> Hm, when I transcode MJPEG->ProRes (for example), the resulting video has lower contrast... [16:25:36 CEST] <Mandevil> The source and destination are both YUV. [16:25:49 CEST] <Mandevil> (though the source is 4:2:0 and destionation is 4:2:2) [16:26:26 CEST] <Mandevil> I assume the dynamic range is little squashed in the target video, but why? [16:43:45 CEST] <kepstin> Mandevil: jpeg usually is interpreted as using "full range" or "pc range", with the full values 0-255, but video uses limited range where black is at 16 and white is at 235, iirc. Assuming the players are all working properly, both should *appear* the same at playback... [16:44:39 CEST] <kepstin> there could be some incorrect conversions going on at some point, too :/ [16:45:47 CEST] <Mandevil> VLC clearly doesn't play it correctly then? [16:45:56 CEST] <Mandevil> Because the video loaded in Resolve looks fine. [16:46:06 CEST] <Mandevil> But in VLC it looks grayish, low contrast. [16:46:09 CEST] <kepstin> hard to say. I'd suggest using mpv with the opengl output to compare [16:46:15 CEST] <kepstin> could be a vlc issue [16:46:22 CEST] <Mandevil> mpv? [16:59:48 CEST] <bencoh> or could be that your transcoder doesn't put the proper flag/field/whatever in your resulting stream [17:00:51 CEST] <bencoh> (bt601 vs bt709?) [17:02:09 CEST] <kepstin> hmm, bt601 vs bt709 won't make a big constrast difference, it's a bit more subtle than that [17:08:09 CEST] <bencoh> ah right, he meant contrast, nevermind [17:08:28 CEST] <bencoh> not shifted red and stuff like that [17:08:43 CEST] <Mandevil> My transcoder is ffmpeg :) [17:11:07 CEST] <Mandevil> When I use -c:0 libx264, the video plays alright in VLC. [17:11:15 CEST] <Mandevil> When I use -c:0 prores, it's wrong. [17:11:45 CEST] <c_14> try the other prores encoder? [17:11:51 CEST] <Mandevil> "The other"? [17:11:54 CEST] <c_14> There's 2 [17:11:59 CEST] <Mandevil> In ffmpeg? [17:12:12 CEST] <c_14> either _aw or _ks [17:12:15 CEST] <c_14> yes [17:13:46 CEST] <Mandevil> Hm, the _ks is much slower. [17:14:49 CEST] <Mandevil> The result from both _ks and _kw is same as contrast is concerned. [17:15:25 CEST] <Mandevil> Maybe VLC is not playing ProRes correctly. [17:15:39 CEST] <c_14> try ffplay or mpv or something maybe [17:16:19 CEST] <Mandevil> Tried MPC. [17:16:40 CEST] <Mandevil> Funny thing... it's about halfway between VLC playing source and VLC playing ProRes. [17:17:10 CEST] <akr> DHE: I managed to get the stream going with VLC, but it freezes after 1 frame :/ [17:17:21 CEST] <akr> All in all, rather poorly spent ~6 hours. [17:19:21 CEST] <Mandevil> So i tried quicktime player. [17:19:40 CEST] <Mandevil> In QT all three files are equally gray :-O [17:22:05 CEST] <Mandevil> In ffplay it's the same as in QT. [17:22:29 CEST] <Mandevil> I'm losing track of what's actually right. [17:24:12 CEST] <BtbN> sounds like limited vs. full range RGB? Or is that what bt601/709 is about? [17:24:19 CEST] <Mandevil> Yes, that's what it is. [17:24:53 CEST] <Mandevil> ffplay even says it's yuvj420p(pc, bt470bg/unk [17:25:05 CEST] <Mandevil> But it looks gray, low contrast. [17:25:15 CEST] <Mandevil> Compared to what VLC plays from _source_ file. [17:26:01 CEST] <Mandevil> My quest is to understand what's how is this supposed to work. [17:27:38 CEST] <Mandevil> s/what's// [17:42:51 CEST] <Mandevil> Hm, various sources on the net tell me that I should setup my nvidia driver to use full range for video. [17:42:59 CEST] <Mandevil> When I do it, it sorta works. [17:43:46 CEST] <Mandevil> Actually no. [17:43:48 CEST] <Mandevil> It's still the same. [17:46:16 CEST] <Mandevil> Ha! Found it. [17:46:42 CEST] <Mandevil> For some reason I had picture processing switched on in VLC and it only worked on the MJPEG source (no idea why only on that...). [17:46:49 CEST] <Mandevil> Once switched off, it all looks the same. [18:44:44 CEST] <t4nk0361> Hello, where could i download a ffmpeg version with --enable-demuxer='flac,gif,image2,image2pipe,matroska' ? [18:44:53 CEST] <t4nk0361> for windows [18:45:12 CEST] <furq> https://ffmpeg.zeranoe.com/builds/ [18:45:45 CEST] <t4nk0361> thanks furq but the builds their have not this option by default enabled... [18:46:13 CEST] <furq> all of those demuxers are enabled by default [18:46:43 CEST] <t4nk0361> sure? https://ffmpeg.zeranoe.com/builds/readme/win64/static/ffmpeg-20160803-d3426f... [18:47:08 CEST] <furq> yes [18:47:23 CEST] <furq> you don't need to explicitly enable them, they're enabled by default [18:47:40 CEST] <t4nk0361> i could not find them on the link above [18:48:11 CEST] <t4nk0361> i try to merge two mpg files together and get a "Invalid data found when processing input" error [18:48:23 CEST] <t4nk0361> i try to use this solution: https://trac.ffmpeg.org/ticket/4854 [18:52:15 CEST] <t4nk0361> does someone know a solution for that? [19:10:03 CEST] <kepstin> t4nk0361: the solution is to use an ffmpeg build that has the mpg demuxer enabled, just like the reply on the ticket says [19:10:13 CEST] <kepstin> the build you were using before has it explicitly disabled. [19:11:56 CEST] <t4nk0361> could someone create a build with the enabled one? [19:23:17 CEST] <Pxl_> whats up everyone [19:23:39 CEST] <thebombzen_> kepstin: I'm doing a follow-up of yesterday. I tried using -itsoffset with -ss and -vf subtitles and it produced a corrupt mkv file [19:24:25 CEST] <thebombzen_> that is, specifically ffmpeg -ss 15:00 -itsoffset 15:00 -i input.mkv -map 0:v -vf subtitles=input.mkv -c ffv1 output.mkv [19:24:42 CEST] <thebombzen_> however without -itsoffset it worked. [19:25:21 CEST] <thebombzen_> kepstin: we discussed this yesterday. i.e. it produced a corrupt file that was 1.8 kB despite being a 10second H.264 video [19:28:02 CEST] <thebombzen_> http://pastebin.com/0VkRMRCB [19:28:59 CEST] <thebombzen_> that's for -itsoffset. without it is this; http://pastebin.com/CG3At0xf [19:36:35 CEST] <thebombzen_> for the record, -copyts also didn't work [19:36:41 CEST] <thebombzen_> as in it produced the same kind of corrupt file. [19:37:01 CEST] <Pxl_> Having an issue with concat that part (~2 secs) of my first clip is getting cut off. any ideas? Videos are fine pre concat. http://pastebin.com/K4fgYDB7 [19:38:14 CEST] <thebombzen_> Pxl_: I literally just got scolded for not pasting the exact command and complete console output [19:38:22 CEST] <thebombzen_> so I'd recommend doing that [19:40:10 CEST] <Pxl_> I like to live life on the edge. lol. But that is the exact command and here is console http://pastebin.com/4M6PWRsT [19:41:39 CEST] <rmoorelxr> I'm getting a video feed from a DVR type device and I don't have direct access to its cameras. I get a stream of bytes that should be h264. Is it possible to pipe this output to ffmpeg for live streaming? [20:03:27 CEST] <kepstin> thebombzen_: huh, that's *really* strange, particularly since there's no apparent errors in the video encoder command output [20:04:45 CEST] <kepstin> thebombzen_: just for fun, have you tried with a different video codec (e.g. libx264)? [20:05:18 CEST] <thebombzen_> same problem [20:06:23 CEST] <kepstin> hmm. the last thing I can think of is that it's having issues with the not-starting-at-0 timestamps, try adding ",setpts=PTS-STARTPTS" to the end of your -vf string (after the subtitles filter) [20:06:42 CEST] <thebombzen_> kepstin: hoh [20:06:49 CEST] <thebombzen_> it appears to be a glitch in the mkv muxer [20:06:54 CEST] <thebombzen_> output.mp4 worked [20:07:02 CEST] <kepstin> yeah, it did look muxer-specific [20:07:34 CEST] <kepstin> you could also use 'nut' if it's just a temporary output file, then switch it to something else after :/ [20:07:49 CEST] <kepstin> (in theory, nut can hold anything ffmpeg can generate) [20:09:00 CEST] <thebombzen_> didn't know that. I use mkv for temp files. I'll keep that in mind and possibly submit a bug report [21:20:38 CEST] <thebombzen_> kepstin: using -vf setpts=PTS-STARTPTS also allows me to mux the matroska [21:20:59 CEST] <thebombzen_> also the matroska muxer errors with the pts that it doesn't like [21:22:39 CEST] <kepstin> yeah, I guess it just has problems with pts starting ad non-zero :/ [21:23:26 CEST] <kepstin> that setpts=... stuff just applies an offset to move everything to start at 0. (it will desync the audio unless you do the same thing there, I think) [21:25:11 CEST] <thebombzen_> apparently -vsync drop didn't work. I'll probably try the setpts stuff [21:25:37 CEST] <thebombzen_> whats' the practical difference between -itsoffset and -copyts? [21:51:54 CEST] <kepstin> -copyts passes through the timestamps from the input file completely untouched. -itsoffset runs the timestamps from the input file through ffmpeg's cleanup algorithm, then applies a simple offset to them afterwards. [21:52:40 CEST] <kepstin> (the cleanup algorithm, among other things, normalizes the timestamps to start at 0) [00:00:00 CEST] --- Fri Aug 5 2016