Hardware Accelerated Decoding of MPEG2 ?
#16
Can you please elaborate on this "still frames" issue? What is it?

Regarding the rest, thanks a lot for the info! I didn't realize (till now) that it was only my AMD-based equipment that had the limitation of not being able to deal with VC-1/main profile properly. And I'm still a bit confused about that, because of what might possibly be AMD official misinformation, specifically here:

http://developer.amd.com/community/blog/...coder-uvd/

I quote:
"VC1 – Up to Advanced profile up to level L3"

The phrase "up to" doesn't usually mean "but nothing lower than this".

Anyway, sigh... based on the info you just provided, guess that it really is time now for me to ditch my AMD HTPC and grab myself a RPi2 instead.

Thank you. I wasn't sure that I wanted to spend the cash (for an RPi2)... even though it isn't much... but now I am sure.

Still wondering about MPEG2 issue though. If there is something specific... which is goofy and which breaks HW decoding... within the MPEG2 files that one finds on many, most or all DVDs... then perhaps someone (e.g. within the ffmpeg or handbrake communities) could write some sort of munger tool that will just fix the files without doing full blown (and detail sacraficing) transcoding (e.g. to MPEG4/AVC).
Reply
#17
Christian König (amd oss dev) removed it from the amd oss radeon drivers - after it caused constant issues (hangs on older gens, etc.). There might be some working code for DXVA on windows. But as AMD closed drivers are the most evil crap one can think of ... I would not try to run kodi on windows on them. See for example the Windows Forum, where every second decoder problem is an AMD problem.

IIRC we had it working back at the time on the closed fglrx drivers on linux ... but we removed that completely after constant no support by those closed source devs.

For still frames: please use widespread literature, my time for lessons is limited to my real students, sorry :-)
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#18
(2015-03-31, 05:04)ronbaby Wrote: So, um... are there any RPi2 users reading this? If so, what say you? Is your RPi2 ... presumably loaded up with the latest and greatest OpenELEC... actually doing hardware accelerated decodes when you play your ripped DVD .iso files? And I have the same question also for your ripped VC-1 BluRays (of which I personally have many). Is the latest and greatest OpenELEC for the RPi2 doing... or alternatively not doing... hardware decode for VC-1? Inquiring minds want to know. Please post and let me know.

The Pi (and Pi2) does hardware decode MPEG-2 for DVDs. This is a necessity for Pi1 which doesn't have the CPU to decode DVD resolution MPEG-2.
It does involve some hackiness to handle the still frames. The hackiness is not merged upstream, but is in all the main Pi builds.

For info, DVD menus sometimes use individual MPEG-2 frames for single background images (or other simple menu animations). These are known as still frames.
Hardware codecs tend to work in a streaming way where you push encoded frames in and asynchronously get decoded frames out. The still frames are not necessarily ready as soon as you submit the encoded data, and you need a means to get the decoded frames back.

libmpeg2 works in a synchronous way and is used in preference (to both ffmpeg and hardware codecs) on other platforms to avoid this issue.
Reply
#19
Thank you, fritsch, for the clarifications regarding AMD. But I'm still scratching my head about all this. Yes, I understand that the closed source AMD stuff was buggy and difficult to work with... for all of the usual closed source reasons... but I could have sworn that a few months back... perhaps as much a 6 months or more ago now... I read some postings online someplace (perhaps here) where there seemed to be quite a bit of joy and hoopla over the (alleged) fact that AMD had opened up their sources... at least for the UVD video decoding sutff. And yet you're telling me that something (you didn't really clarify what) got ``removed'' at some point due to ``constant issues'' with the AMD (closed source) hardware video decoding stuff. OK. I got that. But if the sources are nowadays fully open, then what is the problem now?

OK, here is perhaps some of the stuff I was reading (that announced the opening up of AMD video decoding sources);

April 2, 2013:
http://www.phoronix.com/scan.php?page=ar...source_uvd

August 24, 2014:
http://www.phoronix.com/scan.php?page=ne...px=MTc3MTc

So if the sources are all open nowadays, then what's the problem?

Regarding still frames, yes... I googled the heck out of that last night, and found a tiny bit of info about the general nature of the problem, but there really is scant little about this issue online. But that's OK. The comments just posted by popcornmix are adequate for my purposes. (I don't really need to understand the problem that deeply, but I was certainly curious about it.)

Anyway, I'm not persuaded that the menu/still frame issue is an adequate justification for turning off MPEG2 hardware decoding entirely and even for the actual movie part of a DVD .iso file. I was looking at the "o" display whlie playing back a DVD rip .iso and it seemed to me that Kodi actually was noticing when the menu stuff was playing... and it switched, during that time, to a different decoder. Am I wrong? Did I not see this in the "o" display?

If Kodi can in fact notice when it is playing DVD menu stuff (and when it is not) then why does it need to disable MPEG2 HW decoding even when it is playing non-menu stuff?
Reply
#20
I wanted to say "Thank you" also to popcornmix for the additional helpful & enlightening comments.

