Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

IPP samples, MPEG2Muxer is PoS?

John_D_10
Beginner
236 Views

I don't mean to be rude, but can somebody confirm my impression please?

In my organization we use IPP for tv broadcast stuff and I've been fighting with MPEG2Muxer to get it to produce something that works. I've been on this task for more than a month (part time) and so far my only colcnlusion that it was very wrond decision to use IPP for this task.

I'll give more info on what I'm trying to do. I simply need to generate Mpeg2 TS (Transport Stream) with H264 video and AAC audio. For all these tasks we use IPP. The problem was that some hardware receivers after some playback time start to choke. At first I started to fix some stuff, writing new code to properly stuff the TS stream with NULL packets to acchieve constant bitrate, but still we have problems. So, I started to go more into bitstream looking for problems. The problem that I'm seeing now is that after a few minutes of muxing PCR time-stamp runs aways from PTS stamps of audio or video streams. I tried to step through the code, but it's pretty messy to understand and I didn't want to bother with that. Then I tried to set muxrate to 0, to make it simply mux whatever I pass and what I see inside the code is complete disaster, complete assumption that there has to be some bitrate for TS stream (and if I specify 0, then it randomly sets 100kpbs and 1mbp for audio and video respectively). Probably, with som state of the art codecs (like x264) I can select constant bitrate and trust the encoder and tell the muxer about bitrate, but it just doesn't work that well with H264.

I've used libs from ffmpeg/x264 and so far IPP stuff seems to be pretty inferior to these libs. TS muxer code is broken (or, it's just sample code, as it's called), performance of the encoder is uncomparable to x264 (It just happened that my dev box runs AMD is that the reason for very bad performance?, customers use intel-based servers, anyways, so it's not a big deal).

So, anybody from IPP team can comment on TSMuxer code, is it usable, or it was just made for some constant video bitrate scenario where it worked and ... that's it? The thing is that it's much bigger than relevant ts-muxer code from ffmpeg or other libs, but it doesn't do simplest tasks properly. After fighting it for a long time I turned to ffmpeg muxer code, ripped it from there, tried it... and right away it works and produces stream that plays on my reference HW box. Also, the tsMuxeR from VideoHelp does the job right.

I guess, i'm not he only one compalining about tsmuxer code, perhaps somebody could direct me to similar posts with suggestions or, maybe, some other code samples that do it properly.

0 Kudos
1 Reply
Jeffrey_M_Intel1
Employee
236 Views
I'm very sorry to hear about your frustrating experience. I don't want to sugar-coat anything: the UMC splitters and muxers are not fully developed. UMC, including the splitter/muxer code, is a sample starting point and not intended for production use without modification. As a starting point, it will be up to you to make any changes required. Fully agree that the changes needed may be quite significant. From the samples download page (http://software.intel.com/en-us/articles/code-samples-for-intel-integrated-performance-primitives-intel-ipp-library-71): UMC is a sample, and not optimized, tested, or supported at the same level as the primitives. The media APIs may not fully implement the specs for each codec and splitters/muxers are intended merely as developer tools to facilitate codec evaluation. A similar disclaimer is in the User's Guide. If you're developing for Windows, or plan to at some point in the future, you may be interested in this article: http://software.intel.com/en-us/articles/integrating-intel-media-sdk-with-ffmpeg-for-muxdemuxing-and-audio-encodedecode-usages This illustrates using ffmpeg for splitters/muxers and audio, with Media SDK for hardware accelerated video encode and decode. This may be a shorter path to a solution for splitters/muxers than via UMC, and it may also address some of your performance concerns (especially for machines with Quick Sync Video).
0 Kudos
Reply