Hello.
Looks like this isn't strictly speaking VDR problem, since it appears to be a problem with Xine, but I'm wondering if anyone is using a similar setup in the first place and would've found a solution...
To make it short, I'm using VDR bundle from e-tobi.net (1.6.0-16ctvdr2), running on 64-bit Debian Unstable. Output is done with xineliboutput plugin (1.0.6+cvs20100308.2219-1), and the image is spewed into CRT television through network using another machine - Debian Unstable, 32-bit x86. The output itself is done with xineliboutput-fbfe (1.0.6+cvs20100308.2219-1) using Matrox G450.
Everything with 704x576 (and presumably 720x576) resolution works, but unfortunately some channels send other resolutions, such as 528x576. This results with a simple failure with error message in kern.log: vdr-fbfe[5429] general protection ip:af24feb1 sp:ad8c5f90 error:0 in xineplug_post_swscale.so[af24f000+4000]
So, nothing that requires scaling, works.
libxine1 pacakge is version 1.1.18.1-1+b2, same goes for libxine1-ffmpeg, libavcodec52 is version 5:0.5.1+svn20100411-0.0, libavutil49 4:0.5.1-3, libpostproc51 5:0.5.1+svn20100411-0.0.
Any idea what might cause this kind of behavior?
I demand that Sami Sundell may or may not have written...
[snip; output via Matrox G450]
Everything with 704x576 (and presumably 720x576) resolution works, but unfortunately some channels send other resolutions, such as 528x576.
528 I've not seen. 544 I have...
This results with a simple failure with error message in kern.log: vdr-fbfe[5429] general protection ip:af24feb1 sp:ad8c5f90 error:0 in xineplug_post_swscale.so[af24f000+4000]
So, nothing that requires scaling, works.
Hmm? They all require scaling to 768×576 or 1024×576 (if the display mode in use has square pixels).
libxine1 pacakge is version 1.1.18.1-1+b2, same goes for libxine1-ffmpeg, libavcodec52 is version 5:0.5.1+svn20100411-0.0, libavutil49 4:0.5.1-3, libpostproc51 5:0.5.1+svn20100411-0.0.
Any idea what might cause this kind of behavior?
Install the -dbg package. Get a backtrace. You might also want to print (at least) local variables.
Or (possibly better) provide a short sample.
Either way, I think that the scaler configuration is also needed.
Hello, and thanks for answering.
[snip; output via Matrox G450]
Everything with 704x576 (and presumably 720x576) resolution works, but unfortunately some channels send other resolutions, such as 528x576.
528 I've not seen. 544 I have...
Yup. National Geographic seems to be fond of 544, Extreme Sports sends 528 at the moment. Neither one works.
Hmm? They all require scaling to 768×576 or 1024×576 (if the display mode in use has square pixels).
It doesn't, display mode is 720x576 - output is to CRT tube via S-video, and that particular resolution has been pretty much the only one I got working with G450 and DirectFB. If anyone has working configuration for that one, I'm all ears 8)
Install the -dbg package. Get a backtrace. You might also want to print (at least) local variables.
I'm pretty much a n00b when it comes to debugging linux programs, so I might not get all the info at once, please bear with me :P
Short log and backtrace:
post_warp: detected frame format change: 0x0 -> 544x576, interlaced 0->1, aspect 0,000->1,333, yuy2->yv12 post_warp: aspect ratio matches, no warp post_warp: factor_x = 1,000 factor_y = 1,000 output ratio = 1,333 post_warp: init_yv12: 544x576->720x576 hWarp 1,000 vWarp 1,000
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xae4ffb70 (LWP 3268)] 0xaf2f2eb1 in ?? () from /usr/lib/xine/plugins/1.28/post/xineplug_post_swscale.so (gdb) backtrace full #0 0xaf2f2eb1 in ?? () from /usr/lib/xine/plugins/1.28/post/xineplug_post_swscale.so No symbol table info available. #1 0xaf2f4434 in ?? () from /usr/lib/xine/plugins/1.28/post/xineplug_post_swscale.so No symbol table info available. #2 0xaf2f96bc in parse_chunk (mpeg2dec=0x87bfb20, current=0x8744c80 '\020' <repeats 200 times>..., end=0xb24ad00d "", pts=0) at decode.c:291 picture = 0x8728520 is_frame_done = 189779 ratio = -nan(0x8101010101010) #3 mpeg2_decode_data (mpeg2dec=0x87bfb20, current=0x8744c80 '\020' <repeats 200 times>..., end=0xb24ad00d "", pts=0) at decode.c:723 ret = 58657919 code = 8 '\b' #4 0xaf30eeb4 in mpeg2dec_decode_data (this_gen=0xb7fa11dd, buf=0x80cb5d0) at xine_mpeg2_decoder.c:81 No locals. #5 0x0861ba60 in ?? () No symbol table info available. Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb)
Apparently there's no -dbg package available for xineliboutput-fbfe.
Or (possibly better) provide a short sample.
I guess that can be arranged. Just cutting a piece of vdr recording will suffice?
Either way, I think that the scaler configuration is also needed.
If I had an idea where to get it, I'd be happy to provide it. 8) config_xineliboutput has pretty much everything video related commented out, that is, using defaults.
Sami Sundell wrote:
To make it short, I'm using VDR bundle from e-tobi.net (1.6.0-16ctvdr2), running on 64-bit Debian Unstable. Output is done with xineliboutput plugin (1.0.6+cvs20100308.2219-1), and the image is spewed into CRT television through network using another machine - Debian Unstable, 32-bit x86. The output itself is done with xineliboutput-fbfe (1.0.6+cvs20100308.2219-1) using Matrox G450.
Everything with 704x576 (and presumably 720x576) resolution works, but unfortunately some channels send other resolutions, such as 528x576. This results with a simple failure with error message in kern.log: vdr-fbfe[5429] general protection ip:af24feb1 sp:ad8c5f90 error:0 in xineplug_post_swscale.so[af24f000+4000]
So, nothing that requires scaling, works.
libxine1 pacakge is version 1.1.18.1-1+b2, same goes for libxine1-ffmpeg, libavcodec52 is version 5:0.5.1+svn20100411-0.0, libavutil49 4:0.5.1-3, libpostproc51 5:0.5.1+svn20100411-0.0.
Any idea what might cause this kind of behavior?
Maybe you're seeing the same problem as in the following bug report: https://sourceforge.net/tracker/?func=detail&atid=814342&aid=2952110...
- Petri