search

samirkumardas / jmuxer

jMuxer - a simple javascript mp4 muxer that works in both browser and node environment.
Other
556 stars 113 forks source link

I'd like to ask you a question #37

Closed 771445191 closed 4 years ago

771445191 commented 4 years ago

Is it possible to realize the frame by frame transmission of h264 code stream through websocket, and each frame is transferred to jmuxer

samirkumardas commented 4 years ago

If you provide a valid frame, it should work but you may face scrambled video

771445191 commented 4 years ago

very thank！

771445191 commented 4 years ago

In order to reduce the delay, a frame of h264 is continuously transmitted through websocket. What's the best way to play it on the web without plug-ins? Thank you very much.

samirkumardas commented 4 years ago

Instead of feeding a single frame at a time, it is recommended to feed a chunk of frames as WebSocket itself has a latency. Good luck.

771445191 commented 4 years ago

Thank you very much. I'll consider your answer

771445191 commented 4 years ago

So I provide a GOP (only video) as the input of jmuxer, without a 2-byte duration, but I provide FPS, can it work? I'm a little confused

samirkumardas commented 4 years ago

2-byte duration is not necessary. It was just a demonstration. If you provide all NAL units (picture frames i.e., GOP and non-picture frame SPS, PPS, etc.) properly, it should play.
Finally, you must provide one timing parameter i.e., either duration or fps. As you are giving fps, you are on the right track.

Why do you need timing information?

Because you are providing raw frames and these raw frame does not contain any timing information how long each frame will have to play. Think about HLS or DASH protocol, we get the timing information from HLS chunk or packet NOT from video data. By the way, I added this timing comment for the users who will come across here to know why do they need to provide duration or fps.