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

[burek]

[00:21] <killown> why ffmpeg in any circumstances when using it for screen casts, all videos are outsync from audio due to a little slowdown in the rendering...?
[00:21] <killown> what can I do to record screencast without lag?
[00:21] <killown> at 1080p
[00:22] <durandal_1707> what version of ffmpeg you use?
[00:22] <killown> killown at killown:~/Diversos$ ffmpeg --version
[00:22] <killown> ffmpeg version 1.2.1 Copyright (c) 2000-2013 the FFmpeg developers
[00:22] <killown> I am using this ffmpeg -f alsa -ac 2 -i pulse -f x11grab -s hd1080 -r 24 -i :0.0 -vcodec libx264 -crf 0 -preset ultrafast -an -y video.mkv -acodec pcm_s16le -vn  -y audio.mkv
[00:32] <killown> what's the problem with ffmpeg in recording screens?
[00:32] <killown> it has been in that way since long time ago
[00:50] <killown> what hardware is needed for don't have outsync issues?
[01:33] <killown> my issue was I/O problem, recorded the video in the tmpfs and now it's fine
[01:34] <killown> 2343MBvideo/95minutes == 24MB/s but http://bpaste.net/show/O2bfPzKS9pand8tS3ljh/ should be capable
[01:38] <killown> /minutes/seconds
[01:42] <killown> ffmpeg -f alsa -ac 2 -i pulse -f x11grab -s hd1080 -r 24 -i :0.0 -vcodec libx264 -crf 0 -preset ultrafast -an -y video.mkv -acodec pcm_s16le -threads 0 -vn  -y audio.mkv   <<<< is there something here I can do to reduce the I/O usage?
[01:56] <brx_> anyone here using vlc to stream videos?
[06:29] <taqattack> Does ffmpeg support Intel QuickSync feature?
[06:30] <taqattack> It seems like Handbrake has it implemented. I thought Handbrake was a just a wrapper for ffmpeg.
[06:30] <taqattack> so I'm guessing it might have been added already
[07:25] <Sashmo> does anyone know of what the bootlegers use to auto detect commercials?
[08:21] <defaultro> hey folks,  fade=out:975:25, quick question. What if I don't know the total frames of the video but I know how many frames I like to fade, how do I do that?
[08:21] <defaultro> Is it like this, fade=out::25
[09:35] <bjartwolf> I had some issues with ffplay and node.js, the logoutput seems to be blocking. ref https://github.com/joyent/node/issues/5610
[09:36] <bjartwolf> basically it seems to be blocking when writing the log, whereas some of the node.js developers claims that might not be nescessary and that I could take it upw ith you. Personally I don't really care that much about the issue, as I've resolved/worked around it on my part, but I thought I should bring it up
[09:37] <bjartwolf> Just in case it is some room for improvement here.
[09:42] <Mavrik> bjartwolf, I suggest you post a bug on bugtracker about the blocking output, the easiest way to make the dev team see it :)
[09:43] <bjartwolf> Mavrik: oki, I'll do that
[09:43] <Mavrik> and thanks ;)
[10:05] <SATALIN> ffmpeg slower than android native mediaplayer for mp4.. )))
[10:06] <Mavrik> of course it is.
[10:25] <burek> bjartwolf, seems like you forgot to redirect stderr to /dev/null
[10:29] <burek> SATALIN, ffmpeg is not a "native java" product, so it's ok if it doesn't work as a native Java app
[10:30] <Mavrik> the difference is actually that native mediaplayer uses HW accel and draws directly to screen framebuffer
[10:32] <SATALIN> I thought It should be the opposite
[10:36] <Mavrik> SATALIN, what made you think that? :)
[10:41] <burek> defaultro, there is no such option in fade filter so far, but you can monitor this ticket to see if/when it's going to be implemented: https://ffmpeg.org/trac/ffmpeg/ticket/2631
[10:44] <burek> taqattack: did you read this ticket: https://ffmpeg.org/trac/ffmpeg/ticket/2591
[10:52] <SATALIN> Mavrik: no comments
[10:52] <Mavrik> ?
[11:39] <NovamediaDev1> Hello, anyone can tell what maybe cause of SIGSEGV in av_write_frame? I am using statically compiled libraries from 1.2.1 tar ball, av_write_frame.
[11:39] <NovamediaDev1> This is from backtrace: #0  0x0000000000a707ff in av_write_frame (s=0x7fff08012940, pkt=0x2a873f8) at libavformat/mux.c:516
[11:39] <NovamediaDev1>         ret = <optimized out>
[11:42] <burek> NovamediaDev1
[11:42] <Mavrik> hmm, those lines don't really match up with the newest version :)
[11:43] <Mavrik> NovamediaDev1, which version are you using? are you calling ffmpeg API or is that ffmpeg binary?
[11:44] <NovamediaDev1> Marvik1 this is binary file, that we compiled from source from 1.2.1 tarb ball
[11:45] <NovamediaDev1> i mean, statically linked library
[11:46] <NovamediaDev1> Hm  sorry now i understand not it is not a binary file as ffmpeg command line tool , it is call from C++ code to ffmpeg api
[11:47] <Mavrik> ah, that explains it :)
[11:48] <Mavrik> NovamediaDev1, hmm, the only reason that would crash is if your AVFormatContext would be wrong
[11:49] <Mavrik> that is, the ->pb property would be broken
[11:49] <NovamediaDev1> One more thing, it is working, on x86 architecture, but sigsegv occurs on arm architecture, it is  TEGRAIII
[11:49] <Mavrik> ah, now it gets interesting :)
[11:49] <Mavrik> I suggest compiling ffmpeg wihtout optimizations
[11:49] <Mavrik> and with debug symbols enabled
[11:49] <Mavrik> so gdb will show you full stack trace with variables when core dump happens
[12:50] <Diogo> hi
[12:56] <Diogo> to generate more than 2 thumbnails ubitux help me with this command..
[12:56] <Diogo> command: /servers/ffmpeg/bin/ffmpeg -i "rod.mp4" -filter_complex 'split[a][b][c]; [a] scale=-1:360 [o360p]; [b] scale=-1:240 [o240p]; [c] scale=-1:480 [o480p]' -map '[o360p]' -frames:v 1 out-360p.png -map '[o240p]' -frames:v 1 out-240p.png -map '[o480p]' -frames:v 1 out-480p.png
[12:56] <Diogo> appear this error: No output pad can be associated to link label 'c'.
[12:57] <ubitux> no i provided a working commad ;)
[12:59] <Diogo> ubitux: i know that :)
[12:59] <Diogo> this is a stupid error
[12:59] <Diogo> if i remove the [c] works
[13:00] <Diogo> thanks for the help i adapted your command for my scenario
[13:00] <Diogo> but not working
[13:00] <ubitux> split=3
[13:00] <ubitux> by default split has n=2
[13:21] <damir__> hello
[13:34] <SATALIN> damir__: alloha
[13:36] <damir__> i'm having some problems with mpeg2video encoder regarding rc-buffer
[13:36] <damir__> if there's anyone here that could clear up some things for me that would be great
[13:37] <thetruthisoutthe> oh http://en.wikipedia.org/wiki/Trinidad_Moruga_Scorpion  looks harmless juicy fruit, i feel like slicing one up, put on a slice of buttered bread, and bite in it
[13:47] <damir__> my problem are changes between static and dynamic scenes
[13:48] <damir__> i'm streaming cbr and using rate control
[13:49] <damir__> when transiting to dynamic video from static image, video gets blocky (rc overflows), but in time it gets better
[13:49] <damir__> if i'm only encoding video, no static images, video is OK at all times
[13:49] <damir__> so i'm quessing quant doesn't adapt quick enough?
[13:50] <damir__> i'm setting max-qdiff to 30..
[13:50] <damir__> but there's also larange mult and macroblock quants that I'm not sure if they're affected with max-qdiff
[13:50] <damir__> so this could be the problem
[13:51] <damir__> any input on this?
[14:11] <BuxiNess> What is the meaning of start_time in MPEG 2 PS case? Is often !=0. May i take this info when using concat operation?
[14:11] <BuxiNess> Or how to set this start_time to 0 ?
[14:30] <Diogo> ubitux: this is possible to change to n > 2?
[14:31] <ubitux> i told you how
[14:32] <Diogo> ohh split=3[...]
[14:32] <Diogo> thanks again ubitux
[14:32] <Diogo> :)
[15:19] <smlb> Hi, what cli command for `ffplay` for playing *.m3u files?
[17:24] <bunniefoofoo> I am trying to do average bitrate encoding with libav/libx264 and it seems to ignore my settings
[17:48] <bunniefoofoo> in avoptions passed to avcodec_open2() I have b=2350000,preset=fast,profile=main,level=31  and the file ends up with a bitrate ofa about 24 MBps
[17:58] <JEEB> bunniefoofoo, does that happen if you do two-pass encoding?
[17:58] <bunniefoofoo> havent tried, always first-pass
[17:59] <bunniefoofoo> it seems the only way "abr" works is if I have set a maxrate and bufsize too
[17:59] <JEEB> that's limited abr
[18:00] <bunniefoofoo> without the limit set it doesn't appear to constrain the bitrate at all
[18:01] <bunniefoofoo> final QP is like 2.4
[18:01] <JEEB> it does as far as I know libx264
[18:01] Action: JEEB takes a look at the ffmpeg's libx264 interface
[18:02] <JEEB> how old/new ffmpeg are you using?
[18:02] <bunniefoofoo> I guess I am missing something in my use of lav... it seems ffmpeg doesn't have this problem
[18:02] <bunniefoofoo> 1.2
[18:02] <bunniefoofoo> the last stable release I think
[18:04] <JEEB> x4->params.rc.i_bitrate   = avctx->bit_rate / 1000;
[18:05] <JEEB> so in theory that should be setting libx264's bit rate to the bit rate you set divided by 1000 because libx264 takes in kilobits/s
[18:05] <JEEB> it does the same for bufsize/maxrate
[18:05] <bunniefoofoo> yes I can see it in the libx264 options print
[18:05] <JEEB> ok...
[18:06] <bunniefoofoo> I compare that to same print with ffmpeg and they look almost identical to me
[18:06] <JEEB> what does rc=<something> say?
[18:06] <bunniefoofoo> abr
[18:06] <JEEB> ok, that's correct too
[18:06] <JEEB> what kind of input are you giving it?
[18:07] <bunniefoofoo> 720x480 yuv420p 29.97 fps
[18:07] <JEEB> and that is going in correctly? Although even with problematic stuff in most cases libx264's rate control should do it just fine...
[18:08] <JEEB> (unlike most encoders libx264 actually is /very/ strict about bit rate)
[18:09] <bunniefoofoo> one thing I get from the muxer (not libx264) is "Encoder did not produce proper pts, making some up", maybe that is a problem
[18:10] <JEEB> oh
[18:10] <JEEB> make sure your timestamps are correct, lol
[18:10] <JEEB> pts = presentation time stamp
[18:10] <JEEB> you input some into the encoder, and libx264 then outputs relative timestamps when it has encoded
[18:10] <bunniefoofoo> right, I think I am giving it a valid pts, it says it is giving me back an invalid one
[18:11] <JEEB> libx264 by definition shouldn't be giving you an invalid one :P
[18:11] <JEEB> so I am relatively sure of a PEBKAC there somewhere
[18:11] <JEEB> and that sounds like a timestamp mistake then indeed
[18:11] <bunniefoofoo> hm do I need to rescale timestamps after av_encode_video3
[18:12] <JEEB> the rate you set is correct, but it seems like the encoder thinks it's 1000 times slower or so?
[18:12] <JEEB> and thus you get a wrong-looking result
[18:12] <bunniefoofoo> hm
[18:12] <JEEB> in other words, time to see again what kind of timestamps you're giving to the encoder
[18:12] <bunniefoofoo> videoFrame->pts = av_rescale_q(videoFramesRead - 1,
[18:12] <bunniefoofoo>                 videoStream->codec->time_base, videoStream->time_base);
[18:13] <JEEB> uh, don't you get proper timestamps from your input?
[18:14] <bunniefoofoo> input is synthetic, I am getting a sequence of frames w/o timestamps on them
[18:14] <JEEB> then do check those timebases as well
[18:14] <bunniefoofoo> so take the frame sequence number and scale it, correct?
[18:14] <bunniefoofoo> ok
[18:15] <JEEB> just make sure you are putting in stuff that makes sense :P
[18:15] <bunniefoofoo> ok, should I have to rescale timestamps on output of avcodec_encode_video2() ? This used to be necessary with the older api
[18:23] <JEEB> can't answer those specifics, but it really sounds like you have a problem before that...
[18:23] <JEEB> although I'm not sure :P
[18:24] <JEEB> also you might have to rescale the output timestamps depending on the output container
[18:24] <JEEB> I've mostly coded within libavcodec, not used libav* myself
[18:28] <bunniefoofoo> the muxer says "90k tbn 29.97 tbc" however the stream timebase is 1/30k and the codec timebase is 1001/30000
[18:47] <bunniefoofoo> after I call avformat_write_header() the stream timebase changes to 1/30k (from 1/90k) is this typical?
[19:06] <bunniefoofoo> jeeb, it seems I have to feed frames using the codec timebase
[19:06] <bunniefoofoo> I was feeding frames using the stream timebase
[19:07] <JEEB> yeah, sounds how it should be
[19:07] <bunniefoofoo> I figured the codec would just pass those pts values through and maintain its own times internally but I guess not
[19:08] <bunniefoofoo> I still get the "proper pts" warning at the start, but abr encoding works now. Thanks for your help
[19:09] <JEEB> you should check what the warning's about I guess? But if the rate control seems sane then at least the timestamps libx264's getting are somewhat sane
[19:10] <bunniefoofoo> timestamps are definitely sane in and out, just using wrong timebases it seems
[19:10] <bunniefoofoo> It only prints on the first packet anyways
[19:15] <bunniefoofoo> when enabling rate control (vbv) should bufsize always be == maxrate ? If I don't do that  i seem to get vbv buffer underflow warnings
[19:18] <bunniefoofoo> arg now it seems I can't get vbv limits to work with x264
[19:19] <bunniefoofoo> it seems vbv was working before because I was feeding wrong timestamps
[19:19] <JEEB> bunniefoofoo, you're not enabling "rate control" with vbv
[19:19] <JEEB> vbv is an extra that you use in case of extra bandwidth limiting being needed
[19:20] <JEEB> f.ex. streaming over limited bandwidth
[19:20] <bunniefoofoo> I thought vbv was not only streaming but for mobile devices/embedded players with limited buffer memory
[19:21] <JEEB> yes, that might happen as well. Personally I yet haven't gotten a device that had problems there, but there are some crappy devices out there (some old old blackberries that did software decoding, and possibly some very first gen iphones?)
[19:21] <JEEB> not fully sure
[19:21] <JEEB> and no, bufsize and maxrate don't have to be the same :P
[19:22] <JEEB> maxrate is the maximum bandwidth, and bufsize is the buffer over which you calculate maxrate
[19:22] <JEEB> bufsize is usually something you know on both sides
[19:23] <bunniefoofoo> ok so I have seen in many places for ipod or maybe older iphone the maxrate=1.5mb and bufsize=2.0 mb. When I set these up x264 says I have vbv underflows.
[19:23] <bunniefoofoo> do I even care about underflows or only overflows?
[19:25] <JEEB> yes, you do. If you need those limits, anyways. Also it sounds like you're setting them wrong (or, with an older version, too strict in some way)
[19:25] <JEEB> also I think those limitations are only towards first-gen video-capable ipod and the first iphone methinks
[19:25] <JEEB> 3GS f.ex. already had a high profile / level 4.1 capable decoder
[19:26] <JEEB> also, any specific reason for using a bit rate based mode instead of crf?
[19:26] <JEEB> (constant rate factor, closest thing we currently have to "constant quality")
[19:28] <bunniefoofoo> main motivation is compatiblity, with as many devices as possible. This means a profile with vbv limits to pickup iphones or other devices prior to 3gs
[19:29] <bunniefoofoo> I have a 3gs profile that says it was level 3.0
[19:30] <bunniefoofoo> but main profile
[19:30] <bunniefoofoo> the older devices and somewhat recent androids are the issue, needs to be baseline profile and possibly vbv restricted
[19:31] <JEEB> that 3GS profile is mostly because of iTunes I guess, that's the main limiting point
[19:31] <JEEB> if you got a high/4.1 clip onto a 3GS then it would play just fine
[19:31] <JEEB> the decoder hardware is better than Apple wanted to support
[19:32] <JEEB> and iTunes generally only supports stuff that their own crappy encoder can output
[19:32] <JEEB> as for recent'ish androids, yeah. Although the last thing that really sucked for me was a '09 samsung, that thing failed deblocking, methinks
[19:32] <JEEB> didn't need vbv tho
[19:32] <JEEB> also you can still use vbv with crf
[19:33] <JEEB> so you first select a crf number that looks good enough for you on a couple of clips
[19:33] <JEEB> and then you limit that with vbv
[19:33] <bunniefoofoo> ok, will look at vbv and crf
[19:33] <bunniefoofoo> thanks
[19:33] <JEEB> default for libx264 is crf, value 23
[19:34] <JEEB> lower is more bit rate / possibly better quality
[19:34] <JEEB> higher is less rate / possibly worse quality
[19:34] <JEEB> idea is to find the highest that still looks good
[19:40] <bunniefoofoo> even with very high crf value (60) I still get vbv underflow?
[19:41] <JEEB> sounds like something going wrong again :)
[19:42] <JEEB> I mean, crf 60 starts putting denoising in there :P
[19:42] <JEEB> normal crf values go up to 51, same as with QPs
[19:42] <JEEB> so if you're getting underflows with that and some relatively sane values, you are most probably doing something wrong again
[19:43] <mgeary> hi folks
[19:44] <bunniefoofoo> yeah, somethings not right, i set rc_minrate, rc_maxrate, rc_buffsize, rc_initial_occupancy and still underflow
[19:45] <JEEB> bunniefoofoo, just for your information
[19:45] <JEEB> vbv only needs maxrate and bufsize
[19:45] <mgeary> hey, i'm trying to figure out why an MP3 file from ffmpeg is behaving strangely. I'm using jPlayer/HTML5 to play it back, and Safari reports the file as being 3:43, when it's actually ~5:45. In playback, Safari also gets "lost" sometimes, and jumps back to the beginning.
[19:45] <JEEB> in a standard case nothing else is needed
[19:45] <bunniefoofoo> yeah I figured that, tried that first and did not work
[19:46] <mgeary> Creating an MP3 file from the same source (a FLV file) using an older version of ffmpeg produced the desired results in Safari
[19:46] <mgeary> lemme get the conversion output
[19:48] <mgeary> http://pastebin.com/1wst7Ud8
[19:49] <mgeary> so, i guess it's also worth noting that the input FLV file is also a bit "weird", and it does report to QuickTime that it's duration is 10:20, with the last ~5 minutes being pure silence. This silence gets (correctly?) cut off in mp3 conversion, though i'm not doing that intentionally
[20:50] <fbe> hi
[20:51] <fbe> i'm trying to record a screencast with ffmpeg. i start ffmpeg with ffmpeg -report -f x11grab -s 1920x1080 -i :0.0+2560,0 -vcodec libx264 -preset medium -threads 0 -r 29.97 foo.mp4 but in my screencast the green color of my terminal font is really .. weak
[20:52] <fbe> not as bright as on my normal terminal, bad contrast, really flat
[20:52] <fbe> is there an option to fix this?
[20:53] <durandal11707> try -vcodec libx264rgb
[20:56] <fbe> durandal11707: didn't change anything, still flat colors
[21:00] <durandal11707> what you use to play recoreded video?
[21:02] <fbe> durandal11707: mplayer
[21:06] <LithosLaptop> try: ffmpeg -report -f x11grab -s 1920x1080 -i :0.0+2560,0 -vcodec libx264 -pix_fmt yuvj444p -preset medium -threads 0 -r 29.97 foo.mp4
[21:10] <fbe> LithosLaptop: http://imagebin.org/index.php?mode=image&id=260107 result..
[21:14] <LithosLaptop> if you use some other lossless codec does it do the same?
[21:17] <fbe> yep, same problem
[21:18] <LithosLaptop> ok, what does ffmpeg detect the input as? argb?
[21:19] <LithosLaptop> it is either the player's fault or the input is not read as RGB...I think
[21:21] <fbe> hm ok, then this colors have to do. thanks
[21:23] <LithosLaptop> do you have ffmpeg log?
[21:24] <LithosLaptop> just up untill it starts encoding
[00:00] --- Tue Jun  4 2013