locked
Date stamp in WMV? RRS feed

  • Question

  • I've got an application that requires the date stamp information be in each video frame (year month day hour min sec).  I can get this information from within each frame in the DV format.  I'm using a custom filter in a directshow graph.  I'd like to encode the video to wmv, but may not be able to unless I can embed the datestamp information.

     

    Does WMV support adding this information to each frame, either within the frame or in attributes?  If so, can anyone point me to some documentation or examples?

     

    Regards,

    James

    Thursday, April 3, 2008 2:45 PM

Answers

  • The WMV (ASF) format has a feature that allows you to embed custom attributes with each frame.  The Windows Media Format SDK allows you to both set and retrieve this data per-frame. 

     

    My recommendation, if you're going to be writing a WMV file, is to use the Windows Media Format SDK.  The documentation refers to these custom attributes as "data unit extensions".  You can read about data unit extensions at http://msdn2.microsoft.com/en-us/library/aa390709(VS.85).aspx.  The basic idea is this:

    • When setting up your IWMProfile, you will "declare" your data unit extension on the video stream via IWMStreamConfig2::AddDataUnitExtension.  You'll specify a GUID for it and a fixed size for the data
    • For each video frame you send into the WMFSDK writer, you will first call INSSBuffer3:Tongue TiedetProperty to set whatever value you want.

    And when you read the file back using the WMFSDK reader, you will be able to call INSSBuffer3::GetProperty to see the embedded values. 

     

    I'm guessing from your question that it's okay with you if only your application is capable of reading the datestamp that you embed in the WMV file.  Obviously, since we're talking about custom per-sample attributes, an application like the Windows Media Player won't be able to interpret your attribute values (though of course the content will certainly still be playable).

     

    Monday, April 7, 2008 11:22 PM

All replies

  • The WMV (ASF) format has a feature that allows you to embed custom attributes with each frame.  The Windows Media Format SDK allows you to both set and retrieve this data per-frame. 

     

    My recommendation, if you're going to be writing a WMV file, is to use the Windows Media Format SDK.  The documentation refers to these custom attributes as "data unit extensions".  You can read about data unit extensions at http://msdn2.microsoft.com/en-us/library/aa390709(VS.85).aspx.  The basic idea is this:

    • When setting up your IWMProfile, you will "declare" your data unit extension on the video stream via IWMStreamConfig2::AddDataUnitExtension.  You'll specify a GUID for it and a fixed size for the data
    • For each video frame you send into the WMFSDK writer, you will first call INSSBuffer3:Tongue TiedetProperty to set whatever value you want.

    And when you read the file back using the WMFSDK reader, you will be able to call INSSBuffer3::GetProperty to see the embedded values. 

     

    I'm guessing from your question that it's okay with you if only your application is capable of reading the datestamp that you embed in the WMV file.  Obviously, since we're talking about custom per-sample attributes, an application like the Windows Media Player won't be able to interpret your attribute values (though of course the content will certainly still be playable).

     

    Monday, April 7, 2008 11:22 PM
  • Becky, thank you for the reply.  I was beginning to look at an option to use the 'File Markers' in the header and had not noticed the data unit extension option.  I was thinking about storing a Marker for each timestamp where the date stamp sequence changed.  So if ten scenes were shot by a dv camcorder, then I'd have to store 10 markers.  The name of the marker would have to be something like Date.ToString().  I could use the marker name and then the video timestamp as an offset to determine the actual date stamp of each frame.

     

    Perhaps both options would work.  I think that I'll have a go at the data unit extension option, it would be more consistent with the DV method of storing the datestamp within each frame.  But if you have any comments about using markers that would rule them out as an option, then please respond.

     

    You are correct that only my application needs to read this data.

     

    Tuesday, April 8, 2008 3:39 PM