<div dir="ltr"><div><div><div><div>Hi Sabastian.<br><br></div>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.<br><br></div>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.<br><br></div>Regards<br></div>PMM<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 24, 2016 at 9:47 AM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Do, 2016-06-23 at 20:03 -0700, ht techdev wrote:<br>
> Hi<br>
> Is there a way, within gst-launch, to change the frame rate on fly?<br>
> Failing that is it possible to append to an existing encoded file,<br>
> using a different rate:<br>
>  <br>
> gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw,<br>
> framerate=\(fraction\)”30/1” ! \ ! x264enc ! filesink location=t.mp4<br>
> gst-launch-1.0 videotestsrc is-live=true num-frame=10 !  video/x-raw,<br>
> framerate=\(fraction\)”50/1” ! \ ! x264enc ! filesink –append<br>
> location=t.mp4<br>
<br>
</span>With gst-launch-1.0 you can't do it, with actual code you relatively<br>
easily can (you "just" change the framerate).<br>
<br>
Appending MP4 files is not easily possible, you would at least have to<br>
remux them but for full correctness you would also have to reencode the<br>
h264 stream as the avcC struct (the "header") is going to be different<br>
for both encodings in your case and that's not really allowed by the<br>
spec (there can only be one).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<br>
Sebastian Dröge, Centricular Ltd · <a href="http://www.centricular.com" rel="noreferrer" target="_blank">http://www.centricular.com</a></font></span><br>_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br></blockquote></div><br></div>