Как считать использование, C++ (C#) звучит как поток, отправленный флэш-памятью?

Вы можете попробовать использовать звуковую систему из проекта Gnash .

Как на самом деле отправляется звук? Через сеть?

Редактировать : вы будете либо захватывать звук из потока HTTP, либо из потока RTMP. Запустите Wireshark, чтобы узнать, но я подозреваю, что вы делаете что-то слегка сомнительное ...

Итак, в основном вы хотите подключиться к звуковому потоку RTMP с сервера флэш-памяти из произвольного приложения без флэш-памяти? Вы видели http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol ?

К сожалению, Adobe ЯВЛЯЕТСЯ относительно проприетарным (отсюда происходят войны между яблоками и Adobe в последнее время), но для нескольких языков существуют проекты, с которыми можно помочь. RTMP.

WebOrb является коммерческим, для .NET, Java, PHP: http://www.themidnightcoders.com/products.html

FluorineFX является открытым исходным кодом только для .NET: http://www.fluorinefx.com/

Я не использовал ни того, ни другого для RTMP, но я использовал FluorineFX для подключения к шлюзу удаленного взаимодействия с флэш-памятью (AMF). Я полагаю, он может делать то, что вам нужно для получения аудиопотока от клиента с поддержкой .NET.

Получение кадров, частоты кадров и других атрибутов видеоклипа Если у вас есть опыт написания приложений в Microsoft DirectShow Editing Services (кодовое название Dexter), то эта фраза покажется вам очень знакомой. В среде Windows традиционно захват неподвижных кадров осуществлялся с помощью C++ и библиотеки типов Dexter для доступа к COM-объектам DirectShow. Чтобы сделать это в .NET Framework, вы можете создать Interop-сборку DexterLib, которая находится в списке COM References в VS 2005. Однако вам придется проделать немалую работу, чтобы понять, как преобразовать ваш код из C++ в C# .NET. Проблема возникает, когда вам нужно передать ссылку на указатель в качестве аргумента в родную функцию, CLR не поддерживает указатели напрямую, поскольку положение в памяти может меняться после каждого цикла сборки мусора. Вы можете найти много статей о том, как использовать DirectShow на CodeProject или в других местах, а мы стараемся не усложнять. Здесь наша цель - преобразовать видеофайл в массив растровых изображений, и я постарался сделать это как можно короче, конечно, вы можете написать свой собственный код для получения растровых изображений из живого потока и буферизации их незадолго до отправки.

В принципе, у нас есть два варианта использования DirectShow для преобразования нашего видеофайла в кадры в .NET:

Отредактируйте сборку Interop и измените ссылки на типы с указателей на типы C# .NET. Использовать указатели с ключевым словом unsafe. Мы выбрали метод unsafe (быстрое чтение). Это означает, что мы извлекаем наши фреймы за пределы управляемой области .NET. Важно отметить, что managed не всегда означает "лучше", а unsafe на самом деле не означает "небезопасно"!

MediaDetClass mediaClass = new MediaDetClass(); _AMMediaType mediaType; ... // загружаем видеофайл int outputStreams = mediaClass.OutputStreams; outFrameRate=0.0; for (int i = 0; i < outputStreams; i++) { mediaClass.CurrentStream = i; try{ //Если он может получить частоту кадров, этого достаточно, //мы принимаем видеофайл, иначе здесь возникает исключение outFrameRate = mediaClass.FrameRate; ....... //получаем атрибуты здесь .....

 }catch 
{ // Not a valid meddia type? go to the next outputstream } 

} // Нет частоты кадров? if (outFrameRate==0.0) throw new NotSupportedException( " Программа не может" + " прочитать видеофайл."); // У нас есть частота кадров? Идем дальше... ... //Создайте массив для хранения растровых изображений и интилизируйте... //другие объекты для хранения информации...

unsafe { ... // создаем байтовый указатель для хранения BitmapBits
... while (currentStreamPos < endPosition) { mediaClass.GetBitmapBits(currentStreamPos, ref bufferSize, ref *ptrRefFramesBuffer, outClipSize.Width, outClipSize.Height); ...
//добавляем битмап кадра к массиву frameArray ... } } ...

Передача извлеченных данных по HTTP Итак, мы преобразовали наше видео в массив растровых кадров. Следующим шагом будет передача наших кадров по HTTP до самого браузера клиента. Было бы хорошо, если бы мы могли просто отправить наши биты Bitmap клиенту, но это невозможно. HTTP предназначен для передачи текстовых символов, что означает, что ваш браузер читает только те символы, которые определены в наборе символов HTML-страницы. Все остальное вне этой кодировки не может быть отображено напрямую.

Чтобы выполнить этот шаг, мы используем кодировку Base64 для преобразования нашего Bitmap в символы ASCII. Традиционно кодировка Base64 используется для встраивания объектов в электронные письма. Почти все современные браузеры, включая браузеры Gecko, Opera, Safari и KDE (не IE!) поддерживают данные: URI для отображения изображений в кодировке Base64. Отлично! Теперь у нас есть наши фреймы, готовые к передаче по HTTP.

System.IO.MemoryStream memory = new System.IO.MemoryStream(); while (currentStreamPos < endPosition) { ... // Сохраняем битмапы где-нибудь в (управляемой) памяти vdeoBitmaps.Save(memory, System.Drawing.Imaging.ImageFormat.Jpeg); //Конвертируем в Base64 strFrameArray[frameCount] = System.Convert.ToBase64String(memory.ToArray()); //Подготовьтесь к следующему memory.Seek(0, System.IO.SeekOrigin.Begin); } memory.Close(); ...

Но мы не можем просто отправить закодированные кадры в виде огромной строки. Мы создаем XML-документ, содержащий наши кадры и другую информацию о видео, а затем отправляем его клиенту. Таким образом, браузер может получить наши кадры как объект DOM XML и легко перемещаться по ним. Только представьте, как легко редактировать видео, которое хранится в формате XML:

14.9850224700412 {Ширина=160, Высота=120} 6.4731334 /9j/4AAQSkZJRgABAQEAYAB.... ....

Этот формат также имеет свои недостатки. Видео, которое конвертируется в Base64 кодированные XML файлы, где-то от 10% (в основном AVI файлы) до 300 % или более (некоторые WMV файлы) больше, чем их двоичный эквивалент.

Если вы используете XML-файл, вам даже не нужен веб-сервер, вы можете открыть HTML из локальной директории, и он должен работать! Я включил в файл загрузки статьи исполняемый файл, который может преобразовать ваш видеофайл в XML-документ, который впоследствии может быть показан в браузере. Однако использование больших файлов и видео высокого разрешения - не самая лучшая идея!

Хорошо, теперь мы можем отправить наш �Base64 кодированный видео� XML документ, как мы бы сделали это с любым другим типом XML файлов. Кто сказал, что XML-файлы всегда должны быть скучными наборами записей