- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I'm using the UMC MPEG-4 decoder from the IPP 5.2 samples on Windows XP SP2. I'm seeing that when set my encoder to have a fairly low I-frame rate, I start to see purple and green horizontal lines in the video. The video clears up once another I-frame is decoded, but get progressively worse as more P/B frames are decoded. I've included a sample file that demonstrates the problem. Thanks for any help you can offer.
Derek
I'm using the UMC MPEG-4 decoder from the IPP 5.2 samples on Windows XP SP2. I'm seeing that when set my encoder to have a fairly low I-frame rate, I start to see purple and green horizontal lines in the video. The video clears up once another I-frame is decoded, but get progressively worse as more P/B frames are decoded. I've included a sample file that demonstrates the problem. Thanks for any help you can offer.
Derek
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've done some more testing and found that Elecard's Mainconcept MPEG-4 Decoder also presents this problem. After tweaking with some of the settings, I found that setting the IDCT to float instead of integer fixed the problem. Looking through the UMC code I only see DCT calls for 16s types. Does the MPEG-4 decoder support 32f DCTs? Thanks for the help,
Derek
Derek
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Derek,
in IPP 5.2 sample we did not integrate Ipp32f DCT functions due to performance reasons, though our experimants show that we can pass MPEG4 conformance tests only withIpp32f DCT. The reasons is DCT coefficients with out of allowable range in some conformance streams.
Our experts also recommend you to use control over rounding on encoder side, available in MPEG4:
This is rather the encoding problem: manyP frames in a row,rounding_type set to0 (off) for every frame, theerror accumulates.
When the attached clip is played back with Elecard StreamEye, the same artefacts are seen. If one wants to encode such with low I-frame rates, setting the rounding_type to 1 for every other frame is recommended.
ForMPEG-4'sancestor - H.261, in which there's no such thing as rounding control, theITU-Trecommendation states that "a macroblock should be forcibly updated at least once per every 132 times it is transmitted".
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the quick reply. We are now looking into the issue on the encoder side. Just out of curiosity, we also analyzed the stream with Elecard's StreamEye, but we didn't notice the artifacts. What version of StreamEye are you using? We're using the most recent (2,9,2). Thanks again for the help,
Derek
Derek
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Derek, we use version 2.1.0 (build 60706)
Regards,
Vladimir
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page