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

[burek]

[00:48] <Compn> michaelni : well i was saying that in reply to ubitux's comment. i had no actual idea that git master compile was broken ...
[00:56] <Compn> btw it would be cool if we had a fate bot
[00:56] <Compn> it could check fate.ffmpeg.org and report here 'fate reports compile fail!'
[00:56] <Compn> or something :)
[01:07] <michaelni> compile of vda was broken (i dont have the dependancies so had not noticed ...)
[01:07] <michaelni> i just saw it when i looked at fate 
[01:08] <michaelni> a fatebot would be nice indeed ..
[01:08] <michaelni> would need a bit of inteligence so as not to report known things
[01:08] <michaelni> or overheating ppc boxes or intel cc running out of memory
[01:09] <Daemon404> ppc just loves to overheat
[01:10] Action: Daemon404 has awesome memories of that
[01:21] <michaelni> btw, Daemon404, you should have OP as you are in MAINTAINERS and have a git clone of ffmpeg
[01:21] <Daemon404> sure
[01:21] <Daemon404> im ok with anything really
[01:21] Action: Daemon404 doesnt care about epeen on irc
[01:22] <Compn> its hard to tell who cares about status and having commit access
[01:22] <gnafu> Daemon404: Not even just a little?
[01:22] <Compn> always good to ask :)
[01:22] <Daemon404> nope :P
[01:23] <Daemon404> i may be young but ive been on irc for ~10 years
[01:23] <Daemon404> ops are boring
[01:23] <gnafu> Now's your chance to change that!
[01:23] <gnafu> Be awesome.
[01:23] <Daemon404> ;p
[01:24] <Compn> being on irc for that long , you learn that ops only cause trouble 
[01:25] <Daemon404> having opsalso causes random PMs
[01:25] <Compn> even amongst like-minded individuals :\
[01:25] <Daemon404> from newbies
[01:25] <Daemon404> daily or so
[01:25] <Compn> whitelist your pm approvals then :P
[01:25] <Compn> ehe jk
[01:26] Action: gnafu has gotten random PMs without being op.
[01:26] <Daemon404> ive been getting PMs from gsoc applicants asking for the "results of gsoc"
[01:26] <Daemon404> it's confusing.
[01:26] <gnafu> Hehe.
[01:28] <Compn> what channels do you hang out in ?
[01:28] Action: Daemon404 looks at his irssi bar with a hilight in channel 52
[01:29] <Daemon404> on freenode? ~8 chans
[01:29] <Compn> all of them are +s? hehe
[01:29] <Daemon404> no
[01:29] <Daemon404> i think
[01:29] <Compn> cept this one
[01:30] <Daemon404> [19:29] [freenode]  -!-  channels : #ffmbc @+#libav-devel #poky #UtVideo #x264dev @+#ffmpeg-devel
[01:30] <Daemon404> (one removed that is +s)
[01:30] <Compn> anyways, i think some instructions on libav gsoc say to pm an 'op' and aks for help
[01:30] <Compn> thats possibly why you get gsoc questions in libavdevel
[01:30] <Daemon404> yea
[01:30] <Compn> well you blame being an op or the instructions to pm an op, in that case ?
[01:31] <gnafu> Both, of course!
[01:31] <Compn> of course!
[01:31] <iive> it's Daemon404 fault of course.
[01:31] <gnafu> If he wasn't an op, he wouldn't need to care about the instructions.
[01:31] <Compn> well i dont actually remember the last time i was pm'd in here by newbie
[01:31] <Daemon404> it's better than people thinking im an xdcc bot
[01:32] <Compn> it would help if i identified more i guess :P
[01:32] <Compn> hmmm
[01:32] <Compn> lots of these $$ converter programs now have prores support
[01:32] <Compn> wonder how they got that...
[01:33] <Daemon404> through apple's kind acts of charity.
[01:33] <Compn> of course
[01:33] <Compn> steve jobs is a ghost in the machine
[01:33] <iive> in the shell
[01:33] <gnafu> s/shell/hell/
[01:33] <Daemon404> say what you want
[01:33] <Daemon404> apple stuff is nice
[01:33] <Daemon404> i wish i had a mac mini
[01:34] <iive> Daemon404: get one second hand. If you are lucky enough to find one that didn't broke on its own.
[01:35] <Daemon404> i was thinking of getting a refurbished one
[03:26] <funman> main debug: TIMER  : 0.000 ms - Total 2425386726513824123412325101826455280817817073886013940178100649148027127278321327603471638582279891373599947431444196332694059231614642577013085525952523027237688476255626010898605470768194704249628709211663055933138797955663315664345583084297601017174574875279360.000 ms / 8221900169169065220 intvls (Avg 0.000 ms)
[03:26] <funman> oops wrong chan
[03:31] <Compn> thats a lot of ms
[03:52] <funman> indeed :)
[05:34] <Daemon404> O_o
[08:03] <ubitux> http://lists.libav.org/pipermail/libav-devel/2012-April/025688.html
[08:03] <ubitux> :/
[08:04] Action: ubitux doesn't get it
[10:18] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r6e9c634c36 10ffmpeg/libswresample/swresample_internal.h: 
[10:18] <CIA-17> ffmpeg: swr: fix copy & pasted comment to match the code.
[10:18] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[10:18] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rf9a2c5bc07 10ffmpeg/libswresample/ (rematrix.c resample.c): 
[10:18] <CIA-17> ffmpeg: swr: simplify code by using av_get_bytes_per_sample()
[10:18] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:30] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r6c704d9c30 10ffmpeg/ffmpeg.c: 
[14:30] <CIA-17> ffmpeg: ffmpeg: support changing dither parameters for swr
[14:30] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:30] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rbe4cde226a 10ffmpeg/ (cmdutils.c cmdutils.h): 
[14:30] <CIA-17> ffmpeg: cmdutils: parse options for swr
[14:30] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:30] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * ra2c92e6063 10ffmpeg/libswresample/ (dither.c swresample.c swresample_internal.h): 
[14:30] <CIA-17> ffmpeg: swr: pass context to swri_get_dither()
[14:30] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:30] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r22057e8ecb 10ffmpeg/libswresample/ (swresample.c swresample.h): 
[14:30] <CIA-17> ffmpeg: swr: add swr_get_class()
[14:30] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:30] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rc1d404b9e4 10ffmpeg/libswresample/ (dither.c swresample.c swresample_internal.h): 
[14:30] <CIA-17> ffmpeg: swr: add a dither_scale parameter to tune the amplitude of the dither.
[14:31] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[16:16] <ubitux> michaelni: the av_interleaved_write_frame() dts failures are expected in quite a bunch of situations
[16:16] <ubitux> i guess the source of the error can be quite large?
[16:17] <michaelni> yes, 50 bugs, 1 error message, a million users who belive its the same bug 
[16:17] <ubitux> :)
[16:17] <ubitux> reminds me the "operation non permited" because of -1
[16:18] <michaelni> :)
[16:21] <Compn> ehe
[16:21] Action: Compn votes to rename the non monotonically timestamps error
[16:21] <ubitux> we should add a success message after a transcode btw, like "core dumped ;)"
[16:21] <Compn> lol
[16:22] <Compn> that only gets old users tho ubitux
[16:22] <Compn> these new linux people have never seen a core dump
[16:22] <Compn> so i vote 'kernel panic'
[16:22] <ubitux> :)
[16:23] <ubitux> i'm not sure new linux people except much "kernel panic" messages :p
[16:24] <Compn> maybe we could make a BSOD joke
[16:49] <ubitux> btw, can't we make ffmpeg ignore decoding error?
[16:50] <ubitux> i'm transcoding a broken sample, but as soon as the problematic frame fails to decode, ffmpeg stops encoding
[16:50] <ubitux> mplayer seems to be able to deal with the issue, and continue playback (output is just broken for a few frames)
[16:51] <iive> there used to be error resilience, not sure what it got renamed into.
[16:55] <michaelni> ffmpeg should not stop on a decoding error
[17:38] -:#ffmpeg-devel- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[20:40] <mbradshaw> Hello devs, I tried to ask a question about seeking in #ffmpeg but it was silent. I just want to double check I'm seeking correctly before I file a bug report. Is there anyone I can ask a few questions to make sure I'm not forgetting a function call?
[20:50] <michaelni> mbradshaw, sure, ask 
[20:51] <mbradshaw> Thanks, Michael
[20:51] <mbradshaw> So I've opened a format context and a stream, and playing the video works fine
[20:51] <mbradshaw> However, if I add the call avformat_seek_file(formatContext, -1, 0, 0, 0, 0) it seeks to a pts of 12
[20:52] <mbradshaw> if I set the starting timestamp to less than zero (something like avformat_seek_file(formatContext, -1, -100000, ts, ts, 0)) it seeks to the first frame just fine
[20:52] <mbradshaw> sorry, ts = 0 in the above line
[20:54] <mbradshaw> the stream's starting time is zero
[20:54] <mbradshaw> so I'm not sure why a negative min seek time is required
[20:54] <mbradshaw> Any ideas?
[20:55] <michaelni> could be a bug
[20:56] <nevcairiel> dont use avformat_seek_file, it doesnt give you any advantages and just confuses you
[20:56] <mbradshaw> Would you like me to file one with the full code and source sample? It's only happing with this mpeg2video I have. My h264 sample works ok.
[20:56] <nevcairiel> use av_seek_frame, and specify AVSEEK_FLAG_BACKWARDS for the flags
[20:58] <michaelni> that will likely fix it, still it shouldnt be needed
[20:59] <nevcairiel> avformat_seek_file is just a broken API. its signature might be better, but whats the point, internally it will just go ahead and call av_seek_frame
[21:00] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * rca4a3f4a08 10ffmpeg/libavformat/oggparsevorbis.c: 
[21:00] <CIA-17> ffmpeg: oggparsevorbis: Remove code messing with cur_dts.
[21:00] <CIA-17> ffmpeg: This code caused first_dts to become corrupt and in value to be
[21:00] <CIA-17> ffmpeg: around relative_ts.
[21:00] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:00] <nevcairiel> its some remnant from some attempts for better seeking that never went anywhere
[21:00] <CIA-17> ffmpeg: 03Dale Curtis 07master * r309a931a38 10ffmpeg/libavcodec/h264.c: 
[21:00] <CIA-17> ffmpeg: Fix memory leaks on failed ff_h264_decode_init()
[21:00] <CIA-17> ffmpeg: During failure conditions ff_h264_decode_init() leaks memory
[21:00] <CIA-17> ffmpeg: allocated for nal units. Found via valgrind.
[21:00] <CIA-17> ffmpeg: Valgrind traces: http://pastebin.com/GqTqxs8T
[21:00] <CIA-17> ffmpeg: Signed-off-by: Dale Curtis <dalecurtis at chromium.org>
[21:00] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:00] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r6952301f33 10ffmpeg/libavcodec/internal.h: 
[21:00] <CIA-17> ffmpeg: ff_samples_to_time_base: support AV_NOPTS_VALUE
[21:00] <CIA-17> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:00] <michaelni> nevcairiel, yes but it shouldnt need AVSEEK_FLAG_BACKWARDS
[21:01] <michaelni> if theres a keyframe at ts=0 and one seeks to 0 it should find it
[21:01] <mbradshaw> Yes, av_seek_frame works.
[21:01] <nevcairiel> that depends on the container really, alot of formats dont even have keyframe seeking. :d
[21:02] <mbradshaw> It's an mov container with a mpeg2video stream
[21:03] <mbradshaw> If I don't specify AVSEEK_FLAG_BACKWARD it seeks to a pts of 12, which I'm assuming is what avformat_seek_file is doing
[21:03] <nevcairiel> yes
[21:04] <nevcairiel> both functions do the same, except that avformat_seek_file  uses all the time values you specify to figure out the backwards flag
[21:05] <mbradshaw> Yeah, I'm just curious why AVSEEK_FLAG_BACKWARD is needed, as the first frame with ts=0 is a keyframe, so I can't see why the backward flag would be needed
[21:12] <nevcairiel> it looks like the binary search for the index entry is bugged
[21:14] <nevcairiel> or i failed at reading
[21:14] Action: nevcairiel checks again
[21:16] <nevcairiel> Nop, i think i'm right. It cannot arrive at the first index
[21:17] <mbradshaw> Hmmm... interesting.
[21:18] <nevcairiel> hm, this is confusing, i should write it down on paper
[21:18] <mbradshaw> Is this in ff_seek_frame_binary?
[21:19] <nevcairiel> ff_index_search_timestamp actually
[21:21] <nevcairiel> i think i was wrong, it seems to work fine, i mustve switched two variables around in my head. :d
[21:21] <nevcairiel> but then, why would it not work
[21:21] <nevcairiel> unless the mov forgot to mark its first frame as a keyframe
[21:21] <mbradshaw> I trasncoded the mov with ffmpeg (was h264 originally)
[21:23] <nevcairiel> maybe its a failure in the mpeg2 encoder or the mov muxer then
[21:26] <mbradshaw> When I decode the video, the first frame is reported as a keyframe (though I'm not sure if ffmpeg is doing packet reordering magic behind the scenes that might be changing this)
[21:27] <nevcairiel> that info is probably coming from the decoder then, not from the demuxer
[21:27] <mbradshaw> The next keyfram is at pts=12, which is where it's seeking to without the backwarrd flag
[21:27] <nevcairiel> you could check if the next av_read_frame after your seek to pts=0 (using the backwards flag) has the AV_PKT_FLAG_KEY or what its called set
[21:29] <mbradshaw> Yes, it does have AV_PKT_FLAG_KEY set in the first packet after the seek with the backwards flag set
[21:30] <nevcairiel> then something weird is up. :)
[21:30] <mbradshaw> Ha I think so
[21:31] <mbradshaw> Think I should submit it as a bug with the video samples?
[21:31] <nevcairiel> sure
[21:43] <Daemon404> michaelni, pingpong
[21:47] <CIA-17> ffmpeg: 03Reimar Döffinger 07master * r5735f768b0 10ffmpeg/libavcodec/ (Makefile h261data.c h261data.h h261dec.c h261enc.c): (log message trimmed)
[21:47] <CIA-17> ffmpeg: h261: move tables from header to .c file.
[21:47] <CIA-17> ffmpeg: Currently they end up twice in the binary, since both
[21:47] <CIA-17> ffmpeg: encoder and decoder include the header and thus each gets
[21:47] <CIA-17> ffmpeg: their own copy.
[21:47] <CIA-17> ffmpeg: This is clearly nonsense for the const tables, but shouldn't
[21:47] <CIA-17> ffmpeg: be necessary for the RLTable either.
[21:48] <CIA-17> ffmpeg: 03Reimar Döffinger 07master * re6ad943734 10ffmpeg/libavformat/latmenc.c: 
[21:48] <CIA-17> ffmpeg: latmenc: remove dead code.
[21:48] <CIA-17> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[21:52] <ubitux> michaelni: i think it will be pretty hard to do a reg test on the race condition in h264 decoder
[21:53] <ubitux> the issue doesn't happen often: http://fate.ffmpeg.org/history.cgi?slot=x86_64-archlinux-gcc-threads-8
[21:53] <ubitux> i've just ran a loop with h264-conformance-cama2_vtc_b test; it's been a few minutes already
[21:53] <ubitux> and the race didn't get triggered
[21:56] <ubitux> (i certainly need to slow down my system though)
[21:58] <ubitux> to do a git bisect*
[22:06] <michaelni> Daemon404, pongping
[22:08] <michaelni> ubitux, how often does the failure occur ?
[22:10] <Daemon404> michaelni, i have a question about a commit of yours:
[22:10] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=abe0b8e9f378a0f8781c1a3da6714d20cfd19594
[22:10] <Daemon404> why does shiftonly only affect luma
[22:11] <Daemon404> i dont find a reason for that in bt.709
[22:14] <michaelni> Date:   Thu Aug 25 13:54:43 2011 +0200
[22:14] <michaelni> thats long ago
[22:14] <Daemon404> yeah
[22:14] <michaelni> is it causing some problem ?
[22:14] <Daemon404> but someone asked me to backport it so ffms2 can use it
[22:15] <Daemon404> and im trying to understand it
[22:15] <Daemon404> (i.e. so ffms2 is not broken between libs)
[22:20] <michaelni> it would introduce a color bias if done for chroma IIRC
[22:20] <michaelni> but its long ago i might misremember
[22:21] <ubitux> michaelni: well i ran ~5k times the test and it didn't happen; though on fate the failure happens sometimes (all the yellow tests on the previous link are the race)
[22:22] <ubitux> i guess it's because they're run with multiple jobs at the same time
[22:22] <ubitux> so some random slow down in some functions might trigger the race, dunno
[22:23] <michaelni> 5k is alot
[22:23] <ubitux> yes :p
[22:24] <ubitux> i'm going to run a make fate-h264 with jobs instead now, and see if it triggers it
[22:26] <Daemon404> michaelni, i see
[22:28] <michaelni> 0x80 is the middle 0x8000 too but 0x8080 is not
[22:31] <CIA-17> ffmpeg: 03Reimar Döffinger 07master * rfa8a6385a1 10ffmpeg/libavformat/latmenc.c: 
[22:31] <CIA-17> ffmpeg: latmenc: remove unused return value.
[22:31] <CIA-17> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[22:31] <CIA-17> ffmpeg: 03Reimar Döffinger 07master * ra736eb4a60 10ffmpeg/libavformat/latmenc.c: 
[22:31] <CIA-17> ffmpeg: latmenc: Fix ALS in LATM.
[22:31] <CIA-17> ffmpeg: "Fix" in so far as at least it will no longer overread and possibly
[22:31] <CIA-17> ffmpeg: crash and makes somewhat sense, but no idea whether there is anything
[22:31] <CIA-17> ffmpeg: that can play the resulting files (FFmpeg can't).
[22:31] <CIA-17> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[22:31] <CIA-17> ffmpeg: 03Reimar Döffinger 07master * r8e357e8e75 10ffmpeg/libavformat/latmenc.c: 
[22:32] <CIA-17> ffmpeg: latmenc: error out when packet size is too large.
[22:32] <CIA-17> ffmpeg: Previously it would just silently write out incorrect data.
[22:32] <CIA-17> ffmpeg: This also fixes a potential integer overflow in the allocation.
[22:32] <CIA-17> ffmpeg: Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
[23:07] <ubitux> michaelni: i was able to trigger the race after 2-3 minutes
[23:07] <ubitux> i guess 20-30 make fate-h264 runs with jobs might be safe to assume it works (or not)
[23:15] <ubitux> well, it's been 5 minutes i retried, and still no failure :p
[23:18] <ubitux> anyway, i don't think a git bisect will be reliable in any way
[23:21] <burek> hi, who is the owner of this page: https://sites.google.com/site/linuxencoding/builds
[23:21] <CIA-17> ffmpeg: 03Diego Biurrun 07master * r679481b3b6 10ffmpeg/ (3 files in 2 dirs): 
[23:21] <CIA-17> ffmpeg: Drop some pointless #ifdefs.
[23:21] <CIA-17> ffmpeg: The files are only compiled if the #ifdef conditions are met.
[23:21] <CIA-17> ffmpeg: 03Diego Biurrun 07master * r9676d8eb67 10ffmpeg/libavcodec/interplayvideo.c: 
[23:21] <CIA-17> ffmpeg: interplayvideo: fix av_dlog parameter type mismatch
[23:21] <CIA-17> ffmpeg: libavcodec/interplayvideo.c:909:13: warning: format %p expects argument of type void *, but argument 7 has type GetByteContext [-Wformat]
[23:21] <CIA-17> ffmpeg: 03Luca Barbato 07master * r18b59956e0 10ffmpeg/libavformat/movenc.c: 
[23:21] <CIA-17> ffmpeg: movenc: remove redundant check
[23:21] <CIA-17> ffmpeg: The proper check is already in mov_write_header.
[23:21] <CIA-17> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[23:21] <CIA-17> ffmpeg: 03Luca Barbato 07master * rebbede2265 10ffmpeg/libavformat/movenc.c: 
[23:21] <CIA-17> ffmpeg: movenc: small refactor mov_write_packet
[23:21] <CIA-17> ffmpeg: Share the formerly internal write_packet with the hinter and move the
[23:21] <CIA-17> ffmpeg: fragment flush logic to the user facing one since it is not concerned
[23:21] <CIA-17> ffmpeg: Fixes bug #263
[23:21] <CIA-17> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[23:21] <CIA-17> ffmpeg: 03Michael Niedermayer 07master * r4f6df20a00 10ffmpeg/: (log message trimmed)
[23:21] <CIA-17> ffmpeg: Merge remote-tracking branch 'qatar/master'
[23:21] <CIA-17> ffmpeg: * qatar/master:
[23:21] <CIA-17> ffmpeg:  avplay: Don't free video filters string until the end of decoding.
[23:21] <CIA-17> ffmpeg:  movenc: small refactor mov_write_packet
[23:21] <CIA-17> ffmpeg:  movenc: remove redundant check
[23:21] <CIA-17> ffmpeg:  interplayvideo: fix av_dlog parameter type mismatch
[23:21] <CIA-17> ffmpeg: 03Alex Converse 07master * re1ce756844 10ffmpeg/avplay.c: 
[23:21] <CIA-17> ffmpeg: avplay: Don't free video filters string until the end of decoding.
[23:21] <CIA-17> ffmpeg: av_freep()ing inside configure_video_filters() leaves a dangling
[23:22] <CIA-17> ffmpeg: reference in the calling code, and the filter string is needed again when
[23:22] <CIA-17> ffmpeg: reconfiguring video filters for a size change.
[23:43] <cbsrobot> burek: hit the "donation" button
[23:43] <burek> :)
[23:43] <burek> and is john.vansickle here? :)
[23:44] <cbsrobot> no idea
[23:44] <cbsrobot> ping everybody and ask :)
[23:45] <burek> :)
[23:45] <burek> I've setup an automatic cron for static builds every day
[23:45] <burek> and it works pretty good so far
[23:45] <burek> so, I'd like to make it like that it contains all the popular freeware libraries included
[23:46] <burek> libmp3lame, libx264, etc
[23:46] <burek> and I thought to ask if anyone is interested so that we have it automated completely
[23:46] <burek> and when some newbee comes and wants to play around with ffmpeg, he/she doesn't have to compile it and stuff
[23:48] <burek> anyway, I thought to ask for suggestions from people that already have done it properly :)
[23:48] <burek> so that I don't make some beginners mistakes :)
[00:00] --- Thu Apr 12 2012