Это же катастрофически неправильно. 12:00 в соседней таймзоне это не 12:00 же.
Или обратное: То есть юзер создал в 12:00 запись. Потом мгновенно переместился в соседнюю таймзону и создал запись и у вас в БД запишется две записи:
12:00
13:00
И потом он будет видеть эти два времени в таком виде из любой таймзоны? Несмотря на то, что на самом деле это одно и то же время?
Теперь более реальный случай: юзер из Челябинска (+05:00) такой в 12:00 создал запись и видит 12:00, о, думает всё нормально. А теперь в эту же запись (в это время или же назаватра) смотрит юзер из Москвы (+03:00) и какое время он видит то? 12:00 что ли? Если 12:00, то это жесть полная. Если 10:00 то как раз в этом вопрос — непонятно как это сделано, если, блин, вы не знаете что такое 12:00 на самом деле и в какой таймзоне («локальное время пользователя»).
Не, я просто ещё раз прочитал всё, и не могу понять — у вас в конкретной колонке в БД в каком виде лежит время? Во всех в «московской таймзоне» а вы просто во вьюхах его конвертируете и отдаёте наружу? Просто вот это конкретно сбивает с толку: «Благодаря этому, во всех записях в БД всегда будет проставляться время пользователя, а не московское». Все именно от этого в ужас пришли. Это надо подробнее объяснить вам, потому что не верится в такое.
У юзера сейчас рисуется допустим 12:00 для какой-то сущности, если юзер меняет таймзону (допустим соседнюю на час) то он увидит теперь везде 13:00? Правильно же? Тогда как это делается с учётом, что в БД неизвестное время неизвестной таймзоны?
Это не сложно, это единственный правильный путь работы со временем.
Это должно делаться (и у всех делается) в одном месте — в той или иной прослойке, которая у вас работает с БД. В большинстве бд-фреймворках/орм итд всё это есть искаропки, конечно, потому что по-другому просто нельзя.
В этом случае там будет время по МСК? Или принимать данные извне как?
Пусть хоть по тихоокеанскому, время никогда нельзя передавать, обрабатывать и хранить без привязанной таймзоны (или подразумевания что там UTC, что очевидно для случая, например, типа unixtime). Нет понятия «время по МСК», время оно и есть время — просто временной штамп. По МСК оно может стать при показе его в этой таймзоне. Нет, можно и передавать его по МСК и даже хранить (только непонятно зачем), но надо тогда так и оперировать везде «01.02.2016 22:22:58; МСК», потому что нет времени «01.02.2016 22:22:58» — это не время, а билиберда.
Так же всё и про «принимать извне».
И это не сложно проверить, например, откройте любой ролик на ютюб или иксвидиос, прям таки минутами ждешь когда ролик подгрузится.
Это к чему вообще? Причём тут «подгрузится», если речь о live-стриминге и low latency в нём.
Так что нет, не переубедили, потому что вариантов вы не предложили никаких, не говоря уж о том, что вы как-то крайне превратно поняли моё сообщение. На флеше не надо ничего этого вашего сложного реализовывать, там фактически всё это сделано нативно. Я написал «к сожалению» неспроста, и флеш тут только потому, что других вариантов браузерных rtmp-клиентов тупо не бывает. И даже типа pure-js плееры, которые играют rtmp используют в глубине флешовую прослойку. У вас есть другие подходящие варианты как без гемора и велосипедов?
Вы решаете проблему, которая возникла из-за того, что вы (или кто-то) что-то неправильно делали изначально. Зачем вообще надо хранить время в любом локальном (naive, не-aware, итд) времени, вот как должен вопрос ставиться. Если датавремя представляет конкретную точку во врмени, то оно всегда должно храниться в БД вместе с таймзоной, либо просто подразумеваться UTC (что предпочтительнее и не отменяет первого варианта).
Попробуйте ставить «режим экономии заряда» перманентный (я в настройки в шторку вытаскивал в wp8, в wp10 там все эти квадратики и так есть). За 2-3 дня просто лежания должно несколько процентов тратиться.
В общем, примерно понятно, что надо больше в сторону WebSocket смотреть. А есть вообще что-то такое адекватное и готовое, можно платное? Т.к. про то и говорю, что цельных технологий и решений нет и у всех всё «своё»)
При этом не один из браузеров не успевает обрабатывать относительно короткие фрагменты.
Я вот например на самом низком уровне конвертируюю SDP в Jingle, и вообще с SDP не роботаю, и знать не знаю.
Не очень понятно джингл тут причём. Вы его используете вместе с webrtc?
Вы пытаетесь терминами играть зачем-то, SDP «делает установку сессии» настолько, насколько это понятие применимо для протокола прикладного уровня.
В данном контексте SIP это как раз протокол установления сеанса. И в WebRTC как раз сеанс устанавливается именно точно так же SIP/SDP. И webrtc на тот же SDP жёстко завязан. Который при согласовании уже летает по внешнему signaling протоколу, любому, к которому уже WebRTC равнодушен. Вот то, что WebRTC это не только «SIP в браузере»- это верное замечание.
А вы пробовали играть однофрагментный плейлист HLS? Он постоянно будет затыкаться же и дёргаться. Я пробовал, пройденный этап, всякие готовые решения типа videojs-hls итд очень плохо это переваривают — короткие фрагменты, короткий плейлист итд. Сама по себе суть этой технологии и этого метода, а именно — постоянно зачитываем плейлист (а это отдельные xhr запросы не забываем!), вычитываем новые кусочки (запросы, запросы, http, http, http, http, http), демуксим их в буфер, суём MSE, играем — подразумевает, что без некоторого буфера нереально обойтись. И буфер тут помимо секунд в кол-ве кусочков ещё, т.к. http, как вы понимаете, не очень-то low latency live сам по себе. А если ещё вдруг канал не очень…
Вот про вебсокеты итд это уже интереснее. Это кое-что мы смотрели, вроде где-то на хабре даже было подобное. Нет, на самом деле есть решения разного рода велосипедности. И вебсокетами видел что просто тянут тупо сырой mp4 (ну или тоже чанками, не помню) итд итп. Речь тут больше о стандартных технологиях будущего, нативности. beam.pro посмотрим, спасибо, не видел. А есть ещё какие-то такие же готовые решения типа фреймворков в виде серверная часть + спец. плеер?
Именно так, для ТВ это прекрасные технологии (огромный плюс что не надо даже медиасерверов теперь для всяких VOD; ну и плюс CDN и вот это всё, круто), а вот для чатиков, онлайн-стримов, «скайпа в браузере» итд — технологии никакие.
Да, про WebRTC ещё забыл к rtmp добавить, конечно. Но здесь 1) пока проблема с поддержкой, хуже чем флеш, но лучше тем, что там где есть это нативно 2) плюс некоторая всё костыльность (но на это можно закрыть глаза). Так что, видимо, за ним всё же пока видится low latency будущее.
Определенно, MPEG-DASH — самый настоящий HTML5-стриминг, за ним будущее.
Всё это круто звучит. И да, для DASH, как и для HLS есть немало решений для нативного проигрывания в большинстве браузеров, тот же video.js. Ну и референсную реализацию dash.js надо упомянуть. И даже стабильно работает. Одна проблема — чтобы добиться адекватной (низкой) задержки нужно очень много плясать с бубном. И в итоге обломиться. И речь здесь не о секундах, а о десятках(!) секунд в дефолтных случаях. Издержки обеих технологий, от которых избавиться не получается. Так что, к сожалению, лучше rtmp для low latency live streaming на данный момент ничего нет и в ближайшем будущем не видно. И, как следствие, здесь снова речь про флеш, раз мы говорим об «rtmp в браузере». Буду очень признателен, если кто-то переубедит, проблема не праздная.
Любопытный нюанс: нельзя менять пакет между вызовами createOffer/createAnswer и setLocalDescription.
Вот это непонятно — а почему именно так? То есть как бы мы своей стороне даём реальный sdp, а фейковый — партнёру, т.е. обманываем обе стороны, как будто вторая сторона прислала настоящий sdp, но на самом деле он с подрезанными параметрами? Но почему нельзя себе ставить такой — вот это интересно)
Я пытался в своём проекте кодеки там ковырять в sdp, где-то примеры были в интернете, но как-то не вышло там нормально.
Ещё у вас код дублируется в каждом примере почему-то.
Речь и не про сейчас, а про события нескольколетней давности. Рег мне подарили, везти его хз куда (в соседний город) в СЦ с нечёткими проблемами отличными от «вообще не работает»?
Мой экземпляр имел(ет) такие проблемы: заполняется карта залочеными файлами, как причина (возможно) то что датчик удара вообще неадекватно ведёт себя, как следствие отваливается запись видео в любой момент, почти никогда не стартует GPS, сразу отвалился разъём питания (у товарища с другой моделью тоже отвалился), разъём вообще в принципе очень плохой и провод постоянно отходил, крайне плохая батарейка (на 1-2 минуты с полной зарядки через пару месяцев). И ещё по мелочам чего уже не припомню. Через полгода он у меня был замотан изолентой вместе с проводом и пропаян. Про кач-во сборки я вообще молчу — китай китаем, gps вообще одним проводом был припаен и болтался на подложке из фольги (тут не уверен, может так должно быть).
Про прошивки итд писать мне сейчас нет смысла — я перепробовал несколько штук. Что уже лично для меня тревожный признак, т.к. если ПРИХОДИТСЯ прошивать девайс, да ещё по нескольку раз, то это уже жесть. Тем более(!) для той ниши, в которую вы себя типа позиционируете. В каментах там к этой модели конкретно 70% проблем одни и те же и все бугуртят. Вы бы лучше там пользователям отвечали, мне то сейчас уже чего смысл писать. Ну, может и надо было везти в СЦ, вы правы, да как-то надеялся видимо на прошивки, на паяльник и на дарёного коня. Вы поймите, что речь про всякие такие косячки, которые позволяли пользоваться, но периодически бесили. Особенно с учётом, что девайсы у вас типа «не бюджетные» как вы сами говорите, ещё раз укажу отдельно на это, потому что 90% претензии мои и остальные именно про это.
Плюс, здесь не раз и не два мелькала информация от владельцев о том, что прошивки имеют проблемы, которые по два года не закрываются.
Проблемы прошивок вообще часто не закрываются. У меня есть FD4 GPS, как он немножко то там то сям не работал, так и глючит до сих пор. А прошивок давно уже нет и не будет. И судя по срачу на оф.сайте проблемы у всех такие. Ну, разъём питания почти сразу отвалился, GPS почти никогда не стартует и т.д. — это по мелочам. Потому всегда тут забавно читать про «не совсем уж дешёвые регистраторы» с на самом деле типично китайским качеством и поддержкой.
А потом, что значит — "… возникли и отладились эволюционно."?
Это значит, что муравьи понятия не имеют зачем они всё это делают. Следовательно, термины «планирование», «знание» и т.д. тут в принципе неприменимы. Также как обычные муравьи не понимают зачем они делают всё — строят муравейник, таскают личинок, кормят матку, пополняют запасы на зиму итд. Всё это тоже можно назвать «долговременной стратегией», просто не так похоже на осознанные действия типа выращивания рассады. Хотя по сути разница небольшая.
муравьи случайно или специально вывели такую форму
и т.д. Нет у муравьёв никаких подобных «знаний» и специально они вывести не могут ничего. Все эти процессы, очевидно, возникли и отладились эволюционно.
такое явление, как оверкодинг <...> слишком много кода и возможностей <...> приводит к повышению сложности всей системы <...> не только пользователям, но очень часто даже программистам сложно разобраться в юзабилити программных продуктов <...> К сожалению, этот недостаток является оборотной стороной мощных и многофункциональных решений
Да вообще-то нет, этот недостаток — по большей части следствие невероятно говённой архитектуры. В мире есть множество крупных программных продуктов, масштабных, «мощных и многофункциональных», которые не сильно страдают от этих странных описанных проблем.
Или обратное: То есть юзер создал в 12:00 запись. Потом мгновенно переместился в соседнюю таймзону и создал запись и у вас в БД запишется две записи:
12:00
13:00
И потом он будет видеть эти два времени в таком виде из любой таймзоны? Несмотря на то, что на самом деле это одно и то же время?
Теперь более реальный случай: юзер из Челябинска (+05:00) такой в 12:00 создал запись и видит 12:00, о, думает всё нормально. А теперь в эту же запись (в это время или же назаватра) смотрит юзер из Москвы (+03:00) и какое время он видит то? 12:00 что ли? Если 12:00, то это жесть полная. Если 10:00 то как раз в этом вопрос — непонятно как это сделано, если, блин, вы не знаете что такое 12:00 на самом деле и в какой таймзоне («локальное время пользователя»).
У юзера сейчас рисуется допустим 12:00 для какой-то сущности, если юзер меняет таймзону (допустим соседнюю на час) то он увидит теперь везде 13:00? Правильно же? Тогда как это делается с учётом, что в БД неизвестное время неизвестной таймзоны?
Это должно делаться (и у всех делается) в одном месте — в той или иной прослойке, которая у вас работает с БД. В большинстве бд-фреймворках/орм итд всё это есть искаропки, конечно, потому что по-другому просто нельзя.
Пусть хоть по тихоокеанскому, время никогда нельзя передавать, обрабатывать и хранить без привязанной таймзоны (или подразумевания что там UTC, что очевидно для случая, например, типа unixtime). Нет понятия «время по МСК», время оно и есть время — просто временной штамп. По МСК оно может стать при показе его в этой таймзоне. Нет, можно и передавать его по МСК и даже хранить (только непонятно зачем), но надо тогда так и оперировать везде «01.02.2016 22:22:58; МСК», потому что нет времени «01.02.2016 22:22:58» — это не время, а билиберда.
Так же всё и про «принимать извне».
Так что нет, не переубедили, потому что вариантов вы не предложили никаких, не говоря уж о том, что вы как-то крайне превратно поняли моё сообщение. На флеше не надо ничего этого вашего сложного реализовывать, там фактически всё это сделано нативно. Я написал «к сожалению» неспроста, и флеш тут только потому, что других вариантов браузерных rtmp-клиентов тупо не бывает. И даже типа pure-js плееры, которые играют rtmp используют в глубине флешовую прослойку. У вас есть другие подходящие варианты как без гемора и велосипедов?
Попробуйте ставить «режим экономии заряда» перманентный (я в настройки в шторку вытаскивал в wp8, в wp10 там все эти квадратики и так есть). За 2-3 дня просто лежания должно несколько процентов тратиться.
Э… это непонятно. Имеете в виду в виде hls если?
Вы пытаетесь терминами играть зачем-то, SDP «делает установку сессии» настолько, насколько это понятие применимо для протокола прикладного уровня.
Вот про вебсокеты итд это уже интереснее. Это кое-что мы смотрели, вроде где-то на хабре даже было подобное. Нет, на самом деле есть решения разного рода велосипедности. И вебсокетами видел что просто тянут тупо сырой mp4 (ну или тоже чанками, не помню) итд итп. Речь тут больше о стандартных технологиях будущего, нативности. beam.pro посмотрим, спасибо, не видел. А есть ещё какие-то такие же готовые решения типа фреймворков в виде серверная часть + спец. плеер?
Да, про WebRTC ещё забыл к rtmp добавить, конечно. Но здесь 1) пока проблема с поддержкой, хуже чем флеш, но лучше тем, что там где есть это нативно 2) плюс некоторая всё костыльность (но на это можно закрыть глаза). Так что, видимо, за ним всё же пока видится low latency будущее.
Я пытался в своём проекте кодеки там ковырять в sdp, где-то примеры были в интернете, но как-то не вышло там нормально.
Ещё у вас код дублируется в каждом примере почему-то.
Мой экземпляр имел(ет) такие проблемы: заполняется карта залочеными файлами, как причина (возможно) то что датчик удара вообще неадекватно ведёт себя, как следствие отваливается запись видео в любой момент, почти никогда не стартует GPS, сразу отвалился разъём питания (у товарища с другой моделью тоже отвалился), разъём вообще в принципе очень плохой и провод постоянно отходил, крайне плохая батарейка (на 1-2 минуты с полной зарядки через пару месяцев). И ещё по мелочам чего уже не припомню. Через полгода он у меня был замотан изолентой вместе с проводом и пропаян. Про кач-во сборки я вообще молчу — китай китаем, gps вообще одним проводом был припаен и болтался на подложке из фольги (тут не уверен, может так должно быть).
Про прошивки итд писать мне сейчас нет смысла — я перепробовал несколько штук. Что уже лично для меня тревожный признак, т.к. если ПРИХОДИТСЯ прошивать девайс, да ещё по нескольку раз, то это уже жесть. Тем более(!) для той ниши, в которую вы себя типа позиционируете. В каментах там к этой модели конкретно 70% проблем одни и те же и все бугуртят. Вы бы лучше там пользователям отвечали, мне то сейчас уже чего смысл писать. Ну, может и надо было везти в СЦ, вы правы, да как-то надеялся видимо на прошивки, на паяльник и на дарёного коня. Вы поймите, что речь про всякие такие косячки, которые позволяли пользоваться, но периодически бесили. Особенно с учётом, что девайсы у вас типа «не бюджетные» как вы сами говорите, ещё раз укажу отдельно на это, потому что 90% претензии мои и остальные именно про это.
FIXED
з.ы. Остальное вроде не вопрос, а бред какой-то.