H264 to streamable mp4

[Rūdolfs Bundulis]

Well, ok, then at least it is clear that the whole content itself is fine,
it is the offset that matters.

> It is a remote rtsp source from a chip-on-board device that streams H264
> video. The rtsp stream is catched on the server and restreamed locally for
> http clients and a recording service.

So in general you are making some kind of NVR solution? :)

2016-04-27 17:52 GMT+03:00 bomba <jhonata.poma at gmail.com>:

> Rudolfs Bundulis wrote
> > As for the Chrome info - well it seems that it gets the initial metadata,
> > but what goes on after who knows - i know that Chrome is picky about how
> > the fragments should be constructed.
>
> The first stream is actually doing really good, only problem is you have to
> catch it as it starts :) this behaviour is not what I need for my web
> application: a client should be able to connect anytime and start playing
> the live stream from the next keyframe, keeping latency stretched to 1
> second.
>
>
> Rudolfs Bundulis wrote
> > What is the source of the video?
>
> It is a remote rtsp source from a chip-on-board device that streams H264
> video. The rtsp stream is catched on the server and restreamed locally for
> http clients and a recording service.
>
>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/H264-to-streamable-mp4-tp4677114p4677169.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160427/484f005d/attachment.html>