BetaPlayer with Intel 2700G support - Page 10

11-23-04, 05:40 AM

The preliminary testing is over. Thanks for the feedbacks. I removed the intel2700g plugin, until the license issues are cleared. Hopefully my motives will be clear for everybody in the near future...

11-23-04, 05:52 AM

Originally Posted by PocketTV Team

>I doubt we could learn much from Picard's plug-in source code, since it is most likely very similar to the intel sample code, with regard to the interface with the SDK.

I guess you will realize soon enough that the sample is far from the code which is needed for a fully functional media player like PocketTV or BetaPlayer. Not to mention some optimizations...

Originally Posted by PocketTV Team

A lot of the code (probably more than half of it) belongs to various other GPL or LGPL projects and was developed by other people.

Originally Posted by PocketTV Team

Betaplayer has a slightly faster bit parser (thanks to ffmpeg)

I'am kinda already used to it, but please try to verify your statements about other people's work before posting it on public forums. Thanks!

11-23-04, 05:55 AM

Originally Posted by Un[R]egistered

Just one question, however, all of my Futurama videos have something called "GMC" implementation. I am not aware of what this is, but BetaPlayer realizes that it doesn't have "GMC support" through an error message and continues to play the video, but with a lot of garbage(?). So I was wondering if "GMC" support is of high priority or not. Thanks in advance. :)

GMC is global motion comensation, an advanced simple profile mpeg4 feature which is currently not supported by BetaPlayer's mpeg4 decoder. I plan to support in the future, but not sure when.

11-23-04, 06:17 AM

> I guess you will realize soon enough that the sample is far from the code which is needed for a fully functional media player like PocketTV or BetaPlayer. Not to mention some optimizations...

Of course, and you also know that we did all the work to support the ATI Imageon, and we have not looked at a single line of your code with this regard (except a few clips that you were nice enough to send us regarding the use of AhiDrawIdle, if I recall).

From the documentation we have, it does not look significantly more complex to handle the 2700G, compared to ATI. In fact this hardware is much less flexible, so there is less options, especially when doing the post-processing.

For example, I don't think it's possible to feed the MBs in other than scanning order, which makes it a bit harder - but not impossible - to do the rotation in the frequency domain.

The only problem is that the API is quite close to the hardware and not very application friendly - what do you expect from people manufacturing chips :)

> please try to verify your statements about other people's work before posting it on public forums.

Do you mean that you don't use ffmpeg anymore ? last time i looked, you were using it. Betaplayer also includes (or is based on) several codecs written by other people, unless you rewrote everything from scratch.

11-23-04, 06:26 AM

Originally Posted by PocketTV Team

>Do you mean that you don't use ffmpeg anymore ? last time i looked, you were using it.

I was never using ffmpeg code. I did checkout the ffmpeg mpeg1 implementation to faster help understand the mpeg1 format use the constant tables etc... I'am very thanksfull for ffmpeg project, but didn't copied code and BetaPlayer is fast because I made my own arm optimizations (in C) for mpeg1 parsing too.

11-23-04, 06:30 AM

Originally Posted by PocketTV Team

>Of course, and you also know that we did all the work to support the ATI Imageon, and we have not looked at a single line of your code with this regard

I never said anything about you benefiting from my source. I was talking about a very different statement of yours, which said my source has no additional usefull information compared to the sample code found the SDK.

11-23-04, 06:32 AM

Originally Posted by picard_beta

I was never using ffmpeg code. I did checkout the ffmpeg mpeg1 implementation to faster help understand the mpeg1 format use the constant tables etc... I'am very thanksfull for ffmpeg project, but didn't copied code and BetaPlayer is fast because I made my own arm optimizations (in C) for mpeg1 parsing too.

Sorry, i thought you used it or derived some code from it, since you included "thanks" to this project.

There is a fine line between copying code, using similar algorithms or data structures etc. When you start looking at some code, it's easy to do that, and some times it means copying's someone else's IP (Intellectual Property), even if no code is copied. That's true for Open Source and Closed Source as well. That's why we try to avoid looking at other's people code if this could lead to this shady IP situation.

11-23-04, 06:35 AM

Originally Posted by picard_beta

I never said anything about you benefiting from my source. I was talking about a very different statement of yours, which said my source has no additional usefull information compared to the sample code found the SDK.

Sorry I never said that or intended to say that. Maybe I was not clear.

I just said that the source code in the SDK was certainely enough to interface correctly with the SDK, and that we have that.

I'm sure your code is very good, but your plug-in just interfaces the 2700G, and there are not that many ways to do that, using the Intel SDK.

11-23-04, 06:36 AM

Originally Posted by PocketTV Team

>For example, I don't think it's possible to feed the MBs in other than scanning order, which makes it a bit harder - but not impossible - to do the rotation in the frequency domain.

I would say the problem is not the scanning order, but the mirroring. ATI Imageon supports overlay mirror which means only x/y swapping is needed during video decoding to get rotated frames. But 2700G doesn't support mirror (public pdf), so the video decoding has to generate the fully rotated frames if you don't want to use the post processing rotation. As you said it's it possible in the frequency domain, this is what BetaPlayer does.

11-23-04, 06:39 AM

Originally Posted by picard_beta

I would say the problem is not the scanning order, but the mirroring. ATI Imageon supports overlay mirror which means only x/y swapping is needed during video decoding to get rotated frames. But 2700G doesn't support mirror (public pdf), so the video decoding has to generate the fully rotated frames if you don't want to use the post processing rotation. As you said it's it possible in the frequency domain, this is what BetaPlayer does.

Yes, but that requires a pretty large cache buffer...

And naturally you cannot use the hardware IDCT, you need to reconstruct the blocks before feeding them to the 2700G :(

11-23-04, 06:40 AM

Originally Posted by PocketTV Team

some times it means copying's someone else's IP (Intellectual Property), even if no code is copied.

I agree there about IP and it's very hard to verify what comes from where. My goal was to write the mpeg1 as fast as possible and I still believe that the essense and fastness of BetaPlayers mpeg1 code still my IP. Still I'am very thanksfull for ffmpeg project and I state that in the about dialog too (but not state that I use the ffmpeg library itself like libmad or libid3 or tremor).

11-23-04, 06:45 AM

Originally Posted by PocketTV Team

Yes, but that requires a pretty large cache buffer...

It's starting to go in the direction of the NDA, but I can assure you there is no need for cache buffer. I'am not sure why did you said the statement about the fixed scan order decoding in your earlier post.

11-23-04, 06:48 AM

Originally Posted by picard_beta

It's starting to go in the direction of the NDA, but I can assure you there is no need for cache buffer. I'am not sure why did you said the statement about the fixed scan order decoding in your earlier post.

I'll check with Intel, maybe I misunderstood something, I had the impression that you cannot pass the MBs in random order to the chip. Anyway, I'm sure we'll get all the info directly from Intel, so you should respect the NDA, and we should too.

11-23-04, 06:50 AM

Originally Posted by PocketTV Team

And naturally you cannot use the hardware IDCT, you need to reconstruct the blocks before feeding them to the 2700G :(

Big hint: this is where you are wrong and where I was pretty suprised about my math skills :D

11-23-04, 06:50 AM

Originally Posted by picard_beta

It's starting to go in the direction of the NDA, but I can assure you there is no need for cache buffer. I'am not sure why did you said the statement about the fixed scan order decoding in your earlier post.

But I doubt you can use their hardware IDCT which is probably not a problem because with the CPU it should be possible to get a pretty fast software IDCT.