[erlang-questions] Making erlang more realtime?

[Ilya Shcherbak]

hi,

sorry, but the issue is unclear for me. can you describe a bit more
specific a high level issue. why do you need to send frames in 17ms
interval? it shouldn't be a requirement for a sender by design in my
understanding.

The constant delay doesn't look like a right solution for any reason:
- network spikes won't be resolved due to difference I/P/B frame sizes;
(need to have a smart algorithm of a sender queue)
- playback sync won't be resolved due to network/receiver fluctuations;
(need to have JB on a receiver)

You can check an implementation of a sender queue in WebRTC project:
modules/pacing/paced_sender.cc for instance.

If you are transmitting high res video in a local network and facing an
issue with transmitting you can try to tune socket buffer sizes for
send/recv.

Probably i missed something and you can add more information about an
initial task.





2017-03-03 22:23 GMT+07:00 Max Lapshin <max.lapshin@REDACTED>:

> main question here is:  what does requires sending frames exactly once per
> 17 ms?
>
> Browser do not require it and erlang precision is enough.
>
> C may become mandatory if you want to send about 500-800 mbit of video,
> mux several streams to single multi-stream and maintain strict constant
> bitrate via UDP to send all this to dumb IP -> DVB-C transmitter.
>
> But usually erlang is enough: we are feeding satellite encoder from
> flussonic now and it is ok.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170304/9033c68d/attachment.htm>