Hi Richard, yes, that'd be easy. Unfortunately, I cannot do that. Clients are standard web browsers. There will be a web page with a link to download a specific (user defined) set of segments from the storage. The server will mux these segments into mp4, web browser will download it and save it. The users than expect to be able to open it in their favorite media player and seek in it.
O. čt 19. 9. 2019 v 19:20 odesílatel Richard Hussong <[email protected]> napsal: > Ondrej - > > If you are in charge of the receiving client, it could receive the > non-seekable stream and re-mux it into a seekable container using ffmpeg or > the libraries. I don't know any other way to accomplish what you want, but > I am not an ffmpeg expert. > > - Richard Hussong > > On Wed, Sep 18, 2019 at 5:50 AM Ondřej Perutka <[email protected]> > wrote: > >> Hi, >> >> I'm trying to solve a little puzzle here. I'm looking for a container >> that would allow me to create a video file "on the fly" and stream it over >> HTTP. But I also need the result to be seekable. >> >> To add more details, I have a storage with MPEG-TS video segments >> (thousands of hours of continuous video). I need to create a server >> application that would take a given set of continuous segments from the >> storage, it would mux it into an appropriate container and stream it over >> HTTP to a client. The client can save it as a file, play it back and seek >> in it. >> >> The video codec can be either h264 or MJPEG. There can be also an audio >> in AAC. >> >> Right now I'm using fragmented MP4 but not all players can seek in it. >> From what I understand, the MP4 muxer puts the MOOV atom to the end of the >> file by default, so it should be possible. Unfortunately, when I tried to >> create a regular MP4 (i.e. not fragmented) with AVIOContext which does not >> support seeking, the result wasn't playable. >> >> Please note that I cannot create the whole MP4 file on the server and >> stream it via HTTP when it's done. There would be a big delay and I also >> want to avoid disk IO because of scalability. >> >> Thanks for your help. >> >> Ondrej >> >> _______________________________________________ >> Libav-user mailing list >> [email protected] >> https://ffmpeg.org/mailman/listinfo/libav-user >> >> To unsubscribe, visit link above, or email >> [email protected] with subject "unsubscribe". > > _______________________________________________ > Libav-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/libav-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe".
_______________________________________________ Libav-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
