MPEG-PS seek problem

[balazs-adam]

I'm having troubles opening an Mkv file with MPEG-PS format on Windows 10. I can open the file and play it but at first it doesn't show any frames just a blank white space and I can only see the progress on the seekbar. If I try to seek using the seekbar it jumps to the very end and stays there while the video starts to play from the beginning (in perfect quality). Any other attempt to seek restarts the video playback and it doesn't jump to the desired point.

The video file is from a Foscam IP camera and I now that it's format might have some problems because other players (VLC, KMPlayer) can open it but they all have playback issues after seeking (but at least they can seek). I've also tried PotPlayer and it works fine, even seeking.

I've tried to set all of the video codecs listed here with the parameters option but still no luck. https://www.ffmpeg.org/ffmpeg-codecs.html

Any idea what might be the problem? Thanks

Here's the file in question: http://1drv.ms/1l6eSvF

and here's the file info:

General Complete name : D:\Music\alarm_20151025_051811.mkv Format : MPEG-PS File size : 2.30 MiB Duration : 36s 682ms Overall bit rate : 527 Kbps

Video ID : 224 (0xE0) Format : AVC Format/Info : Advanced Video Codec Format profile : Baseline@L3.1 Format settings, CABAC : No Format settings, ReFrames : 1 frame Format settings, GOP : M=1, N=60 Duration : 36s 682ms Width : 1 280 pixels Height : 720 pixels Display aspect ratio : 16:9 Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive

Audio ID : 192 (0xC0) Format : AAC Format/Info : Advanced Audio Codec Compression mode : Lossy

[balazs-adam]

I've found a kind of a workaround. It seems that in the MediaSampleProvider.GetNextSample method when we get the current AVPacket, the packet's presentation timestamp is incorrect (it's actually larger that the duration of the movie I'd like to play). This timestamp should be 0 at the very first packet but it isn't.

Fortunately this error is consistent meaning that each AVPacket presentation timestamp is larger than it should be by the first packet's timestamp (because that one's should be 0). So if I save this constant "offset" at the first packet (the offset equals with the first packet's timestamp) and subtract it from every packet's presentation timestamp the video works just fine with seek and everything.

Obviously it's not a rock solid solution but hope it helps to finding out what really happens with these files.

[khouzam]

Hi @senkia

Can you issue a pull request with your change and we can evaluate if this is an appropriate solution or if we can adapt it to a more general case?

[reego-fr]

Hi,

you are experiencing the same issue that occurs when playing TS files or program streams from some VOB files. I talked about it here: https://github.com/Microsoft/FFmpegInterop/issues/24 What I use to prevent it is in this branch: https://github.com/reego-fr/FFmpegInterop/tree/branch-mediaStartTimeFix

Hope this helps.

[balazs-adam]

Thanks. I just checked out your solution and it seems to work fine with my files too although sometimes if I seek into these files the playback stops (but the seekbar and time display goes on) and I have to reseek again to resume playing.

[reego-fr]

Regarding the seek issue, you may want to set the BufferTime to 0 as discussed here: https://github.com/Microsoft/FFmpegInterop/issues/20 As said by @timotiusmargo this is a temporary workaround and may improve the situation when playing compressed samples too as in your case, although only uncompressed samples were mentioned at that time. I was able to find the "buggy" position in your file, between 4s and 6s. It should be helpful to test other fixes that accommodate for ffmpeg's seek imprecision vs. what Media Foundation expects without needing to set the BufferTime to 0.

[reego-fr]

Unfortunately, none of the tweaks I had in mind improved the situation when seeking between 4s and 6s. Setting the buffer time to 0 looks like the only thing that helps unless I did something wrong in my tests.