I just ordered my RPi2 less than an hour ago. I hope and believe that will do nicely for me.

P.S. Of course, as my typically bad luck would have it, I also had ordered and taken delivery of an Odroid C1 back in January... just slightly before the existance & availability of the RPi2 become known to the world at large. (Talk about bad timing!) And of course, at that time, there was in fact a guy who worked for the manufacturer (Hardkernel) who was working on a port of OpenELEC to the C1 at that time. But not long after I took delivery of the thing... and loaded up a port of OpenELEC that some outside volunteer had been working on... I found out that this specific OpenELEC port had some serious problems... like specifically being unable to play VC-1 BluRay rips without totally choking up and several other problems too. The next shoe that dropped was when I PM'd the Hardkernel staff guy who had been working on his own OpenELEC port, and he responded back that since there was this outside guy working on it, he himself would no longer be working on porting OpenELEC to the C1 at all. So Hardkernel is selling this board (C1) that they obviously intended to market... at least partly... as a media player (with buit-in IR receiver), and yet now there is nobody who actually works for the company who is working on porting either Kodi or (more importantly) OpenELEC to the board anymore.

Sigh.

I'll be selling my C1 on ebay shortly.

To say that I am kind of pissed off that Hardkernel decided to abandon work on their own port of OpenELEC would be an understatement.
Reply
#21
(2015-03-31, 23:53)ronbaby Wrote: Thank you, fritsch, for the clarifications regarding AMD. But I'm still scratching my head about all this. Yes, I understand that the closed source AMD stuff was buggy and difficult to work with... for all of the usual closed source reasons... but I could have sworn that a few months back... perhaps as much a 6 months or more ago now... I read some postings online someplace (perhaps here) where there seemed to be quite a bit of joy and hoopla over the (alleged) fact that AMD had opened up their sources... at least for the UVD video decoding sutff. And yet you're telling me that something (you didn't really clarify what) got ``removed'' at some point due to ``constant issues'' with the AMD (closed source) hardware video decoding stuff. OK. I got that. But if the sources are nowadays fully open, then what is the problem now?

OK, here is perhaps some of the stuff I was reading (that announced the opening up of AMD video decoding sources);

April 2, 2013:
http://www.phoronix.com/scan.php?page=ar...source_uvd

August 24, 2014:
http://www.phoronix.com/scan.php?page=ne...px=MTc3MTc

So if the sources are all open nowadays, then what's the problem?

Regarding still frames, yes... I googled the heck out of that last night, and found a tiny bit of info about the general nature of the problem, but there really is scant little about this issue online. But that's OK. The comments just posted by popcornmix are adequate for my purposes. (I don't really need to understand the problem that deeply, but I was certainly curious about it.)

Anyway, I'm not persuaded that the menu/still frame issue is an adequate justification for turning off MPEG2 hardware decoding entirely and even for the actual movie part of a DVD .iso file. I was looking at the "o" display whlie playing back a DVD rip .iso and it seemed to me that Kodi actually was noticing when the menu stuff was playing... and it switched, during that time, to a different decoder. Am I wrong? Did I not see this in the "o" display?

If Kodi can in fact notice when it is playing DVD menu stuff (and when it is not) then why does it need to disable MPEG2 HW decoding even when it is playing non-menu stuff?

In fact UVD cannot do VC-1 Main at all. Christian has implemented it and yeah - result was green screen, completely blue content, distorted content. I can patch it back in for you, if you want this kind of screen artifacts instead of real picture :-) ... it was not removed cause of "a bit of issues" with one or two files but cause of a general issue ...

See: https://bugs.freedesktop.org/show_bug.cgi?id=66452#c9 <- if you are of other oppinion (feeling won't help the hw) talk to Christian.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#22
fritsch,

Thanks for the additional info. I certainly do not question that there were problems with AMD/UVD decoding VC-1/main, but I was... and still am... curious to know why the releatively new/recent access to open source code to drive the UVD hardware didn't help to alleviate these problems.

I woudn't mind at all asking Mr. König about this. I fact I am sure that whatever his response was would be most enlightening and educational for me. But I have no idea how to reach him. If you do, then perhaps you could PM me with contact information for him. Thanks in advance.

P.S. Of course, since I am now about to replace my AMD-based HTPC with an RPI2, any and all AMD/UVD issues/problems will soon be only of academic interest to me. But I am still really very curious to learn how AMD could get away with making public statements like "supports up to VC-1/advanced" when really, the hardware they actually shipped was so broken as to be useless for anything (in that WMV{1,2,3} family of codecs) except VC-1/advanced.
Reply
#23
You can contact christian via: christian[DOT]koenig[AT]amd.com

Best regards
Peter
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply

Logout Mark Read Team Forum Stats Members Help
Hardware Accelerated Decoding of MPEG2 ?1