[Libav-user] Creating seekable video files without seekable IO

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Libav-user] Creating seekable video files without seekable IO

Ondřej Perutka
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Richard Hussong
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 <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Carl Eugen Hoyos-2
In reply to this post by Ondřej Perutka
Am Mi., 18. Sept. 2019 um 11:50 Uhr schrieb Ondřej Perutka
<[hidden email]>:

> 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.

What's wrong with mpegts?

Carl Eugen
_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Ondřej Perutka
In reply to this post by Richard Hussong
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Ondřej Perutka
In reply to this post by Carl Eugen Hoyos-2
Hi Carl,

thank you for the suggestion. For some reason, I thought that mpegts is not seekable at all. I've tested it though and seeking worked in all players that I've tested so far. One of the tested players had a problem with playback speed though. But it's probably a bug in the player.

Unfortunately, it works only for h264. I'm able to mux mjpeg content using mpegts but players are not able to handle it for some reason. Transcoding is also out of the question for me as it'd put too much load on the server.

O.


pá 20. 9. 2019 v 1:46 odesílatel Carl Eugen Hoyos <[hidden email]> napsal:
Am Mi., 18. Sept. 2019 um 11:50 Uhr schrieb Ondřej Perutka
<[hidden email]>:

> 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.

What's wrong with mpegts?

Carl Eugen
_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".

_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Carl Eugen Hoyos-2
Am Fr., 20. Sept. 2019 um 09:50 Uhr schrieb Ondřej Perutka
<[hidden email]>:

> thank you for the suggestion. For some reason, I thought that mpegts is not seekable
> at all. I've tested it though and seeking worked in all players that I've tested so far.
> One of the tested players had a problem with playback speed though. But it's probably
> a bug in the player.
>
> Unfortunately, it works only for h264. I'm able to mux mjpeg content using mpegts but
> players are not able to handle it for some reason.

You cannot put mjpeg into mpegts, this is not a limitation of FFmpeg.

> Transcoding is also out of the question for me as it'd put too much load on the server.

Did you test hardware encoding?
Or reencoding all mjpeg input in advance?

Please find out what top-posting means and avoid it here, Carl Eugen
_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Ondřej Perutka
pá 20. 9. 2019 v 19:54 odesílatel Carl Eugen Hoyos <[hidden email]> napsal:
You cannot put mjpeg into mpegts, this is not a limitation of FFmpeg.
Yeah, I thought so. Thank you for the confirmation.

Did you test hardware encoding?
Or reencoding all mjpeg input in advance?
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.

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.

Thanks for your help, Ondrej

_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Carl Eugen Hoyos-2
Am Mo., 23. Sept. 2019 um 16:47 Uhr schrieb Ondřej Perutka
<[hidden email]>:

> 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.

Why don't you serve the mjpeg streams as mjpeg?

Carl Eugen
_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Ondřej Perutka
po 23. 9. 2019 v 23:13 odesílatel Carl Eugen Hoyos <[hidden email]> napsal:
Why don't you serve the mjpeg streams as mjpeg?
 
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?

Just a reminder - I need the result to be downloadable and seekable and I also need the container to be widely supported by players.

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.

_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: Creating seekable video files without seekable IO

Carl Eugen Hoyos-2
Am Di., 24. Sept. 2019 um 15:20 Uhr schrieb Ondřej Perutka
<[hidden email]>:
>
> po 23. 9. 2019 v 23:13 odesílatel Carl Eugen Hoyos <[hidden email]> napsal:
>>
>> Why don't you serve the mjpeg streams as mjpeg?
>
> 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?

There are no timestamps but seeking does not necessarily depend on timestamps.

Carl Eugen
_______________________________________________
Libav-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/libav-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".