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

burek burek021 at gmail.com
Wed Dec 2 02:05:01 CET 2015


[00:07:08 CET] <autofsckk> i cant find how to cut the "canvas", is it possible? i mean if i have a video 600x400 for instance, but i want to get rid of the border, like the ones made from iphones recordings and i want to make it maybe 350x400 , is it possible?
[00:08:05 CET] <autofsckk> kepstin -> thanks for the explanation
[00:08:06 CET] <Mavrik> Use a crop video filter.
[00:09:27 CET] <autofsckk> i see, this one http://ffmpeg.org/ffmpeg-filters.html#crop right?
[00:10:22 CET] <autofsckk> reading it, thanks
[00:28:22 CET] <dongs> why the hell doesn't -to actually work when cutting??
[00:28:29 CET] <dongs> am I missing something super obvious
[00:28:42 CET] <dongs> i hate having to go to wolframalpha to do dumb shit like subtract timestamps
[00:29:22 CET] <dongs> -ss 1:52:22 -to 2:06:34 doesn't work, but -ss 1:52:22 -t 14:12 does
[05:32:58 CET] <dongs> ... wow
[05:33:02 CET] <dongs> thanks for all the replies brors
[08:18:32 CET] <wlritchi> Suppose I'm receiving some audio/video streams and encoding to mp4(h264,aac) on the fly; is there a way to put the moov atom at the start of the file so players can start playing it when it's only partially processed?
[08:19:07 CET] <wlritchi> I've seen -movflags faststart but comments on the site I found it suggest that it only works as a second pass
[08:20:06 CET] <wlritchi> Is it fundamentally impossible to write a (complete) moov atom without having seen the entire file?
[08:38:40 CET] <waressearcher2> wlritchi: hallo
[09:03:16 CET] <maco> Hi everyone, I'm trying to follow this post http://blog.oscarliang.net/webcam-streaming-video-raspberry-pi-via-browser/... but although I can open the stream from VLC when i try to open it from web browser (chrome) it dowloads mjpeg, i've read around that changing the port might help, to be honest havent tried that, anymore suggestions?
[09:30:26 CET] <waressearcher2> maco: hallo
[09:30:43 CET] <Mavrik> wlritchi, it's fundamentally impossible to write the MOOV atom before you write data (it contains an index)
[09:31:00 CET] <Mavrik> wlritchi, I suggest you use MPEG2-TS if you can or use MP4 segmented mode if your player supports it
[09:36:15 CET] <maco> hi waressearcher2
[09:50:02 CET] <waressearcher2> maco: wie geht's es dir ?
[10:04:28 CET] <wlritchi> Mavrik: Thanks for the advice; I'll look into other transports since that's probably easier
[10:17:18 CET] <maco> @waressearcher2: Im fine thanks, No german here BTW! xD
[10:26:41 CET] <maco> hallo, anyone here experiengin issues when streaming mjpeg it wont open on browser (chorme) instead it download a file....
[10:45:38 CET] <xintox> howdy
[10:45:47 CET] <waressearcher2> xintox: hallo
[10:52:35 CET] <maco> ye'llow
[11:08:17 CET] <xintox> man. debian version on wheezy is totally outdated
[11:08:31 CET] <xintox> does ubuntu have an easier way to get latest versions of ffmpeg?
[11:10:41 CET] <Mavrik> xintox, get static builds.
[11:11:11 CET] <fritsch> xintox: http://johnvansickle.com/ffmpeg/
[11:15:39 CET] <xintox> oy
[11:15:58 CET] <waressearcher2> xintox: #ubuntu ?
[11:16:28 CET] <xintox> wtf is .tar.xz file?
[11:28:13 CET] <xintox> nm
[11:28:20 CET] <xintox> i  am getting old
[11:33:23 CET] <fritsch> :-)
[12:01:48 CET] <maco> hi is there anyone here?!?!?!??!?
[12:01:50 CET] <maco> :S
[12:01:57 CET] <xintox> does hls_time have to coincide with source stream?
[12:02:08 CET] <xintox> maco: hey
[12:15:01 CET] <maco> Hi,
[12:15:36 CET] <maco> I created a mjpeg stream it open fine on VLC but when opened from browser it download the mjpeg file...
[12:15:38 CET] <maco> ?
[12:18:59 CET] <xintox> maco what browser?
[12:23:31 CET] <maco> chrome
[12:23:34 CET] <maco> and IE
[12:50:31 CET] Action: maco slaps xintox around a bit with a large fishbot
[12:50:41 CET] <maco> xD
[13:24:06 CET] <DHE> xintox: you can set hls_time to whatever you want, but keep in mind that the keyframe interval will regulate it
[13:24:57 CET] <DHE> I find 4s to be a good minimum, and 10s as a common default or maximum by the industry
[14:04:17 CET] <dantti> I'm creating an AVFrame from a QVideoFrame, since QVF has the image bits mapped I'm just assigning to the avframe->data[] planes, but I'm afraid of when avframe get freed it frees that data, does this look sane? https://paste.kde.org/pvvhg0bq7
[14:06:21 CET] <BtbN> Are you sure the pix_fmt is compatible?
[14:07:02 CET] <Mavrik> Uhh, that probably won't fly well.
[14:07:22 CET] <Mavrik> Check the doc on what encode_frame guarantees around the buffer ownership
[14:08:17 CET] <dantti> BtbN: for now I hardcoded AV_PIX_FMT_NV21 which is what QVideoFrame->pixelFormat() returns (QVideoFrame::Format_NV21)
[14:11:29 CET] <dantti> Mavrik: you mean avcodec_encode_video2? if so it doesn't say anything about the frame
[14:11:59 CET] <dantti> since the code compiles if I write the output to a file will it be played somewhere (as I'm not muxing yet)?
[14:13:10 CET] <dantti> *playable
[14:25:27 CET] <dantti> the code runs at least hopefully it ain't leaking... :P
[14:57:16 CET] <maco> 3rd attempt...
[14:57:18 CET] <maco> Hi everyone, I'm trying to follow this post http://blog.oscarliang.net/webcam-streaming-video-raspberry-pi-via-browser/... but although I can open the stream from VLC when i try to open it from web browser (chrome) it dowloads mjpeg, i've read around that changing the port might help, to be honest havent tried that, anymore suggestions?
[14:58:08 CET] <maco> THE COMMAND...
[14:58:08 CET] <maco> ffserver -f /etc/ffserver.conf & ffmpeg -v verbose -r 5 -s 640x480 -f video4linux2 -i /dev/video0 http://localhost/webcam.ffm
[15:03:47 CET] <retard_> i don't think browsers support mjpeg
[15:11:07 CET] <maco> any format that browser would support? strange becuase the link I gived at the top said that it worked for him???
[15:28:08 CET] <maco> ok
[15:28:13 CET] <maco> found tha issue at last
[15:28:14 CET] <maco> !!!
[15:28:20 CET] <maco> FYI*
[15:28:37 CET] <maco> bug with the latest version of Chrome
[15:28:45 CET] <maco> <img src="http://raspcloud.local/yourfile.mjpeg" />
[15:28:47 CET] <maco> ...
[16:20:53 CET] <awfulmakefile> Do I need this line? DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset) $(SRC_PATH)/doc/ffprobe.xsd
[16:21:15 CET] <awfulmakefile> I'm only using this library to get net streams and decode into pixels
[16:21:26 CET] <awfulmakefile> looks like some sort of shaders?
[16:53:42 CET] <pkeuter> hi. i am trying to encode a h264 file from a device to file and play it in a html5 video element at the same time. the recording goes fine, the playing works too, but the browser wants to load the entire file before it can play. i already use -movflags frag_keyframe+empty_moov but for some reason this doesn't seem to work. anyone has an idea?
[16:58:30 CET] <Franciman> Hello
[16:59:37 CET] <Franciman> I'm using ffmpeg libraries and was wondering: If I have a generic audio stream, not mono. How can I transform it in mono?
[17:00:38 CET] <fritsch> swresample and setting the target to mono
[17:01:49 CET] <fritsch> Franciman: http://stackoverflow.com/questions/14989397/how-to-convert-sample-rate-from-av-sample-fmt-fltp-to-av-sample-fmt-s16
[18:02:55 CET] <awfulmakefile> If I'm using ffplay to just decode h264 for pixel reads only Do I really need to configure filters?
[18:04:47 CET] <durandal_1707> usually no
[18:07:33 CET] <awfulmakefile> So if i just open a stream rtsp i would need protocol rtsp
[18:07:40 CET] <awfulmakefile> and probably h264 if its encoded like that
[18:08:45 CET] <awfulmakefile> As far as muxers and demuxers go... im reading some of the docs and they seem to be audio related.... but the ffmpeg.org says demuxers are configured elements that can read the multimedia streams which seems to indicate they deal with video as well
[18:09:03 CET] <awfulmakefile> I dont need anything audio period... what -disables would i want to use to ensure this?
[18:16:12 CET] <hmbg> Good evening. I just upgraded to 2.8.3, and now my tried and true command line doesnt run anymore. http://pastebin.com/wt9XYbgN
[18:16:32 CET] <hmbg> Cannot select sample rate for the link between filters audio format for output stream 0:1 and output stream 0:1.
[18:23:19 CET] <c_14> hmbg: looks like a bug to me, open a bugreport on trac
[18:23:40 CET] <hmbg> oh snap
[18:23:54 CET] <c_14> mention that it's a regression
[18:24:04 CET] <hmbg> any suggestions for a workaround?
[18:24:04 CET] <c_14> although, could you test with a build from git first?
[18:24:20 CET] <hmbg> I could try
[18:27:06 CET] <c_14> AS for a workaround, I'd try and minimalize the command so you know exactly where it's breaking (only use one output at a time, find which of the outputs is causing the error, find which filterchain is causing the error by removing them one at a time etc)
[18:27:43 CET] <c_14> Then probably add an aformat filter to that filterchain
[18:31:06 CET] <hmbg> ok, will look into it
[18:31:34 CET] <hmbg> just to double check, test with a build from git you mean checkout the latest from git and build it from source?
[18:34:35 CET] <c_14> either that, or use the static git build
[18:48:54 CET] <hmbg> does not work with a git build
[18:49:10 CET] <c_14> Ok, then it's a bug
[18:50:01 CET] <hmbg> Ill post it in trac
[18:50:28 CET] <c_14> Mention that it's a regression between whatever version you had before and 2.8.3
[18:50:36 CET] <c_14> and paste the output from the git build
[18:50:43 CET] <c_14> (to the ticket)
[18:52:51 CET] <awfulmakefile> how about this... configure --disable-all-audio
[18:52:57 CET] <awfulmakefile> what does that equate to?
[18:53:40 CET] <c_14> There's no such option
[18:53:56 CET] <c_14> Ah, you want to disable them
[18:53:58 CET] <awfulmakefile> right so how would i accomplish this or is it not possible now
[18:54:06 CET] <awfulmakefile> yeah i only obtain a stream rtsp decode it
[18:54:13 CET] <awfulmakefile> do some shit with pixels and im done
[18:54:34 CET] <c_14> It's probably easier to disable-everything and enable the things you need
[18:54:43 CET] <awfulmakefile> Yeah im getting to that point
[18:54:59 CET] <c_14> You could of course list all muxers/demuxers/parses/decoders and encoders and disable all the audio ones
[18:57:11 CET] <hmbg> btw the aformat line did the trick, so it works now. Thanks a bunch c_14
[18:58:36 CET] <awfulmakefile> how well would running 4 ffplays connected to different streams work out on a intel i3? not so well?
[18:59:18 CET] <awfulmakefile> i ran about 4 on a i7 and it seemed to handle it but on another i7 it wasnt so good (slightly less specs) so been going through it trying every thing possible to make is thinner
[19:18:53 CET] <dantti> does ffmpeg automatically sets x264_opt_.i_threads ?
[19:32:40 CET] <Mavrik> dantti, yes
[19:32:58 CET] <Mavrik> X264_THREADS_AUTO is the default IIRC
[19:33:38 CET] <dantti> Mavrik: k, thanks, I'm now able to write a h264 file, now I need the muxing part :P
[19:51:02 CET] <awfulmakefile> It seems like --enable-lto causes assembly restraints linker errors
[19:51:31 CET] <awfulmakefile> using this line:
[19:51:31 CET] <awfulmakefile> ./configure --enable-shared --disable-static --prefix=/usr --arch=x86 --disable-postproc --disable-swscale-alpha --disable-ffmpeg --disable-ffprobe --disable-ffserver --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-encoders --disable-outdevs --disable-indevs --disable-muxers --disable-filters --disable-debug --enable-pic --enable-lto
[19:59:53 CET] <awfulmakefile> if i add --disable-asm  to that it compiles... but dont i lose a ton of optimizations or do I really lose anything at all...
[20:01:09 CET] <kepstin> awfulmakefile: you don't want to use --disable-asm, that'll make your ffmpeg a lot slower.
[20:01:38 CET] <DHE> and unfortuantely -flto is incompatible with inline asm right now. and inline asm is the better performance option compared to -flto
[20:12:48 CET] <shincode> so yeah anybody know why I have to --enable-lto --disable-asm on x86 processor?
[20:12:58 CET] <shincode> and I cant just go --enable-lto and call it a day
[20:22:05 CET] <kepstin> shincode: you're the person previously known as "awfulmakefile"?
[20:22:27 CET] <kepstin> shincode: you missed this response: <DHE> and unfortuantely -flto is incompatible with inline asm right now. and inline asm is the better performance option compared to -flto
[20:22:44 CET] <shincode> Yeah
[20:22:49 CET] <shincode> I switched from one machine to next
[20:22:56 CET] <shincode> I got sick of waiting for lto to finish lol
[20:23:04 CET] <shincode> on a 2.1ghz dual core
[20:23:24 CET] <kepstin> right now, on x86, lto provides negative benefit. so don't bother.
[20:23:34 CET] <kepstin> for ffmpeg specifically, at least.
[20:23:41 CET] <shincode> So I see... I should knock off LTO and the asm optimization is implied
[20:23:50 CET] <shincode> as long as i knock off disable-asm as well lol
[20:28:45 CET] <kepstin> it might be interesting to see if lto makes any difference when all the inline assembly is moved to other files, but making that change to ffmpeg would be a lot of effort and I dunno if it's even all possible.
[20:29:17 CET] <kepstin> and in some cases it could mean adding additional function calls to assembly instructions that used to be inline...
[20:31:53 CET] <shincode> is the assembly supposed to be better than what compiler generates for optimizations?
[20:32:06 CET] <shincode> because it never seems to be the case on vstudio windows apps
[20:36:14 CET] <kepstin> most of the assembly stuff that matters is for SIMD instructions (SSE/AVX), which compilers have traditionally been pretty poor at automatically generating.
[20:36:33 CET] <shincode> oh so it uses those... then yes.
[20:36:37 CET] <kepstin> In general, new assembly code is only added if it can be demonstrated to be faster than the compiler generated code.
[20:37:11 CET] <shincode> i have to piece in h264 and mjpeg rtsp http for ffplay to use
[20:37:17 CET] <shincode> then disable strip the rest of it.
[20:37:45 CET] <shincode> so in order for rtsp to work i assume i have to enable... demuxer rtsp or something?
[20:38:58 CET] <kepstin> to figure out what kind of thing rtsp is, the easiest way is often to just run "./configure" and see which header it's listed under
[20:40:03 CET] <kepstin> (in this case, it appears to be a demuxer, yes)
[20:40:35 CET] <shincode> now here is a interesting one
[20:40:43 CET] <shincode> Im guessing i need to look for more h264's
[20:40:54 CET] <shincode> I just enabled h264 decoder and its whining :)
[20:42:23 CET] <kepstin> in most cases, enabling a particular option will pull in its dependencies, but I guess that doesn't always work with stuff like rtsp where it can work with different codecs that have different requirements
[20:44:57 CET] <shincode> so is h261 h263 some older video formats before h264?
[20:47:18 CET] <kepstin> yeah. h261 is more or less mpeg-1, and h263 is kind of a precursor to mpeg4 codecs like divx/xvid/msmpeg4.
[20:47:39 CET] <shincode> oh got it. looks like parsers for h264 or rtsp one of the two did not toggle on when enabling decoder h264, perhaps someone should report it :O
[20:47:58 CET] <kepstin> nah, you can decode h264 without the parser depending on the container.
[20:48:08 CET] <shincode> Ah.
[20:48:23 CET] <kepstin> the parser probably has to be enabled to get the connection between rtp and h264 working, i guess.
[21:08:37 CET] <Kwoth> hello, me again. I managed to decode audio from the web to pcm in real time but the quality is really poor and its choppy. I have decent pc (i5, 8gig ram, r9270x)
[21:08:47 CET] <Kwoth> these are the commands i use for running ffmpeg Arguments = "-i \"" + Uri.EscapeUriString(file) + "\" -f s16le -ar 48000 -af volume=1 -ac 1 pipe:1",
[21:09:43 CET] <Kwoth> basicaly if i could somehow buffer part of the song or something like that, that would be perfect, at least make it not be choppy.
[21:10:26 CET] <Kwoth> i tried with "-maxrate 960 -bufsize 1920" and "-maxrate 970 -bufsize 9600", nothing changes
[21:15:05 CET] <durandal_1707> volume filter with 1 as art does nothing
[21:27:29 CET] <Kwoth> ok ill remove it but that doesnt fix my problem :d
[21:34:26 CET] <durandal_1707> why you use ac 1?
[22:06:23 CET] <Kwoth> no idea what it is tbh.
[22:06:49 CET] <Kwoth> i took it from another lib that does audio decoding from stream
[22:06:53 CET] <durandal_1707> that sets output channel number
[22:07:11 CET] <Kwoth> ah yes
[22:07:14 CET] <Kwoth> i remember now.
[22:07:16 CET] <Kwoth> I need mono.
[22:07:47 CET] <Kwoth> The c# library i am using does not support sending stereo sound to the voice channel.
[22:14:57 CET] <Kwoth> basicaly what i am doing is getting stream from youtube real time,  decoding it to PCM, and sending those to the voice channel in the chat client. Basicaly streaming music.
[22:15:10 CET] <Kwoth> And its lagging, so its useless. I need to make it stop the lag
[23:18:10 CET] <jasom> Kwoth: use more buffering
[23:18:39 CET] <Kwoth> jasom: how?
[23:19:39 CET] <jasom> Kwoth: likely the skipping is happening in your C# library, so maintain a larger buffer there
[23:20:00 CET] <jasom> managed runtimes that aren't designed with bounded-work garbage collectors are going to be a bit of a pain for streaming audio
[23:20:10 CET] <Kwoth> i have no buffer in c#.
[23:20:20 CET] <Kwoth> i just pass the ffmpeg output to pcm sender
[23:20:25 CET] <Kwoth> in real time
[23:20:27 CET] <jasom> Kwoth: I would wager good money that this is your problem then
[23:20:45 CET] <Kwoth> Well, i know it is, i just want to know if ffmpeg can actually buffer it
[23:20:58 CET] <jasom> Kwoth: you need to buffer in C3
[23:20:59 CET] <jasom> c#
[23:21:13 CET] <jasom> it doesn't matter how big the buffer in ffmpeg is if your c# library isn't reading from ffmpeg
[23:21:40 CET] <jasom> which pcm library are you using?
[23:25:55 CET] <Kwoth> what do you mean
[23:26:01 CET] <Kwoth> my c# library isnt reading from ffmpeg?
[23:26:09 CET] <Kwoth> i have process.start
[23:26:15 CET] <Kwoth> which runs this ffmpeg command
[23:26:18 CET] <Kwoth> and i read output stream
[23:26:58 CET] <jasom> right, and if your C# program is busy doing something else (e.g. a garbage collection) then it's not reading from ffmpeg
[23:27:22 CET] <Kwoth> nah, this is in a task
[23:27:26 CET] <Kwoth> it doesnt get blocked
[23:27:48 CET] <jasom> Kwoth: write the raw ffmpeg output to a file and see if it skips when you read from the file rather than a pipe
[23:28:30 CET] <Kwoth> kk, i will try that tommorow
[23:28:42 CET] <Kwoth> I did that before but i dont remember if it lagged or not
[23:28:47 CET] <jasom> Kwoth: if it allocates memory, it may get blocked.  I don't konw CLR very well, but if it accesses memory on the heap, it may get blocked as well
[23:29:39 CET] <Kwoth> i just think the problem is it is not downloading fast enough. If i could prebuffer the part of the stream im reading from and predecode it, before i start reading from the output stream
[23:29:43 CET] <Kwoth> that would be perfect
[23:31:48 CET] <jasom> Ah, just found it; CLR uses a mark and compact GC that stops all threads during the GC
[23:32:00 CET] <jasom> so if any thread is allocating memory, your thread will get blocked from time to time
[23:34:48 CET] <bbloom> i'm trying to make sense of a problem with some code based off of the filtering_audio.c example - i get the error "more samples than frame size" when trying to encode audio. As far as I can tell, the auto-inserted aresample filter is producing frames with a larger nb_samples than the encoder can handle. Do I need to call swr_convert manually? Or is there some way to influence the calculation in the auto-inserted resampler?
[00:00:00 CET] --- Wed Dec  2 2015


More information about the Ffmpeg-devel-irc mailing list