[mantech 35]

3 часа назад, repstosw сказал:

Предлагаю рассматривать нижний уровень - запись блоками кратных 512.

Не получить быстрой записи с такими вводными, ну не рассчитаны сд карты на сектора 512 байт, это не старые жесткие диски. Нужно брать минимум - 4096 байт, а лучше еще в 2 раза больше. Проверено не раз.

21 минуту назад, repstosw сказал:

А вообще, есть способ определить максимальный размер блока под сжатый фрейм у h264? 

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

48 минут назад, repstosw сказал:

чтение файла блоками по 128 кБ занимает 26 мс.  Это выходит 4,8 МБ в секунду.

Так все-таки чтение нужно или запись?  Для чтения это нормальная скорость, больше только перевод в режим UHS на 1.8В. Там можно получить до 16Мб\сек с 10го класса, хотя класс - это для записи, говорит о том, что сырой поток можно писать макс 10 мбайт\сек.

[aaarrr 63]

40 minutes ago, mantech said:

Для чтения это нормальная скорость

Нет

[mantech 35]

17 минут назад, aaarrr сказал:

Нет

Обоснуйте пожалуйста?

[repstosw 18]

1 hour ago, mantech said:

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

Чтение идет блоком по 64 кБ. Фрейм всегда меньше, чем это значение.  А теперь вопрос - сколько ещё нужно начитать для следующего фрейма, чтобы свести к нулю риск того что фрейм будет считан не полностью?

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

 

Типовые значения размеров фреймов в h264:   27546, 13545, 3589, 17341, 8324, ....    причём размер следующего фрейма неизвестен.  И как тут складывать в ОЗУ  ? ))))

Изменено 7 августа, 2022 пользователем repstosw

[aaarrr 63]

18 minutes ago, repstosw said:

И как тут складывать в ОЗУ  ? ))))

Блоками по 256K, например.

 

46 minutes ago, mantech said:

Обоснуйте пожалуйста?

Уже очень давно скорость чтения близка к скорости интерфейса. В данном случае она вдвое ниже.

[mantech 35]

1 час назад, aaarrr сказал:

Уже очень давно скорость чтения близка к скорости интерфейса.

А вы в курсе, что имелась ввиду скорость чтения файлов в ФАТ32 ? Я к тому, что скорость интерфейса на 25МГц клоке - примерно 11 мбайт сек, НО, прочитать данные - это нужно сделать запрос, подождать на время подготовки блока, потом его прочитать, и это только "сырое" чтение, которое уже не будет с такой скоростью, затем накладные расходы ФАТ, и только тогда получаем реальную скорость. То что вы озвучиваете, это возможно только в случае отправляем команду с адресом и потом только читаем и все, читаем линейно мегабайтами... Как это будет сочетаться с работой ФС - для меня загадка...

2 часа назад, repstosw сказал:

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

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

2 часа назад, repstosw сказал:

начит можно упростить кеширование

Для чтения кэширование не нужно, разве, что только для списков ФАТ.

Изменено 7 августа, 2022 пользователем mantech

[aaarrr 63]

3 minutes ago, mantech said:

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

Если файл не фрагментирован безнадежно (а с чего бы вдруг?), то примерно так и происходит.

[mantech 35]

1 час назад, aaarrr сказал:

Если файл не фрагментирован безнадежно (а с чего бы вдруг?), то примерно так и происходит.

Честно говоря не знаю, что там происходит, но сколько бы не тестировал картридеров не поддерживающих режим 1.8В скорость чтения на ПК всегда была в районе 5МБайт сек. У тех, кто поддерживал было около 15-16 в сек. На ПК стояла "семерка" порт усб 2.0.

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

[aaarrr 63]

Современные карты показывают в районе 90МБайт/с при чтении.

[mantech 35]

2 часа назад, aaarrr сказал:

Современные карты показывают в районе 90МБайт/с при чтении.

На картридере с усб 2.0 ?))))))))))))

Изменено 7 августа, 2022 пользователем mantech

[repstosw 18]

7 hours ago, aaarrr said:

Блоками по 256K, например.

И проиграть в скорости, местами получив просадку FPS воспроизводимого видео...

 

Удалось решить проблему с помощью "рационального чтения" данных с SD-карты.

Ранее алгоритм был такой:

1. Читаем блок 64 кБ   (13 мс)
2. Определяем размер текущего h264-фрейма
3. Декодируем фрейм (1..2 мс)
4. Корректируем указатель файла на следующий фрейм
5. Переходим на 1.

При таком подходе происходят две не очень хорошие вещи:

1. Мы постоянно перечитываем часть данных (здесь бы выручило кеширование, о котором писал aaarrr)

2. Постоянно читается блок 64 кБ с задержкой 13 мс (это пока ещё приемлемо на 30 FPS видео 720x576, но на бОльших могут быть проблемы из-за бОльшего времени чтения)

 

Новый алгоритм:

1. В первый раз читаем блок 64 кБ (13 мс)
2. Определяем размер текущего h264-фрейма
3. Декодируем фрейм (1..2 мс)
4. Перемещаем оставшиеся данные (которые за пределами текущего фрейма) в начало буфера (memmove)
5. Фиксируем новые смещение и размер, которые нужно дочитать из файла в буфер (position=64K-current_frame_size, size=current_frame_size)
6. Переходим на 1, лишь только с той разницей, что читаем уже не блок 64 кБ, а size в буфер со смещением. (<< 13 мс)

Проверил: результаты превзошли ожидание! Первое чтение занимает больше всего времени, остальные - время существенно сократилось. Проще говоря - мы всегда дочитываем из файла ровно столько, чтобы новых данных было всегда 64 кБ. При таком подходе читаются всегда новые данные и кеширование здесь НЕ нужно.

 

