Александр Ме

А если подумать?
Что должен выдать 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 попросить создать промежуточные кадры, но оно может заметно исказить оригинал, и для художественного кино это может оказаться нежелательным эффектом.

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

Зачем объявлять enum, если им не пользоваться?

- status: "published"
+ status: QuestionStatus.PUBLISHED

Как оказалось, Transmission вполне переваривает такие файлы

Ребят вы знаете, в чем проблема, и куда копать....

Нет конечно... Берете код, бьете на блоки, расставляете метки времени, отчет по затраченному времени пишете в лог. Проблемные места смотрите и решаете можете ли уменьшить время исполнения. Вангую что самые тормоза у вас будут на выборке из бд или на запросах к апи. В случае бд - вывести запрос и сделать explain. По результату уже можно будет что-то советовать. В случае тормозов с апи - тут уже ничего в плане оптимизации сильно не придумаешь, но в любом случае задачи лучше будет скинуть в очередь и уже оттуда они будут выполняться, пока не закончится список. Кроме того, выборка по одной записи из бд в цикле - классическая ошибка, нужно объединить все запросы в один через join или in(), а дальше работать с полученным массивом.

Точно так же как и в 1977:

Пленка, такая штука есть для съемки качественного видео, вот на нее и снимали. У нее главная характеристика зернистость(насколько мелкие гранулы фоточувствительного вещества) - так вот эта зернистость дает разрешение больше чем 4К.

А ведь и правда есть термин для них (но не тип, конечно): Well-Known Intrinsic Objects

Если же вы спрашиваете как затипизировать что-то, что может быть "RegExp, Array, Function и другим" (и не указывая при этом каждый тип явно), то должен, наверное, подойти только object (не смог в доке TS найти отличается ли TS-тип object от базового JS-объекта; например, в TS есть явная типизация функций, но можно ли её заменить на object?). Но это максимально странная задача, которую явно надо решить каким-то другим способом.