Прямой эфир

0
Зачем ты по прежнему наследуешься от TMemoryStream и загружаешь файл целиком? Наследуйся от TObject и включи поле FData: TStream, значение для которого передается в конструктор (ну или TFileStream, создающийся в конструкторе).
Во-первых, грузить мало-мальски большой файл — долго. Во-вторых, жрет много памяти. И в-третьих — в 32-битных программах теоретический лимит на выделение памяти 2ГБ, а практический — около 1.6ГБ, на более крупном файле будет ошибка.

Как ни странно, встроенных функций конвертирования эндианности у дельфи нет. Только легаси-функция Swap, работающая с 16-битными значениями. Своим функции можно сделать двумя методами.
1) Воспользоваться ассемблерными инструкциями.
function SwapEndian32(Value: integer): integer; register;
asm
  bswap eax
end;

function SwapEndian16(Value: smallint): smallint; register;
asm
  rol   ax, 8
end;

2) Воспользоваться классическим методом:
X := ((X and $ffffffff00000000) shr 32) or ((X and $00000000ffffffff) shl 32);
X := ((X and $ffff0000ffff0000) shr 16) or ((X and $0000ffff0000ffff) shl 16);
X := ((X and $ff00ff00ff00ff00) shr 8) or ((X and $00ff00ff00ff00ff) shl 8);
  • avatar
  • Vga
  • 02 ноября 2019, 14:33
0
можно и производство наладить
Не вижу в этом смысла. Держу его пока как осциллографический пробник. Так как проводить какие либо измерения на нем несколько сложно, можно определить амплитуду сигнала и увидеть его форму, скважность, частоту вычислять никогда не пробовал так как это вызывает трудности из за диапазона ступеней развертки. А что вы хотите, это школьный осциллограф. Для тех кто делает только первые шаги он может устраивать вполне, но по мере роста потребуется более точный прибор.
Другое дело, переделать его. Взять за основу схему от С1-94 или С1-151, но выполнить уже на современной элементной базе. Места в нем по объему не так уж и много, хотя полагаю его должно хватить.
0
Тестовый лог обновленного кода парсингом файла, на котором обломился в прошлый раз:

  --- атомы верхнего уровня ----------------
  Name-ftyp, Atom-70797466, Size-18
  Name-free, Atom-65657266, Size-7E7C
  Name-mdat, Atom-7461646D, Size-2A67CF7
  Name-uuid, Atom-64697575, Size-1147
  Name-moov, Atom-766F6F6D, Size-7E9B
  --- атомы уровня 1 -----------------------
  Name-mvhd, Atom-6468766D, Size-6C
  Name-trak, Atom-6B617274, Size-4700
  --- атомы уровня 2 -----------------------
  Name-tkhd, Atom-64686B74, Size-5C
  --- поиск окончен ------------------------
  Result, Width-1280, Height-720
  ------------------------------------------
  • avatar
  • anakost
  • 02 ноября 2019, 08:56
0
Всегда приветствую конструктивную крититику, не дает закостенеть, спасибо VGA. Переработал первоначально представленный код с учетом выявленных ошибок и критики. Не стал вносить поправки в уже опубликованный код, продолжил статью второй частью.
  • avatar
  • anakost
  • 02 ноября 2019, 08:33
0
Core power consumption is only 1/3 of that of traditional Cortex-M3
Интересно это правда?
Очень странно что GD32VF103CBT6 никто не продает отдельно от плат на aliexpress
  • avatar
  • UR5SIX
  • 01 ноября 2019, 18:57
0
Ты даже элементарнейше реализуемую поддержку больших файлов не сделал.
Моя недоделка, мне просто повезло, и у всех используемых мной для тестирования MP4 атом «moov» оказывался перед атомом «mdat» (сами видео, аудио данные, субтитры если есть). Поэтому код находил разрешение и выходил, не заходя в «mdat».
Сегодня продолжил тестирование и на одном файле обломился, атом «mdat» оказался перед «moov». Лог файл:

  Name-ftyp, Atom-0x70797466, Size-0x18
  Name-free, Atom-0x65657266, Size-0x7E7C
  Name-mdat, Atom-0x7461646D, Size-0x1
  Name-dat , Atom-0x00746164, Size-0x16D
  Name-    , Atom-0x00030000, Size-0x3000003

Хорошо видно, что атом «mdat» имеет размер 1 байт, хотя минимальный размер пустого атома 8 байт. Из-за этого считывание сдвинулось на 1 байт, следующий атом стал называться «dat», а «m» сдвинулась в размер (0x6D). Ну и код полез черти-куда и ничего естественно не нашел.
Как лечить описано в описании "QuickTime container". Цитата:
The 4 bytes allotted for the atom size field limit the maximum size of an atom to 4 GB. Quicktime also has a provision to allow atoms with 64-bit atom size fields by setting the size field 1 and adding the 8-byte size field after the atom type:

bytes 0-3 always 0x00000001
bytes 4-7 atom type
bytes 8-15 atom size (including 16-byte size and type preamble)
bytes 16..n data
This is a logical exception since an atom always needs to be at least 8 bytes in length to account for the preamble. Therefore, if the size field is 1, load the 64-bit atom size from just after the atom type field.

If, on the other hand, the size field is 0, then the atom extends to the end of the file.
Т.е. если в поле размера атома стоит единица, значит 8-байтное поле размера будет следовать за заголовком. Если в поле размера атома стоит ноль, атом продолжается до конца файла.
Ничего этого я не учел, доделаю и выложу попозже.
  • avatar
  • anakost
  • 01 ноября 2019, 18:35
