Re: [vdr] FF card A/V sync suggestion

2006-11-12 Thread Petri Hintukainen
 I'm afraid my knowledge here is too limited.
 If somebody can come up with an idea of how additional timing information
 should be inserted in the PES data, let's hear it.

I'm quite sure this is not the point to work witht.

 Generally I don't think that VDR should have to to anything regarding
 A/V sync during replay. It simply feeds the data to the device as fast
 as the device can take it, and syncing audio and video is the device's
 job. Maybe mplayer just generates additional PES headers for this?

xine and/or mplayer just re-generates the pes layer. So, it have to be
there ?
xine has no problems with the provided samples, so I guess it must be in
the PES layer re-muxing. Has anyone with the problem tried to replay
with separate mpa+mpv - pes streams ?


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-12 Thread Chad Flynt
Thanks for not giving up on this yet guys. 


Udo Richter wrote:


Petri Hintukainen wrote:


xine and/or mplayer just re-generates the pes layer. So, it have to be
there ?
xine has no problems with the provided samples, so I guess it must be in
the PES layer re-muxing. Has anyone with the problem tried to replay
with separate mpa+mpv - pes streams ?



For the tero sample from this thread, I've demultiplexed it with 
projectx and re-muxed it to VDR, and it was playing fine. It must be 
on the PES layer. The only thing I've noticed was a slight +/-1 jitter 
in the PTS timecode of the audio track.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-12 Thread Udo Richter

Udo Richter wrote:

Udo Richter wrote:

Tero Siironen wrote:

Here is a 3 minute clip from the episode of Lost I told earlier.
http://kotisivu.suomi.net/izero/lost.tar

80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X


The only disturbance I've noticed is a slight jitter in the PTS values 
of the audio packets, they are sometimes off by +/- 1, thats 0.01ms. I 
don't know whether the driver ignores such slight offsets, but I guess 
it probably does, esp. since it seems to never sync anyway.


So much for that theory. I've wrote an experimental patch to VDR to fix 
this specific stream, but playback is the same, even with the fixed PTS 
jitter. :(


Cheers,

Udo


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-12 Thread VDR User
First, I too want to express my gratitude  appreciation towards the people actively persuing a once  for all fix to this problem! So what about this... Copy the mplayer code that does the PES layer and slap it into vdr just to test if the problem persists? It seems that the majority opinion is this is in fact a vdr issue rather than a firmware issue but whats the opinion of the person who develops the firmware (if anyone knows)?
On 11/12/06, Udo Richter [EMAIL PROTECTED] wrote:
Udo Richter wrote:So much for that theory. I've wrote an experimental patch to VDR to fixthis specific stream, but playback is the same, even with the fixed PTSjitter. :(Cheers,Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-12 Thread Udo Richter

VDR User wrote:
about this...  Copy the mplayer code that does the PES layer and slap it 
into vdr just to test if the problem persists? 


I don't think that it is that easy. Its just educated guessing, but I 
assume that the mpeg data is going a long way through the mplayer core, 
through demultiplexers, resyncers, multiplexers, playback control and 
lots of more stuff. Thats probably several thousand lines of code that 
need to be reviewed, rewritten and integrated into VDR. Thats a huge 
task, and its probably easier to re-implement every step mplayer does in 
VDR from scratch.


It seems that the 
majority opinion is this is in fact a vdr issue rather than a firmware 
issue 


Once again, I don't agree. VDR does almost nothing on playback. VDR 
recordings are streams of PES packets, and the DVB driver accepts PES 
packets for playback. The only thing VDR does is to drop video packets 
into the video interface and audio packets into the audio interface.


(If there wouldn't be the need to separate video from audio, you could 
probably simply do cat 001.vdr  /dev/dvb/adaper0/video0 and it would play.)


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-06 Thread Steffen Barszus

whoMAN schrieb:


I'm not sure if it's been answered yet, but I thought I'd throw this out:


mplayer uses either LAVC or FAME [depending on how mplayer was
compiled/configured] to convert EVERYTHING to MPEG1 before it is sent 
to the

DVB Device.  In essence, it transcodes in realtime.

Not too efficient, but since transcoding to MPEG 1 takes little 
resources,

most people probably don't notice.

I know it's probably what most of you didn't want to hear, but I 
figured you

guys would want to know.


whoman421

Thats plain wrong. Anything that can be feed directly, will not be 
transcoded. And i can see mplayer taking ressources , if mplayer is 
transcoding. Not everybody has a core duo 6600 ;)



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-03 Thread VDR User
I joined the mplayer mailing list and have tried to seek help/information from those nice folks.. The following is part of one of my exchanges. Maybe the part about the timestamp may be of some help?
 I asked a couple specific questions and included some quotes from other posts to provide an idea of what we're looking at as the cause. I can't tell you what the exact problem is because we're still trying to figure that
 out... And a good place to start is by comparing the differences between the software that has the problem and software that doesn't. We're trying to figure out what mplayer does, if anything, with regards to
 repacking, the pes layer, pcr data, etc. during the playback of a VDR recording.nothing particular: the pes packetization is as standard as you can get,
except that IIRC there's a timestamp on every single frame,rather than once every 0.5-0.7 seconds; this fact alone can make alot of difference during playback.Does the desync that you are experiencing get worse with time or does
it regularly decrease and next increase?
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-03 Thread whoMAN
I'm not sure if it's been answered yet, but I thought I'd throw this out:mplayer uses either LAVC or FAME [depending on how mplayer was compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to the DVB Device. In essence, it transcodes in realtime.
Not too efficient, but since transcoding to MPEG 1 takes little resources, most people probably don't notice.I know it's probably what most of you didn't want to hear, but I figured you guys would want to know.
whoman421On 11/3/06, VDR User [EMAIL PROTECTED] wrote:
I joined the mplayer mailing list and have tried to seek help/information from those nice folks.. The following is part of one of my exchanges. Maybe the part about the timestamp may be of some help?
 I asked a couple specific questions and included some quotes from other posts to provide an idea of what we're looking at as the cause. I can't tell you what the exact problem is because we're still trying to figure that
 out... And a good place to start is by comparing the differences between the software that has the problem and software that doesn't. We're trying to figure out what mplayer does, if anything, with regards to
 repacking, the pes layer, pcr data, etc. during the playback of a VDR recording.nothing particular: the pes packetization is as standard as you can get,
except that IIRC there's a timestamp on every single frame,rather than once every 0.5-0.7 seconds; this fact alone can make alot of difference during playback.Does the desync that you are experiencing get worse with time or does
it regularly decrease and next increase?

___vdr mailing listvdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-03 Thread Pertti Kosunen

