Здравствуйте, paradok, Вы писали:
>>> синхронном источнике (Live, Сеть) на приёме всегда будет либо перебор, либо недобор.
P>вроде вот так не будет... P>пусть eсть буфера длинной N1..NK P>при поступлении очередного кадра из NX потока он добавляется в нужный буфер, а самый кадр старый удаляется из буфера... P>а главный объединитель по своим тактам просматривает все буфера и обирает картинку в главный буфер.
Кадр из сетевого буфера удаляется не по приходу нового, а при наступлении времени приемника, указанного в кадре, которое не совпадает с временем источника. В описанном вами подходе не добиться плавности, т.к. кадры по сети приходят в ужасно дёрганном режиме, относительно реального времени.
Re[14]: как синхронизировать несколько видеостримов
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, paradok, Вы писали:
>>>> синхронном источнике (Live, Сеть) на приёме всегда будет либо перебор, либо недобор.
P>>вроде вот так не будет... P>>пусть eсть буфера длинной N1..NK P>>при поступлении очередного кадра из NX потока он добавляется в нужный буфер, а самый кадр старый удаляется из буфера... P>>а главный объединитель по своим тактам просматривает все буфера и обирает картинку в главный буфер.
V>Кадр из сетевого буфера удаляется не по приходу нового, а при наступлении времени приемника, указанного в кадре, которое не совпадает с временем источника. В описанном вами подходе не добиться плавности, т.к. кадры по сети приходят в ужасно дёрганном режиме, относительно реального времени.
но если дрожание не ужасное, то будет норм.
более реалистична ситуация — 1) есть небольшой дрейф асов источника и приемника 2) и есть небольшое дрожание скорости поступления НО В СРЕДНЕМ = 0.
то есть канал БЕЗ НАКОПИТЕЛЬНОЙ ПАМЯТИ и не теряет кадры.
Тогда при умеренном дрожании — компромис — буффер заполняется и удаляется как я описал,
а главный поток читает НЕ САМЫЙ старый кадр из потоков, но старый,
потом ставит маркер что его можно удалять по приходу нового пакета и далее как выше описано.
при этом скажем 3 сигма дрожания К, а размер буфера скажем N >> K, тогда дрожание полностью погасится.
останется только дрей, но н решаетс как выше описано..
т.е. буфер будет в среднем постоянного размера, но у него будет дрожать время удаления начала и конца
а главный поток должен читать откуда-то из середин буфера.
Здравствуйте, paradok, Вы писали:
P>...
P>т.е. буфер будет в среднем постоянного размера, но у него будет дрожать время удаления начала и конца P>а главный поток должен читать откуда-то из середин буфера.
Теоретически такое возможно, но на практике я такого никогда не встречал, если часы источника и приемника не синхронизированы. Потом, небольшое дрожание понятие такое себе. Помню как-то отлаживали рендерер, который рендерил поток 25 FPS (40 ms между кадрами). Так вот, когда отклонения между точным и фактическим рендерингом кадров превышал +-5 ms, допустим времена фактически были такими: 0, 40, 75, 125, 160, и т.д., то это на глаз воспринималось как рваное проигрывание видео. Особенно это хорошо проверять на монотонно меняющейся картинке, например финальные титры в конце фильма, плывущие снизу вверх.
Все сетевые источники, с которыми мне приходилось работать, не задерживают видео при отправке. Идут у кодека кадры IBBP, так он PBB сразу и пуляет вместе одной пачкой, таким образом рывки сразу по 120 ms, потом тишина и т.д.
Re[16]: как синхронизировать несколько видеостримов
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, paradok, Вы писали:
P>>...
P>>т.е. буфер будет в среднем постоянного размера, но у него будет дрожать время удаления начала и конца P>>а главный поток должен читать откуда-то из середин буфера.
V>Теоретически такое возможно, но на практике я такого никогда не встречал, если часы источника и приемника не синхронизированы. Потом, небольшое дрожание понятие такое себе. Помню как-то отлаживали рендерер, который рендерил поток 25 FPS (40 ms между кадрами). Так вот, когда отклонения между точным и фактическим рендерингом кадров превышал +-5 ms, допустим времена фактически были такими: 0, 40, 75, 125, 160, и т.д., то это на глаз воспринималось как рваное проигрывание видео. Особенно это хорошо проверять на монотонно меняющейся картинке, например финальные титры в конце фильма, плывущие снизу вверх.
V>Все сетевые источники, с которыми мне приходилось работать, не задерживают видео при отправке. Идут у кодека кадры IBBP, так он PBB сразу и пуляет вместе одной пачкой, таким образом рывки сразу по 120 ms, потом тишина и т.д.
небольшое относительно размера буфера! то есть если пуляет блоками то буфер скажем длинной в 10 блоков.
я делал такое в телефонии — работает норм.
но в идеале все же надо делать интерполяцию и экстраполяцию так как кадры могут и пропадать иногда...
