mp4 by 'mp4mux' plays too fast and is not seekable

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

mp4 by 'mp4mux' plays too fast and is not seekable

ivan-perez
Hi there

I'm saving a MP4 video file out of a H264 stream, generated with the raspivid command. The problem I've seen is that some video players can't handle the MP4 file correctly. I've tried Windows Media Player, and the Android-Chrome stock browser (the videos are intended to be played within a webapp) and in both videos are playing very fast (maybe 20x of normal speed), and I can't seek them. However the total length of the videos is correctly computed for both players, but can't move past ~10% of the total length (for example, I've recorded a 1-minute video, Windows Media Player shows correctly that the video is 1-minute long, but it plays it completely in about 8 seconds).

The only player where it works well is VLC, there I've no problems, I can seek and it plays at the correct framerate.

The pipeline:

           fdsrc,
           ! video/x-h264,width=320,height=240,framerate=30/1,profile=main,stream-format=byte-stream,alignment=au
           ! h264parse
           ! mp4mux faststart=true
           ! filesink location=test.mp4

I've tried to set the 'faststart' parameter to true, but it doesn't fix my problem. What else could I try?

As always, thank you very much!!
Reply | Threaded
Open this post in threaded view
|

Re: mp4 by 'mp4mux' plays too fast and is not seekable

Tim Müller
On Tue, 2017-03-07 at 08:06 -0800, ivan-perez wrote:

Hi,

I would recommend you use the rpicamsrc element from

https://github.com/thaytan/gst-rpicamsrc

It will make sure buffers are timestamped correctly and such.

Cheers
 -Tim

> The pipeline:
>
>            fdsrc,
>            !
> video/x-h264,width=320,height=240,framerate=30/1,profile=main,stream-
> format=byte-stream,alignment=au
>            ! h264parse
>            ! mp4mux faststart=true
>            ! filesink location=test.mp4

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: mp4 by 'mp4mux' plays too fast and is not seekable

ivan-perez
Hi Tim

Yes, I've tried that component as has been suggested to me in another thread, and it works well. But my requirements have changed since then, and I can't use 'rpicamsrc' anymore. The reason is that I want to record at least two simulateneous streams (I want them to be added and removed dynamically), and as far as I've seen 'rpicamsrc' doesn't allow it - when there's one instance recording from the camera, the next one fails, because the camera is in use. I've also tried to 'tee' but I got no results.

The only way I've managed to get that functionality is by using the picamera library, which is the only one that allows to create more than one stream from the camera at the same time. My application now creates two different streams and redirects both of them to two Gstreamer pipes.

Is there a way to correct the stream? How can I find if the problem is really about the stream not being correctly timestamped?

Thanks in advance.

Kind regards
Reply | Threaded
Open this post in threaded view
|

Re: mp4 by 'mp4mux' plays too fast and is not seekable

ivan-perez
In reply to this post by ivan-perez
I've just tried 'fdsrc do-timestamp=true' but it isn't working neither...
Reply | Threaded
Open this post in threaded view
|

Re: mp4 by 'mp4mux' plays too fast and is not seekable

Tim Müller
In reply to this post by ivan-perez
On Tue, 2017-03-07 at 23:24 -0800, ivan-perez wrote:

Hi,

> I can't use 'rpicamsrc' anymore. The reason is that I want to record
> at least two simulateneous streams (I want them to be added and
> removed dynamically), and as far as I've seen 'rpicamsrc' doesn't
> allow it - when there's one instance recording from the camera, the
> next one fails, because the camera is in use.

Right, that's kind of expected I guess :)

>  I've also tried to 'tee' but I got no results.

I believe "tee" should work. Maybe post a small example app that
doesn't work so we can look at what you're doing and figure out why it
doesn't work as expected.

> Is there a way to correct the stream? How can I find if the problem
> is really about the stream not being correctly timestamped?

fdsrc doesn't set timestamps and h264parse presumably just makes up
timestamps based on some framerate (25fps? 30fps). It's really not a
good solution, fdsrc isn't meant for this usecase. You could capture
from the library and push buffers manually into the pipeline(s) with
appsrc though, if you configure appsrc accordingly (do-timestamp, time
format, live).

Cheers
 -Tim
--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: mp4 by 'mp4mux' plays too fast and is not seekable

ivan-perez
Hi Tim

Sorry for the late answer.

This is a diagram of my application right now:


At the moment I split the stream using the picamera library, which allows to create up to four simultaneous streams very easily. Before using it, I had been trying a C program you show me in another thread, but I got no success in implementing it into my needs. http://gstreamer-devel.966125.n4.nabble.com/H264-stream-to-MP4-file-without-the-first-bytes-on-the-H264-stream-tp4681699p4681866.html

So, finally, I've found another solution in order to create a playable and seekable MP4 file, but without Gstreamer :( Now Gstreamer only manages the (multi-) RTP stream to the clients.

I've used FFMPEG and it correctly muxes the H264 into a MP4 which plays nicely in all players I've checked. And it's by far more easy to use than Gstreamer for such a simple thing.

Kind regards.

Tim Müller wrote
On Tue, 2017-03-07 at 23:24 -0800, ivan-perez wrote:

Hi,

> I can't use 'rpicamsrc' anymore. The reason is that I want to record
> at least two simulateneous streams (I want them to be added and
> removed dynamically), and as far as I've seen 'rpicamsrc' doesn't
> allow it - when there's one instance recording from the camera, the
> next one fails, because the camera is in use.

Right, that's kind of expected I guess :)

>  I've also tried to 'tee' but I got no results.

I believe "tee" should work. Maybe post a small example app that
doesn't work so we can look at what you're doing and figure out why it
doesn't work as expected.

> Is there a way to correct the stream? How can I find if the problem
> is really about the stream not being correctly timestamped?

fdsrc doesn't set timestamps and h264parse presumably just makes up
timestamps based on some framerate (25fps? 30fps). It's really not a
good solution, fdsrc isn't meant for this usecase. You could capture
from the library and push buffers manually into the pipeline(s) with
appsrc though, if you configure appsrc accordingly (do-timestamp, time
format, live).

Cheers
 -Tim
--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel