Видео и субтитры · Загрузчик миниатюр YouTube и средство просмотра метаданных
Как работает запрос миниатюры YouTube: идентификатор видео, название размера и i.ytimg.com
· Как это работает
ютуб миниатюры http
Миниатюры YouTube хранятся по предсказуемым адресам, определяемым на основе идентификатора видео и названия размера. В этом посте объясняется, как формируются эти запросы, что возвращается и почему инструмент может перечислять все размеры, не затрагивая само видео.
У вас есть ссылка и вам нужна картинка — повседневная задача, связанная с загрузкой миниатюр.
Редактор информационного бюллетеня часто начинается со ссылки просмотра, и ему требуется надежное изображение предварительного просмотра, а не видеопоток. Полезной единицей является одиннадцатизначный идентификатор видео, поскольку каждый общедоступный адрес миниатюры состоит из этого идентификатора и известного имени файла. Регистрация этого идентификатора позволяет редактору связать каждую проверку размера с одним видео, даже если исходный общий ресурс URL содержит параметры отслеживания или метки времени.
ToolAcre анализирует вставленную ссылку в браузере перед выполнением любого запроса. Этот локальный этап отделяет понимание входных данных от получения общедоступных ресурсов, поэтому неверный хост или неверный идентификатор можно отклонить, не обращаясь в Google. Поэтому в журнале запросов недопустимая вставка вообще не должна создавать запись i.ytimg.com; только подтвержденный идентификатор переходит к зондированию изображения.
Хост изображения: i.ytimg.com — где отображаются миниатюры и почему он отделен от youtube.com.
Файлы изображений поступают с i.ytimg.com, а не с хоста страницы просмотра. Хранение статических постеров на хосте изображений позволяет клиенту запрашивать JPEG напрямую, не загружая проигрыватель, рекомендации, комментарии или страницу JavaScript. Следовательно, ответ может быть оценен как изображение сам по себе, без интерпретации разметки игрока или ожидания инициализации полной страницы просмотра.
Хост прямого изображения по-прежнему является сетевой службой, а не локальной обработкой. Блокировщики рекламы, автономный режим, управляемые прокси-серверы или политика DNS могут остановить запрос, и Google получит запрос вместе с заголовком Origin, предоставленным браузером. DevTools может доказать, куда направился запрос, а расшифровка ответа предоставляет отдельные доказательства, необходимые для того, чтобы отличить произведение искусства от небольшого запасного варианта YouTube.
Шаблон адреса — идентификатор видео плюс имя размера, например default, mqdefault, hqdefault, sddefault или maxresdefault.
Реализованный шаблон: https://i.ytimg.com/vi/VIDEO_ID/VARIANT.jpg. ToolAcre заменяет один из maxresdefault, sddefault, hqdefault, mqdefault, default, hq1, hq2 или hq3 после проверки формы идентификатора. Проверка всех имен предотвращает преждевременную победу ответа 200, содержащего крошечный запасной вариант, над другим вариантом, содержащим полезную иллюстрацию.
Эти восемь имен включают в себя пять вариантов постеров и три кадра. В каталоге записаны номинальные размеры и назначение, но браузер все равно проверяет возвращенный файл, поскольку не каждое видео публикует все возможные размеры. В строке указано, что на самом деле вернуло это видео для этого имени, которое может отличаться от размера, который каталог связывает с полностью заполненной загрузкой.
Что доказывает ответ: статус, байты и декодированные измерения вместе
В схеме статус HTTP рассматривается как доказательство существования размера, но реализация исправляет это утверждение. Отсутствующим кандидатом может быть 404, другая ошибка HTTP или успешный ответ 200, содержащий заполнитель YouTube 120×90 YouTube. Датированный отчет фиксирует ответ, отправленный браузеру, вышедшему из системы, во время этого запуска; он не может реконструировать старый плакат, который ранее шел по тому же предсказуемому пути.
ToolAcre считывает тело как Blob и декодирует его истинные размеры. Недекодируемое тело является ошибкой, а результат 120×90 для более крупного варианта помечен как отсутствующий; Таким образом, статус, размеры и байты описывают разные доказательства. Поскольку изображение поступает непосредственно от Google, эта проверка повышает точность, не делая поиск секретным для службы, которая его предоставила.
Рабочий пример: построение всех восьми запросов JPEG для одного видео.
Для одного действительного идентификатора инструмент создает восемь URL-адресов JPEG вместо пяти, указанных в схеме. Он проверяет пять названий плакатов, а также hq1, hq2 и hq3, сохраняя порядок в каталоге, поэтому в первую очередь рассматривается самый большой предполагаемый плакат. Таким образом, редактор может сравнить основную иллюстрацию загрузки с тремя захваченными позициями кадров вместо того, чтобы ошибочно принимать эти кадры за альтернативные разрешения постеров.
Один запрос может вернуть 1280×720, другой 480×360, а необязательный может вернуть заполнитель или 404. В листинге сообщается о каждом результате, а не делается вид, что одна резервная последовательность может подтвердить каждую загрузку. Это параллельное доказательство особенно полезно, когда в более старой загрузке есть плакат стандартного разрешения, но нет подлинного файла с максимальным разрешением.
Почему это никогда не касается видео: миниатюры — это отдельные общедоступные файлы, а не часть потока.
Запрос миниатюры никогда не запрашивает байты видео или аудио. Он обращается к отдельному общедоступному файлу изображения и не содержит токена проигрывателя, расшифровки медиа-подписи или пути загрузки потока. Даже самым крупным кандидатом является обычный ответ JPEG, поэтому проверка этих URL-адресов ничего не говорит о доступных медиаформатах, битрейтах или авторизации воспроизведения.
Разделение не создает доступа. Частные, удаленные видео и видео с возрастными ограничениями не содержат пригодных для использования записей о выходе из системы, а соглашение об общедоступных миниатюрах не может обойти эти ограничения или восстановить файл, который YouTube не публиковал. Предсказуемый путь — это всего лишь соглашение об адресах; разрешение и доступность по-прежнему определяются тем, что хост изображения обслуживает во время запроса.
Что сюда не распространяется: частные видео, контент с привязкой к региону и миниатюры, которые были изменены с момента вашего последнего просмотра.
Измененные миниатюры — это еще одна граница: предсказуемый URL относится к изображению, которое отображается в данный момент, а не к исторической версии. Политика региона и доступность выхода из системы также могут влиять на то, что посетитель может получить во время поиска. Любой, кто документирует кампанию, должен датировать загруженное изображение, поскольку запрос того же пути после редизайна может вернуть разные пиксели под неизмененным URL.
Проверка миниатюр может завершиться неудачно через сеть, из-за неуспешных ответов HTTP, из-за заполнителя 200 или из-за того, что тело не может декодировать как изображение. Интерфейс разделяет эти классы отказов, поэтому их отсутствие не преувеличивается. Прерывание прокси-сервера требует повторной попытки, тогда как декодированный заполнитель 120×90 конкретно показывает, что запрошенный более крупный вариант не был доставлен.
Вывод: предсказуемые адреса, объявленные заранее — как YouTube Thumbnail Downloader перечисляет все размеры ссылок
Анализ происходит до Fetch. После получения браузер отправляет анонимные запросы GET без учетных данных без реферера, без кэширования хранилища и последующих перенаправлений непосредственно на i.ytimg.com и www.youtube.com; Google видит эти запросы и заголовок Origin, но между ними нет сервера ToolAcre или прокси-сервера. Поэтому DevTools должен показывать трафик изображений, исходящий из браузера в Google, но не вызов ToolAcre API, несущий вставленный идентификатор видео.
Сопровождающий поиск oEmbed использует канонические часы URL, содержащие тот же идентификатор плюс format=json. Это может произойти из-за сети, ответа HTTP или недействительного JSON, и ни один из запросов не сможет получить частные, удаленные материалы или материалы с возрастными ограничениями. Миниатюрное свидетельство и свидетельство метаданных остаются отдельными: JPEG может быть доступен даже в случае сбоя структурированной записи, и ни одна из ветвей не обеспечивает постоянный доступ.