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

[burek]

[00:27] <llogan> hack_sesh: overlay has timeline support http://ffmpeg.org/ffmpeg-filters.html#Timeline-editing
[00:28] <llogan> JEEBsv: isn't afterburner on by default?
[00:29] <llogan> hack_sesh: nevermind, i see you already tried that, and now that i think about it enable would deal with both videos involved with overlay
[01:39] <vstemen> What is wrong with this command?
[01:39] <vstemen> ffmpeg -i 'xxx.mpeg' -f mp4 -g 30 -vb 1.4M -acodec copy -vcodec libx264 -pre:veryfast 'xxx.mp4'
[01:41] <vstemen> I keep getting the error, "at least one output file must be specified"
[01:41] <vstemen> What does it think xxx.mp4 is?
[01:41] <sacarasc> Remove -f mp4
[01:41] <vstemen> sacarasc, Nope.  same problem
[01:43] <vstemen> I have been using this very command line in scripts for the last couple of years with the "-vpre veryfast" option and
[01:43] <vstemen> now, with the new version, it  is making me use  -pre instead.
[01:43] <vstemen> But it doesn't work.
[01:43] <sacarasc> Ah, should be -preset:v veryfast.
[01:44] <vstemen> That give me "Preset veryfast specified for stream 0:0, but could not be opened."
[01:46] <vstemen> Apparently they removed the preset files from ffmpeg and are passing  those presets to x264 to use it built in presets.  But the documentation does not see to provide an actually working example of using the  new option.
[01:47] <sacarasc> -preset:v veryfast should work.
[01:48] <vstemen> OK.  give me a moment...
[01:50] <vstemen> Do you want the result of my original syntax or with " -preset:v veryfast" as suggested by sacarasc?
[01:50] <vstemen> fflogger
[01:51] <llogan> -preset:v veryfast (and fflogger is a bot)
[01:52] <vstemen> llogan, hah :-)  OK.
[01:53] <vstemen> OK:  http://pastie.org/8032582
[01:54] <llogan> "-pre:v" is not a vaild option, IIRC
[01:55] <llogan> at least for libx264
[01:55] <vstemen> llogan, That was suggested by sacarasc.  My original syntax was "-pre:veryfast"
[01:55] <sacarasc> -preset:v
[01:55] <vstemen> Which is what I thought I saw in other documentation
[01:56] <vstemen> ffmpeg help output shows "-pre preset  "
[01:57] <vstemen> OK.  I just tried "-preset veryfast" and that seems to be working.
[01:57] <vstemen> Looks like -preset:v veryfast works  also
[01:58] <vstemen> Apparently the help output is outright  wrong
[01:58] <sacarasc> You should use -preset:v over just -preset because some audio can also use presets...
[01:59] <vstemen> sacarasc, OK.  I was thinking that was probably the case.
[02:00] <vstemen> sacarasc, llogan,  thanks for the help.  ffmpeg is extremely powerful, but it can sure be frustratin with the lack of correct working examples.
[02:00] <vstemen> s/frustratin/frustrating/ :-)
[02:00] <llogan> -pre is used for the "text file" presets
[02:01] <llogan> generally in /usr/(local)/share/ffmpeg or in ~/.ffmpeg
[02:01] <llogan> as in "-vpre libvpx-720p"
[02:02] <vstemen> Yea, I was using the text file preset, but they removed all of the out of the new ffmpeg package, forcing me to use the x264 builtins.
[02:03] <vstemen> I just searched the installed doc, /usr/local/share/doc/ffmpeg1/ffmpeg.html, and there is no string "-preset" mentioned at all.
[02:03] <vstemen> ffmpeg docs are irritating to say the least.
[02:03] <llogan> the built in ones are better. the old text files were only rough copies and lacked some options.
[02:04] <llogan> also -tune was not an option with the text files
[02:04] <llogan> http://ffmpeg.org/ffmpeg-codecs.html#Private-Options
[02:04] <vstemen> Yea, I just wish they would have left the text presets there so it would  say working and then tell  you in the docs that they are depricated and give proper examples of the new synax.
[02:04] <llogan> that would be a nightmare to maintain
[02:05] <vstemen> why, they already still support the text presets anyway don't they?
[02:07] <vstemen> s/say working/stay working/
[02:07] <llogan> also, users tend to pick and choose random preset files not understanding that presets from x API version would not work with their version
[02:08] <llogan> https://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide might be of interest to you
[02:10] <vstemen> llogan, Yes it  is.  Thanks.  I will also bookmark the private-Options  link you have me.
[02:10] <vstemen> Looks like that  gets me  going.
[02:11] Action: vstemen starts working on updating his  scripts and notes
[02:14] <vstemen> hm..  also in http://ffmpeg.org/ffmpeg-codecs.html#Private-Options  there is no mention of the ":v" following -preset
[02:14] <vstemen> Nore is there any mention of it in https://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide
[02:15] <llogan> it is optional in your case
[02:16] <vstemen> I also just grep'd every file in /usr/local/share/doc/ffmpeg1 and no mention of preset:v.  How did you find that syntax?
[02:18] <relaxed_> patches welcome
[03:50] <jdolan> ubitux: i finally figured out what i had to do.
[03:51] <jdolan> i first pump each stream through ffmpeg to rewrite the TC's and produce CFR Flash. during this process, i up-sample the streams to 60fps before baking them back down to 24.
[03:52] <jdolan> the up-sampling ensures that the single frame of avatar images i push through show up in the resulting CFR video.
[03:52] <jdolan> once i have the two CFR .flv files, the overlay is trivial and works as expected.
[09:52] <taqattack> is there a way to make ffmpeg drop rtmp packets to keep it as close to real-time as possible?
[10:05] <AISICAO1> haha, same problem
[10:07] <AISICAO1> Did your ffmpeg receive rtmp packets from fms or red5 etc.?
[10:21] <taqattack> AISICAO1, well I'm actually streaming to fms
[10:22] <taqattack> fms receives everything but if I throttle the bandwidth
[10:22] <taqattack> ffmpeg sort of lags behind and increases over time
[10:23] <taqattack> ideally I want it to drop the packets
[10:24] <AISICAO1> taqattack: do you use flash player for streaming?
[10:25] <taqattack> No I'm using ffmpeg to stream to fms
[10:25] <AISICAO1> taqattack: ok
[10:26] <taqattack> I'm just looking to see if there any command line flags to keep ffmpeg as close to real-time as possible
[10:29] <AISICAO1> taqattack: I guess there is no method to do
[10:30] <AISICAO1> taqattack: real-time? you mean there are some clients watching the live at the same time?
[10:32] <taqattack> well the clients are connected to fms server. when I check the fms server gets increasingly delayed over time.
[10:33] <AISICAO1> taqattack: yes!
[10:33] <AISICAO1> i had the same problem
[10:35] <AISICAO1> if your client is flash player, try to reconnect the NetConnection if the buffer time out of 2 seconds, haha
[10:37] <taqattack> well i've tried that but the stream is still wayy behind
[10:38] <taqattack> like after 5 mins, its about 45 seconds delayed from real-time
[10:39] <AISICAO1> taqattack: !!!!
[10:40] <AISICAO1> would you reduce the bit rate?
[10:42] <AISICAO1> taqattack: I guessed the problem was caused by the network delay, after all, the RTMP is based on TCP
[10:45] <taqattack> yes. the problem is that the network doesn't stay constant
[10:46] <taqattack> but I still want to keep the stream at real-time
[10:46] <AISICAO1> taqattack: "like after 5 mins, its about 45 seconds delayed from real-time", try to "Reconnect" when its over 2 seconds?
[10:47] <AISICAO1> taqattack: foolish but effective, 2 seconds delay - reconnect - 2seconds delay - reconnect, haha
[10:47] <AISICAO1> taqattack: My english is poor, sorry, haha
[10:47] <taqattack> no problem, I understand what you're saying :)
[10:48] <AISICAO1> :-D
[10:48] <taqattack> however, that doesn't do anything because the server receives a delayed stream from ffmpeg. so the clients that connect to fms are still delayed by long time.
[10:50] <AISICAO1> you mean the packages received by fms were already delayed?
[10:50] <taqattack> yes
[10:51] <taqattack> because the network bandwidth isn't large enough
[10:53] <AISICAO1> try this quality setting: video: 5fps 8192kbps audio: speex 20kbps
[10:56] <taqattack> i'm using libx264
[10:57] <taqattack> network bandwidth is about 1500kbps
[10:59] <AISICAO1> current video bit rate is?
[11:00] <taqattack> well average is around 1200
[11:00] <taqattack> but sometimes its 1700 average
[11:01] <AISICAO1> the CPU usage rate?
[11:01] <taqattack> its low
[11:01] <taqattack> 20-30%
[11:02] <AISICAO1> ........
[11:06] <AISICAO1> Did you try 800kbps or lower?
[12:04] <phr3ak> could I normalize the audio while converting?
[12:05] <khali> phr3ak: you can apply an amplification factor, yes
[12:05] <khali> you have to figure out the factor manually though, AFAIK
[12:07] <phr3ak> thanks
[12:58] <khali> phr3ak: actually it seems you can use -af volumedetect at first pass to find out the right setting
[12:58] <khali> phr3ak: and then -af volume to actually adjust the volume
[13:05] <khali> are there popular sample aspect ratios other than 1:1 and 64:45?
[13:05] <JEEB> 64:45 o_O
[13:08] <JEEB> "NTSC" DVDs/BDs and most such anamorphic SD content that isn't specifically set otherwise is either 40:33 ("16:9") or 10:11 ("4:3"), for "PAL" it's 16:11 ("16:9") or 12:11 ("4:3")
[13:08] <khali> JEEB: well 64:45 is the standard for PAL DVD and DVB, you shouldn't be surprised?
[13:08] <JEEB> uhh, no
[13:09] <JEEB> the ones I mention are the standard ones for DVD productions
[13:09] <JEEB> SD blu-ray specification uses the same
[13:09] <JEEB> they're simplified off of certain analog-to-digital specifications
[13:10] <JEEB> (since DVD and friends are "digital containers for analog content", basically :V)
[13:10] <khali> JEEB: I've never seen any of the SAR you mention
[13:11] <JEEB> that's because most open source stuff uses the real 16:9/4:3 ARs instead, for whatever reason :P
[13:12] <JEEB> you can go and look at the specifications and stuff linked via http://ps-auxw.de/cgi-bin/ar-calc.pl
[13:12] <JEEB> the ones I listed are the values used in production encoding, and are simplified versions of what that calculator are based f.ex.
[13:13] <khali> JEEB: the SAR is written in the VOB file / MPEG TS, so I fail to see what "open source stuff" has to do with it
[13:13] <JEEB> uhh
[13:13] <khali> I start wondering if we are really talking about the same thing
[13:13] <JEEB> the SAR information as far as I know is just a flag that has values a la 1/2/3 for DVDs at least
[13:13] <JEEB> and for H.264/AVC for SD in blu-ray there are specific values written
[13:14] <JEEB> I can't give you the specification, but I can tell you that http://www.x264bluray.com/home/576p-pal follows the specification regarding that point :P
[13:14] <JEEB> and the 480 part
[13:14] <JEEB> at least with DVDs there is no explicit aspect ratio flag
[13:15] <JEEB> other than the vague preset value, which is to be taken as 40:33 / 16:11 for "NTSC"/"PAL"  for 16:9 f.ex.
[13:16] <JEEB> No idea how specific the flag in the transport streams is, never checked too thoroughly. But I wouldnt' be surprised that in some cases it'd be the same as for DVDs with SD if it's not specific
[13:17] <JEEB> that is, with MPEG-2
[13:17] <JEEB> AVC/H.264 at least has the possibility of explicitly specifying the SAR :)
[13:17] <JEEB> (and it seems to be used)
[13:21] <khali> and I hope the whole concept of SAR would go away with HD video and the BluRay...
[13:21] <khali> hoped*
[13:39] <JEEB> it's all fine as long as it's explicit
[13:39] <JEEB> when it's implicit and the source of that implicit flagging is hard to get to
[13:39] <JEEB> now that's a mess
[14:04] <khali> wow, I never thought upscaling a video would be so slow
[14:07] <JEEBsv> a basic bilinear/bicubic shouldn't be too slow, generally the slowness comes out of encoding that bigger result clip
[14:07] <JEEBsv> I think ffmpeg doesn't have anything fancier, like NNEDI3 and friends
[14:07] <khali> JEEB: ah, good point, I hadn't considered that
[14:08] <khali> JEEB: that being said I'm only taking snapshots every 10 seconds, I wouldn't expect a 1248x720 PNG to be that long to encode
[14:09] <JEEBsv> no idea :)
[18:22] <kauwlna> hi, i cannot figure out how to make really low bitrate vbr ogg vorbis encodings. the standalone encoder oggenc let's me use "-q -1" which from what i know is what libvorbis then recognises (aotuv allows for -2 iirc). with ffmpeg i only seem to be able to go as low as "-acodec libvorbis -aq 1"
[18:24] <kauwlna> with "-aq -1" i get a higher bitrate than with "-aq 1"
[20:39] <faraz_> hey guys! good morning from SF :)
[20:40] <faraz_> I'm using x264 with nalu_process (so it output individual but out-or-order NALs). Just wanted to know if there is a receive side RTP/h264 assembler utility or do I need to write one from scratch?
[20:41] <faraz_> Sounds like someone must've done this before so I don't wanna reinvent the wheel here
[21:02] <xlinkz0> i get this : http://codepad.org/QZuCAwav
[21:04] <derjanni> Good afternoon!
[21:05] <derjanni> Ive got a tool with crtmpserver working to stream my x11 desktop... Now I want to switch to ffserver, but how can I just pass through the incoming stream?
[21:05] <derjanni> I dont want it transcoded in ffserver
[00:00] --- Wed Jun 12 2013