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

[Leon Woestenberg]

Hello Andreas,

I am very interested in this work of yours. I am probably working with
the very same hardware encoder product (Vweb VW2010 MPEG-2/4 codec) and
I have their specs here. I am not sure from your email which chip you
are using (because eyeTV also uses the Wischip 7007 for some of their 
products).

Anyway, we are using the Program Stream firmware.

Did you get teletext capture, or any other kind of VBI capture or
playout to work with their streams?

Regards,

Leon.

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.
> 
> 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.
> 
> Regards,
> 
>   Andreas Junghans
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: leonw.vcf
Type: text/x-vcard
Size: 74 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20050314/3c4b32cc/attachment.vcf>
-------------- next part --------------
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 3/11/2005