> On Jan 8, 2021, at 3:21 PM, Benjamin Lowe <benja...@sc0ville.com> wrote: > > The first clip saves fine, but all subsequent clips show some corrupted > frames for the first second or so, you can see an example corrupted clip: > https://drive.google.com/file/d/1QXJmnjhW68mFlzW5bTOZafDGHjasMNld/view?usp=sharing > > And a healthy clip: > https://drive.google.com/file/d/16RS9gp8i7f_xTRWRwSanQ5lVFQfgVGTF/view?usp=sharing > > I would be very grateful if anyone has any suggestions as to the cause?
What’s happening here is that the recorded H.264 video stream (except for the one at the very start) does not begin with a ‘key’ frame - i.e., a complete picture. Instead, the stream - starting at the 30s, 60s, 90s, etc. point - begins with partial frames, and you have to wait for about 1 second until you (or, more precisely, the H.264 decoder in your video player) see a key frame. These initial frames not ‘corrupted’, just ‘incomplete’. Because “openRTSP does not do any decoding of the incoming H.264 video stream (instead, it records the incoming H.264 video stream data ‘as is’), there’s not much we can do about this. (In principle, we might try to figure out when the stream contains a ‘key’ frame, and then delay the closing of the current output file, and the opening of the new output file, until that point (beyond the normal 30s, 60s, 90s, etc.). However, that would add a lot of complexity to the code, for little benefit.) Instead, you should just accept that the first <1 second of each recorded clip (except for the first) might contain only partial frames. Ross Finlayson Live Networks, Inc. http://www.live555.com/ _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
