x264 video streams in mkv containers do not playback correctly within clip monitors with mlt 0.5.x.

Everything was flawless with mlt 0.4.x.

This is of course a very serious as no cropping / editing / zone selection can be done, with the needed frame accuracy.

Using:
- mlt 0.5.10
- kdenlive 0.7.8
- nvidia driver 256.53
- 9800GT (VDPAU capable)

Steps to reproduce:

1. Insert any Matroska (mkv) container with an H264 video stream into the project (project tree).

2. Go to clip monitor to do a playback in order to select a zone. You see fully black or white frames in random times (moments).

Again the same will happen if you select a zone from the clip monitor, drag the clip to an empty video track in the timeline, and attempt to preview the "finished" product on the project monitor. The same behavior occurs there as well.

I just converted a MP4 to MKV with copy:
ffmpeg -i bbb_youtube_h264_499kbit.mp4 -vcodec copy -acodec copy bbb_youtube_h264_499kbit.mkv

And it works just fine here for me. Please test playback of the mkv in ffplay and do some seeking about by clicking in the window (horizontal axis) and let it play for a bit after seeking. Do you see similar problems? If not, can you share a file that exhibits this problem?

It does not happen with just one file but virtually with any H264+mkv file I have.

smplayer+mplayer play it flawlessly, as vlc does.

I just tested two of those in ffplay.

They both play and seek flawlessly, both forward and backwards, for as long as you want.

The only way to get in a working system for me, is to take the last svn before 0.7.8 was tagged (because it requires mlt 0.5.x). Because any version before 0.7.8 works with mlt 0.4.x.



PS: Using now svn 4885 with mlt 0.4.10 and it works flawlessly.

Unfortunately it doesn't work, because the render quality of mlt 0.4.10 is simply horrible.

So until you fix this critical bug - the ability to playback smoothly content in the monitors with mlt 0.5.10 - the whole app is completely useless.

Until you can provide a sample clip or explain what tool and version was used to create the mkv files you are using this non-critical bug report is completely useless. Seriously, you should check your tone; I don't work for you.

I agree that you do not work for me.

However it is evident, that even since mlt-git was tagged into 0.5.x version, you have not done even the most basic of testing for the most simple (and yet most) essential task -> video playback of source material on the monitors so that someone knows exactly where to cut, with frame-accuracy. Had you done such testing, this critical showstopper bug would not exist.


PS: The version of the tools used to create these files does not matter because I have dozens of different files experiencing the same problem, all of them created with literally every single version of mencoder / mkvmerge / libebml / libmatroska and so on. In fact there is not a single mkv / H264 / AVC-1 container / video-stream that I have tested, to playback correctly with mlt 0.5.x.

PS2: Video files are large.

How may I provide such a sample to you?

You are correct that I have not been testing H.264 MKVs. I do not have any H.264 MKV samples to test with regularly because I am not involved in p2p file sharing, and I tend to use the more standard MP4 and MPEG-TS containers (per ISO and broadcast standards, cameras, and player/device compatibility). Considering this is the first and only report of this problem, I feel my priorities are not wrong for not having tested this. Also, I admit I do not do enough testing in general because there is much work to do. I must rely upon the community to do testing and providing feedback. That is the nature of many open source projects.

I explained how I created a mkv for testing the initial problem report but failed to reproduce. You can provide a ffmpeg command line that produces a file from whatever and that also exhibits the problem. You can upload one of your smaller samples to a web server or rapidshare.com or similar service. You can also direct me to one that is publicly available elsewhere.

If you suspect this could be a vdpau compatibility problem, there are a couple of things to check/test. First, see if your build is actually using vdpau:

$ melt -debug some.mkv 2>&1 | grep vdpau

I think the messages should be obvious if it is enabled. If so, test playback/seeking without vdpau:

$ melt some.mkv novdpau=1 in=80

melt will display transport control key-command help so you can test stepping/jumping.

Also, to test without vdpau in Kdenlive:

$ MLT_NO_VDPAU=1 kdenlive

I use h264 in .mkv extensively by demux/remuxing the .movs off my Canon 550D with mkvmerge and have zero problem with playback in the clip monitor of even the latest kdenlive svn from sunabs PPA. But the builds don't use vdpau. :-)

The test with melt you suggested helped a lot.

Behavior is the same as in the kdenlive monitors.

Every time (these occur at random) I have - instead of a frame displayed - a white flicker, I get these messages on the console:

[producer avformat]
got_pic 0 key 0
[producer avformat]
pkt.dts 23232 req_pos 98 cur_pos 544 pkt_pos 558
[h264_vdpau @ 0x7f5d10] Frame num gap 12 4
[producer avformat]
vdpau_get_buffer
[producer avformat]
VDPAU surface underrun
[h264_vdpau @ 0x7f5d10] get_buffer() failed (-1 0 0 (nil))
[h264_vdpau @ 0x7f5d10] decode_slice_header error
[h264_vdpau @ 0x7f5d10] no frame!

With the last three lines in dark brown/red letters.

Such events occur several times per second, during playback.

I also tested afterwards playback without VDPAU.

It is completely flawless, just as it was with mlt 0.4.x.

I also launched kdenlive with mlt's VDPAU support disabled and attempted playback through the video monitors.

Again it is completely flawless, just as it was with mlt 0.4.x.

Again thank you for your time.

It seems that with your help we have isolated the problem.



PS: You said that to test without VDPAU in kdenlive I have to enter:

$ MLT_NO_VDPAU=1

Before launching kdenlive.

I assume this is an environment variable.

Is there any config file - either in mlt or kdenlive - where I can make this permanent?



PS2: If you need any help in further testing/debugging VDPAU behavior in mlt/kdenlive I am offering myself for assistance.

I know how to built mlt-git and kdenlive-svn packages - in fact I do that at least once per week.

OK. I was wondering how much grief the automatic nature of the VDPAU implementation might cause some people. Since I have not received much complaints or problem reports relating back to that, it seems to work fine for most. I did implement and test it on fairly low end NVIDIA hardware. From the error, it looks like there is vdpau decoder compatibility problems with that H.264. Do the same files play fine with vdpau enabled/used in another video player and after seeking?

There is no other way to configure Kdenlive to not use VDPAU. You can export the environment variable in $HOME/.profile but it seems not all environments source that on startup to make it available when launching apps from menus or panels - your mileage may vary. If you are launching kdenlive from a terminal window, then it will most certainly source it.

When making a build of mlt, theeasiest way right now to disable vdpau is to remove VDPAU=1 from src/modules/avformat/config.mak after running configure but before running make. I wil add a configure option to disable vdpau.

1. There are at least 3 or 4 different classes of nVidia VDPAU-capable hardware (I have an 9800GT card).

2. There are 3 different VDPAU feature sets (A, B and C), but this may not affect at all mlt.

3. And yes, all these files play and seek flawlessly with smplayer+mplayer using VDPAU, both in rendered and in decoder.