whoMAN wrote:
mplayer uses either LAVC or FAME [depending on how mplayer was 
compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to 
the DVB Device.  In essence, it transcodes in realtime.


It doesn't transcode MPEG2.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-11-03 Thread Udo Richter

whoMAN wrote:
mplayer uses either LAVC or FAME [depending on how mplayer was 
compiled/configured] to convert EVERYTHING to MPEG1 before it is sent to 
the DVB Device.  In essence, it transcodes in realtime.


Not too efficient, but since transcoding to MPEG 1 takes little 
resources, most people probably don't notice.


Once again, this is impossible. Really.

My CPU is a VIA C3-600 CPU, and its really too slow to transcode 
*anything*. If I force transcodung with -vf lavc=1000, the CPU load is 
99% and the video plays at 40% original speed only. Just decoding the 
mpeg2 stream eats up 75% CPU alone, without audio and without displaying.


Without forcing transcoding, the CPU load is 10% and no frames get 
dropped. This is roughly 25 times faster than with lavc=1000.


Cheers,

Udo


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-31 Thread Torgeir Veimo


On 31 Oct 2006, at 13:36, C.Y.M wrote:



But I guess they decode the PES stream into two ES streams with
additional timing, and re-pack it to a new PES stream.


Guessing doesn't really help, maybe you should ask on the mplayer  
mailing list what they do with recorded vdr files?


--
Torgeir Veimo
[EMAIL PROTECTED]




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-31 Thread VDR User
If this were a firmware/driver problem then wouldn't the problem exist regardless of the playback software? The fact that vdr has playback sync problems whereas mplayer doesn't when playing back the same file suggests it's a vdr problem... But this has already been covered.
On 10/30/06, Oliver Endriss [EMAIL PROTECTED] wrote:
Afaics it is a firmware/driver problem. It should be fixed there.Werner is currently working on a modified A/V sync code.We will see whether is improves things. Please be patient.Oliver

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-30 Thread Oliver Endriss
Klaus Schmidinger wrote:
 Udo Richter wrote:
  Klaus Schmidinger wrote:
  Morfsta wrote:
  I second that, please don't let it drop again.. Is anyone actually 
  working on this, Klaus, Oliver, ANYONE?
 
  I'm not working on this, because ATM I wouldn't know what to do.
  
  Any comments on C.Y.M's point that PCR should be recorded/used?
  - http://www.linuxtv.org/pipermail/vdr/2006-October/011061.html
  
  As far as I understand this, VDR ignores the TS-layer PCR timing data 
  (which, as far as I understand this, controls the raw data rate fed to 
  the decoders) and the syncing is done by DVB driver/firmware based on 
  the timing information in the underlying PES headers. Since the DVB 
  playback also works on PES layer and accepts data on all-you-can-eat 
  base, I'm not sure whether feeding the DVB device on PCR based data 
  rates would help, or how PCR should be forwarded to the DVB hardware.
 
 I'm afraid my knowledge here is too limited.
 If somebody can come up with an idea of how additional timing information
 should be inserted in the PES data, let's hear it.

Imho there is no need to add anything to the PES data format.

In live mode PCR is required to synchronize the internal clock of the
decoder to the master clock of the transmitter.

In replay mode the clock of the decoder is running free, i.e. it is the
master clock. No need for a PCR or something like that.

 Generally I don't think that VDR should have to to anything regarding
 A/V sync during replay. It simply feeds the data to the device as fast
 as the device can take it, and syncing audio and video is the device's
 job. Maybe mplayer just generates additional PES headers for this?

Does mplayer really play PES data 'as is'?
Afaik it recodes data to MPEG-1.(?)

Afaics it is a firmware/driver problem. It should be fixed there.
Werner is currently working on a modified A/V sync code.
We will see whether is improves things. Please be patient.

Oliver

-- 

VDR Remote Plugin 0.3.8 available at
http://www.escape-edv.de/endriss/vdr/



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-29 Thread Klaus Schmidinger

Udo Richter wrote:

Klaus Schmidinger wrote:

Morfsta wrote:
I second that, please don't let it drop again.. Is anyone actually 
working on this, Klaus, Oliver, ANYONE?


I'm not working on this, because ATM I wouldn't know what to do.


Any comments on C.Y.M's point that PCR should be recorded/used?
- http://www.linuxtv.org/pipermail/vdr/2006-October/011061.html

As far as I understand this, VDR ignores the TS-layer PCR timing data 
(which, as far as I understand this, controls the raw data rate fed to 
the decoders) and the syncing is done by DVB driver/firmware based on 
the timing information in the underlying PES headers. Since the DVB 
playback also works on PES layer and accepts data on all-you-can-eat 
base, I'm not sure whether feeding the DVB device on PCR based data 
rates would help, or how PCR should be forwarded to the DVB hardware.


I'm afraid my knowledge here is too limited.
If somebody can come up with an idea of how additional timing information
should be inserted in the PES data, let's hear it.

Generally I don't think that VDR should have to to anything regarding
A/V sync during replay. It simply feeds the data to the device as fast
as the device can take it, and syncing audio and video is the device's
job. Maybe mplayer just generates additional PES headers for this?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-24 Thread Joerg Knitter

Klaus Schmidinger wrote:

C.Y.M wrote:
Since it has been several years now and I have never been able to 
solve the a/v

desync issues with my Nexus-S FF card when playing back recordings...


I'm replaying many recordings (actually most of what I watch
are recordings ;-) and don't even remember when was the last
time I had an A/V desync.


There is one more issue, that seems to be related. On some recordings, 
here RTL Television with AC3 playback, sometimes single frames seem to 
be skipped during playback. I watched a recording of Alarm für Cobra 
11 yesterday and could identify at least 6 little jumps.


I have isolated a 20 MByte part of this recording where this effect was 
clear to see - I can send it by seperated mails or upload it somewhere 
if someone gives me an URL.


The weird thing: Playing those isolated scenes does not show the effect 
as people can see if they play the whole recording from the beginning, 
but rewinding the short clip to a certain point makes it possible to 
reproduce the problem. And again: This just happens when playing back 
the AC3 audio track.


With kind regards

Jörg



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-24 Thread Joerg Knitter

Torgeir Veimo wrote:


On 24 Oct 2006, at 12:44, C.Y.M wrote:

Somehow, mplayer is able to detect the areas in the VDR recordings 
that need
extra padding to keep the sync.  There must be some kind of pattern 
in the
data that the player recognizes and it knows it must insert a null 
frame.  How

to go about finding how it works and creating an algorithm.


So you're certain that it's always picture frames being dropped, causing 
audio to be behind the video?


Despite of the lost frame, the playback seems to be in sync. On the 
other side, I havent heard any jumps in sound yet.
This could only be possible when the timing of audio and video would be 
different and the software would try to keep video and audio in sync by 
dropping sometimes a single video frames.
On the other side, if the same recording works when playing back video 
with the MP2 track, it looks like a buffering or packaging issue, as if 
in this case the DD packages would not fit into a certain time scale.


With kind regards

Jörg

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-24 Thread Steffen Barszus

Torgeir Veimo schrieb:



