Hi All, I have used this guide to install VDR on debian: https://wiki.debian.org/VDR When I play the digitenne recordings, I see the first few rows coming from the right of the image are actually on the left on the image. It's like the image is rotated a bit horizontally. It's a bit hard to describe, but if the original picture was like this: 12345 12345 12345 What I see on my monitor is like this: 51234 51234 51234 This happens when I playback with VDR itself, and also when I playback with VLC. Therefore I think it's in the recorded .ts itself. I have seen it with recordings made on my arm allwinner A20, and on recordings made with a AMD athlon 64. Both recordings are made with the same DVB-T receiver. Has anybody seen the same on their recordings? Is this my DVB-T receiver, my version of VDR? Or does digitenne (DVB-T Netherlands) actually broadcasts the signal like this? my versions: (from the ARM machine, my X86 platform is decommissioned) ~# vdr --version Oct 5 19:04:08.181 [general.debug] using new 1.7.11+ capture code vdr (1.7.28/1.7.28) - The Video Disk Recorder epgsearchonly (0.0.1) - Direct access to epgsearch's search menu quickepgsearch (0.0.1) - Quick search for broadcasts streamdev-server (0.6.0) - VDR Streaming Server xineliboutput (1.0.90-cvs) - X11/xine-lib output plugin conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu sc (1.0.0pre-HG-29b7b5f231c8+) - A software emulated CAM live (0.2.0) - Live Interactive VDR Environment epgsearch (1.0.1) - search the EPG for repeats and more :~# lsusb Bus 004 Device 004: ID 2013:0245 PCTV Systems PCTV 73ESE Bus 004 Device 005: ID 2013:0245 PCTV Systems PCTV 73ESE Bus 004 Device 006: ID 2013:0245 PCTV Systems PCTV 73ESE Kind regards, Cedric
----Origineel Bericht---- Van : cedric.dewijs@telfort.nl Datum : 05/10/2014 17:05 Aan : vdr@linuxtv.org Onderwerp : [vdr] digitenne recording: image is shifted a few pixels to the left Hi All, I have used this guide to install VDR on debian: https://wiki.debian.org/VDR When I play the digitenne recordings, I see the first few rows coming from the right of the image are actually on the left on the image. It's like the image is rotated a bit horizontally. It's a bit hard to describe, but if the original picture was like this: 12345 12345 12345 What I see on my monitor is like this: 51234 51234 51234 This happens when I playback with VDR itself, and also when I playback with VLC. Therefore I think it's in the recorded .ts itself. I have seen it with recordings made on my arm allwinner A20, and on recordings made with a AMD athlon 64. Both recordings are made with the same DVB-T receiver. Has anybody seen the same on their recordings? Is this my DVB-T receiver, my version of VDR? Or does digitenne (DVB-T Netherlands) actually broadcasts the signal like this? my versions: (from the ARM machine, my X86 platform is decommissioned) ~# vdr --version Oct 5 19:04:08.181 [general.debug] using new 1.7.11+ capture code vdr (1.7.28/1.7.28) - The Video Disk Recorder epgsearchonly (0.0.1) - Direct access to epgsearch's search menu quickepgsearch (0.0.1) - Quick search for broadcasts streamdev-server (0.6.0) - VDR Streaming Server xineliboutput (1.0.90-cvs) - X11/xine-lib output plugin conflictcheckonly (0.0.1) - Direct access to epgsearch's conflict check menu sc (1.0.0pre-HG-29b7b5f231c8+) - A software emulated CAM live (0.2.0) - Live Interactive VDR Environment epgsearch (1.0.1) - search the EPG for repeats and more :~# lsusb Bus 004 Device 004: ID 2013:0245 PCTV Systems PCTV 73ESE Bus 004 Device 005: ID 2013:0245 PCTV Systems PCTV 73ESE Bus 004 Device 006: ID 2013:0245 PCTV Systems PCTV 73ESE Kind regards, Cedric Strange, it's not with all recordings. I don't know what the difference is. Maybe only one of the 3 receivers is doing this. Kind regards, Cedric
I occasionally see vdr crashing when a recording starts like this:
kernel: traps: recording[352] trap divide error ip:4cfeff sp:7fc8e9523e00 error:0 in vdr[400000+156000] runvdr[300]: Floating point exception
$ gdb /usr/bin/vdr (gdb) disass /m 0x4cfeff
1514 in remux.c 0x00000000004cfee6 <+870>: mov 0x290(%rbx),%rsi 0x00000000004cfeed <+877>: xor %edx,%edx 0x00000000004cfeef <+879>: mov 0x284(%rbx),%ecx 0x00000000004cfef5 <+885>: mov 0xc(%rbx),%eax 0x00000000004cfefc <+892>: add 0xc(%rsi),%ecx 0x00000000004cfeff <+895>: div %ecx 0x00000000004cff08 <+904>: mov %eax,%ecx
Point to this in remux.c? 1514: uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
I don't know how to make it happen.
Chris
On 12.10.2014 16:30, Chris Mayo wrote:
I occasionally see vdr crashing when a recording starts like this:
kernel: traps: recording[352] trap divide error ip:4cfeff sp:7fc8e9523e00 error:0 in vdr[400000+156000] runvdr[300]: Floating point exception
$ gdb /usr/bin/vdr (gdb) disass /m 0x4cfeff
1514 in remux.c 0x00000000004cfee6 <+870>: mov 0x290(%rbx),%rsi 0x00000000004cfeed <+877>: xor %edx,%edx 0x00000000004cfeef <+879>: mov 0x284(%rbx),%ecx 0x00000000004cfef5 <+885>: mov 0xc(%rbx),%eax 0x00000000004cfefc <+892>: add 0xc(%rsi),%ecx 0x00000000004cfeff <+895>: div %ecx 0x00000000004cff08 <+904>: mov %eax,%ecx
Point to this in remux.c? 1514: uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
This should fix it:
--- remux.c 2014/03/08 15:10:24 2.75.1.5 +++ remux.c 2014/04/13 13:59:21 2.75.1.6 @@ -1511,7 +1511,12 @@ for (int i = 0; i < numPtsValues; i++) ptsValues[i] = ptsValues[i + 1] - ptsValues[i]; qsort(ptsValues, numPtsValues, sizeof(uint32_t), CmpUint32); - uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset()); + int Div = framesPerPayloadUnit; + if (framesPerPayloadUnit > 1) + Div += parser->IFrameTemporalReferenceOffset(); + if (Div <= 0) + Div = 1; + uint32_t Delta = ptsValues[0] / Div; // determine frame info: if (isVideo) { if (abs(Delta - 3600) <= 1)
Klaus
On 12/10/14 16:42, Klaus Schmidinger wrote:
On 12.10.2014 16:30, Chris Mayo wrote:
I occasionally see vdr crashing when a recording starts like this:
kernel: traps: recording[352] trap divide error ip:4cfeff sp:7fc8e9523e00 error:0 in vdr[400000+156000] runvdr[300]: Floating point exception
$ gdb /usr/bin/vdr (gdb) disass /m 0x4cfeff
1514 in remux.c 0x00000000004cfee6 <+870>: mov 0x290(%rbx),%rsi 0x00000000004cfeed <+877>: xor %edx,%edx 0x00000000004cfeef <+879>: mov 0x284(%rbx),%ecx 0x00000000004cfef5 <+885>: mov 0xc(%rbx),%eax 0x00000000004cfefc <+892>: add 0xc(%rsi),%ecx 0x00000000004cfeff <+895>: div %ecx 0x00000000004cff08 <+904>: mov %eax,%ecx
Point to this in remux.c? 1514: uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
This should fix it:
--- remux.c 2014/03/08 15:10:24 2.75.1.5 +++ remux.c 2014/04/13 13:59:21 2.75.1.6 @@ -1511,7 +1511,12 @@ for (int i = 0; i < numPtsValues; i++) ptsValues[i] = ptsValues[i + 1] - ptsValues[i]; qsort(ptsValues, numPtsValues, sizeof(uint32_t), CmpUint32);
uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
int Div = framesPerPayloadUnit;if (framesPerPayloadUnit > 1)Div += parser->IFrameTemporalReferenceOffset();if (Div <= 0)Div = 1;uint32_t Delta = ptsValues[0] / Div; // determine frame info: if (isVideo) { if (abs(Delta - 3600) <= 1)Klaus
Many thanks. Patch applied. Will take at least a few weeks to be confident of a difference.
I guess I should have googled the line of code, http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1194836-framera...
Chris
-
cedric.dewijs＠telfort.nl -
Chris Mayo -
Klaus Schmidinger