Stream capture over network

[vgrsystems]

Good evening, Not really an issue because the code works very well, even on a raspberry. Nevertheless, I need to stream the video over network with udp and H264 compression. Do you have any ideas how to do this inside your code ? I tried gstreamer and V4L2 drivers but the quality and latency are too bad.

Thank you very much for your help, Regards,

François

[ghost]

Thanks for nice comments. Your approach sounds the correct one to me : V4Linux + gstreamer. (You can also try withe Live555)

Before discarting them i would check:

• Is latency due to your system? or it is due to the player?
• Quality could be related to CPU performance issues or settings on the encoder. Perhaps try to stream using I frames only , even reducing frames/second and see if they look good this way. Perhaps you can downscale the image first to encoding it.

Not sure if RPI can do H264 encoding by HW? or if it is doing it by SW? this is another are to look at. But as i said, your approach sounds correct. There is always the possibility that you use your own blocks, but that is a different project/discussion.

[JimKlingshirn]

The player usually adds a lot of latency. In VLC you can minimize the amount of packet buffering to remove most of the latency.

On Thu, Aug 30, 2018 at 11:59 AM Andres Prieto-Moreno < notifications@github.com> wrote:

Thanks for nice comments. Your approach sounds the correct one to me : V4Linux + gstreamer. (You can also try withe Live555)

Before discarting them i would check:

• Is latency due to your system? or it is due to the player?
• Quality could be related to CPU performance issues or settings on the encoder. Perhaps try to stream using I frames only , even reducing frames/second and see if they look good this way. Perhaps you can downscale the image first to encoding it.

Not sure if RPI can do H264 encoding by HW? or if it is doing it by SW? this is another are to look at. But as i said, your approach sounds correct. There is always the possibility that you use your own blocks, but that is a different project/discussion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FLIR/BosonUSB/issues/4#issuecomment-417430480, or mute the thread https://github.com/notifications/unsubscribe-auth/AFEZvl58cpobC023m4s05GGTprHzQanKks5uWDYNgaJpZM4WTp6A .

[vgrsystems]

Thanks a lot i will try that RegardsFrancois

Envoyé depuis Yahoo Mail pour iPhone

Le vendredi, août 31, 2018, 1:19 AM, Jim Klingshirn notifications@github.com a écrit :

The player usually adds a lot of latency. In VLC you can minimize the amount of packet buffering to remove most of the latency.

On Thu, Aug 30, 2018 at 11:59 AM Andres Prieto-Moreno < notifications@github.com> wrote:

Thanks for nice comments. Your approach sounds the correct one to me : V4Linux + gstreamer. (You can also try withe Live555)

Before discarting them i would check:

• Is latency due to your system? or it is due to the player?
• Quality could be related to CPU performance issues or settings on the encoder. Perhaps try to stream using I frames only , even reducing frames/second and see if they look good this way. Perhaps you can downscale the image first to encoding it.

Not sure if RPI can do H264 encoding by HW? or if it is doing it by SW? this is another are to look at. But as i said, your approach sounds correct. There is always the possibility that you use your own blocks, but that is a different project/discussion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FLIR/BosonUSB/issues/4#issuecomment-417430480, or mute the thread https://github.com/notifications/unsubscribe-auth/AFEZvl58cpobC023m4s05GGTprHzQanKks5uWDYNgaJpZM4WTp6A .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.