The VideoLAN Forums

I have a problem that I don't understand. We are using VLC v. 2.1.3 as an RTSP server screen scraping on Windows to provide video into a network. A system in the network using GStreamer is connecting to VLC to distribute the video into the network using multicast RTP. We have 2 systems setup, one in QA and the other in development. They were intended to be identical but don't seem to be. The clients in the QA system (that are using ancient VLC 1.0.1 to decode and display the video on Linux) freeze after 10 to 45 minutes. Clients in the development network (using the same OS/VLC/etc) don't seem to ever have this problem. I have found that in the h264 SPS in the QA network, the fixed_frame_rate_flag is 1 and the nal_hrd_parameters_present_flag is also 1. In the SPS in the dev system, both of these are 0. The SPS in the QA system then has the following fields: cpb_cnt_minus1: 656, bit_rate_scale: 14, cpb_size_scale: 3, bit_rate_value_minus1: 49, cpb_size_value_minus1: 0, cbr_flag: 0, bit_rate_value_minus1:0. That ends the SPS. It seems to be missing an rbsp_stop_bit and the rbsp_trailing_bits fields and maybe more. I got this information from wireshark which reports the SPS to be 'malformed'. My GStreamer application extracts the sprop_parameter_set from the RTSP conversation and inserts it into the RTP bitstream ahead of IFrames to allow clients to randomly connect and display current video.

I don't know if this SPS is causing decoding failures on the clients, but (so far) it is the only difference I have been able to isolate between working and non-working systems. VLC is launched on the screen scraping systems by another program which does additional network setup, so the launch is controlled and should use identical parameters.

1. Is is possible that this SPS difference is causing the client decoding failures?
2. Is there some configuration parameter that I can enter to disable the 'fixed frame rate' and the nal_hrd_parameters?

Thank you very much for any and all help!

Chuck Crisler

Update: this may be a bug but it isn't causing my display problem. I found that someone had adjusted the output resolution on 1 system. When I changed the 'failing' system to match the 'good' system, the SPS is now valid, but the original problem persists. So there does seem to be a bug in the SPS generation but it seems to work anyway.

We have found something else though. IFrames work fine. However, the update frames seem to often have a problem. There are many instances where an update (P) frame will have 200 - 400 bytes in the packet with the MARK bit set (MTU is 1400), but it will be followed by a packet with 62 - 70 bytes with the same timestamp and also having the MARK bit set. According to wireshark, the h264 data in this second packet will indicate that the first MB in the slice is number 0, which indicates a new frame. If it is a new frame then it should have a different timestamp. If it isn't a new frame, then the first MB in the slice should not be 0. There are typically 6-8 h264 bytes in the packet, which doesn't seem enough to describe a 1024 x 768 frame. This is clearly a problem. It looks like this second packet is being generated incorrectly and doesn't have any 'real' data.

Has anyone else seen this?