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

burek burek021 at gmail.com
Sun Jun 2 02:05:01 CEST 2013


[00:04] <heredic> Hi. I'm trying to convert an YUV AVFrame to an RGB24 AVFrame. However, using avpicture_fill() and avpicture_alloc() initializes only the 0's data element and the 0's linesize.. I'd like to have 3 data elements with linesize={256,256,256}
[00:04] <heredic> How can this be done?
[00:05] <saste> heredic, check doc/examples/scaling.c and libavutil/imgutils.h
[00:05] <bunniefoofoo> heredic for conversions you need to use sws_scale and friends
[00:06] <heredic> I know I need to use those
[00:06] <heredic> but I must init some props in the output AVFrame first
[00:06] <bunniefoofoo> oh i see
[00:07] <heredic> and the only way to init it is having only 1 data element and 1 linesize elemenet..
[00:07] <bunniefoofoo> for frames coming out of decode_video() you don't have do do anything, pass directly into sws_scale the data pointer and line sizes as the srcPtr, and srcStride
[00:07] <heredic> i need 3
[00:07] <bunniefoofoo> so you want planer RGB and not packed RGB?
[00:08] <heredic> 3 planes
[00:08] <bunniefoofoo> ok so the destination surface needs to have a pixel format for RGB planar when you allocated it
[00:08] <bunniefoofoo> "surface" == frame
[00:09] <heredic> whats the pixel format for that?
[00:10] <heredic> ill search it n/m
[00:11] <bunniefoofoo> heh, looks like most of the pixel formats are packed for RGB
[00:11] <heredic> why isnt there HSV????
[00:11] <heredic> all i need, in the end, the saturation channel
[00:12] <nellynel90> JEEB: good to know. thanks for the help friend!
[00:12] <bunniefoofoo> there isn't a saturation channel you would have to calculate that
[00:12] <bunniefoofoo> packed RGB is not too difficult to deal with
[00:13] <KalD> [repost - more active ppl] Hi Guys - got a quick question:  I'm running ffmpeg on win32 - I am recording 5 min chunks of mp4 video from a webcam, i need to add current date/time to the video.  I've looked around online and see many examples for linux, etc, but i cant get any of them to work on win32.~
[00:13] <heredic> i know, its easy to calculate it from rgb
[00:13] <heredic> but first i need the planer rgb
[00:13] <bunniefoofoo> AV_PIX_FMT_GBRP I am assuming is what you might want
[00:14] <bunniefoofoo> I haven't tried these myself
[00:14] <heredic> how can iterate a packed AVFrame?
[00:14] <heredic> i tried av_read_image_line() and got segmentation fault.. heh
[00:15] <bunniefoofoo> usually, cast data[0] do uint8_t*. The ptr[0] = R, ptr[1] = G, ptr[2] = B, ptr[3] = R ... etc
[00:16] <bunniefoofoo> there is more to it than that though because of the row stride
[00:16] <heredic> yes its encoded in a peculiar way
[00:16] <heredic> thats why i want 3 data arrays
[00:16] <bunniefoofoo> pretty standard. offset to the next row is ptr + linesize[0]
[00:17] <bunniefoofoo> almost all 2d graphics uses packed rgb, every API i've seen
[00:18] <Mavrik> yeah, since using planar RGB is just silly from performance standpoint
[00:18] <bunniefoofoo> if you are after speed, probably the packed form is most optimized in sws_scale
[00:18] <heredic> ic
[00:20] <JEEB> basically with packed RGB there's naturally a width and a height
[00:20] <JEEB> and then you have the step and the stride
[00:20] <Mavrik> KalD, localtime function doesn't work in drawtext filter?
[00:21] <JEEB> step goes to the next value on the line, stride is the length of a possibly padded memory area to the start of the next line
[00:21] <KalD> Mavrik: hmmm, haven't tried that... got a quick example?
[00:21] <Mavrik> http://ffmpeg.org/ffmpeg-filters.html#drawtext-1
[00:21] <Mavrik> *cough* doc *cough*
[00:21] <bunniefoofoo> jeeb I never understood why YUV formats like to use planar, since it has similiar problem to planar rgb, that is large stride beats up the cache
[00:21] <KalD> lol :-)
[00:21] <Mavrik> there's even a current date example ;)
[00:22] <JEEB> bunniefoofoo, I've gotten used to dealing with both. Oh, and GPUs love YCbCr that is half-packed :)
[00:22] <JEEB> NV12 and such
[00:22] <JEEB> (luma is in its own plane, chroma samples packed)
[00:22] <Mavrik> yeesh, now you're bringing up nightmares
[00:23] <bunniefoofoo> sheesh
[00:23] <heredic> so what will a pixel by pixel loop look like for a packed RGB ?
[00:23] <Mavrik> I think the planar preference mostly comes from subsampling
[00:24] <JEEB> heredic, something I wrote last year http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/utvideoenc.c;h=acb25c3899ebf726bfc58be866bdf4edab14035a;hb=HEAD#l200
[00:24] <Mavrik> packed 420 can be a pain to deal with
[00:24] <JEEB> see how it uses width, height, step and stride
[00:24] <bunniefoofoo> i guess planar kind of makes sense when you use the same UV sample for 2 or 4 display pixels
[00:24] <heredic> Thanks a lot JEEB
[00:24] <KalD> Mavrik: What I get is: a d Y when I try that example as-is.  should I try %%?
[00:24] <JEEB> heredic, this is from within libavcodec tho, so I'm not touching AVFrames in that stuff~
[00:25] <JEEB> heredic, but it generally shows you how to loop through values :P
[00:25] <Mavrik> KalD, probably, I'm don't really know the specifics of cmd.exe escaping :)
[00:26] <heredic> What does this mean?: (uint8_t const * const *)pIn->data
[00:26] <heredic> passed to sws_scale
[00:26] <KalD> Mavrik:  Hmmm... ok I'll play with this.  I for some reason haven't seen this page before or any ref to localtime...  I'll see how far I can get before bugging you more :-)
[00:26] <Mavrik> ;)
[00:26] <Mavrik> it's probably just a shell escaping issue
[00:27] <JEEB> heredic, https://ffmpeg.org/doxygen/trunk/group__lsws.html#gae531c9754c9205d90ad6800015046d74
[00:27] <JEEB> welcome to the doxygen :P
[00:27] <KalD> Mavrik: so I should be passing literal %Y correct?
[00:28] <heredic> I know the doxygen...... :/
[00:28] <bunniefoofoo> heredic, I believe that's "pointer to a constant pointer to a constant uint8_t"
[00:28] <heredic> bunniefoofoo, that means it takes in 1 channel only?
[00:29] <bunniefoofoo> no... not really it is just pendantic for uint8_t**
[00:29] <bunniefoofoo> pedantic
[00:29] <heredic> ic
[00:29] <bunniefoofoo> sws_scale wants pointer to the data planes, so it is an array of pointers, likewise for the stride
[00:30] <heredic> Do you guys know it's impossible to encode alpha channels with OpenCV ?
[00:30] <heredic> Thats why I'm now learning to use ffmpeg
[00:31] <Mavrik> good luck with that O.
[00:31] <Mavrik> o
[00:32] <heredic> Thanks...?
[00:33] <heredic> encoding rgba flv with ffmpeg is no harder than doing it rgb, right?
[00:34] <Mavrik> um, just how are you going to get RGBA video in flv container?
[00:34] <heredic> not possible?
[00:35] <Mavrik> well, I haven't heard of any format that would support alpha channel besides RGB
[00:36] <Mavrik> most formats don't support alpha at all& you could try to get YUVA VP6 video into FLV
[00:36] <Mavrik> but that would probably look terrible with questionable playback capabilities around
[00:36] <Mavrik> hmm& it seems ffmpeg doesn't even support vp6 encodes
[00:37] <heredic> so what are my options, if i must have an alpha channel?
[00:39] <Mavrik> probably some kind of video format meant for intemediate video production
[00:39] <Mavrik> most of them are proprietary though
[00:41] <heredic> I think Iv'e seen flvs with transparency on the web....
[00:42] <Mavrik> [00:36:00] <Mavrik>	 most formats don't support alpha at all& you could try to get YUVA VP6 video into FLV
[00:44] <heredic> but thats not part of ffmpeg as u said..
[03:35] <KalD> Hi Guys - in vf_drawtext.c there is reference to strftime, expand, and other 'options', how do I leverage these using the drawtext filter?  There is an example in some check-in history that provides: drawtext='fontfile=FreeSans.ttf:expand=expand:text=%@{localtime:%a %b %d %Y@}'
[03:35] <KalD>  but I'm told expand isn't an option.
[03:41] <ubitux> where did you see an "expand" option?
[03:41] <ubitux> there is an "expansion" option that can take strftime, none or normal, according to the documentation
[03:42] <ubitux> "normal" being the default
[03:45] <ubitux> https://ffmpeg.org/ffmpeg-filters.html#drawtext
[03:46] <KalD> url: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-November/134045.html - referred to 'expand'.   More importantly -- I'm trying to inject the current date/time stamp into my video file (overlay on the video) and am unable to find a working example for win32.  I've looked at localtime, and am at a loss as to why things aren't working for me.  All I get (with above example for example) is a
[03:46] <KalD> single letter printed to the video feed.
[03:47] <ShinzonX> Howdy folks
[03:48] <ubitux> KalD: it's a temporary patch posted on the devel mailing list, look at the final commit, and the documentation i just linked you too
[03:49] <KalD> @ubitux: reviewing the docs now...  I'm missing something simple (or it is broken on win32)... or I'm broken :-)
[03:49] <ShinzonX> I am having problems with ffmpeg and rtmpdump on Centos 5.8.. I am using pastebin.com to provide some data per channelop instructions. :)
[03:50] <KalD> @ubitux: http://pastebin.com/ZBi9HQkf
[03:51] <ubitux> "and the COMPLETE console output"
[03:51] <KalD> ... mybad one sec
[03:52] <KalD> @ubitux: http://pastebin.com/8efjyEdV
[03:53] <ubitux> i see no error
[03:53] <ubitux> what happened?
[03:54] <KalD> the output on the video is: a d Y}  in the top left, not the current date/time :-\
[03:54] <ShinzonX> Centos ffmpeg rtmpdump issue link someone who could help me out:  http://pastebin.com/f56mkKKi
[03:54] <ShinzonX> thanks in advance for the assist..
[03:57] <ubitux> KalD: you need to escape the ':'
[03:58] <ubitux> and the expansion mode strftime is not what you are looking for
[03:58] <ubitux> at least that's not consistent with the expansion mode you're trying to use
[03:59] <KalD> I need to escape the : behind localtime?  - which expansion option to you recommend?
[03:59] <ubitux> ShinzonX: http://ffmpeg.org/trac/ffmpeg/wiki/CentosCompilationGuide
[04:00] <ubitux> KalD: the default, don't change it
[04:00] <ShinzonX> @ubitux  Thanks I will relook at it again
[04:02] <KalD> @ubitux: Hmm, so dumb question:  how do you escape : in win32/cmd.exe ?  ^:, ^:, :: all don't work
[04:02] <KalD> sorry \: either
[04:03] <ubitux> i don't know, i never used the win shell
[04:03] <ShinzonX> @ubitux My apologies, but there is nothing in the guide regarding rtmpdump compilation...
[04:03] <KalD> @ubitux: I'll play around with it... just to confirm - I'm escaping the : after localtime correct?
[04:04] <ubitux> ShinzonX: look for a librtmp devel package
[04:04] <ubitux> KalD: some hints: https://ffmpeg.org/ffmpeg-filters.html#Notes-on-filtergraph-escaping
[04:04] <ubitux> KalD: yes the ':' into localtime must not be interpreted as an option separator of the drawtext options
[04:05] <KalD> thx :-)
[04:05] <ShinzonX> @ubitux Yes I pulled down the 2.4 version to include the update to librtmp..
[04:05] <ubitux> KalD: ./ffplay -f lavfi color -vf "drawtext=fontcolor=white:x=50:y=100:fontsize=20:text=%{localtime}"  this gives me the time, i let you deal with the escaping
[04:05] <ubitux> also, its extremely late so i'm gonna sleep, have fun
[04:06] <ubitux> ShinzonX: i don't know, except that you need to install the devel package of librtmp if you want to build it with it (that's what i guessed from your incomplete and inconsistent paste)
[04:06] <ubitux> cya.
[04:06] Action: ubitux &
[04:07] <ShinzonX> Hmmm
[04:08] <KalD> omg :-)  he just left and I got it to work....  . o O ( must put large sums of bitcoin in @ubitux's account)
[04:08] <ShinzonX> lol Nice job KaID :)
[04:09] <KalD> so maybe the docs are all buggy as hell :-)  they refer to localtime:..... stuff - you dont put : or any stuff after localtime :-)
[04:09] <KalD> ... afk
[04:09] <ShinzonX> In my case I pulled the latest rtmpdump...  librtmp0-2.3-1.el5.x86_64.rpm
[04:10] <ShinzonX> and this one too   rtmpdump-devel-2.3-1.el5.x86_64.rpm
[04:11] <ShinzonX>    *scratches head*
[04:18] <ShinzonX> Man its been awhile since I have been on the IRC... I presume most are AFK?
[04:19] <ShinzonX> ^_^
[17:40] <scott_> guys whats the best way to improve scenechange quality for low video bitrate
[17:43] <Mavrik> uh
[17:44] <Mavrik> elaborate
[17:58] <scott_> inorder to play some specific low quality videos at iOS i am converting them from mainline to baseline profile
[17:58] <scott_> and during that i see huge quality degradation after optimizaiton
[17:59] <scott_> if i convert these videos to flv them it works close to the original mp4 quality
[17:59] <scott_> i see huge degrade in quality during scenechange
[18:07] <Zeranoe> Can FFmpeg read from an ISO archive source?
[18:08] <scott_> <Mavrik>  any suggestions
[18:10] <Mavrik> "quality degradation after optimization"?
[18:10] <Mavrik> also:
[18:19] <scott_> @ <fflogger> <Mavrik> http://pastebin.com/PuAkP8kZ
[18:21] <Mavrik> ok, using veryfast will significantly degrade your quality
[18:21] <Mavrik> why are you using such wierd GOP size?
[18:22] <Mavrik> you're not setting baseline profile either :)
[18:33] <scott_> i m sorry for the delay
[18:34] <scott_>  ./ffmpeg -i /test_original.mp4 -acodec libfaac -ab 64k -ar 44100 -ac 1  -threads 1 -vcodec libx264 -vprofile baseline -preset veryfast -wpredp 0  -g 8*1200/40   -y output.mp4
[18:35] <scott_> what should be the right GOP SIZE?
[18:35] <Mavrik> the default usually works well
[18:36] <scott_> i tried default first but that was even worst
[18:36] <Mavrik> so what made you think "8*1200/40" is the sweet spot?
[18:37] <scott_> some combinations for certain videos
[18:38] <LithosLaptop2> libfaac is going to stuggle real bad @ 64kbit/s, even if it is mono
[18:39] <scott_> will min-keyint will make diffeence for open-gop
[18:43] <scott_> why scenechange is that bad
[18:44] <Mavrik> probably because you have "veryfast" profile and you're forcing the encoder not to put an I-frame on scenechange
[18:44] <Mavrik> also, just noticed
[18:44] <Mavrik> you're not setting target quality anywhere
[18:44] <Mavrik> no wonder your videos look terrible :P
[18:45] <scott_> i m sorry to ask how to set target quality?
[18:46] <Mavrik> scott_, that depends on what you're targeting. Do you have a strict output file size requirement? Or do you just want a certain amount of quality?
[18:47] <scott_> i am only looking for quality on these videos not size
[18:48] <scott_> offcource size shouldnt increse by original
[18:48] <Mavrik> scott_, use "-crf" parameter then
[18:48] <Mavrik> a "good" default is around 23
[18:49] <Mavrik> higher number - smaller file / worse quality
[18:49] <Mavrik> lower number - larger file / better qualiy
[18:49] <Mavrik> also, as I said, for crying out loud, use at medium or even slow preset if you're not doing encoding in realtime
[18:49] <Mavrik> it's going to significantly improve quality at same filesize
[18:51] <scott_> unfortunatly its Realtime encoding
[18:59] <scott_> i tried that doesnt helped
[19:00] <scott_> even tried lowering the crf value
[19:02] <Mavrik> if you used crf and havent seen a change you're doing something wrong
[19:02] <Mavrik> either you're looking at the wrong file or you're not passing the parameters you've shown us
[19:33] <ShinzonX> Hi folks good afternoon
[19:33] <ShinzonX> got rtmptump compiled into ffmpeg :D :D
[19:33] <ShinzonX> thanks for all your help especially @ubitux
[19:34] <ShinzonX> So my next question has to do with live streams.. I am pretty sure yall hear about it a lot
[19:35] <JEEB> btw, in many cases you don't need to build librtmp for ffmpeg's rtmp usage
[19:35] <JEEB> since ffmpeg now has an internal implementation of rtmp(e)
[19:35] <ShinzonX> ooOO
[19:35] <JEEB> which gets disabled if you enable librtmp
[19:36] <ShinzonX> I am using Serviio... it says it requires it.. I am new to ffmpeg and serviio, so I am learning as a fast as I can.
[19:36] <ShinzonX> wow I went through all that pain for nothing..
[19:36] <JEEB> yes, if the documentation is at all old it will most probably say that librtmp is needed for any rtmp activity
[19:36] <JEEB> well, don't destroy your current binary :P
[19:36] <ShinzonX> Ok.. I wont.
[19:36] <JEEB> just try building with just the internal rtmp(e) implementation
[19:37] <JEEB> don't make install it or anything, just build a static binary with just the internal one (don't add --enable-librtmp)
[19:37] <ShinzonX> OH MAN! I did that...
[19:37] <ShinzonX> arrrgh
[19:37] <ShinzonX> do I have to go back and rebuild ffmpeg again?
[19:37] <JEEB> ?
[19:37] <ShinzonX> *smdh*
[19:38] <ShinzonX> I did it with --enable-librtmp
[19:38] <ShinzonX> *groans*
[19:38] <ubitux> you don't need to rebuild ffmpeg, you just need to select the appropriate format/protocol at runtime
[19:38] <ubitux> --enable-librtmp doesn't mean it disable the builtins
[19:38] <ubitux> it just adds a wrapper around librtmp
[19:38] <ShinzonX> ah ok..
[19:38] <ubitux> so you have the choice
[19:39] <ShinzonX> *whew*
[19:39] <JEEB> oh?
[19:39] <JEEB> I think at one point of time it did disable the internal one :s
[19:39] <ShinzonX> I thought I was gonna make you proud ubitux.. ^-^
[19:40] <ShinzonX> I actually cleaned everything out and carefully installed step by step..
[19:41] <ubitux> JEEB: huh? you sure about that? sounds weird
[19:41] <ubitux> JEEB: maybe change the default, disable the internals sounds fishy to me
[19:41] <JEEB> well, my memory /can/ play tricks with me
[19:42] <ShinzonX> I am using Serviio to stream content for my little one versus using the crappy Comcast kids channel which costs a fortune
[19:42] <ShinzonX> but I love new technology ... ffmpeg is fascinating..
[19:42] <ShinzonX> and so powerful... I just didnt realize how powerful.
[19:42] <ubitux> JEEB: you might be right, i see a "not" dependency
[19:43] <ubitux> which is really too bad
[19:43] <JEEB> yeah :P
[19:43] <ubitux> heh then you might be owned ShinzonX ;)
[19:43] <ShinzonX> lol
[19:44] <ShinzonX> so much you can do with ffmpeg... there are huge possibilities.. Sorry for sounding like a max level nerd.
[19:44] <JEEB> yes, until what you want to do needs ffserver, then you start wanting to cut your veins
[19:44] <JEEB> ffmpeg itself is <3
[19:44] <ShinzonX> lol...
[19:45] <ShinzonX> Sounds like CORBA in its early implementation...
[19:45] <ShinzonX> *stares at scars on my wrists*
[19:46] <ubitux> and when you'll open the avfilter doors, you'll see a nice rainbow
[19:48] <ShinzonX> lol
[19:48] <JEEB> ubitux, don't you mean swscale ;)
[19:50] <ShinzonX> so dumb question... ffmpeg is what serviio uses to do the transcoding of video, audio right?
[19:50] <JEEB> most internet services that transcode video use the stuff that ffmpeg uses, too
[19:50] <JEEB> some use ffmpeg, some use the libraries themselves
[19:50] <JEEB> etc.
[19:50] <ShinzonX> ooooOOO
[19:51] <ShinzonX> I read where ffserver gives folks fits... is it that difficult to implement?
[19:52] <JEEB> it's a literally unmaintained and undocumented piece of voodoo machinery
[19:53] <ShinzonX> ....
[19:53] <ShinzonX> lol
[19:54] Last message repeated 1 time(s).
[19:54] <ShinzonX> its dark magic eh?
[19:54] <JEEB> thankfully stuff like rtmp(e) was implemented within ffmpeg
[19:54] <JEEB> no need to touch
[19:54] <JEEB> no need to know
[19:54] <JEEB> SAN points kept
[19:54] <ShinzonX> ah the forbidden arts..
[19:55] <ShinzonX> brb gotta get the kid something for lunch
[19:55] <JEEB> thankfully VLC implements most of the stuff that you would need ffserver for
[19:55] <JEEB> and generally is more sanely usable
[19:56] <ubitux> JEEB: i never used the rtmp stuff in ffmpeg; i remember something like having a muxer being a server or something?
[19:58] <JEEB> it just pushes the stream to an rtmp streaming server, so it's really closer to the usual stuff. It's just not supported on the ffserver side so no-one can even think about using it with ffmpeg
[19:58] <ubitux> right so well you still need a server.
[19:58] <JEEB> yeh
[19:58] <JEEB> in most cases, though, that is nowadays set up by a third party
[19:59] <JEEB> or you use red5/adobe's thingy
[19:59] <ubitux> is rtmp actually still used?
[19:59] <JEEB> yes
[20:00] <ubitux> i mean, i only heard bad things about it
[20:00] <JEEB> not gonna die any time soon
[20:00] <ubitux> why is it prefered over other brand new technologies such as hls?
[20:00] <JEEB> because it's what flash handles?
[20:00] <JEEB> and HLS can't have "DRM"
[20:00] <ubitux> flash can plays hls afaik
[20:00] <ubitux> -s
[20:01] <JEEB> no idea about that to be honest, never tried :)
[20:01] <ubitux> isn't there some mess with multiple ports with rtmp?
[20:01] <JEEB> but yeah, unfortunately many things/places want DRM
[20:01] <ubitux> like a control channel just like ftp
[20:01] <JEEB> hmm
[20:01] <JEEB> don't remember
[20:01] <ubitux> or maybe i'm confused with rtsp
[20:09] <ubitux> ok so rtsp seems to be the playback control thing
[20:09] <ubitux> and rtmp looks like... well fine?
[20:10] <JEEB> :D
[20:23] <Mavrik> ubitux, RTMP is pretty much still the go-to protocol for any streaming
[20:24] <Mavrik> HLS is apples only thing as of now, rest of the protocols just throw away very expensive bandwidth
[20:24] <Mavrik> and offer not content "protection" the content providers so badly want
[20:25] <Mavrik> it's a terrible terrible stateful protocol though that comes in about 4 or 5 versions ;)
[20:25] <ubitux> what if you aim at apple devices?
[20:25] <ubitux> also, isnt hls allowing you to have auto bitrate switches?
[20:25] <Mavrik> yeah, RTMP as well
[20:25] <ubitux> what about seeking?
[20:26] <Mavrik> seeking too :)
[20:26] <ubitux> and apple devices?
[20:26] <Mavrik> as I said, HLS is Apple devices stuff, so you send HLS to apples and new androids
[20:26] <Mavrik> and deliver RTMP to everything else
[20:26] <Mavrik> if you're half smart and a company you just buy a Wowza license
[20:27] <Mavrik> get your video to Wowza with MPEG-TS, RTMP or something and Wowza will remux the stream to deliver it pretty much anywhere
[20:27] <Mavrik> even over those wierd RTMP-over-HTTP-with-encryption protocol versions
[20:28] <ubitux> well, why not hls everywhere (assuming i don't care about that content protection)?
[20:29] <Mavrik> because nothing supports HLS except iOS, Android 4.+ and Safari on OS X
[20:29] <ubitux> i thought flash players were fine with it
[20:29] <Mavrik> maybe the new ones
[20:29] <Mavrik> also it is still more wasteful for bandwidth than RTMP
[20:30] <ubitux> ah, really?
[20:30] <ubitux> mp4 overhead?
[20:30] <ubitux> about hls, can i do some live stream with it?
[20:30] <ubitux> i mean, like, i can't define the playlist in advance
[20:30] <Mavrik> nah, just the protocol - it's basically chunked MPEG-TS or MP4 (not sure which) so devices tend to download it in bigger chunks
[20:31] <ubitux> it's mp4/mov
[20:31] <Mavrik> while RTMP has bandwidth control and mostly doesn't stream ahead so far which makes for a noticable difference if you have to pay for TB of bandwidth on your server ;)
[20:31] <ubitux> it might support ts though, but that might be dash only
[20:31] <ubitux> mmh
[20:32] <Mavrik> actually here I'm reading apple live-streaming doc where they talk only about the MPEG2-TS container :)
[20:32] <Mavrik> but yes, HLS can do live streaming :)
[20:32] <Mavrik> http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/HTTPStreamingArchitecture/HTTPStreamingArchitecture.html
[20:33] <ubitux> huh indeed it's ts, i really have a bad memory
[20:34] <ubitux> Mavrik: that page shows the basic segmentation
[20:34] <ubitux> my question is more how you can do that when you need to change the playlist regularly
[20:35] <ubitux> maybe i should read completely though
[20:42] <ubitux> oh ok you just don't put #EXT-X-ENDLIST at the end
[20:42] <ubitux> i wonder what's the fetching period in these case
[20:43] <ubitux> typically i wonder if it's ok to "redefine" the stream
[20:43] <ubitux> but well ok
[21:55] <__AL__> hi all
[21:55] <__AL__> I am a ffmpeg newbie
[21:55] <__AL__> Trying to compile ffmpeg for MSVC
[21:56] <__AL__> I have followed the documentation given at http://ffmpeg.org/platform.html
[21:57] <__AL__> But get the following error -
[21:57] <__AL__> $ ./configure --toolchain=msvc
[21:57] <__AL__> Unknown option "--toolchain=msvc".
[21:57] <__AL__> See ./configure --help for available options.
[21:57] <__AL__> Appreciate any help
[21:58] <JEEB> how old is your ffmpeg?
[21:58] <JEEB> as in the source cod
[21:58] <JEEB> *code
[21:58] <__AL__> 0.10.7 an 0.11.3
[21:58] <JEEB> not sure when exactly MSVC support was added, but you will most probably want to update
[21:59] <__AL__> ok. Let me try a later version.
[22:08] <__AL__> ok. I tried compiling 1.1.5
[22:08] <__AL__> I get this error
[22:08] <__AL__> c99wrap cl is unable to create an executable file.
[22:08] <__AL__> If c99wrap cl is a cross-compiler, use the --enable-cross-compile option.
[22:08] <__AL__> Only do this if you know what cross compiling means.
[22:08] <__AL__> C compiler test failed.
[22:32] <JEEB> __AL__, do you have c99wrap/c99conv? Also why exactly 1.1.x and not the currently newest release :P
[00:00] --- Sun Jun  2 2013


More information about the Ffmpeg-devel-irc mailing list