Re: [vdr] Integartion with systemd and rtcwake
Am 11.04.2023 um 16:36 schrieb Marko Mäkelä: Can you point to an example? https://github.com/j1rie/IRMP_STM32/blob/master/irmplircd/vdrshutdown writes the time of the next vdr timer start into the alarm of the STM32 https://github.com/j1rie/IRMP_STM32/tree/master/stm32IRalarm/Linux. That alarm gets decreased by the systick of the STM32 and finally starts the system. https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103x8/src/main.c#L382 https://github.com/j1rie/IRMP_STM32/blob/master/STM32F103x8/src/main.c#L416 That's not as precise as a RTC, but good enough. As a side effect you have an IR receiver for many protocols https://github.com/j1rie/IRMP_STM32 Joerg ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Integartion with systemd and rtcwake
Am 11.04.2023 um 07:41 schrieb Marko Mäkelä: Mon, Apr 10, 2023 at 07:08:29AM -0700, VDRU VDRU wrote: Why don't you make life easy and just add a $5-10 rtc module and be done with it? Based on this discussion https://forums.raspberrypi.com/viewtopic.php?t=210662 one would need more than that. "Shutting down" the Raspberry Pi will actually reboot it into the bootloader in a special mode that will cause the firwmare to wait for a "power on" GPIO signal. The only way to actually power off the Raspberry Pi is to cut the power supply. At https://github.com/bablokb/pi-wake-on-rtc you can find a schematic diagram and board layout of such a solution (incompatible with rtcwake). I don't think that the hardware part can be done by extending the Pi TV HAT with some 3D soldering, like I did to mount an IR receiver. I was actually looking feedback for the systemd integration, which is not specific to the Raspberry Pi. Marko Maybe still not what you want, but how other guys do it: https://www.vdr-portal.de/forum/index.php?thread/133092-ein-weiterer-ir-einschalter-f%C3%BCr-den-rpi/=1319903=mosfet https://www.vdr-portal.de/forum/index.php?thread/12-arduino-nano-mit-neopixel-leds-seriell-steuern-ausschalten/=1322285#post1322285 (german, you might need google translate, but you can post in english) * wakeup done by STM32 microcontroller board (either by timer set from vdr or by remote control) * power switched by MOSFET * full systemd and vdr integration * very cheap Joerg ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Hi Klaus, we need your help
Hi Klaus, please have a look at http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/128920-ring-buffer-overflows-cdevice-detach-blockiert/?s=549ec1180bfb2f98a7fde3211785f589756c26d0 We need your help. Thanks, Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] determine within plugin, whether radio or tv stream
Am 27.01.2016 um 14:45 schrieb Stefan Braun: Hi, i do this in my plugins in the following way (Channel is a cChannel object): bool isRadio = !Channel->Vpid() && Channel->Apid(0); cheers Louis Well, I should have mentioned, that this is about a player plugin. So the stream it receives from VDR might be a recording as well. The question more precisely is, how do I get the video pid and audio pid (or be sure there is no video pid) out of the stream. I guess I need to parse it. Or if there is a better way of doing this. Joerg *Gesendet:* Mittwoch, 27. Januar 2016 um 11:48 Uhr *Von:* "Joerg Riechardt" <j.riecha...@gmx.de> *An:* "vdr@linuxtv.org" <vdr@linuxtv.org> *Betreff:* [vdr] determine within plugin, whether radio or tv station Hi, what is a safe way to determine within a plugin, whether the stream it is receiving from VDR is a radio or a tv stream? There are tv streams with slowly changing still pictures, there are radio plugins which insert grafical information, so I am not sure if this could be achived by analysing the stream. Of cause there is the video pid. Is there a standard way to get that to the plugin? Do I think to complicated or am I missing something? The plugin needs to know within less than 100ms after start of stream. Joerg ___ 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] determine within plugin, whether radio or tv station
Hi, what is a safe way to determine within a plugin, whether the stream it is receiving from VDR is a radio or a tv stream? There are tv streams with slowly changing still pictures, there are radio plugins which insert grafical information, so I am not sure if this could be achived by analysing the stream. Of cause there is the video pid. Is there a standard way to get that to the plugin? Do I think to complicated or am I missing something? The plugin needs to know within less than 100ms after start of stream. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Restart of frontend
Am 13.02.2015 um 00:02 schrieb René: On 12.02.2015 17:27, VDR User wrote: Rather than treating a symptom, why not try to figure out the root cause of your freezing and address it there? That is of course the best solution, but i still would prefer an option to reload/restart a frontend instead of having to restart vdr.. René start softhddevice suspended: ./vdr -P'softhddevice -g 1920x1080 -s' resume softhddevice: svdrpsend plug softhddevice RESU suspend again: svdrpsend plug softhddevice SUSP Jörg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] SNR bar depends from UNC [vdr-2.1.6]
Am 15.06.2014 11:19, schrieb Klaus Schmidinger: Because when I introduced cDevice::SignalQuality() it was agreed upon that SNR, BER and UNC should be taken into account. If the general opinion is now that we should leave UNC (and BER?) out of the calculation, that's fine with me. Any opinions? Klaus My personal preference is to see SNR instead of SignalQuality as the second bar. SNR is common, everybody knows, what it means. (BTW AFAIK the term SNR is from analog times and obsolete, with digital broadcasts it is called CNR.) Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-xine and vdr-2.1.3
Hi, Reinhard Nissl’s vdr-xine is still my favorite output plugin. The additional parameter in cDevice::TrickSpeed() breaks fast forward, instead of increasing the speed in three steps, it is always most fast. Has anybody a patch for this, or is planning to create one? Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine and vdr-2.1.3
Am 10.01.2014 12:57, schrieb Joerg Riechardt:
Hi,
Reinhard Nissl’s vdr-xine is still my favorite output plugin. The
additional parameter in cDevice::TrickSpeed() breaks fast forward,
instead of increasing the speed in three steps, it is always most fast.
Has anybody a patch for this, or is planning to create one?
Joerg
this patch seems to do it
Joerg
diff -Nru xine-a/xineDevice.c xine-b/xineDevice.c
--- xine-a/xineDevice.c 2013-01-18 15:55:51.0 +0100
+++ xine-b/xineDevice.c 2014-01-10 15:30:03.254256728 +0100
@@ -300,19 +300,14 @@
//#endif
}
- void cXineDevice::TrickSpeed(int Speed)
- {
-TrickSpeed(Speed, false);
- }
-
- void cXineDevice::TrickSpeed(int Speed, bool IBP)
+ void cXineDevice::TrickSpeed(int Speed, bool Forward)
{
f = false;
ts = Speed;
xfprintf(stderr, TrickSpeed: %d\n, Speed);
m_xineLib.execFuncTrickSpeedMode(lastCmdWasClear);
-m_xineLib.execFuncSetSpeed(100.0 / Speed * (IBP ? 12 : 1));
+m_xineLib.execFuncSetSpeed(100.0 / Speed);
m_xineLib.execFuncWait();
m_xineLib.freeze(false);
m_xineLib.pause(false);
diff -Nru xine-a/xineDevice.h xine-b/xineDevice.h
--- xine-a/xineDevice.h 2013-01-18 15:55:51.0 +0100
+++ xine-b/xineDevice.h 2014-01-10 15:46:29.290199807 +0100
@@ -50,8 +50,7 @@
virtual bool CanReplay(void) const;
virtual bool SetPlayMode(ePlayMode PlayMode);
virtual bool HasIBPTrickSpeed(void);
-virtual void TrickSpeed(int Speed, bool IBP);
-virtual void TrickSpeed(int Speed);
+virtual void TrickSpeed(int Speed, bool Forward);
virtual void Clear(void);
virtual void Play(void);
virtual void Freeze(void);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-xine-0.9.4 plugin
Hi,
two patches I use attached,
Joerg
Am 15.03.2013 16:38, schrieb Carsten Koch:
Hi,
On 03/16/11 20:29, Reinhard Nissl wrote:
I'm pleased to announce maintenance release 0.9.4.
is there something newer available?
In partcular, something that works with VDR 1.7.40?
With VDR 1.7.40 (under OpenSUSE 12.3) I get:
*** Plugin xine:
WARNING: plugin xine is using an old Makefile!
g++ -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='xine'
-DFIFO_DIR=\/tmp/vdr-xine\ -DVERIFY_BITMAP_DIRTY=0 `pkg-config
--cflags libxine` -I/home/cko/vdr-1.7.40/include xineDevice.c
xineDevice.c: In member function 'virtual void
PluginXine::cXineDevice::StillPicture(const uchar*, int)':
xineDevice.c:1203:36: error: 'class cPatPmtParser' has no member named
'PmtPid'
xineDevice.c:1403:1: warning: narrowing conversion of
'(vdr172::cRemux::IsFrameH264(Data, Length) ? 10 : 183)' from 'int' to
'uchar {aka unsigned char}' inside { } is ill-formed in C++11 [-Wnarrowing]
make[1]: *** [xineDevice.o] Error 1
You can
find it on my homepage as usual:
http://home.vr-web.de/~rnissl
Not any more.
http://home.vr-web.de in general and http://home.vr-web.de/~rnissl
seems to be gone.
Cheers,
Carsten.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
diff -Naur xine-0.9.4_orig/xineDevice.c xine-0.9.4/xineDevice.c
--- xine-0.9.4_orig/xineDevice.c2011-02-27 19:14:19.0 +0100
+++ xine-0.9.4/xineDevice.c 2012-12-22 18:42:36.389557075 +0100
@@ -1200,7 +1200,11 @@
int pid = TsPid(Data);
if (pid == 0)
patPmtParser.ParsePat(Data, TS_SIZE);
+#if APIVERSNUM = 10732
+ else if (patPmtParser.IsPmtPid(pid))
+#else
else if (pid == patPmtParser.PmtPid())
+#endif
patPmtParser.ParsePmt(Data, TS_SIZE);
else if (pid == patPmtParser.Vpid())
{
diff -Nru b/Makefile a/Makefile
--- b/Makefile 2011-03-15 23:22:03.0 +0100
+++ a/Makefile 2012-03-27 23:28:00.684231800 +0200
@@ -97,7 +97,7 @@
### The main target:
-all: libvdr-$(PLUGIN).so i18n xineplayer
+all: libvdr-$(PLUGIN).so xineplayer
### Implicit rules:
diff -Nru b/xine.c a/xine.c
--- b/xine.c2011-01-18 14:45:04.0 +0100
+++ a/xine.c2012-03-27 23:29:28.338233019 +0200
@@ -13,7 +13,6 @@
#include xineDevice.h
#include xineSettings.h
#include xineSetupPage.h
-#include xineI18n.h
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HD Test clip(s)
Am 17.02.2013 02:17, schrieb VDR User: On Sat, Feb 16, 2013 at 2:50 PM, Gerald Dachs v...@dachsweb.de wrote: If you want the highest quality deinterlacing on 1080i, a GT220 is required. A GT610 is good enough, costs only the half and it is much easier to cool it quietly. I've read the opposite -- that the GT610 struggle with 1080i highest deinterlacing. A Gt520/GT610 has double decoding speed compared to a GT220. The GT220 has far higher rendering speed. If you want to have both, go for a GT640, with even less power consumption. Or oc a GT520/GT610. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Sound and picture problems with ITV3
Am 26.03.2012 19:00, schrieb brian: Hi, Running VDR 1.6 on a FF and Budget cards I have problems with recordings made from the channel ITV3. The video itself starts OK, but gets very jerky after a while. Restarting playback makes it better for a while. Sound gets more out of sync with the picture, its also better after restarting playback. I tried replaying on VDR 1.7 and the problem was the same. I tried demuxing the recording with ProjectX, this was the output: session infos Monday, March 26, 2012 4:32:41 PM CEST ProjectX 0.90.4.00 (30.03.2006) - working with collection 0 - save normal log file - write all video data - write all other data - patch c.d.flagged infos of pictures - add sequence end code - set resolution in SDE - PVA: strictly specs. for audio streams - VOB: determine diff. Cell timelines - TS: ignore scrambled packets - TS: enhanced search for open packets - TS: join file segments (of Dreambox®) - TS: generate PMT stream dependent - get only enclosed PES/TS packets - concatenate different recordings - ensure 1st PES-packet start with video - generate PCR/SCR from PTS - write output files to: '/home/brian/VDR-debug' - Input File 0: '/media/public/video/VDR/2012-03-24.23.56.50.50.rec/001.vdr' (1,953,444 bytes) - Filetype is PES (incl. MPEG Video) - demux - found PES-ID 0xE0 (MPEG Video) @ 0 - found PES-ID 0xC1 (MPEG Audio) @ 2048 - found PES-ID 0xC0 (MPEG Audio) @ 6537 - video basics: 704*576 @ 25fps @ 0.7031 (16:9) @ 1500bps, vbvBuffer 112 - starting export of video data @ GOP# 0 ! dropping useless B-Frames @ GOP# 0 / new Timecode 00:00:00.000 - actual written vframes: 145 switch to file: /media/public/video/VDR/2012-03-24.23.56.50.50.rec/002.vdr (2,097,184,848 bytes) @ 1953444 ! dropping GOP# 9 @ orig.PTS 08:50:48.464 (2866361773), errorcode: 24 ! Pics exp/cnt 3/1, inGOP PTS diff. 0ms, new Timecode 00:00:05.800 ! ID 0xC0 (sub 0x0) packet# 252, big PTS difference: this 2866437692, prev. 2866321052 ! ID 0xC1 (sub 0x0) packet# 253, big PTS difference: this 2866450652, prev. 2866321052 ! PTS difference of 108000 (00:00:01.200) to last exported GOP detected (broken_link corrected) ! dropping useless B-Frames @ GOP# 10 / new Timecode 00:00:05.800 - found PES-ID 0xBD (private stream 1) (SubID 0x20) @ 2554745 - found PES-ID 0xBD (private stream 1) @ 4396859 GOP# 9947, new format in next leading sequenceheader detected: (01:45:12.760) - video basics: 704*576 @ 25fps @ 0.6735 (4:3) @ 1500bps, vbvBuffer 112 - Video: fr/ ct/ 1p/ cg/ og/ dg - 174194/ 2/ 1/ 10896/ 0/ 1 - Video length: 174194 frames @ 01:56:07.760 - GOP summary: min. 6, max. 40 fields; contains interlaced frames - avg. nom. bitrate 2067611bps (min/max: 261600/8854800) - set first sequenceheader bitrate to 8854800bps --- new File: /home/brian/VDR-debug/001.m2v -- MPEG Audio (0xC1) - check CRC of AC-3 / MPEG-Audio L1,2 - delete CRC in MPEG-Audio Layer1,2 - add frames Audio PTS: first packet 08:50:42.107, last packet 10:46:51.851 Video PTS: start 1.GOP 08:50:42.664, end last GOP 10:46:51.704 - adjusting audio at video-timeline - src_audio: MPEG-1, Layer2, 48000Hz, stereo, 128kbps, noCRC @ 00:00:00.000 ! 14 frame(s) (336ms) inserted @ 00:00:05.472 audio frames: wri/pre/skip/ins/add 290323/0/0/14/0 @ 01:56:07.752 done... --- new File: '/home/brian/VDR-debug/001.mp2' -- MPEG Audio (0xC0) - check CRC of AC-3 / MPEG-Audio L1,2 - delete CRC in MPEG-Audio Layer1,2 - add frames Audio PTS: first packet 08:50:42.107, last packet 10:46:51.851 Video PTS: start 1.GOP 08:50:42.664, end last GOP 10:46:51.704 - adjusting audio at video-timeline - src_audio: MPEG-1, Layer2, 48000Hz, stereo, 192kbps, noCRC @ 00:00:00.000 ! 16 frame(s) (384ms) inserted @ 00:00:05.424 audio frames: wri/pre/skip/ins/add 290323/0/0/16/0 @ 01:56:07.752 done... --- new File: '/home/brian/VDR-debug/001[1].mp2' -- Subpicture (SubID 0x20) - selected DVB subpicture color model: (0) 4 colors ; fixed to page id: - export format: sup - temp. file: 001.sp (995605 bytes) Subpicture PTS: first packet 08:50:52.525, last packet 10:46:52.627 Video PTS: start 1.GOP 08:50:42.664, end last GOP 10:46:51.704 - adjusting subpicture at video-timeline ! suppic unknown cmd: 144 The last line is repeated 500 times, then I get: stopped... ! an error has occured.. (please inform the authors at 'forum.dvbtechnics.info') java.lang.NullPointerException Is there any way I can analyse this further? I dont see any errrors with femon on ITV3. Hi, you could try checkts, and see if the recording has continuity errors. http://projects.vdr-developer.org/git/vdr-checkts.git/tree/README Joerg Cheers Brian ___ 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] [ANNOUNCE] VDR developer version 1.7.24
Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem. Jörg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 19.02.2012 19:51, schrieb Joerg Riechardt: Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem. This happens with the vdr-xine plugin only. With softhddevice or xineliboutput it is ok. Jörg Jörg ___ 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] [ANNOUNCE] VDR developer version 1.7.24
Am 19.02.2012 22:04, schrieb Klaus Schmidinger: On 19.02.2012 20:45, Joerg Riechardt wrote: Am 19.02.2012 19:51, schrieb Joerg Riechardt: Hi, when I replay a recording with 1.7.24 and switch several times from replay to fast replay and back, it takes too long until VDR responds to the remote. Happens with old recordings and recordings made with 1.7.24. With 1.7.23 no problem. This happens with the vdr-xine plugin only. With softhddevice or xineliboutput it is ok. Jörg It also works fine with the TT S2-6400. The only thing I could image to be causing this are the changes in dvbplayer.c regarding Fixed a possible deadlock in time shift mode. Can you please try with dvbplayer.[hc] from version 1.7.23? This will also remove the fix for pausing live video, but that should be independent from this problem. Oh, and just to make sure: you haven't applied any other patches, have you? Klaus With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again. Other patches were not involved. Jörg ___ 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
[vdr] problem in remux.c
Hi Klaus, I just wanted to make you aware of http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1046411-vdr-coredump-und-speicherverletzungen-beim-umschalten/#post1046411 It is about a problem in remux.c Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe can't connect
Am 09.11.2011 13:49, schrieb Damien Bally: Le 09/11/2011 11:19, Theunis Potgieter a écrit : Your vdr-xineliboutput might not be the primary output device, you must first change that before you see live video/audio. I tried the following command line : vdr-Pxineliboutput --local=none --primary --remote=37890 Hi, enable verbose, what´s the output? Joerg No success. Damien ___ 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] VDR Issues with DVB-T Services in Israel
Am 29.07.2011 01:32, schrieb Barak Nahari: I've been looking in my syslog, http://pastebin.com/L3MmV7dh and found a segfault error, is it concerning xine decoding of the h264 stream? From a quick googling it looks like this may be the problem. Is there's a way do get debug info from vdr and maybe to determine where the fault? When trying to play the stream i captured with vlc in mplayer i only get sound, is anyone can confirm that there is a problem while decoding the stream. My stream capture http://www.2shared.com/file/wEdFKfZy/test.html Hi, the stream plays fine on my vdr machine using mplayer (mplayer -vo vdpau:deint=3 -vc ffh264vdpau -af resample -cache 8192 -autosync 1 -fs /test.ts). If you play with xineliboutput and --verbose, what do you get? (I use the xine plugin from Reinhard Nissl, there it is --verbose=2). How do you decode, with cpu or gpu? Do you use vdpau? Joerg If so then will vdr remain unusable at all until a fix is patched to xine lib. ___ 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] vdr-xine trickspeed bug report
Am 13.04.2011 12:55, schrieb Joerg Riechardt: Am 10.04.2011 20:18, schrieb Joerg Riechardt: Am 10.04.2011 13:30, schrieb Reinhard Nissl: Hi, Am 08.04.2011 19:45, schrieb Joerg Riechardt: In the replay of a h264 720p recording I am paused at a mark. 1. Now I press right and start slow motion forward at 1/8 speed. The log shows TrickSpeed: 8 TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode ... In the rythm of the SequenceEndCode messages I see distortions and hold-ups in the video flow. The start is immediate. 2. This time starting at the mark I press play, pause, right and start slow motion forward at 1/8 speed. The log shows TrickSpeed: 8 P ... The start is delayed, but there are no distortions and the video flow is steady. So I guess there is something wrong with the SequenceEndCode detection in 1. and in 2. with the delayed start. You describe slow backward and slow forward behavior of VDR (and vdr-xine behavior in case of H.264 recordings). For the latter, VDR sends all pictures and xine replays them at reduced speed for slow motion. In case of slow backward, VDR sends only I-frames like it does for fast forward or fast backward, but at a much slower replay speed. As for all trickspeed modes which only transfer I-frames, vdr-xine inserts a H.264 SequenceEndCode between each frame to flush the frame immediately to screen, because the current H.264 decoder first fills its DPB with 16 frames before it outputs them on screen. For all other trickspeed modes (i. e. slow forward) you see the delay of filling the DPB. Regarding your distortions, disable deinterlacing in xine and verify, that your distortions go away besides that every second line of the image appears in background color. To fix this issue please apply a patch to VDR-1.7.17 (which was issued on this mailing list) regarding frame detection and rebuild your index file. Besides that you should also check the following settings in .xine/config: # disable decoder flush at discontinuity # bool, default: 0 engine.decoder.disable_flush_at_discontinuity:1 # disable decoder flush from video out # bool, default: 0 engine.decoder.disable_flush_from_video_out:1 Bye. Hi, thanks for your explanation. Maybe I was not clear enough. I was *not* describing slow backward and slow forward. *Both* logs were with slow forward, the difference was that in 1. the replay was started from pause at an I-Frame and in 2. the replay was started from pause in between two I-Frames, so from a non-I-Frame. So starting from an I-Frame leads to a different result than starting from a non-I-Frame. For me that was unexpected and interesting. From your explanation it seems to me, that 2. is the behaviour you expect for slow forward. But 1. was also slow forward, not slow backward. 1. seems to show, that an immediate start is possible also for slow forward. And the short delays in the video flow reminded me a little bit of the delays with newer nvidia drivers. Only in 1. they are in the rythm of the I-Frames. So I thought maybe there is something to find out from this. I have the mentioned frame detection patch applied, so this happened with that patch. If I remember right, I have also both those settings in my .xine/config. I am not at home right now. Joerg Hi, I do have both mentioned settings in my .xine/config. I did a test with xineliboutput and got no distortions (except sometimes at the very beginning) when starting slow forward from an I-Frame. So I guess this *is* a vdr-xine bug. Although probably not a very important one. And vdr-xine is still my favourite, so thanks for all your work on it! Joerg btw. this happens with the new decoder as well. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine trickspeed bug report
Am 10.04.2011 20:18, schrieb Joerg Riechardt: Am 10.04.2011 13:30, schrieb Reinhard Nissl: Hi, Am 08.04.2011 19:45, schrieb Joerg Riechardt: In the replay of a h264 720p recording I am paused at a mark. 1. Now I press right and start slow motion forward at 1/8 speed. The log shows TrickSpeed: 8 TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode ... In the rythm of the SequenceEndCode messages I see distortions and hold-ups in the video flow. The start is immediate. 2. This time starting at the mark I press play, pause, right and start slow motion forward at 1/8 speed. The log shows TrickSpeed: 8 P ... The start is delayed, but there are no distortions and the video flow is steady. So I guess there is something wrong with the SequenceEndCode detection in 1. and in 2. with the delayed start. You describe slow backward and slow forward behavior of VDR (and vdr-xine behavior in case of H.264 recordings). For the latter, VDR sends all pictures and xine replays them at reduced speed for slow motion. In case of slow backward, VDR sends only I-frames like it does for fast forward or fast backward, but at a much slower replay speed. As for all trickspeed modes which only transfer I-frames, vdr-xine inserts a H.264 SequenceEndCode between each frame to flush the frame immediately to screen, because the current H.264 decoder first fills its DPB with 16 frames before it outputs them on screen. For all other trickspeed modes (i. e. slow forward) you see the delay of filling the DPB. Regarding your distortions, disable deinterlacing in xine and verify, that your distortions go away besides that every second line of the image appears in background color. To fix this issue please apply a patch to VDR-1.7.17 (which was issued on this mailing list) regarding frame detection and rebuild your index file. Besides that you should also check the following settings in .xine/config: # disable decoder flush at discontinuity # bool, default: 0 engine.decoder.disable_flush_at_discontinuity:1 # disable decoder flush from video out # bool, default: 0 engine.decoder.disable_flush_from_video_out:1 Bye. Hi, thanks for your explanation. Maybe I was not clear enough. I was *not* describing slow backward and slow forward. *Both* logs were with slow forward, the difference was that in 1. the replay was started from pause at an I-Frame and in 2. the replay was started from pause in between two I-Frames, so from a non-I-Frame. So starting from an I-Frame leads to a different result than starting from a non-I-Frame. For me that was unexpected and interesting. From your explanation it seems to me, that 2. is the behaviour you expect for slow forward. But 1. was also slow forward, not slow backward. 1. seems to show, that an immediate start is possible also for slow forward. And the short delays in the video flow reminded me a little bit of the delays with newer nvidia drivers. Only in 1. they are in the rythm of the I-Frames. So I thought maybe there is something to find out from this. I have the mentioned frame detection patch applied, so this happened with that patch. If I remember right, I have also both those settings in my .xine/config. I am not at home right now. Joerg Hi, I do have both mentioned settings in my .xine/config. I did a test with xineliboutput and got no distortions (except sometimes at the very beginning) when starting slow forward from an I-Frame. So I guess this *is* a vdr-xine bug. Although probably not a very important one. And vdr-xine is still my favourite, so thanks for all your work on it! Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine trickspeed bug report
Am 10.04.2011 13:30, schrieb Reinhard Nissl: Hi, Am 08.04.2011 19:45, schrieb Joerg Riechardt: In the replay of a h264 720p recording I am paused at a mark. 1. Now I press right and start slow motion forward at 1/8 speed. The log shows TrickSpeed: 8 TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode TrickSpeedMode: push H.264 SequenceEndCode ... In the rythm of the SequenceEndCode messages I see distortions and hold-ups in the video flow. The start is immediate. 2. This time starting at the mark I press play, pause, right and start slow motion forward at 1/8 speed. The log shows TrickSpeed: 8 P ... The start is delayed, but there are no distortions and the video flow is steady. So I guess there is something wrong with the SequenceEndCode detection in 1. and in 2. with the delayed start. You describe slow backward and slow forward behavior of VDR (and vdr-xine behavior in case of H.264 recordings). For the latter, VDR sends all pictures and xine replays them at reduced speed for slow motion. In case of slow backward, VDR sends only I-frames like it does for fast forward or fast backward, but at a much slower replay speed. As for all trickspeed modes which only transfer I-frames, vdr-xine inserts a H.264 SequenceEndCode between each frame to flush the frame immediately to screen, because the current H.264 decoder first fills its DPB with 16 frames before it outputs them on screen. For all other trickspeed modes (i. e. slow forward) you see the delay of filling the DPB. Regarding your distortions, disable deinterlacing in xine and verify, that your distortions go away besides that every second line of the image appears in background color. To fix this issue please apply a patch to VDR-1.7.17 (which was issued on this mailing list) regarding frame detection and rebuild your index file. Besides that you should also check the following settings in .xine/config: # disable decoder flush at discontinuity # bool, default: 0 engine.decoder.disable_flush_at_discontinuity:1 # disable decoder flush from video out # bool, default: 0 engine.decoder.disable_flush_from_video_out:1 Bye. Hi, thanks for your explanation. Maybe I was not clear enough. I was *not* describing slow backward and slow forward. *Both* logs were with slow forward, the difference was that in 1. the replay was started from pause at an I-Frame and in 2. the replay was started from pause in between two I-Frames, so from a non-I-Frame. So starting from an I-Frame leads to a different result than starting from a non-I-Frame. For me that was unexpected and interesting. From your explanation it seems to me, that 2. is the behaviour you expect for slow forward. But 1. was also slow forward, not slow backward. 1. seems to show, that an immediate start is possible also for slow forward. And the short delays in the video flow reminded me a little bit of the delays with newer nvidia drivers. Only in 1. they are in the rythm of the I-Frames. So I thought maybe there is something to find out from this. I have the mentioned frame detection patch applied, so this happened with that patch. If I remember right, I have also both those settings in my .xine/config. I am not at home right now. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
Am 02.04.2011 23:18, schrieb Klaus Schmidinger:
On 02.04.2011 02:38, Joerg Riechardt wrote:
Problem solved with this patch:
--- dvbplayer.c.orig 2010-03-07 15:24:26.0 +0100
+++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200
@@ -320,7 +320,7 @@
if (nonBlockingFileReader)
nonBlockingFileReader-Clear();
if (!firstPacket) // don't set the readIndex twice if Empty() is
called more than once
- readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action() will
first increment it!
+ readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // prevents dropped
frames in xine vdpau h264
delete readFrame; // might not have been stored in the buffer in Action()
readFrame = NULL;
playFrame = NULL;
@@ -388,6 +388,8 @@
int pc = 0;
readIndex = Resume();
+ int resume = readIndex;
+ bool firsttime = true;
if (readIndex = 0)
isyslog(resuming replay at index %d (%s), readIndex,
*IndexToHMSF(readIndex, true, framesPerSecond));
@@ -452,6 +454,12 @@
else if (index) {
uint16_t FileNumber;
off_t FileOffset;
+ if (firsttime) {
+ if (readIndex == (resume + 32)) {
+ Goto((readIndex - 32));// prevents dropped frames in xine vdpau h264
+ firsttime = false;
+ }
+ }
if (index-Get(readIndex + 1, FileNumber, FileOffset,
readIndependent, Length) NextFile(FileNumber, FileOffset))
readIndex++;
else
@@ -760,7 +768,7 @@
if (Index 0)
Index = index-GetNextIFrame(Index, false, NULL, NULL, NULL, true);
if (Index = 0)
- readIndex = Index - 1; // Action() will first increment it!
+ readIndex = Index; // prevents dropped frames in xine vdpau h264
}
Play();
}
I can't help the feeling that this is a problem that should
be addressed in xine, rather than working around it in VDR.
Klaus
I agree. I just thought, until that happens, it is nice for those
concerned to have that patch.
And maybe this patch gives an idea for a fix in xine.
Joerg
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
Am 31.03.2011 17:27, schrieb Joerg Riechardt: Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxx because it's too old (diff : y) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with - readIndex = Index - 1; // Action() will first increment it! + readIndex = Index; // Index - 1 causes problems in xine I no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high. This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch. Well, for fast forward I do have a patch now, which is similar to the above: - readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action() will first increment it! + readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // -1 causes problems in xine ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
Problem solved with this patch:
--- dvbplayer.c.orig2010-03-07 15:24:26.0 +0100
+++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200
@@ -320,7 +320,7 @@
if (nonBlockingFileReader)
nonBlockingFileReader-Clear();
if (!firstPacket) // don't set the readIndex twice if Empty() is
called more than once
- readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1; // Action()
will first increment it!
+ readIndex = ptsIndex.FindIndex(DeviceGetSTC()); // prevents
dropped frames in xine vdpau h264
delete readFrame; // might not have been stored in the buffer in
Action()
readFrame = NULL;
playFrame = NULL;
@@ -388,6 +388,8 @@
int pc = 0;
readIndex = Resume();
+ int resume = readIndex;
+ bool firsttime = true;
if (readIndex = 0)
isyslog(resuming replay at index %d (%s), readIndex,
*IndexToHMSF(readIndex, true, framesPerSecond));
@@ -452,6 +454,12 @@
else if (index) {
uint16_t FileNumber;
off_t FileOffset;
+ if (firsttime) {
+if (readIndex == (resume + 32)) {
+Goto((readIndex - 32));// prevents dropped
frames in xine vdpau h264
+firsttime = false;
+}
+ }
if (index-Get(readIndex + 1, FileNumber,
FileOffset, readIndependent, Length) NextFile(FileNumber, FileOffset))
readIndex++;
else
@@ -760,7 +768,7 @@
if (Index 0)
Index = index-GetNextIFrame(Index, false, NULL, NULL,
NULL, true);
if (Index = 0)
- readIndex = Index - 1; // Action() will first increment it!
+ readIndex = Index; // prevents dropped frames in xine vdpau h264
}
Play();
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxx because it's too old (diff : y) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with - readIndex = Index - 1; // Action() will first increment it! + readIndex = Index; // Index - 1 causes problems in xine I no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high. This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch. I would very much appreciate if somebody with deeper knowledge of the interplay between vdr - vdr-xine - xine-lib would look into and comment on this. You find more information at http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p990596-das-abspielen-von-aufnahmen-wird-erst-nach-einiger-zeit-stabil-oder-nie-betrifft-auch-spr%C3%BCnge/#post990596 (german). Without patch the video plugin gets loaded first, the audio plugin second. With patch the video plugin gets loaded second, the audio plugin first. Don´t know if that is important. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
Am 31.03.2011 17:48, schrieb VDR User: On Thu, Mar 31, 2011 at 8:27 AM, Joerg Riechardtj.riecha...@gmx.de wrote: Hi, I have a problem with skipping during a replay of a HD recording. Running xine --verbose=2 I see after pressing the yellow button (skip +60 sec) lots of video_out: throwing away image with pts xxx because it's too old (diff : y) messages. This is for a few seconds or forever, depending on system load, and causes 100% Cpu, and spoils recordings on my slow system. On faster systems you will hardly notice this. If I patch cDvbPlayer::SkipSeconds with - readIndex = Index - 1; // Action() will first increment it! + readIndex = Index; // Index - 1 causes problems in xine I no longer get those „throwing away image“ messages and the Cpu peak is only short and not that high. This happens also for starting a replay and for resuming replay after fast forward, but for those I have no vdr patch. I would very much appreciate if somebody with deeper knowledge of the interplay between vdr- vdr-xine- xine-lib would look into and comment on this. Are you saying that when you press skip+/-, you get a delay before the skip occurs? Well, before stable replay starts. You could run xine verbose and post your log in order to know if we are talking about the same thing, I am not sure from your description. If so, I experience this problem too. Most of the time when I press skip+/-, there's a 4-6 second pause before the skip actually occurs. Very aggravating to say the least. The good news is that Rnissl has this problem also How do you know? Are you in contact with him? so there's no need to try to reproduce it -- he can already observe it locally. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine-0.9.2 plugin does not support cutting.
Carsten Koch schrieb: Reinhard, you have done an amazing job with the xine plugin. It works very well and considering xine's complexity, I can appreciate the hard work that must have been required to get both the infrastructure in xine and the plugin itself working as well as it does today. I noticed, however, that it is extremely hard to use VDRs cutting function with it. For example, when I use the '7' and '9' keys to jump to the previous/next cut mark, or when I use the '4' and '6' keys to fine-position a cut mark, the video image is not updated, works here (except in very rare cases with certain video material) Joerg so I am basically forced to navigate in complete darkness. Is that a known bug? Does it happen only in my setup (TT-budget S2-3200, GeForce 9500GT with VDPAU)? Is there a configuration option I can tweak to fix it? Thanks in advance for any hints, Carsten. ___ 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] [ANNOUNCE] vdr-xine-0.9.0 plugin
Reinhard Nissl schrieb: Hi, Well, vdr-xine-0.9.0 should be compatible till VDR-1.2.x. Hi, I tried with vdr-1.6.0.2 and got messages trying to connect or so, but never a connect. I used the added xine-lib (+ patch) and -ui under Suse 11.1. vdr-xine-0.8.2 works well. As I have no X I use fbxine. Joerg ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
