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

[burek]

[00:01] <cone-54> ffmpeg.git 03Nidhi Makhijani 07master:2fc85fe96e7e: bmv: Split audio and video decoder
[00:01] <cone-54> ffmpeg.git 03Michael Niedermayer 07master:96761e9306a9: Merge commit '2fc85fe96e7e0e5fc433b98eacebf4d3511d2d58'
[00:09] <cone-54> ffmpeg.git 03Nidhi Makhijani 07master:d6902070c521: dsicin: Split audio and video decoder
[00:10] <cone-54> ffmpeg.git 03Michael Niedermayer 07master:28c031951747: Merge commit 'd6902070c52151ec1e8154ce9b22283a1d0bc192'
[00:45] <cone-54> ffmpeg.git 03Timothy Gu 07master:d69243d39b77: samplefmt: Add doxygen categories
[00:45] <cone-54> ffmpeg.git 03Michael Niedermayer 07master:52ea7ffdfbfc: Merge commit 'd69243d39b773b64614792487cd93f6ceb237b25'
[01:12] <jamrial> ejl: your change seems to have broken one fate system: http://fate.ffmpeg.org/report.cgi?time=20140706220712&slot=x86_32-athlon64-gentoo-gcc
[01:27] <cone-54> ffmpeg.git 03Timothy Gu 07master:a7985cfd4c51: audio_fifo: Split into a separate doxygen module
[01:27] <cone-54> ffmpeg.git 03Michael Niedermayer 07master:705eb5a17749: Merge commit 'a7985cfd4c51b7fe2b870fc4ecd109707ee035d6'
[01:28] <ejl> crap
[01:41] <BBB> you guys are weird
[01:42] <BBB> ejl: if you dont know git, just use a UI for it
[01:42] Action: Daemon404 wonders what weirdness he missed
[01:42] <BBB> ejl: Im quite happy with git gui, theres more advanced UIs that are sufficiently self-explanatory
[01:42] <ejl> I am
[01:44] <ejl> I'm just used to P4/SVN, and haven't used git.  Also, when something recommends using a feature from the command line, it's taking a bit to find the corresponding feature in the GUI. :)
[01:44] <Daemon404> p4...
[01:44] <Daemon404> my condolences
[01:44] <ejl> it pays the bills
[01:44] <BBB> omg p4
[01:44] <BBB> I cant believe companies still use that
[01:45] <BBB> svn is ok
[01:45] <ejl> and TFS, which is basically "P4, but worse"
[01:45] <Daemon404> BBB, windows is still stored in p4
[01:45] <Daemon404> for now.
[01:45] <BBB> windows& p4
[01:45] <BBB> fitting
[01:45] <Daemon404> the codebase is truly massive, and dates back to the 80s
[01:45] <Daemon404> "no time to move it"
[01:45] <BBB> like I said, fitting
[01:45] <Daemon404> though i heard a rumor theyre moving windows to git and splitting into modules
[01:45] <BBB> shit goes to shit
[01:47] <ejl> I'm surprised they're even doing that after making their own SCM
[01:47] <ejl> although now I guess I know why that SCM is basically a P4 knockoff
[01:47] <Daemon404> MS is the 2nd biggest contriuter to libgit2
[01:47] <Daemon404> which is also bundled with all new MSVS
[01:47] <Daemon404> as an SCM option
[01:47] <ejl> ah
[01:49] <Daemon404> ejl, it could be worse. it could be: http://i.imgur.com/7p8L6Aj.gif
[01:49] <Daemon404> the enterprisiest
[01:50] <ejl> oh that's not the worst, I've heard of startups whose SCM is Dropbox.
[01:50] <Daemon404> thats bad for different reasons.
[01:51] <ejl> if I'm reading this correctly, the fate test failed because the error went up by a miniscule amount (not surprising given that the range expanded), so I guess the test needs to be updated?
[01:51] <Daemon404> yes
[01:54] <Timothy_Gu> Daemon404, ejl: michaelni already changed the checksum in http://git.videolan.org/?p=ffmpeg.git;a=commit;h=8be23d424feea50d4ee892cdbdd6abd9a807709f , but somehow the test shows the old result.
[01:58] <ejl> mine's showing 10.35/27.82/90   hrm
[02:02] <michaelni> maybe some bug in the ppc fate client
[02:02] <michaelni> maybe it will disappear on its on in the next run, assuming somehow old code was tested with new checksums
[02:07] <ejl> should I keep the followup patch(es) on the same thread or start new ones?
[02:12] <michaelni> whichever you prefer
[02:23] <Timothy_Gu> michaelni: is GMX good again? (Should I use niedermayer.cc or gmx.at?)
[02:24] <michaelni> whichever you prefer, gmx seems working atm
[02:25] <michaelni> btw why are you asking ?
[02:26] <Timothy_Gu> im writing a email to you about Doxygen. Then, im wondering which email to use
[02:27] <Timothy_Gu> BTW you should update your blog post
[02:28] <michaelni> i should write more blog posts more often 
[02:28] <Timothy_Gu> yep
[02:28] <Timothy_Gu> your blog posts are fun to reaf
[02:29] <Timothy_Gu> reaf
[02:29] <Timothy_Gu> read
[02:33] <Compn> yes i also enjoy your blog
[02:33] <Compn> some of the other blogs too. most people stopped updating though
[02:45] <Timothy_Gu> yeah. I always wish that i was born a few years earlier so I can see how active the MPlayer community, multimediamike, arpi, and ods15 were. But things fall apart, MPlayer isnt the 2003 MPlayer, and Michael doesn't write fun filters anymore
[02:59] <Timothy_Gu> jamrial: seems like the movu fixed it http://fate.ffmpeg.org/history.cgi?slot=x86_32-debian-kfreebsd-gcc-4.1
[03:06] <cone-54> ffmpeg.git 03Eric Lasota 07master:586406980f49: avcodec/roqvideodec: set JPEG output color range
[07:10] <ejl> would an SSE2 j_rev_dct be particularly useful?
[07:50] <jamrial> ejl: no idea, but asm optimizations are always welcome
[09:16] <plepere> good morning
[12:35] <rhernandezl> goof afternoon
[12:36] <rhernandezl>  does anyone can help me? I have an issue when trying to compile projects in windows for a ffmpeg android project by cygwin, I got the config.log with me
[12:43] <ubitux> this is a #ffmpeg question, and please don't /query random people
[12:44] <rhernandezl> I did, you were oper there, I think this is not random :)
[13:02] <wm4> it's quite rude to /query people about such questions
[13:02] <wm4> especially for something as boring and google-able as build problems
[13:03] <rhernandezl> I have googled a lot :D don't be confussed, if this was too easy in windows, I would not bother anyone, but I just said hi to the opers
[13:04] <rhernandezl> thank for being so kind wm4
[13:05] <wm4> do you think we exist to give user support? we don't mind helping out users, but if they're being obnoxious about it, then no
[13:06] <rhernandezl> excuse me?
[13:06] <cone-233> ffmpeg.git 03Clément BSsch 07master:5f4dbf3c1030: avcodec: make vismv option as flag types
[13:06] <cone-233> ffmpeg.git 03Clément BSsch 07master:7ac7e8793d3b: avcodec/mpegvideo: small indent fix in vismv code
[13:12] <ubitux> wm4: libfridibi *and* harfbuzz? really?
[13:13] <wm4> ubitux: yes, that's why harfbuzz exists
[13:13] <wm4> but apparently, fribidi is also needed
[13:14] <wm4> fribidi handles text direction, while harfbuzz handles glyph combining
[13:14] <wm4> or something like this
[13:20] <ubitux> nice mess
[13:20] <ubitux> anyway, i was wondering
[13:20] <ubitux> i just wrote a hack to export in json the MV from mpeg-like videos
[13:21] <ubitux> the best way i can think of for doing it properly would be to have a flag to export them as frame side data
[13:21] <ubitux> (so side data injected on demand)
[13:21] <ubitux> would anyone object to such approach?
[13:21] <wm4> I think that's what Libav also wants to do
[13:21] <wm4> and wtf, export as json?
[13:22] <cone-233> ffmpeg.git 03Timothy Gu 07master:3be90723e704: transcoding: fix Doxygen file path
[13:25] <ubitux> wm4: yeah it was just a hack really
[13:25] <ubitux> json ’ easy import in python to do various analysis
[13:40] <ubitux> wm4: did they do anything?
[13:41] <wm4> as usually, no
[13:41] <wm4> not yet
[13:41] <ubitux> ok
[13:41] <ubitux> i'll try to do sth then
[15:00] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:8324bd51867f: avcodec/mpegvideo_enc: fix b frame strategy 2
[15:14] <cone-233> ffmpeg.git 03Diego Biurrun 07master:8d686ca59db1: dsputil: Split off *_8x8basis to a separate context
[15:14] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:462c6cdb8ed2: Merge commit '8d686ca59db14900ad5c12b547fb8a7afc8b0b94'
[15:43] <cone-233> ffmpeg.git 03Diego Biurrun 07master:c166148409fe: dsputil: Move pix_sum, pix_norm1, shrink function pointers to mpegvideoenc
[15:43] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:020865f557cc: Merge commit 'c166148409fe8f0dbccef2fe684286a40ba1e37d'
[16:25] <cone-233> ffmpeg.git 03Diego Biurrun 07master:3c650efb81aa: dsputil: Move draw_edges() to mpegvideoencdsp
[16:25] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:3790801f9ced: Merge commit '3c650efb81aaa3b395ba4606ee68a47ee4efb57b'
[18:47] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:5320b34b9853: avcodec/cljrdec: remove unneeded include
[18:47] <cone-233> ffmpeg.git 03Nidhi Makhijani 07master:246f869590b8: vmd: Split audio and video decoder
[18:47] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:06dae71d477c: Merge commit '246f869590b8c7313d26e1c2ef56db01f6fd2503'
[18:47] <Daemon404> j-b, see you at IBC!
[18:49] <j-b> Daemon404: ?
[18:49] <Daemon404> are you not going this yera?
[18:49] <j-b> IBC? in 3 months?
[18:49] <j-b> of course, I am
[18:49] <Daemon404> yes
[18:49] <j-b> IBC and then VDD
[18:49] <Daemon404> frist time Vimeo (me) is going
[18:50] Action: Daemon404 is figuring out who is at IBC
[18:51] <j-b> although, I might not go, I don't know yet
[18:51] <Daemon404> oic
[18:51] <j-b> depends on VDD organization
[18:51] <Daemon404> is anyone from VLC there?
[18:51] <Daemon404> (to tear down posters of course)
[18:51] <j-b> kierank, funman, Meuuh, luca often go to IBC
[18:51] <Daemon404> o ok
[18:51] <kierank> koda goes as well
[18:52] <kierank> and he has no booth this time
[18:54] <j-b> but koda is now overseas
[18:55] <kierank> 5:51 PM <"j-b> although, I might not go, I don't know yet --> aww no, there will be no drunk audrey :)
[18:57] <j-b> kierank: Audrey will probably do US->Dublin directly
[18:57] <j-b> to organize VDD
[18:57] <kierank> I thought she works for meuuh
[18:57] <j-b> and I hope we'll get many FFMpeg people this year
[18:57] <kierank> ?
[18:57] <j-b> kierank: she's in the US too, with us
[18:57] <kierank> ah
[18:57] <j-b> kierank: we're 7 of us, here.
[18:57] <kierank> I tried to convince carl eugen
[18:58] <j-b> it would be nice to have CE
[18:58] <Daemon404> do you want to see him and I fist fight?
[18:58] <j-b> no
[18:58] Action: Daemon404 kids of course
[18:58] <j-b> I want to see him and you drink fight
[18:58] <j-b> with michaelni doing the referee
[18:59] <Daemon404> lul
[19:02] <j-b> Daemon404: I can dream
[19:02] <Daemon404> there was no proper vdd drinks last year
[19:02] <Daemon404> but.. welll
[19:02] <Daemon404> dublin
[19:03] <Daemon404> ;)
[19:03] <j-b> Daemon404: because of the too many issues with drinks at conferences
[19:03] <Daemon404> o lol
[19:06] <Daemon404> j-b, "carriage of webvtt in mp4"
[19:06] <Daemon404> appeared on mp4-sys apparently
[19:06] <Daemon404> i know you love webvtt.
[19:06] <JEEB> It is largely based on the blog post I wrote some time ago (http://www.w3.org/community/texttracks/2013/09/11/carriage-of-webvtt-and-ttml-in-mp4-files/).
[19:06] <JEEB> (that is a quote)
[19:06] <Plorkyeran> I thought the whole point of conferences was to get drunk and get into fights
[19:06] <j-b> Daemon404: introducing a new subtitles format in 201x that is that stupid is unforgiveable
[19:07] <Daemon404> :D
[19:08] <kierank> j-b: ah it is mr conclato
[19:08] <j-b> and not to mention close to SRT
[19:08] <j-b> so that people will do half-baked convertors
[19:08] <Daemon404> srt is a terrible format
[19:09] <Plorkyeran> SRT's main problem is no spec and no reference implementation
[19:09] <Daemon404> well also it is hard to parse
[19:09] <Daemon404> easy for humans, hard for computers
[19:09] <Plorkyeran> and no real agreement about what subset of html it should support
[19:09] <JEEB> yeh
[19:09] <Daemon404> Plorkyeran, dont worry, webvtt is "all"
[19:09] <Daemon404> embedded css hnnng
[19:09] <Plorkyeran> yes, webvtt does "solve" that problem
[19:10] <Plorkyeran> by requiring that it be rendered by a web browser
[19:10] <j-b> Plorkyeran: it's not hard to write one spec and be the authority on SRT.
[19:10] <Daemon404> its far too late for that
[19:10] <j-b> I doubt it
[19:11] <j-b> SRT is here for the next 10 years
[19:11] <Daemon404> no i mean the files out there are not going away
[19:11] <j-b> new implementations will be written
[19:11] <Daemon404> most of them suck
[19:11] <Daemon404> least bad one so far is aegisub's
[19:11] <j-b> aegisub? the one that is "let's convert everything into ssa?"
[19:12] <Plorkyeran> aegisub's doesn't support the line position things
[19:12] <Plorkyeran> and doesn't support all of the font attributes that vsfilter does (which may or may not be a bad thing)
[19:12] <j-b> http://ale5000.altervista.org/subtitles.htm
[19:12] <Daemon404> j-b, the internal model isnt relevant
[19:12] <Daemon404> i specifically meant the parser
[19:12] <Daemon404> error-handling-wise
[19:13] <kierank> ateme supports webvtt
[19:13] <kierank> no idea how/why
[19:16] <ubitux> <@Daemon404> least bad one so far is aegisub's // hey ffmpeg's one is not that bad ;)
[19:16] <wm4> but at least mp4 is doing it better than matroska: http://concolato.wp.mines-telecom.fr/files/2012/09/webvtt-overlapping-cues-rewritten.png
[19:16] <ubitux> <@j-b> aegisub? the one that is "let's convert everything into ssa?" // no, this is ffmpeg politic :D
[19:16] <wm4> I assume they are doing this kind of splitting so that seeking actually fucking works
[19:17] <Plorkyeran> converting everything to ass is kinda common
[19:17] <j-b> wm4: wow, a graph! that must be good.
[19:17] <Plorkyeran> since unless you're rolling your own renderer you're going to eventually use an ass renderer
[19:17] <j-b> Plorkyeran: being done by mplayer and ffmpeg does not make it common
[19:18] <Plorkyeran> everything that uses libass or vsfilter to render subtitles does it
[19:18] <Plorkyeran> i.e. basically all players?
[19:18] <wm4> vlc AFAIK has completely separate codepaths
[19:18] <ubitux> if libass could be updated to become a subtitles rendering library, that could be nice
[19:19] <j-b> yep
[19:19] <j-b> and not depend on being SSA everywhere
[19:19] <j-b> and not depend on fontconfig
[19:19] <ubitux> ff as well
[19:19] <ubitux> (demuxing ` decoding)
[19:19] <wm4> j-b: there's experimental work to make it not use fontconfig on OSX or win32
[19:20] <Plorkyeran> vlc has an entirely separate subtitle renderer for non-ass?
[19:20] <j-b> Plorkyeran: yes.
[19:20] <Plorkyeran> that sounds sort of insane
[19:20] <wm4> Plorkyeran: it's based on html
[19:20] <wm4> or pseudo-html
[19:20] <j-b> like srt and vtt are
[19:20] <j-b> wm4: it's weird that there are no text rendering libraries in general
[19:21] <j-b> wm4: everyone must mix fontconfig,harfbuzz,freetype and fribidi
[19:21] <Plorkyeran> pango
[19:21] <wm4> pango is g* shit
[19:21] <Plorkyeran> well yes
[19:21] <j-b> pango is glib
[19:21] <wm4> not a good dependency
[19:21] <j-b> so, NO.
[19:21] <Plorkyeran> but uh, it exists
[19:21] <JEEB> gobjects in your pants
[19:22] <wm4> j-b: libass is the lib you're looking for
[19:22] <j-b> wm4: it's not.
[19:22] <JEEB> I think someone used libass to render documents
[19:22] <JEEB> which I kind of felt funny
[19:22] <wm4> I even use libass to render a GUI
[19:22] <j-b> wm4: it's very SSA specific, it's not cross-platform enough
[19:22] <Plorkyeran> and like half of the non-pango stack is things extracted from pango
[19:22] <JEEB> https://github.com/rfw/python-ass/blob/master/test.png
[19:22] <j-b> wm4: I wish it could be there.
[19:23] <j-b> wm4: and be less expansive, CPU-wise
[19:23] <wm4> j-b: uh
[19:23] <wm4> j-b: what is the basis for this claim?
[19:24] <wm4> the CPU one
[19:25] <ubitux> fontconfig? :))
[19:26] <wm4> blame fontconfig
[19:26] <ubitux> btw, there are still no automated tests for libass? (i'm still wondering if there is a "bitexact" mode in FT...)
[19:26] <j-b> wm4: bench, we did 3 years ago
[19:26] <wm4> ubitux: I brought it up a couple of times, bu nobody is interested
[19:26] <j-b> wm4: rendering simple text with freetype and libass
[19:27] <wm4> well it's obvious that it would lose against raw freetype
[19:30] <Plorkyeran> there have been significant performance improvements in the last three years
[19:30] <Plorkyeran> but it is still kinda eh
[19:31] <j-b> but, yes, if someone can split rendering from ass-parsing with a clean API, I'd love that
[19:32] <ubitux> yes, please define an abstract way or storing the markup
[19:32] <ubitux> s/or/of/
[19:32] <j-b> exactly the hard part
[19:32] <ubitux> ...that could be used by external apps
[19:32] <wm4> for an API, you'd simply used an array of structs, each defining text and its attributes
[19:32] <ubitux> "simply" yeah but...
[19:33] <ubitux> i'm tried to design such thing, i actually even had an PoC
[19:33] <wm4> I mean, no need for a language or an easy to manipulate "representation"
[19:33] <wm4> i.e. not what ffmpeg needs
[19:33] <j-b> how do you renderi stuff like that: H<font color=green>ell</font>o
[19:33] <j-b> and pass that with array of struct?
[19:33] <wm4> you'd have 3 items, where the second has the font color set to green
[19:34] <wm4> the details are left as exercise for the reader
[19:34] <Plorkyeran> I don't think there's any fundamentally better way to pass an attributed string to a renderer than markup
[19:34] <Plorkyeran> plenty of stuff uses html-subsets specifically because providing "real" data structures for that is a giant pain
[19:34] <wm4> true
[19:34] <wm4> but then why not use ASS
[19:35] <Plorkyeran> ASS is pretty shitty markup
[19:35] <Plorkyeran> but otherwise yeah
[19:35] <wm4> to escape the endless bad puns?
[19:35] <ubitux> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-November/134607.html
[19:35] <j-b> because ASS is badly defined
[19:35] <j-b> and the spec is "aegisub" implementation
[19:35] <wm4> ASS is very well designed
[19:35] <wm4> no
[19:35] <wm4> the spec is an immutable code base
[19:35] <wm4> the ancient vsfilter
[19:36] <wm4> whatever it does is "correct"
[19:36] <j-b> amazing spec
[19:36] <Plorkyeran> also half the spec is "what GDI does"
[19:36] <Compn> so people have ... ass pain ?
[19:36] <j-b> !pun
[19:36] <Plorkyeran> vsfilter isn't even a good reference implementation because it doesn't actually do most of the interesting bits
[19:37] <Compn> vdd is announced ? :P
[19:37] <Compn> will they pay for my ticket? 
[19:37] <Compn> ehe
[19:38] <wm4> while I agree that ASS is a pretty bad format and vsfilter is the worst spec ever, it also doesn't change often
[19:38] <j-b> well, so you suggest having an API with a markup without a good spec?
[19:39] <ubitux> yes please
[19:39] <wm4> obviously we should write libwebvtt
[19:40] <ubitux> libsubtitles
[19:40] <ubitux> libavsubtitles
[19:40] <ubitux> libswsubtitles to avoid conflicts
[19:40] <wm4> preferably something that doesn't change API every fullmoon
[19:40] <j-b> and make it depend on libavutil?
[19:40] <j-b> what about no?
[19:40] <Plorkyeran> creating a real spec would not be meaningfully harder than making a new markup from scratch
[19:41] <j-b> I liked the idea of structs
[19:41] <j-b> but not sure how doable it is
[19:41] <wm4> AFAIK pango does it approximately this way
[19:41] <wm4> though I remember it being painful
[19:41] <ubitux> j-b: did you check my link?
[19:42] <wm4> ubitux: I think we should avoid encoding format specifics into this API
[19:42] <wm4> so for example how collision detection is done should not be part of a text render API; the API should merely allow implementing it
[19:42] <j-b> ubitux: http://git.videolan.org/?p=vlc.git;a=blob;f=include/vlc_text_style.h;hb=HEAD
[19:42] <j-b> ubitux: just saw it
[19:43] <Plorkyeran> NSAttributedString is relatively pleasant to use, but have fun doing something like that in C
[19:43] <ubitux> mmh
[19:43] <Daemon404> j-b, btw i assume VDD stuff is going out soon
[19:43] <j-b> Daemon404: yes
[19:43] <Daemon404> kk
[19:43] <j-b> Compn: you will be invited
[19:43] <Daemon404> just getting all my craploads of airline stuff done
[19:43] <Daemon404> booked all but vdd now
[19:45] <wm4> ubitux: trying to "unify" all possible formats is what makes it hard in the first place
[19:45] <kierank> j-b: wow 7 people
[19:46] <ubitux> wm4: it should be fine with srt/ass/vtt, but indeed it gets pretty ugly when you're mixing this with teletext, SAMI, jacosub and other insanities
[19:46] <j-b> oh yeah, teletext!
[19:47] <j-b> and rolllup EA-608
[19:47] <wm4> don't forget ASS is the most insane format
[19:47] <wm4> because vsfilter is the spec
[19:47] <wm4> it's also called vshitler by libass devs
[19:48] <ubitux> funny that libass devs plays on other library names...
[19:49] <ubitux> vshitler & libass, that kind of summarize pretty well the state of art in subtitles handling
[19:49] <iive> LOL
[19:49] <j-b> yeah
[19:49] <j-b> horrible shit
[19:49] <ubitux> evil shit
[19:49] <wm4> ubitux: but that's missing webvtt
[19:50] <ubitux> webvtt is not that much an issue
[19:50] <j-b> VTT is insane
[19:50] <wm4> nobody cares about webm, but if it's in mp4...
[19:50] <j-b> you need a full browser for that
[19:50] <ubitux> it can be expressed in ass markup relatively easily if you omit the CSS part (just like SAMI), and add support for ruby character in libass
[19:50] <j-b> and of course, one vtt file for chapters, one for comments, one for annotation
[19:51] <wm4> j-b: isn't that just webm
[19:57] <j-b> no
[21:40] <cone-233> ffmpeg.git 03Andrey Utkin 07master:fcd1f6bc9d5c: avutil/bprint: Add av_bprint_fd_contents()
[21:40] <cone-233> ffmpeg.git 03Andrey Utkin 07master:2229a6dfe66f: avdevice/lavfi: allow non-mmappable files for graph_file
[23:03] <cone-233> ffmpeg.git 03Deti fliegl 07master:8cda23f341be: avformat/segment: Support cutting at clocktime
[23:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:b8d017adba85: avformat/segment: simplify localtime* use
[23:03] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:154954c2acdf: avcodec/vmdvideo: remove unneeded include
[23:11] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:a863c97e99bf: smoothstreamingenc: Fix a memory leak on errors
[23:11] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:75be508f7c6e: Merge commit 'a863c97e99bf30a88baa74f83bab9e3ab25984dc'
[23:30] <cone-233> ffmpeg.git 03Omer Osman 07master:1e9a93bfca2c: libfdk-aacdec: Decode the first AAC frame to reliably identify the bitstream
[23:30] <cone-233> ffmpeg.git 03Michael Niedermayer 07master:242b3c292a49: Merge commit '1e9a93bfca2c2f43a07e01f2ef9fd5cbafe6c22d'
[00:00] --- Tue Jul  8 2014