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

burek burek021 at gmail.com
Fri Aug 29 02:05:01 CEST 2014


[02:26] <voip_> Hello guys. I need to trans code 150 streams to h264 flash. How many CPUs approximately i will need ?
[02:28] <llogan> voip_: not enough information to provide answer, because you could do it with 1 cpu.
[02:29] <voip_> llogan, somting like  -acodec aac -strict experimental -ar 44100 -ac 2 -b:a 96k -vcodec libx264  -b:v 900k -threads 4 -f flv
[02:29] <klaxa> you still can do what with one cpu
[02:30] <voip_> with this parameters u have 7% cpu usage on 8 core xeon e5
[02:31] <voip_>  when runing only 1 stream
[02:32] <voip_> how to calculate how many servers we need for transcoding 150 streams ?
[02:33] <klaxa> oh you mean in real time
[02:33] <klaxa> i don't know, try to do as many as you can with that setup, when it crashes: that's too much for one single machine
[02:34] <klaxa> it also depends on the source material i think
[02:34] <llogan> why -b:v 900k?
[02:36] <Hello71> f
[02:36] <Hello71> and parameters.
[02:36] <Hello71> obviously you will be fine on a p4 if you use -preset ultrafast
[02:37] <voip_> guys i need raltime for IPTV
[02:38] <klaxa> if you expect a mathematical way to determine how many machines you need to do what you want to do, you will be disappointed
[02:39] <llogan> voip_: ...because if you're limited by bandwidth in any way you should be using VBV instead of just -b:v
[02:39] <llogan> with -maxrate and -bufsize
[02:43] <voip_> llogan, i am not limited by bandwith in datacenter side, my some custumers with 1mb DSL may be limited.  So we planing take 150 streams from privider trnascode and pass to wowza.
[02:47] <llogan> progressive download or live streaming? (sounds like live)
[02:48] <voip_> live streaming
[02:54] <llogan> use VBV
[02:55] <voip_> its will decrease cpu ussage ?
[02:57] <llogan> [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-August/161881.html
[02:57] <llogan> obviously that is the wrong channel, llogan
[03:05] <voip_> llogan, i can increase with vbv cpu ussage?
[04:30] <surf2b1> Here is my question: http://pastebin.com/w0DbyzPD Any help is greatly appreciated.
[07:35] <tm512> why is ffmpeg so finicky when it comes to not having the audio and video desync terribly? If I use a alsa and a pulse source, it's fine, but two pulse sources, and it desyncs
[07:49] <tm512> I get a lot of "Non-monotonous DTS in output stream 0:0; previous: 26603, current: 26588; changing to 26603. This may result in incorrect timestamps in the output file."
[08:09] <tm512> I used to have this working just fine. I don't know what went wrong
[09:47] <termos> I have an issue with a multithreaded program that crashes on av_interleaved_write_frame, it seems to happen when I start another thread with another encoding job. Can I not write frames while doing something like avformat_open_input?
[10:13] <K4T> http://ffmpeg.gusari.org/viewtopic.php?f=11&t=1648&p=4654#p4654 can someone look on this?
[11:31] <lkiesow> Hi, yesterday a college of mine brought to my attention the following sentence from the FFmpeg wiki:
[11:31] <lkiesow> If you use -ss with -c:v copy, the resulting bitstream might end up being choppy, not playable, or out of sync with the audio stream, since ffmpeg is forced to only use/split on i-frames.
[11:31] <lkiesow> I'm regularly using bitstream copy together with seeking and can't remember having any problems. Is this statement still true?
[12:37] <groundnuty> hey, I've recorded a tutorial video for the a purpose of presentation, si there some magic way to make the video autoamticly pause at specyfied times?
[13:25] <lkiesow> groundnuty: Not really, I guess that is something your player would have to do
[13:29] <Diaz2211> hi all experts,
[13:29] <Diaz2211> I am new here
[13:29] <Diaz2211> I am searching the fixed point decoder for WMA
[13:30] <Diaz2211> is there any information about that?
[13:30] <Diaz2211> in libav, wma is not fixed point, when I try to use that to decode wma audio file,
[13:31] <Diaz2211> it takes 100% cup usage, there is not float instructions support on my embedded cpu
[13:31] <Diaz2211> I would like to search fixed point decoder
[13:31] <Diaz2211> any ideas?
[14:08] <Diaz2211> I can see the code wmafixed from vlc source code
[14:08] <Diaz2211> but ffmpeg does not have that code,
[14:09] <Diaz2211> is it possible to support wmafixed in ffmpeg source code?
[16:06] <badcompiler> ?w
[16:06] <badcompiler> ??
[16:06] <badcompiler> :help
[16:13] <badcompiler> I have a really basic question about using ffmpeg. I'm not sure if this is codec/conatiner specific or just all files in general but. If I have a source file (QT Animation from Adobe Package I think) and I do a straight copy with ffmpeg -i input.mov -vcodec copy -acodec copy output.mov why do I get different duration always by a frame or more (40-160 ms) ?
[16:13] <klaxa|work> what version are you using
[16:14] <klaxa|work> of ffmpeg that is
[16:14] <badcompiler> i think its 2.3.3
[16:14] <badcompiler> ffmpeg version N-62249-g845414b
[16:14] <badcompiler> mandelbrot ?
[16:15] <klaxa|work> that's weird, if it really bugs you, maybe upload a sample and file a bugreport?
[16:16] <badcompiler>  ffprobe -i input.mov  Duration: 00:00:35.00, start: 0.000000.  ffprobe -i output.mov Duration: 00:00:35.04, start: 0.000000,
[16:17] <badcompiler> now I do get Unsupported codec with id 0 for input stream 1 when I run the ffmpeg copy
[16:29] <OutBound> Hi... perhaps someone can help: When I try to capture the screen with x11grab and also 2 audio streams into three files, the audio drifts apart. After recording for two minutes, the audio files show being almost a second longer, increasing with longer recording session. Infos here: http://pastebin.com/N6hmV22Y
[16:32] <Hello71> why don't you put everything into one file
[16:32] <OutBound> because I need them seperate for different editing purposes
[16:47] <klaxa|work> OutBound: using -r 30 as an input option might be the cause
[16:48] <klaxa|work> i think there is a parameter specifically for x11grab to always produce the same amount of frames regardless of whether or not your hardware is fast enough to get them through x11
[16:49] <badcompiler> can somene else verify for me...if you down load a refernce file (eg http://a1408.g.akamai.net/5/1408/1388/2005110403/1a1a1ad948be278cff2d96046ad90768d848b41947aa1986/sample_iTunes.mov.zip ) and run ffmpeg -i sample_iTunes.mov -vcode copy -acodec copy output.mov and compare ffprobe with both files ?
[16:49] <klaxa|work> see: http://ffmpeg.org/ffmpeg.html#X11-grabbing for examples on how to use -framerate instead of -r
[16:49] <OutBound> thanks klaxa|work
[16:50] <badcompiler> every time the file output from ffmpeg adds 40 milliseconds,
[16:51] <badcompiler> I cant be a bug it would be too obvious, there must be a good reason for it that I don't understand
[16:52] <klaxa|work> how can this not be a bug?
[16:52] <badcompiler> because I figure someone else would have definitely noticed it before me if it is a bug.
[16:53] <klaxa|work> what happens if you remux the file ffmpeg produced again?
[16:56] <badcompiler> hmm if i run the command ffmpeg -i output.mov -vcodec copy -acodec copy output2.mov, I get no change in the duration from ffprobe. In other words the inital 40 milliseconds added is still there but doesn't increase on second copy
[16:57] <badcompiler> is there a built in padding time or something....
[16:58] <klaxa|work> i would assume it has to do with ffmpeg's mov muxer which apparently is slightly different from apple's one
[17:00] <badcompiler> if I remux again that file to a mkv , it adds 200 milliseconds !  ffmpeg -i output.mov -c:v libx264 -preset slow -crf 22 -c:a copy output.mkv
[17:00] <badcompiler> so thats 240 milliseconds from the original mov
[17:01] <badcompiler> intresting you say that klaxa|work, because, the issue I'm trying to get to the bottom of, is incorrect audio sync playback in apple quicktime player !!
[17:01] <badcompiler> and the first place I started looking was the difference in duration ffmpeg is adding when transcoding from mov files
[17:02] <badcompiler> I dearly want to replace a production pipeline using ffmpeg and open source, but so far issues like these mean I have to slip audio and video streams by a few frames to compensate
[17:12] <badcompiler> I found this which seems like the same thing I'm seeing http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/175181
[17:32] <NucWin> is it posssible to tell the encoder to use half the bitrate of the source without knowing the sources bitrate before hand?
[17:34] <klaxa|work> can you tell what the number i'm thinking of is divided by 2?
[17:34] <NucWin> yes n/2
[17:36] <NucWin> i want to batch convert a lot of mkv's from h264 to h265 at half the bitrate
[17:36] <NucWin> but they all have slightly different bitrates
[17:36] <klaxa|work> well you can use ffprobe to get the bitrate
[17:49] <NucWin> no other suggestions before i use perl to do a nasty scrape on the output of ffprobe?
[18:57] <diegoviola> hi
[18:57] <diegoviola> can i make a gif from a video file?
[18:57] <diegoviola> animated gif
[19:00] <sacarasc> ffmpeg -i blah.rv -pix_fmt rgb output.gif
[19:00] <sacarasc> Maybe?
[19:01] <diegoviola> will try that, thanks
[19:17] <vlatkozelka> hi , i want to stream a video froma .ts file , the video is h264 encoded , i wanna transcode it to h265 cuz lower bitrate ... i tried -vcodec libx265 but the quality is really poor that the video isnt even showing at the client
[19:18] <vlatkozelka> also tried this : ffmpeg -i INPUT -c:a copy -x265-params crf=25 OUT.mov
[19:18] <vlatkozelka> but the quality is still really poor
[19:23] <sacarasc> What is the client?
[19:24] <vlat> oops
[19:24] <vlat> <sacarasc> What is the client?
[19:24] <vlat> <vlatkozelka> oh
[19:24] <vlat> <vlatkozelka> i mean when i played it on vlc or with ffplay
[19:24] <vlat> <vlatkozelka> wich is basically simulating a client
[19:25] <BtbN> keep in mind that there is no way you will ever be able to encode h265 in real time
[19:25] <vlat> im just pasting the conversatio before i DC ed
[19:25] <BtbN> sacarasc, he just posted what he already send but got disconnected... pastbining that seems overkill
[19:26] <sacarasc> No, pastebinning the whole of ffmpeg stuff.
[19:26] <vlat> alright
[19:26] <vlat> one sec
[19:26] <sacarasc> The output is the important bit, BtbN.
[19:26] <diegoviola> ok so that `ffmpeg -i output.mp4 -pix_fmt rgb24 output.gif` works, but how do i make it smaller?
[19:27] <sacarasc> diegoviola: Video dimensions or HD space?
[19:27] <diegoviola> both
[19:27] <BtbN> vlat, if you want to live stream h265, you better have 32 physical cores or more
[19:27] <diegoviola> sacarasc: not too small, just a compression of both
[19:27] <diegoviola> small compression
[19:28] <sacarasc> I think gifs can do -q, also, -vf scale should work as normal.
[19:28] <diegoviola> thanks
[19:28] <vlat> sacarasc : http://pastebin.com/PitGVyrc
[19:28] <vlat> i do have that available
[19:28] <vlat> well im just testing one video on my pc but for the real thing i have that processing power available
[19:29] <BtbN> you never told it which encoder to use
[19:29] <BtbN> so it defaults to mpeg2
[19:29] <sacarasc> Yeah, that. ^
[19:29] <vlat> me ?
[19:30] <sacarasc> Yeah, you need -c:v libx265
[19:30] <vlat> i also tried that
[19:30] <vlat> the bitrate is really low with that
[19:31] <BtbN> That
[19:31] <BtbN> 's the whole point
[19:31] <vlat> and the video doesnt show on the client
[19:31] <vlat> one sec ill try again
[19:32] <vlat> oh lol
[19:33] <vlat> i see now my cpu jumped to 100%
[19:33] <vlat> i guess thats the problem
[19:34] <vlat> well ... i will try tomorrow on the server we have at work
[19:34] <vlat> thanks for the help guys :)
[19:36] <BtbN> i wasn't joking about the 32 cores
[19:36] <vlat> yeah i see
[19:36] <vlat> that compression must've killed my cpu
[19:36] <vlat> but it should work with that command on a better server right ?
[19:36] <BtbN> it should allways work
[19:36] <BtbN> just be extremely slow
[19:37] <vlat> hmm
[19:37] <vlat> lowering res and framerate (idc if slow just for a test ) might make it work here
[19:37] <vlat> ?
[19:37] <vlat> just for the sake of testing it
[19:38] <BtbN> transcoding an entire 30 minute video would propably take hours
[19:39] <vlat> ahh
[19:39] <vlat> hmm
[19:39] <vlat> i could instead of live streaming it , transcode it first  , save , then stream ?
[19:39] <vlat> or would i lose the low bitrate ?
[19:40] <BtbN> that's your only option if you don't actualy have 32 fast CPU cores
[19:40] <vlat> alrithy then
[19:40] <BtbN> Or just go with h264, nothing wrong about it
[19:40] <vlat> its wrong when ur boss nags :/
[19:40] <vlat> "PEOPLE ARE USING H265 ... WE SHOULD TOO :@ "
[19:41] <vlat> :P
[19:44] <vlat> well since u wannna know "whats wrong about it " , in my country internet is real slow so using lower bitrate would give me an advatage ;)
[19:44] <Baked_Cake> i can encode a 2 hour movie in x265 in about 30 hourss
[19:44] <Baked_Cake> thats with 64 bit ffmpeg
[19:45] <Baked_Cake> veryslow setting
[19:45] <Baked_Cake> but the result is a work of art
[19:45] <Baked_Cake> my cpu hates decoding it tho
[19:45] <vlat> haha
[19:46] <Baked_Cake> hogs up 20% and spikes at 30%
[19:46] <vlat> the last app i made took 60 %
[19:46] <vlat> but it was decodeing 30 videos at once and displaying them
[19:46] <vlat> and recording
[19:46] <vlat> :P
[19:46] <Baked_Cake> damn
[19:46] <vlat> yeah was for millitary purpose
[19:47] <vlat> i love programming for people who have super computers lol
[19:47] <vlat> there's just no limits :P
[19:47] <Baked_Cake> ya
[19:48] <Baked_Cake> gotta get those confesions compressed and sent out to the magistrate
[19:52] <BtbN> If you want to stream to normal users, h265 is a poor choice anyway. It easily overloads client machines.
[19:52] <BtbN> I'd not use it untill h265 hw decoders have become a common thing
[19:58] <vlat> ok :)
[19:58] <vlat> thx
[20:45] <voip_> hello guys i have same eroors
[20:45] <voip_> invalid band type
[20:45] <voip_> Error while decoding stream #0:0: Invalid data found when processing input
[20:46] <voip_>  SSR is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[20:46] <voip_> [aac @ 0x3d02a20] If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel at ffmpeg.org)
[20:46] <voip_> Error while decoding stream #0:0: Not yet implemented in FFmpeg, patches welcome
[20:46] <voip_> log: http://pastebin.com/kjvGw71J
[21:23] <diegoviola> how do i shrink file size when generating a gif?
[21:23] <diegoviola> ffmpeg -i output.mp4 -vf scale=640:-1 -r 10 output2.gif
[21:24] <diegoviola> i have this
[21:32] <xqdr> hello, has anyone tested https://github.com/drocon11/ffmpeg-qsv ?
[21:33] <xqdr> I compiled it on ubuntu x64, kernel 3.8.0-29generic, with IntelMediaSDK2014R2
[21:33] <xqdr> without any problems, but when I try using h264_qsv codec I get a segfault
[21:41] <lkiesow> Hi, I already asked this on the ffmpeg-users list but as I didn't get an answer yet, I might as well try it here again.
[21:41] <lkiesow> Yesterday a college of mine brought to my attention the following sentence from the FFmpeg wiki:
[21:41] <lkiesow> If you use -ss with -c:v copy, the resulting bitstream might end up being choppy, not playable, or out of sync with the audio stream, since ffmpeg is forced to only use/split on i-frames.
[21:41] <lkiesow> I'm regularly using bitstream copy (-ss as input option) together with seeking and can't remember having any problems. Is this statement still true?
[22:27] <diegoviola> I can't find a way to decrease the image quality in ffmpeg when generating a gif file
[22:27] <diegoviola> any ideas
[22:27] <diegoviola> I'm looking to get a small file size
[22:33] <Nitori> gif is not that flexible.
[22:36] <diegoviola> what do you suggest i use instead?
[22:36] <diegoviola> webm?
[22:37] <thebombzen> lkiesow: bitstream copy means it won't decode the file when it copies (you know this). This means it can't seek to anywhere, but only to the edge of one coding Block. If the video is encoded for streaming, this shouldn't be much of an issue because they have really small blocks. If the video is encoded for storage, you could have very large blocks and that makes the compression ratio better.
[22:38] <thebombzen> But it makes seeking way harder. Those are the ones it might mess up on
[22:42] <llogan> diegoviola: you'll probably get better results outputting to png then using convert from imagemagick or graphicsmagick to create the gif
[22:42] <llogan> AFAIK
[22:44] <diegoviola> ok i'll try that, ty
[22:47] <lkiesow> thebombzen: But wouldn't that just mean that the seek point is off a bit? So you end up a second before the actual seek point
[22:47] <lkiesow> The wiki says it might be not playable
[22:53] <voip_> llogan, hello yestorday i asced about 150 livestream transcode processing you said i must use VBV. You tinking i can decrease CPU's usage ?
[22:54] <llogan> lkiesow: refer to the docs when in doubt. note that the "Community Contributed Documentation" (which includes the article you referenced) section of the FFmpeg Wiki is often written by users who may not substatiate claims
[22:55] <llogan> voip_: using VBV is not about reducing CPU usage, but for providing a reliable stream (as in no buffer waiting except during beginning)
[22:57] <llogan> instead you're just declaring an apparently arbitrary bitrate
[22:58] <voip_> i know, int not about CPU usage , beacuse a im asking again:) I have no problem with bitrates. I need to buld system for trnscoding 150 streams
[22:58] <voip_> i realy dont know how many servers and CPUs i need
[22:59] <llogan> you'll just have to run some tests
[23:00] <lkiesow> You are right, but there seemed to be a reason in the past why it wouldn't work ao I am a bit worried. And I couldn't find something that made things clear in the official docs. Though from what I read I would *guess* that using -ss as input option together with -c copy is safe
[23:01] <lkiesow> &while -ss as output option together with -c copy miht not work
[23:01] <voip_> llogan, did you ever benchmarked aproximatly how many streams can processed intel xeon with 6 cores with fast preset ?
[23:01] <llogan> lkiesow: i've never really had any trouble with it, IIRC, using it either way
[23:02] <llogan> voip_: no. and it depends on too many factors for me to be able to give you an actual number.
[23:02] <voip_> ok
[23:03] <llogan> just try it
[23:03] <lkiesow> llogan: Me neither and I do a lot of encoding :)
[23:03] <lkiesow> anyway, thanks for the reply
[23:05] <llogan> lkiesow: you can ask the author for more details or why he added that. looks like it was added on version twelve by slhck. his site is slhck.info
[23:17] <lkiesow> ok, thanks
[23:46] <lkiesow> Seems like the sections was originally introduced on version six by rogerdpack
[23:47] <lkiesow> *section
[00:00] --- Fri Aug 29 2014


More information about the Ffmpeg-devel-irc mailing list