Mailing List Archive

Hi,

you won't get an avi file just because you provide avi as file
extension. Your device delivers a MPEG PS stream. So better name the
file accordingly (e.g. somevid.mpeg). If you want to recode the file
later you can use mencoder, ffmpeg, avidemux...

Regards


Am 23.08.2011 12:53, schrieb asbesto molesto:
> Hi there,
>
> I'm new into this mailing list and hope someone can help me solving
> (or understanding) the problem I'm facing;
>
> I'm using a Debian with 2.6.32-686 kernel on my Intel(R) Pentium(R) 4
> CPU 2.40GHz computer with 1GB of RAM...
>
> My board is an Hauppage WinTV PVR-350, with modules loaded and it's
> working, i has used it simply with "cat /dev/video0> file.avi" to
> encode VHS tapes using this board.
>
> I use the S-VIDEO input, converted from the SCART out of a VHS player
> (to encode VHS into AVI files) or using the S-VIDEO output of my
> Video-8 player...
>
> Now I'm facing a weird problem! I'm trying to encode video from a Hi-8
> (Video8) source, and with some tapes, the video "jumps", some frames
> are lost, the video out (as sees with "mplayer /dev/video0") sometimes
> freeze, and I obtain the classical mplayer warning "Your system is too
> slow etc. etc." while the CPU is under 10% of usage!
>
> I have this problem with some tapes, and other tapes goes perfectly.
> So I suspect they are somewhere damaged. This prevent me to encode
> (and save!) those tapes correctly!
>
> Also, those "damaged" tapes can be seen without problems on my
> tv-screen, so, what kind of damage is it, giving problems to the wintv
> card, and not showing any problem on my tv screen?
>
> How can I correctly encode a .avi from those tapes?
>
> Can please someone help me in this? I'm new into this kind of problems.
>
>

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On 8/23/11, Christian Rapp <saedelaere.tv@googlemail.com> wrote:
> Hi,
>
> you won't get an avi file just because you provide avi as file
> extension. Your device delivers a MPEG PS stream. So better name the
> file accordingly (e.g. somevid.mpeg). If you want to recode the file
> later you can use mencoder, ffmpeg, avidemux...

>> (Video8) source, and with some tapes, the video "jumps", some frames
>> are lost, the video out (as sees with "mplayer /dev/video0") sometimes
>> freeze, and I obtain the classical mplayer warning "Your system is too
>> slow etc. etc." while the CPU is under 10% of usage!

