SSRC change on an RTP stream should lead to BYE

[do_coredump]

Summary of the bug:

when receiving an elementary live video stream (e.g. h264) and the sender of the stream restarts, then the receiving ffmpeg entity ignores all incoming packets due to a different SSRC. This is bad when the sender is an embedded system which might restart any time.

I propose to return RTP_BYE in case a different SSRC is received by the demuxer in ffmpeg

Claus
How to reproduce:

SDP file : 
-----------------
v=0
t=0 0
m=video 35004 RTP/AVP 96
c=IN IP4 127.0.0.1
a=rtpmap:96 H264/90000
------------------
* run a receiving ffmpeg instance
** ffmpeg -protocol_whitelist udp,file,crypto,rtp  -i foo.sdp -vcodec copy -acodec copy foo.mp4
* run an ffmpeg version that creates an RTP stream
** ffmpeg -re  -i /tmp/sd.mp4 -vcodec copy -an -f rtp rtp:/127.0.0.1:35004
* kill this instance and restart it (without restarting the receiver)
** ffmpeg -re  -i /tmp/sd.mp4 -vcodec copy -an -f rtp rtp:/127.0.0.1:35004

Output on the receiving instance: 

output on the first receiving instance (relevant output only) : 
[sdp @ 0x55a8cba18780] RTP: dropping old packet received too late
    Last message repeated 528 times

built on ffmpeg version  origin/release/4.0

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.