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.

Generated Mp4 file won't play

Matthew_C_
New Contributor I
1,326 Views

The more specific problem I'm having is that upon playing the mp4 file my program generates, I get a "Windows Media player cannot play the file. The Player might not support the file type of might not support the codec that was used to compress the file."

The h264 file will play so I'd like to run through what I'm doing and at least make sure it makes sense, any thoughts as to things to look for would be appreciated.

After setting it up, I generate a Bitstream for h264 frames and I write them out to a file, one after another.

I then take that bitstream and feed it through MFXMuxer_PutBitstream (this might be related to this question: http://software.intel.com/en-us/forums/topic/501569)

Within MFXMuxer_PutBitstream, it automatically calls curBitstream->write, where curBitstream is a DataIO object (I wrote my own so that instead of saving to/from a file, it just copies the buffer passed into curBitstream->write into a mfxBitstream within the file).

Then as soon as MFXMuxer_PutBitstream finishes executing I call curBitstream->Read, pull the Bitstream out, which seems like it should represent mp4 frames, and write them one at a time to a file.

Then I try to play the file. This approach is correct, right?

0 Kudos
1 Solution
Matthew_C_
New Contributor I
1,326 Views

Figured it out, it was indeed a MFXMuxer_PutBitstream problem, basically I was passing in a 0 instead of a 1 for the track number because I assumed that track_num was 0-indexed, whereas it's actually 1-indexed... probably worth adding to the documentation.

View solution in original post

0 Kudos
3 Replies
Matthew_C_
New Contributor I
1,327 Views

Figured it out, it was indeed a MFXMuxer_PutBitstream problem, basically I was passing in a 0 instead of a 1 for the track number because I assumed that track_num was 0-indexed, whereas it's actually 1-indexed... probably worth adding to the documentation.

0 Kudos
Jeffrey_M_Intel1
Employee
1,326 Views

Request noted.  Thanks!

0 Kudos
Matthew_C_
New Contributor I
1,326 Views

Also, just so this answer doesn't mess anyone else up.. for some reason switching track number from 0 to 1 appeared to fix the problem previously.  But I believe that what was actually happening was that it was simply avoiding the line of code that was messing up and making it look like it was working.

If you go through the MFXMuxer_PutBitstream code, these line make me think it is indeed 0 indexed:

if (track_num >= in_mux->stream_params.NumTracks)
        return MFX_ERR_UNKNOWN;

 

So my bad and make sure that documentation is correct in that regard.  Thank you!

0 Kudos
Reply