On 24 Oct 2006, at 12:44, C.Y.M wrote:

Somehow, mplayer is able to detect the areas in the VDR recordings  
that need
extra padding to keep the sync.  There must be some kind of  
pattern in the
data that the player recognizes and it knows it must insert a null  
frame.  How

to go about finding how it works and creating an algorithm.



So you're certain that it's always picture frames being dropped,  
causing audio to be behind the video?


Since mplayer is open source , someone who is able to do changes on that 
should contact someone at mplayer/xine.
I think Nico Sabbi is working on dvb area on mplayer side. Further i 
think mplayer is checking very closely sync issues. For most stations 
the video stream  should fulfil the task of the PCR stream, but here 
people that really know what they are talking about should step in ;) 
Furthermore mplayer-dvb list might be applicable.


Steffen

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-24 Thread C.Y.M
Torgeir Veimo wrote:
 
 On 24 Oct 2006, at 12:44, C.Y.M wrote:
 
 Somehow, mplayer is able to detect the areas in the VDR recordings
 that need
 extra padding to keep the sync.  There must be some kind of pattern
 in the
 data that the player recognizes and it knows it must insert a null
 frame.  How
 to go about finding how it works and creating an algorithm.
 
 So you're certain that it's always picture frames being dropped, causing
 audio to be behind the video?
 

From what I understand, it could be either video or audio that is using
stacked data.  Either a video frame that does not change or perhaps a few
seconds of silence on the audio track could trigger this.

Best Regards.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread Guy Roussin
Tero Siironen [EMAIL PROTECTED] wrote :
 Here is a 3 minute clip from the episode of Lost I told earlier.
 http://kotisivu.suomi.net/izero/lost.tar
 
 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X
 
if i make this, the file play fine (vdr ffcard) :

mv 001.vdr _001.vdr
mv index.vdr _index.vdr
mplayer -vo mpegpes:001.vdr -ao mpegpes 001.vdr
genindex

But now the file 001.vdr is 100Mb !
--
Guy Roussin

___
http://www.teledetection.fr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread C.Y.M
Guy Roussin wrote:
 Tero Siironen [EMAIL PROTECTED] wrote :
 Here is a 3 minute clip from the episode of Lost I told earlier.
 http://kotisivu.suomi.net/izero/lost.tar

 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X

 if i make this, the file play fine (vdr ffcard) :
 
 mv 001.vdr _001.vdr
 mv index.vdr _index.vdr
 mplayer -vo mpegpes:001.vdr -ao mpegpes 001.vdr
 genindex
 
 But now the file 001.vdr is 100Mb !
 --

Am I doing something wrong? I dont seem to have any sound.. also if you move
001.vdr to _001.vdr, then the command below will not be able to find the file. 
:)

Good info though! Thanks.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread Guy Roussin
 if i make this, the file play fine (vdr ffcard) :
 
 mv 001.vdr _001.vdr
 mv index.vdr _index.vdr
 mplayer -vo mpegpes:001.vdr -ao mpegpes 001.vdr
 genindex
  
 But now the file 001.vdr is 100Mb !
 
 Am I doing something wrong? I dont seem to have any sound.. also if you move
 001.vdr to _001.vdr, then the command below will not be able to find the file.
 :)

Sorry for the typo :

 mplayer -vo mpegpes:001.vdr -ao mpegpes _001.vdr

--
Guy Roussin

___
http://www.teledetection.fr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread Joerg Knitter

Udo Richter wrote:
Just talking about the case that I've reported. I experience such issues 
only very rarely, and mostly related to bad reception. The reported 
issue related to blackness is very specific to this channel.


Do you mean that this is e.g. just related to ATV+? Does Lost on 
ProSieben play without problems?
This problems also appeared with 24 from ATV+ (also black fades on 
counter jumps). Anybody commenting if there are also problems with 24 
recordings from RTL2?


I can also see some sync problems e.g. when I have cut a recording from 
Sat1. During playback, VDR often gets out of sync directly after a cut 
point so that I have to press rewind and play to get it back in sync 
again. I think that I have also seen some weird sync behaviour after 
jumping within a recording of e.g. WDR - pressing rewind and play 
also does help here.


Maybe this problem also is connected to recent problems with xinelibout 
and DVB-T: Switching to the ARD transponder here near Munich, the A/V 
sync sometimes takes about 20 seconds to get right, while other channels 
 give instant sound.
Everyone who wants to test it could take a look at the latest Kanotix 
version where VDR, xinelibout and some channels.confs are included so 
that it can be started directly from the live CD without installing.


With kind regards

Jörg

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread Mattia Rossi
On Mon, 23 Oct 2006 17:49:38 +0200
Joerg Knitter [EMAIL PROTECTED] wrote:

 Udo Richter wrote:
  Just talking about the case that I've reported. I experience such
  issues only very rarely, and mostly related to bad reception. The
  reported issue related to blackness is very specific to this
  channel.
 
 Do you mean that this is e.g. just related to ATV+? Does Lost on 
 ProSieben play without problems?
 This problems also appeared with 24 from ATV+ (also black fades on 
 counter jumps). Anybody commenting if there are also problems with 24 
 recordings from RTL2?
 

If it can help to better pinpoint the problem, I have same symptoms, and
same cause (loss of audio/video sync on black fades - dark scenes) with
almost all recordings of C.S.I from Fox Crime - Sky Italia and a lot of
Battlestar Galactica episodes from Fox - Sky Italia in the last two
years. I do not have the same symptoms from other Sky Italia
recordings, mainly sport events. One factor that can compound the
problem is that the channels I am recording are encrypted and the
decoding is done through a real smartcard, real subscription connected
to a serial smartcard reader. 
I'll try to isolate a couple of recordings
and pass them through mplayer to check whether they come out clear.
I do not have the dropouts when I burn the recordings to dvd with the
burn plugin, but I am digressing.

Cheers

Mattia

-- 
---MR.-

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread VDR User
I just want to say that I, and many others not on the ml, are thankful this problem is finally being seriously addressed! It's very much appreciated that work is currently being done to discover and resolve the a/v sync problems once and for all! Many of us have just gotten used to the idea it would never be fixed but seeing this new activity happening makes people optimistic again.
On behalf of myself and everyone else who've hassled with this problem, thanks to all contributors! Your work is greatly appreciated!
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread Lauri Tischler

Richard Scobie wrote:
Adding my 2 cents, in the hope that others more knowledgable may be able 
to reproduce the problem.


Using a Nexus S 2.1 with the latest beta firmware, I find I lose audio 
sync when doing multiple yellow button skips to jump through 
commercial breaks, where there is a 30-50% chance the audio will be out 
after this. Doing a green button skip backwards almost always corrects 
it.


