Обычно h264 упакован в контейнер, например mp4, и в этом контейнере (в блоке moov или moof) указывается pts (presentation time) каждого кадра, то есть порядок их показа. Допустим, moov куда-то потерялся, но остался блок mdat, в нём сырой h264. В нём есть информация о порядке кадров или никак нет?

Когда я сконвертировал mp4 в annexb (тоже можно считать без контейнера) - mpv получившийся файл успешно показывал, и вроде даже нормально выглядело. Хотя, допускаю, что кадры там показывались в порядке кодирования, а я просто не заметил разницы от мелких перестановок.

Узнал сегодня о релизе gdk-pixbuf 2.43.2. В зависимости(пока опционально) добавлен новый пакет — glycin, а с ним bubblewrap и gtk4.

Релиз-нот:

2.43.2 (development)
===

- Make the thumbnailer optional
- Add a glycin loader. Glycin is a sandboxed image loading framework that
  is written in rust, and supports more image formats than gdk-pixbuf ever
  did. On Linux, we recommend that you build gdk-pixbuf with *only* the
  glycin loaders, and rely on glycin for thumbnailers too. Like this:

  meson configure -Dpng=disabled                \
                  -Dtiff=disabled               \
                  -Djpeg=disabled               \
                  -Dgif=disabled                \
                  -Dothers=disabled             \
                  -Dglycin=enabled              \
                  -Dbuiltin_loaders='glycin'    \
                  -Dthumbnailer=disabled

  Note that this change has some potential for fallout: use of gdk-pixbuf
  (e.g. for pixdata conversions) will fail if bubblewrap sandboxing is not
  available (as is the case in many build systems). The recommendation is
  to simply stop using pixdata as a format for resources, and just use png.
- Deprecate "gtk_doc" configuration option; to conform with the rest of the
  GNOME core libraries, use "documentation" instead
- Remove the long-since deprecated "docs" configuration option
- Require Meson 1.0 to build gdk-pixbuf
- Deprecate the XPM-related API; the XPM loader is disabled by default,
  and we have better API for loading those kinds of assets, though nobody
  should be shipping XPM files in 2025

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

Очевидно:

• Зачем в зависимостях программы альтернативная реализация ее собственного функционала?
• Кодеки heif, jxl тяжёлые, требовательные к вычислительным ресурсам, имеют собственную реализацию pixbuf-loaders. Сомнительно, что вариант от гном сильно лучше.

Приветствую. Собсна, посоветуйте игрулю в стиле старого-доброго ультранасилия старой-доброй Дяблы 1-2.

Эта статья является продолжением предыдущей публикации, в которой описывается разработка сетевой библиотеки на C++20. В данном продолжении акцент сделан на более детальном описании разработки алгоритма Raft и его интеграции с сетевой библиотекой.

( читать дальше... )

Введение

С годами работы в области распределённых систем, я понял, что мой опыт не будет полным без реализации алгоритма Raft. Это осознание побудило меня к действию: я решил создать свою реализацию, используя асинхронные возможности C++20.

( читать дальше... )

МТС (MTS): *916*9хх1234567#
Билайн (Beeline): *444*9хх1234567#
МегаФоне: *629*9хх1234567#

Оставьте в закладках.

<fat>Добрый вечер, эта ваша убунта чуть мне ноут не сожгла.</fat>

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

После того как я его вырубил, ноут остыл и ожил.

ноут - ThinkPad x220

Вопрос: Какие есть тесты дабы посмотреть состояние подпаленного, да и вообще, что может подгореть? На первый взгляд все работает нормально