Замеры времени на чтение фреймов h264 и их размер (некоторые фреймы служебные) - здесь время больше, так как древняя SD-карта без класса скорости вообще, на 2 ГБ.

Здесь первое чтение самое затратное по времени, так как 64 кБ.

17.007000 ms, 58.799316 FPS, 65536 bytes
1.442167 ms, 693.401123 FPS, 32 bytes
6.985167 ms, 143.160507 FPS, 19650 bytes
4.491500 ms, 222.642776 FPS, 6232 bytes
3.901833 ms, 256.289764 FPS, 2706 bytes
2.517833 ms, 397.166870 FPS, 627 bytes
3.836833 ms, 260.631592 FPS, 3520 bytes
1.284667 ms, 778.412048 FPS, 315 bytes
4.228500 ms, 236.490479 FPS, 4062 bytes
4.228500 ms, 236.490479 FPS, 4062 bytes
1.239667 ms, 806.668457 FPS, 372 bytes
1.238833 ms, 807.211060 FPS, 506 bytes
4.734334 ms, 211.222977 FPS, 8308 bytes
1.260500 ms, 793.335999 FPS, 735 bytes
4.621666 ms, 216.372162 FPS, 7464 bytes
10.734000 ms, 93.161919 FPS, 29959 bytes
11.059667 ms, 90.418640 FPS, 32597 bytes
9.231333 ms, 108.326714 FPS, 19985 bytes
4.425333 ms, 225.971680 FPS, 5400 bytes
4.255667 ms, 234.980804 FPS, 4107 bytes
4.711500 ms, 212.246628 FPS, 7100 bytes
6.702667 ms, 149.194351 FPS, 6901 bytes
4.167833 ms, 239.932816 FPS, 4237 bytes
4.445333 ms, 224.955002 FPS, 4419 bytes
4.505833 ms, 221.934525 FPS, 6604 bytes
4.826500 ms, 207.189468 FPS, 8323 bytes
4.159833 ms, 240.394241 FPS, 4537 bytes
6.213833 ms, 160.931259 FPS, 5156 bytes
4.345500 ms, 230.123123 FPS, 6297 bytes
4.110500 ms, 243.279404 FPS, 4186 bytes
0.002667 ms, 375000.000000 FPS, 32 bytes
6.218500 ms, 160.810486 FPS, 16423 bytes
6.284000 ms, 159.134308 FPS, 6180 bytes
3.491667 ms, 286.396179 FPS, 1532 bytes
2.755833 ms, 362.866638 FPS, 1265 bytes
5.427667 ms, 184.241226 FPS, 11395 bytes
5.255167 ms, 190.288925 FPS, 12024 bytes
6.583000 ms, 151.906433 FPS, 8573 bytes
3.320000 ms, 301.204834 FPS, 1912 bytes
3.460167 ms, 289.003418 FPS, 1469 bytes

 

4 hours ago, aaarrr said:

Современные карты показывают в районе 90МБайт/с при чтении.

И как их получить на карте с классом скорости 10 (UHS-I) при напряжении питании 3,3V, используя 4 бита линии данных ?

Изменено 7 августа, 2022 пользователем repstosw

[SII 0]

Если правильно понял уже сделанное, то можно ещё больше ускорить путём использования двух буферов по 64 К:

1) Читаем первые 64 К в первый буфер.

2) Определяем размер.

3) Запускаем две параллельные операции: пересылку из первого буфера во второй "лишней" части с помощью контроллера DMA (передача "память-память", без всяких там memmove) и одновременно чтение во второй же буфер очередной порции данных (сколько там не хватает, чтоб получились полные 64 К) -- опять же, с передачей по DMA.

4) Пока контроллеры DMA и SD усердно выполняют п. 3, декодируем первый буфер и выполняем всё прочее, что там нужно.

5) Дожидаемся завершения пересылки и считывания, инициированных в п. 3.

6) Переходим на п. 2, но уже со вторым буфером.

[repstosw 18]

3 hours ago, SII said:

4) Пока контроллеры DMA и SD усердно выполняют п. 3, декодируем первый буфер и выполняем всё прочее, что там нужно.

Предложенный вами конвеер хорош.

Но есть одно "НО" :  файловая система и SDcard-DMA  - вещи несовместимые.

[aaarrr 63]

8 hours ago, mantech said:

На картридере с усб 2.0 ?))))))))))))

На нативном контроллере или картридере с USB SS. Думаю, понятно, что и на HS будет не 15МБайт/с совсем.

 

6 hours ago, repstosw said:

И проиграть в скорости, местами получив просадку FPS воспроизводимого видео...

Я как-то не учел, что многозадачность недоступна. Тогда остаются только костыли.

[mantech 35]

8 часов назад, repstosw сказал:

Постоянно читается блок 64 кБ с задержкой 13 мс (это пока ещё приемлемо на 30 FPS видео 720x576, но на бОльших могут быть проблемы из-за бОльшего времени чтения)

Т.е. кольцевой буфер не хотите использовать принципиально, хотя он почти во всех плеерах используется? Ваше право))

В смысле "пока"? Какой у вас битрейт на входе декодера?  Учитывая степень сжатия и разрешение, должно быть порядка 200кбайт\сек. При скорости чтения с сд карты в 4-5Мбайт\сек должен быть огромный запас, ИМХО...

1 час назад, aaarrr сказал:

Я как-то не учел, что многозадачность недоступна.

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

Изменено 8 августа, 2022 пользователем mantech