<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">po 23. 9. 2019 v 23:13 odesílatel Carl Eugen Hoyos <<a href="mailto:ceffmpeg@gmail.com" target="_blank">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">
Why don't you serve the mjpeg streams as mjpeg?<br></blockquote><div> </div><div>I'm not sure if I understand you correctly. Do you mean the raw MJPEG video muxer (labeled as "mjpeg")? I didn't know that there can be any timestamps in raw mjpeg files. Are the timestamps directly in the JFIFs?<br></div><div><br></div><div>Just a reminder - I need the result to be downloadable and seekable and I also need the container to be widely supported by players.</div><div><br></div><div>I've tested the "mjpeg", "smjpeg", "mpjpeg" muxers. The "mjpeg" container was working in some players but other players were completely ignoring timestamps and playing the content as fast as they could. VLC wasn't able to play it at all. Most of the players weren't able to seek in it. The "smjpeg" was working fine in most of the players except QuickTime. Seeking was working as well here. The multipart format wasn't usable at all (as I suspected). Anyway, the biggest problem with these formats is in file associations. The file format/extension wasn't recognized on Windows, Mac, iOS and Android. This would just lead to a bunch of confused users.<br></div></div></div>