[pvrusb2] HVR-1950 - bad video quality

Tue Mar 31 01:22:22 CDT 2009

Sorry about the huge files.. I must admit I am kind of at a loss for some of
the parameters.  But I did dump "all" of the parameters.  I am hooked up to
"Plain Analog Cable".  Nothing exciting.  All Tv's and the cablemodem seem
to work fine, so I doubt that it is a signal problem.  Here are the
parameters:

./ctl_brightness/cur_val 128
./ctl_contrast/cur_val 68
./ctl_saturation/cur_val 64
./ctl_hue/cur_val 0
./ctl_volume/cur_val 62000
./ctl_balance/cur_val 0
./ctl_bass/cur_val 0
./ctl_treble/cur_val 0
./ctl_mute/cur_val false
./ctl_crop_left/cur_val 0
./ctl_crop_top/cur_val 0
./ctl_crop_width/cur_val 720
./ctl_crop_height/cur_val 480
./ctl_cropcap_pixel_numerator/cur_val 0
./ctl_cropcap_pixel_denominator/cur_val 0
./ctl_cropcap_bounds_top/cur_val 0
./ctl_cropcap_bounds_left/cur_val 0
./ctl_cropcap_bounds_width/cur_val 0
./ctl_cropcap_bounds_height/cur_val 0
./ctl_input/cur_val television
./ctl_audio_mode/cur_val Stereo
./ctl_resolution_hor/cur_val 720
./ctl_resolution_ver/cur_val 480
./ctl_srate/cur_val 48 kHz
./ctl_frequency/cur_val 175250000
./ctl_channel/cur_val 0
./ctl_freq_table_value/cur_val 0
./ctl_freq_table_channel/cur_val 0
./ctl_streaming_enabled/cur_val false
./ctl_usb_speed/cur_val High
./ctl_master_state/cur_val ready
./ctl_signal_present/cur_val 65535
./ctl_audio_modes_present/cur_val Mono
./ctl_video_standard_mask_available/cur_val PAL-M PAL-N PAL-Nc NTSC-M
NTSC-Mj NTSC-Mk ATSC-8VS ATSC-16V
./ctl_video_standard_mask_active/cur_val NTSC-M
./ctl_video_standard/cur_val NTSC-M
./ctl_audio_layer/cur_val Layer II
./ctl_audio_bitrate/cur_val 224 kbps
./ctl_mpeg_audio_mode/cur_val Stereo
./ctl_mpeg_audio_mode_extension/cur_val Bound 4
./ctl_audio_emphasis/cur_val No Emphasis
./ctl_audio_crc/cur_val No CRC
./ctl_video_aspect/cur_val 4x3
./ctl_video_b_frames/cur_val 2
./ctl_video_gop_size/cur_val 15
./ctl_video_gop_closure/cur_val true
./ctl_video_bitrate_mode/cur_val Variable Bitrate
./ctl_video_bitrate/cur_val 6000000
./ctl_video_bitrate_peak/cur_val 8000000
./ctl_video_temporal_decimation/cur_val 0
./ctl_stream_type/cur_val MPEG-2 Program Stream
./ctl_video_spatial_filter_mode/cur_val Manual
./ctl_video_spatial_filter/cur_val 0
./ctl_video_luma_spatial_filter_type/cur_val 1D Horizontal
./ctl_video_chroma_spatial_filter_type/cur_val 1D Horizontal
./ctl_video_temporal_filter_mode/cur_val Manual
./ctl_video_temporal_filter/cur_val 8
./ctl_video_median_filter_type/cur_val Off
./ctl_video_luma_median_filter_top/cur_val 255
./ctl_video_luma_median_filter_bottom/cur_val 0
./ctl_video_chroma_median_filter_top/cur_val 255
./ctl_video_chroma_median_filter_bottom/cur_val 0

A ideas?

Stan

On Mon, Mar 30, 2009 at 10:04 PM, Mike Isely <isely at isely.net> wrote:

> On Mon, 30 Mar 2009, Mike Isely wrote:
>
> > On Sun, 29 Mar 2009, stan schultz wrote:
> >
> > > My first HVR-1950 was DOA.  went back to the store and got a new one.
>  It
> > > works much better. On WIndows it captures video that looks as good as
> the
> > > direct TV in analog mode.  But on my Linux box, the video is very bad
> > > quality.  It looks like the problem is the synchronization of the start
> of
> > > the scan lines.  They start at a random location between 0 and about 20
> > > pixels from the left edge of the screen.  This happens both with Mythtv
> and
> > > with mplayer (both at 720x480 resolution).  Do you have any ideas on
> what's
> > > wrong?
> > >
> > > Thanks,
> > >
> > > Stan
> >
> > Stan:
> >
> > Can you capture a snippet and post it somewhere?
> >
> >   -Mike
>
> Stan:
>
> When I said "post it somewhere", I was thinking about a web page or
> direct e-mail to me.  Large multi-megabyte posts to this list are not
> allowed - that would just annoy everyone here and likely lay waste to my
> net connection for an extended period (and probably anger a bunch of
> other MTAs).  So I'm going to reject that post.
>
> However the moderation message I received also includes the snapshots
> you are trying to post and I had a look.  I'm glad I asked because this
> is not anything like I was imagining.  This looks like seriously messed
> up video capture timing - looks like the color modulation is messing
> things up.  I think you've probably got the device set to the wrong
> video standard.  MythTV should be handling that automatically (assuming
> of course that you've configured MythTV with the correct standard).  As
> for mplayer, it isn't going to set the standard; rather it will just use
> the device according to whatever standard is in effect.  The quickest
> way to diagnose this problem is to first read this:
>
> http://www.isely.net/pvrusb2/usage.html#sysfs
>
> Then take a look at ctl_video_standard/cur_val and see if it looks
> reasonable.  It's entirely possible that the default setting in the
> driver isn't what you want.  You can change it directly which will help
> mplayer, but for MythTV it needs itself to be configured with the
> correct video standard.  If you think MythTV is getting it right, then
> look again at ctl_video_standard *while* MythTV is running a capture -
> you'll be able to directly observe what standard is being used at the
> moment the capture is going on.
>
> If the problem isn't the video standard, then you have a huge signal
> reception problem.  But that would not seem likely since you said that
> the same hardware setup is working fine in Windows.  I bet my money on
> this being a video standard configuration issue.
>
>  -Mike
>
>
> --
>
> Mike Isely
> isely @ pobox (dot) com
> PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>