[Ffmpeg-devel] dvr-ms seek help request

[Steve Lhomme]

John Donaghy wrote:
> Hi
> 
> dvr-ms files can now play in the likes of mplayer using the ffmpeg asf
> demuxer. However seeking doesn't work well because key frames cant be
> detected.
> 
> I've being trying to fix this without much success so I'm hoping for
> suggestions from anyone who might be able to help. First off - is
> there an asf expert in the house or is this a dead format as far as
> anyone here is concerned? If you dont care about asf format then I'm
> sure the following will be of no interest to you. I only got
> interested in it because I currently record TV in the format that I
> want to watch on other devices. (Also I have trouble giving up on a
> problem once I start!)
> 
> Anyway, the main problem is that every single data segment (also known
> as payload) in every packet has the key frame flag set which I assume
> shouldn't be the case if the format conformed to the ASF spec.

[...]
> 
> Regarding key frames, my guess is that the information on whether a
> particular video stream segment is part of a key frame is hidden
> somewhere in an undocumented place (perhaps in the replicated data of
> each segment).  I could be totally wrong though cause I really don't
> know much about this whole video stuff. Anyway, the main question I
> have is this - is there another way to determine if a video segment is
> part of a key frame in the demuxer code?
> 
> Also, the current version of asf.c doesn't attempt to read the Simple
> Index in an asf file even though it knows the GUID for the object.
> I've written some code to read it on demand from the seek function
> (much like the avidec.c). I can submit this as a patch if anyone wants
> it but it only helps a bit... when using the index to seek the lag
> time between completing the seek and finding the next key frame is
> perceptibly less (usually about 8 frames) than without it. I also
> think you end up closer to where you expected to be in the file with
> the index so it is useful up to a point.
> 
> The Simple Index consists of a series of packet numbers (and
> associated packet count) at regularly spaced time intervals. The
> packet number is supposed to contain the closest past key frames so I
> was quite hopeful that it would be of use here.  Eg:
> pktnum:0, pktct:1
> pktnum:53, pktct:1
> pktnum:115, pktct:1
> ...
> pktnum:445, pktct:2
> 
> etc
> 
> My understanding of this is that you can derive the position required
> by av_add_index_entry by simply multiplying pktnum by the packet
> size(fixed) and adding the data offset. The timestamp is simply the
> interval times the index entry number (starting at zero). I assume you
> can ignore pktct. Something like this:
> 
> for (i=0;i<ict;i++){
>     pktnum=get_le32(&s->pb);
>     pktct=get_le16(&s->pb);
> 
>     pos=s->data_offset + asf->packet_size*(pktnum);
>     index_pts=itime/10000*i;    //itime is index time interval in nanosecs
> 
>     av_add_index_entry(s->streams[stream_index], pos, index_pts,
> asf->packet_size, 0, AVINDEX_KEYFRAME);
> }	
> 
> Once you get that far you can easily jump to the start of a packet
> near the point you wanted to go to - ie with 1/2 a second. But then
> what? I've seen other code refer to the frame_offset. Should you jump
> to the start of the frame or the start of the packet. Or jump to the
> start of the packet and read up to the first video segment which I'm
> guessing should be a key frame? Needless to say nothing I've tried has
> worked and I'm out of ideas mainly because my lack of knowledge of the
> general subject.

I had to deal with problems seeking in ASF too. One of the problem was 
the use of start_time. Apparently the index_entry on other formats 
doesn't include the start_time and ASF does (or the opposite). But in 
the end, I never managed to have a consistent behaviour for seeking 
between AVI, MPEG, ASF.

Given there is no documentation and the ASF demuxer was giving wrong 
timecodes until a few weeks ago, I assume that seeking in FFMPEG is 
globally not working or is not tested.

Also note that seeking within MPEG2 content (like in DVR-MS files) can 
cause crashes. I submitted a patch that works for me, but it was never 
accepted and the bug was never fixed.

Steve