Ogame's new portal, not surprisingly, broke tons of stuff.
Firefox no longer seems to remember usernames/passwords with it, and they also broke the FoxGame extension.
Ogame's new portal, not surprisingly, broke tons of stuff.
Firefox no longer seems to remember usernames/passwords with it, and they also broke the FoxGame extension.
TRWTF is the comments. The code does a strict superset of the calculations as the non-FAST MODE; it does all the same loads, so it cannot possibly be "cache locality". Even x86 has enough registers to make that trick worthless, and this code isn't targeted at an 8-bit 8086. The only possible benefit is SIMD -- and if they wanted to use that, they could just write two lines of intrinsics.
From the Tandberg/ Nokia/ Ericsson H.265 video compression proposal (A119 here). Bonus points: their powerpoint says "Clean and fast software written from scratch using C".
/*-----------------------------------------------------------------------------------------
Function: SAD_64x64
Purpose: Calculate SAD for a 64x64 block
Input: *a - Pointer to first block
*b - Pointer to second block
stridea - stride of first block
strideb - stride of second block
Return: sad - SAD value
Parameters: None
-------------------------------------------------------------------------------------------*/
static inline unsigned int SAD_64x64(const unsigned char *a,
const unsigned char *b,
const int stridea,
const int strideb)
{
int i,j;
unsigned int sad = 0;
#if FAST_MODE
for (i=0;i<64;i++)
{
unsigned char b_[64];
for (j=0;j<64;j++)
b_[j] = b[i*strideb+j];
for (j=0;j<64;j++)
sad += abs(a[stridea*i+j] - b_[j]);
}
#else
for (i=0;i<64;i++)
for (j=0;j<64;j++)
sad += abs(a[stridea*i+j] - b[i*strideb+j]);
#endif
return(sad);
}
This "FAST_MODE" pattern is repeated for about 10 different copy-pastes of the same function with different input sizes. Sometimes they use memcpy instead of a for loop. I still am not quite sure what the author of this was trying to accomplish.
@ender said:
@Dark Shikari said:Ogg wasn't "designed", it was thrown together in the same fashion that a 4 year old cleans up his room by hiding all the toys in the closet.It definitely won't work for AVI, MP4, or MKV, and probably won't work for FLV, OGG, or WMV/ASF.One of design goals of Ogg was to be able to simply cat files together.
@Tacroy said:
Erm, if you're dealing with mpeg video fragments, you can usually just concatenate them together. e.g,
cat vid1 vid2 vid3 > vid123
(assuming the fragments aren't too huge, otherwise use dd). In Windows,type vid1 vid2 vid3 > vid123
should work but I've never tried it and Windows tends to mess this sort of thing up.In fact, it should work as long as all of the fragments use the same encoding scheme, and it isn't ridiculously old. Modern encoding schemes are based on a packet stream model, and don't really care about file boundaries.
This won't work for anything with a global header, i.e. almost any modern video container format. It'll work for MPEG-2 TS, and maybe PS depending on the phase of the moon and how much you like desynced audio, and that's about it. It definitely won't work for AVI, MP4, or MKV, and probably won't work for FLV, OGG, or WMV/ASF.
SUPER is a pile of unusable buggy garbage. There are a gajillion better GUIs, and of course you can just go and use the libraries directly via the commandline.
A tiny selection of better (free) GUI applications:
Handbrake
Staxrip
Ripbot264
HDConvertToX
Avidemux
MeGUI
AutoMen
ASXGui
And CLI:
x264
ffmpeg
mencoder
handbrake-cli
Keep in mind that nearly every single freeware H.264 encoder in the entire world uses x264 with about half a dozen exceptions total, so they're all using the same encoding library anyways.
@fennec said:
I believe that Popular Science or Popular Mechanics had an issue about a nucleonic airplane concept (thorium strobed with X-Rays).Recently, too (not just in the 60's, in the 90's or 2000's).
From what I recall, both the US and Soviets tried this one out: imagine an airplane that could fly around for months without refueling? It's the nuclear tactician's dream. And I mean a full nuclear reactor on a plane.
It actually worked, but there were two "small" problems:
1. Enough shielding to protect a full crew would make the plane far too heavy to take off. This could be solved by having a single crew member, or even making the plane autonomous.
2. It seems almost possible at this point... except for one problem. It turns out that most of the atoms in the air are not easily neutron-activateable; oxygen, carbon, etc won't generally become radioactive from neutron bombardment. But xenon, a trace impurity, does. A lot. And so the plane would become a gigantic machine spewing highly radioactive Xenon wherever it flew.
They decided that this was probably a bad idea and gave up.
The log speaks for itself.
16:59 -!- mohamedferose [n=mohamedf@219.64.67.150] has joined #x264
16:59 < mohamedferose> Hi Zarxrax
16:59 < mohamedferose> How is going on
16:59 < mohamedferose> Z0rc
17:00 < mohamedferose> Topic About x264 is so boring
17:00 < mohamedferose> how u implemets
17:00 < mohamedferose> pls post me sorce conde
17:00 < mohamedferose> whaer is it c
17:01 -!- mohamedferose [n=mohamedf@219.64.67.150] has quit [Client Quit]
I find it amazing that not only do they insist that someone "post me sorce conde", but that if they don't get their "sorce conde" within 1 minute, they leave.
@Rootbeer said:
Speaking Super(TM)(R)(C)(MRUEQ), can anyone recommend a GUI frontend for video encoding that DOESN'T make me bleed out of the eyes and anus with its utter and all-consuming interface awfulness?
Ripbot264? AutoMKV? Staxrip? Handbrake? Megui?
If you need Vdub-like editing functionality (trim, etc), Avidemux?
@Someone You Know said:
That was the greatest presentation ever.Chicken chicken chicken. Chicken chicken? Chicken.
I mean, chicken chicken chicken chicken, chicken chicken, chicken chicken chicken!