Media (Intel® Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools like Intel® oneAPI Video Processing Library and Intel® Media SDK
Announcements
The Intel Media SDK project is no longer active. For continued support and access to new features, Intel Media SDK users are encouraged to read the transition guide on upgrading from Intel® Media SDK to Intel® Video Processing Library (VPL), and to move to VPL as soon as possible.
For more information, see the VPL website.

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

rictripper
Beginner
557 Views
Hello,

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.
0 Kudos
4 Replies
Kz_Liao
Beginner
557 Views
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?
0 Kudos
Nina_K_Intel
Employee
557 Views
Hello,

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_out->Data.TimeStamp = 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 http://software.intel.com/en-us/forums/showthread.php?t=103139) This could also be the case.

Regards,
Nina
0 Kudos
rictripper
Beginner
557 Views
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.

Richard.
0 Kudos
Nina_K_Intel
Employee
557 Views
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.

Regards,
Nina
0 Kudos
Reply