@MSGID: 2:5059/38 657fbe92
@REPLY: 2:6078/1 657ea413
@CHRS: CP866 2
@TZUTC: 0300
Здравствуй, Dmitriy!

 Ответ на сообщение Dmitriy Romanov (2:6078/1) к Andrey Mundirov,
написанное 17 дек 23 в 09:21:


 DR> Интересное решение, но есть несколько но.
 DR> 1. Как у него с задержкой? Я так понимяу, что задержка будет минимум
 DR> на длину одного фрагмента. Чем длиннее фрагмент, тем больше задержка,
 DR> а чем короче, тем потом неудобнее пользоваться сохраненным архивом.

 Именно так оно и работает. В моем случае задержка была не критична,
была задача раздать видео максимальному количеству пользователей. VLC
вывозил максимум 20-30 юзеров, ffserver чуть больше, а nginx тянет сотню и
больше потянул бы, но уже канала не хватает.

 DR> 2.
 DR> А будет ли оно работать, если вместо libx264 будет mpeg4 ? У меня все
 DR> уперлось в эту проблему. Пока что изобразил решение на базе ffserver.
 DR> Но ни в одном браузере ни с одним плеером в mpeg4 не хочет показывать.
 DR> Вот с libx264 - то пожалуйста сколько угодно. Но у меня была
 DR> первоочередная задача уйти от использования libx264 в любых его
 DR> проявлениях, ибо у меня и в один то поток в реальном времени не тянет,
 DR> а хотелось бы их 16 запихнуть.

 Странно, что даже один поток не тянет. Core i7 1 поколения
нормально справляется, теоретически должен даже 4 потока вывозить, по числу
ядер. Или там разрешение большое и битрейт?

С наилучшими пожеланиями, Andrey

--- GoldED+/LNX 1.1.5-b20161221
 * Origin: PC Lovers (2:5059/38)
SEEN-BY: 46/49 50/18 72 361 450/68 452/28 455/19
469/122 5010/275 5019/40
SEEN-BY: 5020/101 290 545 556 570 715 837 848
921 1042 2992 4096 4441 9696
SEEN-BY: 5020/12000 5022/2 128 5023/12 24 5026/49
5028/63 68 5030/500 1081
SEEN-BY: 5030/1900 1997 5034/13 5037/28 5055/73
5057/19 5059/37 38 5060/900
SEEN-BY: 5075/128 6035/4 6056/1 6078/80 6090/1
@PATH: 5059/38 5023/24 5020/715 4441