Hi,
I am currently using VDR with a Nexus-S FF card in an NTSC environment. For a long time, I could never get the correct tv standard (NTSC) while trying to watch television via VDRAdmin. I recently noticed that once I stream VDR using VLC and its v4l interface, something in /dev/video0 gets set to NTSC, because from then on, the video is correctly set to NTSC mode and I can watch television via the VDRAdmin television interface. Here is the VLC command I'm using:
vlc -vvv v4l:/dev/video0:adev=/dev/dsp:audio=1:norm=ntsc:size=352x240 --sout '#transcode{vcodec=DIV3,vb=64,acodec=mp3,ab=48,deinterlace}:std{access=http,mux=asf,dst=:6789}'
Notice how VLC is directly interacting with the video from /dev/video0 (this method only works with FF cards). Somehow, the v4l interface from VLC is setting the tv standard properly for /dev/video0 and fixing VDRAdmin for NTSC. Anyone have an idea whats going on? The firmware is set to NTSC as soon as the card tunes to a NTSC channel. Why would /dev/video0 not be set to NTSC until I stream it with VLC?
Best Regards.
Stone wrote:
Hi,
I am currently using VDR with a Nexus-S FF card in an NTSC environment. For a long time, I could never get the correct tv standard (NTSC) while trying to watch television via VDRAdmin. I recently noticed that once I stream VDR using VLC and its v4l interface, something in /dev/video0 gets set to NTSC, because from then on, the video is correctly set to NTSC mode and I can watch television via the VDRAdmin television interface.
Basically there are two ways to select NTSC mode: - v4lctl setnorm NTSC - module parameter 'tv_standard' for dvb-ttpci
modinfo dvb-ttpci: ... parmtype: tv_standard:int parm: tv_standard:TV standard: 0 PAL (default), 1 NTSC ...
Oliver
On 6/7/07, Oliver Endriss o.endriss@gmx.de wrote:
Stone wrote:
Hi,
I am currently using VDR with a Nexus-S FF card in an NTSC environment.
For
a long time, I could never get the correct tv standard (NTSC) while
trying
to watch television via VDRAdmin. I recently noticed that once I stream
VDR
using VLC and its v4l interface, something in /dev/video0 gets set to
NTSC,
because from then on, the video is correctly set to NTSC mode and I can watch television via the VDRAdmin television interface.
Basically there are two ways to select NTSC mode:
- v4lctl setnorm NTSC
- module parameter 'tv_standard' for dvb-ttpci
modinfo dvb-ttpci: ... parmtype: tv_standard:int parm: tv_standard:TV standard: 0 PAL (default), 1 NTSC
Yes, I use the tv_standard option when modprobing the drivers as follows:
alias /dev/dvb/* /dev/dvb alias char-major-212-* dvb-ttpci options dvb-core dvb_shutdown_timeout=0 options dvb-ttpci tv_standard=1
But, this seems to make no difference when VDRAdmin tells VDR to "grab" the picture. Basically VDRAdmin uses VDR's SVDRP interface to "grab" a frame and send it over http. Prior to streaming VDR with VLC, VDR's grab still gets the frames in PAL mode for some reason. VLC's v4l module is doing something in addition to switching the driver in NTSC mode with modprobe options. Also, this is only a problem with FF ttpci cards.
Best Regards.
R
But, this seems to make no difference when VDRAdmin tells VDR to "grab" the picture.
To summarize, when I stream /dev/video0 with VLC, it seems like VLC's v4l module is setting the resolution in the driver to something other than PAL because now for the first time ever, I can use VDR's grab command with a FF card, in NTSC mode, and not have the picture look like the horizontal is all offset. The image does not have horizontal lines in it now. This has always been a problem with FF cards, NTSC, and VDR's grab command.
Best Regards.
Basically there are two ways to select NTSC mode:
- v4lctl setnorm NTSC
- module parameter 'tv_standard' for dvb-ttpci
modinfo dvb-ttpci: ... parmtype: tv_standard:int parm: tv_standard:TV standard: 0 PAL (default), 1 NTSC ...
When tv_standard=1 is used, why does VDR still startup with these PAL resolutions:
vdr: [7841] starting plugin: screenshot vdr: [7841] grabbing to PNM 100 768 576 vdr: [7841] grabbed image to /dev/null
And after I run VLC, I get these new resolutions:
vdr: [7841] connect from 127.0.0.1, port 49972 - accepted vdr: [7841] grabbing to JPEG 70 384 288
Can I hardcode the default resolution from within VDR or the kernel driver? Best Regards.
Stone wrote:
Basically there are two ways to select NTSC mode:
- v4lctl setnorm NTSC
- module parameter 'tv_standard' for dvb-ttpci
modinfo dvb-ttpci: ... parmtype: tv_standard:int parm: tv_standard:TV standard: 0 PAL (default), 1 NTSC ...
When tv_standard=1 is used, why does VDR still startup with these PAL resolutions:
vdr: [7841] starting plugin: screenshot vdr: [7841] grabbing to PNM 100 768 576 vdr: [7841] grabbed image to /dev/null
And after I run VLC, I get these new resolutions:
vdr: [7841] connect from 127.0.0.1, port 49972 - accepted vdr: [7841] grabbing to JPEG 70 384 288
Can I hardcode the default resolution from within VDR or the kernel driver? Best Regards.
Does it work if you use the v4lctl method?
Are there any FTA NTSC transmissions on Astra 19.2° or Eutelsat 13°? I'd like to do some tests...
Oliver
vdr: [7841] connect from 127.0.0.1, port 49972 - accepted vdr: [7841] grabbing to JPEG 70 384 288
Can I hardcode the default resolution from within VDR or the kernel
driver?
Best Regards.
Does it work if you use the v4lctl method?
Are there any FTA NTSC transmissions on Astra 19.2° or Eutelsat 13°? I'd like to do some tests...
I have not been able to test the v4lctl method since I do not have X on the machine. Does v4lctl require xawtv? I suppose I could try and install X but I would rather not if possible. Also, I'm not sure about Astra or Eutelsat since my dish is in America.
Best Regards.
On 6/30/07, Stone syphyr@gmail.com wrote:
vdr: [7841] connect from 127.0.0.1, port 49972 - accepted vdr: [7841] grabbing to JPEG 70 384 288
Can I hardcode the default resolution from within VDR or the kernel
driver?
Best Regards.
Does it work if you use the v4lctl method?
Are there any FTA NTSC transmissions on Astra 19.2° or Eutelsat 13°? I'd like to do some tests...
I have not been able to test the v4lctl method since I do not have X on the machine. Does v4lctl require xawtv? I suppose I could try and install X but I would rather not if possible. Also, I'm not sure about Astra or Eutelsat since my dish is in America.
I just went ahead and installed X and xawtv. It appears the "v4lctl" method does work and the kernel option does not. I wonder what the difference is between the two.
Best Regards.
Stone wrote:
On 6/30/07, *Stone* <syphyr@gmail.com mailto:syphyr@gmail.com> wrote:
> vdr: [7841] connect from 127.0.0.1 <http://127.0.0.1/>, port 49972 - accepted > vdr: [7841] grabbing to JPEG 70 384 288 > > Can I hardcode the default resolution from within VDR or the kernel driver? > Best Regards. Does it work if you use the v4lctl method? Are there any FTA NTSC transmissions on Astra 19.2° or Eutelsat 13°? I'd like to do some tests... I have not been able to test the v4lctl method since I do not have X on the machine. Does v4lctl require xawtv? I suppose I could try and install X but I would rather not if possible. Also, I'm not sure about Astra or Eutelsat since my dish is in America.I just went ahead and installed X and xawtv. It appears the "v4lctl" method does work and the kernel option does not. I wonder what the difference is between the two.
AFAIK:
The TV-out connectors in the dvb-ttpci board output automatically NTSC if the stream is NTSC. They output automatically PAL when the stream is PAL.
When there is no stream (channel switch or the like), they output PAL by default, or NTSC if the tv_standard kernel option is used to select that.
The output from /dev/video0 file is PAL all the time, unless it is changed by the proper V4L ioctl, which is done by VLC and v4lctl.
AFAIK:
The TV-out connectors in the dvb-ttpci board output automatically NTSC if the stream is NTSC. They output automatically PAL when the stream is PAL.
When there is no stream (channel switch or the like), they output PAL by default, or NTSC if the tv_standard kernel option is used to select that.
The output from /dev/video0 file is PAL all the time, unless it is changed by the proper V4L ioctl, which is done by VLC and v4lctl.
This is exactly what I have observed as well. Is there any way VDR could perform this V4L ioctl without the need for external applications such as VLC and v4lctl?
Best Regards.
Unfortunately I don't have a patch to vdr to handle this but it's better then having to install X and all the other unnecessary packages... You can compile and use v4l2-ctl from the current mercurial v4l drivers located in the v4l-dvb/v4l2-apps/util dir.
command is: v4l2-ctl -s ntsc
Tested and works. v4l2-ctl is meant to be a standalone app.
On 7/1/07, VDR User user.vdr@gmail.com wrote:
Unfortunately I don't have a patch to vdr to handle this but it's better then having to install X and all the other unnecessary packages... You can compile and use v4l2-ctl from the current mercurial v4l drivers located in the v4l-dvb/v4l2-apps/util dir.
command is: v4l2-ctl -s ntsc
Tested and works. v4l2-ctl is meant to be a standalone app.
Thanks for this. I think the Makefile needs another dependency added to it:
L../../lib -lqt-mt -lXext -lX11 -lm -lpthread /usr/bin/ld: cannot find -lv4l2 collect2: ld returned 1 exit status
Best Regards.
On 7/1/07, Stone syphyr@gmail.com wrote:
On 7/1/07, VDR User user.vdr@gmail.com wrote:
Unfortunately I don't have a patch to vdr to handle this but it's better then having to install X and all the other unnecessary packages... You can compile and use v4l2-ctl from the current mercurial v4l drivers located in the v4l-dvb/v4l2-apps/util dir.
command is: v4l2-ctl -s ntsc
Tested and works. v4l2-ctl is meant to be a standalone app.
Thanks for this. I think the Makefile needs another dependency added to it:
L../../lib -lqt-mt -lXext -lX11 -lm -lpthread /usr/bin/ld: cannot find -lv4l2 collect2: ld returned 1 exit status
Sorry, my bad. I just need to start building one directory higher. Thanks again.
-
Anssi Hannula -
Oliver Endriss -
Reinhard Nissl -
Stone -
VDR User