[linux-dvb] Re: Problems using mplex (fwd)

[Jan Panteltje <root@panteltje.demon.nl>]

---------- Forwarded message ----------
Date: Sun, 6 May 2001 00:36:47 +0200 (CEST)
From: Jan Panteltje <root@panteltje.demon.nl>
To: ma.hoff@bigfoot.com
Subject: Re: [linux-dvb] Re: Problems using mplex



On 5 May 2001 ma.hoff@bigfoot.com wrote:

> > Isn't there a chance that the answer is much simpler:
Yes, see below

> > 
> > The firmware or the driver occasionally loses a packet?
> Maybe, but it makes no difference - the results are recordings which get out of sync by demuxing and muxing again. But this is what we have to do, regardless of the destination format (X-SVCD / MiniDVD / SVCD / DivX / VCD or what ever). That's why we should look for a solution or a workaround...
> 
> Okay if it's the driver, it may be corrected, but I doubt that, because with windows drivers it's just the same... So maybe the firmwares fault, but then we can nothing do about that, right?
> 
> I hope we'll find some solution soon, because on the 14.5 Sat1 broadcasts STAR TREK every day of the week - thats a lot to record and convert...;-)
> 
> Martin.
I am still working on the subtitle software.
For this I need good lip sync too.
I have written a program that reads av_pes (from driver 0.7.1) and
then I add a constant to each video PTS.
3600 seems to be one picture (40 mS) coming from the 90 kHz reference in
mpeg2, coming from the 27 MHz xtal divided by 300.

So much for that, this way it seems possible to align audio in place.
For example for adding 5 frames shift (relative to audio) you have to add
18000 (5 x 3600) to each video PTS.

This works so far.
Also I noticed in the process that the packets are not in incremental
sequence (so neither are the frames / pictures), but like:
current_video_pts=3947359872
start_video_pts=3946341072
in play=1018800
current_picture=283 <<<<<<<<<<<<<<<<<<<<<<<<<<<<
WAS stream ID=1
old pts=3947392272 offset=-18000  < here I substract 5 pics from the video,
                                      so the audio gets earlier. 
new pts=3947374272
video section
current_video_pts=3947374272
start_video_pts=3946341072
in play=1033200
current_picture=287 <<<<<<<<<<<<<<<<<<<<<<<<<<<
WAS stream ID=1
old pts=3947385072 offset=-18000
new pts=3947367072
video section
current_video_pts=3947367072
start_video_pts=3946341072
in play=1026000
current_picture=285 <<<<<<<<<<<<<<<<<<<<<<<<<<<
WAS stream ID=1
old pts=3947388672 offset=-18000
new pts=3947370672

 
So this is already ++++ times faster then demuxing and remuxing to mpeg2,
which gave me no usable audio anyways.
Now I am contemplating writing code that re-arranges the video frames in
incremental order (so as to prese3nt a more pleasnt stream to the
'hardware'.
Also this has no buffer limit really in Linux.
Maybe that will solve any additional frame drops...

Will probably write to a buffer and keep a linked list, or hashed list of
structures holding the audio and video packet data, and then read ijn
sequence from that list...
No promises when this will work.
Regards
Jan




-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.