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
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
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: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,
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 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
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 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 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 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
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, 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_
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 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
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 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,
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
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 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,
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 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 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 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!"
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 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
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
>
26 matches
Mail list logo
