Твитнуть
Re: разработка API для просмотра IPTV сервиса Rodnoe.TV (обсуждение/предложения)
Еще уточнение по поводу времен.
Сначала исходные данные
ПЕРВОЕ
У нас есть несколько режимов работы с плеером:
1) в текущем времени
2) с таймшифтом
3) проигрывание из архива при отключенном таймшифте
4) проигрывание из архива при включенном таймшифте
ВТОРОЕ
Есть каналы, поддерживающие таймшифт (и архив) и не поддерживающие. Поэтому при включенном таймшифте клиент смотрит "пересортицу", т.е. одни каналы в таймшифте, другие - в текущем времени.
ТРЕТЬЕ
В клиентской программе (CLIENT) есть два интерфейса для показа ЕПГ - общий дневной (MAIN) и текущий (CURRENT)
Итак, вариант работы:
Пункты 3 и 4 с точки зрения вещания - это одно и то же. Разница только с точки зрения ЕПГ (при выборе программы из архива может возникнуть путаница с пересчетом времен)
Я предлагаю вне зависимости от режимов проигрывания (таймшифт, архив, пр.) отдавать ЕПГ с непреобразованным реальным таймстампом, но в возвращаемый ЕПГ добавляю параметр TIME_SHIFT (в секундах), который вместе с известной локальной таймзоной дает возможность получить строковое представление локального клиентского времени понятного пользователю.
Что получается при разных указанных выше режимах работы.
1) CLIENT в запросе MAIN ЕПГ и CURRENT ЕПГ не указывает таймшифт, а затем, при получении ответа, для каждого канала отнимает полученный его (канала) таймшифт от таймстампов его ЕПГ (в данном случае он все равно вернется нулевой), не задумываясь установлен ли клиентом таймшифт. Затем переводит полученные таймстампы в строковые локальные времена.
2) CLIENT в запросе MAIN ЕПГ и CURRENT ЕПГ указывает таймшифт, а затем, при получении ответа, для каждого канала отнимает полученный его (канала) таймшифт от таймстампов его ЕПГ, не задумываясь установлен ли клиентом таймшифт. Затем переводит полученные таймстампы в строковые локальные времена.
В ответе MAIN ЕПГ каждого канала "временнОе окно выбора программ" будет смещено назад на величину таймшифта этого канала. Для неархивируемых каналов - останется не смещенным - это понятно.
3) CLIENT запросил и получил MAIN ЕПГ без таймшифта.
Теперь он щелкает в MAIN ЕПГ на определенный канал. Идет запрос на CURRENT ЕПГ с указанием параметра "время начала" (реальный таймстамп) и возвращается CURRENT ЕПГ для этой временнОй точки с реальными таймстампами и с таймшифтом равным смещению этой временнОй точки относительно текущего времени. MAIN ЕПГ остается прежним (не перезапрашивается).
4) CLIENT запросил и получил MAIN ЕПГ с таймшифтом.
Далее все аналогично п.3
Т.е. CLIENT и SERVER всегда обмениваются реальными таймстампами, а все пересчеты времен производятся ими с помощью дополнительных параметров корректировки времен (таймшифт, старттайм, пр.) которыми они по необходимости обмениваются во время сеанса.
Вот такая-вот схема.
Думаю, она позволяет избежать путаницы и
Еще уточнение по поводу времен.
Сначала исходные данные
ПЕРВОЕ
У нас есть несколько режимов работы с плеером:
1) в текущем времени
2) с таймшифтом
3) проигрывание из архива при отключенном таймшифте
4) проигрывание из архива при включенном таймшифте
ВТОРОЕ
Есть каналы, поддерживающие таймшифт (и архив) и не поддерживающие. Поэтому при включенном таймшифте клиент смотрит "пересортицу", т.е. одни каналы в таймшифте, другие - в текущем времени.
ТРЕТЬЕ
В клиентской программе (CLIENT) есть два интерфейса для показа ЕПГ - общий дневной (MAIN) и текущий (CURRENT)
Итак, вариант работы:
Пункты 3 и 4 с точки зрения вещания - это одно и то же. Разница только с точки зрения ЕПГ (при выборе программы из архива может возникнуть путаница с пересчетом времен)
Я предлагаю вне зависимости от режимов проигрывания (таймшифт, архив, пр.) отдавать ЕПГ с непреобразованным реальным таймстампом, но в возвращаемый ЕПГ добавляю параметр TIME_SHIFT (в секундах), который вместе с известной локальной таймзоной дает возможность получить строковое представление локального клиентского времени понятного пользователю.
Что получается при разных указанных выше режимах работы.
1) CLIENT в запросе MAIN ЕПГ и CURRENT ЕПГ не указывает таймшифт, а затем, при получении ответа, для каждого канала отнимает полученный его (канала) таймшифт от таймстампов его ЕПГ (в данном случае он все равно вернется нулевой), не задумываясь установлен ли клиентом таймшифт. Затем переводит полученные таймстампы в строковые локальные времена.
2) CLIENT в запросе MAIN ЕПГ и CURRENT ЕПГ указывает таймшифт, а затем, при получении ответа, для каждого канала отнимает полученный его (канала) таймшифт от таймстампов его ЕПГ, не задумываясь установлен ли клиентом таймшифт. Затем переводит полученные таймстампы в строковые локальные времена.
В ответе MAIN ЕПГ каждого канала "временнОе окно выбора программ" будет смещено назад на величину таймшифта этого канала. Для неархивируемых каналов - останется не смещенным - это понятно.
3) CLIENT запросил и получил MAIN ЕПГ без таймшифта.
Теперь он щелкает в MAIN ЕПГ на определенный канал. Идет запрос на CURRENT ЕПГ с указанием параметра "время начала" (реальный таймстамп) и возвращается CURRENT ЕПГ для этой временнОй точки с реальными таймстампами и с таймшифтом равным смещению этой временнОй точки относительно текущего времени. MAIN ЕПГ остается прежним (не перезапрашивается).
4) CLIENT запросил и получил MAIN ЕПГ с таймшифтом.
Далее все аналогично п.3
Т.е. CLIENT и SERVER всегда обмениваются реальными таймстампами, а все пересчеты времен производятся ими с помощью дополнительных параметров корректировки времен (таймшифт, старттайм, пр.) которыми они по необходимости обмениваются во время сеанса.
Вот такая-вот схема.
Думаю, она позволяет избежать путаницы и
Комментарий