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

[burek]

[00:12] <cone-154> ffmpeg.git 03Michael Karcher 07master:dcbb920f1587: Fix atrac3 decoder broken in e55d53905f34f8e8747f6d321e9a695dc02ebb2f
[00:18] <beastd> ^^^  e55d53905f34f8e8747f6d321e9a695dc02ebb2f  is  "atrac3: cosmetics: pretty-printing and renaming" "also does some minor refactoring."
[00:18] <beastd> That is why I dislike this heavily squashed cosmetic patches
[00:19] <JEEBsv> if there's refactoring, that's no longer cosmetics IMNSHO
[00:19] <beastd> JEEBsv: yeah, kind of fuzzy line but i tend to agree
[00:21] <beastd> also the error that introduced was as folloes: rename var in outer loop from cnt to i + rename variable from inner loop from i to j . In the 2nd rename the loop body was forgotten so it still contained i which was still there because of the 1st rename.
[00:29] <beastd> IMHO it is best to just make a 1st patch that does all whitespace cosmetics that will produce zero output if diffed with "git diff -b" .  then add a series with small consistent changes that are easy  to review on top of that.  this way there is a chance you will get a minimum eyeballing from e.g. patch readers or commit reviewers.
[00:31] <j-b> just use tig -b to review 
[00:32] <beastd> Despite IMHO one should never apply cosmetics on a file one doesn't intent to work on *soonish*. With open source software and especially with recent popularity of Git there is a (high) chance someone is working on that very file you pointlessly change.
[00:32] <burek> llogan, did you try to check the git hash from that tessus ffmpeg (from the forum)
[00:32] <beastd> Happened to me multiple times and I am not a frequent patch contributor...
[00:33] <burek> it seems the git hash does not exist in ffmpeg's git
[00:57] <RamajanSan> HI
[01:19] <llogan> burek: no, i didn't check.
[01:29] <burek> maybe he cloned it to his own git or something, dunno
[02:33] <cone-154> ffmpeg.git 03Michael Niedermayer 07master:53a3fdbfc56d: 4xm: Check available space in read_huffman_tables()
[02:33] <cone-154> ffmpeg.git 03Michael Niedermayer 07master:d73b65ed0ebc: 4xm: add assert to check that the pointer from read_huffman_tables is within the array
[02:33] <cone-154> ffmpeg.git 03Michael Niedermayer 07master:cfc7b9cfff65: 4xm: remove avcodec_get_frame_defaults() calls
[03:43] <cone-154> ffmpeg.git 03Michael Karcher 07release/1.1:302094e1d2ea: Fix atrac3 decoder broken in e55d53905f34f8e8747f6d321e9a695dc02ebb2f
[04:35] <cone-154> ffmpeg.git 03Michael Niedermayer 07master:66daebc9d50d: indeo4: check for invalid transform_size blk_size combinations
[04:35] <cone-154> ffmpeg.git 03Michael Niedermayer 07master:c8f25cafd2f2: atrac3: fix buffer size for get_bits.
[05:21] <Daemon404> that ami... always amazes me what he finds
[05:21] <llogan> Daemon404: same. i don't know what in hell he does to do that.
[05:24] <llogan> burek: i didn't forget about your fate stuff. i intend to take a look after things slow here.
[05:26] <Darkarnium> Hey all, quick, and somewhat strange question regarding url_open2. Looking through a patch, there's an option added to an avdict that's passed as the 'options' attribute into ffurl_open, which appears to cascade down to url_open2. How can I determine the supported values that url_open2 will accept?
[05:27] <Darkarnium> As in, there's a 'user-agent' added, which works, however, there's also a 'cookies' option set, which doesn't end up in the HTTP request. If I rewrite to snprintf into a 'headers' option and pass that, the cookie does appear in the HTTP request.
[05:28] <Darkarnium> Which makes me suspect that 'cookies' in not a valid option in an AVDict / Option to url_open2. Unless I'm losing the plot, which is entirely possible :)
[05:28] <wm4> I've used "cookies" successfully lately
[05:30] <wm4> probably all a matter of using it correctly, maybe I can help...
[05:31] <wm4> though url_open2 is not a public API so you're probably asking from an implementer's perspective or something
[05:31] <Darkarnium> Ahh, I thought as much 
[05:32] <Darkarnium> What format were you required to pass the cookie in? A "Set-Cookie" HTTP header style attribute - value and options "foo=bar; path=/ .. etc" or just attribute value ("foo=bar")
[05:32] <Darkarnium> ?
[05:32] <wm4> Set-Cookie
[05:32] <wm4> the reason is probably that it allows specifying cookies per-domain
[05:33] <wm4> http://curl.haxx.se/rfc/cookie_spec.html
[05:33] <Darkarnium> Alright, I'll give it a crack :)
[05:33] <Darkarnium> Cheers
[06:04] <Darkarnium> wm4: Any chance of an example in your usage? As per the spec, only the attribute / value is required. Even so, if I also set the path, expires and domain fields, the cookie doesn't make it to the HTTP header. In this instance, I'm adding an option to override via CLI arguments to allow for a cookie to be set by the client when ffmpeg / ffplay is called - due to an appliation generating the cookie client side from an XML HTTP response, rather than by
[06:05] <wm4> Darkarnium: your message was cut off at "than by"
[06:05] <Darkarnium> a Set-Cookie HTTP header from the remote web service.
[06:05] <wm4> I don't quite remember the code, but maybe setting the domain is required
[06:08] <wm4> I'm basically doing sprintf(result, "%s=%s; path=%s; domain=%s; \n", name, value, path, domain) (yeah don't use sprintf)
[06:09] <wm4> and pass that as "cookies" option
[06:09] <Darkarnium> Alright, I'll wrap it up in an snprintf and give it a shit
[06:09] <Darkarnium> ...shot rather
[06:09] <Darkarnium> Thanks again for your help :)
[06:35] <cone-154> ffmpeg.git 03Michael Niedermayer 07master:61884d198521: sws: GBRP output support
[06:35] <cone-154> ffmpeg.git 03Michael Niedermayer 07master:e4033d89f172: sws: GBRP9, GBRP10 GBRP12 GBRP14 output support
[06:37] <Daemon404> michaelni, ill fix up my old patch tomorrow
[06:37] <Daemon404> and re-send it
[06:38] <michaelni> Daemon404, ok thx
[10:43] <cone-258> ffmpeg.git 03Paul B Mahol 07master:254e11cc019d: lavf/gifdec: fix typo
[10:43] <cone-258> ffmpeg.git 03Paul B Mahol 07master:d1d159d31ecb: lavf/gifdec: cosmetics: remove extra whitespace
[10:43] <cone-258> ffmpeg.git 03Paul B Mahol 07master:9648e1495bf6: lavc/gif: remove some obsolete/irrelevant chunks
[11:03] <durandal_1707> michaelni: i get [swscaler @ 0x295f9000] 42bpp not supported by yuv2rgb
[11:07] <durandal_1707> when doing yuv420p -> gbrp14
[11:20] <cone-258> ffmpeg.git 03Nicolas George 07master:fccd8c21c40c: ffmpeg: add -guess_layout_max option.
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:b6afb2dde1aa: lavfi: support unknown channel layouts.
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:7bb98b753b45: lavfi: implement ff_all_channel_counts().
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:b6b2f3433c21: lavfi: implement ff_query_formats_all().
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:19506af788b6: lavfi/sink_buffer: accept unknown channel layouts.
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:ea645e90a1ea: lavfi/buffersrc: accept unknown channel layouts.
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:6d962aec8dd3: lavfi/af_aformat: accept unknown channel layouts.
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:b00502457ac3: lavfi/af_aresample: accept unknown channel layouts.
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:699b286a2145: lavfi/af_anull: accept unknown channel layouts.
[11:21] <cone-258> ffmpeg.git 03Nicolas George 07master:41f025dff0a3: ffmpeg: support filtering of unknown channel layouts.
[11:23] <durandal_1707> michaelni: why isAnyRGB have grbp in it?
[11:26] <cone-258> ffmpeg.git 03Nicolas George 07master:255ae9f38096: lavfi: version bump and change log entries after the last commits.
[11:40] <cone-258> ffmpeg.git 03Nicolas George 07master:5361f4958fbf: fate: add an attachment to the Matroska test.
[11:42] <saste> ^^ please mention git hash when closing bugs
[12:21] <durandal_1707> michaelni: should isAnyRGB list all gbrp formats and not just gbrp?
[13:00] <cone-258> ffmpeg.git 03Nicolas George 07master:42c6f2a645a8: lavfi/vf_drawtext: default to expansion=normal.
[13:03] <cone-258> ffmpeg.git 03Paul B Mahol 07master:25c75525bf1d: lavc/iff: ilbm: unbreak decoding on big endian
[13:43] <cone-258> ffmpeg.git 03Luca Barbato 07master:5ea5ffc9cee1: doc: support multitable in texi2pod
[13:44] <cone-258> ffmpeg.git 03Justin Ruggles 07master:38c1466ca41c: dict: add av_dict_parse_string()
[13:44] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:e7e14bc69a60: Merge commit '38c1466ca41c73c7ce347da702362cb69c151716'
[13:47] <durandal_1707> does anyone know link of j2k repo that certain dev is working on?
[14:23] <cone-258> ffmpeg.git 03Gavriloaie Eugen-Andrei 07master:29b553c1a663: libx264: introduce -x264-params private option
[14:23] <cone-258> ffmpeg.git 03Luca Barbato 07master:ded3673d7794: doc: document libx264 options and mappings
[14:23] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:d235d240d8ba: Merge commit 'ded3673d77943c376d94e8157b1238bbd1eeca2d'
[14:37] <cone-258> ffmpeg.git 03Michael Karcher 07master:0e3afacd4d8f: atrac3: use correct loop variable in add_tonal_components()
[14:37] <cone-258> ffmpeg.git 03Diego Biurrun 07master:033a86f9bb6f: x86: h264qpel: Move stray comment to the right spot and clarify it
[14:37] <cone-258> ffmpeg.git 03Anton Khirnov 07master:69c25c928464: dnxhdenc: fix invalid reads in dnxhd_mb_var_thread().
[14:37] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:446d62f0cfea: Merge commit '69c25c9284645cf5189af2ede42d6f53828f3b45'
[14:43] <cone-258> ffmpeg.git 03Anton Khirnov 07master:6837bd6e49d5: txd: return meaningful error codes.
[14:43] <cone-258> ffmpeg.git 03Anton Khirnov 07master:0859eaa0122b: cyuv: return meaningful error codes.
[14:43] <cone-258> ffmpeg.git 03Anton Khirnov 07master:ade402804a0e: eatgv: return meaningful error codes.
[14:43] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:3a9f48f0337d: Merge commit 'ade402804a0e811cd00862c90559121a793054a6'
[14:51] <saste> uhm... multitable HTML rendering sucks
[14:58] <cone-258> ffmpeg.git 03Anton Khirnov 07master:4b7598e2fe07: eatgv: cosmetics, reformat
[14:58] <cone-258> ffmpeg.git 03Anton Khirnov 07master:f337c29017b1: eatgq: return meaningful error codes.
[14:58] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:325ee4ed7ad2: Merge commit 'f337c29017b10c98ccb4dce20efced4c74b665f6'
[15:07] <cone-258> ffmpeg.git 03Paul B Mahol 07master:27cadb9ce3f0: remove av_strnstr from Changelog
[15:11] <cone-258> ffmpeg.git 03Paul B Mahol 07release/1.1:c2d2bf1d6bf1: lavc/iff: ilbm: unbreak decoding on big endian
[15:16] <cone-258> ffmpeg.git 03Stefano Sabatini 07master:c0c06c1bba80: doc/texi2pod: fix warnings introduced in e7e14bc69a606a6bec82efef729263cd38f122d4
[15:23] <cone-258> ffmpeg.git 03Anton Khirnov 07master:adf0110d878d: eatgq: cosmetics, reformat.
[15:23] <cone-258> ffmpeg.git 03Anton Khirnov 07master:edb2426b75a1: dxa: return meaningful error codes.
[15:23] <cone-258> ffmpeg.git 03Anton Khirnov 07master:9221c0af772e: pngdec: cosmetics, reformat.
[15:23] <cone-258> ffmpeg.git 03Anton Khirnov 07master:04e12496094a: iff: drop ff_ prefix from a static function.
[15:23] <cone-258> ffmpeg.git 03Anton Khirnov 07master:a0cabd0a2758: mimic: cosmetics, reformat
[15:23] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:8ab97a60ef94: Merge commit 'a0cabd0a27587525e90a44660c795d40d2f44fe2'
[15:28] <someone-noone> Hello! I'm developing own container-format and have problems while decoding h264(other codecs work fine). When I try to decode my file I always receiving "no frame!" error. Looks like I doesn't provide some options for h264. Which one?
[15:33] <Compn> someone-noone : check how nut or libnut contains h264 ?
[15:33] <Compn> maybe ti will give you hint on the missing parser or other missing thing
[15:33] <someone-noone> Compn, thanks
[15:33] <Compn> since nut is a simple container. maybe it will be easy 
[15:33] <Compn> :)
[15:34] <someone-noone> Compn,  thanks.. Because, I was starting from avi...
[15:34] <Compn> haha
[15:34] <Compn> not supposed to put h264 in avi 
[15:35] <someone-noone> anyway I'm new in "containers" world. So I didn't know from where to start. :)
[15:37] <Compn> why making a new container ?
[15:38] <Compn> why not just use nut? its about as good as a new container, since very little supports it :)
[15:40] <someone-noone> Compn, I need some specific container that can be dividable by fixed-size chunks (1300 bytes)
[15:41] <someone-noone> for example: header - chunk1 - chunk2 - chunk3
[15:41] <durandal_1707> why 1300 bytes?
[15:41] <someone-noone> and this container can be played in next situation: header - chunk2 - chunk3
[15:41] <someone-noone> 1300 minimum MTU
[15:42] <someone-noone> not minimum, but nearly all has value greater than 1300 bytes
[15:42] <iive> someone-noone: why not use mpeg-ts?
[15:42] <someone-noone> iive, mpeg-ts can have fixed size chunks?
[15:42] <nevcairiel> mpeg-ts is always 188 byte chunks
[15:43] <someone-noone> hm
[15:43] <nevcairiel> you can use 7, then you have 1316
[15:44] <someone-noone> nevcairiel, and where header is stored? In the beginning or in each chunk? How can I pass such stream to player (decoder)
[15:45] <nevcairiel> there is a small mpeg-ts header in front of every chunk, and there is also pes headers inside the data, and data packets can also contain header-like tables, like pmt/pat/sdt, etc
[15:46] <someone-noone> nevcairiel, so actually, I can play starting from any chunk, right?
[15:46] <someone-noone> start playing *
[15:46] <someone-noone> sorry for english :)
[15:46] <nevcairiel> not any chunk, but it usually doesnt take long to find one where you can get all info you need
[15:46] <cone-258> ffmpeg.git 03Anton Khirnov 07master:b965cb906bed: mimic: return meaningful error codes.
[15:46] <cone-258> ffmpeg.git 03Anton Khirnov 07master:0ce033f88852: rawdec: cosmetics, reformat
[15:46] <cone-258> ffmpeg.git 03Anton Khirnov 07master:7bcaeb408e3e: mjpegdec: fix indentation
[15:46] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:8380fc88845e: Merge commit '7bcaeb408e3eb2d2f37a306009fa7fe7eb0f1d79'
[15:47] <someone-noone> nevcairiel, thanks
[15:47] <iive> mpeg-ts is used for DVB-S/C/T and the other non-eu standards for digital TV
[15:47] <iive> they also include the usage of h264 for hdtv.
[15:48] <someone-noone> hm& that makes reason for me
[15:48] <iive> it is usually encapsulation format, where the video/audio is carried by mpeg-ps or mpeg-es
[15:50] <someone-noone> anyway can't repack mp4 into mpeg-ts 
[15:50] <someone-noone> Failed to open bitstream filter h264_mp4toannexb for stream 0 with codec copy: Invalid argument
[15:51] <someone-noone> ./ffmpeg -i test.mp4 -vcodec copy -acodec copy -bsf h264_mp4toannexb test.ts
[15:51] <cone-258> ffmpeg.git 03Anton Khirnov 07master:3f47d316cda9: mpegvideo_enc: do not modify the input frame.
[15:51] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:c46943ec19df: Merge commit '3f47d316cda9037024ffbc76f789332e62b729bc'
[16:37] <durandal_1707> doesnt this iff nonsense can be much smaller if one stop using single while{} instead of multiple for loops
[18:40] <cone-258> ffmpeg.git 03Anton Khirnov 07master:04f4dbc2fa7c: mpegvideo_enc: fix indentation in load_input_picture()
[18:40] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:5cb0782b952f: Merge remote-tracking branch 'qatar/master'
[18:55] <Daemon404> i really wish i didnt keep finding functional changes introduced in merge commits
[18:55] <Daemon404> its damn enar impossible to figure out the intent
[18:55] <Daemon404> near*
[18:57] <beastd> Seems michaelni is not hear at the moment.
[18:58] <beastd> Daemon404: It can get hairy with conflicts. Besides conflict resolutions I agree it would be better to commit the merge. and then a set of patches and then push all together.
[18:59] <Daemon404> beastd, these are not conflict fixe
[18:59] <Daemon404> stheyre straight up functional changes
[18:59] <Daemon404> for bug fixes
[18:59] <Daemon404> there's no excuse for that.
[18:59] <beastd> well there is one. bisectabilitly
[18:59] <beastd> bisectability
[19:00] <Daemon404> it's just as bisectable if you push a post-merge bug fix
[19:00] <Daemon404> with a proper message
[19:00] <beastd> Daemon404: a bug could go on and off and that could be hit when bisecting
[19:01] <beastd> Daemon404: But I am in favor to do such things in separate commits  because of communication and documentation benefits
[19:04] <beastd> One could also opt for writing long merge commit messages,  but that is currently not a strength of michaelni.
[19:05] <beastd> So I still favor merge first, do one or more commits on top if needed. Then push out all in one go.
[19:06] <beastd> We should tell michaelni though. As he does virtually all the merges it is not very productive to discuss without him-
[19:28] <durandal_1707> why are refcounted buffers unaligned?
[19:50] <nevcairiel> they are only unaligned if you use realloc, because many systems dont have an aligned realloc
[19:51] <Daemon404> you could use je_reallocm or w/e
[19:51] <Daemon404> :P
[19:51] <nevcairiel> windows has an aligned realloc, so see if i care!
[19:52] <Daemon404> lol
[19:52] <Daemon404> durandal_1707, is on freebsd though
[19:52] <Daemon404> and iric freensd's *alloc funcs are idneed je
[19:53] <Daemon404> though you might need an m suffix
[20:44] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:4e585f63257b: sws: use planarRgbToRgbWrapper only for 8bit per component
[20:44] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:3c2ecfcc2476: sws: dont enable chrSrcHSubSample for planar RGB
[20:44] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:02001a372de6: sws: add planar RGB formats to isAnyRGB
[21:41] <beastd> oi michaelni
[21:41] <beastd> Daemon404 complained about merge commits being hard to follow
[21:41] <Daemon404> no i didnt
[21:41] <Daemon404> i complained about adding functional changes and bgu commits in merge commits
[21:43] <beastd> Daemon404: was about to complete that but didn't want to paste the whole discussion
[21:43] <nevcairiel> some merge commits are impossible to read anyway, i never really know if some diff it shows is just because of a 3-way merge it performed due to differences between the versions, or if some manual changes went in <.<
[21:43] <beastd> michaelni: maybe you can find it in channel log
[21:44] <beastd> was about 3h ago
[21:44] <michaelni> 3h ago my logs are full of " Disconnected (Connection reset by peer)."
[21:45] <beastd> flood :)
[21:46] <beastd> [18:55:26] <@Daemon404> i really wish i didnt keep finding functional changes introduced in merge commits
[21:46] <beastd> [18:55:37] <@Daemon404> its damn enar impossible to figure out the intent
[21:46] <beastd> [18:55:40] <@Daemon404> near*
[21:46] <beastd> [18:57:52] <@beastd> Seems michaelni is not hear at the moment.
[21:46] <beastd> [18:58:49] <@beastd> Daemon404: It can get hairy with conflicts. Besides conflict resolutions I agree it would be better to commit the merge. and then a set of patches and then push all together.
[21:46] <beastd> [18:59:07] <@Daemon404> beastd, these are not conflict fixe
[21:46] <beastd> [18:59:14] <@Daemon404> stheyre straight up functional changes
[21:46] <beastd> [18:59:16] <@Daemon404> for bug fixes
[21:46] <beastd> [18:59:21] <@Daemon404> there's no excuse for that.
[21:46] <beastd> [18:59:34] <@beastd> well there is one. bisectabilitly
[21:46] <beastd> [18:59:42] <@beastd> bisectability
[21:46] <beastd> [19:00:01] <@Daemon404> it's just as bisectable if you push a post-merge bug fix
[21:46] <beastd> [19:00:12] <@Daemon404> with a proper message
[21:46] <beastd> [19:00:48] <@beastd> Daemon404: a bug could go on and off and that could be hit when bisecting
[21:46] <beastd> [19:01:37] <@beastd> Daemon404: But I am in favor to do such things in separate commits  because of communication and documentation benefits
[21:46] <beastd> [19:04:11] <@beastd> One could also opt for writing long merge commit messages,  but that is currently not a strength of michaelni.
[21:46] <beastd> [19:05:17] <@beastd> So I still favor merge first, do one or more commits on top if needed. Then push out all in one go.
[22:44] <durandal_1707> michaelni: the 4e585f63257bfacb4a9d is funny as prev line too
[22:46] <durandal_1707> prior you added other gbrp to isAnyRGB...
[22:47] <durandal_1707> also such checks like !=,==,&& .. can be simplified
[22:50] <durandal_1707> Daemon404: you sure you did not miss some part of code in your patch?
[22:50] <Daemon404> what patch
[22:51] <Daemon404> i havent resubmitted my patch form months ago yet
[22:52] <durandal_1707> michaelni: so no way to fix red warning?
[23:23] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:f0d3a031150f: sws: include isRGB in  isAnyRGB() so that future RGB formats wont be missed again
[23:23] <cone-258> ffmpeg.git 03Michael Niedermayer 07master:6512405ce203: sws: disable yuv2rgb warning for planar rgb.
[23:30] <durandal_1707> michaelni: that isAnyRGB is still weird
[23:30] <durandal_1707> now it list bitstream rgb and pseudopal crap.....
[23:38] <wm4> what is pseudo-pal at all?
[23:40] <durandal_1707> wm4: pixel format that use pallete but do not need too ...
[23:42] <wm4> so does a picture have a palette or not?
[23:43] <durandal_1707> it have pseudo palette
[23:43] <Daemon404> and wtf is a pseudo palette
[23:44] <Daemon404> sure is ambiguous terms
[23:44] <wm4> a "figure it our yourself moron" style of API
[23:45] <durandal_1707> it is toy, why do you still play with toys?
[23:45] <beastd> wm4. Daemon404: the pal is not stored in the file but generated by the decoder
[23:45] <durandal_1707> swscale actually
[23:46] <wm4> is that by libswscale can output AV_PIX_FMT_BGR4, but not take it as input?
[23:48] <durandal_1707> only for bitstream variant of bgr4
[23:49] <durandal_1707> byte one have IO 
[23:49] <durandal_1707> wm4: you have nothing better to do?
[23:49] <wm4> no
[00:00] --- Sun Jan 27 2013