Результаты поиска по запросу "скачать mp4 фильмы"
Чего тебе?
"Большой брат": в Сети появился сервис, отслеживающий все загрузки с торрентов по IP
Неизвестные создали сайт на домене .com под названием "I know what you download" – "Я знаю, что ты скачивал". На нём, используя один только IP-адрес пользователя, можно узнать, что он скачивал с торрентов.
При указании конкретного IP сервис показывает, где он зарегистрирован, а также какие загрузки с торрентов по нему выполнялись. Указывается название загрузки, дата начала и окончания и даже тип контента и ссылка на него – можно запросто перейти к первоисточнику. Также указан и размер файла.
По какому принципу работает сервис, пока не совсем ясно – он способен фиксировать далеко не все загрузки. Примечательно, что в разделе "О нас" указывается возможность сотрудничества, например, с правоохранителями.
– Мы готовы делиться данными, предоставляя их в различных форматах/разрезах на автоматизированной основе. Кроме того, мы располагаем техническими возможностями для "поимки" пользователей, раздающих торрент-файлы. Подключаясь к компьютеру пользователю и скачивая маленький кусочек торрента, мы можем снять TCP-дамп обмена данных с пользователем. Данные из дампа имеют уникальный "отпечаток" – хэш, который совпадает с хэшем из торрент-файла. Это позволяет однозначно доказать факт распространения торрента с некоторого IP-адреса. Скоро это будет актуально и в России, – пишут создатели.
Отметим, что за распространение некоторых типов файлов, а также файлов, при распространении которых были нарушены авторские права, в России действительно предусмотрено уголовное наказание.
Ссылка на сайт iknowwhatyoudownload.com
P.S При заходе на сайт он автоматом пишет твой ip и скачки
25.12.2016 1:32:38 25.12.2016 1:32:38 Приложение для PC 19.27Гб 23.12.2016 20:07:27 23.12.2016 20:07:27 Фильм 1.46Гб 23.12.2016 20:07:27 23.12.2016 20:07:27 Приложение 13.98Мб 23.12.2016 16:09:08 23.12.2016 16:09:08 Приложение для PC 302.04Мб
Так же можно увидеть кто еще скачивал файлы.Заходишь в любой торрент на сайте и появится кнопка выбора всех IP кто его скачивал,а затем переход на все их скачки.
Как то так
"Ленивая" загрузка картинок + остановка гифок на плохом интернете
Этот пост касается только нового движка, на текущем основном реакторе все без изменений.
Что такое "ленивая" загрузка?
Это такое поведение сайта, при котором картинки, которые лежат где-то глубоко внизу, далеко от текущего экрана, не загружаются. Вы решаете промотать страницу вниз, и только тогда эти далекие картинки начинают подгружаться, потому что есть реальный шанс, что вы-таки до них домотаете.
Это полезно и с точки зрения экономии трафика, и с точки зрения более приоритетной загрузки именно тех картинок, у которых максимальный шанс быть посмотренными.
Раньше мы полагались на библиотеку nextjs в вопросе "ленивой" загрузки картинок, но в новой версии они - согласно современным практикам - отказались от своих механизмов и перешли на встроенные механизмы "ленивой" загрузки в браузерах. Стало лучше!
Для примера рассмотрим, как работает "ленивая" загрузка картинок в Хроме (и в браузерах на Chromium). С июля 2020 года разработчики браузера изменили расстояние от видимого экрана, на котором картинки начинают загружаться. Для быстрого интернета это расстояние уменьшили с 3000 пикселей до 1250 пикселей, для медленного - с 4000 пикселей до 2500.
Разработчики браузера говорят, что могут еще экспериментировать с этими порогами. Мы на этот встроенный механизм влиять не можем.
В разных браузерах могут быть разные расстояния от видимой части экрана.
А что же гифки?
Гифки и гифковидео(видеогифки?) тоже подвластны этому механизму браузера. В дополнение мы в качестве эксперимента добавляем новый механизм остановки гифковидео для плохого интернета.
Если браузер решил начать загрузку видеогифки, но за 5 секунд загрузка не закончилась полностью, мы ставим видео на паузу и показываем контролы. Это выглядит вот так:
Браузер будет потихоньку буферизовать контент видеогифки, особенно если она находится у пользователя на экране. Это тоже встроенный механизм - браузер сам выбирает, загрузке какого контента отдать приоритет.
Пользователь может сам решить, интересна ли ему гифка, будет ли он ждать ее полной загрузки. Если гифка будет безжалостно промотана, браузер сильно понизит приоритет или вовсе остановит загрузку данных для этой видеогифки.
Обратная связь
Для нас новый движок - это тестовая песочница для новых фичей, построенная на довольно новых технологиях. Через 5 лет эти технологии перестанут быть столь новыми, и все будет работать на каждом утюге и чайнике. А пока могут быть проблемы, о которых вы можете нам сообщить, что поможет нам обкатать новый движок как следует.
Важно! Мы принимаем репорт только если у вас отключены все расширения браузера или вы используете "чистый" браузер. Если проблема возникает только с включенным расширением, то репорт надо слать разработчику расширения, а не нам.
В прошлый раз, когда мы тестировали редактор, было много проблем, связанных KellyC. Дело житейское, KellyC может просто не успевать отреагировать на наши изменения. Здесь можно подать репорт разработчику KellyC, если что-то вдруг сломается.
А вот инструкция как прислать репорт о баге на новом движке нам: https://m.joyreactor.cc/report
До связи, драгоценные!
Вскрытие формата OJD
Кому лень читать интересную историю, вот ссылка на конвертер с инструкциями, как превратить .ojd в .mp4: https://drive.google.com/file/d/1GlMXGss0R2-jYP0TOZ_2Y1xzl9Ugar7l/view?usp=sharing
инструкции в readme.txt применимы к unix/linux, но всё работает и на WSL под виндой.
Ну ладно, а кому не лень и таки интересно, услышьте же охуительную историю о том, как я этот самый конвертер собрал!
Заранее предупреждаю - я нихрена не смыслю в аудио и видео, я просто программист на C. всю инфу про H264 и AAC я нагуглил и вычитал в коде старой версии ffmpeg; если тут есть эксперты, простите меня заранее, если какую-нибудь хуиту скажу.
НАЧАЛО ИСТОРИИ. ТАИНСТВЕННОЕ ВИДЕО НА РЕАКТОРЕ? СКАНДАЛЫ, ИНТРИГИ...
Ну так вот, ушел я тут, значит, в отпуск на пару недель, и тут вижу интересный пост от Иисуса:
Удивительная история - файл с видео, который сам Иисус не может открыть!
Вместе с многоуважаемыми пидорами из комментов начал гуглить, с превеликим любопытством - случай и правда таинственный, не находилось вообще ничего толкового. С большим интересом тред пялился на хекс-дампы, которые Иисус предоставил в начале ветки ( http://joyreactor.cc/post/4899255#comment23718856 ), особенно на повторяющееся ASCII слово qbox...
И наконец товарищ http://joyreactor.cc/user/nun-buoy , а затем и товарищ http://joyreactor.cc/user/dadv нашли совпадение - старый проприетарный аппаратный видео/аудио кодек MG1264! Эта штуковина была вроде как сделана с рачетом на мобильные девайсы, что совпадало с инфой от Иисуса (видео со старого телефона).
Сообща нами были найдено следующее:
* Базовые характеристики: https://www.semiconductorstore.com/pdf/newsite/mobilygen/MG1264_Comet3_DS.pdf
* Слитые доки по версии 1.1 кодека: https://manualzz.com/doc/7153241/mg1264
* Чудом сохранившийся кусок самопального муксера на C#: https://csharp.hotexamples.com/site/file?hash=0xed6a386bc80b4638eac9ea030e141c8312db2507c58453306c1ab71598c2b8f2&fullName=VideoStreamCodecs/Formats/QBox.cs&project=ctapang/GPUCyclops (толку от этого в результате не вышло, просто интересно почитать)
* Полностью сохранившаяся либа для работы с аппаратным кодеком: https://tipok.org.ua/node/13, плюс патч для ffmpeg 0.6, включающий в себя демуксер для проприетарного формата qbox: https://gist.github.com/lynxis/3033513 (последнее в результате стало основным столпом решения проблемы)
Ручки уже основательно чесались, так что я скачал те самые доки и стал читать и сравнивать с хекс-дампами из треда.
Те самые qbox-ы оказались форматом контейнеров для AAC и H264 пакетов. В доках был описан формат самих qbox-ов:
![The QBOX header is as follows.
typedef struct {
uint32_t box_size; uint32_t box_type; // "qbox"
uint32_t box_flags; // (version << 24 | box_flags)
uintl6_t sample_stream_type;
uintl6_t sample_stream_id;
uint32_t sample_flags;
uint32_t sample_cts;
uint8_t sample_data[];
} QBox;](https://img2.joyreactor.cc/pics/post/full/Иисус-geek-программирование-6900579.png "Иисус,Исусе,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,программирование,реактор помогающий,много букаф,Истории,длиннопост")
Действительно, в хекс-дампах Иисуса прослеживались эти самые qbox-ы, в основном все как описывалось (http://joyreactor.cc/post/4899255#comment23720396), но с одним нюансом. Первые 8 байт файла не являлись частью какого-либо qbox-а. "Ну мало ли, наверное, проприетарный хедер", подумал я. Все казалось достаточно однозначно: ojd файлы - наверняка просто qbox аудио/видео стрим в формате "что энкодер высрал, то в файл и запишем" (в примерах из доков MG1264 такие файлы назывались .qbx), плюс в начало дописаны 8 байт для точной идентификации типа файла или еще чего-то в этом духе. Из интереса я еще некоторые время попытался эти 8 байт нагуглить, проверил пару баз файл хедеров, но это мне ничего не дало.
Стоит отметить, что тут все, блять, все в big-endian. Я раньше никогда с такой херней не работал, так что тут все немножко ломало мой привыкший к little-endian мозг =)
Тут стоит отметить один неприятный нюанс - я это далеко не сразу заметил, но несмотря на то, что те самые доки вроде бы жестко гарантируют, что в первом H264 видео qbox-е будут только NAL-ы SPS-PPS, в реальности тут в первом qbox-е выходит последовательность AUD-SPS-PPS-IDR (это можно увидеть здесь: http://joyreactor.cc/post/4899255#comment23718856 у каждого NAL-а 4 байта стандартного старткода заменено на префикс-размер, так что их можно легко подряд читать, не парясь с полным декодированием).
Для наглядности:
Тут выделены размеры (которыми заменены старткоды). Начинается каждый NAL так: 1 бит == 0, 2 бита == реф индекс (типа группа типов), дальше 5 битов ID (nal_unit_type: 9==AUD, 7==SPS, 8==PPS, 5==IDR), это все гуглится по запросу "ISO/IEC 14496 pdf". Короче, получается, что вместо чистого конфига тут еще и данные видео есть.
Если бы я знал хоть что-то об H264, я наверняка бы заподозрил, что 13744 байта как-то слишком дохуя для одних SPS-PPS. Но я ничего не знал и ничего не заметил, так что подозрений об актуальности и возможной устаревшести дока относительно ojd ко мне в душу не закралось...
КАК Я ЕБАЛСЯ С ФОРМАТОМ OJD
Ну, в общем, охуительно уверенный в себе, я постучался к Иисусу в личку, и он мне скинул .ojd файл. Дальше я нашел github FFmpeg-а, клонировал, и стал тыркаться. Приладить тот патч с tipok.org.ua к современной версии FFmpeg-а оказалось слишком сложно, но благо в репозитории был бранч подходящей версии 0.6.7 (патч писался для 0.6.1), я чекаутнул бранч и приладил на него qbox.c, qbox.h и прочие диффы из патча, нужные для работы демуксера. Нагуглив, как с этим ffmpeg вообще работать (лол), легким движением хвоста... эээ... tail-а я обрубил первые 8 байт файла ojd и попытался скормить результат свежескомпиленному ffmpeg-0.6.7.
Естественно, просто так нихуя не сработало.
Покопавшись в ffmpeg-е (выяснилось, что у него, по крайней мере, в версии 0.6, компилится дебаг-билд ffmpeg_g, который заходит с gdb), выяснил, что первый qbox парсится нормально, но со вторым возникают проблемы. Применив xxd, я обнаружил странное: второй qbox начинался через какой-то промежуток после ожидаемого конца первого.
Для наглядности покажу на изначальном .ojd (без обрубленного начала):
Тут хорошо видно "хедер" в начале, после него qbox с размером 0x35b0, и по-хорошему, если это qbox стрим, как в доках, то следующий qbox должен начаться на 0x8+0x35b0==0x35b8, но вот нихуя, начинается он аж на 0x3690!
Изрядно прифигев с такого расклада событий, я тупо пялился на этот хекс-дамп, и тут заметил в нем нечто крайне интересное.
А вы, дорогие мои читатели, заметили это? Заметили, блять, с чего начинается строка 00003600?
0461 00a0 **** 03ff
Практически идентично хедеру в начале файла!!!!
Я охуел. Я сделал grep. Я охуел еще больше.
Это пиздец. Каждые 0x200 (512) байт .ojd файла начинаются с 8-байтного префикса. Байты 5-6, по ходу, какой-то... sequence number? Причем нормальный счет идет только в байте 6, в байте 5 же происходит какая-то полная поебень, но там явная закономерность (36-06-13-02-02-03-21-00 повторяются, но потом меняются с переносом единицы из 6 байта, короче, что-то крайне странное).
Я не знаю, что это за наркомания. Я подозреваю, что это след какой-то крайне допотопной (возможно самопальной?) блочной файловой системы родной ОС девайса, на который таинственные видео записывались. Если кто тут узнал-распознал эту херню, объясните мне, пожалуйста, мне очень любопытно!
Кстати, забавный нюанс - в видео Иисуса этот сраный формат немножко поломал конец qbox-стрима, то есть последний qbox, который не влез в последний блок ojd, оказался таки обрезан. Это видно в комменте Иисуса с дампом конца ojd файла здесь, если посчитать размер последнего qbox-а: http://joyreactor.cc/post/4899255#comment23719489 а после конца этих блоков зачем-то идет очень дохуя нулей =) но не буду на этом заостряться.Ну, делать нечего, по-быстрому я написал конвертер, который из каждого 512-байтного блока в файле .ojd выкидывал первые 8 байт и записывал результат в файл .qbx.
Дело пошло веселее. С выкинутыми префиксами блков конец каждого qbox-а стал совпадать с началом следующего, и ffmpeg... послал меня нахуй, потому что что-то оказалось не так с аудио. Оказывается, демуксер не генерировал почему-то аудио-стрима, хотя я точно видел в файле аудио-qbox-ы.![printf("Converting ojd blocks to qbox stream..An"); while (fread(block, INBLK_SIZE, 1, infile))
{
int bufval = 0; int i;
for (i = 0; i < 8; i++)
{
bufval |= block[i];
>
if (bufval = 0)
{
// Reached ojd padding at end of file, apparently break;
}
fwrite(block + 0x8, INBLK_SIZE - 0x8, 1,](https://img2.joyreactor.cc/pics/post/full/Иисус-geek-программирование-6900584.png "Иисус,Исусе,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,программирование,реактор помогающий,много букаф,Истории,длиннопост")
Решил я разобраться с этим позже. Путем нехитрых хаков кода, я смог декодировать видео в валидный mp4 файл с... ебаным слайдшоу, судя по частоте кадров. Настроив вручную взятый от балды фреймрейт, я еще раз декодировал видео, и... моему взору предстали обещанные Иисусом ебущиеся карлики! Успех!!!!!!!!!
Ебались они, правда, как-то подозрительно слишком резво, так что я сделал заметочку себе на будущее - разобраться с фреймрейтом ебаным. Но сначала аудио.
И тут меня ждал пиздец.
КАК Я ЕБАЛСЯ С АУДИО
В ебаных доках черным по белому было написано, что первый аудио qbox должен содержать аудио конфиг в формате AudioSpecificConfig из ISO/IEC 14496-3. Но конфиг-флага ни на одном из аудио-qbox-ов не нашел ни демуксер, ни я вручную. Правда, в доках и не было написано, что этот флаг обязательно на qbox-е с аудио-конфигом должен быть... Я решил поэкспериментировать и взять просто первый аудио-qbox и попытаться дешифрануть его как конфиг.
Меня ждало жестокое разочарование.
FFmpeg матерился по-черному, закидывал меня эррорами, говорил мне, что конфиг говно. Поебавшись немного, я горько вздохнул, вбил в гугле "ISO/IEC 14496-3 pdf" и начал вникать.
Как видно, первые 5 бит должны указывать на тип объекта. Судя по докам MG1264, этот тип должен быть 2 (AAC_LC).
И тут уже незадача - все содержимое qbox-ов с аудио начиналось на 0x21:
дас ист крайне печально, ведь первые 5 битов 0x21 - это вовсе не 2 (AAC_LC), а очень даже 4 (AAC_LTP), который тот билд ffmpeg-а вообще не поддерживал.
Вообще, рассматривая эти qbox-ы, я невольно задумался - а есть ли среди них вообще этот самый AudioSpecificConfig? Даже если проигнорировать первые 5 битов, дальше все равно получалась лютая хуита. В доках было четко сказано, что девайс поддерживает 2-канальное стерео AAC-LC аудио с sample rate 48000, 44100, 32000, 24000, или 22050 Hz.
Крепко задумавшись, я продолжил гуглить и штудировать ISO/IEC 14496-3, как вдруг до меня дошло, что все эти пакеты прекрасно подходят под определение AAC raw data block типа ChannelPairElement!
Здесь ID_CPE==1. CPE - это просто пакеты для двухканального стерео-аудио (это подтвердил и код ffmpeg). Я чувствовал, что я на верном пути!
Но мне пришлось смириться с горькой правдой - конфига аудио (AudioSpecificConfig) в этом стриме qbox, по ходу, нет вообще. Возможно, девайс, с которого это было записано, поддерживал только одну настройку аудио, и qbox с аудио из файла ojd специально выкинули? Или же расчет был на то, что какие-то декодеры поумнее ffmpeg 0.6 смогут и без конфига тут разобраться? Мистика, конечно...
Ну, раз конфига нет, то сделаем сами, хуле. Будет у нас свой AudioSpecificConfig с блекджеком и шлюхами. Сначала я просто хакал ffmpeg, а потом уже дописал фальшивый аудио qbox в начало файла. Но это я чуть позже покажу.
Итак, мы имеем audioObjectType==2, 3<=samplingFrequencyIndex<=7, channelConfiguration==2. Если что, кстати, последние 2 значения - индексы в такие массивы (из кода ffmpeg 0.6.7):
После некоторых попыток стал я пробовать различные комбинации и... нихрена. FFmpeg выплевывал тонну ошибок (но файл какой-то все-таки выдавал). В чистое AAC не конвертировалось, а при декодировании в raw audio (wav) мои уши встречал оглушительный пердеж. После некоторой ебли, мне показалось, что на частоте 22050 ошибок вроде выдается меньше, и стал с ней тыркаться.![const int ff_mpeg4audio_sample_rates[16] = { 96000, 88200, 64000, 48000, 44100, 32000
57 24000, 22050, 16000, 12000, 11025, 8000,
58 };
59
const uint8_t ff_mpeg4audio_channels[8] = {
61 0, 1, 2, 3, 4, 5, 6, 8
62 };
7350,Иисус,Исусе,geek,Прикольные гаджеты. Научный, инженерный и айтишный](https://img2.joyreactor.cc/pics/post/full/Иисус-geek-программирование-6900589.png "Иисус,Исусе,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,программирование,реактор помогающий,много букаф,Истории,длиннопост")
Дальше я взял в руки gdb и стал разбираться, откуда идут ошибки. FFmpeg декодирует каждый channel_pair_element так: сначала общий конфиг, потом левый канал, потом правый. В пакете с данными они идут друг за другом последовательно (в табличке channel_pair_element это видно - там это называется individual_channel_stream).
Удивительно, но все ошибки выдавались при декодировании правого канала.
Почесал я репу, похакал я код ffmpeg-овского декодера aac, чтобы, значит, он игнорил ошибки со второго канала, и с каждого qbox-а брал только один экземпляр данных для первого канала.
Получившееся в результате аудио было... странным. В правом ухе оглушительно пердел сатана. Но в левом, кажется, слышались стоны ебущихся карликов!!!!!!
...но стонали они как-то... ускоренно? Я задумался и сел вчитываться в код ffmpeg. Скорее всего, второй канал не выходило распарсить, потому что плохо парсились данные первого канала. Если его недопарсить до конца, или же наоборот перепарсить, то не попадешь на данные второго канала. В конце первого канала шли спектральные данные, которые парсились каким-то очень сложным кодом... Но на его парсинг влиял sample rate.
Отсюда следует очевидное умозаключение - sample rate неправильный. Но я, как было написано раньше, свято верил слитым докам MG1264, в которых было написано, что самый маленький sample rate для аудио, который поддерживает кодек - 22050 герц.
Но в какой-то момент я от безнадеги таки взял и попробовал 16000 герц (индекс 8).
И ебать-колотить, что же я увидел? Конвертацию аудио без ошибок от ffmpeg! И что же я услышал? Громкие, четкие, стерео стоны ебущихся карликов!!!! Я смог!!!!!
В конвертер для qbox-ов добавилась новая фича - дописывать в начало стрима аудио-qbox с найденным мною конфигом.
![8 // A config audio qbox that we can prepend to a qbox stream from an ojd
9 const char config_audio_qbox[] = {
10 // BEGIN QBOX HEADER
11 0x00, 0x00, 0x00, OxlA, // box_size, 26 bytes
'q', 'b1, 'o', 'x', // box_type, magic number
13 0x00, 0x00, 0x00, 0x01, // box_flags, data-present flag set](https://img2.joyreactor.cc/pics/post/full/Иисус-geek-программирование-6900590.png "Иисус,Исусе,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,программирование,реактор помогающий,много букаф,Истории,длиннопост")
КАК Я ЕБАЛСЯ С ФРЕЙМРЕЙТОМ
Последней моей задачей было сделать конвертацию видео с нормальным фреймрейтом. Аудио каким-то образом отконвертилось идеально, но чтобы подогнать к нему по времени видео, пришлось подбирать вручную - выяснилось, что там был фреймрейт 25. Но откуда брался изначальный фреймрейт, который был похож на ебаное слайдшоу? Оказалось, что все дело было в демуксере, который зачем-то рескейлил дефолтные 90000 герц базовой шкалы тайминга на какую-то хуйню. Исправив сей огрех и пошаманив немножко с кодом таймстампов, я получил нормальную комбинацию аудио с видео, нормальный mp4 файлик, который уже можно было отправить заждавшемуся Иисусу!ЗАКЛЮЧЕНИЕ
Ебать это было весело. Я дохрена нового для себя узнал про мир аудио и видео энкодингов. И теперь умею немножко работать с ffmpeg! Ну и в кои-то веки есть что интересного рассказать реактору =) всем бобра, я пошел допроебывать свой отпуск!
Здесь мы собираем самые интересные картинки, арты, комиксы, мемасики по теме скачать mp4 фильмы (+1000 постов - скачать mp4 фильмы)
Отличный комментарий!