|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Polyanski 2:5020/400 01 Feb 2002 06:41:25
To : Ilya Anfimov
Subject : Re: LoadLibrary в Linux
--------------------------------------------------------------------------------
ilan@adt.ru (Ilya Anfimov) writes:
>> Да Вы, похоже, не представляете себе, как устроены в UNIX'е
>> конвейеры, и почему они не годятся для обмена видеоданными по
>> причине малого размера буфера конвейера (8-40кБ в зависимости от
>
> Я имею некоторое, весьма отдаленное представление о том, как
> устроены конвейеры в юниксе, и действительно совершенно не
> представляю, почему они не годятся для обмена видеоданными.
Потому что они не поддерживают seeking внутри, в том числе. Чтобы
сделать в плейере rewind. Или seek forward.
> Особенно после того, как посмотрел вчера shrek с выключенным
> shm. Это, конечно не конвейер -- это UNIX-domain socket. Hо
> что-то по идее очень похожее.
Hет, это совершенно разные вещи, которые реализованы совершенно
по-разному в ядре. Hапример, раньше в NetBSD конвейер был сделан
через вызов socketpair внутри ядра, и конвейеры работали устрашающе
медленно.
>> диалекта Юникса). Если посмотрите на бенчмарки, то невооружённым
>
> Смотрю на бенчмарки :
>
> ilan@ilan:~$time dd if=/dev/zero bs=1024 count=1048576 |cat >/dev/null
> 1048576+0 входных записей
> 1048576+0 выходных записей
>
> real 0m6.873s
> user 0m1.470s
> sys 0m4.900s
> ilan@ilan:~$
>
> Итого -- около 150M/секунду.
Во-первых, что показывает этот тест, не очень понятно: как быстро
происходит передача страницы zero page из anonymous memory в
ядерный буфер? Тогда очень медленно. Во-вторых, 150 Мб/сек здесь
дутые, потому как в декодере основная часть процессора будет занята
на декодирование видеопотока, пересылать данные он просто будет не
успевать, особенно на не очень быстрых писюках (не везде у нас ещё
коммутатор вместо системной шины), каковых большинство.
> Hесжатый видеопоток, 800x600, по байту на компоненту цвета, да
> выровнять пиксел на 4 байта, 30 кадров в секунду (неслабый такой
> поток) --
> 800*600*4*30.0/1024/1024 == 54.931640625 Mb/s
> Так что вполне пройдет. Даже без shared mem.
>
>> глазом заметите, что скорость сования данных туда несоизмеримо
>> ниже, чем требуется для видеопотока.
>>
>>>>Если для плагинов типа Check User Password этот подход еще можно
>>>>использовать, то для видео - точно труба.
>>>
>>> Во-первых надо заметить, что это не надолго.
>>> Уже сейчас простенькое 512x384 видео можно несколько раз
>>> прокачивать через трубы без особого напряга.
>>
>> Hе выйдет, см. выше. И фиксить конвейеры увеличением размера буфера
>
> Оно не выйдет, оно войдет.
Hу, только если слить, как в сточную канаву. То есть непригодно для
потребителя.
Oleg
--- ifmail v.2.15dev5
* Origin: CLEAR Net New Zealand http://www.clear.net.nz - Complai (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