hear, hear, same here.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread Chad Flynt
I am sure this is more widespread than people imagine.  I know that 
everyone I talk to has this issue.  But most don't participate on the 
ML.  There are forums that have talked bout it all over.  Most of us 
have just as said, gotten used to it and assumed it will never be 
addressed.  So I too am glad to see it being discussed once again, and 
do hope there can be a resolution.  I wish I understood more about how 
it all pieced together to help.


Lauri Tischler wrote:


Richard Scobie wrote:

Adding my 2 cents, in the hope that others more knowledgable may be 
able to reproduce the problem.


Using a Nexus S 2.1 with the latest beta firmware, I find I lose 
audio sync when doing multiple yellow button skips to jump through 
commercial breaks, where there is a 30-50% chance the audio will be 
out after this. Doing a green button skip backwards almost always 
corrects it.



hear, hear, same here.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-23 Thread C.Y.M
Chad Flynt wrote:
 I am sure this is more widespread than people imagine.  I know that
 everyone I talk to has this issue.  But most don't participate on the
 ML.  There are forums that have talked bout it all over.  Most of us
 have just as said, gotten used to it and assumed it will never be
 addressed.  So I too am glad to see it being discussed once again, and
 do hope there can be a resolution.  I wish I understood more about how
 it all pieced together to help.
 


The problem seems extra prevalent when watching cartoons.  I would assume that
many of the frames are repeated the same during the voice over and because
they're using stack compression, they won't send any empty (null) frames. This
is why the A/V desync is so terrible whenever I try to watch the Simpsons.

Best Regards.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread Udo Richter

C.Y.M wrote:

mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc -quiet 
001.vdr

Notice that -framedrop is added to the command line.  I wonder if that is the
reason why mplayer is immune to the a/v desync problem.


Definitely not just that. My playback issue already disappears when 
using the most simple command line: mplayer -vo mpegpes -ao mpegpes 001.vdr.


And just for completeness: No serious CPU load when playing back with 
VDR or mplayer.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread Udo Richter

Morfsta wrote:
Certainly I think the problem is that VDR is not properly doing sync, 


In a way, I agree. VDR does not sync at all. Never.

Simplified, here's what the VDR playback really does:

- Read data from file in frame-sized chunks into read buffers
- If the DVB driver accepts data, read a frame from buffers
- Filter the PES packets for current video and audio track
- Write the packets into the DVB device.

Thats all. VDR just delivers the data stream as fast as the DVB device 
accepts it. The DVB devices do all the syncing and timing.


And thats why I think that this is a firmware issue, not a VDR issue, 
simply because VDR does almost nothing to the video.


Cheers,

Udo


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread Tero Siironen
On 21.10.2006 15.58, Oliver Endriss [EMAIL PROTECTED] wrote:

 Udo Richter wrote:
 Tero Siironen wrote:
 However, like Pasi Juppo told earlier in other thread, in last weeks episode
 of Lost there was many fadeout-fadeins between scenes and a/v desync
 happened on every one of these.
 
 I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade
 into black, the data stream seems to get stuck, frames get delayed, and
 as consequence A/V desyncs and playback gets jerky, with lots of audio
 and video frame drops. This can be fixed by pausing and jumping a few
 frames backwards.
 
 My theory is that since audio is typically 600ms ahead of video, maybe
 the audio buffers run over. Strange thing is why this happens
 reproducible on blackness. Maybe due to extremely low bit rate in this
 situation, more frames get packed into one data block, causing data flow
 to be disturbed beyond some limit. It cant be too high data rate, ATV+
 has just 2mbit avg, 4mbit max data rate.
 
 Does it also occur with the latest test firmware?
   http://www.suse.de/~werner/test_av-f22623.tar.bz2
 
 If yes, please provide short sample clips.
 Please verify that the clips are not damaged, i.e. they play fine with
 mplayer or xine.
 
 Oliver


Here is a 3 minute clip from the episode of Lost I told earlier.
http://kotisivu.suomi.net/izero/lost.tar

80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X


-- 
Tero



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread Richard Scobie
Adding my 2 cents, in the hope that others more knowledgable may be able 
to reproduce the problem.


Using a Nexus S 2.1 with the latest beta firmware, I find I lose audio 
sync when doing multiple yellow button skips to jump through 
commercial breaks, where there is a 30-50% chance the audio will be out 
after this. Doing a green button skip backwards almost always corrects it.


Regards,

Richard

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread Timothy D. Lenz
The way I understand it, the shows are sent as mpeg2, VDR decodes to raw
data and stores as xxx.vdr files? which then need a special player that
dosn't seem to work correctly to play these now much larger files which eat
up a lot more space. So why not store them as mpeg files? A more common
format which seems to have more options to play back and which work better?
What format do DVD's use? What do you gain by converting to xxx.vdr aside
from not needing to decode on playback? Which would be an advantage if the
system worked and it didn't requre more complexities to convert back to mpeg
for recording to a dvd. Also mpeg is a lossy compression, so data is lost
converting back and forth.

- Original Message - 
From: C.Y.M [EMAIL PROTECTED]
To: VDR Mailing List vdr@linuxtv.org
Sent: Friday, October 20, 2006 5:14 PM
Subject: Re: [vdr] FF card A/V sync suggestion


 Juri Haberland wrote:
  Klaus Schmidinger [EMAIL PROTECTED] wrote:
  C.Y.M wrote:
  Since it has been several years now and I have never been able to
solve the a/v
  desync issues with my Nexus-S FF card when playing back recordings...
  I'm replaying many recordings (actually most of what I watch
  are recordings ;-) and don't even remember when was the last
  time I had an A/V desync.
 


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread C.Y.M
Udo Richter wrote:
 C.Y.M wrote:
 mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc
 -quiet 001.vdr

 Notice that -framedrop is added to the command line.  I wonder if
 that is the
 reason why mplayer is immune to the a/v desync problem.
 
 Definitely not just that. My playback issue already disappears when
 using the most simple command line: mplayer -vo mpegpes -ao mpegpes
 001.vdr.
 
 And just for completeness: No serious CPU load when playing back with
 VDR or mplayer.
 

Yes, if the extra CPU load by mplayer is not even noticeable when playing back
VDR recordings, and it is not prone to any type or desync, then I vote we all
try to figure out what mplayer is doing and repeat it. Whats a few extra CPU
cycles if it becomes much much more stable in the end.

Thanks everyone for chiming in on this one.  I really hope that this time we can
stop passing the buck and just git'r done. :)

Best Regards.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread Torgeir Veimo


On 22 Oct 2006, at 22:56, C.Y.M wrote:


Torgeir Veimo wrote:


On 22 Oct 2006, at 22:33, C.Y.M wrote:



And just for completeness: No serious CPU load when playing back  
with

VDR or mplayer.



Yes, if the extra CPU load by mplayer is not even noticeable when
playing back
VDR recordings, and it is not prone to any type or desync, then I  
vote

we all
try to figure out what mplayer is doing and repeat it. Whats a few
extra CPU
cycles if it becomes much much more stable in the end.


The reason i mentioned the dvbplayer.c thread, is that this  
problem was
mitigated by using different code to feed the softdevice mpeg2  
decoder;

using softplay to playback recordings provided dropout free playback.
I'm not sure if softplay works with FF cards, but you might get the
source at softdevice.berlios.de to give it a try.



I use xine with my FF card and it works flawlessly and fixes all my  
problems,
but since I never had trouble with the FF card when just watching  
live TV, I
thought it was such a waste of CPU to have to use software decoding  
for
everything. I only have problems when playing back recordings with  
the FF card.


I wasn't talking about using different decoding software, I was  
talking about trying some other piece of code thant dvbplayer.c to  
read the recording from disk and feeding the hardware decoder. The  
softplay plugin is such a different playback mechanism (but I can't  
guarrantee that it works with an FF card). My thesis is that there  
are issues with dvbplayer.c, which only show under certain  
circumstances. One such ciscumstance is using a budget card with  
softdevice playback of recordings, and a powerfull cpu.


--
Torgeir Veimo
[EMAIL PROTECTED]




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread matthieu castet

Hi,

Timothy D. Lenz wrote:

The way I understand it, the shows are sent as mpeg2, VDR decodes to raw
data and stores as xxx.vdr files

Now vdr file are raw data sent by the card : ie mpeg2.
Have you an idea of the size of uncompressed video ?


Matthieu

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread Torgeir Veimo


On 22 Oct 2006, at 22:33, C.Y.M wrote:



And just for completeness: No serious CPU load when playing back with
VDR or mplayer.



Yes, if the extra CPU load by mplayer is not even noticeable when  
playing back
VDR recordings, and it is not prone to any type or desync, then I  
vote we all
try to figure out what mplayer is doing and repeat it. Whats a few  
extra CPU

cycles if it becomes much much more stable in the end.


The reason i mentioned the dvbplayer.c thread, is that this problem  
was mitigated by using different code to feed the softdevice mpeg2  
decoder; using softplay to playback recordings provided dropout free  
playback. I'm not sure if softplay works with FF cards, but you might  
get the source at softdevice.berlios.de to give it a try.


--
Torgeir Veimo
[EMAIL PROTECTED]




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread C.Y.M
Torgeir Veimo wrote:
 
 On 22 Oct 2006, at 22:33, C.Y.M wrote:
 

 And just for completeness: No serious CPU load when playing back with
 VDR or mplayer.


 Yes, if the extra CPU load by mplayer is not even noticeable when
 playing back
 VDR recordings, and it is not prone to any type or desync, then I vote
 we all
 try to figure out what mplayer is doing and repeat it. Whats a few
 extra CPU
 cycles if it becomes much much more stable in the end.
 
 The reason i mentioned the dvbplayer.c thread, is that this problem was
 mitigated by using different code to feed the softdevice mpeg2 decoder;
 using softplay to playback recordings provided dropout free playback.
 I'm not sure if softplay works with FF cards, but you might get the
 source at softdevice.berlios.de to give it a try.
 

I use xine with my FF card and it works flawlessly and fixes all my problems,
but since I never had trouble with the FF card when just watching live TV, I
thought it was such a waste of CPU to have to use software decoding for
everything. I only have problems when playing back recordings with the FF card.

Best Regards.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread Udo Richter

Tero Siironen wrote:

Here is a 3 minute clip from the episode of Lost I told earlier.
http://kotisivu.suomi.net/izero/lost.tar

80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X


I've checked your recording. Lost The other 48 days - surely one of 
the worst episodes for me too, because the fade-to-black on every day break.


Your recording however runs relatively fine on my FF (r1.6 firmware 
f22623) card. There's noticeable audio stuttering after the 
fade-to-black scenes, but audio desync is only small, though noticeable.


Demultiplexing with ProjectX throws 11649 of errors like this:

! error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 / 
true / false)
! error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 / 
true / false)


pos is changing, the rest seems always the same.

I then re-muxed the elementary streams and converted them back to VDR, 
and the resulting video played fine again. So this issue seems to be 
some problem on the PES packaging layer.


In contrast, my recording issue cannot be fixed by re-muxing, and has 
more noticeable audio desync, its probably a totally different issue. 
The dev's already have a sample file.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-22 Thread C.Y.M
Udo Richter wrote:
 Tero Siironen wrote:
 Here is a 3 minute clip from the episode of Lost I told earlier.
 http://kotisivu.suomi.net/izero/lost.tar

 80MB file and played ok at least with VLC v 0.8.5. and MPlayer on OS X
 
 I've checked your recording. Lost The other 48 days - surely one of
 the worst episodes for me too, because the fade-to-black on every day
 break.
 
 Your recording however runs relatively fine on my FF (r1.6 firmware
 f22623) card. There's noticeable audio stuttering after the
 fade-to-black scenes, but audio desync is only small, though noticeable.
 
 Demultiplexing with ProjectX throws 11649 of errors like this:
 
 ! error in pes_extension of pes-ID 0xE0 @ pos: 38780 (2048 / 14 / 15 /
 true / false)
 ! error in pes_extension of pes-ID 0xC0 @ pos: 46972 (686 / 14 / 15 /
 true / false)
 
 pos is changing, the rest seems always the same.
 
 I then re-muxed the elementary streams and converted them back to VDR,
 and the resulting video played fine again. So this issue seems to be
 some problem on the PES packaging layer.
 
 In contrast, my recording issue cannot be fixed by re-muxing, and has
 more noticeable audio desync, its probably a totally different issue.
 The dev's already have a sample file.
 

It is postulated that vdr takes whatever it gets and shoves it into the playback
buffers of the a/v decoder in whatever order it is in. In live TV this is
rate-limited meaning the clocking source is the network and the network
transmits at whatever rate it needs to and the decoder decodes it.  So, let us
say that time is x. If video is transmitted faster than rate x, and audio
also is transmitted faster than time x, then we get a xrun. I think that's
understood. But, if video is transmitted faster, then slower, then faster, then
slower etc, but drifts around time x, and is not sent to the decoder at any
other speed than x, then the decoder gets a constant smooth stream. Because if
it takes x+3 ms to play something, the input stream on livetv won't overfill its
buffer because the next run will be x-3 ms and so the extra time is made up.
This is very easily seen with variable framerates and bitrates. Audio also might
be doing the same thing, where it send at spurts rather than a steady stream.
Now if audio and video are both spurting along, where do you find a common time?

IRL, time is constant. But on playback if vdr doesn't clock its data, then
desync is quite possible. For example, if there's nothing to change for a few
video frames, because they're using stack compression they won't send an empty
frame. So, consider this blackout time in Lost. The theory is that problems
are occurring because they're not sending empty null frames. Also, if they're
clocking on video, not audio. You will get your sync problems because you're
missing bits. Does VDR store the pcr pid in the recordings? Is the pcr used
during playback to clock the data?

