[Libav-user] mjpeg overread 8
Paul B Mahol
onemda at gmail.com
Tue May 9 09:16:22 EEST 2023
On Tue, May 9, 2023 at 4:17 AM wolverin <wolverin82 at mail.ru> wrote:
>
>
> Суббота, 22 апреля 2023, 13:00 +05:00 от Paul B Mahol <onemda at gmail.com>:
>
> On Fri, Apr 21, 2023 at 3:12PM wolverin via Libav-user <
> libav-user at ffmpeg.org
> <//e.mail.ru/compose/?mailto=mailto%3alibav%2duser at ffmpeg.org>> wrote:
>
>
>
> Пятница, 21 апреля 2023, 17:13 +05:00 от Yurii Monakov <
> monakov.y at gmail.com
> <//e.mail.ru/compose/?mailto=mailto%3amonakov.y at gmail.com>>:
>
> Hi,
>
> The local screen is converted to mjpeg and streamed to localhost:
>
> ffmpeg -video_size 1024x768 -framerate 5 -f x11grab -i :1 -vcodec mjpeg -f
> mjpeg udp://127.0.0.1:8554
> ffplay -f mjpeg udp://127.0.0.1:8554
>
>
> This pair of commands work fine with ffmpeg 4.4.2
>
> Yurii
>
>
> Thank you for paying attention to my problem, again!
>
> I am using ffmpeg 5.0 version, but I am not transferring localhost, but
> between different hosts or even the internet.
> Of course, in the latter case, packet losses occur, but how to make the
> ffmpeg of the library process this correctly.
> I set fifo_size to 100M, it reduced the number of other errors, but it
> didn't get rid of this one.
>
>
> I doubt that udp protocol can handle packet losses reliably.
>
>
> _______________________________________________
>
>
> Initially, I wanted to forward packets via symmetric NAT, and it doesn't
> even matter if some frames are lost, the question is probably how to
> discard damaged frames?
>
> Perhaps you can recommend another protocol from ffmpeg, more suitable for
> my task???
>
Over real physical network use protocol that can handle losses.
Also mjpeg format is not going to handle well losses via udp, mpegts might
be better for that, but it does not support mjpeg video.
>
> Thank you if you respond.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20230509/40f3b93a/attachment.htm>
More information about the Libav-user
mailing list