[FFmpeg-devel] matroska file hits eof on any seek

[Reimar Döffinger]

On Sat, Feb 18, 2012 at 01:35:37AM -0700, Pavel Koshevoy wrote:
> On 2/18/2012 1:06 AM, Reimar Döffinger wrote:
> >
> >On 18 Feb 2012, at 08:58, Pavel Koshevoy<pkoshevoy at gmail.com>  wrote:
> >
> >>On 2/17/2012 11:41 AM, Reimar Döffinger wrote:
> >>>On Fri, Feb 17, 2012 at 11:15:23AM -0700, Pavel Koshevoy wrote:
> >>>>On 2/17/2012 10:51 AM, Reimar Döffinger wrote:
> >>>>>Also, if intra refresh is used then it is possible that there
> >>>>>is not one single IDR slice even in a multi-hour video that can
> >>>>>be seeked to any place without any issue.
> >>>>Can you suggest how I should handle this situation?
> >>>If you look at libavcodec/h264_parser.c you'll find
> >>>what FFmpeg does.
> >>>For this case: Parse the recovery SEI and check
> >>>recovery_frame_cnt. In that case probably all frames should be
> >>>marked as keyframes.
> >>Actually, this file doesn't appear to have any SEI NAL units.  At least I couldn't find any using my very basic NAL parser.  I also didn't see any mention of them with ldecod (H.264 reference implementation http://iphome.hhi.de/suehring/tml/download/)
> >I didn't investigate in that much detail, but did you look in extradata? (not sure what the mkv term for that is).
> 
> 
> I am not sure if you are referring to CodecPrivate data or not, but
> I believe that in matroska it is an AVC Decoder Configuration Record
> (from ISO/IEC
> 14496-15), it includes an SPS and PPS, but does not include SEI.
> Also, this file does not use matroska header stripping for frame
> compression, so it isn't there either.
> 
> I don't believe this is an intra-only coded file.  According to
> ldecod there are mostly P, B, and b slices, with an IDR slice thrown
> in periodically.

Big "sorry"! I forgot that the H.264 parser is indeed still completely
broken with MOV/MP4/MKV style H.264 and just marks everything as
key/intra/whatever without ever looking at the content.
In principle the SEI issue does exist (you should be able to create
a sample with the right x264 options if you are curious), but it does
not apply here.
I am still not sure about a good way to solve this, but since the
file is clearly broken I guess it is a bit lower priority.