 |
In commit 6899 fixed severe stuttering on AVI with XVID content. Before, raw PTS value from packet was used to calculate timestamp. Unfortunately, it is not set in some common cases, that's why everyone uses function av_frame_get_best_effort_timestamp to get effective timestamp. Now we use it too =) |
|
|
I have checked following combinations on a 720 x 400 video: AVI + XVID MP4v2 + XVID MP4 + x264 AVI + MPEG2 AVI + x265 - FAIL (no codec) All of them play well, except for the last one. It is simply not supported by FFmpeg yet. |
|
|
New issues are created for playing sound stream and using natural duration of video (see related). |
 |
I changed the ffmpeg use from static link to dll (win32 only) because it adds too much to exe size. We may want to revisit this later. |
|
|
It turns out that matroska (mkv) is not a good format for current player implementation. In a sample video I see, each sound packet contains 2048 samples, which corresponds to about 46.44 ms of time. However, all the packets in mkv has timestamps with millisecond precision - that's the limitation of format specification. That's why some sound packets have 46 ms duration, and some have 47 ms duration. Although timestamps and durations cover the whole timeline properly, they do not correctly reflect the real amount of samples encoded in them. As a result, current player has to drop or insert about 10-20 samples before each packets (jitter), which produces noticeable sound artifacts (cracks). I think it is much easier to limit support to MP4 container than trying to support every possible issue which might happen in one format or another... |
|
|
It turned out that even MP4 format sometimes starts dropping/inserting one sample regularly. This is not noticeable for voice, but test sound sample makes it clearly noticeable. So, I have made sound decoding resistant to timestamps jitter (up to 10 ms) in svn rev 6937. This makes it possible to play MKV files normally. However, I still think we should advise everyone using MP4. |
- Anonymous
