![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
thorneyedХорошо иметь непротиворечивую картину мира. Рано или поздно попытки сломать её с треском разбиваются без особых усилий с твоей стороны. Я ничего не отвечал на вбросы про дату ролика от СБУ, потому что был уверен в появлении вот такого текста, который вы прочитаете ниже. Уточню лишь, что писал это программист, сотрудник Гугла, которому принадлежит Ютуб. То есть, чувак вдвойне в теме - знает и предмет разговора и внутреннюю кухню своей конторы.
Оригинал взят у![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
avva в бритва хэнлона, временные метки и падение боинга
Оригинал взят у
avva в бритва хэнлона, временные метки и падение боингаЭто, наверное, первая запись в моем журнале с метками одновременно "программирование" и "политика".
Если вы следите за кризисом в Украине и в частности за падением малазийского "Боинга", то заметили, наверное, что украинское СБУ опубликовало запись переговоров сепаратистов вскоре после падения самолета. Видео была закачано на канал СБУ в Ютюбе всего через несколько часов после падения самолета. Люди заметили, что если скачать с Ютюба это видео, а потом посмотреть на видеофайл в какой-нибудь программе, которая показывает метаданные, то "дата создания" в файле оказывается 16-го июля, т.е. днем раньше собственно падения. Причем это не может быть разница в часовых поясах, потому что время почти на 24 часа раньше падения; отсюда люди заключили, что это доказательство того, что СБУ сделало фальшивые записи еще до катастрофы. Правда, другие люди вскоре заметили, что Ютюб поступает так с любым видео, которое в него загружают, и это видимо баг в Ютюбе. Так что теперь волнами по сети и оффлайновым СМИ расходятся разоблачение СБУ и разоблачение разоблачения.
Кажется, я разобрался, что это за баг. В видеоформате mp4 (стандарт MPEG-4) есть возможность записать "время создания" любого потока данных, с помощью специальной метки. Значение этой метки в стандарте - кол-во секунд, прошедших с 1 января 1904 года, или так называемое "время по эпохе макинтоша", потому что маки первыми стали использовать такой отсчет времени. Меж тем в современных серверах намного проще иметь дело с "временем по эпохе Юникса", а именно кол-вом секунд, прошедших с 1 января 1970 года. В результате этого во множестве программ, которые работают на Линуксе или других юниксовских операционных системах, есть кусок кода, который выглядит примерно так:
- получить "время сейчас по юниксу";
- добавить разницу между временем по юниксу и временем по макинтошу - это некая константа;
- полученное "время сейчас по макинтошу" записать в файл mp4, который мы создаем.
Чему равна константа "разница между временем по юниксу и временем по макинтошу"? Она равна в точности числу секунд, прошедших между 1 января 1904 и 1 января 1970. Это 66 лет, из которых 17 были високосными (проверьте, если не доверяете мне). Всего дней получается: 66*365+17 = 24107, а секунд, учитывая 86400 секунд в сутках: 24107*86400 = 2082844800. Это правильное значение константы.
Но есть маленькая крохотная незаметная проблемка. Часть стандарта MPEG-4 - исходники библиотек, которые умеют читать и писать mp4-файлы, так называемое "reference software" на C++, которым все могут пользоваться, чтобы позаимствовать или сравнить со своим кодом. Полное название этой части стандарта - "ISO/IEC 14496-5". Если вам интересно, вы можете скачать эту часть стандарта бесплатно с официального сайта. И если вы посмотрите на исходники, то увидите, что там используется другое значение этой константы, а именно 2082758400. Это ровно на 86400 секунд, то есть на одни сутки, меньше правильного значения.
Как случилось, что создатели MPEG-4 неправильно посчитали разницу между двумя датами? Может, кто-то вручную считал високосные годы и ошибся? Не знаю. Так или иначе, неправильное значение из-за его присутствия в стандарте попало во множество библиотек для чтения и записи видеоформатов. Постепенно в последние годы правильное значение начинает его сменять; если вы поищете в гугле оба числа, то увидите несколько точных описаний проблемы в исходниках нескольких проектов: "стандарт предлагает использовать 2082758400, но правильное значение 2082844800". В других проектах правильное значение стоит просто потому, что они сами посчитали, исходя из определений эпох, а не пользовались исходниками из стандарта.
Если в библиотеке, которая создает для вас mp4-файл, записано неправильное значение, то что произойдет, когда она захочет записать время "сейчас"? Она возьмет правильное число секунд по юниксу, добавит константу на сутки меньше, чем надо, и получит тем самым число секунд, согласно эпохе макинтоша, которое соответствует времени на сутки раньше. Я послал описание проблемы и решения разработчикам Ютюба, и надеюсь, что вскоре этот баг исчезнет.
Все в этом мире взаимосвязано. Кривые руки авторов стандарта MPEG-4 приводят к конспиративным теориям в украинском конфликте. Так и живем.
Если вы следите за кризисом в Украине и в частности за падением малазийского "Боинга", то заметили, наверное, что украинское СБУ опубликовало запись переговоров сепаратистов вскоре после падения самолета. Видео была закачано на канал СБУ в Ютюбе всего через несколько часов после падения самолета. Люди заметили, что если скачать с Ютюба это видео, а потом посмотреть на видеофайл в какой-нибудь программе, которая показывает метаданные, то "дата создания" в файле оказывается 16-го июля, т.е. днем раньше собственно падения. Причем это не может быть разница в часовых поясах, потому что время почти на 24 часа раньше падения; отсюда люди заключили, что это доказательство того, что СБУ сделало фальшивые записи еще до катастрофы. Правда, другие люди вскоре заметили, что Ютюб поступает так с любым видео, которое в него загружают, и это видимо баг в Ютюбе. Так что теперь волнами по сети и оффлайновым СМИ расходятся разоблачение СБУ и разоблачение разоблачения.
Кажется, я разобрался, что это за баг. В видеоформате mp4 (стандарт MPEG-4) есть возможность записать "время создания" любого потока данных, с помощью специальной метки. Значение этой метки в стандарте - кол-во секунд, прошедших с 1 января 1904 года, или так называемое "время по эпохе макинтоша", потому что маки первыми стали использовать такой отсчет времени. Меж тем в современных серверах намного проще иметь дело с "временем по эпохе Юникса", а именно кол-вом секунд, прошедших с 1 января 1970 года. В результате этого во множестве программ, которые работают на Линуксе или других юниксовских операционных системах, есть кусок кода, который выглядит примерно так:
- получить "время сейчас по юниксу";
- добавить разницу между временем по юниксу и временем по макинтошу - это некая константа;
- полученное "время сейчас по макинтошу" записать в файл mp4, который мы создаем.
Чему равна константа "разница между временем по юниксу и временем по макинтошу"? Она равна в точности числу секунд, прошедших между 1 января 1904 и 1 января 1970. Это 66 лет, из которых 17 были високосными (проверьте, если не доверяете мне). Всего дней получается: 66*365+17 = 24107, а секунд, учитывая 86400 секунд в сутках: 24107*86400 = 2082844800. Это правильное значение константы.
Но есть маленькая крохотная незаметная проблемка. Часть стандарта MPEG-4 - исходники библиотек, которые умеют читать и писать mp4-файлы, так называемое "reference software" на C++, которым все могут пользоваться, чтобы позаимствовать или сравнить со своим кодом. Полное название этой части стандарта - "ISO/IEC 14496-5". Если вам интересно, вы можете скачать эту часть стандарта бесплатно с официального сайта. И если вы посмотрите на исходники, то увидите, что там используется другое значение этой константы, а именно 2082758400. Это ровно на 86400 секунд, то есть на одни сутки, меньше правильного значения.
Как случилось, что создатели MPEG-4 неправильно посчитали разницу между двумя датами? Может, кто-то вручную считал високосные годы и ошибся? Не знаю. Так или иначе, неправильное значение из-за его присутствия в стандарте попало во множество библиотек для чтения и записи видеоформатов. Постепенно в последние годы правильное значение начинает его сменять; если вы поищете в гугле оба числа, то увидите несколько точных описаний проблемы в исходниках нескольких проектов: "стандарт предлагает использовать 2082758400, но правильное значение 2082844800". В других проектах правильное значение стоит просто потому, что они сами посчитали, исходя из определений эпох, а не пользовались исходниками из стандарта.
Если в библиотеке, которая создает для вас mp4-файл, записано неправильное значение, то что произойдет, когда она захочет записать время "сейчас"? Она возьмет правильное число секунд по юниксу, добавит константу на сутки меньше, чем надо, и получит тем самым число секунд, согласно эпохе макинтоша, которое соответствует времени на сутки раньше. Я послал описание проблемы и решения разработчикам Ютюба, и надеюсь, что вскоре этот баг исчезнет.
Все в этом мире взаимосвязано. Кривые руки авторов стандарта MPEG-4 приводят к конспиративным теориям в украинском конфликте. Так и живем.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-07-20 05:50 pm (UTC)...
Date: 2014-07-20 05:53 pm (UTC)no subject
Date: 2014-07-20 06:39 pm (UTC)no subject
Date: 2014-07-20 07:05 pm (UTC)no subject
Date: 2014-07-20 07:24 pm (UTC)no subject
Date: 2014-07-20 07:57 pm (UTC)no subject
Date: 2014-07-20 08:09 pm (UTC)no subject
Date: 2014-07-20 08:12 pm (UTC)Re: ...
Date: 2014-07-20 08:14 pm (UTC)no subject
Date: 2014-07-20 08:15 pm (UTC)no subject
Date: 2014-07-20 08:51 pm (UTC)no subject
Date: 2014-07-20 09:17 pm (UTC)Если он прав, то варианта два - или сии ЗРК просочились из Рашки (и тогда нужны ЖЕЛЕЗНЫЕ улики), либо кто-то ловил авиацию "зелёных человечков", а вышло как с той тушкой.
no subject
Date: 2014-07-20 09:38 pm (UTC)no subject
Date: 2014-07-20 09:46 pm (UTC)Что касается "преступной халатности", то до 8 км зона была закрыта, и это норма для всего мира. Летают и над Афганом, и над Сирией, и над Ираком - просто выше определённого эшелона. И только борцы за рузке мир умудрились захуячить гражданский борт.
И ещё раз: из РФ "просочился" как минимум блок "свой-чужой" (больше неоткуда). Также очень высока вероятность того, что российским был и расчёт. Бук - не ПЗРК, расчёты перед постановкой на боевое годами дрючат. Информации об украинских зенитчиках на стороне террористов нет. Откуда взялась сама пусковая машина - уже не так важно.
no subject
Date: 2014-07-20 09:52 pm (UTC)>> Кто вам сказал такую херню?
Вы уверены, что не перепутали ветку? Вопрос был адресован не вам.
no subject
Date: 2014-07-20 09:54 pm (UTC)ps: а от сьогодні наші війська "пройшли" рідне Рубіжне, забезпечивши мирне життя моїм батькам :)
no subject
Date: 2014-07-20 10:52 pm (UTC)no subject
Date: 2014-07-20 10:54 pm (UTC)Ну ок, простите.
no subject
Date: 2014-07-21 05:44 am (UTC)no subject
Date: 2014-07-21 09:04 am (UTC)И там тоже у террористов высотные ЗРК, а не банальные Стингеры и ЗУ?
>И ещё раз: из РФ "просочился" как минимум блок "свой-чужой" (больше неоткуда).
Или Буки были захвачены исправными, или вовсе не были захвачены - возможны варианты.
>Бук - не ПЗРК, расчёты перед постановкой на боевое годами дрючат.
Для ошибочной стрельбы как раз наоборот - обученных не надо. А ведь укроармия давно уже не торт - мне харьковские катаны говорили, что только при Кравчуке за ней худо-бедно следили.
>Откуда взялась сама пусковая машина - уже не так важно.
Откуда и чья - важно. Ибо обе стороны воюют одним и тем же оружием.