Десятка лучших консольных команд

Взято с хабра: http://habrahabr.ru/post/198482/

В данном посте я расскажу о наиболее интересных командах, которые могут быть очень полезны при работе в консоли. Однозначных критериев определения какая команда лучше другой — нет, каждый сам для своих условий выбирает лучшее. Я решил построить список команд на основе наиболее рейтинговых приемов работы с консолью от commandlinefu.com, кладовой консольных команд. Результат выполнения одной из таких команд под Linux приведен на картинке. Если заинтересовало, прошу под кат.

Десятое место

Ввод последнего аргумента недавних команд. Удерживая ALT или ESC, с каждым нажатием на точку в строку ввода будут подставляться параметры предыдущих команд, начиная от недавно введенных к старым.

Комбинация 'ALT+.' или '<ESC> .'

Девятое место

Переинициализация терминала без завершения текущей сессии. Например, в случае когда в терминал были выведены двоичные данные и он перестал корректно работать.

reset

Восьмое место

Создает пустой файл. Уничтожает содержимое файла без его удаления.

> file.txt

Седьмое место

Запуск команды с пробелом перед ней не сохраняет ее в истории. Может пригодиться при передаче паролей программам в открытом виде.

<пробел>команда

OpenCV. Processing external byte buffer

We have such an example from openCV documentation:

Mat img(height, width, CV_8UC3, pixels, step);
GaussianBlur(img, img, Size(7,7), 1.5, 1.5);

What does it mean?

Lets say I have an image img:

typedef unsigned char BYTE;
BYTE * img = new BYTE[ w * h ];

Lets assume the image is scanned line by line. So

img[ 10 * w + 3 ] is a 3-rd pixel in 10-line of image.

Then I import it in openCV is such a way:

Mat img(h, w, CV_8UC1, dmDst, w);

last argument is a pitch or stride.

Fast way of copying byte array in C/C++ (With measurements)

I have the following code for copying several buffers from one object to another:

// Copy several buffers (images)
for( int i = 0; i < MIN( conf_.size(), src.conf_.size() ); ++ i )
{
   // Copy one image per pixel
   for( int j = 0; j < MIN( sizeOfBuffer_, src.sizeOfBuffer_ ); ++ j )
   {
      conf_[i][j] = src.conf_[i][j];
   }
}

Array conf_ is defined as follows:

std::vector<BYTE*> conf_;

BYTE is unsigned char. That code is written with no doubt about software performance. It just works. When I do so I hope compiler make it better for me.
This fragment takes about 45 ms for copying of 2 images with ( 1980x1080 pixels ) x 3 planes = 6.2 MPixels.
I use Microsoft Visual Studio 2008 compiler on Intel Core i7 950 @ 3.07 GHz. The code is built for x64 platform. Disabled compiler option for buffer security check (GS-) and debug information has no effect on the productivity.

Slightly better solution:

// Copy several buffers (images)
for( int i = 0; i < MIN( conf_.size(), src.conf_.size() ); ++ i )
{

   int sizeOfArray = MIN( sizeOfBuffer_, src.sizeOfBuffer_ );

   // Copy one image per pixel
   for( int j = 0; j < sizeOfArray; ++ j )

   {
      conf_[i][j] = src.conf_[i][j];
   }
}

It takes about 35 ms per full copy.

Much better solution:

Source:Diary Of An x264 Developer

Filed under: benchmark,H.264,stupidity,test sequences ::

Over the past few years, practically everyone and their dog has published some sort of encoder comparison. Sometimes they’re actually intended to be something for the world to rely on, like the old Doom9 comparisons and the MSU comparisons. Other times, they’re just to scratch an itch — someone wants to decide for themselves what is better. And sometimes they’re just there to outright lie in favor of whatever encoder the author likes best. The latter is practically an expected feature on the websites of commercial encoder vendors.
One thing almost all these comparisons have in common — particularly (but not limited to!) the ones done without consulting experts — is that they are horribly done. They’re usually easy to spot: for example, two videos at totally different bitrates are being compared, or the author complains about one of the videos being “washed out” (i.e. he screwed up his colorspace conversion). Or the results are simply nonsensical. Many of these problems result from the person running the test not “sanity checking” the results to catch mistakes that he made in his test. Others are just outright intentional.
The result of all these mistakes, both intentional and accidental, is that the results of encoder comparisons tend to be all over the map, to the point of absurdity. For any pair of encoders, it’s practically a given that a comparison exists somewhere that will “prove” any result you want to claim, even if the result would be beyond impossible in any sane situation. This often results in the appearance of a “controversy” even if there isn’t any.
Keep in mind that every single mistake I mention in this article has actually been done, usually in more than one comparison. And before I offend anyone, keep in mind that when I say “cheating”, I don’t mean to imply that everyone that makes the mistake is doing it intentionally. Especially among amateur comparisons, most of the mistakes are probably honest.
So, without further ado, we will investigate a wide variety of ways, from the blatant to the subtle, with which you too can cheat on your encoder comparisons.

Using h264/multiview codec from Intel Media SDK

I needed to launch multiview compression using codec from Intel MVC. Approximately a half a year ago I launched it normally. Yesterday it tried and I got such an error:

$ ./sample_encode.exe h264 -i input.yuv -o output.h264 -w 1920 -h 1080
Return on error: error code -3, .\src\pipeline_encode.cpp 865

Return on error: error code 1, .\src\sample_encode.cpp 343
Frame number: 0

I started debug and found out the error appears in

MFXVideoSession::mfxStatus Init(mfxIMPL impl, mfxVersion *ver)
{
return MFXInit(impl, ver, &m_session);
}

Error code

MFX_ERR_UNSUPPORTED = -3, /* undeveloped feature */

Of course, the cause was in missing dll.

libmfxsw32.dlllibmfxsw64.dll

After I added it to console's directory everything became fine.

PS I could not build sample_encode with Visual Studio 2008. So use 2010 instead.

Using ls command

ls -w1 */ - show only subdirectories in current directory (*/) and display in 1 column (-w1)
ls -c - sort by date

Некоторые заметки о приведении типов в СиПлюсПлюс

АлёнаC++:
http://alenacpp.blogspot.ru/2005/08/c.html

static_cast между указателями корректно, только если один из указателей - это указатель на void или если это приведение между объектами классов, где один класс является наследником другого. То есть для приведения к какому-либо типу от void*, который возвращает malloc, следует использовать static_cast.

int * p = static_cast<int*>(malloc(100));

Если приведение не удалось, возникнет ошибка на этапе компиляции. Однако, если это приведение между указателями на объекты классов вниз по иерархии и оно не удалось, результат операции undefined. То есть, возможно такое приведение: static_cast<Derived*>(pBase), даже если pBase не указывает наDerived, но программа при этом будет вести себя странно.

Image&video processing, programming etc