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

[burek]

[01:20] <jjx1> hi  guys
[01:20] <jjx1> i need help
[02:21] <LanDi> hey guys... I'm getting a very low framerate with this command...
[02:21] <LanDi> ffmpeg -f v4l2 -framerate 30 -video_size 1280x7200 -i /dev/video0 output.mkv
[02:21] <LanDi> can anyone help me ?
[02:21] <c_14> try adding -preset ultrafast
[02:22] <LanDi> c_14: after which argument ?
[02:23] <c_14> before output.mkv after /dev/vdea0
[02:24] <LanDi> c_14: it still very low :(
[02:24] <c_14> What version are you running?
[02:25] <LanDi> c_14: http://pastebin.geany.org/VGU15/
[02:25] <LanDi> that's the output
[02:25] <LanDi> c_14: 2.5.4
[02:25] <c_14> Can you pastebin the output on stderr as well?
[02:26] <LanDi> c_14: just tell me how
[02:33] <c_14> ffmpeg command 2>&1
[02:39] <LanDi> c_14: http://pastebin.geany.org/Ijetm/
[02:39] <LanDi> is it right?
[02:40] <c_14> yep
[02:40] <llogan> The driver changed the time per frame from 1/30 to 2/15
[02:42] <LanDi> when I'm running Kamerka I can get 30fps... don't not why I can not record with this framerate with ffmpeg
[02:42] <llogan> v4l2-ctl --list-formats-ext
[02:43] <LanDi> dont know*
[02:43] <LanDi> llogan: http://pastebin.geany.org/zPmrR/
[02:45] <c_14> set the input format to mjpeg, -input_format mjpeg (probably)
[02:46] <LanDi> c_14: before -video_size ?
[02:46] <llogan> you're choosing 1280x960, but that only allows 7.5 fps
[02:46] <c_14> Your camera can't produce yuv at that speed at that resolution
[02:46] <c_14> ye
[02:46] <llogan> nevermind. i was looking at raw
[02:46] <LanDi> I'm trying to record at 1280x720
[02:47] <llogan> see the output you just provided. the camera can supply yuyv422 (raw) or mjpeg. it lists available frame sizes and frame rates at those sizes
[02:48] <llogan> in ffmpeg, to choose the format of the input use -input_format as c_14 mentioned.
[02:48] <LanDi> yeah
[02:48] <llogan> by default it will choose yuyv422
[02:48] <LanDi> llogan: so, it says I can record at 30fps on 1280x960
[02:49] <llogan> as mjpeg
[02:49] <llogan> not as the other format
[02:49] <LanDi> ffmpeg -f v4l2 -framerate 30 -input_format mjpeg -video_size 1280x720 -i /dev/video0 -preset ultrafast output.mkv
[02:49] <LanDi> but this command is not working
[02:49] <LanDi> :(
[02:49] <c_14> error?
[02:50] <llogan> unfortunately "not working" is not informative
[02:50] <LanDi> nope, it just record with a very low fps as well
[02:50] <c_14> output?
[02:50] <LanDi> this last command actually makes ffmpeg record with less than 1fps
[02:51] <LanDi> ohh, now I've got 14fps... hmm
[02:52] <LanDi> c_14: llogan http://pastebin.geany.org/7KLMD/
[02:54] <c_14> hmm, that looks fine now. might be cpu issues now. Can you replace the -preset ultrafast with -c:v copy ?
[02:58] <LanDi> c_14: it's better with -c:v copy...
[02:58] <LanDi> but I'm getting a lot of messages: [matroska @ 0x25b36c0] Non-monotonous DTS in output stream 0:0; previous: 2115, current: 2058; changing to 2115. This may result in incorrect timestamps in the output file.
[02:59] <c_14> ye, that was just a test. Looks like your cpu is too slow for a realtime 30fps 1280x720 libx264 encode
[03:00] <LanDi> c_14: what ? it's an core i7
[03:01] <LanDi> c_14: http://pastebin.geany.org/BtaXr/
[03:02] <c_14> erm, interesting
[03:02] <c_14> Can you try -c:v ffvhuff ?
[03:05] <LanDi> c_14: hmmm better
[03:05] <LanDi> but not 30fps yep
[03:05] <LanDi> yet*
[03:06] <c_14> What fps did -c:v copy give you?
[03:06] <LanDi> max 20
[03:07] <c_14> And wth ffvhuff?
[03:07] <LanDi> 15
[03:08] <LanDi> ohh sorry, I meant the opposite
[03:09] <LanDi> but I get a lot of error messasges from -c:v copy
[03:10] <LanDi> c_14: wait... I have an idea.. why not just use vlc to capture and ffmpeg to record my desktop/vlc window ?
[03:10] <c_14> ffvhuff gets you more fps than copy ?
[03:11] <c_14> If you're going to do that, at least use vlc to stream/save the video, don't grab the x11 screen
[03:11] <LanDi> c_14: copy is a mess
[03:11] <LanDi> ok
[03:12] <c_14> But I'm pretty sure that if ffmpeg isn't getting enough frames, vlc won't either.
[03:12] <llogan> your camera may be automatically reducing frame rate if there isn't enough light
[03:12] <LanDi> hmmmmmmm
[03:13] <LanDi> llogan: interesting
[03:58] <k_sze> Hi guys,
[03:59] <k_sze> I vaguely remember that there is a certain constraint about resolutions for certain video codecs (like, the width and height need to be multiples of 16 or something). Is libx264 one of them?
[04:00] <c_14> Only with certain pixel formats
[04:00] <c_14> yuv420 w/h divisible 2
[04:00] <k_sze> sure
[04:00] <k_sze> same for yuv422
[04:00] <c_14> With yuv422 it's only one of them iirc
[04:00] <c_14> Don't quote me on that though
[04:01] <k_sze> (well, yuv422 requires width divisible by 2)
[04:01] <k_sze> because of the way it encodes pixel data.
[04:01] <c_14> ye, but I don't think it needs the height
[04:02] <k_sze> Yes, that's logically understandable.
[04:03] <k_sze> I'm sure I saw something crazier (seriously, multiples of 16 for some reason), but I can't remember what pixel format/codec it was.
[04:04] <c_14> I know they exist, I don't know what they are.
[10:01] <k_sze[work]> How does frame data alignment work?
[10:02] <k_sze[work]> I have a 1294x964 yuv422p video, in H.264, in a nut file. The planes are coming out larger than I expect
[10:03] <k_sze[work]> 1295616 bytes, 647808 bytes, and 647808 bytes for the Y, U, and V planes, respectively
[10:03] <k_sze[work]> which are slightly larger than the 1247416 bytes, 623708 bytes, and 623708 bytes that I expect.
[10:07] <Mavrik> k_sze[work], your frame size is height * stride
[10:07] <Mavrik> or linesize as ffmpeg calls it
[10:07] <Mavrik> not height*width
[10:08] <Mavrik> because linesize/stride takes into account any codec alignment optimizations
[10:14] <k_sze[work]> You mean this: http://ffmpeg.org/doxygen/trunk/structAVFrame.html#aa52bfc6605f6a3059a0c3226cc0f6567
[10:19] <k_sze[work]> So in the data array, I would need to ignore the last few bytes for each line?
[10:21] <k_sze[work]> (instead of ignoring a big chunk at the end of the plane)
[10:21] <Mavrik> yes
[10:22] <Mavrik> among other things
[10:22] <k_sze[work]> among other things...
[10:22] <Mavrik> your full framedata will be sized at height * linesize[index]
[10:22] <Mavrik> that's the full buffer
[10:23] <Mavrik> but the actual lines can be aligned and can have invalid data in them
[10:23] <Mavrik> it also depends how the decoder is passing you data - if it's split on planes or everything is stuffed in data[0]
[10:23] <k_sze[work]> it's in planes
[10:25] <k_sze[work]> How large is the linesize is an array that contains one value for each plane, right?
[10:25] <k_sze[work]> ugh
[10:25] <k_sze[work]> linesize is an array that contains one value per plane, right?
[10:25] <Mavrik> yep
[10:25] <Mavrik> linesize[0] is for data[0]
[10:25] <Mavrik> etc.
[10:26] <k_sze[work]> "but the actual lines can be aligned and can have invalid data in them" - what do you mean?
[10:27] <Mavrik> uh
[10:27] <k_sze[work]> can you make up a simple line with A, B, C as valid data and X as gibberish?
[10:27] <Mavrik> in frame, you can have a bit of grabage/padding at the end of each horizontal line
[10:27] <Mavrik> due to alignment
[10:27] <k_sze[work]> right, that's what I understand
[10:27] <Mavrik> e.g. if you have a linesize of 764 and your frame width is 720
[10:28] <Mavrik> you'll have 44px of garbage between each line
[10:28] <k_sze[work]> which is why I guess I have to ignore the last few bytes for each line
[10:28] <Mavrik> that's what I meant :)
[10:28] <k_sze[work]> ah
[10:28] <k_sze[work]> Thanks. :)
[10:28] <Mavrik> so when you decode data for display, you listen to width
[10:28] <Mavrik> but when you iterate / move over data to find a start of a line, you listen to linesize
[10:28] <Mavrik> most image processing frameworks take that into account, so usually you can just pass them the buffer and give them width and linesize (also called stride)
[10:28] <k_sze[work]> The same thing never happens for the height? (i.e. never garbage at the bottom of the picture?)
[10:29] <Mavrik> nop, only width
[10:29] <k_sze[work]> I see
[10:40] <k_sze[work]> One more question: does this alignment optimization happen at encoding time or decoding time?
[10:48] <jthemovie> Hi Everyone
[10:48] <jthemovie> I noticed that version around > 2.4 always compile with tls_verify
[10:49] <jthemovie> i manually specified in the ./configure the following option disable-gnutls and enable-openssl
[10:50] <jthemovie> but it doesn't change anything, all the others libraries are compiled with libgnutls :(
[10:51] <jthemovie> So my only hope is to keep using ffmpeg 1.0.10 that doesn't include any kind of tls check
[10:51] <jthemovie> Any hope how to really get rid of tls check on upper versions?
[10:51] <jthemovie> Thanks a lot for your answer :)
[10:52] <jthemovie> ps: i compile ffmpeg 1.0.10 and 2.4.7 with the same exact parameter, withtout sucess
[11:33] <lilibox> hi
[11:34] <lilibox> i would like to know if here is any tool allows the newest ffmpeg builds easy compile as static
[11:35] <lilibox> includes all main codecs/formats
[11:35] <ramiro> lilibox: what operating system?
[11:47] <lilibox> centos/rhel
[11:48] <lilibox> and i would like also to know how deeply dev team cares about prores's new versions and new cameras from Blackmagic
[11:53] <ubone> o/ can ffmpeg cut a portion of a video without changing the quality of the output file, (just cut, no additional encoding)?
[11:54] <relaxed> lilibox: did you see http://johnvansickle.com/ffmpeg/ ?
[11:54] <relaxed> ubone: yes, you can copy the streams
[12:02] <ubone> is it ffmpeg -ss 190 / -t 13 -i in out ?
[12:05] <relaxed> ffmpeg -i input -ss 190 -t 13 out -c copy out
[12:06] <relaxed> you might fine -to useful too
[12:08] <relaxed> find*
[12:11] <ubone> ty i will try
[12:11] <iznogood> Hello guys, its my first time here, so if i am asking in wrong way or something similar dont hesitate to let me know. I am following this guide for installing FFmpeg https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu#ffmpeg  on my ubuntu vps, i startet missing arround with linux 3 weeks ago, so i am not a linux shark hehe. My question is "PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg
[12:11] <iznogood> _build/lib/pkgconfig" ./configure \"  is it correct understood that i need to put every variable inside now? i mean like --prefix, --extra and so on and run it one time or do i have to "PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \ --prefix="$HOME/ffmpeg_build" \ and hit enter and run every one of those variables like that ?  I am so sorry if my question
[12:11] <iznogood> is "stupid" but i hope there is some on out there that mind let me know the concept.
[12:12] <iznogood> dont mind* ofc ;)
[12:14] <ramiro> iznogood, did you try hitting enter and seeing the result? =)
[12:16] <iznogood> i did do it step by step firstly but i did come up with problems at libfdk-aac and libvpx
[12:16] <iznogood> so now i tryed put it all inside and run it
[12:16] <iznogood> and it seems to be working fine
[12:16] <iznogood> now i am at next step "PATH="$HOME/bin:$PATH" make"
[12:17] <iznogood> alot of things are happening hehe so i guess i am okay :)
[13:22] <leandrosansilva> Hello, I'm using libavcodec to encode videos (using VP8 codec) and I'd like to know if there is a way to preallocate the AVPacket used on avcodec_encode_video2 call so it will not be allocated for each frame I encode. What I need is basically allocate it only once and then use the same across the encoding process.
[13:52] <lilibox> relaxed, interesting, thank you
[15:57] <NoNet> I'm enabling fdk-aac for my ffmpeg build. Could someone who's gentoo savy take a look at my USE options and express an opinion regarding any potential conflicts or USE flags I should add? https://bpaste.net/show/733bd9ca6e77
[15:58] <NoNet> BTW - I update from latest git for roughly weekly.
[16:05] <BtbN> It's not possible to have a conflicting combination of gentoo useflags. If there is, you found a bug.
[16:17] <NoNet> BtbN: Thank you. That's good to know.
[16:22] <luc4> Hello! Anyone who knows if there is a place somewhere to underastand what is currently supported of vaapi in ffmpeg? I keep finding pretty outdated documents.
[16:24] <BtbN> luc4, the ffmpeg cli tools do not support vaapi at all.
[16:25] <luc4> BtbN: so the libs maybe?
[16:25] <BtbN> The vaapi support in libavcodec is limited to basic de-slicing and buffer filling, you still have to do the major part of dealing with libva on your end.
[16:26] <luc4> BtbN: yes, but does it mean? That I get callbacks with the decoded frames?
[16:26] <BtbN> no.
[16:27] <BtbN> You have to deal with libva on your own to get the frames from it.
[16:27] <BtbN> avcodec only fills the encodec data in the input buffer.
[16:29] <luc4> BtbN: I see. Any example code around that uses this to get the frames back?
[16:29] <BtbN> vlc uses this
[16:29] <luc4> BtbN: ah ok, I probably found that yes. Thank you.
[16:30] <BtbN> You have to decode them first though. libavcodec only fills the input buffer
[20:03] <NoNet> I was building ffmpeg and friends from git master and got a failure with x264-encoder: Detection of system libx264 configuration failed. I use the gentoo based distro. The log output was: https://bpaste.net/show/a849ae008c9c
[20:04] <NoNet> Suggestions? I can copy the git master ebuild to local and modify the ebuild if I know what to change.
[20:06] <kepstin-laptop> NoNet: err, that's building the 'x264-encoder' package; there's nothing to do with ffmpeg there.
[20:06] <kepstin-laptop> NoNet: you should probably file a distro bug.
[20:07] <NoNet> OK - I understand that but was hoping anyway. ;/ It's the first time it's failed for me.
[20:11] <kepstin-laptop> yeah, the way gentoo does the x264 build is kind of weird, it builds the shared libraries and command-line encoder separately
[20:11] <kepstin-laptop> even if you can't build the command-line encoder, you can still use ffmpeg to encode with x264, of course :)
[20:12] <c_14> The best thing with ffmpeg and x264 is the possible cyclic dependencies.
[20:15] <kepstin-laptop> huh, that might actually be why they split the libraries and command line tool in gentoo; i think only the x264 command line tool actually links to ffmpeg.
[20:17] <c_14> That would actually be a sane reason.
[20:25] <llogan> x264/libx264 is one of the few packages Arch separates. 8 vs 10-bit IIRC.
[20:26] <JEEB> it's because you can't have both in a single library
[20:27] <JEEB> I think you might be able to have a single x264 using multiple libx264s (LD_LIBRARY_PATH getting switched), but not having both 8 and {9,10}bit support at the same time
[20:29] <NoNet> OK - so basically, I don'
[20:30] <NoNet> don't need to worry about x264-encoder with ffmpeg. libx264 from their git master build fine. That works for me. Thank you
[20:33] <NoNet> The issue only came up because I decided last night I wanted support in ffmpeg for fdk-aac. I apparently need to transcode anything I want to watch on my android device from ac3 to aac before I load it.
[00:00] --- Wed Mar  4 2015