[vlc-devel] Re: [PATCH] mpeg4 packetizer
gbazin at altern.org
Thu Mar 10 11:53:45 CET 2005
On Wednesday 09 March 2005 22:54, Andreas Junghans wrote:
> Hi list,
> I'm the developer of CyTV
> ("http://www.lucid-cake.net/cytv/index_en.html"), a streaming solution
> for certain TV tuners on OS X. It's based on VLC for playback, and I'm
> very greatful for this terrific player!
> During the last few weeks, I wrestled with MPEG-4 streams produced by
> Plextor's ConvertX unit in combination with elgato's EyeTV software for
> OS X. These streams consist of MPEG-4 video embedded in an MPEG-2
> transport stream. A sample is available here:
> The first problem was that there are no PCRs in the stream. I've
> already encountered this in the past, and I've solved it by generating
> PCRs based on the streams' audio timestamps on the fly to make them
> playable. The sample stream mentioned above, but with these artificial
> PCRs inserted, is available here:
> It would be nice if VLC wasn't so dependent on PCRs. Are clock
> differences between systems really so bad? I would assume (perhaps
> naively) that playback would work just fine with an internal clock that
> just keeps running (without synchronization with the stream's PCRs).
> Even if there are differences in the millisecond range, they shouldn't
> be noticeable (especially since it's only a question of playback speed,
> not audio/video sync). I'd appreciate some comments about this.
VLC relies a lot on PCRs partly for historical reasons and partly for
Historical reasons are mainly that VLC was originally designed as a network
player for MPEG TS so its design was very much based on the MPEG TS logic.
Technical reason is that being a network player, VLC needs to keep in sync
with the server's sending rate so that its buffers don't
underflow/overflow, and this is done in the demuxer using the PCRs.
This could surely be done using only the PTS/DTS (since we are not very
tight on buffer memory like hardware players are) but would be technically
more difficult and anyway the PCRs are a mandatory part of the MPEG TS
There have been talks about changing our clock synchronisation algorithm
(which is only really adapted to LAN streaming) so this might change in the
> After I generated PCRs artificially, the stream sort of worked. Audio
> was fine, but video was stuttering badly (looking "scratched" with some
> sequences shown too early and some too late). However, transcoding the
> stream with ffmpeg worked fine, so it seemed like the stream was OK. A
> few long debug sessions later, it turned out that there are problems in
> modules/packetizer/mpeg4video.c - the timestamps are simply not handled
> correctly (even in the latest svn version).
> Attached is a patch (against the current trunk, freshly checked out)
> that fixes playback of the ConvertX streams for me (at least after PCRs
> have been inserted). It's basically a port of ffmpeg's mpeg4 timestamp
> handling to VLC's mpeg4 packetizer. However, it's not quite ready since
> I've completely ignored DTS for now. I'd appreciate any insight into
> how the decoding timestamps are used by VLC. Simply setting them to the
> same value as PTS seems to work just fine, so that's what I'm currently
> doing. It would be great if someone could explain to me how these are
> actually used, so I could come up with a proper patch.
At first sight the patch doesn't look right to me... I'll try to investigate
that with your sample.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel