Udo Richter wrote:
> Oliver Endriss wrote:
>> Does mplayer really play PES data 'as is'?
>> Afaik it recodes data to MPEG-1.(?)
>
> From CPU load on my machine, mplayer cannot do much with the signal. The
> CPU load is even lower than the VDR load when playing back 001.vdr. And
> even decoding in
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 th
Joerg Knitter wrote:
> 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 rep
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
> Recordings are pure PES packet sequences of video and audio PES packets.
> PCR is not recorded. On playback, the PES packets are forwarded to the
> DVB driver without further modification. IMHO the playback sync only
> uses the PTS of the PES packets, however thats just guessing.
>
If PCR is i
Juri Haberland wrote:
> "C.Y.M" <[EMAIL PROTECTED]> wrote:
>> Guy Roussin wrote:
>>>>> if i make this, the file play fine (vdr ffcard) :
>>>>>
>>>>> mv 001.vdr _001.vdr
>>>>> mv index.vdr _index.vdr
>>>&g
Guy Roussin wrote:
>>> 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 soun
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 ff
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
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 wh
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 "
Torgeir Veimo wrote:
>
> 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
>> appro
>> 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
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 an
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.
>
>
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
>> involve
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...
>>
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.
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
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
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
mlists wrote:
> I'm running VDR 1.4.3 with hoochster's patches.
>
> I've install xine but I'm not getting any audio. When vdr starts up and
> then xine -- I'm getting this:
> vdr-xine: Client connecting ...
> vdr-xine: Client connected!
> [VM]buffered 50.2 frames (v:50.2, a:0.0)
> buffered 51.5
Tero Siironen wrote:
> On 14.10.2006 23.20, "Pasi Juppo" <[EMAIL PROTECTED]> wrote:
>
>> This problem is yet to be fixed to my understanding. Now I have a good
>> recording (one episode from Lost) where this happens very often. The
>> problem seems to be related to situations where the scene fades
Udo Richter wrote:
> Peter Bieringer wrote:
>> Thank you for the nice script.
>>
>> One fix is necessary:
>>
>> -[ -n "$VFAT" ] && VDRCMD="$VDRCMD -v"
>> +[ -n "$VFAT" ] && VDRCMD="$VDRCMD --vfat"
>
>
> Hmm, you're right. Thanks. I've missed that because my VDR is switched
> to
V Live wrote:
> What about the patches for xine-lib @
> http://www.youmustbejoking.demon.co.uk/patches/vdr-xine are they being
> maintained too?
>
I have not seen them change for a while.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-
martin wrote:
> Hey Darren,
>
> since some days, the xine-lib has changed a bit, so your patches fail
> against version 1.1.3. I've updated all necessary patches, to make xine-lib
> running with the current cvs version. You may want to update our patches on
> your site!
>
What about "xine-lib_mo
lamikr wrote:
> I am not sure from the installation of rpm versions, because I am just
> used to download the .bin versions of sun jdk.
> If you install the ".bin" version of Sun JVM, you can basically extract
> it to any directory you want.
> Then just make sure that the jdk/bin directory where ja
Klaus Schmidinger wrote:
> Lauri Tischler wrote:
>> Klaus Schmidinger wrote:
>>> CR wrote:
Hi,
I notice when I change channels, video/audio will start and then it
will
pause and resume, in the syslog I often see "returning due to
modification
of channel " when it
Peter Juszack wrote:
> Hallo everybody,
>
>
>I finally managed to upload new versions of plugins which honor
> APIVERSION and compile with VDR 1.4.
> No other changes except Dutch translations for the eggtimer-plugin
>
> Plugins can be found at
> http://turku.wi-bw.tfh-wildau.de/~pjuszack/di
Oliver Endriss wrote:
> Torgeir Veimo wrote:
>> On 21 Sep 2006, at 09:03, Marko Mäkelä wrote:
>>
>>> On Sun, Sep 17, 2006 at 11:43:09AM +0100, Torgeir Veimo wrote:
Using the remote plugin with a /dev/input/eventX setup for a
hauppauge grey remote via a nova-t sensor with X11/Xv using
> - Added -S option to ppmtoy4m call in example image convert script. Suggested
> by
> Thorsten Gehrig.
I was thinking of something more like this for backwards compatibility:
@@ -61,17 +61,23 @@
#
# now run the conversion
#
+
+# 'chroma subsampling mode' mjpegtools >= 1.8.0
+if ppmtoy4m
Udo Richter wrote:
> C.Y.M wrote:
>> Yes, I like the idea of backgrounding VDR using "&" and then using
>> 'wait $PID'.
>> Is that the method you use? I've been trying to find the best way to
>> do this.
>> Could you give me an
Udo Richter wrote:
> C.Y.M wrote:
>> Because in the runvdr script, the vdr command is executed by an "eval"
>> statement
>> which basically waits for the process to die before it continues on.
>
> This could be avoided by backgrounding VDR, do other stuff, an
Udo Richter wrote:
> C.Y.M wrote:
>> Thanks for your replay, but I was looking for a switch that would make
>> vdr run a
>> script right after vdr starts up.
>
> If you want to start a program together with VDR, why don't you put it
> into your runvdr scrip
martin wrote:
> Just add option "-r script.sh"
>
> #!/bin/sh
> case "$1" in
> before)
> ;;
> after)
> echo "After recording $2"
> /usr/local/bin/startnoad.sh "$2" &
> ;;
> edited)
> echo "Edited recording $2"
>
Here is an example of the changes that I have had to make to runvdr so that my
nexus-s works. I have added a maximum retry value to runvdr so that vdr will
not keep attempting to start over and over if there is a major problem with
reception. Also, I have added a minimum runtime (in seconds) that
Is there a command line switch that would allow me to define a command vdr must
excute after initial startup? I see one for before and after recordings, but I
am looking for a way to execute a command after startup only.
Best Regards.
___
vdr mailing l
I have been trying to clean up my builds and when updated softdevice and
softplay via cvs, noticed several warning about unused variables. Also, it
appears that softplay does not have the current Makefile fixes required to build
under the latest VDR.
Best Regards,
--- softdevice.cvs/video-shm.c.or
C.Y.M wrote:
> I have been trying to clean up my builds and when updated softdevice and
> softplay via cvs, noticed several warning about unused variables. Also, it
> appears that softplay does not have the current Makefile fixes required to
> build
> under the latest VDR.
>
I have been trying to clean up my builds and when updated softdevice and
softplay via cvs, noticed several warning about unused variables. Also, it
appears that softplay does not have the current Makefile fixes required to build
under the latest VDR.
Best Regards,
--- softdevice.cvs/video-shm.c.or
Hello,
I just wanted to mention that I noticed a warning when compiling the latest
liemikuutio-1.10 patch with an unused variable.
Best Regards.
--- vdr-1.4.2/recording.c.orig 2006-08-27 20:46:51.0 -0700
+++ vdr-1.4.2/recording.c 2006-08-27 20:47:40.0 -0700
@@ -736,7 +736,7 @@
Darren Salt wrote:
> I demand that Stone may or may not have written...
>
>>> There is a fixed patchset here:
>>> http://www.youmustbejoking.demon.co.uk/patches/vdr-xine/>
>
>> Darren, should all of these patches in your vdr-xine directory be applied
>> to current xine development? Thanks for
42 matches
Mail list logo
