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

[Andreas Junghans]

Hi list,

Am 10.03.2005 um 11:53 schrieb Gildas Bazin:

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

OK, got that. I'll keep generating artificial PCRs then.

>> 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).
>>
>
> The mpeg4video packetzier behaves just fine, it's your stream that is
> completely broken.
> In the timestamps log I included at the end of the mail, you'll see 
> that
> your stream doesn't follow the MPEG standard.
>
> 1 - It timestamps every frame (which is fine) but the timestamps are 
> not
> valid (hence your hack to ignore them by only taking them when a GOP
> appears).
> 2 - An other obvious mistake is that DTS and PTS are mandated by the 
> MPEG
> spec to be equivalent for B frames (which clearly isn't the case here).

Sorry, I didn't realize that. I'm not familiar enough with the specs - 
I simply assumed what's produced by the Plextor unit is a valid stream. 
The fact that ffmpeg has no problems with it looked like another 
indicator that VLC is misbehaving here. However, ffmpeg has a lot of 
corrections for broken stuff, so I assume this is just one more. My 
apologies for jumping to conclusions.

>> 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.
>>
>
> This patch is unacceptable because:
> 1 - It ignores the frames' PTS/DTS except on GOP boundaries. That's not
> acceptable simply because the PTS and DTS information passed on from 
> the
> demuxer should always take precedence over timestamp interpolation.
> 2 - The timestamp interpolation is not based on current/previous DTS 
> anymore
> which will break demuxers which don't have any PTS information (eg. 
> avi).
>
> The current timestamping in the mpeg4video packetizer isn't broken at 
> all
> (not surprising since it timesamps the frames based on the spec 
> defined in
> the MPEG standards).

OK. Thanks for your time and effort in analysing this, I appreciate it 
very much! I'll keep my current solution then (start VLC with a 
plugin-path that contains my patched mpeg4 packetizer). Of course it 
would be better to have valid streams to begin with, but I'm not in a 
position to influence that.

Thanks for your feedback!

   Andreas

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