[vlc-devel] [RFC] Don't trust the PCR by default

[Denis Charmet]

Hi,

Le lundi 17 mars 2014 à 04:42:33, Francois Cartegnie a écrit :
> This kind of fix needs an observation window, or can't be that easy.
I agree this is just a PoC, (it took me a lot more time to figure out the
demux architecture than to actually write this). My goal is to start a
real technical discussion about this issue and give broadcast experts
the chance to give their opinion.
 
> You can't ask the user to specify to trust pcr or not. Otherwise, just
> use avcodec. So you need to check is PCR is accurate, and estimate gap
> which needs to watch some packets.

I'm only reusing an option that Raphael added a few month ago (and think
that he should have made it this way :)
> 
> Then taking the lowest DTS after means packets have already been sent
> (and PCR must have been set too) and you're probably setting a new
> PCR<DTS value for, at least, one track.
Nah because if you don't trust PCR, the code doesn't call SET_GROUP_PCR
on the PCR.
Now I agree that this PoC lacks proper verfication to avoid the fact
that if a pid is absent in a group it will always send VLC_TS_INVALID
which sucks but that's easily fixable.

> 
> Furthermore, the rollover needs to be handled too from that point as
> DTS/PCR might now be set in pre-rollover values while PTS might be post
> rollover. We are also killing the purpose of PCR.
To be honest if the PCR is valid why would the DTS be invalid? Isn't
that taking the best of the both world? Now what happens when your
stream lacks PCR?
While PCR master makes a lot of sense for broadcast (dtv) using dts for
file may not be completely stupid.

> 
> According to the spec, DTS is always monotonically increasing. So we
> might only need to pick the first DTS of the first packet we see,
> assuming there's not violation of that part of the spec.
Well I fail to imagine a source that would send out of decoding order
data without breaking the continuity counter. Again using dts is the way
used by other long used and tested demuxes.

> 
> And to keep the PCR clock signals, we could compute a (DTS - PCR) offset
> which would be applied to any other stamp. But this means, again, to set
> an observation window, which requires preseek or to buffer blocks
> (annoying for 4K) until an undefined deadline (*).
I've seen streams where PCR increase twice faster than the DTS so the
difference may be debatable too.

I'm going to study the norm a little closer and try to figure out a
better solution (unless someone has a brilliant idea).

Regards,

-- 
Denis Charmet - TypX
Le mauvais esprit est un art de vivre