VLC 2.1.3 on iOS 6.1.3 crashes in at least 3 places in the file I will attach.
It crashes at about 1 minute 30 seconds in, and 26 minutes 50 seconds in. There's another spot later where it crashes too, and I can find that if necessary.
Just a (very) wild guess: Is vlc using libavcodec's flag "fast"?
It must not be used for corrupt input, the stream in question has errors (that trigger segfaults with -flags2 fast). See the comment above mpeg2_fast_decode_block_intra() in libavcodec/mpeg12dec.c
This actually happens in a huge portion of the files I try to watch.. and since it's relatively hard to get back to the same place and skip just past the crashing point, this is really a big day to day issue trying to use VLC on the iPad.
I saw that another one of my bugs is fixed in the next version (https://trac.videolan.org/vlc/ticket/9365). Since I now know about getting files to VLC via iTunes, that bug actually isn't very important to me.
But THIS bug makes VLC very very very difficult to use, since the vast majority of shows I try to watch crash at some point (so I have to watch the missed bit via some other means).. and have to carefully skip past the crashing point, etc..
Is there any chance this one will be fixed in the next version? This is actually by far the biggest issue I'm having with VLC.
I saw that another one of my bugs is fixed in the next version (https://trac.videolan.org/vlc/ticket/9365). Since I now know about getting files to VLC via iTunes, that bug actually isn't very important to me.
But THIS bug makes VLC very very very difficult to use, since the vast majority of shows I try to watch crash at some point (so I have to watch the missed bit via some other means).. and have to carefully skip past the crashing point, etc..
Is there any chance this one will be fixed in the next version? This is actually by far the biggest issue I'm having with VLC.
It should be fixed as soon as we have some samples and backtrace.
This is actually fixed in the current versions of libav and FFmpeg by increased bounds checking within the mp2v decoder, which had difficulties to deal with incomplete packets, usually received through MPEG TS encapsulated streams.
Btw, as long as I'm semi-nagging, the other issue, while way less serious, that greatly affects me is the wrong length shown for many shows... So I can't easily skip commercials for example. (I wrote a separate bug about this.)
This is actually fixed in the current versions of libav and FFmpeg by increased bounds checking within the mp2v decoder, which had difficulties to deal with incomplete packets, usually received through MPEG TS encapsulated streams.
Do you know which commit(s) fixed the problem? It might make sense for us to backport the relevant changes.
This is NOT FIXED in the newest version released a day or two ago (2.2.0). Or at least it still crashes for me, with the first video I tried. Since I can't tell for sure that it's the same bug, I'm writing up a new one and will comment here. If I could reopen this bug, I would.
I'm currently on my iPhone, and don't see any preferences along those lines.
Yes, I realize this is a bug in the iPhone version of vlc: It apparently actives "Allow speed tricks" by default (and you cannot disable the option), but this option should only be used for streams that are known not to contain any (reception) errors.