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 al
Hi,
dvb wrote:
No luck with this patch (1.4.1 & 1.4.3) :(
they(tv company) use MPEG2 ID in H.264 stream
PID found: 512 (0x0200) [PES: ITU-T Rec. H.262 | ISO/IEC 13818-2 or
ISO/IEC 11172-2 video stream]
Oct 20 18:40:09 testbox vdr: [17201] switching to channel 11
Oct 20 18:40:39 testbox v
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 prob
Harald Milz wrote:
Harald Milz <[EMAIL PROTECTED]> wrote:
I've been upgrading to 1.4.1 last May, then rebuilt my VDR lately. It seems
it can't playback older recordings (pre-1.4.1) any more. The sound is
stuttering heavily, and it looks as if audio were entirely out of sync. The
... and way t
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
> 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 bac
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
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 ca
On 21 Oct 2006, at 11:36, C.Y.M wrote:
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
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
Hi,
I've got VDR (1.4.3) running on a machine by my TV and have just been
playing with the xineliboutput plugin to stream vdr over the network.
Everything works well on its own but I'd like to be able to have someone
watching TV on one channel via the dxr3 and someone else watching a
recording on
En/na Glyn Edwards ha escrit:
> Hi,
>
> I've got VDR (1.4.3) running on a machine by my TV and have just been
> playing with the xineliboutput plugin to stream vdr over the network.
> Everything works well on its own but I'd like to be able to have someone
> watching TV on one channel via the dxr3
> I don't know how xineliboutput works, but I'm currently using a dxr3 and
> xine (with the network patches). When xine is used (i.e. the client
> connects) it becomes the primary device and there's no more output on
> the dxr3, when xine disconnects output resumes on the dxr3.
> If you want to se
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 wou
En/na Glyn Edwards ha escrit:
> Streamdev isn't quite what I want since you need a whole vdr install on
> the client as well.
I suppose you could run both instances (one with streamdev-server and
the other with streamdev-client) on the server.
Bye
--
- Yo también quiero una Europa libre de Pa
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
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
Pasi Juppo wrote:
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.
Just talking about the case that I've reported. I experience such issues
only very rarely, and mostly related to bad recep
Glyn Edwards wrote:
I've got VDR (1.4.3) running on a machine by my TV and have just been
playing with the xineliboutput plugin to stream vdr over the network.
Everything works well on its own but I'd like to be able to have someone
watching TV on one channel via the dxr3 and someone else watchin
>> 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
Seems that when runnin xinelibout with local frontend Overscan crop
doesn't work.
If I run remote frontend vdr-sxfe it crops just right.
I'm running vdr-1.4.3-2 and xineliboutput-1.0.0pre6
-P"xineliboutput --local=sxfe --video=xv --remote=37890"
--
Jussi
On 21 Oct 2006, at 20:22, C.Y.M wrote:
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
C.Y.M wrote:
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
23 matches
Mail list logo