Ah, ok! But this is not the problem I'm talking about... I can "cat
/dev/video0 >file.mpeg" but some frames are lost, the video "freeze"
and goes out of sync, recovering after a while.... and so creating a
MPEG for this video8 tape is impossible! :(




--
73 de IW9HGS - Gabriele "Asbesto Molesto" Zaverio
Museo dell'Informatica funzionante - Freaknet Computer Museum
http://museum.freaknet.org || http://freaknet.org/asbesto
GPG Fingerprint: 8935 5586 7F2D 9C5E 51B6 BBC5 EA15 9A4E 613D 44D7

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On 2011-08-23 07:25, asbesto molesto wrote:
>
>> (Video8) source, and with some tapes, the video "jumps", some frames
>> are lost, the video out (as sees with "mplayer /dev/video0") sometimes
>> freeze, and I obtain the classical mplayer warning "Your system is too
>> slow etc. etc." while the CPU is under 10% of usage!

I probably won''t be able to help you, but when you try to capture the
same section of tape multiple times, are the same frames lost each time
and does it freeze in the same place each time?

Do the frames that you are able to capture before and after the problem
areas look ok? Do they have any kind of horizontal sync problems at the
top, move vertically or have interlacing issues? Do the colors and
brightness look ok?

Roger


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On 8/23/11, Roger Dahl <rdmisc@dahlsys.com> wrote:
> On 2011-08-23 07:25, asbesto molesto wrote:
>>> (Video8) source, and with some tapes, the video "jumps", some frames
>>> are lost, the video out (as sees with "mplayer /dev/video0") sometimes
>>> freeze, and I obtain the classical mplayer warning "Your system is too
>>> slow etc. etc." while the CPU is under 10% of usage!
> I probably won''t be able to help you, but when you try to capture the
> same section of tape multiple times, are the same frames lost each time
> and does it freeze in the same place each time?

It seem to freeze almost in the same place, but sometimes the result
is better, sometime not :(

> Do the frames that you are able to capture before and after the problem
> areas look ok? Do they have any kind of horizontal sync problems at the
> top, move vertically or have interlacing issues? Do the colors and
> brightness look ok?

Colors and pictures seem OK but when I play the stream directly
(mplayer /dev/video0) i notice some weird lines at the bottom of the
image; I made a screenshot, it's here:

http://zaverio.com/~asbesto/capture1.jpg

(p.s. that image was just me kidding many years ago :D hahahahahahah!!!)

What are those lines and what they mean?

ps everything here is PAL

> Roger
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>


--
73 de IW9HGS - Gabriele "Asbesto Molesto" Zaverio
Museo dell'Informatica funzionante - Freaknet Computer Museum
http://museum.freaknet.org || http://freaknet.org/asbesto
GPG Fingerprint: 8935 5586 7F2D 9C5E 51B6 BBC5 EA15 9A4E 613D 44D7

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On 2011-08-23 08:56, asbesto molesto wrote:
>> I probably won''t be able to help you, but when you try to capture the
>> same section of tape multiple times, are the same frames lost each time
>> and does it freeze in the same place each time?
> It seem to freeze almost in the same place, but sometimes the result
> is better, sometime not :(
>
>> Do the frames that you are able to capture before and after the problem
>> areas look ok? Do they have any kind of horizontal sync problems at the
>> top, move vertically or have interlacing issues? Do the colors and
>> brightness look ok?
> Colors and pictures seem OK but when I play the stream directly
> (mplayer /dev/video0) i notice some weird lines at the bottom of the
> image; I made a screenshot, it's here:
>
> http://zaverio.com/~asbesto/capture1.jpg
>
> (p.s. that image was just me kidding many years ago :D hahahahahahah!!!)
>
> What are those lines and what they mean?
>
> ps everything here is PAL

Old CRT TVs used magnetic fields to guide an electron beam across the
screen. At the end of each field, they needed time for resetting the
magnetic fields back to the beginning, upper left, screen position. That
period is called the vblank. Anything in the video signal that was
output to the TV in this period would be invisible. In addition, they
used a technique called overscan to hide issues with their power
supplies, further hiding signals output to the TV while the electron
beam was in the overscan areas. VCRs often (always?) output junk during
these times, probably related to the way the video heads scan the tape.

I have two cards, a PVR 250 and an HVR 1600. In my experience, both of
these cards are easily confused by junk in the video signals during the
vblank and overscan. It's just bad engineering because LCD TVs have no
trouble at all with the signals. Issues I'm seeing are poor hsync at the
top of the screen, misinterpreted odd/even field signals and poor colors.

My guess is that the tapes you're having trouble with were recorded in
some way that is causing the VCR to output junk during the vblank and/or
overscan periods that cause the card to lose track of the vsync signal
in the video.

I think that a TBC, Time Base Corrector, would fix your issues. It sits
between your VCR and your card and cleans up the video signal. Just for
fun, you could try re-recording your tape onto another tape. That could
fix up the problems, at the cost of worse quality. If you have a DV
camera, you could try recording onto the DV camera and dump the digital
data out via FireWire. Another option is to just send the tapes off to a
company that has professional equipment to do transfers to digital,
though I would not recommend that if there are any beheadings on your
tapes :)

Roger


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

... and TBC are expensive :( So, I can't encode those videos :(

Thank you for the answer!

Does someone have any idea to solve this? :)


On 8/23/11, Roger Dahl <rdmisc@dahlsys.com> wrote:
> On 2011-08-23 08:56, asbesto molesto wrote:
>>> I probably won''t be able to help you, but when you try to capture the
>>> same section of tape multiple times, are the same frames lost each time
>>> and does it freeze in the same place each time?
>> It seem to freeze almost in the same place, but sometimes the result
>> is better, sometime not :(
>>
>>> Do the frames that you are able to capture before and after the problem
>>> areas look ok? Do they have any kind of horizontal sync problems at the
>>> top, move vertically or have interlacing issues? Do the colors and
>>> brightness look ok?
>> Colors and pictures seem OK but when I play the stream directly
>> (mplayer /dev/video0) i notice some weird lines at the bottom of the
>> image; I made a screenshot, it's here:
>>
>> http://zaverio.com/~asbesto/capture1.jpg
>>
>> (p.s. that image was just me kidding many years ago :D hahahahahahah!!!)
>>
>> What are those lines and what they mean?
>>
>> ps everything here is PAL
>
> Old CRT TVs used magnetic fields to guide an electron beam across the
> screen. At the end of each field, they needed time for resetting the
> magnetic fields back to the beginning, upper left, screen position. That
> period is called the vblank. Anything in the video signal that was
> output to the TV in this period would be invisible. In addition, they
> used a technique called overscan to hide issues with their power
> supplies, further hiding signals output to the TV while the electron
> beam was in the overscan areas. VCRs often (always?) output junk during
> these times, probably related to the way the video heads scan the tape.
>
> I have two cards, a PVR 250 and an HVR 1600. In my experience, both of
> these cards are easily confused by junk in the video signals during the
> vblank and overscan. It's just bad engineering because LCD TVs have no
> trouble at all with the signals. Issues I'm seeing are poor hsync at the
> top of the screen, misinterpreted odd/even field signals and poor colors.
>
> My guess is that the tapes you're having trouble with were recorded in
> some way that is causing the VCR to output junk during the vblank and/or
> overscan periods that cause the card to lose track of the vsync signal
> in the video.
>
> I think that a TBC, Time Base Corrector, would fix your issues. It sits
> between your VCR and your card and cleans up the video signal. Just for
> fun, you could try re-recording your tape onto another tape. That could
> fix up the problems, at the cost of worse quality. If you have a DV
> camera, you could try recording onto the DV camera and dump the digital
> data out via FireWire. Another option is to just send the tapes off to a
> company that has professional equipment to do transfers to digital,
> though I would not recommend that if there are any beheadings on your
> tapes :)
>
> Roger
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>


--
73 de IW9HGS - Gabriele "Asbesto Molesto" Zaverio
Museo dell'Informatica funzionante - Freaknet Computer Museum
http://museum.freaknet.org || http://freaknet.org/asbesto
GPG Fingerprint: 8935 5586 7F2D 9C5E 51B6 BBC5 EA15 9A4E 613D 44D7

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

If you have access to Windows, you can use some other devices,
such as an ADSTech Instant DVD 2.0 Converter USBAV-702
or an ADSTech DVD Xpress DX2 USB 2.0 Video Capture Box.

My dad and I have both used the USBAV-702, and it seems to work
pretty well. But it is USB to MS Windows, don't think they
have Linux support.

> -----Original Message-----
> From: ivtv-users-bounces@ivtvdriver.org [mailto:ivtv-users-
> bounces@ivtvdriver.org] On Behalf Of asbesto molesto
> Sent: Tuesday, August 23, 2011 2:23 PM
> To: User discussion about IVTV
> Subject: Re: [ivtv-users] A problem with Debian, WinTV PVR-350 and
> IVTV: .avi file "jumps" loosing frames...
>
> ... and TBC are expensive :( So, I can't encode those videos :(
>
> Thank you for the answer!
>
> Does someone have any idea to solve this? :)
>
>
> On 8/23/11, Roger Dahl <rdmisc@dahlsys.com> wrote:
> > On 2011-08-23 08:56, asbesto molesto wrote:
> >>> I probably won''t be able to help you, but when you try to capture
> the
> >>> same section of tape multiple times, are the same frames lost each
> time
> >>> and does it freeze in the same place each time?
> >> It seem to freeze almost in the same place, but sometimes the result
> >> is better, sometime not :(
> >>
> >>> Do the frames that you are able to capture before and after the
> problem
> >>> areas look ok? Do they have any kind of horizontal sync problems at
> the
> >>> top, move vertically or have interlacing issues? Do the colors and
> >>> brightness look ok?
> >> Colors and pictures seem OK but when I play the stream directly
> >> (mplayer /dev/video0) i notice some weird lines at the bottom of the
> >> image; I made a screenshot, it's here:
> >>
> >> http://zaverio.com/~asbesto/capture1.jpg
> >>
> >> (p.s. that image was just me kidding many years ago :D
> hahahahahahah!!!)
> >>
> >> What are those lines and what they mean?
> >>
> >> ps everything here is PAL
> >
> > Old CRT TVs used magnetic fields to guide an electron beam across the
> > screen. At the end of each field, they needed time for resetting the
> > magnetic fields back to the beginning, upper left, screen position.
> That
> > period is called the vblank. Anything in the video signal that was
> > output to the TV in this period would be invisible. In addition, they
> > used a technique called overscan to hide issues with their power
> > supplies, further hiding signals output to the TV while the electron
> > beam was in the overscan areas. VCRs often (always?) output junk
> during
> > these times, probably related to the way the video heads scan the
> tape.
> >
> > I have two cards, a PVR 250 and an HVR 1600. In my experience, both
> of
> > these cards are easily confused by junk in the video signals during
> the
> > vblank and overscan. It's just bad engineering because LCD TVs have
> no
> > trouble at all with the signals. Issues I'm seeing are poor hsync at
> the
> > top of the screen, misinterpreted odd/even field signals and poor
> colors.
> >
> > My guess is that the tapes you're having trouble with were recorded
> in
> > some way that is causing the VCR to output junk during the vblank
> and/or
> > overscan periods that cause the card to lose track of the vsync
> signal
> > in the video.
> >
> > I think that a TBC, Time Base Corrector, would fix your issues. It
> sits
> > between your VCR and your card and cleans up the video signal. Just
> for
> > fun, you could try re-recording your tape onto another tape. That
> could
> > fix up the problems, at the cost of worse quality. If you have a DV
> > camera, you could try recording onto the DV camera and dump the
> digital
> > data out via FireWire. Another option is to just send the tapes off
> to a
> > company that has professional equipment to do transfers to digital,
> > though I would not recommend that if there are any beheadings on your
> > tapes :)
> >
> > Roger
> >
> >
> > _______________________________________________
> > ivtv-users mailing list
> > ivtv-users@ivtvdriver.org
> > http://ivtvdriver.org/mailman/listinfo/ivtv-users
> >
>
>
> --
> 73 de IW9HGS - Gabriele "Asbesto Molesto" Zaverio
> Museo dell'Informatica funzionante - Freaknet Computer Museum
> http://museum.freaknet.org || http://freaknet.org/asbesto
> GPG Fingerprint: 8935 5586 7F2D 9C5E 51B6 BBC5 EA15 9A4E 613D 44D7
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

If you have access to Windows, you can use some other devices,
such as an ADSTech Instant DVD 2.0 Converter USBAV-702 or
an ADSTech DVD Xpress DX2 USB 2.0 Video Capture Box.

My dad and I have both used the USBAV-702, and it seems to work
pretty well. But it is USB to MS Windows, don't think they have Linux support.

> -----Original Message-----
> From: ivtv-users-bounces@ivtvdriver.org [mailto:ivtv-users-
> bounces@ivtvdriver.org] On Behalf Of asbesto molesto
> Sent: Tuesday, August 23, 2011 2:23 PM
> To: User discussion about IVTV
> Subject: Re: [ivtv-users] A problem with Debian, WinTV PVR-350 and
> IVTV: .avi file "jumps" loosing frames...
>
> ... and TBC are expensive :( So, I can't encode those videos :(
>
> Thank you for the answer!
>
> Does someone have any idea to solve this? :)
>
>
> On 8/23/11, Roger Dahl <rdmisc@dahlsys.com> wrote:
> > On 2011-08-23 08:56, asbesto molesto wrote:
> >>> I probably won''t be able to help you, but when you try to capture
> the
> >>> same section of tape multiple times, are the same frames lost each
> time
> >>> and does it freeze in the same place each time?
> >> It seem to freeze almost in the same place, but sometimes the result
> >> is better, sometime not :(
> >>
> >>> Do the frames that you are able to capture before and after the
> problem
> >>> areas look ok? Do they have any kind of horizontal sync problems at
> the
> >>> top, move vertically or have interlacing issues? Do the colors and
> >>> brightness look ok?
> >> Colors and pictures seem OK but when I play the stream directly
> >> (mplayer /dev/video0) i notice some weird lines at the bottom of the
> >> image; I made a screenshot, it's here:
> >>
> >> http://zaverio.com/~asbesto/capture1.jpg
> >>
> >> (p.s. that image was just me kidding many years ago :D
> hahahahahahah!!!)
> >>
> >> What are those lines and what they mean?
> >>
> >> ps everything here is PAL
> >
> > Old CRT TVs used magnetic fields to guide an electron beam across the
> > screen. At the end of each field, they needed time for resetting the
> > magnetic fields back to the beginning, upper left, screen position.
> That
> > period is called the vblank. Anything in the video signal that was
> > output to the TV in this period would be invisible. In addition, they
> > used a technique called overscan to hide issues with their power
> > supplies, further hiding signals output to the TV while the electron
> > beam was in the overscan areas. VCRs often (always?) output junk
> during
> > these times, probably related to the way the video heads scan the
> tape.
> >
> > I have two cards, a PVR 250 and an HVR 1600. In my experience, both
> of
> > these cards are easily confused by junk in the video signals during
> the
> > vblank and overscan. It's just bad engineering because LCD TVs have
> no
> > trouble at all with the signals. Issues I'm seeing are poor hsync at
> the
> > top of the screen, misinterpreted odd/even field signals and poor
> colors.
> >
> > My guess is that the tapes you're having trouble with were recorded
> in
> > some way that is causing the VCR to output junk during the vblank
> and/or
> > overscan periods that cause the card to lose track of the vsync
> signal
> > in the video.
> >
> > I think that a TBC, Time Base Corrector, would fix your issues. It
> sits
> > between your VCR and your card and cleans up the video signal. Just
> for
> > fun, you could try re-recording your tape onto another tape. That
> could
> > fix up the problems, at the cost of worse quality. If you have a DV
> > camera, you could try recording onto the DV camera and dump the
> digital
> > data out via FireWire. Another option is to just send the tapes off
> to a
> > company that has professional equipment to do transfers to digital,
> > though I would not recommend that if there are any beheadings on your
> > tapes :)
> >
> > Roger
> >
> >
> > _______________________________________________
> > ivtv-users mailing list
> > ivtv-users@ivtvdriver.org
> > http://ivtvdriver.org/mailman/listinfo/ivtv-users
> >
>
>
> --
> 73 de IW9HGS - Gabriele "Asbesto Molesto" Zaverio
> Museo dell'Informatica funzionante - Freaknet Computer Museum
> http://museum.freaknet.org || http://freaknet.org/asbesto
> GPG Fingerprint: 8935 5586 7F2D 9C5E 51B6 BBC5 EA15 9A4E 613D 44D7
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Tue, Aug 23, 2011 at 1:53 PM, Roger Dahl <rdmisc@dahlsys.com> wrote:
> I have two cards, a PVR 250 and an HVR 1600. In my experience, both of these
> cards are easily confused by junk in the video signals during the vblank and
> overscan. It's just bad engineering because LCD TVs have no trouble at all
> with the signals. Issues I'm seeing are poor hsync at the top of the screen,
> misinterpreted odd/even field signals and poor colors.
>
> My guess is that the tapes you're having trouble with were recorded in some
> way that is causing the VCR to output junk during the vblank and/or overscan
> periods that cause the card to lose track of the vsync signal in the video.

For what it's worth, I've seen this sort of thing before in devices.
In most cases it can be fixed by poking the register that controls the
tolerances for vsync/hsync. Most video decoder chips I have seen have
a "vcr mode", which when enabled widens the tolerances at the cost of
overall quality.

That said, I haven't dug very closely into the docs for the Conexant
video decoder core (known as the Mako) to see how to manipulate this
functionality.

And yes, it pretty much universally is the result of the VCR putting
out a crappy/malformed signal.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users