MP4 edit list causes initial H.264 IDR to be skipped

[rectalogic@…]

Videos shot with the Sanyo Xacti cameras do not play properly with -demuxer mov. The initial IDR data chunk is skipped and so the first few seconds of playback are garbled, and this warning is printed:
[h264 @ 0x7ba2f0]warning: first frame is no keyframe

I uploaded a sample video shot with a Sanyo Xacti HD700 camera to upload.mplayerhq.hu /MPlayer/incoming/Xacti-elst/MP4-AVC-SanyoXactiHD700-elst.mp4

The video track has an edit list ('elst') and in demux_mov.c:demux_mov_fill_buffer where the 'real frame index' is calculated, we end up with frame==1. The stream is then seeked ahead 390544 bytes to this frame and decoding starts there - so the decoder never sees the first 390544 bytes worth of AVC video data.

Compare the output from mplayer -demuxer mov:
Starting playback...
[h264 @ 0x7ba2f0]AVC: Consumed only 27196 bytes instead of 27204

to mplayer -demuxer lavf:
Starting playback...
[h264 @ 0x7ba2f0]AVC: Consumed only 128377 bytes instead of 128388

lavf is sending the first frame of data and does not have playback issues - because it doesn't attempt to handle the 'elst' at all (but the reason I am using -demuxer mov is because I was hoping to avoid audio sync issues since it attempts to handle the 'elst')

So I believe demux_mov needs to send the video data through to the decoder, but start playback with the second frame to obey the 'elst' and keep audio sync.

[rectalogic@…]

mplayer -demuxer mov

[rectalogic@…]

mplayer -v -demuxer lavf

[rectalogic@…]

mplayer -v -demuxer mov

[rectalogic@…]

demux_mov.c patch

[rectalogic@…]

This patch fixes the issue. This is On2's GPL'd mplayer patch provided at ​http://support.on2.com/gpl/mplayer/2008-07-17-mencoder-on2flixenglinux.tar.bz2

The attached patch is mencoder-on2flixenglinux-2008-07-17/patch/mov_01_edl_kf_search.diff applied to current svn HEAD.