Hi,
attached you'll find an updated patch for VDR-1.5.10. It replaces the formerly patch for VDR-1.5.9.
Have a look at this page for more instructions on this concern:
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
Bye.
On Wed, Oct 17, 2007 at 08:16:54PM +0200, Reinhard Nissl wrote:
Hi,
attached you'll find an updated patch for VDR-1.5.10. It replaces the formerly patch for VDR-1.5.9.
I still don't understand why you want to record h.264 in PES...
Georg Acher schrieb:
On Wed, Oct 17, 2007 at 08:16:54PM +0200, Reinhard Nissl wrote:
Hi,
attached you'll find an updated patch for VDR-1.5.10. It replaces the formerly patch for VDR-1.5.9.
I still don't understand why you want to record h.264 in PES...
Furthermore: How do I demux a h.264 PES recording? With TS files recorded on Windows I used the tool "xport" which also takes care of proper audio sync. ProjectX still does not support H.264.
Nevertheless: Thanks a lot, hope that I get it working within the next days, especially for checking if my system is fast enough for software-only decoding.
With kind regards
Joerg Knitter
Hi there,
attached you'll find an updated patch for VDR-1.5.10. It replaces the formerly patch for VDR-1.5.9.
could you seperate the patch into H.264 and DVB-S2 parts again? I use DVB-C with it here and do not want to upgrade to drivers with DVB-S2 support.
Have a look at this page for more instructions on this concern:
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
These are really nice and work fine.
Cheers and many thanks for your efforts!
Jan
Hi,
Jan Wagner schrieb:
attached you'll find an updated patch for VDR-1.5.10. It replaces the formerly patch for VDR-1.5.9.
could you seperate the patch into H.264 and DVB-S2 parts again? I use DVB-C with it here and do not want to upgrade to drivers with DVB-S2 support.
I've removed the DVB-S2 part from the original patch. The result is attached. Please give it a try.
Bye.
On Sat, Oct 20, 2007 at 10:49:13PM +0200, Reinhard Nissl wrote:
Hi,
Jan Wagner schrieb:
attached you'll find an updated patch for VDR-1.5.10. It replaces the formerly patch for VDR-1.5.9.
could you seperate the patch into H.264 and DVB-S2 parts again? I use DVB-C with it here and do not want to upgrade to drivers with DVB-S2 support.
I've removed the DVB-S2 part from the original patch. The result is attached. Please give it a try.
How about version that allows reception of dvb-[t,c,s] and dvb-s2? I did test with the instructions found from: http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
but... when tuning to dvb-c channels, i get message saying something like "channel not available".
Of course one can have separate vdr instances on each cards by using -D option, but that's not the best choice. br.
...hanu
Hi,
Hannu Tirkkonen schrieb:
How about version that allows reception of dvb-[t,c,s] and dvb-s2? I did test with the instructions found from: http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
but... when tuning to dvb-c channels, i get message saying something like "channel not available".
Of course one can have separate vdr instances on each cards by using -D option, but that's not the best choice. br.
The problem is that DVB-S2 devices can currently only be used by the multiproto interface. This interface supports DVB-S, DVB-C, DVB-T and DVT-H too, but the existing drivers need to be adapted to the new interface -- more or less the same as VDR had to be adapted to the new API, but one big question seems to be whether the multiproto API is the right way to go.
As the multiproto tree still supports the old frontend API, the problem could also be solved in VDR by using the old API when the device reports a certain error for new API functions. But this would mean to double much code.
Anyway, if one feels the need to go this way, feel free to do so.
Bye.
Am Samstag, den 20.10.2007, 22:49 +0200 schrieb Reinhard Nissl:
Hi,
Jan Wagner schrieb:
attached you'll find an updated patch for VDR-1.5.10. It replaces the formerly patch for VDR-1.5.9.
could you seperate the patch into H.264 and DVB-S2 parts again? I use DVB-C with it here and do not want to upgrade to drivers with DVB-S2 support.
I've removed the DVB-S2 part from the original patch. The result is attached. Please give it a try.
Thanks. It does work as expected. I am still not able to play H.264 content on my Core2Duo 6850 (3.0 GHz) though. My nvidia graphics card 8600 does not seem to support xvmc so I have a lot of dropped frames and lots of block artefacts which seem to be caused by the stream (ffmpeg always says something about cabal(?)). Can I transcode the records into something playable under windows? pes2ts does not seem to work.
Cheers Jan
Jan Wagner wrote:
Thanks. It does work as expected. I am still not able to play H.264 content on my Core2Duo 6850 (3.0 GHz) though. My nvidia graphics card 8600 does not seem to support xvmc so I have a lot of dropped frames and lots of block artefacts which seem to be caused by the stream (ffmpeg always says something about cabal(?)). Can I transcode the records into something playable under windows? pes2ts does not seem to work.
Try the patch at posted at http://www.vdr-portal.de/board/thread.php?threadid=50139&page=32 from Reinhard, which will solve most of the performance problems. Unfortunately, transmissions using interlaced pictures+spatial direct mode still do not seem to work right and may cause major performance and stability problems.
With kind regards
Jörg
Try the patch at posted at http://www.vdr-portal.de/board/thread.php?threadid=50139&page=32 from Reinhard, which will solve most of the performance problems. Unfortunately, transmissions using interlaced pictures+spatial direct mode still do not seem to work right and may cause major performance and stability problems.
Awesome, that works like a charm even with deinterlacing on. I will try xine-0.8.0 tonight. Keep up the nice work Reinhard!
Jan
Hello Reinhard
it's interesting - is there some opinion from VDR's users about this path ? Which h.264 dvb-s2 channels is it possible to watch really ? What about CPU's load during this ? which hardware (dvb-s2 card, cpu, graphic card) use ?
regards Igor
Hi,
I tried the patch yesterday on my desktop computer: -
2.13Ghz Intel Core 2 CPU 2Gb RAM Nvidia 6200LE PCI-E graphics card 400Gb IDE (not SATA) hard disk Skystar 2 DVB-S Latest Ubuntu with xorg Latest NVIDIA Drivers Hooked up DVI -> HDMI on a Pioneer 43" plasma TV at 720p (native resolution of the panel = 1024x768) and using 32bpp on the desktop. vdr-1.5.9 with the earlier h264 patch (I didn't see the seperated patch for 1.5.10 yesterday) xine-lib-cvs
The only test channel I could try it on at the moment is the BBC HD service on Astra 2 which is FTA, DVB-S and mpeg4 (MBAFF). Used tvtime Greedy2Frame deinterlacer in xine.
The picture was very good, but there was dropped frames that xine reported and the stuttered on occassion and then ran very quickly to catch up. Playing around with the settings in xine (setting threads to 2 etc) didn't really make much difference. However, for the first time I've spent playing with this I was impressed with the picture quality out of VDR. Top reported that the CPU was ~40% idle so I don't know why I saw dropped frames...
One other thing I noticed though was when using XVMC (-V xxmc) to view normal MPEG2 channels the VDR OSD looked terrible (very blockly looking) and playing with the settings in the xine plugin did not make it better. Any recommendations on improving this? When using MPEG4 (i.e. software accel) the OSD was fine.
Any thoughts on this anyone and/or Reinhard?
Cheers
Morfsta
On 10/21/07, Igor Nikanov goga777@bk.ru wrote:
Hello Reinhard
it's interesting - is there some opinion from VDR's users about this path ? Which h.264 dvb-s2 channels is it possible to watch really ? What about CPU's load during this ? which hardware (dvb-s2 card, cpu, graphic card) use ?
regards Igor
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hello, Morfsta
thanks you very much for your report
vdr-1.5.9 with the earlier h264 patch (I didn't see the seperated patch for 1.5.10 yesterday)
can you try with yesterday patch for 1.5.10 ?
The only test channel I could try it on at the moment is the BBC HD service on Astra 2 which is FTA, DVB-S and mpeg4 (MBAFF). Used tvtime Greedy2Frame deinterlacer in xine.
can you try with others dvb-s FTA hdtv channels ? http://ru.kingofsat.net/hdtv.php
regards Igor
Hi,
Morfsta schrieb:
The picture was very good, but there was dropped frames that xine reported and the stuttered on occassion and then ran very quickly to catch up. Playing around with the settings in xine (setting threads to 2 etc) didn't really make much difference. However, for the first time I've spent playing with this I was impressed with the picture quality out of VDR. Top reported that the CPU was ~40% idle so I don't know why I saw dropped frames...
Frame duration wasn't set at all in xine-lib for this case. xine-lib-1.2 contains now a fix for this issue. The fix is part of vdr-xine-0.8.0's xine-lib.patch for xine-lib-1.1.8, too.
One other thing I noticed though was when using XVMC (-V xxmc) to view normal MPEG2 channels the VDR OSD looked terrible (very blockly looking) and playing with the settings in the xine plugin did not make it better. Any recommendations on improving this? When using MPEG4 (i.e. software accel) the OSD was fine.
xxmc's OSD support allows only 16 colors. I assume, you've enabled font antialiasing in VDR, which requires much more than 16 colors. This is the case for hardware accelerated MPEG2 decoding. For H.264, xxmc falls back to xv where there is no such limitation.
You may also want to try to choose unscaled OSD in vdr-xine's setup menu, which renders the OSD on top of the video image, using libX11. It is therefore not limited to 16 colors but doesn't support OSD transparency at all.
Bye.
Le mercredi 24 octobre 2007 à 09:04 +0200, Reinhard Nissl a écrit :
The picture was very good, but there was dropped frames that xine reported and the stuttered on occassion and then ran very quickly to catch up. Playing around with the settings in xine (setting threads to 2 etc) didn't really make much difference. However, for the first time I've spent playing with this I was impressed with the picture quality out of VDR. Top reported that the CPU was ~40% idle so I don't know why I saw dropped frames...
Frame duration wasn't set at all in xine-lib for this case. xine-lib-1.2 contains now a fix for this issue. The fix is part of vdr-xine-0.8.0's xine-lib.patch for xine-lib-1.1.8, too.
Reinhard,
Where can I find xine-lib-1.2?
Without patching and using the 0.3.0 CPU is back down under 40% on my Epia M10000
Cheers
Tony
Hi,
Tony Grant schrieb:
Frame duration wasn't set at all in xine-lib for this case. xine-lib-1.2 contains now a fix for this issue. The fix is part of vdr-xine-0.8.0's xine-lib.patch for xine-lib-1.1.8, too.
Where can I find xine-lib-1.2?
xine-lib-1.2 is only available from the hg repository. Please follow this guide:
http://www.vdr-wiki.de/wiki/index.php/OpenSuSE_DVB-S2_-_Step_by_Step_Install...
Although not required, I'd suggest you to use vdr-xine-0.8.0 too (see other thread about fixes).
Bye.
Le mercredi 24 octobre 2007 à 09:47 +0200, Reinhard Nissl a écrit :
xine-lib-1.2 is only available from the hg repository. Please follow this guide:
OK I have lib-1.2 and vdr-xine-0.8.0 humming along. Image very clean and CPU usage is down another 5%. I will see if the new version of openchrome and libXVmc fixes something (CPU was 15% when I started this VDR journey). Zaps fast. Locks solid when right clicking to get the xine menu...
How do I set the PCM volume on startup? The setting in the OSD?
Cheers
Tony
On 24 Oct 2007, at 15:44, Tony Grant wrote:
OK I have lib-1.2 and vdr-xine-0.8.0 humming along. Image very clean and CPU usage is down another 5%. I will see if the new version of openchrome and libXVmc fixes something (CPU was 15% when I started this VDR journey). Zaps fast. Locks solid when right clicking to get the xine menu...
Is there any support for h.264 decoding in any of the linux support libraries for the CN700 now?
Otherwise I'd assume that XvMC was not in use when not doing mpeg2 decoding.
Hi,
Tony Grant schrieb:
OK I have lib-1.2 and vdr-xine-0.8.0 humming along. Image very clean and CPU usage is down another 5%. I will see if the new version of openchrome and libXVmc fixes something (CPU was 15% when I started this VDR journey). Zaps fast. Locks solid when right clicking to get the xine menu...
It would be interesting, where the deadlock occurs. To analyze the deadlock, please compile xine-lib and xine-ui with debug information by running configure like that:
CFLAGS='-g3 -O0' ../xine-lib/configure --prefix=/soft/xine-lib-cvs --enable-debug --disable-optimizations --with-external-ffmpeg --disable-dxr3
CFLAGS='-g3 -O0' ../xine-ui/configure --prefix=/soft/xine-ui-cvs --enable-debug --disable-optimizations --enable-vdr-keys
When the deadlock occurs, run gdb like that:
gdb /path/to/xine `pidof xine`
There will be a lot of libraries listed by gdb. Among the output gdb will also report for which libraries it could find debug symbols. For the best result, try to install missing debug symbols if your Linux distribution provides them. For simplicity, quit gdb by typing quit and let xine alive. Restart gdb as mentioned above until debug symbols for all libraries are available.
Then type the following command into gdb:
thread apply all bt
gdb will then output the backtrace of each thread (and there will be about 20). Please report the backtraces here.
How do I set the PCM volume on startup? The setting in the OSD?
When VDR sets the volume, vdr-xine stores this value internally. When xine connects to vdr-xine, the stored value will be transmitted to xine.
Please have a look into VDR's setup menu. There exists a setting which controls whether VDR shall restore the last set volume when it starts. When VDR doesn't restore the volume setting, then vdr-xine's internal value will be 0 and xine's volume will be set to 0, too.
Bye.
Hi Reinhard,
I have downloaded and installed the latest CVS of ffmpeg and xine-lib as well as installing the latest vdr-xine-0.8.0. I again followed the general compilation instructions at the Open Suse DVB-S2 instructions page.
I have just tried it on BBC HD (Astra 2 - H264/MBAFF) as well as HD2/5 (Astra 3 H264/???) and I get video jumping every 2 seconds. Here is the [clipped] output from xine (verbose=3): -
video_out_xshm: video mode depth is 24 (32 bpp), TrueColor, not swapped, video_out_xshm: red: 00ff0000, green: 0000ff00, blue: 000000ff x11osd: unscaled overlay created (XShape mode). video_out: thread created audio_alsa_out : supported modes are 8bit 16bit 24bit mono stereo (4-channel not enabled in xine config) (4.1-channel not enabled in xine config) (5-channel not enabled in xine config) (5.1-channel not enabled in xine config) (a/52 and DTS pass-through not enabled in xine config) audio_out: thread created xine_stream_new video_out: thread created audio_out: thread created xine_interface: unknown or deprecated stream param 10 set xine_stream_new xine_interface: unknown or deprecated stream param 10 set xine_stream_new xine_interface: unknown or deprecated stream param 10 set video_out_xshm: aspect ratio changed to 16:9 video_out_xshm: tried to get unsupported property 2 video_out_xshm: tried to set unsupported property 2 video_out_xshm: tried to get unsupported property 2 gui_xine_open_and_play(): mrl: 'vdr://tmp/vdr-xine/stream#demux:mpeg_pes', sub 'NONE', start_pos 0, start_time 0, av_offset 0, spu_offset 0. xine: found input plugin : VDR display device plugin xine: found demuxer plugin: mpeg pes demux plugin video discontinuity #1, type is 0, disc_off 0 waiting for audio discontinuity #1 audio discontinuity #1, type is 0, disc_off 0 waiting for in_discontinuity update #1 vpts adjusted with prebuffer to 38099 av_offset=0 pts spu_offset=0 pts xine_play play_internal ...done ratio: 0 prebuffer=0 pts +++ CLEAR(-1a) ao_flush (loop running: 1) === CLEAR(-1.1) video discontinuity #2, type is 0, disc_off 0 waiting for audio discontinuity #2 audio discontinuity #2, type is 0, disc_off 0 waiting for in_discontinuity update #2 vpts adjusted with prebuffer to 26139 === CLEAR(-1.2) === CLEAR(-1.3) === CLEAR(-1.4) === CLEAR(-1.5) --- CLEAR(-1a) +++ CLEAR(-1b) ao_flush (loop running: 1) === CLEAR(-1.1) video discontinuity #3, type is 0, disc_off 0 waiting for audio discontinuity #3 audio discontinuity #3, type is 0, disc_off 0 waiting for in_discontinuity update #3 vpts adjusted with prebuffer to 26166 === CLEAR(-1.2) === CLEAR(-1.3) === CLEAR(-1.4) === CLEAR(-1.5) --- CLEAR(-1b) video_out_xshm: tried to set unsupported property 0 load_plugins: plugin mpeg2 will be used for video streamtype 00. video_out_xshm: tried to set unsupported property 0 vdr_video: osd: (0, 0)-(720, 576)@1.33333 video_out_xshm: tried to get unsupported property 8 video_out_xshm: tried to get unsupported property 13 ratio: 13333 video_out_xshm: tried to set unsupported property 8 video_out_xshm: tried to set unsupported property 13 vdr: flush: n: 77, 941.1 input_vdr: flush buffers (vb: 0, ab: 0, vf: 0, af: 0) done. +++ CLEAR(-5a) ao_flush (loop running: 1) === CLEAR(-5.1) === CLEAR(-5.2) === CLEAR(-5.3) === CLEAR(-5.4) === CLEAR(-5.5) --- CLEAR(-5a) video_out_xshm: tried to set unsupported property 0 video discontinuity #4, type is 0, disc_off 0 waiting for audio discontinuity #4 audio discontinuity #4, type is 0, disc_off 0 waiting for in_discontinuity update #4 vpts adjusted with prebuffer to 113685 ao_flush (loop running: 1) === CLEAR(-5.1) === CLEAR(-5.2) === CLEAR(-5.3) === CLEAR(-5.4) === CLEAR(-5.5) --- CLEAR(-5b) video discontinuity #5, type is 0, disc_off 0 waiting for audio discontinuity #5 audio discontinuity #5, type is 0, disc_off 0 waiting for in_discontinuity update #5 vpts adjusted with prebuffer to 113716 set_speed 125000 video_out_xshm: tried to set unsupported property 0 load_plugins: plugin mpeg2 will be used for video streamtype 00. video discontinuity #6, type is 2, disc_off 7837506763 waiting for audio discontinuity #6 load_plugins: plugin mad will be used for audio streamtype 01. upmix_mono: upmixing a single channel from original 2 channels stream. audio_alsa_out:open pause_resume=0 output sample rate 48000 audio discontinuity #6, type is 2, disc_off 7837506763 waiting for in_discontinuity update #6 video vpts adjusted to audio vpts 115876 audio jump, diff=0 video_out_xshm: tried to set unsupported property 0 video discontinuity #7, type is 0, disc_off 0 waiting for audio discontinuity #7 ao_close audio_out: no streams left, closing driver audio discontinuity #7, type is 0, disc_off 0 waiting for in_discontinuity update #7 vpts adjusted with prebuffer to 118377 video discontinuity #8, type is 2, disc_off 7837566420 waiting for audio discontinuity #8 audio discontinuity #8, type is 2, disc_off 7837566420 waiting for in_discontinuity update #8 vpts adjusted with prebuffer to 118378 load_plugins: plugin ffmpegvideo will be used for video streamtype 4d. load_plugins: plugin mad will be used for audio streamtype 01. upmix_mono: upmixing a single channel from original 2 channels stream. video_out_xshm: tried to set unsupported property 0 [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]no frame! ffmpeg_video_dec: error decompressing frame vdr_video: osd: (0, 0)-(1, 1)@1 video_out_xshm: tried to get unsupported property 8 [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error ratio: 10000 [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]no frame! ffmpeg_video_dec: error decompressing frame [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]no frame! ffmpeg_video_dec: error decompressing frame [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]no frame! ffmpeg_video_dec: error decompressing frame [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]non existing PPS referenced [h264 @ 0x2aaaace75800]decode_slice_header error [h264 @ 0x2aaaace75800]no frame! ffmpeg_video_dec: error decompressing frame audio_alsa_out:open pause_resume=0 output sample rate 48000 audio jump, diff=51017 ffmpeg_video_dec: increasing buffer to 198787 to avoid overflow. vdr_video: osd: (0, 0)-(1440, 1080)@1.77778 video jump video_out_xshm: tried to get unsupported property 8 video_out_xshm: tried to get unsupported property 13 ratio: 17778 video_out_xshm: tried to set unsupported property 8 video_out_xshm: tried to set unsupported property 13 set_speed 1000000 video_out: throwing away image with pts 166092 because it's too old (diff : 1845). video jump video_out: throwing away image with pts 375881 because it's too old (diff : 4107). video_out: throwing away image with pts 379057 because it's too old (diff : 4171). video_out: throwing away image with pts 384743 because it's too old (diff : 5685). video_out: throwing away image with pts 390877 because it's too old (diff : 10351). video_out: throwing away image with pts 393793 because it's too old (diff : 9596). video jump video_out: throwing away image with pts 400041 because it's too old (diff : 14510). video_out: throwing away image with pts 501830 because it's too old (diff : 4525). video_out: throwing away image with pts 507368 because it's too old (diff : 6187). video_out: throwing away image with pts 513026 because it's too old (diff : 11330). video_out: throwing away image with pts 515711 because it's too old (diff : 9724). video_out: throwing away image with pts 521531 because it's too old (diff : 14705). video_out: throwing away image with pts 524292 because it's too old (diff : 11944). video_out: throwing away image with pts 530257 because it's too old (diff : 16779). video_out: throwing away image with pts 535943 because it's too old (diff : 16134). video_out: throwing away image with pts 539184 because it's too old (diff : 16133). video_out: throwing away image with pts 544993 because it's too old (diff : 17164). video_out: throwing away image with pts 548292 because it's too old (diff : 21065). video jump video_out: throwing away image with pts 605648 because it's too old (diff : 2952). video_out: throwing away image with pts 609337 because it's too old (diff : 1785). video_out: throwing away image with pts 640296 because it's too old (diff : 4307). video_out: throwing away image with pts 642698 because it's too old (diff : 5144). video_out: throwing away image with pts 647981 because it's too old (diff : 9222). video_out: throwing away image with pts 653030 because it's too old (diff : 10293). video_out: throwing away image with pts 655968 because it's too old (diff : 10595). video_out: throwing away image with pts 661201 because it's too old (diff : 12563). video_out: throwing away image with pts 664226 because it's too old (diff : 16738). video_out: throwing away image with pts 669626 because it's too old (diff : 15298). video_out: throwing away image with pts 672731 because it's too old (diff : 15441). set_speed 0 audio_alsa_out: Drain call failed. (err=-11:Resource temporarily unavailable) set_speed 1000000 audio_out: inserting 17006 0-frames to fill a gap of 31895 pts video_out: throwing away image with pts 678281 because it's too old (diff : 19202). video_out: throwing away image with pts 681457 because it's too old (diff : 18186). video_out: throwing away image with pts 687143 because it's too old (diff : 20781). video_out: throwing away image with pts 690384 because it's too old (diff : 23300). video_out: throwing away image with pts 696193 because it's too old (diff : 23251). video_out: throwing away image with pts 702441 because it's too old (diff : 26723). video jump 200 frames delivered, 8 frames skipped, 35 frames discarded video_out: throwing away image with pts 777163 because it's too old (diff : 2765). video_out: throwing away image with pts 781531 because it's too old (diff : 6317). video_out: throwing away image with pts 786432 because it's too old (diff : 9696). video_out: throwing away image with pts 788763 because it's too old (diff : 12405). video_out: throwing away image with pts 793898 because it's too old (diff : 12310). video_out: throwing away image with pts 799181 because it's too old (diff : 14948). video_out: throwing away image with pts 801687 because it's too old (diff : 17842). video_out: throwing away image with pts 807168 because it's too old (diff : 18121). video_out: throwing away image with pts 809768 because it's too old (diff : 20922). video_out: throwing away image with pts 815426 because it's too old (diff : 21024). video_out: throwing away image with pts 818111 because it's too old (diff : 23739). video_out: throwing away image with pts 823931 because it's too old (diff : 26920). video_out: throwing away image with pts 829481 because it's too old (diff : 27130). video_out: throwing away image with pts 832657 because it's too old (diff : 29715). video_out: throwing away image with pts 838343 because it's too old (diff : 29789). video_out: throwing away image with pts 844477 because it's too old (diff : 33015). video_out: throwing away image with pts 847393 because it's too old (diff : 32259). video_out: throwing away image with pts 853641 because it's too old (diff : 35731). video jump video_out: throwing away image with pts 915668 because it's too old (diff : 2146). video_out: throwing away image with pts 919452 because it's too old (diff : 6282). video_out: throwing away image with pts 921789 because it's too old (diff : 8986). video_out: throwing away image with pts 925880 because it's too old (diff : 10295). video_out: throwing away image with pts 928363 because it's too old (diff : 12854). video_out: throwing away image with pts 932731 because it's too old (diff : 13525). video_out: throwing away image with pts 935345 because it's too old (diff : 16313). video_out: throwing away image with pts 939963 because it's too old (diff : 17453). video_out: throwing away image with pts 945098 because it's too old (diff : 20599). video_out: throwing away image with pts 947540 because it's too old (diff : 23198). video_out: throwing away image with pts 952887 because it's too old (diff : 26131). video_out: throwing away image with pts 955430 because it's too old (diff : 28988). video_out: throwing away image with pts 960968 because it's too old (diff : 27770). video_out: throwing away image with pts 963601 because it's too old (diff : 30538). input_vdr: execution of rpc command 15 () failed, exiting ... input_vdr: rpc thread done. video_out: throwing away image with pts 969311 because it's too old (diff : 30588). video_out: throwing away image with pts 972026 because it's too old (diff : 33273). video_out: throwing away image with pts 975131 because it's too old (diff : 32329). video_out: throwing away image with pts 977892 because it's too old (diff : 34968). video_out: throwing away image with pts 980681 because it's too old (diff : 33618). [h264 @ 0x2aaaace75800]concealing 5040 DC, 5040 AC, 5040 MV errors video_out: throwing away image with pts 983857 because it's too old (diff : 36202). video_out: throwing away image with pts 986687 because it's too old (diff : 34094). ffmpeg_video_dec: error decompressing frame ffmpeg_video_dec: error decompressing frame ffmpeg_video_dec: error decompressing frame ffmpeg_video_dec: error decompressing frame
I don't get video jumping on MPEG 2 pictures, but I do get the video_out "too old" messages.
When the video jumps, the whole of VDR seems to lock up, i.e. you can't move the menu selection on the OSD until the video restarts.
Any ideas - or am I hitting some kind of hardware bottleneck here (dual core 2.13Ghz, 2Gb RAM, IDE disk, NVIDIA 6200LE PCIe graphics @ 720p)? Both cores are idle @ around 40%: -
top - 12:17:39 up 1:10, 4 users, load average: 3.07, 3.31, 3.03 Tasks: 138 total, 2 running, 136 sleeping, 0 stopped, 0 zombie Cpu0 : 29.3%us, 1.7%sy, 0.0%ni, 67.3%id, 0.0%wa, 1.0%hi, 0.7%si, 0.0%st Cpu1 : 46.7%us, 0.3%sy, 0.0%ni, 53.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2063240k total, 1537516k used, 525724k free, 593748k buffers Swap: 1100412k total, 0k used, 1100412k free, 494464k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8565 root 15 0 517m 120m 53m S 69 6.0 32:45.80 xine 8081 root 15 0 155m 82m 55m R 8 4.1 3:18.08 Xorg 7607 root 15 0 215m 30m 3856 S 2 1.5 0:36.89 vdr
top - 12:18:29 up 1:11, 4 users, load average: 3.04, 3.28, 3.03 Tasks: 138 total, 3 running, 135 sleeping, 0 stopped, 0 zombie Cpu0 : 80.3%us, 1.0%sy, 0.0%ni, 17.7%id, 0.0%wa, 0.7%hi, 0.3%si, 0.0%st Cpu1 : 66.2%us, 1.0%sy, 0.0%ni, 32.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2063240k total, 1537640k used, 525600k free, 593820k buffers Swap: 1100412k total, 0k used, 1100412k free, 494472k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8565 root 15 0 517m 120m 53m R 140 6.0 33:50.91 xine 8081 root 15 0 155m 82m 55m S 8 4.1 3:21.94 Xorg 7607 root 15 0 215m 30m 3856 S 1 1.5 0:37.70 vdr
HD recordings also show the same symptoms. If you are interested I am currently uploading a minute of BBC HD recording (140Mb)
Regards,
Morfsta
On 10/24/07, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Morfsta schrieb:
The picture was very good, but there was dropped frames that xine reported and the stuttered on occassion and then ran very quickly to catch up. Playing around with the settings in xine (setting threads to 2 etc) didn't really make much difference. However, for the first time I've spent playing with this I was impressed with the picture quality out of VDR. Top reported that the CPU was ~40% idle so I don't know why I saw dropped frames...
Frame duration wasn't set at all in xine-lib for this case. xine-lib-1.2 contains now a fix for this issue. The fix is part of vdr-xine-0.8.0's xine-lib.patch for xine-lib-1.1.8, too.
One other thing I noticed though was when using XVMC (-V xxmc) to view normal MPEG2 channels the VDR OSD looked terrible (very blockly looking) and playing with the settings in the xine plugin did not make it better. Any recommendations on improving this? When using MPEG4 (i.e. software accel) the OSD was fine.
xxmc's OSD support allows only 16 colors. I assume, you've enabled font antialiasing in VDR, which requires much more than 16 colors. This is the case for hardware accelerated MPEG2 decoding. For H.264, xxmc falls back to xv where there is no such limitation.
You may also want to try to choose unscaled OSD in vdr-xine's setup menu, which renders the OSD on top of the video image, using libX11. It is therefore not limited to 16 colors but doesn't support OSD transparency at all.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Morfsta schrieb:
I have just tried it on BBC HD (Astra 2 - H264/MBAFF) as well as HD2/5 (Astra 3 H264/???) and I get video jumping every 2 seconds. Here is the [clipped] output from xine (verbose=3): -
video_out_xshm: video mode depth is 24 (32 bpp), TrueColor, not swapped,
Is there a special reason why you use -V xshm and not -V xv? The later would do colorspace transformation in hardware.
HD recordings also show the same symptoms. If you are interested I am currently uploading a minute of BBC HD recording (140Mb)
Please provide a link to this recording.
Bye.
On 10/25/07, Reinhard Nissl rnissl@gmx.de wrote:
Is there a special reason why you use -V xshm and not -V xv? The later would do colorspace transformation in hardware.
I was just changing settings - I did have xxmc on, but it didn't make any difference.
HD recordings also show the same symptoms. If you are interested I am currently uploading a minute of BBC HD recording (140Mb)
Please provide a link to this recording.
Try here: -
http://www.megaupload.com/?d=55JZHZ4A
Thanks.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
Morfsta schrieb:
HD recordings also show the same symptoms. If you are interested I am currently uploading a minute of BBC HD recording (140Mb)
Please provide a link to this recording.
Try here: -
Please give the patch on the below mentioned site a try. Your recording (which uses only interlaced frames) plays properly here when I play it at 50 % of normal speed (my PC simply isn't fast enough for realtime decoding).
http://www.vdr-portal.de/board/thread.php?postid=662944#post662944
Bye.
On 10/25/07, Reinhard Nissl rnissl@gmx.de wrote:
Please give the patch on the below mentioned site a try. Your recording (which uses only interlaced frames) plays properly here when I play it at 50 % of normal speed (my PC simply isn't fast enough for realtime decoding).
http://www.vdr-portal.de/board/thread.php?postid=662944#post662944
That has fixed it - BBC HD and HD2/5 (Astra 3) are now playing smoothly! It is so much better!
Now I have noticed another problem - there is a strange "fuzz" effect (like tearing, but not exactly the same) on some broadcasts and not on others. At first I thought it was the graphics setup on fast panning, but this is not the case - it affects static images also. I saw this on BBC HD and HD2/5. I managed to capture a snippet of the BBC HD preview that demonstrates this - it's very strange because clips before and after this preview snippet were fine again so it must be something to do with this particular HD recording as part of the preview...
Here is a link to a short recording (26Mb) demonstrating the problem: -
http://www.megaupload.com/?d=72LCAI2P
Regards,
Morfsta
Hi,
Morfsta schrieb:
Now I have noticed another problem - there is a strange "fuzz" effect (like tearing, but not exactly the same) on some broadcasts and not on others. At first I thought it was the graphics setup on fast panning, but this is not the case - it affects static images also. I saw this on BBC HD and HD2/5. I managed to capture a snippet of the BBC HD preview that demonstrates this - it's very strange because clips before and after this preview snippet were fine again so it must be something to do with this particular HD recording as part of the preview...
Here is a link to a short recording (26Mb) demonstrating the problem: -
Please have a look at the patches referenced at http://www.vdr-portal.de/board/thread.php?postid=664938#post664938
With theses patches, your recording looks much better.
Bye.
On Oct 31, 2007 11:51 PM, Reinhard Nissl rnissl@gmx.de wrote:
Please have a look at the patches referenced at http://www.vdr-portal.de/board/thread.php?postid=664938#post664938
With theses patches, your recording looks much better.
Thanks for your help and assistance Reinhard - I read the thread on gmane.comp.video.ffmpeg.devel with interest.
I patched ffmpeg and did a make && make install and the recording is still the same on my system. Do I have to re-compile xine-lib?
Hi,
Morfsta schrieb:
I patched ffmpeg and did a make && make install and the recording is still the same on my system. Do I have to re-compile xine-lib?
Sure, because you need the fixes in xine-lib's FFmpeg interfacing file ff_video_decoder.c, too.
And you'll have to specify a deinterlacer as mentioned on the vdr-portal page.
Bye.
On 01/11/2007, Reinhard Nissl rnissl@gmx.de wrote:
Hello :-)
Please have a look at the patches referenced at http://www.vdr-portal.de/board/thread.php?postid=664938#post664938
With theses patches, your recording looks much better.
I have recompiled ffmpeg svn with this patch, and xine-lib-1.2 (there semmes to be included) and also my vdr which now segfault when I try to tune to BBC HD :
gdb ./vdr GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -u greg -c /etc/vdr -l 3 -s 'sudo /usr/local/bin/vdrpoweroff.sh' -P'xine -r' Starting program: /usr/src/vdr-1.5.10/vdr -u greg -c /etc/vdr -l 3 -s 'sudo /usr/local/bin/vdrpoweroff.sh' +-P'xine -r' warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff3effd000 ------------------------- MakePrimaryDevice: 1 ========================= SetVideoFormat: 1 SetVolumeDevice: 255 frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00) SetVideoWindow: 0, 0, 720, 576, 720, 576 SetVolumeDevice: 255 SetAudioChannelDevice: 0 SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00) SetPlayMode: 1 video: synced early [VM] vdr-xine: Client connecting ... vdr-xine: Client connected! frame: (0, 0)-(720, 576), zoom: (1.00, 1.00) [vVMA]buffered 20.4 frames (v:28.7, a:20.4) frame: (0, 0)-(720, 576), zoom: (1.00, 1.00) SetPlayMode: 0 frame: (0, 0)-(720, 576), zoom: (1.00, 1.00) SetAudioChannelDevice: 0 SetDigitalAudioDevice: 1 SetAudioChannelDevice: 0 SetPlayMode: 1 audio: synced early [AMMVframe: (0, 0)-(16, 32), zoom: (1.00, 1.00) [New LWP 31657]
Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 31657] 0x00002b0f6c5e47f1 in PluginXine::cXineLib::execFuncOsdDrawBitmap (this=0x2aaaaea15d98, needsScaling=PluginXine::cXineLib::shq, videoWidth=16, videoHeight=29, xineOsd=<value optimized out>, window=0, bitmap=0x2aaaaeb355f0, x=0, y=0, width=672, height=187, stride=672) at xineLib.c:1010 1010 *c++ = delinearize(c2 / sai) / FIX_POINT_FACTOR; Current language: auto; currently c++ (gdb) bt #0 0x00002b0f6c5e47f1 in PluginXine::cXineLib::execFuncOsdDrawBitmap (this=0x2aaaaea15d98, needsScaling=PluginXine::cXineLib::shq, videoWidth=16, videoHeight=29, xineOsd=<value optimized out>, window=0, bitmap=0x2aaaaeb355f0, x=0, y=0, width=672, height=187, stride=672) at xineLib.c:1010 #1 0x00002b0f6c5e59bd in PluginXine::cXineLib::sendWindow (this=0x2aaaaea15d98, xineOsd=0x2aaaaeb35520, windowNum=0, bitmap=0x2aaaaeb355f0, videoLeft=0, videoTop=0, videoWidth=16, videoHeight=32, videoZoomX=100, videoZoomY=100, dontOptimize=false) at xineLib.c:1867 #2 0x00002b0f6c5e6fcb in PluginXine::cXineOsd::ReshowCurrentOsd (this=0x2aaaaeb35520, dontOptimize=false, frameLeft=<value optimized out>, frameTop=<value optimized out>, frameWidth=<value optimized out>, frameHeight=<value optimized out>, frameZoomX=100, frameZoomY=100) at xineOsd.c:136 #3 0x00002b0f6c5dae25 in PluginXine::cXineDevice::reshowCurrentOsd (this=0x2aaaaea14ad0, dontOptimize=64, frameLeft=0, frameTop=0, frameWidth=16, frameHeight=32, frameZoomX=100, frameZoomY=100) at xineDevice.c:3642 #4 0x00002b0f6c5dae81 in PluginXine::cXineDevice::ReshowCurrentOSD (this=0x5580, frameLeft=1820500048, frameTop=2880, frameWidth=66187264, frameHeight=518684672, frameZoomX=<value optimized out>, frameZoomY=100) at xineDevice.c:3739 #5 0x00002b0f6c5e97ea in PluginXine::cXineRemote::Action (this=0x2aaaaea147f0) at xineRemote.c:135 #6 0x00000000004bffc5 in cThread::StartThread (Thread=0x2aaaaea14810) at thread.c:244 #7 0x0000003054406597 in ?? () from /lib/libpthread.so.0 #8 0x0000003053cd406d in clone () from /lib/libc.so.6 #9 0x0000000000000000 in ?? ()
That's with OSD display mode : Blend scaled Auto, with X11 overlay it don't crash (but that's not nice at all...).
By the way there is another annoying bug with xine-lib : if you have a timer set, and VDR want to powerdown, but it can't die to some external reason, you can't control it anymore :
#0 0x000000305440deef in waitpid () from /lib/libpthread.so.0 #1 0x00000000004bfb82 in SystemExec ( Command=0x2aaaae9ee0c0 "sudo /usr/local/bin/vdrpoweroff.sh 1194037200 121229 317 "C'EST PAS SORCIER" 1", Detached=true) at thread.c:511 #2 0x00000000004ad2df in cShutdownHandler::CallShutdownCommand (this=0x7275c0, WakeupTime=1194037200, Channel=317, File=0xfecdec "C'EST PAS SORCIER", UserShutdown=<value optimized out>) at shutdown.c:129 #3 0x00000000004ad8ac in cShutdownHandler::DoShutdown (this=0x7275c0, Force=false) at shutdown.c:247 #4 0x00000000004c962b in main (argc=14, argv=0x7fffcd756e48) at vdr.c:1062
Maybe the bug don't come from xine-lib directly, but without xine-lib it doesn't appear.
Thank,
Hi,
Grégoire FAVRE schrieb:
I have recompiled ffmpeg svn with this patch, and xine-lib-1.2 (there semmes to be included) and also my vdr which now segfault when I try to tune to BBC HD :
[snip]
That's with OSD display mode : Blend scaled Auto, with X11 overlay it don't crash (but that's not nice at all...).
Please have a look at
http://www.vdr-portal.de/board/thread.php?postid=665758#post665758
The new libxine patch should fix this bug.
By the way there is another annoying bug with xine-lib : if you have a timer set, and VDR want to powerdown, but it can't die to some external reason, you can't control it anymore :
#0 0x000000305440deef in waitpid () from /lib/libpthread.so.0 #1 0x00000000004bfb82 in SystemExec ( Command=0x2aaaae9ee0c0 "sudo /usr/local/bin/vdrpoweroff.sh 1194037200 121229 317 "C'EST PAS SORCIER" 1", Detached=true) at thread.c:511 #2 0x00000000004ad2df in cShutdownHandler::CallShutdownCommand (this=0x7275c0, WakeupTime=1194037200, Channel=317, File=0xfecdec "C'EST PAS SORCIER", UserShutdown=<value optimized out>) at shutdown.c:129 #3 0x00000000004ad8ac in cShutdownHandler::DoShutdown (this=0x7275c0, Force=false) at shutdown.c:247 #4 0x00000000004c962b in main (argc=14, argv=0x7fffcd756e48) at vdr.c:1062
Maybe the bug don't come from xine-lib directly, but without xine-lib it doesn't appear.
Maybe I'll have a look at it tomorrow.
Meanwhile, you could have a look at this issue with this gdb command:
thread apply all bt
It'll tell you the backtrace for all threads.
Bye.
On Sat, Nov 03, 2007 at 10:24:33PM +0100, Reinhard Nissl wrote:
Hello :-)
Please have a look at
http://www.vdr-portal.de/board/thread.php?postid=665758#post665758
The new libxine patch should fix this bug.
Great, thank !
Maybe I'll have a look at it tomorrow.
Meanwhile, you could have a look at this issue with this gdb command:
thread apply all bt
It'll tell you the backtrace for all threads.
Oops, with the new patched ffmpeg/xine-lib-1.2/vdr-xine it don't segfault (but I still can't access my VDR after a "shutdown try".
Thank you very much :-)
Hi reinhard,
Is this patch only for (new) radio-recordings???
I tried it but sometimes I am getting a seeg fault when trying to play old recordings. My client vdr is a vdr-1.4.7 with softdevice. Thanks. Halim