Menu

#53 Improvents to video handling

Trunk
open
nobody
None
1
2015-06-29
2015-03-29
No

Well, I think they are improvements.

Patch 1 and 5 fix bugs I observed, but I don't know if they happen with FFmpeg as well (I use an old libav version). Libav deprecated r_frame_rate but while my
version still has that field, there were some videos where it was 0, making fFrameDuration a NaN. This caused the video to run as fast as possible.

The problem I fixed with patch 5 was that one video didn't like seeking backwards from timestamp 0. Its first frame was at 0.02s and when av_seek_frame failed, the
video would not play.

Patch 1, 2, and 3 fix problems with a carefully crafted mkv file that is more like a discontinuous slide show than a video.

Patch 4 was my first attempt at fixing the problem finally fixed by patch 5.

5 Attachments

Discussion

  • Brian Chalega da Silva

    Hi Daniel, I'm really sorry, had forgot to comment on this one.

    Can you provide video files for me to test if the same problems can happen with ffmpeg?

    ps.: Video files that are not protected by copyright hehehe

     

    Last edit: Brian Chalega da Silva 2015-04-27
  • Daniel Glöckner

    Here is the "slide show" video.
    It should play for 20 seconds.
    The other videos I can't share.

     
  • Brian Chalega da Silva

    I took a look at the patches but I have to admit that I'm still too inexperienced in the ffmpeg video processing code to review then... We would need to be confident that the changes won't have bad side-effects or make regressions, anyway the patches being here they won't get lost and can be used in the future, thanks for taking your time to make then.

    Anyway, here are some quick tests about the mkv:
    Mplayer: The video plays as you said (20 seconds).
    FFPlay: Same as above
    VLC: The video don't reach the end, it goes up to "0:11-0:12" and stop
    USdx with ffmpeg: It doesn't crash, but the video stay static in "0:00-0:10".

    Sorry for getting off-topic, but as you are interested in the media code, I wonder if you could help with a bug that is present since the changes in ffmpeg 1.0, when the default decoded format was changed from AV_SAMPLE_FMT_S16 to AV_SAMPLE_FMT_S16P making ogg vorbis, for example, currently unplayable.

    What need to be done is to resample the audio to AV_SAMPLE_FMT_S16 (with swresample) in order for sdl to play it correctly, but if you could update the UAudioDecoder_FFmpeg.pas to use avcodec_decode_audio4 would be a great help already.