No description provided.
changed, add a proper GUI selector for AMLogic video decoder, refacto…
…r AMLogic bits in AESinkAUDIOTRACK
will be overwritten with 0.0 below ... if the diff shows it right - might want to add an else here?
crap, I'll rework it, I don't want a dangling else just waiting to f**k us over if someone does not watch what they are doing.
@davilla @FernetMenta @fritsch: This is our blip. I missed it on mainline due to amcodec not being enabled by default. :/
so adding this blips, removing it, removes the blip ?
Most of it :)
I'm still seeing a much shorter and less consistent blip of silence on the Pivos tree. I'll bring over @FernetMenta's work since a10 tomorrow, which I have high hopes of resolving the remainder.
this was added to resolve a noticeable constant a/v offset of about 1/4 second.
want to use the setting here instead of aml_present like you did with the othrer?
no, if the device is some AMLogic SoC, then the m_audiotrack_empty_sec_tweaks applied for all audio, not just audio that comes from playing a video with amcodec. So it is device depended, not video codec dependent
fixup, order check for m_audiotrack_empty_sec_tweaks
I'm suspecting this is the cause of http://forum.xbmc.org/showthread.php?tid=181739&pid=1617597#pid1617597
The only right way to decode dvd menu stills is using libmpeg2 - because when amcodec is enabled, you'll ultimately fall back to ffmpeg decoding which is proven not to work for dvd stills (hint.stills = true and hint.software = true). Perhaps a solution to try would be:
if (!CSettings::Get().GetBool("videoplayer.useamcodec") || hint.software)
to at least allow to get in here for software decoding.
hint.software is much less expensive than '!CSettings::Get().GetBool("videoplayer.useamcodec"' in the case of an OR, the less expensive operations should be first in line :)
of course, I was merely pointing out the idea.