H264 to streamable mp4
Locked
12
12
 
|
0000000 0000 3c01 6f6d 666f 0000 1000 666d 6468 0000020 0000 0000 0000 0f00 0000 2401 7274 6661 0000040 0000 1800 6674 6468 0000 2800 0000 0100 0000060 0000 6400 0100 c000 0000 0401 7274 6e75 0000100 0000 010a 0000 1e00 0000 4401 0000 8f18 0000120 0000 f401 0000 df18 0000 c800 0000 0f18 0000140 0000 0000 0000 1c18 0000 6400 0000 3918 0000160 0000 9001 0000 1318 0000 c800 0000 ff17 0000200 0000 0000 0000 b11b 0000 9001 0000 0f18 0000220 0000 c800 0000 2518 0000 0000 0000 7f18 0000240 0000 f401 0000 1819 0000 c800 0000 3718 keep in mind that this is a live source. The muxing problem could be originated by GStreamer not passing the required * atom when the client connects. |
|
|
Ok, this was the first really useful piece. Yeah, it seems that the data you have is actually not the beginning - it has a moof atom (which simply denotes a fragment), but that is useless without an initial moov. Ok, I guess this is where GStreamer knowledge is needed - how to make the source spit out proper content starting from the beginning for each client. That is why I tried to stress that you connect to a fresh pipeline - then I *assume* the very first connect could even work, but again not sure. But yeah, it seems that all the future connections get the data simply from the point where the pipeline is at the moment. Maybe using files is really a better idea, but that can possibly create latency. 2016-04-27 16:15 GMT+03:00 bomba <[hidden email]>: Rudolfs Bundulis wrote _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
I can attach to the first stream if I delay the pipeline start and refresh the browser. No luck on the second one or if I attach the browser after pipeline starting. The correct headers are being sent only at the beginning of the stream. This is a muxing/sinking problem definitely.
Any suggestion, hints, trick? |
|
|
I've got a personal reply from Jan Schmidt:
|
|
|
This is chrome://media-internals/ on the catched-while-starting
render_id: 280 player_id: 16 pipeline_state: kPlaying event: PLAY url: http://192.168.1.30:8080/ is_downloading_data: true total_bytes: -1 streaming: true single_origin: true passed_cors_access_check: false range_header_supported: false buffer_current: 2195456 buffer_end: 2242576 buffer_start: 100776 info: FFmpegDemuxer: created video stream, config codec: h264 format: 2 profile: h264 baseline coded size: [640,480] visible rect: [0,0,640,480] natural size: [640,480] has extra data? true encrypted? false duration: 1.3932 found_audio_stream: false found_video_stream: true video_codec_name: h264 width: 640 height: 480 coded_width: 640 coded_height: 480 time_base: 1/20000 video_format: PIXEL_FORMAT_YV12 video_is_encrypted: false max_duration: 1.3932 start_time: 0 bitrate: 1326434 video_dds: false video_decoder: FFmpegVideoDecoder |
|
|
In reply to this post by bomba
Well sadly I can't help much any more:) Let's hope someone more familiar with GStreamer will be able to advise you. I hope that it's not like such behavior is not possible by design. 2016-04-27 17:07 GMT+03:00 bomba <[hidden email]>: I can attach to the first stream if I delay the pipeline start and refresh _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
This post was updated on .
And as Jan said, it looks like this is not possible by design. Is it possible to embed H264 video in HLS or DASH keeping latency <= 1 second? |
|
|
In reply to this post by bomba
Seems that you are out of luck:( 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. 2016-04-27 17:24 GMT+03:00 bomba <[hidden email]>: This is chrome://media-internals/ on the catched-while-starting _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
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. 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. |
|
|
In reply to this post by bomba
I guess it should be, if the file sizes are small enough but I have no experience with HLS or DASH. My personal view: the issue with HLS is that if you don't already receive the data in an MPEG TS you have to mux the raw H264 into a MPEG TS which as far as I understand is subject to patents and that is where MPEG LA kicks in. As for DASH, i know that you can use mp4 files there but I'm not sure about the browser support. Firefox mentions only WebM (https://developer.mozilla.org/en-US/docs/Web/HTML/DASH_Adaptive_Streaming_for_HTML_5_Video), but of course you have external libraries like dash.js. 2016-04-27 17:39 GMT+03:00 bomba <[hidden email]>: Rudolfs Bundulis wrote _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by bomba
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 <[hidden email]>: Rudolfs Bundulis wrote _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Kind of, yep. I'm trying to keep things HTML5 based - very fast and portable. Luck/Unluck: the camera that acquires the video at the first step natively encodes H264 - that's the reason why I'd like to stick with MP4 and avoid transcoding in the whole process. |
|
|
Clear. Well since I just finished HTML5 live streaming for the NVR system our company makes I can assure you are in for a lot of fun:D Had to debug both Firefox and Chrome to make it work and even with that there are still open bugs in Chrome:) > So in general you are making some kind of NVR solution? :) Kind of, yep. I'm trying to keep things HTML5 based - very fast and portable. Luck/Unluck: the camera that acquires the video at the first step natively encodes H264 - that's the reason why I'd like to stick with MP4 and avoid transcoding in the whole process. -- View this message in context: http://gstreamer-devel.966125.n4.nabble.com/H264-to-streamable-mp4-tp4677114p4677174.html Sent from the GStreamer-devel mailing list archive at Nabble.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 |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |