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

[burek]

[00:17] <tg2> any way to find out a video bitrate for a particular stream inside a container using ffmpeg if ffprobe only finds the total bitrate for the audio+video?
[00:19] <tg2> http://pastie.org/private/qzfwhyxlxjlumapps5dkq
[00:19] <tg2> example
[00:19] <tg2> if I vcopy/acopy into an mp4 it shows the bitrate per channel
[00:30] <tg2> http://pastie.org/private/mveyy7goxskfms7zbcl8aa <-- after vcopy/acopy into an mp4
[01:55] <uglyoldbob> I have been looking at the segment documentation for ffmpeg and the documentation for ffserver but cannot figure how to use them to live stream a webcam. I  am using ffmpeg to stream to ffserver on a server, then ffmpeg on the remote server to grab from ffserver and output to a web directory using flowplayer to watch the stream. I am unable to watch the stream by doing this. Has anybody used ffmpeg and hls to stream a webcam?
[02:26] <uglyoldbob> I am using the following line for hls, "ffmpeg -v 9 -loglevel 99 -i http://127.0.0.7:8090/test.mpg -re -acodec libfaac -ar 44000 -b:a 48k -vcodec libx264 -s 426x250  -b:v 128k -vpre libx264-ipod320 -flags -global_header -map 0 -f segment -segment_time 10 -segment_list_size 10 -segment_list playlist.m3u8 -segment_list_type m3u8 -segment_format mpegts ${stream}_240p%05d.ts", does anybody see anything wrong with it?
[03:13] <uglyoldbob> can anybody explain the entry in the sample ffserver config that says(# Transcode an incoming live feed to another live feed,
[03:13] <uglyoldbob> using libx264 and video presets) ?
[04:11] <uglyoldbob> I pasted the output from my ffmpeg command at http://pastebin.com/MP5ZcuYG
[06:53] <funyun> hi. does anyone know how i can dump the raw ac3 audio track from a dvd video_ts directory?
[09:44] <`rm\x20-rf\x20\x> so http://atei.st/~tom/extractclip is the easiest way i've found of extracting a clip from a file without losing video and audio sync
[10:54] <mudkipz> can someone point me to a good resource for understanding x264 vbv rate control?
[11:54] <JEEB> mudkipz, the Iain Richardson H.264 book if you want to know about H.264 in general (should also probably mention about VBV), or the actual spec http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11466
[11:55] <JEEB> of course everything depends on what exactly you want to know
[11:55] <mudkipz> oh wow
[11:56] <mudkipz> Well, really I just want a basic intuition for how it works, what people mean by bitrate spikes, how it fills, etc..
[11:56] <mudkipz> Right now it's about 4 am, so I'm looking for something to read.
[11:56] <mudkipz> Mainly for rtmp streaming purposes.
[11:58] <JEEB> basically you set a buffer that you want the encoder to follow, as well as the maximum average bit rate within that buffer. That ends up with the result that if your transfer rate is at least maxrate, and your client buffers at least bufsize amount of data, you won't have to buffer ever again as long as the transfer is OK and if the encoder doesn't underflow
[11:58] <JEEB> (underflow = basically go over that maxrate over bufsize)
[11:58] <JEEB> I'm not too technical myself, but that is the basics
[11:59] <JEEB> you match your client and encoder on the bufsize and the maxrate is the minimum rate needed to be able to watch it
[11:59] <mudkipz> when you say client, you mean the person watching on the other end?
[11:59] <JEEB> if your specification for whatever you are doing/using specifies the buffer in seconds, then you calculate it with <maxrate>*<buffer amount in seconds>
[11:59] <JEEB> mudkipz, the player, receiving end
[12:01] <mudkipz> Right, but I'm trying to work out how to set it up on the sending side. Seems that setting too low a buffer = low quality, but too higher a buffer can cause bitrate spikes that may be higehr than the sending side's internet capabilities and may cause frame drops.
[12:01] <mudkipz> At least, that's my really bad understanding of what I've been seeing.
[12:02] <JEEB> you can't set up the sending side's bufsize without acknowledging what the receiving end does
[12:02] <JEEB> if you have control of both sides, you decide it, otherwise you match it to whatever is not in your control
[12:02] <JEEB> and yes, too small of a buffer is a bad thing for rate control
[12:03] <JEEB> and the spikes themselves are not a problem, the fact that your bufsize on the player and encoder side don't match is
[12:04] <mudkipz> Well, with rtmp you generally stream from your computer to an rtmp server and then that rmp server streams to lots of users using different flash based players. The flash based players seem to be able to handle large bufsize and well users generally have fairly good download speeds nowadays (compared to the average person's upload speed).
[12:04] <JEEB> then you get the limits from the thing that gives users the flash-based players?
[12:04] <JEEB> most streaming services have the limits in their FAQ/support/whatever
[12:05] <JEEB> some say explicitly the values, others just tell you the maxrate and the seconds of buffer
[12:05] <JEEB> where you use the maxrate * amount of seconds calculation
[12:06] <mudkipz> hmm
[12:06] <JEEB> there's nothing for you to really think about in that case :P
[12:07] <mudkipz> It's just that I never considered looking for that info on sites like livestream and ustream.
[12:07] <mudkipz> So I'm looking around now.
[12:08] <mudkipz> I know that ustream for example can handle people streaming at really high bitraes, several megabits, and about equal bufsizes (xsplit sets them 1:1, for example).
[12:09] <mudkipz> I'm more worried about streamers with really lousy upload.
[12:09] <mudkipz> I'm trying to figure out, like supposing I have a streamer with 0.5 megabit upload (really slow, generally considered bare minimum), if they were streaming using a fixed constant bitrate then they could just make sure that audio bitrate + video bitrate sit under 500 kbps.
[12:10] <mudkipz> but if they're using maxrate and bufsize then I can't just treat maxrate the same way I would a fixed constant bitrate upload.
[12:10] <mudkipz> Because their bitrate might spike up and choke their upload connection.
[12:10] <mudkipz> Like, how do I figure out the maximum that a bitrate can jump up given a maxrate and a bufsize.
[12:10] <mudkipz> and what is it exactly that makes it spike like that?
[12:11] <JEEB> any "too big" spikes come from too big bufsize if the maxrate is set correctly. And they're not bad in itself, as long as the encoder abides to the vbv
[12:11] <JEEB> The encoder is just using the amount of bits it has per second
[12:13] <JEEB> and even with "CBR" you would need vbv to be honest, due to the VBR nature of video formats :P Maybe some filling but there still would be a bufsize
[12:14] <mudkipz> I see. I'm just not sure how FMLE handles x264, I'd assumed it maintained the bitrate fixed regardless of quality.
[12:14] <JEEB> x264 itself handles VBV just as noted, yes
[12:14] <JEEB> i have no effing idea about FMLE naturally :)
[12:16] <mudkipz> okay, so assuming that the player on the client side can handle a huge bufsize and maxrate and that the viewers have really good download speeds, but that the streamer has a constrained upload at some value like 0.5 mbit/s how would I go about choosing a maxrate?
[12:18] <mudkipz> I've been testing several rtmp streaming programs with other streamers and none of us have any idea what a good bufsize is and if we're using maxrate how we expect to be.
[12:20] <mudkipz> general rule of thumb we've been using is to set bufsize 1:1 with maxrate (giving 1 second of buffer).
[12:20] <JEEB> I can't say anything else but that you should match your shit to the player/middleman
[12:20] <JEEB> poke them until they bleed
[12:20] <JEEB> just like you can't tango alone
[12:20] <JEEB> you can't maxrate/bufsize alone either
[12:20] <mudkipz> right
[12:20] <JEEB> also even if it's flash the different flash players can be set for different buffering
[12:21] <JEEB> it's not something set to something specific
[12:21] <mudkipz> how do you mean?
[12:21] <mudkipz> or do you just mean that different flash players can have different bufsize capabilities.
[12:22] <JEEB> yes, I just mean that the bufsize in flash isn't set in stone and the people who made the player probably set it to something
[12:22] <JEEB> :P
[12:23] <mudkipz> Right, of course.
[12:25] <mudkipz> Well thanks, I'll look more into this with that info.
[13:07] <slimjimflim> hi, anybody know how to convert a 720p mkv to a lower quality?
[13:14] <zap0> just do it.
[13:18] <slimjimflim> zap0: if i knew how to do it i wouldn't be asking
[13:19] <zap0> what do you have so far?
[13:20] <slimjimflim> a 1.5 gb mkv in bluray that i can't skips in vlc cause my video card can't handle it
[13:20] <slimjimflim> so i wanna reduce the quality/framerate
[13:21] <slimjimflim> *that skips in vlc...
[13:22] <zap0> how do you know its the video card?
[13:23] <slimjimflim> i dont, but it's either that or the ram
[13:23] <slimjimflim> ram's only 562
[13:23] <slimjimflim> that's not the point though, i just wanna reduce the quality
[14:02] <luc4> Hi! I'm trying to compile an OpenMAX player which seems to be using also ffmpeg. It seems it is looking for libswresample/swresample.h. This is a debian like system, do you have any idea where I could find this (with its library)?
[14:04] <JEEB> the *resample libraries are so new I don't think they're yet packaged officially. Building ffmpeg from source would be your best bet :)
[14:05] <luc4> JEEB: I understand... thanks!
[15:11] <samek__> Anyone here with experience of streaming to rtmp with ffmpeg ?
[17:49] <jure> well this is odd
[17:49] <jure> ALAC-encoded files make iTunes crash
[17:49] <jure> they didn't use to
[17:52] <jure> 44.1 KHz/16 bits/2ch
[17:57] <durandal11707> jure: what versio you are using?
[17:57] <jure> of ffmpeg or iTunes
[17:57] <durandal11707> ffmpeg of course
[17:58] <jure> N-46842-g461ecea
[17:58] <durandal_1707> what container?
[17:58] <jure> -f ipod
[18:05] <durandal_1707> jure: can created file be played back with ffplay?
[18:08] <jure> probably ... I hadn't built a ffplay ... but avplay 0.8.4-6:0.8.4-1 can play it
[18:09] <jure> there is a BUNCH of error messages in the beginning, however ... pastebin?
[18:09] <durandal_1707> please use ffplay/ffmpeg
[18:09] <durandal_1707> this is channels for FFmpeg project
[18:10] <jure> http://pastebin.com/Zu5DPQAj
[18:10] <jure> well, typing in 'ffplay' redirected me to avplay
[18:11] <durandal_1707> you are using package?
[18:11] <durandal_1707> thing is i cant help you if i cant reproduce your issue
[18:12] <durandal_1707> i do not use avplay/avconv because this is ffmpeg support channel
[18:12] <jure> right right
[18:12] <jure> I'll think of something
[18:12] <jure> my ffmpeg is custom-built
[18:13] <durandal_1707> you have real ffmpeg?
[18:15] <jure> yes
[18:15] <jure> but I used --disable--ffplay
[18:15] <jure> I mean --disable-ffplay
[18:16] <durandal_1707> you can still test decoding with ffmpeg -i input.m4a -f null -
[18:17] <jure> hm, ok
[18:17] <jure> looks ok
[18:18] <jure> no errors
[18:20] <durandal_1707> give pastebin of command line that created m4a file
[18:20] <durandal_1707> with full output
[20:25] <uglyoldbob> so "ffmpeg -i http://127.0.0.1/test.mpg http://127.0.0.1/good.ffm" causes "av_interleaved_write_frame(): Connection reset by peer"
[20:27] <uglyoldbob> correction, "ffmpeg -i http://127.0.0.1:8090/test.mpg http://127.0.0.1:8090/good.ffm"
[20:32] <uglyoldbob> here is the output from ffmpeg http://pastebin.com/ywQLz7HE
[20:37] <okhattab> gcc is unable to create an executible file (raspberry pi / fedora remix / omxplayer)  any ideas or pointers??
[20:45] <Mavrik_> okhattab: config.log usually has a more detailed explanation
[20:50] <okhattab> collect2: error: ld returned exit status
[20:50] <okhattab> c compiler test failed
[21:58] <dbro> Ahoy! Is there a reason why compiling with enable-encoders \ could still result in av_codec_open2() returning "Operation not permitted" on CODEC_ID_AAC. Is there a special flag I need for native aac support
[22:12] <JEEB> dbro, the included aac encoder is still stuffed under the 'experimental' insignia so you will have to set the experimental flag when opening it I'd think
[22:24] <dbro> JEEB: Thanks! I'll give that a try
[22:26] <dbro> perhaps the experimental flag says it all, but I wonder what the state of the native aac codec is vs the 3rd party alts
[22:27] <JEEB> if you use it with 192kbps or over you shouldn't have problems with it, just don't try to go <128kbps I guess?
[22:27] <JEEB> :D
[22:27] <JEEB> too bad almost every other library that can be linked and is decent is nonfree :P
[22:27] <JEEB> with fdk-aac being the worst thing, which was /almost/ GPL-like
[22:28] <JEEB> (everything else was using reference source code and is nonfree because that under no way is under a license that could be redistributed at all)
[22:31] <dbro> interesting. I'm building a variable bandwidth live-streaming app for Android, so I'll need the option of lower bitrates
[22:33] <dbro> I'm trying to keep my work GPL, so this part's a challenge
[22:33] <dbro> anyway, gotta go but thanks again for the info
[22:33] <JEEB> well, you can't distro the useful things
[22:33] <JEEB> so pretty much that or vo-aacenc are your options, and vo-aacenc isn't really better
[22:33] <JEEB> which google noticed as well and switched to fdk with android
[22:33] <dbro> ahh interesting
[22:33] <dbro> thanks man
[22:34] <dbro> see ya
[00:00] --- Sun Nov 25 2012