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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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 was
thinking about what could be done. As of now, I have been using xine with my FF
card to fix the problem. But, if I use xine, then even live tv
46 matches
Mail list logo
