CODEWITHSUNDEEP
ffmpeg
Joe Quinn
Joe Quinn

Reputation: 1

FFMPEG H.264 to JPEG for real time video

Any help appreciated.

We are trans-coding H.264 streams into Jpgs which are sending across a web socket to the browser. The reason we are looking to do this is so we can deliver real time video to a browser natively. No need for plugins in a browser agnostic way. If there is a better way to do this then it would be great to know more. The Videos source are H.264 though and we cant change that.

As we lower the FPS we are seeing a greater lag in the camera video feed. e.g at 1 FPS we see the video in the browser is 8 seconds behind. at 15 FPS the video is about 1 second behind. So even though at 1 FPS it updates every second the frame is 8 seconds behind.

We think this is because FFMPEG with the lower frame rate has to wait longer for an I Frame and wont send a Jpeg to the web socket until it has a complete one. We would rather it sends a the Jpeg without having to wait till the IFrame arrives, we would rather see a partial image that gradually gets filled in on the browser. We cannot tolerate a lag of greater than 0.8 seconds in the browser. When the cameras are set to send MJPEG we see 0.250 seconds lag. With H.264 we see 1.25 seconds and we need to get that down to 0.8 seconds. So we really are looking to fine tune H.264 to shave off some time. That's why when our first approach to lower the FPS made things worse we were surprised so wondering what else needs to be fine tuned in step with the FPS to get a good result.

Is there any option to FFMPEG that tells it to send Jpegs as soon as the first piece of data arrives? OR maybe we should look at other tuning avenues?

Here are the FFMPEG parameters: ffmpeg -buffer_size 1024000 -r 15 -i rtsp://10.140.150.92/02441987-0826-4dc2-b9bd-62efdc0dd951/02441987-0826-4dc2-b9bd-62efdc0dd951_vs1?token=02441987-0826-4dc2-b9bd-62efdc0dd951^LVEAMOKTD^100^40^26^1500482113^a97effd2a6f85c4a0b5e93953b27c8e1eb40ca77&username=USER1 -f image2 -multiple_requests 1 -icy 0 -chunked_post 0 -q:v 31 -vsync 1 -r 15 -vf scale=640:-1 http://127.0.0.1:58014/video/cameraTag_deviceId_22cameraUid_-1scale_640:-1cameraOrigin_requestedStreams_videostream1/frame-%03d.jpeg

Many Thanks, Joe.

Upvotes: 0

Views: 760

Answers (1)

Brad
Brad

Reputation: 163232

We are trans-coding H.264 streams into Jpgs which are sending across a web socket to the browser.

Why would you ever want to do this?

As we lower the FPS we are seeing a greater lag in the camera video feed.

You're lowering the FPS, so therefore there is going to be a greater time in between frames...

We think this is because FFMPEG with the lower frame rate has to wait longer for an I Frame and wont send a Jpeg to the web socket until it has a complete one.

No need to wait for I frames to extract JPEGs from video, but who knows as you didn't show us your FFmpeg command so it's impossible to say which of the 999 methods you're using for this.

We would rather it sends a partial Jpeg

Presumably, you mean you'd rather have a complete JPEG for the current frame, even if it's not an I frame from the source video, correct?

as we can not tolerate a lag in the video player

You're using completely the wrong technology for everything here if this is a real concern.

I probably should have posted all this as a comment, but there was too much here. If you can fix your question and tell us what it is you're trying to do, I'll delete this answer and post an actual answer.

Upvotes: 2

Related Questions