Changing Frame Rate

[HtGst]

Hi

Is there a way, within gst-launch, to change the frame rate on fly? Failing that is it possible to append to an existing encoded file, using a different rate:

 

gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw, framerate=\(fraction\)”30/1” ! \ ! x264enc ! filesink location=t.mp4

gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw, framerate=\(fraction\)”50/1” ! \ ! x264enc ! filesink –append location=t.mp4

Cheers,

 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Do, 2016-06-23 at 20:03 -0700, ht techdev wrote:

> Hi
> Is there a way, within gst-launch, to change the frame rate on fly?
> Failing that is it possible to append to an existing encoded file,
> using a different rate:
>  
> gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw,
> framerate=\(fraction\)”30/1” ! \ ! x264enc ! filesink location=t.mp4
> gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw,
> framerate=\(fraction\)”50/1” ! \ ! x264enc ! filesink –append
> location=t.mp4

With gst-launch-1.0 you can't do it, with actual code you relatively
easily can (you "just" change the framerate).

Appending MP4 files is not easily possible, you would at least have to
remux them but for full correctness you would also have to reencode the
h264 stream as the avcC struct (the "header") is going to be different
for both encodings in your case and that's not really allowed by the
spec (there can only be one).

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Peter Maersk-Moller-2]

Hi ht Techdev.

Couple of things.
1. num-frames should be num-buffers in your example.

2. Using filesink to save into a file with the extension mp4 does not make it a file using the mp4 containerforat. You need to add a mp4 muxer. What you are saving is a raw h264 stream.

On Fri, Jun 24, 2016 at 5:03 AM, ht techdev <[hidden email]> wrote:

Hi

Is there a way, within gst-launch, to change the frame rate on fly? Failing that is it possible to append to an existing encoded file, using a different rate:

 

gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw, framerate=\(fraction\)”30/1” ! \ ! x264enc ! filesink location=t.mp4

gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw, framerate=\(fraction\)”50/1” ! \ ! x264enc ! filesink –append location=t.mp4

Cheers,

 

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Peter Maersk-Moller-2]

Hi Sabastian.

Assuming you are using mp4mux with h264parse prepended and assuming the stream could be ... lets say a RTP stream received using udpsrc, then you can send first a stream with frame rate A (and resolution X) and then frame rate B (and resolution Y). In theory h264parse should detect the frame rate change and in theory, it should signal that to mp4mux and in theory mp4mux should accept this and create a new entry describing the new condition, as it can with resolution change in the middle of a stream. If the code is there in mp4mux and h264parse, that ought to work.

Likewise the demuxer should be able to detect frame rate change and resolution change and a player should be able to handle change of both resolution and frame rate during play. However implementations may not always be full.

Regards

PMM

On Fri, Jun 24, 2016 at 9:47 AM, Sebastian Dröge <[hidden email]> wrote:

On Do, 2016-06-23 at 20:03 -0700, ht techdev wrote:
> Hi
> Is there a way, within gst-launch, to change the frame rate on fly?
> Failing that is it possible to append to an existing encoded file,
> using a different rate:
>  
> gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw,
> framerate=\(fraction\)”30/1” ! \ ! x264enc ! filesink location=t.mp4
> gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw,
> framerate=\(fraction\)”50/1” ! \ ! x264enc ! filesink –append
> location=t.mp4

With gst-launch-1.0 you can't do it, with actual code you relatively
easily can (you "just" change the framerate).

Appending MP4 files is not easily possible, you would at least have to
remux them but for full correctness you would also have to reencode the
h264 stream as the avcC struct (the "header") is going to be different
for both encodings in your case and that's not really allowed by the
spec (there can only be one).

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Fr, 2016-06-24 at 10:04 +0200, Peter Maersk-Moller wrote:

> Hi Sabastian.
>
> Assuming you are using mp4mux with h264parse prepended and assuming
> the stream could be ... lets say a RTP stream received using udpsrc,
> then you can send first a stream with frame rate A (and resolution X)
> and then frame rate B (and resolution Y). In theory h264parse should
> detect the frame rate change and in theory, it should signal that to
> mp4mux and in theory mp4mux should accept this and create a new entry
> describing the new condition, as it can with resolution change in the
> middle of a stream. If the code is there in mp4mux and h264parse,
> that ought to work.

h264parse does, I doubt that mp4mux does that currently. But yes, in
theory that would work when implemented :)

(Still requires you to write code instead of using gst-launch-1.0)

> Likewise the demuxer should be able to detect frame rate change and
> resolution change and a player should be able to handle change of
> both resolution and frame rate during play. However implementations
> may not always be full.

The demuxer should be able to handle that already, yes.

--

Sebastian Dröge, Centricular Ltd · http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

On Fri, 2016-06-24 at 10:04 +0200, Peter Maersk-Moller wrote:

Hi Peter,

> Assuming you are using mp4mux with h264parse prepended and assuming
> the stream could be ... lets say a RTP stream received using udpsrc,
> then you can send first a stream with frame rate A (and resolution X)
> and then frame rate B (and resolution Y). In theory h264parse should
> detect the frame rate change and in theory, it should signal that to
> mp4mux and in theory mp4mux should accept this and create a new entry
> describing the new condition, as it can with resolution change in the
> middle of a stream. If the code is there in mp4mux and h264parse,
> that ought to work.
>
> Likewise the demuxer should be able to detect frame rate change and
> resolution change and a player should be able to handle change of
> both resolution and frame rate during play. However implementations
> may not always be full.

MPEG-TS would likely be a better container for tha use case than
(traditional) MP4.

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