Полигон призраков

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

esasoft, я тоже сравнивал вывод mediainfo, но не думаю что дело именно в битрейде видео (сам то декодер и до 1080 кушает видосики), не думаю что от условно двухкратного повышения он захлебнулся бы в 480р.
ну а если да, то тут вопрос как заставить yt-dlp на лету перекодировать поток чтобы проверить

upd: прихожу к выводу что декодер похоже действительно захлебывается высоким битрейдом с ютуба. если так то железка станет еще бесполезнее конечно, хотя казалось бы.

pioner666, там ещё разница во фреймрейте. Мизерная, но всё же. Возможно, ровно 30 fps оно не умеет нормально, а 29.97 - норм. Всё-таки, это же не программный плейер, которому пофиг, а аппаратный декодер. Там вполне могут быть такие приколы. На такую мысль меня наводит то, что Вы говорили, что глючить начинает не сразу, а спустя какое-то время. Возможно, накапливается ошибка из-за разницы во фреймрейте и происходит сбой. Это, конечно, чисто мои домыслы, но я бы проверил и это тоже.
Попробуйте перекодировать какое-нибудь современное видео в 29.97, и проверить.

pioner666 писал(а): 25.12.2024,23:25 ну а если да, то тут вопрос как заставить yt-dlp на лету перекодировать поток чтобы проверить

Пересобрать файл не проблема, мышкой в mkvmerge gui (на выходе будет .mkv) или в консольке через ffmpeg Поменять FPS сложнее, он зашит в сам видеопоток если речь о h264 формате

esasoft, решил проверить вашу теорию и поскольку декодер должен поддерживать 60fps видео то выбрал свеженькое видео и скачал его в 720 и 1080 - и самое смешное оно взяло и заработало спокойно - вот данные файлов: думаю ну вот и решение - не хочет кушать в 30fps буду скармливать в 60 для проверки скачиваю то видео которое не работало у меня в 30 кадров в том же виде 720/1080 на 60 и очень удивляюсь когда оно ровно так же запинается как и вариант который я выкладывал: причем параметры работающего видео даже слегка выше по битрейду, частота у обоих фиксирована. я прям не знаю что за фигня. без декодера чисто на проце работает. на интеловских встройках которые умеют декодировать h264 - декодирует. у меня что то варианты заканчиваются.

Mov AX, 0xDEAD писал(а): 26.12.2024,12:52 Пересобрать файл не проблема

тут конечно интересно именно было бы заставить сам yt-dlp перекодировать (хотя системы с декодером у меня это атомы, на которых это сомнительная забава), но пока непонятно что конкретно не нравиться декодеру

pioner666, из отличий - только это:
У работающего 1080p - Bits/(Pixel*Frame) : 0.034
У не работающего 1080p - Bits/(Pixel*Frame) : 0.024

Плюс, у работающего 1080p:
Writing library : x264 core 155 r2901 7d0ff22

У не работающего 1080p эта запись опять отсутствует.

pioner666 писал(а): 27.12.2024,02:56 и самое смешное оно взяло и заработало спокойно - вот данные файлов:

При кодировании видео, помимо битрейта и частоты кадров, задается множество параметров.
Например для наглядности:
cabac=1 / ref=12 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=32 / lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=0 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=2pass / mbtree=0 / bitrate=1800 / ratetol=1.0 / qcomp=0.70 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

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

esasoft писал(а): 27.12.2024,11:46 У работающего 1080p - Bits/(Pixel*Frame) : 0.034
У не работающего 1080p - Bits/(Pixel*Frame) : 0.024

не думаю что тут это играет роль. а вот библиотека кодирования, может быть в теории.

Takedasun писал(а): 27.12.2024,19:49 При кодировании видео, помимо битрейта и частоты кадров, задается множество параметров.

а как то эти параметры можно вывести для двух разных видео чтобы сравнить? а то стандартный вывод mediainfo из k-lite не дает всей перечисленной вами информации.
да разработчики давно положили на эту железку, и вообще она имеет очень нишевое применение. но для систем где встройка не может декодировать h264 и есть свободный порт minipci-e она хороша - кушает намного меньше энергии чем декодирование на процессоре, да и не все на том же атоме можно декодировать

pioner666 писал(а): 27.12.2024,22:51 При кодировании видео, помимо битрейта и частоты кадров, задается множество параметров

Бывает и в разы больше.
Достаточно посмотреть документацию к ffmpeg, чтобы офигеть от количества параметров и настроек.
Но не думаю, что Youtube сильно заморачивается над кодированием каждого видео разными параметрами, скорее всего, там более-менее одинаково. С годами, конечно, меняется кодирование, но в определённом промежутке времени кодируется определённым набором кодеков со стандартными параметрами.

небольшие новости касательно использования этого декодера. все таки vlc может его использовать, но только в 64 битной версии и только до 2.2.8 включительно
перебрал все libcrystalhd_plugin.dll - только в районе версии 2.2 работали.
к сожалению это не касается 32 битных версий - аналогично перебрал все варианты этой библиотеки, но или она полностью не используется или же плеер падает при попытке взаимодействия с декодером. это странно ведь версия драйвера от декодера ровно одна и та же и на 64 битной семерке и на 32 битной хп. похоже мечты заставить декодировать ютуб на хп через vlc прямо в mypal останутся только мечтами
на всякий случай добавлю лог при падении плеера

Декодер Crystal HD может использовать Potplayer, только надо в настройках добавить его поддержку.