<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pá 20. 9. 2019 v 19:54 odesílatel Carl Eugen Hoyos <<a href="mailto:ceffmpeg@gmail.com">ceffmpeg@gmail.com</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You cannot put mjpeg into mpegts, this is not a limitation of FFmpeg.<br></blockquote><div>Yeah, I thought so. Thank you for the confirmation.</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Did you test hardware encoding?<br>
Or reencoding all mjpeg input in advance?<br></blockquote><div>It would be still too expensive for my use case. The storage constantly records hundreds of streams and only a very small fraction of them is ever downloaded via the server application that I mentioned. And yet the server application needs to be able to serve hundreds of download requests in parallel. So it does not make much sense to transcode the streams in any stage.</div><div><br></div><div>I'll probably go with a compromise here. MPEG-TS for h264 streams and MP4 for MJPEG streams. It isn't ideal but as I understand it, there's no better solution right now.</div><div><br></div><div>Thanks for your help, Ondrej</div></div></div>