Если не лень, то можно написать свой протокол, который в рамках одного TCP соединения будет осуществлять весь обмен.

для передачи видео неплохо подходит rtp и rtps

предача видео уже реализована, а можете подкинуть ссылки на туторила по rtp and rtps , в свое время искал ничего путевого не нашол.

Интересная затея но нету на это времени...

VLC Player

Можешь еще в нем посмотреть как это устроено, благо документации для него достаточно.

Передача данных реализована, вопрос как в совмещенном клиенте разспределять когда строка пришла, а когда фрэйм.

Тру ънтрпрайз решение - разнести сигнальный и нагрузочный трафик по разным портам. Это дает кое-какой профит, см. подробнее т.н. «сети нового поколения».

За примерами далеко ходить не надо: SIP + RTP

>Тру ънтрпрайз решение - разнести сигнальный и нагрузочный трафик по разным портам. Это дает кое-какой профит

Не какой-то профит, а так делать принципиально грамотно. Тут главное разнести сокеты т.к. видео нужно пускать по UDP, а команды по TCP.

Я делал подобное через CGI, общающиеся между собой при помощи POSIX'овской очереди сообщения и mmap'нутого файла конфигурации. Для изменения параметров клиент делает POST-запросы одному CGI. Видео берет с другого.

Правда, я делал через браузер, но вы не изложили посредством чего происходит контакт и нужно ли это видео на клиенте сохранять.

Тру ънтрпрайз решение - разнести сигнальный и нагрузочный трафик по разным портам. Это дает кое-какой профит, см. подробнее т.н. «сети нового поколения».

ничего найти не могу,наверное не так или не там ищу, не направите на верный путь-куда копать? как я понимаю на сервере нужно создать два сокета (в моем случае) один на порт Х для видео, другой будет управлятся другим потоком на порт У для комманд? я верно рассуждаю? новичок в этом деле...

Я делал подобное через CGI, общающиеся между собой при помощи POSIX'овской очереди сообщения и mmap'нутого файла конфигурации. Для изменения параметров клиент делает POST-запросы одному CGI. Видео берет с другого.

Правда, я делал через браузер, но вы не изложили посредством чего происходит контакт и нужно ли это видео на клиенте сохранять.

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

А почему через браузер не хотите? Это же самый простой и кроссплатформенный вариант клиента.

Верно.

я мальца с русским переводом попутал, вот линк http://ru.wikipedia.org/wiki/NGN

>советовали сделать через сериализацию еще и бустовскую, почти согласился но незнаю возможно ли будет десериализовать на шарповском клиенте

Сериализация чего, сигнального траффика? XML - глобально и надежно :)

XML - глобально и надежно :)

Зато запросы вида key1=value1;key2=value2 и т.п. легче разбирать :)

А почему через браузер не хотите? Это же самый простой и кроссплатформенный вариант клиента.

ну не нужен браузер )))кроссплатформенность тоже пока что не нужна,а если появится нужда , товсе же реализация через джаву будет... но не в этом суть сейчас.

2yoghurt

Верно.

я мальца с русским переводом попутал, вот линк http://ru.wikipedia.org/wiki/NGN

получается якобы будет два сервира работать один на порт Х другой на порт У?? это вполне приемлимо? есть какието подводные камни??

Какие два сервера? Сервер можно и один, просто будет работать через два сокета на одного клиента.

Какие два сервера? Сервер можно и один, просто будет работать через два сокета на одного клиента.

Что то я уже запутался, как сие реализовать? я создаю два сокета на каждый сокет по потоку,и уже с каждого потока биндю сокет и слушаю его так и так же send()/recv() с каждого потока ведется отдельно?

Пы.Сы. на клиенте тоже два сокета на разные порты с таким же принципом как на сервере, что я выше описал?

Смотри, вот есть у тебя сигнальный протокол, по которому идёт общение сервера с клиентом.

• Сервер говорит клиенту, что сейчас пойдет передача видео
• Клиент сообщает серверу порт, на котором он это видео может принять, ну и открывает сокет у себя на этом порту
• Сервер коннектится вторым сокетом клиенту на порт и шлёт туда поток RTP с видео.

2yoghurt

А если мне нужно что бы постоянно видео поток принимался, т.е. у меня постоянно клиент законектен на сервер и принимает видео и в тоже время нужно с клиента отправить команлу на сервер+ сервер в любой момент может сообщить об ошибке клиенту. получается у еня одновременно два сокета должно быть открыто на сервере и клиенте, так?

Пы.Сы. передача идет по TCP\IP протоколу.нету времени заниматься RTP

>получается у еня одновременно два сокета должно быть открыто на сервере и клиенте, так?

Да, так

Спасибо, вроде цель более менее ясна, буду собирать в кучу, посмотрим что выйдет.

