Changing frame resolution during a RTP stream (possible BUG)

[filros1]

Hi.
I have to receive and see a multicast continous rtsp/rtp stream (which is streamed with the live555 lib). Unfortunately, the frames' resolution can change during the stream and VLC doesn't properly adapt its size according to it. But the real problem is that: if I shut down the VLC and re-open it again, it starts with the same initial screen size! it seems that it has "cached" this screen size somewhere, and it has associated it to the rtsp session .... In fact, If I shutdown and then play again the rtp stream, and then launch again VLC, THIS TIME the screen size is correctly set.
I think it is a bug: is there a solution for that, or at least a work around?
Thanks
Filippo

[Rémi Denis-Courmont]

The RTSP 1.0 protocol is not capable of signaling codec format changes. You should either use MPEG/TS (over RTP/RTSP) or wait for full RTSP 2.0 support, but the latter is not coming anytime soon.

[filros1]

The RTSP 1.0 protocol is not capable of signaling codec format changes. You should either use MPEG/TS (over RTP/RTSP) or wait for full RTSP 2.0 support, but the latter is not coming anytime soon.

Sorry but you did not get the point. read again the question, which shows a bug.
Note that Mplayer, for example. doesn't have this problem.

[Rémi Denis-Courmont]

I stay by my point. Obviously the sender is sending incorrect information until restarted. For sure, VLC does NOT cache this information across restarts.

[filros1]

I stay by my point. Obviously the sender is sending incorrect information until restarted.

You can stay on the point you want, but RTSP/RTP has NOTHING to do with frame resolution.
And this is a bug.
Please read the RTSP and RTP specification.

For sure, VLC does NOT cache this information across restarts.[

Yes, I suppose this too. And therefore I don't understand this strange behaviour.
There's something cached somewhere. Mybe it has something to do with the X-server ? (it could appear crazy, but I suspect so)

[Rémi Denis-Courmont]

RTSP and RTP, no. SDP yes.

[filros1]

RTSP and RTP, no. SDP yes.

when the resolution changes, during the stream, the screen size of VLC MUST CHANGE according to the new resolution. Mplayer does change it, vlc NO.
This is a bug.

[Rémi Denis-Courmont]

when the resolution changes, during the stream, the screen size of VLC MUST CHANGE according to the new resolution. Mplayer does change it, vlc NO.
This is a bug.

If and only if the information is transmitted solely inband and not in the session description, then it is a VLC/live/codec bug.

What does the SDP says?

[filros1]

Code: Select all

If and only if the information is transmitted solely inband and not in the session description, then it is a VLC/live/codec bug.

NO. NO.
IF the information CHANGES "inband" (regardless if an initial resolution is in the SDP) THEN the player has to change its size according to the new resolution.
Mplayer does that, and this is correct.
VLC doesn't do that and this is a fair bug.
There's nothing more to say, and I don't understand why do you insist so much.
I don't want to throw a flame, but I would like to signal this thread to vlc developers.
They will certainly understand what has to be corrected.

[Rémi Denis-Courmont]

There are two cases:

1/ The resolution (or any other codec parameter for that matter) is specified in the SDP, provided by the sender to the receiver at startup via RTSP DESCRIBE.
In this case, there is a promise from the sender to stick to these parameters for the duration of the stream. If the resolution (or any SDP-provided parameter) changes, the sender is violating the protocol and the bug is in the server. The receiver is free to do whatever it wants, be tolerant (like mplayer) or not.

2/ OTHERWISE, the parameters are not in the SDP. Then obviously they have to be transmitted inband, and the codec-specific standards will specify whether changing the resolution is allowed or not. For instance, if using MPEG Transport Stream over RTP, then it is allowed (and as far as I know, VLC will handle it fine).

Since you refuse to provide details this far, that's all there is to say.