Mpeg2Muxer creates invalid TS files

Mpeg2Muxer creates invalid TS files

Allen Drennan's picture

I'm using the SimpleMuxer sample (http://software.intel.com/en-us/articles/getting-started-with-intel-ipp-...) to create a TS file for use with HTTP Live Streaming. However, the resulting TS file is invalid. Trying to play it in Windows Media player results in a black screen. And when using it for HTTP Live Streaming, the TS won't play at all.

When I use the SimpleEncoder sample (from the sample sample page) to create a .264 file, and let FFMPEG create a TS file from it, then that TS works fine in Media Player and HTTP Live Streaming. So I think there is something wrong with the output from the Mpeg2Muxer class.

Any other people with the same issue or a solution/workaround?

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Chao Y (Intel)'s picture

Hello,

What is the verion of the sample code you tested and did you have any change on the example?

If possible, you can also upload theTS file to have a check.

Thanks,
Chao

jmason's picture

IPP Version -- 6.1.1.035 IPP Sample Version -- 6.1.1.044

Ive been trying to get the same thing done, but I havent
had any luck. Ive been trying to take a .mp4 file, encoded with H.264 video
and AAC audio , and mux it into a series of .ts files. The .ts files I create
are able to be played in VLC, but when I tried to play them in Quicktime or on
the iPhone, they won't work. I found that Apple has a mediastreamvalidator
program which is used to validate streams against various versions of the
iPhone. I pointed it at the .ts files I created with the IPP MPEG2Muxer and it came back saying failed
to parse segment as either an MPEG-2 TS or an ES: error -12971. I then took the same .mp4 file and put it through one of Apples programs,
mediafilesegmenter, that also generates .ts files. Then I pointed
mediastreamvalidator at those files and everything worked just fine. Im fairly certain that the mediafilesegmenter is not reencoding the files because it
only takes about 15 seconds to run the program on a 5 minute long video.

Any thoughts, suggestions or fixes would be greatly appreciated.

Justin

Ying H (Intel)'s picture

Just quick thought, What is the Quicktime version? There isrelated issue reported at http://software.intel.com/en-us/forums/showthread.php?t=75828&o=d&s=lr.

what's the result if upgraded to the latest Quicktime 7.6.8?

Regards,
Ying

soimattrang's picture

Hi Allen Drennan,

did you solved your problem. i'm facing the same problem with you that i submited here: http://software.intel.com/en-us/forums/showthread.php?t=102740&o=a&s=lr
if you solved the problem, could you please share your solution with me. Thanks you very much!

Kieran L.'s picture

Not to bring up an old thread - but the muxer is generating incorrect CRC32 values as it is not using crc-32-mpeg.

Using pycrc you can generate the correct crc algorithm using

./pycrc.py --std C99 --model crc-32-mpeg --algorithm table-driven --table-idx-width 8 --generate c -o crc-mpeg.c

then the PMT/PAT code needs to be modified in umc_mpeg2_muxer_chunk.cpp:1067 and anywhere that ippsCRC32_8u(....) is called to use the correct crc algorithm. 

Replace

    //ippsCRC32_8u(bs.m_lpb - uiCRCDataLen, uiCRCDataLen, &uiCRC32);
    //uiCRC32 ^= 0xFFFFFFFF;

With

uiCRC32 = crc_update(0xffffffff, bs.m_lpb - uiCRCDataLen, uiCRCDataLen);

Attachments: 

AttachmentSize
Download crc-mpeg.c4.61 KB

Login to leave a comment.