А разве готовых приложений, выполняющих то же самое, не существует? А то взяли бы что-нибудь уже работающее, подрихтовали бы под свои нужды и - вуаля, готово. Намного быстрее будет, чем с нуля все самому писать.

не видел, жа и врят ли нечто ткое есть...

>не видел, жа и врят ли нечто ткое есть...

Давай если я ща найду, то ты мне $100?

Все уже сделали до тебя :)
RTMP -> (Media + RPC_Calls). И не придется быдлокодить на шарпе. Возми однго «Флешера за еду» :) Их ща как собак не резаных.

Все уже сделали до тебя :) RTMP -> (Media + RPC_Calls). И не придется быдлокодить на шарпе. Возми однго «Флешера за еду» :) Их ща как собак не резаных.

Проблема не в передачи видео в реалтайме, да и сама передача реализована намного проще.Реализация на С++ openCV Сервер через сокет передает видео пофрэймово, клиент через этот сокет получает,зачем мне для этого RTMP и флэшер хоть без еды за просто так?)мне нужно что бы сервер одним потоком передавал видео, другим принимал комманды и сообщал об ошибках если таковы имеются.В дискуссии выше было принято решение реализации через два сокета.Если это неудачное,неправильное,сложное и т.д. решение выслушаю другие предложения и факты , что и почему лучше использывать и изучать новые для меня протоколы-нет времени.На сервере будет вестись обработка видео в реалтайме по средствам opencv посему не вижу смысла в полученом фрэйме передавать его через протокол если модно передать просто и легко обычным raw массивом.Клиент(C#) будет этот фреэйм принимтаь и отоброжать по средствам Emgu тоже элеменатрно-без заморочек. Я больше чем уверен что в своей позиции в чемто или даже во всем могу ошибаться, за сим буду признаетелен за здравую критику или поправку и разьяснения(обьяснения).

P.S. Флэш сюда не хочу пихать вообще никаким боком, да и не только сюда а вообще с ним связываться не хочу))сорри если кого обидел .

Флэш сюда не хочу пихать вообще никаким боком

За это - браво!

А насчет велосипедостроения - ваша воля. Мне тоже нравится «велосипеды строить» - в целях саморазвития...

А насчет велосипедостроения - ваша воля. Мне тоже нравится «велосипеды строить» - в целях саморазвития...

если честно велосипеды тоже не люблю строить, но с другой стороны и в данный момент поискав и расмотрев множество предложений приобрелся некий опыт)), а во вторых ну на самом деле сомневаюсь что нечто такое есть, хотя даже представления не имею как именно такое искать,а сомневаюсь что такое есть - потому что скажем так «единичное решение/преминение» и например под сервер с двумя или тремя сокетами врят ли кто то либу писал))а втюхивать сюда протокол навороченный ну не вижу смысла, передача идет ТОЛЬКО НА ОДИН клиент и обязательно в реалтайме делать нечто с буферизацией и т.п. просто НЕЛЬЗЯ. оффтоп а самое главное я понял что буст это не очень хорошо))))если не прав буду рад услышать опровержения и обратные доводы)

А взять ffmpeg и дописать к нему небольшую обертку?

Да и вообще, если клиент всего один, почему бы просто ssh не использовать?

А взять ffmpeg и дописать к нему небольшую обертку?

а зачем, если есть openCV ?) есть готовые сервер клиент реализующий данную процедуру. код самого сервера/клиента больше самого получения картинки с камеры и сборки ее из полученного массива, если интересно могу выложит его тут. изначально думал обертку писать или юзать vlc или напрямик работа с камерой чер v4l2 но openCV реально решил задачу )

Да и вообще, если клиент всего один, почему бы просто ssh не использовать?

А тут по подробней можно: зачем, почему и в чем преимущества простой передачи через сокет?

код самого сервера/клиента больше самого получения картинки с камеры и сборки ее из полученного массива

Ну, не знаю. В моей почти аналогичной задаче код получения картинки занял ~300 строк. Еще ~400 - сжатие в jpeg и передача клиенту (через http). Правда, openCV я не использовал: почитал его описание и понял, что это не для меня...

А тут по подробней можно: зачем, почему и в чем преимущества простой передачи через сокет?

Если у вас уже есть готовое (не сетевое) приложение, работающее на сервере, зачем городить какие-то велосипеды (тем более, что вам не нужно ни записывать видео на клиенте, ни поддерживать больше 1 клиента)? Просто соединяетесь с сервером по ssh, запускаете это приложение и смотрите себе видео...

// Пы.Сы. А openCV с CUDA работает? Или для ресурсоемких задач эта библиотека не пригодна?

Хм.... видео фреймы упакованы в какой-то протокол ? или чистые даныне?
Если упаковано во чтонить, то проще пареной репы. Если нет, то городи костыли. Правда потом всеравно это боком вылезет.

