Скачивание видео из под Tor Browser
Прошу помочь тех, кто разбирается. Скачал и установил последнюю версию Тор Браузер. Работает хорошо, стабильно. Но не могу ни просмотреть, ни скачать видео практически ниоткуда. Требует установить флэш плэйер, а установить я его не могу. Он почему-то устанавливается на другой файрфокс, который установлен в системе. Тор Браузер я запускаю со сменного носителя. Как обойти проблему к сожалению не знаю.
Заранее спасибо.
Ссылки
[link1] https://www.torproject.org/torbutton/torbutton-faq.html.en#noflash
[link2] https://www.pgpru.com/forum/unixlike/konfigurirovanieiptables
[link3] http://rg3.github.com/youtube-dl/documentation.html#d5
[link4] http://freshmeat.net/projects/pornotube-dl
[link5] https://www.pgpru.com/comment50800
[link6] https://productforums.google.com/forum/#!msg/youtube/oix_TqHUiNs/aIuyFymvIIYJ
[link7] http://www.reddit.com/r/lifehacks/comments/1pyi62/request_how_to_download_1080p_youtube_videos/
[link8] http://www.clipconverter.cc/addon/
[link9] http://runetbsd.ru/node/346
[link10] http://forums.debian.net/viewtopic.php?f=5&t=76268
[link11] http://comments.gmane.org/gmane.linux.debian.user/415000
[link12] http://forums.opensuse.org/showthread.php/474963-MTP-error-at-booting
[link13] https://lists.debian.org/debian-kernel/2011/12/msg00138.html
[link14] http://mpv.io/
[link15] http://cclive.sourceforge.net/
[link16] http://www.deb-multimedia.org/
[link17] https://packages.debian.org/search?keywords=mpv
[link18] https://www.pgpru.com/comment80262
[link19] https://www.pgpru.com/comment87016
[link20] https://www.pgpru.com/comment80266
[link21] https://www.pgpru.com/comment80271
[link22] https://www.youtube.com/watch?v=r9aE5gNSXxA
[link23] http://www.forensicmag.com/news/2014/07/software-forensically-recovers-watched-youtube-videos
[link24] https://www.youtube.com/watch?v=5m9KLD0-s1w
[link25] http://vladmiller.info/blog/index.php?comment=308
[link26] http://www.scottsmitelli.com/articles/youtube-audio-content-id
[link27] http://earningfun.com/?do=ydl&yt_vid=XXXXXXXXXXX
[link28] http://vcg.isti.cnr.it/~ponchio/untrunc.php
[link29] https://webapps.stackexchange.com/questions/8830/download-a-videopress-video
1). Узлов Tor не так много, их пропускная способность реально ограничена и не стоит перегружать их еще и скачиванием порнухи.
2). Модули для скачивания и просмотра видео не являются составной частью защищенной версии браузера, работающей в связке с Tor. Они поставляются сторонним производителем и их безопасность абсолютно негарантирована. В том же Adobe Flash Player неоднократно находили дыры, дающие возможность не то что деанонимизировать пользователя, но и провести атаку на его компьютер.
Так что или-или. Tor либо просмотр видео.
ТС только захотел флеш поставить, а уже деанон словил :) Мыслепреступление детектор детектед.
По теме[link1]:
Там же. Ну и это выстрел себе в голову, если нет хотя бы правильно настроенного[link2] файервола.
Скачивайте с помощью служб типа http://ru.savefrom.net/ и смотрите скаченное локально. Кстати, не всё видео в сети – порнуха.
Да, ещё бывают миленькие котята.
Ну вот может кто-то и не хочет афишировать свою зоопедофилию :-))
Скачивайте с
помощью служб типа http://ru.savefrom.net/скрытых сервисов и смотрите скаченное локально. Кстати,нетам всё видеов сети– порнуха. Флэш не понадобится. Задача решена. Fixed :)Некоторые видеоматериалы на некоторых сайтах (наример http://pravdu.ru) некоторые могут счесть экстремистскими, так что ёрничать тут не очень уместно.
не вариант
ВолковJS бояться — в интернет не ходить.Существуют плагины (скрипты, программы), способные выдрать flash-поток со страницы на стороне клиента, не устанавливая при этом непосредственно сам флэш. Смотреть видео можно будет mplayer'ом.
Вот только как их самих аккуратно торифицировать?
У youtube-dl, например, вот[link3].
Есть, кстати, и другие[link4] проекты :)
Ещё один полезный веб-сервис для скачки видео: http://videotools.12pings.net. Выдаёт готовую ссылку, которую можно открыть в другой вкладке, чтобы начал скачиваться файл. JS нужен.
В тему: заметил странную особенность. Раньше видео 1080x успешно качалось как через savefrom.net, так и через плагин DownloadHelper[link5], а потом как отрубило: в меню youtube показывается, что разрешение 1080x есть, но ни одно меню (ни веб-сервис, ни плагин) не предлагает в таком разрешении скачать ролик, везде максимум 720x То ли youtube врёт про наличие разрешения у ролика (на моём мониторе это затруднительно определить), то ли они пофиксили интерфейс так, чтобы на таком разрешении не качалось сторонними средствами (а родных не предусмотрено)... Это всё не про Tor Browser, а про обычный FireFox.
Последние полтора-два года качаю с youtube.com, в том числе через Тор, без ява-скриптов с помощью perl-сценария
https://calomel.org/youtube_wget.html
В качестве агрумента нужно указать ссылку вида http://youtube.com/watch?v=abcdefghijk. youtube время от времени меняет формат ссылок, поэтому нужно периодически обновляться. У меня последняя версия (v.30) от декабря 2012, пока работает.
В моём браузере этот сайт сейчас не открывается, непонятно закрылся ли он или автор перемудрил с ssl-настройками. Если у других тоже не открывается, могу этот скрипт тут разместить, он небольшой по размеру.
Поправка: youtube меняет формат внутренных ссылок в html-коде, формат ссылки на веб-страницу не меняется (youtube.com/watch?v=abcdefghijk)
Спасибо. По ссылке есть
Но ссылка никуда не ведёт. Может быть, плагин почах. Искал поиском, но нашёл только, кажется, stand alone application от того же автора.
Перепроверил с помощью perl-сценария. Результат тот же: только 720x. Видимо, или youtube заблочил 1080x на скачку без регистрации (или ещё как), либо попросу врёт про разрешение.
Там, на самом деле, целая Санта-Барбара с этими 1080x и ещё более крутыми разрешениями.
«Why am not being able to download 1080p videos?»[link6] [JS нужен для ссылки] — гугл рассказывает всем, что видео и не должно качаться, и у них по их лицензии нельзя скачивать видео, и вообще шли бы все эти ребята лесом от них, да побыстрее. Народ с политики «мы поменяли интерфейсы всем назло» явно охреневает.
О том, как фиксить, лучше всего написано на reddit[link7]'е. Одни рекомендовали дописывать lataa к началу youtube-адреса, что переправляло вас на сайт, позволяющий скачать видео. Другие рекомендовали сервисы http://savedeo.com и http://tubedld.com (последний пробовал, он не даёт в высоком разрешении скачать). Ещё кто-то советовал этот[link8] аддон (не тестировал). Какой-то из советов даже был ссылкой на сайт, который за вас сам скачает с youtube видео и сам же его cконвертит в вам нужный формат. Как все уже догадались, это будет работать, мягко говоря, очень небыстро, да и не нужно конвертировать видео, не стоит такая задача. Скажу кратко: большинство этих советов меня или не впечатлили или (лично у меня) не заработали.
Как выясняется по ссылкам, проблема состоит в следующем (отваливались многие качалки, какие-то работали, какие-то нет и т.д.): youtube перешёл на другой формат хранения данных. Якобы аудио у него хранится на одних серверах, а видео на других теперь. И никаких совмещённых контейнеров (аудио+видео) теперь в принципе в природе у них для 1080x-видео нету. Помимо этого народ жаловался, что иногда разрешение 1080x есть, но не показывается. Иногда скачка 1080x работала, а иногда нет. Видимо, у них был переходный период на новую систему хранения, и это могло бы объяснить наблюдаемые глюки. Так или иначе, вскорости все традиционные средства перестали работать с 1080x, а предложения скачивать и ставить отдельную программу не внушают доверия. В моём случае всё было просто: я нашёл старый файл, котрый заведомо имел 1080x-разрешение и попытался его скачать с youtube'а заново. Все попытки терпели неуспех. Собственно, на этом файле я и пытался добиться правды.
Теперь о тех способах, которые заведомо работают и более-менее безопасны.
Способ №1
Делаем так:
Способ №2
Допустим, нужно скачать с TBB (конечно, без включенного JS тут не обойтись). В целом, алгоритм тот же, только вместо youtube-dl идём на http://savefrom.net, скачиваем отдельно видео в нужном разрешении (выбираете из списка: хоть 1080, хоть 1440), и отдельно аудио. Потом запускаете всё ту же команду:
Финальные мучения
Казалось бы, всё ОК. Файлы скачаны, звук и видео вместе, всё смотрится. Но не в mplayer. Любая попыка воспользоваться прокруткой прекращает воспроизведение файла. Можно, конечно, пережать, но это будет долго и муторно. Трюки типа -idx тоже не помогают. Приходится смотреть в сторону других плееров. Оказывается, vlc (и его консольная версия cvlc) умеет смотреть такие файлы с прокруткой. При первом запуске vlc задаёт вопросы на предмет того, разрешено ли ему самому лазить в сеть (типа для скачки альбомов или ещё какой служебной информации). Можно это отключить. Но если сразу запускаете cvlc, то не знаю, лазит ли он в сеть или нет. Честно говоря, cvlc сильно продвинулся с тех пор, как я его смотрел в последний раз: много новых хоткеев и опций, покадровая перемотка взад и вперёд и ещё много чего интересного. Видео, правда, при перемотках искажается, но через секунды обычно восстанавливается.
Итак, устанавливаем vlc. Казалось бы, прикладная программа уровня игралки видео никак не может взаимодействовать с такими глубинными вещами как загрузка системы, логи ядра и прочее. Любое рациональное мышление срач в виде ошибок при загрузке ОС сразу отказывается связывать с тем, что мы поставили какую-то маленькую прикладную программу. Но это Unix, и здесь всё возможно. Как было n лет назад возможным, что при установке fluxspace (автоматический менятель обоев для fluxbox) вы получаете[link9] в довесок апач и пых в качестве пакетов-зависимостей, так и сейчас... дух Unix'а не меняется. И ЧСХ, эта ошибка, судя по рассылке, возникает исключительно, если установлен vlc! Конечно, речь не об этой ошибке, а о том, что несколько лет назад такое уже было, а теперь, видимо, наблюдается регрессия. Якобы раньше ядро игнорировало этот класс ошибок, а теперь ругается. Зато юзеры теперь думают, как же так: одной установкой vlc что-то серьёзное сломали в системе:
Читаем это[link10], это[link11], это[link12] и это[link13].
Разработчики ядра сами не очень понимают, что у них там происходит?Авось, через год, когда кто-нибудь нажалуется, это исправят, а пока любуемся на ошибки при загрузке.vlc лучше забыть как страшный сон. Там давно большинство багрепортов воспринимают как "мы все правильно делаем, это другие все делают неправильно", при том, что остальное ПО как-то без этого ухитряется работать стабильно.
Пробуйте mpv[link14]
Качаю через заторенный cclive[link15] (стандартный консольный пакет Debian). Это конечно профилирует перед ютубом.
На выходе файлы flv (для старых роликов) или webm (для новых, в т.ч. HD). Mplayer отлично играет всё скачанное, только нестандартный дебьяновский, а бэкпортнутый из deb-multimedia[link16]. Ну и помним, что Mplayer, как и практически все многоформатные плэйеры — решето в плане безопасности.
720x — это тоже HD. Ваш cclive качает 1080x? Команда exiftool file выводит разрешение для ролика, если что. На обычных ноутбучных экранах, как правило, разница в качестве между 720 и 1280 хорошо заметна.
Мне кажется, или и впрямь в стабильном Debian (Wheezy) его нет[link17]?
А какие проблемы у стандартного дебиановского? Я уже давно не помню проблем, чтоб что-то не смотрелось, но иногда попадаются файлы для которых не работает перемотка (скорее проблема создателей таких файлов, чем mplayer'а). Проблема со скачанными с youtube таким образом файлами — первый в своём роде пример, когда mplayer почему-то не дружит с перемоткой.
Да по барабану вообще, что там в стабильном дебиане есть или нет...
У savefrom.net ограничение в 150MB, но есть другие сайты для скачки с youtube:
- http://file2hd.com
- http://deturl.com
- http://www.telechargerunevideo.com
- http://www.dirpy.com
(один из них выдаёт ссылки на всех разрешения, включая 1080x1920, но ни одна из них не работает). Обычное HD (720) скачивается без проблем. А у savefrom.net, оказывается, есть фишка с доменными именами: если к в ссылке youtube заменить на pwnyoutube или ssyoutube, то сразу перейдёте на savefrom.net с возможностью скачки.mencoder был удалён из jessie, в перспективе — полностью из Debian'а. И как теперь перекодировать видео в нужный кодек? Как сливать аудио и видео в один файл? Ещё ffmpeg есть, но все скрипты и решения были заточены под mencoder. ☹
Лол, в тестинге ffmpeg'а тоже нет. Реп debian multimedia в apt добавлять считается плохо? Там, возможно, он есть.
Попытка:
Импортируйте gpg-ключ со страницы автора непосредственно в gpg и посмотрите на его подписи, есть ли там пересечения с debian-кейрингом. После этого экспортируйте из gpg в apt через apt-key add.
Arnaud Quette
Не будет ли это означать, что теперь любой пакет, подписанный ключом этого автора, система будет считать валидным? Как разруливается, кто что имеет право подписывать? apt-get всё хорошо сделает?
Нет, я только хотел об этом предупредить.
Никак.
С этой т.з. — плохо.
Теперь этот автор (или кто-то утащивший его ключ), который не является владельцем официального подписывающего ключа Debian, может протроянивать вашу систему не только своими собранными пакетами, но и подписывать левые пакеты якобы от Debian. Его можно поймать если сверять все подписи пакетов до установки, но по умолчанию apt этого не делает.
С другой стороны, любой пакет — это потенциальный троян. Пофиг, что вы ставите: можете ставить утилиту, а вам протроянят GRUB. Поэтому, разделять подписи особого смысла нет.
ffmpeg через ffmpeg -i video -i audio out.avi сливает как попало — видео теряет в качестве, звук тоже штормит. Но зато с debian multimedia теперь ставится mencoder, где всё ОК.
В рот мне ноги. А можно, чтоб apt хотя бы предупреждал, что ставит пакеты из сомнительного источника? Наверно, меньшим злом сейчас будет удалить от греха подальше этот ключ. По крайней мере, до тех пор, пока снова не понадобится что-то доустановить из их репа, можно будет спать спокойно.
Сделал apt-key del. Ключ не сразу удалился, что странно. То ли влияет наличие/отсутствие префикса 0x, то ли просто глюки. В sources.list тоже закомментил реп, что он более не ругался.
Они могли бы организовать apt иначе, назначив роли ключам, чтоб каждый мог подписывать только то, на что у него есть компетенция. Конечно, мог бы быть и мастер-ключ, но не у каждого разработчика или владельца репа.
Он один у выпускающего дистра. И один на каждый доп. репозиторий. Все пакеты и так ставятся в систему с правами рута. Какая разница, будет вам протроянено ядро левым mplayer'ом или левым kernel'ом, подписанным ключом mplayer?
Много их там: stable-ключи, automatic-ключи... у меня apt-key list сейчас показывает наличие 10-ти ключей.
Ну и что? Рут мог бы разруливать, в какие пути какой реп что может ставить. Как вы думаете, почему в BSD есть /usr, а есть /usr/local, причём ни один пакет ничего не может поставить вне /usr/local? Тут можно было бы сделать аналогично: под каждый реп — свой /usr/local. А юзеры критичные пакеты всегда будут брать из /usr/bin, потому что PATH. По-хорошему, конечно, тут уже нужен SELinux.
SELinux имеет копию apt-get в виде se_apt-get и массу других команд с приставкой "se_". Но se_apt-get вроде всего лишь не позволяет руту ставить пакеты без подтверждения пароля и смены контекста на SELinux'овый, соответственно он гарантирует лишь, что на поставленные файлы раздадутся правильные SELinux'овые права. Но если правил для раздачи прав содержимому конкретного пакета не предусмотрено, то раздадутся права высшего уровня (unconfined). Ну т.е. да, штатный модуль SELinux для mplayer не даст ему лезть в систему и делать больше положенного, в т.ч. и на этапе установки через se_apt-get. Но чего-то более тонкого мне неизвестно, особо глубокие извращения с SELinux я не осиливал, из-за него и так масса всего в системе глючит и не работает. Если для вас конфигурирование Debian — ужас, то SELinux — это ужас за гранью разумного понимания. А SELinux в исполнении Debian из-за взаимной плохой поддержки — особо ужасен.
Каждый ключ подписывает не пакет, а общий список пакетов репа с хэш-суммами каждого пакета в этом списке. От этого списка проверяется подпись, а по этому списку сверяется сумма скачанных пакетов.
Я, возможно, неосторожно высказался в плане перестраховок, а вы сразу мне поверили в плане негатива. Я не знаю точно, как оно там работает и нет желания это разбирать. Может ли злоумышленник в список своего репа включить пакет из другого? Заметит ли apt конфликт пакетов между репами и как его разрешит? Может ли злоумышленник подменить весь список чужого репа, подписав его своим ключом и подменив там часть пакетов? А если да, то пройдёт ли это незаметно? Или на смену ключа в списке будет реакция как на смену дистра и apt предложит dist-upgrade, а простой upgrade не прокатит? Можно ли сделать хитрую подмену и хитрый MiTM, чтобы обмануть все проверки apt?
Я не знаю ответов на эти вопросы. Они мне неинтересны. Я исхожу из того, что неважно через что будет подсажен в систему троян, в тот же mplayer можно упаковать любой руткит, а на этапе инсталляции из пакета можно выполнить любой скрипт и любую команду (если нет правила SELinux). Если вы не доверяете ключу deb-multimedia, то не ставьте этих пакетов вообще. А то поставил, отвернулся и зажмурился.
Ну да, ключи старых дистров, ключи будущего стабильного, чтобы можно было обновить систему. Нужно знать досконально всю эту матчасть прежде чем обвинять разрабов в недалёкости.
Минимум в плане записи файлов можно сделать традиционными средствами UNIX: запускать установщик пакетов от имени непривелегированного юзера с дропом прав после запуска, причём права должны быть такие, что в /usr/local он писать может, а в другие пути /usr — нет.
Охотно верю, поэтому считаю, что в моей модели угрозы виртуалки будут самым правильным выбором.
А мне кажется, что это вопросы, с которых всё должно начинаться, а не заканчиваться ими. «Чему мы доверяем-то?». Хотя, в принципе, да, даже зная имена пакетов, это не гарантия ни чему. Вдруг в библиотеке libnsa сидит файл /usr/bin/gpg, который будет apt'ом записан вместо настоящего gpg?
Юзабилити тоже важно. По-хорошему, под мультимедиа нужно отвести отдельный дом, вырубить его из сети, ставить туда всё, что заблагорассудится, и никуда не отворачиваться. Без виртуалок это не делается.
Либо libnsa будет конфликтовать с gpg (мейнтейнеры пропишут), и APT её не поставит, либо dpkg при попытке установить пакет страшно разругается на конфликт содержимого пакетов, и всё равно его не поставит.
Вместо уже существующего gpg можно установить другой критический пакет, да ещё дать ему какие-то приоритеты над другими через настройки (поменять PATH или ешё как).
Можно при установке выполнить скрипт, который выгрузит некий файл и запишет его как руткит в GRUB, в initrd, куда угодно, а после загрузки и активации он всё за собой на системе подчистит.
Кстати, прокрутка в новой версии mplayer для так слитых файлов (звук + видео → avi-контейнер) нормально работает искоробки, поэтому извращения с vlc более не нужны. Ну, хоть какие-то баги исправились, а то в основном лишь к старым добавляются новые.
Многие называют это прогрессом. :)
Зато есть старые файлы, которые когда-то были слиты через старый mencoder и игрались старым mplayer или старым vlc с известными проблемами. Если теперь их проирывать новым mplayer'ом, то играются нормально, но без прокрутки. Если их проигрывать новым vlc, то на видео через каждые сколько-то секунд будут видны такие артефакты, как будто два разных видео искуственно слили в одно. Т.е. удачный баг-пофикс касается только новых файлов, обработанных новыми версиями mencoder'а и проигрываемых новым mplayer'ом, а вот со старыми уже готовыми файлами теперь всё стало только хуже. Даже если ручная перекодировка видеопотока через mencoder спасёт дело, это всё равно ад: даже на Intel i7 перекодировка занимает по времени столько же, сколько сама длительность видео, а на i5 уже в два раза больше.
У mplayer (надеюсь вы используете его без GUI) можно открыть man и ужаснуться количеству опций. Есть шанс, что вы подберёте такие опции, при которых он не будет падать или зависать на прокрутке файлов. Смутно припоминаю, что это опции, касающиеся синхронизации кадров.
Есть опция -idx, которая часто помогает, но в данном случае она почему-то оказывается бесполезной. Инуитивно я понимаю, что проблема почти точно в том, что mencoder делает (делал) бракованные файлы. При попытке нажать на прокрутку проигрывание без каких-либо ошибок просто прерывается и возвращается приглашение командной строки. Иногда удаётся найти в начале файла такие моменты, когда при прокрутке назад mplayer не падает, а просто проигрывание немного прокурчивается вперёд.
Можно попробовать ещё другие проигрыватели помимо mplayer и vlc. Кстати, заметил, что ранее mplayer играл (хотя бы как-то) почти все файлы, а теперь во многих он играет только звук, а чтобы получить ещё и видео, нужно запускать vlc. То ли mplayer'у кодеков не хватает, то ли каких-то плагинов... не знаю.
Естественно. GUI даже не установлено.
Нет в жизни счастья.
Не качает. ☹ Контрпример[link22]:
P.S. cclive рассказывает ютубу, какой на ethX прописан локальный IP и какой на машине hostname?
Наблюдения за последними эксцессами на ютубе:
Это у меня одного так?
В команде ошибка, torsocks не написано.
Лень разбираться, но, похоже (см. пример выше), таки качает, хотя с опцией -S это разрешение почему-то не показывается в листинге.
Проверил. Дело не в нём, дело в ютубе. Иногда даже видно в некоторых случаях, что ютуб поменял внешний вид своего интерфейса.
Наблюдается такая корреляция, что чем свежее ролик, тем меньше вероятность, что он будет смотреться, но это лишь корреляция, а на практике может быть по-всякому. Иногда те ролики, которые не показывались, через какое-то время начинают смотреться, или наоборот: те, которые смотрелись, перестают показываться. Такого, чтоб рестарт цепочек или браузер при этом помогали, тоже не наблюдается.
Кто-нибудь интересовался тем, что ютуб вставляет в загружаемые видео? Почти ничего не гуглится. Есть это[link23], но оно только косвенно относится к теме вопроса. Скачал через Tor пару раз один и тот же файл, сравнил. Видно, что между файлами есть отличие: в ролик записывается дата скачки, адрес конкретного google-сервера, который отдал ролик, и ещё немного каких-то шестнадцатеричных и не только цифр, назначение которых непонятно.
Пример:
Берём стандартный ролик[link24], скачиваем его через разные цепочки в одинаковом разрешении (360, к примеру), сравниваем полученные файлы:
Вспомнил цитату[link25] про SATtva fingerprints. ☺
А если много-много раз скачивать один и тот же файл, то этот кусок псевдорэндомный?
М.б. Google заносит себе в базу всё, что может вытянуть о пользователе: браузер, ОС, устройство, был ли залогинен, по какой ссылке перешёл, что смотрел до этого. А в файл заносит хэш этой инфы, чтобы по этому хэшу сопоставлять с закрытой базой и быстро делать по ней поиск.
Если же хэши не псевдорэндомные, а с какими-то корелляциями как в этой паре, то может использоваться нечёткий хэш для поиска наиболее совпадающих вариантов.
Без дополнительных зацепок трудно сказать, что это.
При скачивании по одной и той же прямой ссылке, в том числе через разные цепочки, меняется только часть напоминающая время.
А что этот участок файла означает в контексте MP4-контейнера? Тэг какой-нибудь?
Может это какой-то content-ID[link26]?
Не изучал вопрос.
Не сомневаюсь.
Может, и так. Сложно сказать. Модель угрозы — скачали ролик, потом его перевыложили, после чего противник может узнать, как его изначально скачали, с какого IP, какая была система и т.д. Заносить хэш инфы в сам файл нет реальной необходимости: логи могут быть на стороне гуглосервера, а в файле достаточно указать конкретный сервер и время скачки (что, как видно, и так делается).
Я скачивал одно видео через savefrom.net, а другое — через cclive. Есть, конечно, шансы, что и savefrom.net что-то своё вставляет в загружаемый ролик...
youtube-dl научился скачивать видео в FullHD (1920x1080): вытаскивает с YouTube отдельно FullHD-видео и аудиофайл и склеивает их в постобработке.
А разве не умел? Если в списке форматов был FullHD – номер его после ключа -f ставишь и выкачивает.
YouTube выдаёт FullHD только как видеопоток, без звука. Скачивать можно было и раньше, но нужно было склеивать вручную. Теперь это автоматизировано.
Понял. Спасибо.
Последние полгода-год заметил особенность: почти всегда youtube-видео, проигрываемые в TBB, чуть-чуть не доигрываются до конца. Чтобы досмотреть до конца, требуется перезагружать страницу. Часто это сопровождается началом показом рекламы. Т.е. он не может штатно показать несколько последних секунд почти каждого ролика, хотя почти все ролики смотрятся отлично вне зависимости от их длины.
Если судить по savefrom.net, то это особенность не только HD-разрешения (1080x), но и 480x-разрешения. В отличие от них 360x и 720x скачиваются сразу как единый файл со звуком и видео.
Ещё сервис для скачки с ютуба. Из ссылки
https://www.pgpru.com/comment39487
Fix a truncated mp4: do it yourself. (source code and instructions HERE)[link28]
В mp4 заголовки хранятся в конце файла
Как скачать c rutube?
saveformnet с ним не работает.
http://ktak.ru (проверил, работает).
Чем скачать с videopress.com?
На stackexchange советуют[link29] FlashGet. Веб-даунлоадеры для videopress найти не получается.
После обновления TBB до 5.5 savefrom.net перестал давать скачивать файлы. Предыдущая версия TBB работает.