[vlc-devel] issue arising from OggDirac muxing
davidf+nntp at woaf.net
Tue Oct 28 13:01:08 CET 2008
On 2008-10-28, Laurent Aimar <fenrir at via.ecp.fr> wrote:
> On Mon, Oct 27, 2008, David Flynn wrote:
>> So i propose adding an extra field to es_format_t to store the first
>> pts output from a decoder (or packetizer if it can solve it).
>> i_time_pts0 ? any other suggestions
> That's not possible, at least because of:
> - es_format_t has to be created before this value can be known in a lot of
> cases (ts, ps, avi, etc).
However, it would be possible to fill it in when it becomes known, and
for a muxer to wait until it is filled in.
Actually, thinking about it some more, i don't even think that it is
correct to renormalize each ES independently, consider the case of
the following output from a decoder:
AudioPTS: [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, ...]
VideoPTS: [ -, -, -, 13, 14, 15, 16, 17, 18, 19, 20, ...]
If these two streams are then normalized independently, you end up with
a 3 frame a/v sync issue.
> - A timeshift is applied after the decoder or packetizer and will depends on
> pause, seek etc.
> - The es_format_t is not recreated after a seek whereas i_time_pts0 need to be
I don't see how either of these should affect muxing (I have a problem
trying to define the semantics of a pause or seek in the middle of a
remux or transcode).
More information about the vlc-devel