Best Regards.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-21 Thread C.Y.M
Udo Richter wrote:
 C.Y.M wrote:
 Utilizing mpegpes is really the best of
 both worlds.  We would still be using the video output on the FF card
 but having
 software to process the actual mpeg decoding.  There would be no
 transcoding
 involved because obviously the recording would already be in a DVB
 resolution
 format. 
 
 This leaves the question: If the video is already in DVB compatible
 mpeg2 format, what does mplayer do before forwarding the data stream to
 the DVB card, that VDR does not?
 Basically, VDR just forwards the whole data stream to the DVB driver. If
 mplayer is immune against stream desyncing, then they must do some
 repacking/fixing to the data stream that helps the DVB hardware on
 decoding.
 

If the answer to this question could be discovered, then problem solved.  So,
what you are suggesting is VDR is not doing something that mplayer is doing that
fixes the problem.  Hmm... so then it is not a driver or firmware issue
after all?? Could we agree that much? :) This has been back and forth for a long
 long time with the drivers development team and Klaus. hehe.

Best Regards.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-21 Thread C.Y.M
Klaus Schmidinger wrote:
 C.Y.M wrote:
 ... [ problem with A/V desync ]
 I would have to say that this is exactly the same thing I have been
 experiencing
 for years and years.  But, this never happens with budget cards.. only
 FF cards.
 
 I'm not sure what you mean here. Budget cards can't replay,
 so it's clear that this problem can't happen with them.
 
 Or are you saying that this only happens with recordings
 made from FF cards, and not with recordings made from
 budget cards? Both, of course, replayed via a FF card.
 

What I was trying to say is that the recordings are not damaged.  They seem to
playback fine with a software decoder on both FF and budget cards. I think that
Udo has brought up a very good point about why mplayer is immune to the a/v
desync problem when just using mpegpes to forward the video to the FF dvb card.

BR.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-21 Thread Klaus Schmidinger

C.Y.M wrote:

Klaus Schmidinger wrote:

C.Y.M wrote:

... [ problem with A/V desync ]
I would have to say that this is exactly the same thing I have been
experiencing
for years and years.  But, this never happens with budget cards.. only
FF cards.

I'm not sure what you mean here. Budget cards can't replay,
so it's clear that this problem can't happen with them.

Or are you saying that this only happens with recordings
made from FF cards, and not with recordings made from
budget cards? Both, of course, replayed via a FF card.



What I was trying to say is that the recordings are not damaged.  They seem to
playback fine with a software decoder on both FF and budget cards.


There you go again: a software decoder *can't* replay on a budget card.
This is just nonsense (sorry, no offense).


I think that
Udo has brought up a very good point about why mplayer is immune to the a/v
desync problem when just using mpegpes to forward the video to the FF dvb card.


What VDR sends to the FF DVB card *is* MPEG-PES. I wouldn't know
what to do differently - but apparenty mplayer does some magic,
so if this can be found out, it might help.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-21 Thread C.Y.M
Klaus Schmidinger wrote:
 C.Y.M wrote:
 Klaus Schmidinger wrote:
 C.Y.M wrote:
 ... [ problem with A/V desync ]
 I would have to say that this is exactly the same thing I have been
 experiencing
 for years and years.  But, this never happens with budget cards.. only
 FF cards.
 I'm not sure what you mean here. Budget cards can't replay,
 so it's clear that this problem can't happen with them.

 Or are you saying that this only happens with recordings
 made from FF cards, and not with recordings made from
 budget cards? Both, of course, replayed via a FF card.


 What I was trying to say is that the recordings are not damaged.  They
 seem to
 playback fine with a software decoder on both FF and budget cards.
 
 There you go again: a software decoder *can't* replay on a budget card.
 This is just nonsense (sorry, no offense).

OK, I understand what you are saying because nothing outputs through a budget
card.  What I meant to say is that a recording from a budget card and a
recording from a FF card both play the same when using a software decoder such
as xine.

 
 I think that
 Udo has brought up a very good point about why mplayer is immune to
 the a/v
 desync problem when just using mpegpes to forward the video to the FF
 dvb card.
 
 What VDR sends to the FF DVB card *is* MPEG-PES. I wouldn't know
 what to do differently - but apparenty mplayer does some magic,
 so if this can be found out, it might help.
 

ACK. I hope that someone who understands the mpegpes code in mplayer can shed
some light on this. What kind of repacking is mplayer doing that fixes this
problem.  It is definitely not transcoding the video.  All it is doing is
forwarding the video to the dvb card via mpegpes.

Best Regards.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-21 Thread Udo Richter

C.Y.M wrote:

If the answer to this question could be discovered, then problem solved.  So,
what you are suggesting is VDR is not doing something that mplayer is doing that
fixes the problem.  Hmm... so then it is not a driver or firmware issue
after all?? Could we agree that much? :) 


I wouldn't go that far. For this concrete case, since it is limited to 
one specific channel, there's a good chance that the encoding of the 
channel breaks some standards limitation.
There's also most likely nothing wrong on VDR, as VDR is basically just 
forwarding data streams. If mplayer does a better job, then its probably 
more like a bug workaround.
Generally, things would be a lot better if the driver/firmware would do 
A/V resyncing constantly and not just at playback start. That way, A/V 
desync wouldn't built up, and desync would only happen for a short time.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-21 Thread Chad Flynt
I will chime in again and also state this has nothing to do with 1 
particular channel.  This, at least in North America, happens no matter 
what channel it is on.  I can't recall any live TV ever being affected, 
but every recording I have has desync issues if I play straight through 
VDR on a FF card, some worse than others mind you, but every one gets 
out of sync.  I don't know if it is an NTSC thing or what.  I am willing 
to accept that if it is, but the problem still stands.  But it sounds as 
if it happens on PAL systems as well from all those that have chimed 
in.  I am in no way ungrateful for everything VDR has done and all the 
development from others, but this problem has been brought up many times 
in the past and ends up getting dropped as mentioned.  Mainly, obviously 
due to the fact the developers can't reproduce it.  But it isn't just 
Mplayer that plays fine, Xine plays fine as well.  Both of these 
outputting via the FF Card.  So, not just going full software mode.  So 
that's 2 different playback devices that bypass whatever bugs or whatnot 
you might be mentioning.  It is only when playing back through whatever 
VDR is using.  It may very well be passing it straight through and the 
others aren't.  But that is what we are trying to find out.  And find 
out if there is a way that we can have an option if anything to choose 
playback a different way.  I am not a programmer, so I don't know the 
ins or outs of how this can be accomplished, but being as so many others 
are now complaining about it, there has to be some way of figuring this 
out.  Thanks for any insight you have on looking into this problem.



Pasi Juppo wrote:


Udo Richter wrote:
 


C.Y.M wrote:
   


