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

[burek]

[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-d3426fb-win64-static-readme.txt
[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