2016-01-09, 19:37
As the original author of DVDVideoCodecAmlogic, I'll be the 1st to say it is in dire need of refactoring/cleaning. It was on the list but I never had the time to get to it.
DVDVideoCodecAmlogic has two parts, a wrapper/helper for a codec and the AMCodec core. Originally AMCodec was based on internal AMLogic codec code and has become quite squirrelly (technical term). The render method (by-pass) was the best I could get approved by the owner of that area of code (elupus) and the render callbacks were the only way to get the updates when needed. It was only when renderer code was changed to include timestamps that problems really started to show up. Prior to that it was quite good.
Maybe there is something better, maybe not, but to call it wrong is silly. It's just a different way and has worked for years despite the constraints the code was forced to live with.
One area that really needs serious thought is the system amcodec can and will try to suck down large amounts of demux. We are not taking about a few frames here, 10s of seconds of frames. Too little and the system by-pass renderer will stop and wait, too much and the internal kodi player will thrash. It's very tricky to get the right amount of balance as the system codec is like a run-away train, all you can do is try and make sure it stays on the tracks. I mentioned this very thing once and was told it's wrong too
Well, right or wrong, that is the way the system codec works and unless you are willing to dive into some massive kernel driver code, that is the way it will always work. AMLogic has no interesting in changing its behavior as a pure streaming codec. At least now you can get the amount of time buffered but that only works with h264 (maybe h265). So far, I have seen very little interest in the change I did to move from size to time in controlling buffer behavior and it greatly improved potential player thrashing at Pivos.
As for DVDs, they are MPEG2 and there is zero reason now to be diddling with hardware decode for them. Most if not all Android based (and rpi2) boxes are quad-core and have more than enough ponies to handle the decode and deinterlace with room to spare.
DVDVideoCodecAmlogic has two parts, a wrapper/helper for a codec and the AMCodec core. Originally AMCodec was based on internal AMLogic codec code and has become quite squirrelly (technical term). The render method (by-pass) was the best I could get approved by the owner of that area of code (elupus) and the render callbacks were the only way to get the updates when needed. It was only when renderer code was changed to include timestamps that problems really started to show up. Prior to that it was quite good.
Maybe there is something better, maybe not, but to call it wrong is silly. It's just a different way and has worked for years despite the constraints the code was forced to live with.
One area that really needs serious thought is the system amcodec can and will try to suck down large amounts of demux. We are not taking about a few frames here, 10s of seconds of frames. Too little and the system by-pass renderer will stop and wait, too much and the internal kodi player will thrash. It's very tricky to get the right amount of balance as the system codec is like a run-away train, all you can do is try and make sure it stays on the tracks. I mentioned this very thing once and was told it's wrong too
Well, right or wrong, that is the way the system codec works and unless you are willing to dive into some massive kernel driver code, that is the way it will always work. AMLogic has no interesting in changing its behavior as a pure streaming codec. At least now you can get the amount of time buffered but that only works with h264 (maybe h265). So far, I have seen very little interest in the change I did to move from size to time in controlling buffer behavior and it greatly improved potential player thrashing at Pivos.As for DVDs, they are MPEG2 and there is zero reason now to be diddling with hardware decode for them. Most if not all Android based (and rpi2) boxes are quad-core and have more than enough ponies to handle the decode and deinterlace with room to spare.
