> But since it sounds like the goal is computer playback in small areas
> (384x288 or so) this might be worth thinking about:
>
> For lower ("VCD") resolution I think it's better capturing at the
> 1/2 size (384x288 for "PAL") to begin with. This will be progressive
> (since it's only 1 fiel
I know I have already asked this a couple of months ago but I am really
getting desperate here.
I'm directly streaming to hard disk from my satellite reciever. In order
to burn it to dvd I have do demux, reencode the audio and then remux it.
The problem is that mplex does not recognize the demuxed
Hallo
> I know I have already asked this a couple of months ago but I am really
> getting desperate here.
> I'm directly streaming to hard disk from my satellite reciever. In order
> to burn it to dvd I have do demux, reencode the audio and then remux it.
>
> The problem is that mplex does not re
Hallo
> If you're in a 625line (usually "PAL") video country then VHS has
> 576 active (vertical) lines in 2 fields just like TV and DVDs.
>
> VHS does lack resolution though since it effectively only has 200 or
> so horizontal lines.
I still have not found any re
On Tue, 21 Sep 2004 17:25:00 +0800
Derek Fountain <[EMAIL PROTECTED]> wrote:
> While I'm asking, here's another quick question: can I do anything
> with the sound to lower the file size? It's just crowd noise and
> commentary so I can drop the quality right down if that's possible.
> I was just tr
On Tue, Sep 21, 2004 at 04:56:04PM +0200, Bernhard Praschinger wrote:
> Hallo
>
> > If you're in a 625line (usually "PAL") video country then VHS has
> > 576 active (vertical) lines in 2 fields just like TV and DVDs.
> >
> > VHS does lack resolution though since it effectively only has 200
> > or
On Tue, 21 Sep 2004, Bernhard Praschinger wrote:
> I just tired it with a TS stream from the German Sender: 3sat at
> 720x576, and 48kHz stereo audio. And it worked well. I demuxed it with a
What type of audio is being used? In the US the HDTV stations are
using AC3 (either 384K
Hallo
> The HOWTO says: "If you have an interlaced source (broadcast) you can encode
> it as interlaced stream. Or deinterlace the stream and encode it as
> progressive stream. If you deinterlace it with yuvdenoise -F, you will lose
> details."
The bad thing is that Boradcast movies can also be no
Hallo
> > > I am running kernel 2.6.8. I see that there are zr36067 and so on
> > > drivers in that kernel source so I am using them. Thats part of my first
> > > question
> > >
> > > My motherboard is about 2-3 years old a Soltek VIA based board
> > > KT133/KM133 according to lspci. I see tha
> > I'm using a tuned version of the 3 pass lav2avi.sh script which basically
> > does:
>
> The MPlayer/mencoder developers have deprecated (and highly
> discourage the use of) the 3 pass method and recommend the use
> of the 2 pass method. The lav2avi.sh script hasn't been
> updated/rewritten
On Wed, 22 Sep 2004, Derek Fountain wrote:
> The MPlayer docs describe the 2 pass method like this:
...
> but, er, that doesn't appear to make sense when the input is coming from
> lav2yuv because there's no sound. So what is the two pass method now
> recommended? 1 audio pass and 1 vi
> mencoder -audiofile out.mp3 -oac copy ...
>
> just prepare the .mp3 or whatever ahead of time and use that.
OK. That appears to mean the lav2wav-to-mp3 stage is still required, which is
what I thought. I still have it in my script.
> As an experiment you might try doing a one pass encod
12 matches
Mail list logo
