That's why the webm spec suggests each Cluster begin with a key frame. If all you have access to is the webm container format data stream, and you treat the video SimpleBlocks as opaque, you cannot reliably detect key frames. (But I haven't been working on this in a while.) I believe it's necessary to use a new MediaRecorder instance to initiate a new stream when a new viewer wants to start watching. I've never had success trying to feed a player without providing it that header data.
There's a whole mess of header data at the beginning of the Matroška (EBML) file that's necessary to make sense of the data in Clusters. i need to get it work via mediarecorder only in my situation it is not right solution. if you help me i m gonna be happy :)Įdit: I also tried ffmpeg.js but on browser ffmpeg works sync on worker, so i can not feed stding with it. So if every cluster start with keyframe, why mediasource can not play it ? i couldnt solve this yet. My temporary solution is when someone join the socket, start recording again from streamer and its working but it is annoying 300ms freeze on video element. i can not use ffmpeg because of cpu usage. there is no information about it except your answers. I also tried parsing clusters and send via normal request from video element. because i got start of cluster no need to parse another coming packets. i add mediasourcebuffer after init data and i do not check again. so after that i am waiting next cluster on watcher side when i see first time 1f 43 b6 75. so it is init data for users who connect websocket. I am parsing mediarecorder data once until first 1f 43 b6 75. I am using websocket instead pure http stream because when streamer stop and start again. if someone start watching from begining, he/she can watch the stream. Tools exist to create seekable files from MediaRecorder-flavored Matroška hello sir.
#Xvid4psp video track in san seekable software
So, good software that tries to do this sketchy Cluster-detection will need to be able to abandon a potential Cluster if it doesn't turn out to be real. There's no guarantee that the 12-byte sequence I mentioned will not recur elsewhere in a stream. From those it's possible to recover the 'avcC' metadata needed for VideoDecoder's scription value. And, if the video codec in use happens to be H.264, the SPS and PPS NALUs will appear in the first SimpleBlock of the Cluster. Therefore, for what it's worth (and contrary to the advice of Matroška's designers) it should be possible to scan a Matroška stream for this sequence of bytes 1f 43 b6 75 01 ff ff ff ff ff ff ff to find the beginning of a Cluster. And those streaming Clusters have indeterminate length (all 1s in the length field). And Clusters have one of those four-byte EBML tags, specifically 1f 43 b6 75. Some streams last a few seconds others last hours.īut, each Cluster of that Matroska stream happens to begin with a video key frame.
It's hard to imagine how a stream of indeterminate length, like the ones generated by MediaRecorder, could usefully be made seekable. MediaRecorder generates streaming Matroška.
0 kommentar(er)
