Я говорил о премиальном контенте с очень высоким битрейтом — в Вы мне про выбор формата, старые фильмы… автоснижение качества оно хорошо когда канал не монопольный и тем более если он беспроводной — а не потому что кто-то тут блондинка вне закона!
А вот про озвучки — это Вы правильно упомянеули — это тоже большой плюс пиратских раздач! ОЧЕНЬ большой плюс — когда есть возможность выбора разных озвучек — и когда есть возможность выбора более правильных озвучек, чем официальные — как бы не парадоксально это было. Да и в ру сегменте сейчас это единственный способ получить озвучки с нецензурной лексикой (ибо так они легко выходят в оригинале, но запрещены к оф. публикации в России) — для ценителей озвучки с правильным эмоциональным окрасом онлайн кинотеатры не подходят
Фильмы бывает проваливаются в кинотеатрах (но могут потом отбить прокат за счёт стриминга и телепоказа, или в кинотеатрах в других странах).
Фильмы не всегда вообще выходят в физических кинотеатрах
Вон в прошлом году в США долго физические кинотеатры были вообще закрыты (и не только в США они были закрыты) — ещё не известно что будет в следующем году!
Фильмы в разных странах выходят в прокат в разное время — это вообще большая проблема правообладателей
В реальном времени смотреть Torrent-TV можно только с невысоким битрейтом. Но если есть толстый канал (за который надо платить больше) можно конечно смотреть очень популярны торрент файлы — вот только редко таковыми бывают файлы с высоким битрейтом (4K HDR 10Bit весят обычно 25Гб за час видео и имеют не так уж много сидов, да ещё и без проблем с NAT, чтобы эффективно отдавать такой поток — да ещё и не одному клиенту; а именно о защите премиального контента тут в статье в первую очередь и говорили). А по беспроводной сети тут ещё и периодические лаги будут жуткие. А автоматически снизить качество компрессии источники не смогут, а в отличии от онлайн кинотеатров
Стриминговые кинотеатры мне не нравятся лишь одним — ограниченностью континента: ни у кого нет полной коллекции даже общего контента + есть эксклюзивный контент каждого сервиса, который они не спешат передавать другим. И это очень печально. Был бы общий сервис, у которого было бы всё (включая развлекательные и другие передачи ) в любое удобное время без рекламы — не пожалел бы и 1.5 косаря рублей в месяц хотя бы за FHD (смотреть большее через стриминг нужно иметь очень толстый канал — иначе очень сильная компрессия; а толстый канал получить по мобильной связи, например, почти нереально за городом — хотя тут есть спутниковое вещание конечно). За 500 руб вообще был бы здорово — даже если бы весь контент появлялся не сразу — а с задержкой, в 1-2 года от эксклюзивной премьеры. Покупать контент по отдельности — уже будет слишком дорого! Самый близкий такой сервис по сериалам — наверное будет только Амедиатека
Для уникального видео смотри мой пост выше (и тут уже тоже предалагли этот вариант вчера) — про случайный шум + блур + шарп + двойное перекодирование — вотермарк будет с большой вероятностью искажён до неузнаваемости без его фактического поиска.
Либо, как тут, уже писали, с одного источника можно снять несколько изображнений в разное время, с разных IP и эккаунтов, и с чистым кешем — водяные знаки идентификации пользователя будут разные — можно сравнивать — 3-х таких источников будет вполне достаточно для надёжного тройного сравнения. Но не годится для уникального источника, который доступе пирату в одной копии (например слив с уникального показа в кинотеаторе) — тогда способом выше пытаемся исказить вотермарк без его поиска
Какая-то пустая статья. Слов много. Толку мало. Ни про принципы работы DRM практически не рассказали, ни про водяные знаки — в общем — техническая составляющая почти нулевая — больше похоже на страшилку для пиратов-дилетантов, чтобы отпугнуть оных от наивного копирования контента кинотеатров. Возможно в этом то и был весь посыл статьи. А если бы тут была техничка — то это скорее было бы подспорье для пиратов — впрочем пираты сами найдут нужные источники — где это всё более детально изложено как и источники где написан как это всё обходить!
Смысл такого взлома в том, чтобы как раз найти эти вотермарки — они будут либо найдены, либо алгоритм надо дорабатывать. Комбинировать оба видео, наверное не будут (хотя это самое простое решение), выкладывать будут только с одного источника, вырезав с него найденные вотермарки. Если не найдут — то не выложат.
Ещё вариантом атаки может быть как раз комбинация двух источников + наложение случайного полнокадрового шума тоже как невидимого вотермарка + дополнительная обработка с комбинированием двух кадров одного с размытием другого с шарпом — конечно это может чуть ухудшить качество картинки — зато вполне себе затрёт любой невидимый вотермарк. В общем вотермарки не так уж хорошо защищают — технология старая и профессионалы давно уже научились её обходить. Но вот дилетантов-пиратов вотермарки должны хорошо сдерживать
Чтобы «не слышать нигде и никогда» — это только закопать (хотя пример Умы Турман говорит что и этого не достаточно).
На самом деле давить на таких производителей бесполезно (тем более, что все они обычно забугорные), даже если «закапать такого», завтра его местой займёт другой такой же (и скорее всего с тем же источником финансирования и управления). Давить надо на магазины — которые в погоне за дешевизной плюют на качество того, что реализуют!
Я объяснил на всякий случай. Ведь речь не идёт о знакомом синтаксисе Python
На мой взгляд — строчки весьма понятны и без пояснения. Я пояснил — скорее для того, чтобы показать всю глубину заложенной смысловой логики
Причём можно сократить без снижения ясности и заменить оператор "->" командой «to», а команду «undone» на команду «empty»
array to
filter(matches) to do_job_with
epmty to no_matched_found
Здесь элементы из источника «array» автоматически направляются в первый аргумент функций (когда он есть) — это техника подсмотрена в языке Kotlin.
А обращение к имени функции без круглых скобок автоматически приравнивается к получению адреса (когда не нужно явно указывать связь со значениями аргументов — а в данном случае единственный аргумент передаётся автоматически).
В таком виде читаемость почти идеальна — даже если не вникать в тонкости семантики языка
Не знаю, почему мой более короткий код Вам показался менее читабельным. Мне кажется это больше дело привычки. «Старая школа» любит классическое ветвление и блоки циклов. Новая — вполне может отдавать предпочтение лямбда-функциям и функциям-расширениям, с отложенным вычислением. Просто у такой модели больше возможностей для автоматической оптимизации и универсальности кода, которому не важно что и как он обрабатывает (вся логика скрывается в реальных типах задействованных классов). Так же на восприятие влияет и цветовая раскраска и форматирование.
Мне, вот, Ваш пример кажется куда более корявым и трудночитаемым. Всё Ваше объяснение про многосторонность — не более чем полемика почему «оранжевый код краше синего», хотя да — тут «ноги растут» из определённых традиций стилистики программирования на языке Python. Я лишь пытался порассуждать над красотой к которой, по моему-мнению, надо бы стремиться. Но с Python тут уже ничего не поделаешь — в нём много заложено такого, что, например мне не нравится, и это уже его коренные черты (но всегда найдутся те — кто яро будет защищать их самобытность и красоту).
А насчёт мгногострочного кода — тут да — ничего не поделаешь — только упаковывать в анонимные лямда-функции раз Python такой специфический в этом плане — что мне больше всего в нём не нравится — прям категорически! Но в указанном примере всё уже было упаковано — поэтому, именно для него я и привёл свой вариант.
Вот так могло бы быть ещё красивее (а может и нет, многое зависит от привычки, но не всегда и после привыкания получается удобство) — будь такая поддержка (совсем не Python):
(не знаю как тут сохранить правильную табуляцию — но она не принципиальна — не Python же, к счастью)
Построчное пояснение:
1. Открываем чтение поток поэлементного чтения из источника «array», позиция чтения в «el»
2. Вызываем команду «filter» у открытого потока чтения (если поддерживается), передаём ей ссылку на некий предикат «matches» (через оператор получения адреса "@"), в данном случае, вероятно функцию (хотя кто его знает, что это на самом деле — может декларативное описание выражение фильтра — что предпочтительнее — так как его можно оптимизированно использовать, ускорив фильтрацию, например за счёт грамотного применения имеющихся индексов у источника потока). С предикатом связывается переменная элементов потока «el» — так же через получение адреса (что гарантирует, что будет передача будет по ссылке, а не сразу будет закреплено за входящим аргументом текущее значение переменной). После чего получаем модифицированный поток.
3. Передаём элементы потока в предикат обработки «do_job_with» (опять-таки, мы не знаем, что это, но пусть для простоты будет функция). Передача «el» так же по ссылке, а не текущее значение перед началом обработки.
4. Вызываем команду «undone» (всегда доступна у потоков) — если вызов ни одной из предыдущих команд (в данном случае «filter»; а их, может быть несколько) не вернули результат. Она передаст поток в дальнейшую обработку и вызовет предикат «no_matched_found»
Итого имеем очень высокую абстракцию кода, при сохранении достаточно выского уровня читаемости и понимания заложенной логики, и сокрытия реальных процессов обработки данных (но так и задумано).
А многостронные уструкции просто размещаем в классических фигруных скобках "{ }" (как уже сказал — это совсем не Python и даже не C++/C# — это уже скорее пример некоего абстрактного программирования на квазиязыке 5-го поколения)
«undone» намеренно ввёл вместо «else» или "?"/"??" что бы не смешивать их синтаксические конструкции с командами обработки потоков. Команды — не являются зарезервированными словами. А внутри их блоков могут применятся указанные зарезервированные слова для организации какого-то ветвления и проверки условий.
Возможно «undone» лучше было бы назвать «defaut» — усиливая аналогию с паттерн метчингом — ведь тут команды именно так обрабатываются — перебираются пока их паттерн не сработает. Но мне тут просто не очень нравится само слово «default» — оно больше ассоциируется у меня со значениями по умолчанию, чем с ветвлением (хотя и используется «испокон веков» в «switch» конструкциях). Возможно были бы более «красивыми» такие слова как "_", «another», «any», «nothing» или даже просто ввести отдельную команду «empty» — это всё к семантики данного выражении не имеет отношения — это всё элементы архитектуры конкретной реализации интерфейса потока «array»
C# — очень неплохой язык. Ему бы ещё сбросить груз наследия языка Си/С++ — вообще было бы здорово — но это уже не возможно. Но… C# — это платформа .NET — тут можно создать свой язык — покруче чем C# (правда мода на это уже прошла, из относительно популярных языков — только F# от тех же Мелко мягких назвать могу, кстати IronPython для .NET был, в своё время, как и Python for .NET)
Это вот как так можно аккуратно удалить зуб, без повреждений (с минимальными повреждениями), если он коренной. Не ну профи зубы выбивают будь здоров — но либо они должны сломаться, либо у клиента и так проблемы с зубами, что они так плохо сидят в своих местах, что скоро все сами выпадут
Для этого в Python изначально была заложена «функциональность» описательных комментариев в начале функций. Если их нет в исходниках (или они не корректно написаны) — то аннотации типов не спасут — их так же могут не сделать. Если IDE не может правильно извлекать информацию о типах аргументов из этого описания — то это уже проблема IDE, а не языка.
А вообще — базовая динамическая типизация — это плохое решение (увы, свойственное многим интерпретируемым ЯП) — это, по большей части — пережитки прошлого (плохой дизайн). Лучше иметь статическую типизацию + выведение типов + составные типы + возможность в отдельных редких случаях иметь возможность объявлять динамическую переменную + иметь тип что-то на подобии Variant — для хранения и передачи уж очень динамических значений
По-моему откровенно дурацкая и почти бесполезная реализация else в цикле for (и почему только в for?). На мой взгляд — куда полезнее было — если бы в секцию «else» цикл входил в случае если не разу не выполнился (это бы как раз соответствовало оператору ветвления if — если условие выполнилось — значит переход в тело; не выполнилось — переход в else — просто для цикла переход в else уместен только на первой итерации, а у if второй итерации и быть не может — значит, аналогично, уместно только для первой). Вот такой логике else у цикла (причём любого) можно было бы найти применение (эмулировать, конечно, аналогично можно, как и показано в статье)
Я могу предположить, что самая большая проблема — это как раз сборка в космосе. Это должны делать космонавты, и за 24 часа они это не сделают — а дальше… дальше (а скорее, уже через 8 часов непрерывной работы) им нужно возвразаться на какую-то базу. Либо на Землю — что не эффективно. Либо на МКС — что тоже не особо эффективно — т.к. там мало места и производить сборку вблизи станции не безопасно. Либо на отдельный корабль — как рабочую бытовку. Раньше для этих целей использовали шатлы — сейчас их нет. Возможно Старшип для этого сгодился бы — вопрос только, поднимется ли он на достаточную орбиту — т.к. сборку нужно производить где-то выше орбиты МКС. Ну, можно вернуться к старой схеме — одно-двухмодульных станций как «Салют» или Skylab- где рабочие могли бы «переспать» до следующей вахты. Ну или начинать нужно с постройки отдельной новой космической станции типа МКС-2 — специализирующейся на строительной поддержке.
А грузы — их проще доставлять Протонами или Heavy Falcon'ами — они мощнее Союзов.
Вот только это всё денег не малых стоит — и никто в это вкладываться не намерен — пока и на Земле хлопот хватает… нужно к войне готовиться
Как пользовались зумом так и будут пользоваться — а отечественным компаниям как было сложно пробиться в госсектор так и будет сложно и впредь (ну разве что как всегда — хорошие инвестиции в чиновников не сдвинут дело с мёртвой точки)
Плохо, что не написали плюсы и минусы альтернативрных сервисов, да и самого зума, причём отдельно для платных и бесплатных возможностей (т.к. порой они разительно отличаются); и не провели сравнение цен; а самое главное, ни слова не сказали про качество сервисов — а ведь тут (особенно для госструктур) надёжность и защищённость — превыше всего (а то зум постоянно ломают, вон, недавно нидерландский журналист пробрался в секретный видеочат военных евросоюза). А для взаимодействия с населением ещё важно и качество связи на плохих каналах (не везде же гигабитная сеть в Интернет как в Кремле) — и тут многое зависит от уровня сжатия медиапотока, да и всего протокола передачи данных
А вот про озвучки — это Вы правильно упомянеули — это тоже большой плюс пиратских раздач! ОЧЕНЬ большой плюс — когда есть возможность выбора разных озвучек — и когда есть возможность выбора более правильных озвучек, чем официальные — как бы не парадоксально это было. Да и в ру сегменте сейчас это единственный способ получить озвучки с нецензурной лексикой (ибо так они легко выходят в оригинале, но запрещены к оф. публикации в России) — для ценителей озвучки с правильным эмоциональным окрасом онлайн кинотеатры не подходят
Фильмы не всегда вообще выходят в физических кинотеатрах
Вон в прошлом году в США долго физические кинотеатры были вообще закрыты (и не только в США они были закрыты) — ещё не известно что будет в следующем году!
Фильмы в разных странах выходят в прокат в разное время — это вообще большая проблема правообладателей
Либо, как тут, уже писали, с одного источника можно снять несколько изображнений в разное время, с разных IP и эккаунтов, и с чистым кешем — водяные знаки идентификации пользователя будут разные — можно сравнивать — 3-х таких источников будет вполне достаточно для надёжного тройного сравнения. Но не годится для уникального источника, который доступе пирату в одной копии (например слив с уникального показа в кинотеаторе) — тогда способом выше пытаемся исказить вотермарк без его поиска
Ещё вариантом атаки может быть как раз комбинация двух источников + наложение случайного полнокадрового шума тоже как невидимого вотермарка + дополнительная обработка с комбинированием двух кадров одного с размытием другого с шарпом — конечно это может чуть ухудшить качество картинки — зато вполне себе затрёт любой невидимый вотермарк. В общем вотермарки не так уж хорошо защищают — технология старая и профессионалы давно уже научились её обходить. Но вот дилетантов-пиратов вотермарки должны хорошо сдерживать
На самом деле давить на таких производителей бесполезно (тем более, что все они обычно забугорные), даже если «закапать такого», завтра его местой займёт другой такой же (и скорее всего с тем же источником финансирования и управления). Давить надо на магазины — которые в погоне за дешевизной плюют на качество того, что реализуют!
На мой взгляд — строчки весьма понятны и без пояснения. Я пояснил — скорее для того, чтобы показать всю глубину заложенной смысловой логики
Причём можно сократить без снижения ясности и заменить оператор "->" командой «to», а команду «undone» на команду «empty»
array to
filter(matches) to do_job_with
epmty to no_matched_found
Здесь элементы из источника «array» автоматически направляются в первый аргумент функций (когда он есть) — это техника подсмотрена в языке Kotlin.
А обращение к имени функции без круглых скобок автоматически приравнивается к получению адреса (когда не нужно явно указывать связь со значениями аргументов — а в данном случае единственный аргумент передаётся автоматически).
В таком виде читаемость почти идеальна — даже если не вникать в тонкости семантики языка
Мне, вот, Ваш пример кажется куда более корявым и трудночитаемым. Всё Ваше объяснение про многосторонность — не более чем полемика почему «оранжевый код краше синего», хотя да — тут «ноги растут» из определённых традиций стилистики программирования на языке Python. Я лишь пытался порассуждать над красотой к которой, по моему-мнению, надо бы стремиться. Но с Python тут уже ничего не поделаешь — в нём много заложено такого, что, например мне не нравится, и это уже его коренные черты (но всегда найдутся те — кто яро будет защищать их самобытность и красоту).
А насчёт мгногострочного кода — тут да — ничего не поделаешь — только упаковывать в анонимные лямда-функции раз Python такой специфический в этом плане — что мне больше всего в нём не нравится — прям категорически! Но в указанном примере всё уже было упаковано — поэтому, именно для него я и привёл свой вариант.
Вот так могло бы быть ещё красивее (а может и нет, многое зависит от привычки, но не всегда и после привыкания получается удобство) — будь такая поддержка (совсем не Python):
(el <- array) ->
filter(@matches(@el)) ->
do_job_with(@el)
undone -> no_matched_found
(не знаю как тут сохранить правильную табуляцию — но она не принципиальна — не Python же, к счастью)
Построчное пояснение:
1. Открываем чтение поток поэлементного чтения из источника «array», позиция чтения в «el»
2. Вызываем команду «filter» у открытого потока чтения (если поддерживается), передаём ей ссылку на некий предикат «matches» (через оператор получения адреса "@"), в данном случае, вероятно функцию (хотя кто его знает, что это на самом деле — может декларативное описание выражение фильтра — что предпочтительнее — так как его можно оптимизированно использовать, ускорив фильтрацию, например за счёт грамотного применения имеющихся индексов у источника потока). С предикатом связывается переменная элементов потока «el» — так же через получение адреса (что гарантирует, что будет передача будет по ссылке, а не сразу будет закреплено за входящим аргументом текущее значение переменной). После чего получаем модифицированный поток.
3. Передаём элементы потока в предикат обработки «do_job_with» (опять-таки, мы не знаем, что это, но пусть для простоты будет функция). Передача «el» так же по ссылке, а не текущее значение перед началом обработки.
4. Вызываем команду «undone» (всегда доступна у потоков) — если вызов ни одной из предыдущих команд (в данном случае «filter»; а их, может быть несколько) не вернули результат. Она передаст поток в дальнейшую обработку и вызовет предикат «no_matched_found»
Итого имеем очень высокую абстракцию кода, при сохранении достаточно выского уровня читаемости и понимания заложенной логики, и сокрытия реальных процессов обработки данных (но так и задумано).
А многостронные уструкции просто размещаем в классических фигруных скобках "{ }" (как уже сказал — это совсем не Python и даже не C++/C# — это уже скорее пример некоего абстрактного программирования на квазиязыке 5-го поколения)
«undone» намеренно ввёл вместо «else» или "?"/"??" что бы не смешивать их синтаксические конструкции с командами обработки потоков. Команды — не являются зарезервированными словами. А внутри их блоков могут применятся указанные зарезервированные слова для организации какого-то ветвления и проверки условий.
Возможно «undone» лучше было бы назвать «defaut» — усиливая аналогию с паттерн метчингом — ведь тут команды именно так обрабатываются — перебираются пока их паттерн не сработает. Но мне тут просто не очень нравится само слово «default» — оно больше ассоциируется у меня со значениями по умолчанию, чем с ветвлением (хотя и используется «испокон веков» в «switch» конструкциях). Возможно были бы более «красивыми» такие слова как "_", «another», «any», «nothing» или даже просто ввести отдельную команду «empty» — это всё к семантики данного выражении не имеет отношения — это всё элементы архитектуры конкретной реализации интерфейса потока «array»
или даже такой (для данного примера)
Простите за мой квази-Python который уже и не Python вовсе
А вообще — базовая динамическая типизация — это плохое решение (увы, свойственное многим интерпретируемым ЯП) — это, по большей части — пережитки прошлого (плохой дизайн). Лучше иметь статическую типизацию + выведение типов + составные типы + возможность в отдельных редких случаях иметь возможность объявлять динамическую переменную + иметь тип что-то на подобии Variant — для хранения и передачи уж очень динамических значений
А грузы — их проще доставлять Протонами или Heavy Falcon'ами — они мощнее Союзов.
Вот только это всё денег не малых стоит — и никто в это вкладываться не намерен — пока и на Земле хлопот хватает… нужно к войне готовиться