[mythtv-users] 0.25 Major AV sync problems

[David Moore]

On 19/06/12 16:24, Jean-Yves Avenard wrote:
> On 18 June 2012 18:41, David Moore<dmoo1790 at ihug.co.nz>  wrote:
>
>> Hi Jean-Yves, I'm running 0.25+fixes from mythbuntu repos. Is it possible to
>> do a simple upgrade from this to the current master? Or do you mean compile
>> the master from source?
> Be aware that you will not be able to easily go back to 0.25+fixes,
> and at best you'll have to go back to the last backup. So if you've
> made any recordings after upgrading to master and you're going back to
> 0.25 they won't be easily accessible.
>

I guess you mean the database schema is different in the master? Anyway 
I probably won't try it. System is nearly perfect so don't want to risk 
breaking it or making it worse.

>
> Having said that... There's a nightly build of master on the mythbuntu repo
>
>>
>> I'll upload a sample when I can figure out where to upload it to. The things
>> I see are common across all DVB-T broadcasts in NZ. No difference if I
>> select AAC or AC3 audio on channels where this is possible. The problem
>> seems to be something to do with audio PTS so I guess it's independent of
>> codec type.
>
> it's bizarre that it's not something everyone would see

More bizarre than you may think. I tried playing files with mythffplay 
and also ffplay (version N-40644-g04064e1). Neither show the problems I 
see in mythtv. One obvious difference is displayed A-V sync always 
"pulls in" to a small value (< 0.1) with ffplay and mythffplay. With 
mythtv it usually stops at a value around -2. Weird thing is 
mythfrontend.real and mythffplay use the same libmythav* libraries.

And now that I grep the code for "AVSync" I find that mythplayer.cpp has 
a bunch of functions which appear to handle audio/video sync. And there 
appears to be different A/V sync code in ffplay.c. Hmmm. Starts to make 
sense. I think the A/V sync code for any media player would likely be in 
the player code rather than a shared library because it would be largely 
codec independent. This would also explain why mythfrontend.real and 
mythffplay can use the same libraries yet exhibit different A/V sync 
behaviour.

So my bet is something in the mythplayer code is the problem, not in 
ffmpeg code. Or maybe some interaction between mythplayer and ffmpeg code.

But once again let me stress that it would be nice to fix but not 
critical for me. I can live with it.