0
Я еще не понял, как определить тип трека и надо ли. Лишняя проверка.
Проверка лишняя только тогда, когда не дает решить решаемую без нее задачу. Проверка на лицензию, например.
Тип трека, впрочем, надо искать в других атомах и эти поля в атоме tkhd действительно могут содержать только разрешение. Но судя по флагам — там может быть разрешение превью-картинки, например.
Возможно так, но геморойно.
Зато работает не только в самых простых случаях. Ты даже элементарнейше реализуемую поддержку больших файлов не сделал. А еще бывают сжатые метаданные, когда в moov единственный атом cmov. Да и парсить вывод не особо геморройно, а вот таскать с собой 100-метровый ффмпег может быть не очень приятно. Лучше посмотреть на библиотеки медиаинфо.
  • avatar
  • Vga
  • 01 ноября 2019, 16:19
0
Схему нарисовали, детали поменяли, можно и производство наладить.
  • avatar
  • gadz
  • 01 ноября 2019, 08:21
0
Вообще-то, не мешало бы сперва выяснить какой вообще трек открыли, посмотрев на его тип.
Я еще не понял, как определить тип трека и надо ли. Лишняя проверка.
Вместо 5 вызовов ReadBuffer можно было 1 раз считать структуру и затем перевернуть в ней слово встроенной функцией, разворачивающейся в одну ассемблерную команду.
Можно, до оптимизаций пока не добрался.
Так что ffmpeg даст более надежные сведения.
Возможно так, но геморойно.
  • avatar
  • anakost
  • 01 ноября 2019, 04:24
0
LoadFromFile(aFileName);
Что-то мне подсказывает, что на запуск ffmpeg и полноценный парсинг им файла уйдет куда меньше времени, чем на загрузку мало-мальски приличного видеофайла в память целиком. Я уж не говорю о потреблении памяти.
Вместо абсолютно неуместного наследования от TMemoryStream следовало наследоваться от TObject и открывать файл через TFileStream. Это если тут вообще имеет смысл делать объект.
так понимаю, видео и аудио, причем один на месте разрешения содержит нули
Вообще-то, не мешало бы сперва выяснить какой вообще трек открыли, посмотрев на его тип.
// BigEndian -> LittleEndian
Вместо 5 вызовов ReadBuffer можно было 1 раз считать структуру и затем перевернуть в ней слово встроенной функцией, разворачивающейся в одну ассемблерную команду. Конечно, по сравнению с чтением всего файла это совершенно несущественная оптимизация, но она бы сделала код короче и понятнее.
Это же в полной мере относится к GetResolution, а вот FindAtom являет собой типичный пример названия, абсолютно не соответствующего выполняемой операции, что опять же усложняет понимание кода.
P.S. Этот код работает правильно со стандартом файлов MP4, у которых поле размера атома составляет двойное слово, а значит размер атома не может превышать 2Гб.
На самом деле он вылетит уже на файле размером примерно в 1.6ГБ, что в нынешних реалиях вызывает вопрос «а они вообще бывают такими мелкими?».

Кроме того, сведения в контейнере больше референсные и могут не соответствовать реальности. Иногда одни и те же данные записаны в десяти местах, противоречат друг другу или делают видео криво отображающимся в половине плееров. Так что ffmpeg даст более надежные сведения.
  • avatar
  • Vga
  • 31 октября 2019, 21:08
0
Спасибо.
  • avatar
  • hudoykl
  • 29 октября 2019, 14:15
0
Я не опечатался. Идея не использовать шаблоны, засветку УФ — только смывка после травления. То-есть, оставшийся фоторезист только как защита при травлении.
  • avatar
  • DVF
  • 22 октября 2019, 12:02
0
Увы, не смогу ответить насколько одинаковыми (по модулю, конечно) остаются напряжения.
В пределах 300мА (абсолютно) заметной разницы не видел, полагаясь на показания встроенного вольтметра.
Специальных исследований не проводил — пока не было надобности.

Кстати, о разбросе напряжений имеет смысл говорить, когда нагрузка минусового плеча значительно приближается к порогу ограничения. В остальном же отрицательное плечо просто повторяет с инверсией значение на выходе положительного плеча (см. схему).
  • avatar
  • Fahivec
  • 20 октября 2019, 11:17
0
А можно описание этого действа. Поскольку такой принтер имеется в наличии. Но я использовал его только по назначению.
  • avatar
  • skelet
  • 20 октября 2019, 08:02
0
Спасибо большое. Прям очень актуально.
  • avatar
  • skelet
  • 20 октября 2019, 07:49
0
Во, как раз я хотел почитать про одинаковость двухполярного напряжения при неравномерной нагрузке плеч))
0
Внешний вид готового устройства
  • avatar
  • Fahivec
  • 19 октября 2019, 23:49
0
Покорнейше извиняюсь, что с таким огромным опозданием!!!

Внутренности девайса с описываемым БП
  • avatar
  • Fahivec
  • 19 октября 2019, 23:46
0
Хммм. Ну, тем не менее, насколько я помню, когда я гуглил примененные динамики — обнаружил, что это высокочастотники, ну и на (мой) слух НЧ там сильно не хватает.
В принципе, по сравнению со всякими китайскими «диалогами» звучали они вполне нормально, это после перехода на что получше их слушать невозможно.
  • avatar
  • Vga
  • 11 октября 2019, 12:46
0
В области голосовых частот АЧХ вроде нормальная. Скорее всего наушники были созданы для военных целей, а бытовая версия — это побочный продукт.

  • avatar
  • Gum
  • 11 октября 2019, 12:24