Packet Loss Crash

[Queueball]

I'm getting a crash on VLC with version 0.8.6b caused by what I believe is packet loss.

We have MPEG2/4 streams coming over a satellite connection and thus bandwidth is capped to a certain level by necessity. If the video coding source is pushing a higher MTU than the satellite allows, then packets are dropped. This is fine and expected.

VLC attempts to play the stream with the packets available, which comes up as a colored mess along with intermittent slices of the video. Eventually VLC will crash.

The debug report is as follows:

Code: Select all

main warning: late picture skipped (19126) main warning: late picture skipped (21992) main warning: late picture skipped (3250) main debug: decoded 103/105 pictures main warning: vout synchro warning: pts != current_date (-33100) main warning: backward_pts != dts (33100) main warning: backward_pts != current_pts (33099) main warning: vout synchro warning: pts != current_date (-33300) main warning: backward_pts != dts (33367) main warning: vout synchro warning: pts != current_date (-33367) main warning: vout synchro warning: pts != current_date (-33301) main warning: backward_pts != dts (33300) main warning: backward_pts != current_pts (33299) main warning: vout synchro warning: pts != current_date (-33567) ts warning: discontinuity received 0xa instead of 0x1 (pid=32) ts warning: discontinuity received 0x1 instead of 0x8 (pid=32) ts warning: discontinuity recieved 0x8 instead of 0xf (pid=32) ...

Also during the crash it points to the liblibmpeg2_plugin.dll when viewing MPEG2 video and the libffmpeg_plugin.dll when viewing MPEG4 video as where the error occurred. At offset 0x00016681 for MPEG2 and 0x001282bb for MPEG4.

Not that it matters, but this issue also affects previous versions of VLC ( tested with 0.8.2, 0.8.5, 0.8.6, 0.8.6a).

[s3rg3]

Wow!!! Finally, somebody with the same configuration and ... the same problem...
I've only one question : have you solved your problem?

[janezp]

Wow!!! Finally, somebody with the same configuration and ... the same problem...
I've only one question : have you solved your problem?

I am curious, since I had similar experience (mpeg4 over wlan, late frames, etc...), but I think such
behaviour is, ehm, normal?

1. the garbled video is expected - what should the decoder do when there is not enough information?
2. the warnings about late frames and subsequent drop of connection can be maybe (partially?) solved with large cache size, but video will still be unwatchable (there is information missing... vlc cannot do anything)
3. maybe the experience could be improved using this trick: viewtopic.php?f=2&t=46559
4. regarding the crashes ... I think it is clear that at least one (if not both) of the crashes occured in ffmpeg, which is external video decoding library, used by vlc. So the proper address for this issue would be ffmpeg developers.
5. still, regarding the crashes - are you sure they should not happen? what do standards say about corrupted streams? Obviously ffmpeg does not handle well streams that have chunks missing, but the question is if it is required to handle them gracefully, or whether this is anywhere high on the developers priority list (I figure not).