Ты все неверно понял :)
То что ты описываешь/ищешь уже реализовано ну на вскидку десяток раз.
Концептуально они все подобны. Буст нормашка, но для своих задач.
Банальная сериализация это ни в коем случае не «навороченый протокол». В любом отличном случае тебе придется городить кучу костылей. Про буферизацию тоже понравилось :)

у, не знаю. В моей почти аналогичной задаче код получения картинки занял ~300 строк. Еще ~400 - сжатие в jpeg и передача клиенту (через http). Правда, openCV я не использовал: почитал его описание и понял, что это не для меня...

а зря, на самом деле ничего там сложного нет вот кусок кода захват видео с камеры + воспроизведение Сервер

CvCapture *capture = cvCaptureFromCAM(-1);
cvNamedWindow("video",CV_WINDOW_AUTOSIZE);
IplImage* originalFrame=cvQueryFrame(capture);
startSrv=boost::thread(&StartServer);//liniking functionto thread для сервера
while(1)
{
	originalFrame=cvQueryFrame(capture);
	originalFrame->origin=0;
	frame=cvCreateImage(cvSize(320,240),IPL_DEPTH_8U,3);//изменение размера картинки/фрэйма
	cvResize(originalFrame,frame,0);
	boost::recursive_mutex::scoped_lock mtx_lock(mtx);//для сервера
	FrameIsReady=true;//для сервера
	mtx_lock.unlock();//для сервера
	if(frame)
	{
		cvShowImage("video",frame);
		char c=cvWaitKey(33);
		if(c==27)
			break;
	}
}
cvReleaseCapture(&capture);
cvDestroyWindow("video");

//сборка из массива во фрэйм
for (i = 0, k = 0; i < rcvdFrame->height; i++)
{
for (j = 0; j < rcvdFrame->width; j++)
{
((uchar*)(rcvdFrame->imageData + i *rcvdFrame->widthStep))[j*3] = sockdata[k*3];
((uchar*)(rcvdFrame->imageData + i * rcvdFrame->widthStep))[j*3+1] = sockdata[k*3+1];
((uchar*)(rcvdFrame->imageData + i * rcvdFrame->widthStep))[j*3+2] = sockdata[k*3+2];
k++;
}
}

//воспроизвдение полученного и собраного фрэйма на стороне клиента
cvNamedWindow("Client",CV_WINDOW_AUTOSIZE);
while(1)
{
if(FrameIsReady)
	{
		сvShowImage("Client",rcvdFrame);
		char c=cvWaitKey(33);
		if(c==27)
		{
			FrameIsReady=false;
			break;
		}
		FrameIsReady=false;
	}
}
cvDestroyWindow("Client"); 

Если у вас уже есть готовое (не сетевое) приложение, работающее на сервере, зачем городить какие-то велосипеды (тем более, что вам не нужно ни записывать видео на клиенте, ни поддерживать больше 1 клиента)? Просто соединяетесь с сервером по ssh, запускаете это приложение и смотрите себе видео...

есть готовое сетевое решение )))я об этом уже твержу долго просто незнал как лучше и правильнее обьеденить в одном сервере передачу видео и команд и пришли к выводу на данном этапе что с помощью двух сокетов соответственно)))

если нужно могу выслать/выложить готовое черновое,НО РАБОЧЕЕ решение сервер клиент по передаче приему видео через сокет.

Банальная сериализация

одни говорят делай сериализацию, другие делай сокеты))0я уже запутался , уже было решился делать сериализацию простенько с помощью буста, но встал вопрос на который не был получен ответ-клиент на шарпе как десериализирует эти данные. то что нашол и глянул по RTMP видел выглядело не «привлекюще» и в основном пож флэш , если подскажете куда копать , копну-сериализация конечно более приемлемый вариант, если использовать RTMP я так понимаю он для видео как клиент будет различать что он получил-видео или банальную строку текста?

Хм.... видео фреймы упакованы в какой-то протокол ? или чистые даныне? Если упаковано во чтонить, то проще пареной репы. Если нет, то городи костыли. Правда потом всеравно это боком вылезет.

чистые данные, если упакованно то чем проще?про какие кастыли речь идет?сборка фрэйма из массива или реализация сокетов и т.д.?

PS

судя по вики RTMP протокол флжшофский, или я не прав? у меня язык строго и только с++.

Вы разберитесь сначала что есть сериализация :) Не совсем понял зачем для сериализации буст, но наверное там что-то есть :)
Использовать тот же РТМП никто не мешает без флеша. РТМП это просто некий протокол так же как и сип, как и ртсп... только более компактный...

Каким боком относится ПРОТОКОЛ к ЯЗЫКУ ? :)
Ну и да, сам протокол на самом деле не прост. но у него есть несколько приемов которые в Вашем случае будут очень полезны.