[vlc-devel] Re: [PATCH] mpeg4 packetizer

Gildas Bazin 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: 
> "http://www.lucid-cake.net/cytv/mpeg4sample_orig.ts".
> 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: 
> "http://www.lucid-cake.net/cytv/mpeg4sample.ts".
> 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 
technical reasons.

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 mailing list