If the answer to this question could be discovered, then problem
solved.  So,
what you are suggesting is VDR is not doing something that mplayer is
doing that
fixes the problem.  Hmm... so then it is not a driver or firmware
issue
after all?? Could we agree that much? :) 
 


I wouldn't go that far. For this concrete case, since it is limited to
one specific channel, there's a good chance that the encoding of the
channel breaks some standards limitation.
There's also most likely nothing wrong on VDR, as VDR is basically just
forwarding data streams. If mplayer does a better job, then its probably
more like a bug workaround.
Generally, things would be a lot better if the driver/firmware would do
A/V resyncing constantly and not just at playback start. That way, A/V
desync wouldn't built up, and desync would only happen for a short time.
   



How come you make the conclusion that this is limited to one specific
channel? To my understanding there are multiple channels where this
problem occurs.

The best to start solving this problem is to try to figure out what
happens with the recordings that are correct but still cause desync
problems. This has been suggested already by many readers. Since it
seems that only few people have access to the firmware source code the
debugging is quite limited..

Br, Pasi

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

 




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-21 Thread C.Y.M

 My theory is that since audio is typically 600ms ahead of video, maybe 
 the audio buffers run over. Strange thing is why this happens 
 reproducible on blackness. Maybe due to extremely low bit rate in this 
 situation, more frames get packed into one data block, causing data flow 
 to be disturbed beyond some limit. It cant be too high data rate, ATV+ 
 has just 2mbit avg, 4mbit max data rate.
 
 Does it also occur with the latest test firmware?
   http://www.suse.de/~werner/test_av-f22623.tar.bz2
 
 If yes, please provide short sample clips.
 Please verify that the clips are not damaged, i.e. they play fine with
 mplayer or xine.
 

Yes, it still happens on every firmware revision.  But, I really dont think this
is a firmware issue as much as it is a VDR one.  There must be several ways to
approach this problem but the best way would be an open source solution IMHO. If
mplayer can successfully forward the video every time straight to the FF card
w/o any transcoding, then why cant VDR do the same thing?  Im sure someone can
post links to problematic recordings if you need some to test with.

Best Regards.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread Klaus Schmidinger

C.Y.M wrote:

Since it has been several years now and I have never been able to solve the a/v
desync issues with my Nexus-S FF card when playing back recordings...


I'm replaying many recordings (actually most of what I watch
are recordings ;-) and don't even remember when was the last
time I had an A/V desync.

Are you getting this with recordings from particular channels,
or does it happen all the time?
Also, is this with MPEG audio or AC3?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread Tero Siironen
On 20.10.2006 15.09, Klaus Schmidinger [EMAIL PROTECTED]
wrote:

 C.Y.M wrote:
 Since it has been several years now and I have never been able to solve the
 a/v
 desync issues with my Nexus-S FF card when playing back recordings...
 
 I'm replaying many recordings (actually most of what I watch
 are recordings ;-) and don't even remember when was the last
 time I had an A/V desync.
 
 Are you getting this with recordings from particular channels,
 or does it happen all the time?
 Also, is this with MPEG audio or AC3?

Well here in Finland the channels at least where I've seen this to happen
are two commercial channels (MTV3 and Nelonen). I don't remember seeing
those problems with non-commercial channels (YLE's channels).

The a/v sync problems usually occur when commercial break ends and program
continues. But it happens also in the spots where there has been commercial
break in the original broadcast but not in here.

However, like Pasi Juppo told earlier in other thread, in last weeks episode
of Lost there was many fadeout-fadeins between scenes and a/v desync
happened on every one of these. I preserved an example clip of this with
length of 3 minutes and there is four desync spots in it. So it is not
directly related to commercial breaks. I think this happens almost on every
recording made from these two channels.

Audio is normal MPEG.


-- 
Tero Siironen



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread Udo Richter

Tero Siironen wrote:

However, like Pasi Juppo told earlier in other thread, in last weeks episode
of Lost there was many fadeout-fadeins between scenes and a/v desync
happened on every one of these.


I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade 
into black, the data stream seems to get stuck, frames get delayed, and 
as consequence A/V desyncs and playback gets jerky, with lots of audio 
and video frame drops. This can be fixed by pausing and jumping a few 
frames backwards.


My theory is that since audio is typically 600ms ahead of video, maybe 
the audio buffers run over. Strange thing is why this happens 
reproducible on blackness. Maybe due to extremely low bit rate in this 
situation, more frames get packed into one data block, causing data flow 
to be disturbed beyond some limit. It cant be too high data rate, ATV+ 
has just 2mbit avg, 4mbit max data rate.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread Chad Flynt
I am sure it has something to do with North American systems, it happens 
with regular or AC3 audio.  And doesn't seem to matter on the channel.  
Doesn't affect live at all just on playback.  And as mentioned, if you 
use Mplayer or such all is fine.  Only if you are playing back via the 
default VDR playback through the card.  The fix is always to rewind just 
a sec and start playing again and usually you are good, till the next 
desync heh. 


Klaus Schmidinger wrote:


C.Y.M wrote:

Since it has been several years now and I have never been able to 
solve the a/v

desync issues with my Nexus-S FF card when playing back recordings...



I'm replaying many recordings (actually most of what I watch
are recordings ;-) and don't even remember when was the last
time I had an A/V desync.

