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

[burek]

[00:17:07 CEST] <feliwir> is pross_ here already?
[01:01:12 CEST] <cone-287> ffmpeg 03Michael Niedermayer 07master:f1e173049ecc: avcodec/jpeg2000: Remove CBLK limit
[01:53:34 CEST] <rcombs> \o/ successfully made bsf_h264_mp4toannexb's name somewhat incorrect
[05:13:13 CEST] <cone-912> ffmpeg 03Philip Langdale 07master:6e5e139fe370: avcodec/vdpau: Support for VDPAU accelerated HEVC decoding
[11:21:01 CEST] <ubitux> WARNING: Option --enable-hwaccel=vdpau did not match anything
[11:21:03 CEST] <ubitux> curious.
[11:22:50 CEST] <ubitux> it seems it can only be auto-probed with --enable-hwaccels
[11:23:04 CEST] <ubitux> if this is the desired behaviour, there is a bug in the "documentation" of the configure
[11:23:11 CEST] <ubitux> but i have doubt that's expected
[11:24:45 CEST] <nevcairiel> Its vdpau_h264 etc
[11:25:01 CEST] <nevcairiel> Codec specific names
[11:25:19 CEST] <nevcairiel> The general option is just --enable-vdpau
[11:27:07 CEST] <ubitux> ah? mmh
[11:37:14 CEST] <cehoyos> Hi! What is "-vsync drop" supposed to do?
[11:37:52 CEST] <BtbN> I think it syncs the video by dropping frames.
[11:38:01 CEST] <cehoyos> A user uploaded a hd cellphone recording that contains audio "holes". FFplay, MPlayer and WMP speed up video to keep A/V sync, QT fails to play the sample without desync.
[11:38:17 CEST] <cehoyos> ffmpeg -async 1 -i ... inserts silent audio and keeps A/V sync.
[11:38:35 CEST] <cehoyos> How is possible to drop frames to keep A/V sync? -vsync drop makes no difference here...
[11:38:44 CEST] <cehoyos> (And I wonder what it does / how it works.)
[11:39:05 CEST] <cehoyos> http://avmule.com/ffmpeg/source2.mp4
[11:39:17 CEST] <cehoyos> The most prominent drop is after 77 seconds, but there are several.
[11:39:28 CEST] <BtbN> ah, drop does not drop frames. It drops timestamps from the frames, so the muxer generates fresh ones
[11:39:42 CEST] <cehoyos> Ok, thank you, that explains it.
[11:40:02 CEST] <cehoyos> So is it a feature request to drop frames if input audio contains holes to keep A/v sync?
[11:40:16 CEST] <cehoyos> michaelni?
[11:40:26 CEST] <BtbN> I can't imediately see a way to do that, so i'd say it is
[11:41:14 CEST] <BtbN> cehoyos, try with vfr
[11:41:17 CEST] <BtbN> -vsync vfr
[11:41:57 CEST] <BtbN> But the default, auto, should do something similar already
[11:42:15 CEST] <BtbN> I'm not sure if it means dropping timestamps or actual frames though.
[11:42:28 CEST] <cehoyos> Well, if the default would not lead to A/v desync, there would be no issue...
[11:42:56 CEST] <BtbN> Propably nobody every thought of actual holes in the audio stream
[11:43:11 CEST] <cehoyos> I don't see a difference in the output file between -vsync vfr and -vsync drop and default
[11:43:26 CEST] <cehoyos> That's why -async 1 exists, so the issue is known afaict.
[11:45:31 CEST] <BtbN> My guess is that with actual holes in the audio stream, it never knows the video is out of sync
[11:45:39 CEST] <BtbN> Because there are no timestamps to compare to
[11:46:22 CEST] <cehoyos> It knows that the audio is missing (if not, -async 1 wouldn't help I guess): The FFplay status line shows the issue visibly.
[11:46:50 CEST] <cehoyos> And ffplay has to do some visibly action to keep A/V sync: speed up video.
[11:47:23 CEST] <BtbN> iirc -async 1 only affects the beginning of the stream, and does nothing if something happens in the middle
[11:47:42 CEST] <cehoyos> That is not correct.
[11:48:13 CEST] <cehoyos> But please feel free to test yourself, link is above.
[11:48:24 CEST] <BtbN> "-async 1 is a special case where only the start of the audio stream is corrected without any later correction." At least that's what the doc says
[11:48:40 CEST] <BtbN> i'm at work currently and can't listen to audio, so testing is kind of complicated
[11:49:55 CEST] <cehoyos> docs can be wrong...
[11:50:30 CEST] <cehoyos> (The reason is that -async one now maps to an audio filter that does not know anything about "beginning of streams". The doc may have been correct once upon a time)
[11:53:11 CEST] <cehoyos> No, it seems the doc were never right, -async 1 also works for the sample before the audio filters were written.
[12:17:19 CEST] <michaelni> cehoyos, i think its a feature request to drop the video during these holes of a different stream
[12:25:32 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:6c4a2f11ddde: avcodec/jpeg2000dec: Add coords to Jpeg2000Tile
[12:25:33 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:50b77e364f0a: avcodec/jpeg2000dec: iterate over positions with the special cases from jpeg2000
[12:25:34 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:f5822ea3798a: avcodec/jpeg2000dec: Add missing \n to av_log()
[12:37:40 CEST] <cehoyos> michaelni: Thank you, ticket created!
[13:00:26 CEST] <cehoyos> michaelni: Concerning j2k, this may be the only remaining issue that users have reported before ami_stuff started to stress-test the decoder: http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2586/ 
[13:32:56 CEST] <ashish_3805> hello, I am new to open-source. I am second year engineering student in india. I know c++, c and webstuffs . I want to get my hands in development by contributing to ffmpeg.. please help
[13:34:12 CEST] <JEEBsv> start by building current git HEAD FFmpeg
[13:34:28 CEST] <JEEBsv> getting used to what is used for configuration and building steps
[13:34:35 CEST] <JEEBsv> then, well, find something that interests you
[13:36:25 CEST] <Compn> ashish_3805 : there are many things to work on in ffmpeg :)
[13:36:31 CEST] <Compn> we always need help
[13:37:32 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:29cc0a178e75: ffmpeg_opt: Fix sync_ist
[13:37:53 CEST] <ashish_3805> thanks for ur help...
[13:42:22 CEST] <cehoyos> Compn: I don't understand your comment in ticket 4661...
[13:48:55 CEST] <Compn> cehoyos : which part is confusing ?>
[13:49:45 CEST] <cehoyos> There is only one sentence, and I don't think it is understandable...
[13:51:01 CEST] <Compn> feel free to edit/delete or make your own comment then ?
[13:51:33 CEST] <cehoyos> Deleting is not welcome iirc...
[13:51:50 CEST] <cehoyos> My comment would just be "wontfix" but I was hoping somebody else would close the ticket.
[13:52:00 CEST] <Compn> why wontfix ?
[13:52:21 CEST] <Compn> what if there are files that exist with some problem that work in fcp ?
[13:52:32 CEST] <Compn> er some problem in ffmpeg, but those same files work in fcp ?
[13:52:39 CEST] <J_Darnley> While it isn't the best sentence ever written, read it as: we need a sample, or a way to produce prores 422 with v210 colorspace, so we can fix this.
[13:53:00 CEST] <kierank> cehoyos: it's not really a bug
[13:53:06 CEST] <kierank> as such
[13:54:26 CEST] <cehoyos> J_Darnley: What sample do we need?
[13:54:43 CEST] <cehoyos> kierank: I did not claim it is a bug (I claimed it is an invalid ticket)
[13:54:54 CEST] <kierank> I know
[13:54:56 CEST] <Compn> i merely asked for more info ....
[13:54:59 CEST] <kierank> I'm agreeing with you cehoyos 
[13:55:23 CEST] <Compn> i dont know the validity of the bug/request, nor do i care
[13:55:59 CEST] <Compn> i do care about fostering a helpful attitude on the bug tracker, so that users reporting bugs arent scared away.
[13:56:34 CEST] <Compn> because i dont mind using the bug tracker as user help
[13:56:36 CEST] <cehoyos> I have a feeling that this is not a "user" in your sense
[13:56:52 CEST] <Compn> but thats just my personal opinion and not speaking for anyone else or the project.
[13:57:12 CEST] <cehoyos> But there are hundreds of tickets with status new that are probably valid that you could try to reproduce and fix the status...
[13:57:18 CEST] <Compn> are you saying its someone who wants to create invalid prores files with ffmpeg ?
[13:57:38 CEST] <cehoyos> (And I do know that what you write here is you personal opinion, at least I hope so ;-) )
[13:58:27 CEST] <cehoyos> What does the word "invalid" have to do with these two tickets? (And, while being there "fcp"?)
[13:59:16 CEST] <Compn> fcp = final cut pro, one of the main tools used in dealing with prores files , i thought
[13:59:30 CEST] <cehoyos> The user has a slightly unusual way of implementing his use-case and wants to avoid using FFmpeg decoders. I don't know why and I am not sure if we want to know it.
[13:59:48 CEST] <cehoyos> I do know what "fcp" stands for, I don't understand how it is related to the ticket(s) in question.
[14:00:32 CEST] <Compn> see, i thought he had a file that works in fcp but not ffmpeg
[14:00:50 CEST] <cehoyos> There is no (not even remotely) indication for this in the ticket.
[14:01:06 CEST] <cehoyos> But as I said: There are hundreds of tickets that need somebody to reproduce them...
[14:01:53 CEST] <Compn> so encourage the devs who come in this channel to take up that job , like ashish_3805 earlier asked for what he should work on
[14:02:17 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:7ca0cd583125: avcodec/jpeg2000dec: iterate in tile sample space for CPRL & RPCL
[14:02:31 CEST] <cehoyos> Unfortunately, you need some experience to reproduce tickets;-(
[14:02:45 CEST] <Compn> :)
[14:03:11 CEST] <cehoyos> (Or to say it differently: If you fail to undertand a relatively trivial report, how should a user with zero experience succeed?)
[14:03:35 CEST] <Compn> in essence, that is what you are saying i am doing, failing to understand a relatively trivial report :)
[14:03:44 CEST] <Compn> ehe
[14:04:17 CEST] <Compn> er i'm reading things wrong today :P
[14:04:23 CEST] <cehoyos> michaelni: Is "Fix sync_ist" related to my earlier question?
[14:04:39 CEST] <Compn> maybe new user will have better reading comprehension
[14:05:13 CEST] <cehoyos> compn: No, my original questoin was "Why do you request a sample that can be produced with "ffmpeg -f lavi -i testsrc -vcodec v210 out.mov". Only when you wrote that you thought that he has a sample that doesn't play, I realized that there is a misunderstanding.
[14:05:18 CEST] <Compn> cehoyos : want to make a new custom query for this page , https://trac.ffmpeg.org/report , that lists only "new" tickets ?
[14:06:05 CEST] <cehoyos> No, I don't really like the reports...
[14:06:12 CEST] <Compn> or "new" tickets without comments.
[14:06:12 CEST] <Compn> doh
[14:06:18 CEST] <michaelni> cehoyos, i looked at sync ist code because of your question and saw the issue, i was wondering if it could be implemented using sync_ist ...
[14:06:41 CEST] <cehoyos> (I prefer tantalizing the database)
[14:06:49 CEST] <cehoyos> Thank you!
[14:07:04 CEST] <cehoyos> And is it?
[14:07:05 CEST] <Compn> cehoyos : so is that user using libavformat with quicktime binary codec ?
[14:07:46 CEST] <Compn> also, i have to go work now. cya
[14:07:48 CEST] <cehoyos> No, he wants us to move a decoder to libswscale which has (among other things) the issue that no all encoders follow the spec, so the decoder already contains some hacks that are probably not easy to port to libswscale.
[14:08:21 CEST] <cehoyos> Or to say it differently: He wants us to add packed yuv422p10
[14:09:05 CEST] <cehoyos> But there are so many feature requests for which no solution exists currently (he only wants another solution).
[14:09:22 CEST] <cehoyos> ... another solution than the one already in FFmpeg
[14:09:34 CEST] <Compn> i understand
[14:09:44 CEST] <Compn> i just didnt get that upon first reading the bug
[14:09:50 CEST] <cehoyos> And packed yuv444p16
[14:10:27 CEST] <Compn> instead of a wontfix , i'd put 'requires bounty' :P
[14:10:32 CEST] <cehoyos> Given that several people (developers) asked here repeatedly "why are there so many colour spaces?", we should probably not add new ones.
[14:10:41 CEST] <cehoyos> I disagree.
[14:15:21 CEST] <durandal_1707> there are so many pixel formats because there are different usecase
[14:18:35 CEST] <cehoyos> durandal_1707: I thought there are so many pixel formats because hardware supports so many...
[14:18:47 CEST] <cehoyos> Both as input and output pix_fmts.
[14:19:05 CEST] <cehoyos> And then came the formats with 8<bpp<=16
[14:19:27 CEST] <cehoyos> And somebody explained that x264 would be slower if we didn't have yuv420p10
[14:22:17 CEST] <wm4> a 4:4:4 packed format would actually be a good idea
[14:22:30 CEST] <wm4> because it's such a simple format
[14:22:48 CEST] <durandal_1707> Y416 is defined by MSDN and used in hardware
[14:25:44 CEST] <wm4> V210 on the other hand is rather complicated, so it's rightfully rejected
[14:27:51 CEST] <durandal_1707> tiff works with packed yuvs and current code is big hack
[14:28:29 CEST] <cone-666> ffmpeg 03Zhang Rui 07master:d38bc6361df6: avutil/log: modify AV_LOG_MAX_OFFSET for AV_LOG_TRACE
[14:38:07 CEST] <cehoyos> wm4: Did you undertand that he wants an output-only colour-space? (I had originally not)
[14:38:25 CEST] <cone-666> ffmpeg 03schenk michael 07master:b9161ef05231: avformat/hls: do not iterate to next sequence number if interruption is requested
[14:49:15 CEST] <cone-666> ffmpeg 03Peter Ross 07master:ea8fec20573a: fate: test ea vp6 with alpha stream
[16:01:01 CEST] <wm4> philipl: one of my users tried it, result: https://0x0.st/6h.jpg
[16:01:40 CEST] <wm4> philipl: with 349.16 on a 960
[16:02:34 CEST] <Daemon404> nice watermark
[16:03:36 CEST] <wm4> so you can feel like it's 2005 when it's 2015
[16:04:27 CEST] <Daemon404> in 2005 we were already on xvid
[16:33:37 CEST] <philipl> wm4: Is that meant to be correct or incorrect?
[16:33:54 CEST] <wm4> philipl: I think this interlacing effect is incorrect
[16:34:04 CEST] <wm4> didn't you have similar issues?
[16:34:08 CEST] <philipl> Yes. it's incorrect.
[16:34:12 CEST] <philipl> This is what I'd expect to see.
[16:34:21 CEST] <philipl> I did say it wasn't usable.
[16:34:35 CEST] <philipl> Yeah. that's the nvidia bug
[16:34:43 CEST] <wm4> ok... then why was it applied to master? anything that supports the new ffmpeg/vdpau API will use it by default
[16:35:27 CEST] <philipl> Such as? I thought it would only opt-in.
[16:36:08 CEST] <wm4> vlc and mpv
[16:36:27 CEST] <wm4> (I'm not sure if vlc enables it by default - the player still can whitelist or blacklist on its own)
[16:38:32 CEST] <philipl> Sorry. I did all my testing with the command line and mplayer, both of which are opt-in.
[16:38:43 CEST] <philipl> And mplayer needs separate code changes to even use it.
[16:38:50 CEST] <philipl> Didn't think it would automatically trigger anywhere.
[16:39:21 CEST] <philipl> Is there a way to de-propritize it in the codec metadata?
[16:43:59 CEST] <wm4> the "new" way of enabling hw decoding is by returning the vdpau pixel format in get_format unconditionally, and using av_vdpau_bind_context()
[16:44:20 CEST] <wm4> the API user doesn't even need to know about any codecs
[16:44:40 CEST] <wm4> so when AVHWAccel.init doesn't return an error, it'll be used
[16:45:24 CEST] <wm4> I suppose we could add a flag for experimental codecs or so, and let default init fail if it's not set
[16:45:42 CEST] <philipl> There are hwaccel capabilities but no flags are defined today.
[16:46:05 CEST] <philipl> But I could add an experimental capability and repeat the equivalent logic from the codec level check
[16:46:15 CEST] <wm4> av_vdpau_bind_context() takes flags which affect decoding in various ways
[16:47:06 CEST] <wm4> e.g. AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH lies pretty much on the same code path as you'd need
[16:47:16 CEST] <philipl> K
[16:47:37 CEST] <wm4> (don't know if this is the best solution)
[16:47:58 CEST] <philipl> Well, it's the best solution that doesn't involve me explicitly disabling it in some way.
[16:48:59 CEST] <wm4> hm maybe we could actually use the global experimental codec flag?
[16:49:08 CEST] <wm4> something about -strict
[16:49:28 CEST] <philipl> Yes. That's what I started looking at.
[16:49:38 CEST] <philipl> We can check that in bind_context
[16:49:43 CEST] <wm4> AVCodecContext.strict_std_compliance and FF_COMPLIANCE_EXPERIMENTAL
[16:52:20 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174642.html <-- who knows HEVC better than me and wants to poke at this
[17:10:31 CEST] <BBB> rcombs: Daemon404 knows it pretty well, he might be able to
[17:14:50 CEST] Action: rcombs turns to face Daemon404 
[17:15:14 CEST] <rcombs> Daemon404: lemme guess: you don't like the pile of repetitive conditionals leading up to the alloc_and_copy calls?
[17:15:49 CEST] <Daemon404> no i dont like the bsd's impl in the first place
[17:15:53 CEST] <Daemon404> pre-hevc
[17:16:05 CEST] <Daemon404> im not entirely sure about mp4's hevc crap.
[17:16:17 CEST] <rcombs> I was trying to guess what you don't like about the existing implementation
[17:17:15 CEST] <Daemon404> the insertion code
[17:17:24 CEST] <Daemon404> trying to fudge it
[17:33:22 CEST] <philipl> Eh, this is harder than it looks. The AVHWAccel isn't guaranteed to be set in vdpau_bind_context
[17:33:40 CEST] <philipl> At least it's not set in the ffmpeg cli tool.
[17:36:32 CEST] <durandal_1707> michaelni: where is midterm evaluation reached?
[17:37:32 CEST] <michaelni> durandal_1707, it seems the page is not accessible before 16UTC 
[17:38:30 CEST] <wm4> sigh, all the time users complain that seeking in mpeg-ts or similar shit is broken
[17:38:54 CEST] <Daemon404> because mpeg-ts isnt meant to seek
[17:39:09 CEST] <nevcairiel> it usually works reasonably well though
[17:39:10 CEST] <Daemon404> certainly not 188byte
[17:39:14 CEST] <Daemon404> with no index
[17:45:23 CEST] <philipl> wm4: review sent
[19:13:10 CEST] <cone-666> ffmpeg 03Andreas Cadhalpun 07master:151dbe457960: mpegaudiodec: copy AVFloatDSPContext from first context to all contexts
[19:20:51 CEST] <cone-666> ffmpeg 03Andreas Cadhalpun 07master:1f1e0a2971b2: vc1dec: use get_bits_long and limit the read bits to 32
[20:05:28 CEST] <[-T-]> t
[20:25:05 CEST] <llogan> ding ding ding. we have another FFmpeg version SVN-r23418 user
[20:25:42 CEST] <llogan> not a record though
[20:40:56 CEST] <kierank> lglinskih: what have you been up to?
[20:51:07 CEST] <lglinskih> kierank: I've sent few versions of my patch with H264 test, know I'm preparing fix of my FLAC test. 
[20:51:20 CEST] <kierank> ok 
[20:51:29 CEST] <kierank> what is the next thing you should work on?
[20:51:36 CEST] <kierank> any preference?
[20:51:40 CEST] <kierank> wm4, any ideas?
[20:52:04 CEST] <wm4> for API tests?
[20:52:06 CEST] <kierank> yes
[20:52:25 CEST] <kierank> I guess it should be lossy audio
[20:52:39 CEST] <wm4> here's a touch one: check whether seeking + decoding outputs the same results when going back and forth more than once
[20:52:42 CEST] <wm4> *tough
[20:53:00 CEST] <wm4> since ffmpeg.c apparently seeks only once, this almost never gets tested
[20:53:28 CEST] <kierank> I wanted draw_horiz_band tested but that's rather niche
[21:02:23 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:2ec0ba1e2203: avcodec/jpeg2000dec: Parse POCs
[21:02:24 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:c72a83193118: avcodec/jpeg2000dec: Support progression order changes
[21:05:32 CEST] <rcombs> https://bugs.webkit.org/show_bug.cgi?id=146346 0.o an Apple employee just CC'd himself on my BPG ticket in WebKit
[21:12:57 CEST] <Daemon404> rcombs, be ashamed
[21:13:02 CEST] <Daemon404> for opening that ticket
[21:14:33 CEST] <rcombs> elaborate
[21:21:34 CEST] <cehoyos> michaelni: You also enabled p0_03.j2k from the reference files with your latest j2k patch, it looks quite broken though...
[21:26:47 CEST] <lglinskih_> kierank: Explain me, please, what is draw_horiz_band used for?
[21:27:57 CEST] <wm4> good question
[21:27:59 CEST] <wm4> MPlayer uses it
[21:28:19 CEST] <Daemon404> its so you can draw a picture as it decodes
[21:28:24 CEST] <Daemon404> in raster order
[21:28:26 CEST] <Daemon404> i believe.
[21:28:32 CEST] <Daemon404> i.e. you get one band at a time
[21:28:34 CEST] <Daemon404> rather than one pic
[21:28:43 CEST] <Daemon404> (i think)
[21:29:10 CEST] <nevcairiel> does anyone really still use that
[21:29:12 CEST] <wm4> I bet 100 flamewars on it doesn't work when using multithreaded
[21:29:15 CEST] <nevcairiel> it seems like a silly thing
[21:31:16 CEST] <Daemon404> i dont know why you would use it
[21:31:24 CEST] <Daemon404> seems like it would end up with more overhead.
[21:32:20 CEST] <kierank> If you need to process the data for hardware (e.g. v210 while it is still in cache). Also for lower latency
[21:33:08 CEST] <Daemon404> it depends how you define latency
[21:33:13 CEST] <Daemon404> it may actually be slower to get the entire pic
[21:41:58 CEST] <cone-666> ffmpeg 03James Almer 07release/2.7:459090181fe5: library.mak: Workaround SDL redefining main and breaking fate tests on mingw
[21:41:59 CEST] <cone-666> ffmpeg 03James Almer 07release/2.7:aebb9410c546: swscale/x86/rgb2rgb_template: add missing xmm clobbers
[21:42:00 CEST] <cone-666> ffmpeg 03James Almer 07release/2.7:7f2ab5e50ff7: swscale/x86/rgb2rgb_template: don't call emms on sse2/avx functions
[21:44:11 CEST] <cone-666> ffmpeg 03James Almer 07master:5abd4a932337: libvpx: disable unused function prototypes
[22:08:05 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:c56ba5c27064: avcodec/jpeg2000dec: Print what is found in place of EPH if EPH is not found
[22:08:06 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:b75c0a72ed3b: avcodec/jpeg2000dec: Fix tp_index for POC
[22:10:14 CEST] <lglinskih_> oh, thanks, it became more clear
[22:10:53 CEST] <lglinskih_> kierank: I think I'll start with seek test =)
[22:23:25 CEST] <philipl> Question for everyone: Regarding my last patch - would hwaccel capability flags be considered part of the public API? Do I need a version bump to define one (the first one)?
[22:26:39 CEST] <wm4> they're definitely public API
[22:26:51 CEST] <wm4> the field is above the "No fields below this line are part of the public API." comment
[22:27:09 CEST] <wm4> a micro bump is probably fine
[22:27:46 CEST] <philipl> Ok. That's what I suspected.
[22:28:38 CEST] <philipl> wm4: I'll change it to micro and then push.
[22:28:45 CEST] <philipl> Thanks
[22:28:58 CEST] <wm4> I wonder if this stuff is documented somewhere
[22:29:03 CEST] <wm4> but if so, then nobody can find it
[22:30:32 CEST] <philipl> Indeed.
[23:34:59 CEST] <cone-666> ffmpeg 03Kieran Kunhya 07master:22291c372fa7: avcodec: Add support for per-frame AFD output in h264
[23:36:19 CEST] <cone-666> ffmpeg 03Andreas Cadhalpun 07master:04dfbc9441be: s302m: fix arithmetic exception
[23:37:30 CEST] <jamrial> whoa, aacenc patchset
[23:37:45 CEST] <jamrial> did the epic ticket finally come to an end?
[23:39:50 CEST] <JEEBsv> wow
[23:40:05 CEST] <atomnuker> I'm afraid not, that'll happen when klaussfreire sends his patches through
[23:44:40 CEST] <jamrial> ah ok
[23:44:44 CEST] <jamrial> glad to see some of the work finally making it to the tree
[23:56:42 CEST] <cone-666> ffmpeg 03Andreas Cadhalpun 07master:072756cdd2f9: vc1dec: use get_bits_long and limit the read bits to 32
[23:56:43 CEST] <cone-666> ffmpeg 03Michael Niedermayer 07master:a4d76faf45cf: Merge commit '072756cdd2f949462520041e357f52f15d8c274d'
[00:00:00 CEST] --- Sat Jun 27 2015