Re: Key frames

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Alexander Chertov wrote:

> So, a packet is a unit of data, suitable for transmission
> thru network for example.
> A sample is also a unit of data, it is *kinda* supposed
> to store one frame. But since nobody controls how
> encoding/decoding is performer, nobody guarantees that.
>
> I just don't understand why do we need the concept of
> "sample" at all. For indexing?

A sample is a "unit" of media data, whatever that means in
the world of the specific stream format. It's what the ASF
specs calls Media Object.

A packet is a unit of data according to the transport stream
(ASF in this case).

There is no relation between packet and sample.

> What I need now, is a reliable-enough procedure for
> determining if a sample corresponds to a frame (which
> would mean that I can iterate thru compressed samples).
>
> What do you think of this ? :
> Read some uncompressed frames and also read the same
> number (~10) of compressed samples. Then compare the sets
> of timestamps. If they differ slightly (by 1 or 2 values)
> then we conclude that a sample and a frame is the same
> thang! huh?

I don't think this is reliable.

What about the following?

Open the same file twice in 2 WMSyncReaders, one configured
to deliver compressed samples (C) and the other uncompressed
samples (U).

Read with U->GetNextSample() to get whole frames in the
correct order. For each frame F_U you read, call
C->SetRange(F_U.PTS,0) (where F_U.PTS is the timestamp of
F_U) then C->GetNextSample(). If F_C.PTS == F_U.PTS, then
you have a keyframe. That's because the WMSyncReader always
seeks to keyframes (read the Remarks section of the doc page
on IWMSyncReader::SetRange()).

This way you do not need a frame-based index and it should
be relatively efficient and very reliable, because the
clean-point flag is only set on the first payload of the
first sample of a keyframe (in case of fragmentation).

> P.S. Correct me if I am worng. It is up to the decoder to
> reconstruct bitmaps from "samples". But its up to some
> other "component" to decide WHEN to display it. Right?

Well, nothing in the WMF runtime deals with rendering. The
WMF reader gives you the data and the presentation
timestamp, then it's up to you to do something useful with
it. DirectShow provide a more integrated solution, from
reading to rendering.

--
// Alessandro Angeli
// MVP :: Digital Media
// a dot angeli at psynet dot net


.

Relevant Pages

  • Packet cap diff... for classic dhcp over winxp s/w bridge prob.
    ... the server simultaneously. ... DHCP Discover - Transaction ID 0xe5448fbb ... Time delta from previous packet: ... Time since reference or first frame: ...
    (comp.os.linux.networking)
  • Re: problem with hostapd
    ... a "frame too short for this IEEE 802.1X packet" message, ...   frame too short for this IEEE 802.1X packet ...
    (freebsd-net)
  • IP protocol checksum errors
    ... Frame 3484 ... Time delta from previous packet: ... Capture Length: 254 bytes ... Fragment offset: 0 ...
    (comp.os.linux.embedded)
  • Re: problem with hostapd
    ... a "frame too short for this IEEE 802.1X packet" message, ...   frame too short for this IEEE 802.1X packet ...
    (freebsd-net)
  • Re: problem with hostapd
    ... WPA: group state machine entering state GTK_INIT ... frame too short for this IEEE 802.1X packet ...
    (freebsd-net)