Are you getting this with recordings from particular channels,
or does it happen all the time?
Also, is this with MPEG audio or AC3?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread C.Y.M
Tero Siironen wrote:
 On 20.10.2006 15.09, Klaus Schmidinger [EMAIL PROTECTED]
 wrote:
 
 C.Y.M wrote:
 Since it has been several years now and I have never been able to solve the
 a/v
 desync issues with my Nexus-S FF card when playing back recordings...
 I'm replaying many recordings (actually most of what I watch
 are recordings ;-) and don't even remember when was the last
 time I had an A/V desync.

 Are you getting this with recordings from particular channels,
 or does it happen all the time?
 Also, is this with MPEG audio or AC3?
 
 Well here in Finland the channels at least where I've seen this to happen
 are two commercial channels (MTV3 and Nelonen). I don't remember seeing
 those problems with non-commercial channels (YLE's channels).
 
 The a/v sync problems usually occur when commercial break ends and program
 continues. But it happens also in the spots where there has been commercial
 break in the original broadcast but not in here.
 
 However, like Pasi Juppo told earlier in other thread, in last weeks episode
 of Lost there was many fadeout-fadeins between scenes and a/v desync
 happened on every one of these. I preserved an example clip of this with
 length of 3 minutes and there is four desync spots in it. So it is not
 directly related to commercial breaks. I think this happens almost on every
 recording made from these two channels.
 
 Audio is normal MPEG.

I would have to say that this is exactly the same thing I have been experiencing
for years and years.  But, this never happens with budget cards.. only FF cards.
 My guess is that it is firmware/driver related.  But, since only a handful of
people have the source code to the firmware, it is virtually impossible to fix.
 we could work around it by using mplayer with mpegpes to playback the
problematic recordings and live tv is never an issue.  I would just like another
way of playing back the recordings in VDR w/o having to rely on the firmware of
the FF card that nobody can fix.


Best Regards.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread C.Y.M
Udo Richter wrote:
 Tero Siironen wrote:
 However, like Pasi Juppo told earlier in other thread, in last weeks
 episode
 of Lost there was many fadeout-fadeins between scenes and a/v desync
 happened on every one of these.
 
 I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade
 into black, the data stream seems to get stuck, frames get delayed, and
 as consequence A/V desyncs and playback gets jerky, with lots of audio
 and video frame drops. This can be fixed by pausing and jumping a few
 frames backwards.
 
 My theory is that since audio is typically 600ms ahead of video, maybe
 the audio buffers run over. Strange thing is why this happens
 reproducible on blackness. Maybe due to extremely low bit rate in this
 situation, more frames get packed into one data block, causing data flow
 to be disturbed beyond some limit. It cant be too high data rate, ATV+
 has just 2mbit avg, 4mbit max data rate.
 

This theory sounds reasonable.  Any idea on a way to fix it? The biggest
question is if it can be fixed from within VDR's source code or if it would
require an additional firmware/driver revision.  I have given up hope on it.
The only way I know of that is reliable is using software decoding.

Best Regards.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread C.Y.M
C.Y.M wrote:
 Udo Richter wrote:
 Tero Siironen wrote:
 However, like Pasi Juppo told earlier in other thread, in last weeks
 episode
 of Lost there was many fadeout-fadeins between scenes and a/v desync
 happened on every one of these.
 I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade
 into black, the data stream seems to get stuck, frames get delayed, and
 as consequence A/V desyncs and playback gets jerky, with lots of audio
 and video frame drops. This can be fixed by pausing and jumping a few
 frames backwards.

 My theory is that since audio is typically 600ms ahead of video, maybe
 the audio buffers run over. Strange thing is why this happens
 reproducible on blackness. Maybe due to extremely low bit rate in this
 situation, more frames get packed into one data block, causing data flow
 to be disturbed beyond some limit. It cant be too high data rate, ATV+
 has just 2mbit avg, 4mbit max data rate.

 
 This theory sounds reasonable.  Any idea on a way to fix it? The biggest
 question is if it can be fixed from within VDR's source code or if it would
 require an additional firmware/driver revision.  I have given up hope on it.
 The only way I know of that is reliable is using software decoding.
 

But, the biggest question is.. why does the ONLY happen when playing back
recordings??

Best Regards.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread Juri Haberland
Klaus Schmidinger [EMAIL PROTECTED] wrote:
 C.Y.M wrote:
 Since it has been several years now and I have never been able to solve the 
 a/v
 desync issues with my Nexus-S FF card when playing back recordings...
 
 I'm replaying many recordings (actually most of what I watch
 are recordings ;-) and don't even remember when was the last
 time I had an A/V desync.

I also have A/V desyncs. This is with one TT-DVB-T (and a
TT-DVB-C, most of the time we record and watch via the DVB-T card).

In most cases it is bad reception.
Pausing and restarting the video fixes it - most of the time - but
sometimes I have to switch back to live TV and restart the video.

 Are you getting this with recordings from particular channels,
 or does it happen all the time?
 Also, is this with MPEG audio or AC3?

There is no AC3 involved - just plain replay via FBAS and audio out
of the TT card.

Cheers,
Juri


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread C.Y.M
Juri Haberland wrote:
 Klaus Schmidinger [EMAIL PROTECTED] wrote:
 C.Y.M wrote:
 Since it has been several years now and I have never been able to solve the 
 a/v
 desync issues with my Nexus-S FF card when playing back recordings...
 I'm replaying many recordings (actually most of what I watch
 are recordings ;-) and don't even remember when was the last
 time I had an A/V desync.
 
 I also have A/V desyncs. This is with one TT-DVB-T (and a
 TT-DVB-C, most of the time we record and watch via the DVB-T card).
 
 In most cases it is bad reception.
 Pausing and restarting the video fixes it - most of the time - but
 sometimes I have to switch back to live TV and restart the video.
 
 Are you getting this with recordings from particular channels,
 or does it happen all the time?
 Also, is this with MPEG audio or AC3?
 
 There is no AC3 involved - just plain replay via FBAS and audio out
 of the TT card.
 

The A/V desync problem would not be so critical if it corrected itself with some
type of time code.  In fact, even playing bad recordings back with some kind of
software decoder can give you a desync once in a while, but the difference is
that the software method fixes the desync automatically (without having to fast
forward or rewind to the next GOP).  Utilizing mpegpes is really the best of
both worlds.  We would still be using the video output on the FF card but having
software to process the actual mpeg decoding.  There would be no transcoding
involved because obviously the recording would already be in a DVB resolution
format.  The CPU usage would be very minimal and I would not need to install
X-windows or some type of framebuffer. I am just talking about regular MPEG
audio/video.  It doesn't seem like it would that hard to modify the mplayer
plugin for just this purpose.  In fact, it already works.  But there are a few
minor issues with it.

1) Mplayer can not get the correct seek time when playing back VDR recordings
for some reason (causing the time bar to show incorrect values).
2) Mplayer can not handle playing back split files (ie; 001.vdr, 002.vdr). As of
now each one must be selected individually.
3) Sometimes when playing back a video with mplayer (using only a single FF card
in the machine), something puts a lock on something in /dev/dvb/adapter0/*. So,
if a timer should happen to go off in VDR while you are playing back a video
with mplayer, VDR will crash when attempting to start recording with the timer.

Best Regards.



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] FF card A/V sync suggestion

2006-10-20 Thread Udo Richter

C.Y.M wrote:

Utilizing mpegpes is really the best of
both worlds.  We would still be using the video output on the FF card but having
software to process the actual mpeg decoding.  There would be no transcoding
involved because obviously the recording would already be in a DVB resolution
format. 


This leaves the question: If the video is already in DVB compatible 
mpeg2 format, what does mplayer do before forwarding the data stream to 
the DVB card, that VDR does not?
Basically, VDR just forwards the whole data stream to the DVB driver. If 
mplayer is immune against stream desyncing, then they must do some 
repacking/fixing to the data stream that helps the DVB hardware on decoding.



1) Mplayer can not get the correct seek time when playing back VDR recordings
for some reason (causing the time bar to show incorrect values).


For proper seeking, a program must be able to read the index.vdr file. 
Everything else is educated guessing.



3) Sometimes when playing back a video with mplayer (using only a single FF card
in the machine), something puts a lock on something in /dev/dvb/adapter0/*. So,
if a timer should happen to go off in VDR while you are playing back a video
with mplayer, VDR will crash when attempting to start recording with the timer.


Only one program can use the DVB card. And if mplayer uses it, then VDR 
cannot.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr