mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-10-05 02:02:26 +00:00
8ed7ab178b
Turns out that the "big-gap"-logic of the jitterbuffer has been horribly broken. For people using lost-events, an RTP-stream with a gap in sequencenumbers, would produce exactly that many lost-events immediately. So if your sequence-numbers jumped 20000, you would get 20000 lost-events in your pipeline... The test that looks after this logic "test_push_big_gap", basically incremented the DTS of the buffer equal to the gap that was introduced, so that in fact this would be more of a "large pause" test, than an actual gap/discontinuity in the sequencenumbers. Once the test was modified to not increment DTS (buffer arrival time) with a similar gap, all sorts of crazy started happening, including adding thousands of timers, and the logic that should have kicked in, the "handle_big_gap_buffer"-logic, was not called at all, why? Because the number max_dropout is calculated using the packet-rate, and the packet-rate logic would, in this particular test, report that the new packet rate was over 400000 packets per second!!! I believe the right fix is to don't try and update the packet-rate if there is any jumps in the sequence-numbers, and only do these calculations for nice, sequential streams. |
||
|---|---|---|
| .. | ||
| alpha | ||
| apetag | ||
| audiofx | ||
| audioparsers | ||
| auparse | ||
| autodetect | ||
| avi | ||
| cutter | ||
| debugutils | ||
| deinterlace | ||
| dtmf | ||
| effectv | ||
| equalizer | ||
| flv | ||
| flx | ||
| goom | ||
| goom2k1 | ||
| icydemux | ||
| id3demux | ||
| imagefreeze | ||
| interleave | ||
| isomp4 | ||
| law | ||
| level | ||
| matroska | ||
| monoscope | ||
| multifile | ||
| multipart | ||
| replaygain | ||
| rtp | ||
| rtpmanager | ||
| rtsp | ||
| shapewipe | ||
| smpte | ||
| spectrum | ||
| udp | ||
| videobox | ||
| videocrop | ||
| videofilter | ||
| videomixer | ||
| wavenc | ||
| wavparse | ||
| y4m | ||
| Makefile.am | ||
| meson.build | ||