Simple GrephEdt Source->Encode->Muxer->File Writer

Simple GrephEdt Source->Encode->Muxer->File Writer


Using thethe following DirectShowfilters, Video Capture Device -> Intel Media SDK H.264 Encoder -> Intel Media SDK MP4 Muxer -> File Writer I am sucessfuly encoding frames and creating an increasing file size. When it comes to viewing the file I fail, no error number. Tried rendering the file using the Intel Media SDK H.264 Decoder with no luck in GrapgEdt.exe? Any ideas? I am able to successfully Capture -> Encode -> Decode -> Render so the error is with the file writing or playback.. Using a P8 Z68. Thanks.

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

When I wasdoing so I met similar problem. When the video is within about30 minutes, seek to specific position by Windows Media Player can be done but take a long time. When the video comes longer, the operation will makeWMP report an unknown error.
I notice that the filter sampleshave not beenfully tested and marked 'as is'. I debugged the H264 Encoder Filter, it turned out that the output sample has no timestamp(after a series of asynchronous call, when comes to deliver the sample, the rtStart is 0). Is that the cause of the problem? Or sth wrong within the mp4 mux filter?

The issue with time stamps is known and will be fixed in the upcoming Media SDK 2012 Gold Update.
Meanwhile anyone can do a quick fix in sample code since it is open. Please see recommendation below.

In case RGB32 format is passed as input to MSDK Encoder Filter (e.g. Cam
Capture -> MJPEG Decompressor -> Intel Encoder ) there is a color space
conversion plugin inserted before encoder to convert to NV12. This plugin
doesnt pass-through the timestamp of the input surface therefore the correct
timestamp never reaches encoder input and doesnt appear on encoded bitstream
to be transformed into output MediaSample start and end times (see CEncVideoFilter::DeliverBitstream function).

The fix is very simple:

In file samples\sample_dshow_plugins\common\src\plugin_csc.cpp, line 129
add the following line of code:

= surface_in->Data.TimeStamp;

Please also note, that there is a limitation for Intel MSDK MP4 Muxer - it cannot create a valid file with size over 4GB. (see This could also be the case.

Hello Nina,

The file is only 10 seconds long, less than 4GB.
Does this mean that I cannot use GraphEdt as a solution?
Tried using a CSC prior to the encoder and still see an error when trying to playback the file.
Output of the source filter is RGB32, tried also YUY2, RGB565, and RGB24.

When do you plan a release of the Gold Update?
I represent Datapath Ltd, Vision capture cards, we are asked about the QuickSinc technology on support and would like totest with our capture cards at a GraphEdt level.

Thanks in advance.


Hi Richard,
Ok, I see, then I think you're hitting the timestamps issue. Have you applied the fix I mentioned in my previous post?
Gold Update is planned for the firs half of April.

Leave a Comment

Please sign in to add a comment. Not a member? Join today