Александр Ме

VDS-сервера

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

Опишу только принцип, реализацию уже сделаете сами, либо попросите AI.

Кнопка "назад" работает просто: переводит браузер на предыдущий урл.

Это можно использовать. Вы же, наверняка, используете history API в вашем приложении.
Так вот, при открытии модального окна добавляйте хэш к адресу в history.

https://example.com/page // окна нет
https://example.com/page#modal1 // окно открыто

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

Ваша программа должна добавлять к текущему адресу хэш при открытии окна, и закрывать окно, когда хэш из адреса убирается.

дергай телеграм бота, простой http запрос

Проблема не в HEVC, а в HDR.
Конвертируйте цветовое пространство из rec2020 в rec709. Например:

ffmpeg -hide_banner -y -i .\costa_rica_4k_60fps_hdr_uhd.webm -vf "zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,format=yuv420p" -c:v libx264 .\costa_rica_4k_60fps_sdr_uhd-10s.libx264.mp4

https://www.binarytides.com/convert-hdr-video-to-s...

По софту с GUI не подскажу, но такое умеют многие. Handbrake, например. Ищите по colorspace, rec2020, rec709

UP: а, да. Возможно оно вам не надо. Есть плееры, которые производят конвертацию на лету. Например mpv.

решил вопрос если кому надо базу надо закидывать сюда
${FileSystem.documentDirectory}SQLite/base.db
я закидывал без SQLite

А если подумать?
Что должен выдать document.querySelector('https://vk.com/krosrs')?
Правильно, ошибку. Что и выдаёт.

что делать?

Для начала определиться, а что именно вы хотите получить этим кодом и зачем делать ссылку, а потом запрещать переход по ней.

/**
 * @link MyClass::myMethod
 */

class MyClass
{
    static public function myMethod()

Попробуем отделить коней от людей, насколько это получится.
Говоря просто: API - для отдачи непосредственного среза данных, обычно в виде JSON, WEB - для отдачи целых страниц в виде HTML.

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

Ну, неправильно думали, ничего страшного. Точнее, очень узко. Вот есть у вас сайт, а потом вы решили сделать к нему в пару мобильное приложение. Оно стороннее? Ничего сделать с отданным через WEB HTML оно не сможет*, потребуется API.
Наличие или отсутствие авторизации тут совершенно ни при чём.

в тоже время используя api.php любой человек может запросить любой роут и получить кучу информации

Любой человек получит то, что вы ему отдадите. Никакого запрета (или сложностей) на внедрение авторизации в API нет.

Количество Middleware на web.php значительно больше, т.е. любой запрос проходит больше проверок перед тем как выдать результат.

Middleware - это любые обработчики, а не только проверки. Т.е. "больше обработчиков не значит больше проверок". Любые обработчики вы можете навесить и на API**. И их даже не надо писать отдельно, в Laravel уже всё есть.

В итоге вопрос, с точки зрения безопасности, производительности есть преимущества api.php перед web.php

С точки зрения безопасности разницы нет. API может быть несколько производительнее за счёт того, что обрабатывает и отдаёт меньше "лишнего". Но по этим аспектам их вообще не надо сравнивать, это всё равно, что выбирать между экскаватором и самосвалом по степени лёгкости угона того или другого.

* без костылей
** с поправкой на отсутствие сессии обычно

ffmpeg -i входной_файл.ts -map 0 -c copy выходной_файл.mp4

Если в исходном файле есть потоки, которые нельзя записать в формат MP4 (например, субтитры в формате, неподдерживаемом MP4), ffmpeg может выдать ошибку.

Первому файлу нужно сжать 402240 точек на кадр, 20 fps, получаем в секунду 8 млн точек. Видим сжатие 817 kb/sec
Второму файлу нужно сжать 921600 точек на кадр, 60 fps, получаем в секунду 55.3 млн точек. Видим 2526 kb/sec

Сравниваем 55.3 / 8 и 2526 / 817 = 6.9125 и 3.0917992656058751529987760097919

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

По поводу размера файлов, еще обращу внимание что 128 и 104 kb/s для звука - значимо влияет на размер файла. Звук вообще может занимать четверть а то и треть, ибо сжимается хуже, чем видео.

Ну собственно и все. Тут оба видео сжаты одним и тем же кодеком, и сложно предположить, что можно как-то заметно качественнее пережать, дефолтные настройки в современных кодеках обычно fits many, и какие-то кастомные настройки обычно влияют не столько на размер, сколько на адаптацию сжатия к контенту видео.

получить более высокий фпс из кадров которых не существует?? Ну не знаю, можно просто продублировать кадры. Можно в ffmpeg попросить создать промежуточные кадры, но оно может заметно исказить оригинал, и для художественного кино это может оказаться нежелательным эффектом.

В общем тут нет некачественного сжатия. Надо сравнивать контент (наличие статических частей экрана, количество цветовой гаммы и так далее).