On Fri, Mar 14, 2003 at 06:56:54PM +0100, Bernhard Praschinger wrote:
> Hallo
Hi Bernhard,
> I'm nearly finished with adding that feature in LVS.
Oh cool! Do let me know when you are finished. I would love to try
it out.
> But you can easily check if the boarders are set correct with with
>
On Fri, Mar 14, 2003 at 05:42:03PM +0100, Martin Samuelsson wrote:
>
> It does. You can. Just give -F to lavplay/glav for that genuine interlace
> experience.
Excellent! I looked at the source (briefly) but did not think to look
for it associated with "flicker".
As an editing tool, I would lov
I am wondering if glav (or rather lavplay) applies some form of
de-interlacing algorithm before output? Can I suppress this behaviour
if it does?
The reason being, I am using glav to edit broadcast television
programming (i.e. edit out commercials) and while I am doing that I want to
(manually, v
On Mon, Feb 10, 2003 at 08:45:41PM -0500, Matto Marjanovic wrote:
>
> "Your donation of only 5 dollars a week, less than the price of a
> double-latte, will give dominance-bit-preserving assistance to these
> poor fields. Let the world know that apathy is not the answer.
> Send us money now!"
On Mon, Feb 10, 2003 at 05:51:06PM -0500, Matto Marjanovic wrote:
>
> Isn't this:
>
> >True enough. But the cropping tool is mencoder, which is quite
> >generic. From what I have been told, A'rpi (mencoder
> >author/maintainer) doesn't much care for interlace output, so
> >everything is (de
On Mon, Feb 10, 2003 at 02:36:21PM -0500, Matto Marjanovic wrote:
>
> >If you plan HW playback it is not wise to crop the images to a unusal
> >size. You should use there the yuvscaler -I
> >ACTIVE_widthxheight+xoffset+yoffset for setting everything outside the
> >area to real black. You can a
On Mon, Feb 10, 2003 at 07:42:04PM +0100, Bernhard Praschinger wrote:
> Hallo
Hi
> If you plan HW playback
I don't. I am transcoding to MPEG4/AVI with mencoder.
> it is not wise to crop the images to a unusal
> size.
I could understand that.
> You should use there the yuvscaler -I
> ACTIVE_w
On Mon, Feb 10, 2003 at 10:53:41AM -0500, Matto Marjanovic wrote:
>
> I would suggest starting here:
>
> http://www.mir.com/DMG/aspect.html
>
> and see what gets answered. (Not everything, but it is a start.)
Cool. Maybe I should try this from another angle, given that I
capture at 352x480,
I am trying to understand the relationship between frame sizes, aspect
ratios and all that sort. For reference, I am in North America here
so NTSC applies.
I have a Matrox G400 Marvel. I capture using lavrec with -d21. My
captured MJPEG winds up being 352x480. This is my first puzzle. Why
is
On Sat, Feb 08, 2003 at 10:44:28PM +0100, Ronald Bultje wrote:
> Hi Brian,
Hi Ronald,
> On Fri, 2003-02-07 at 14:17, [EMAIL PROTECTED] wrote:
> > Should be. But it might lag while it waits for disk i/o or something.
>
> Could be... But this never happens in practice actually.
Something happens
On Fri, Feb 07, 2003 at 08:18:20AM +0100, Ronald Bultje wrote:
> Hi Brian,
Hi Ronald.
> it writes q\n, which quits lavplay nicely.
Right.
> After that, lavplay should be
> long gone when do_real_exit() is called.
Should be. But it might lag while it waits for disk i/o or something.
> If not,
I noticed the following in glav_main.c:
void do_real_exit(int ID, void *data)
{
int status;
/* Kill all our children and exit */
printf("real exit here\n");
kill(0,9);
waitpid(pid,&status,0);
exit(0);
}
void Exit_cb(GtkWidget *ob, long data)
{
/* Try to exit gracefully, wai
On Tue, Jan 07, 2003 at 12:15:31AM +, Martin Collins wrote:
>
> Create an editlist with all your files in then
> lav2yuv editlist.edl | mencoder - .
lav2yuv only provides the video track though right? How does mencoder
get the audio to mux in with the yuv data?
>
> Or cat all your avis
On Tue, Jan 07, 2003 at 01:30:55AM +0100, Ronald Bultje wrote:
> Hey Brian,
Hi Ron,
> One word: MPEG... :-(.
That's actually an acronym for 4 words. ~ducking~ :-) But you are
indeed correct. Is there room in the MPEG specification to put MJPEG
frames into it?
I would think that movtar would
On Mon, Jan 06, 2003 at 12:06:12AM +0100, Ronald Bultje wrote:
> Hi Brian,
Hi Ronald,
> Sounds like... Your sampling rate is a bit weird? Does lavinfo report
> the sampling rate correctly?
$ lavinfo cnn.movtar
video_frames=943
video_width=352
video_height=480
video_inter=1
video_norm=NTSC
video_
When I use lavrec to create a movtar file, and then try to extract the
audio from the movtar file with lav2wav, it comes out "gurgly". By
gurgly, imagine the filter a special effects man would use to make you
believe somebody was talking under water.
If I use lavrec to create an avi file, lav2wav
On Mon, Dec 30, 2002 at 08:34:08PM -0600, Jeremy Mann wrote:
>
> I still don't see what the big hype is about PVRs.
Best thing since TV. :-)
> First of all, you can't
> get the MPEG recorded material OFF the PVR without first capturing from
> its own outputs.
You are right if you are talking a
On Mon, Dec 30, 2002 at 06:20:44PM -0800, Trent Piepho wrote:
> On Mon, 30 Dec 2002 [EMAIL PROTECTED] wrote:
> > At the difference in space usage, disk. I have a 5:27s clip here
> > that I was testing with. It is 720x480, default lavrec jpeg quality
> > (50% I think it is isn't it?). It is 917MB
On Mon, Dec 30, 2002 at 10:16:18AM -0800, Trent Piepho wrote:
>
> If you just want a PVR, then why not keep the recording in mjpeg form?
Something else worth mentioning here. MJPEG seems to take a lot of
CPU to decode. Using MPlayer, I constantly drop frames trying to play
an MJPEG on the same
On Mon, Dec 30, 2002 at 10:16:18AM -0800, Trent Piepho wrote:
>
> If you just want a PVR, then why not keep the recording in mjpeg form?
Several reasons...
> Sure
> it takes up more space then mpeg2,
Way more!
> but what costs more, a 100GB+ ide drive or
> a hardware mpeg2 compression card?
A
On Mon, Dec 30, 2002 at 05:59:00PM +0100, Ronald Bultje wrote:
> Hi Brian,
Hi Ronald,
> Not that difficult, I guess... I'm not familiar with the ffmpeg internal
> interface,
mp1e is from the zapping/rte folks. I don't know if the lineage of
that goes back to ffmpeg though.
> but it shouldn't b
encoding time. mp1e fills this void
very well (although only with MPEG1, not MPEG2) but does not (AFAIK)
fit in a "lav2yuv" pipeline. I wonder how difficult it would be to
make mp1e read yuv data from stdin rather than a v4l{1,2} device.
The better solution though, would be a fast (an
On Sun, Dec 29, 2002 at 12:34:18PM -0800, James Klicman wrote:
> Hi Brian,
Hi James.
> I checked the numbers for 720x480 input which is DVD resolution.
>
> Athlon 700Mhz
> DVD...: 6.34 fps
> DVD Interlaced: 3.70 fps
Yeah, I seemed to have gotten it up to about 4fps or thereabouts,
On Sun, Dec 29, 2002 at 04:01:01AM -0800, James Klicman wrote:
> Hi Brian,
Hi James,
> Is there another process in your pipeline that could be causing the
> slowdown?
$ lav2yuv test.avi | /usr/src/mjpeg_play/mpeg2enc/mpeg2enc -f 3 -4 4 -2 4 -q12 -b 4500
-V 300 -I 1 -o test.m2v
++ WARN: [lav2yuv
On Sun, Dec 29, 2002 at 12:14:47PM +0100, Andrew Stevens wrote:
>
> What kind of CPU are you using.
800MHz Athlon ThunderBird. The mpeg2enc was build on this machine so
(hopefully) it is tuned for the Athlon's processor features. I did
see mention of MMX being used during the startup of mpeg2en
I am trying to convert some MJPEG that I captured with my G400 Marvel
to MPEG2. I have tried an mpeg2enc coomandline sever al times but
it's too slow. The best I can get (with bad quality switches) is
2fps. But at that rate every hour I record will take 15 hours to
convert.
Is there a better MP
26 matches
Mail list logo
