[vlc-devel] asf, core and codecs

[Francois Cartegnie]

Hi,


Well, after many days of investigating and fixing asf,
I've figured out the main problem and tried many different ways to solve it.

We were relying on pts from asf muxer to set up PCR and blocks pts.
As video & audio packets are interleaved and then may have pts out of
sequence, if the audio packet was less frequent, the PCR for the stream
was reset.

The asf "send time" timestamp from each packet is the only reliable
(incremental, frequent) timebase to work with. So I started working with
it for PCR computation, and this indeed solves most of the problems.

Unfortunately, asf has some "preroll" time, offsetting all timestamps.
(mostly to cope with the huge latency between audio & video in some
streams. Your 1st packet has a 20s pts and will be decoded after 20s of
buffering. This duplicates our own buffer handling)
If we have a 20sec preroll, every packet PTS is offset'ed by 20s.
ex: niceday.asf
( For the fun, that's not the only possible global offset... )

Currently, 2 solutions have some drawbacks:

1 - Subtracting preroll on PTS & PCR computation.

We no longer have problems with audio or other tracks latency, but the
PCR update/demuxing stops at duration - preroll, because everything
has been already buffered.
Afaiu, the culprit here seems the decoder which still reads/handles
preroll and is tricked by its removal from pts.

2 - Keep preroll offset, and fix time/position information.

Buffering is correct (demuxes/updates up to the end time) but the audio
decoder complains about the audio delay and plays nothing (assuming the
PTS in still in sequence).


If someone has a clearer understanding of the clock/pcr/decoder's fifo
handling, I'll take any hints to end solving that issue.
(assuming my guesses are correct)


For 1, I can't patch the header before sending to decoder: this would
have been too easy :/


Francois