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

[Gildas Bazin]

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 
spec.

There have been talks about changing our clock synchronisation algorithm 
(which is only really adapted to LAN streaming) so this might change in the 
future.

>
> 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.

--
Gildas

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html