Play live and archive video error with wrong PPS

[frankchen]

Hi there,
We are integrating a new brand IPCAM, and found something weird. In the beginning, that IPCAM can be normally viewed in both live and archive playing. Until one day, we change it's bitrate setting, from that time, it can't be viewed normally any more. We've analyzed the archive mp4 file by some media tools and found the failed reason.

The reason is when the bitrate of the ipcam be changed, it will change the PPS parameter. But unreal archive server still use the old PPS and stored it into mp4 file. It caused the archive video be played abnormally. Would you please kindly fix this kind of bug.

Thanks very much.

--Frank

[admin]

The Archival Server takes PPS from the stream itself. So it's a camera problem that provides the old PPS although since the bitrate is changed, it needs to provide a new PPS in the response to RTSP describe request.

[frankchen]

The reason why the mp4 archive video can not be played normally:

1.Before Camera sending I Frame out, it will send SPS/PPS first, that is why a player can normally play the video.
When user change the H.264 parameters of the camera, it’s SPS/PPS will be changed as well. That is necessary for player for normally replaying the video.

2.SPS + PPS + I Frame will be stored in the same Sample when recorded by VLC , and the PPS is correct. What I meant is that PPS is correctly recorded by VLC after user changing H.264 parameter of camera.

3.But Unreal Archive Server first store SPS/PPS, then SPS+PPS+I Frame.
In that moment, user change some parameter, camera change it’s PPS, too. But Unreal store the original PPS, not the newest and updated PPS.

Frank

[admin]

Do you mean that user changes parameters while Archival Server already started recording?
In this case, sure, it cannot work correctly. A single .mp4 file cannot have more than one SPS/PPS set for the same video track.

Note that the Media Server and Archival Server take SPS/PPS not from the stream itself, but from RTSP describe command response,
which is received when Media Server just asking the camera - what format is supported. That happens right before RTSP play command.
VLC doesn't care about RTSP describe command response, it takes SPS/PPS from the stream itself. We cannot do that.

[frankchen]

Hi there,
Very disappointed to hear this answer.

For a video surveillance system, changing parameters of ipcam's is not a unexpected thing.
Ipcam has done what it can do, sending the correct PPS. But media server just don't care about that, and lead to wrong video playing.

I think it is not a tough job to record the right PPS value into archive file, like VLC and wowza server can do. Hope you can fix it ASAP.

Frank

[admin]

changing parameters of ipcam's is not a unexpected thing

Yes, but not in the middle of live streaming. Normally, the camera will stop streaming when you do that. So you need to open a player again.
So Archival Server will work just fine if you start archiving after you changed the camera settings.

But I don't think any program will be able to record correctly if you change camera settings while it's streaming. Can you even do that? Your camera doesn't stop streaming when you change settings? Hard to beleive...

[albert.liao]

Dear admin,

Recently, some application may keep RTP stream connection even when argument is change, which means the SPS/PPS will be changed midstream.
For example: TV broadcast, Camera live stream.
The bit rate and resolution may be changed midstream.

To support this situation, FFmpeg has provide a solution. When user invoke av_interleaved_write_frame(AVFormatContext *s, AVPacket *pkt), if the AVPacket contains new SPS/PPS named SPS2 and PPS2, FFmpeg will update the SPS/PPS value in TRAK box. For example:
(SPS1,PPS1,I-Slice)(P-Slice)(P-Slice) ... (SPS2,PPS2,I-Slice)(P-Slice).

The final mp4 will contain SPS/PPS information in 2 place.
First place is AVC box. The SPS/PPS in AVC box keep the original value without any change, which means SPS1/PPS1 is still in AVC box.
Second place is TRAK box. Each I-Slice sample combined with SPS/PPS is always mapping to the correct SPS/PPS value.

With this small modification, the decode engine can render the I-Slice without any problem.

I think it is good if archive server can support this feature.

[admin]

Thanks for detailed explanation, we will see what can be done.