It looks like the only use of ebx is in the code to detect CPU features
using cpuid. A better way to do it would be to read the /proc/cpuinfo file
and look for the sse2 or whatever flag.
On Tue, Oct 12, 2010 at 11:06 AM, sfrase6 wrote:
>
> - Original Message -
> From: "Christian Ebert"
On Wed, Oct 13, 2010 at 12:11 AM, Christian Ebert wrote:
> * Trent Piepho on Tuesday, October 12, 2010 at 12:06:45 -0700
> > It looks like the only use of ebx is in the code to detect CPU features
> > using cpuid. A better way to do it would be to read the /proc/cpuinfo
> fil
On Thu, Oct 14, 2010 at 2:43 PM, Christian Ebert wrote:
> * Bernhard Praschinger on Thursday, October 14, 2010 at 19:06:33 +0200
> >> Oh yeah, this isn't on Linux. OSX probably has some kind of API for
> >> checking if sse2 is available. Using CPUID isn't enough, because sse
> >> requires OS su
On Fri, Oct 15, 2010 at 12:40 AM, Christian Ebert wrote:
> * Trent Piepho on Thursday, October 14, 2010 at 17:38:39 -0700
> > On Thu, Oct 14, 2010 at 2:43 PM, Christian Ebert
> wrote:
> >>>>
> >>>> Easy fix would just be the change the sse de
On Fri, Oct 15, 2010 at 10:58 AM, Christian Ebert wrote:
> No! Trent nudged me in the right direction I believe. By applying
> the same fix to the other asm volatile line I was able to build
> it here as well. This change makes it build, but of course I've
> no idea what I was doing:
>
> Index: yu
On Mon, Jun 23, 2014 at 10:40 AM, Bernhard Praschinger
wrote:
> The problem was than that the card did support v4l2, as far as I
> remember but you needed mplayer to get a picture on the screen (xawtv
> and other TV Apps didn't work). But with that the recording didn't work.
I seem to recall that
On Wed, 14 Jan 2004, Steven M. Schultz wrote:
> Look in cpu_accel.c - you should see something like this:
>
> if (posix_memalign( &buf, simd_alignment, size))
> buf = memalign(pgsize, size);
> if (buf && ((int)buf & (simd_alignment - 1)))
> {
>
On Sat, 17 Jan 2004, James Finnall wrote:
> What I need is for jpeg2yuv and/or ppmtoy4m to have an option to
> strip the format info. So that the output files can be cat'd
> together. Of course the first time it is called, include the
> format, but then an option to continue the sequence. In
On Mon, 19 Jan 2004 [EMAIL PROTECTED] wrote:
> If you only watch the movie on a 4:3 TV, then it is both a waste of
> bits and a reduction in quality to encode the widescreen (anamorphic)
> version. Most (all? certainly the cheap ones) DVD players convert
> 16:9 material to 4:3 material by dropping
On Mon, 19 Jan 2004 [EMAIL PROTECTED] wrote:
> > Some 4:3 TVs however, have a 16:9 enhanced mode. In this mode, they take the
> > full vertical resolution signal and squish the scan lines into a 16:9
> > letterbox area. This will give you more quality than throwing away the
> > resolution before
On Tue, 27 Jan 2004, Steven M. Schultz wrote:
> On Wed, 28 Jan 2004, E.Chalaron wrote:
>
> > Regarding frame rates for DVD, do I have to comply with NTSC or PAL frame
> > rate or is it possible to use 20,18, 16 fps without the standalone DVD
> > player going mad ? or mplex refusing mplexing
On Tue, 23 Mar 2004, Steven M. Schultz wrote:
> IEEE1394 connection. All I need (and it's been ordered - should
> arrive Friday) is a HDTV tuner with a IEEE1394 port on it. Converting
What is this piece of hardware? This can be used to record HDTV content from
over the air onto a
On Wed, 5 May 2004, Axel Philipsenburg wrote:
> I was wondering if there is a way to monitor the recording of video from an
> Iomega BUZ.
>
> Any ideas? Thanks a lot.
A. Watch the video on your computer via the BUZ's tv overlay function. The
DC10+ can overlay and do mjpeg capture at once, t
On Tue, 22 Jun 2004, Steven M. Schultz wrote:
> cards are "adequate". For archival purposes, well, quality isn't
> free/cheap ;( The other gotcha is that the analog cards (at least
> the Bt878 based ones) going thru the v4l layer yield square pixels
You are about that? I hav
On Wed, 29 Dec 2004, Ray Cole wrote:
>
> a single frame in probably > 200 hours of recording). I tell it to capture
> at 720x480 and I haven't noticed any distortion. Should I really be
> capturing at 704x480 instead? I don't do any scaling beyond the capture
> phase and it all looks fine to me
On Wed, 29 Dec 2004, Steven M. Schultz wrote:
> > bt848 datasheet. 52.15 is used by VCDs, DVDs in 704x480 mode, and 640x480
> > square pixel captures.
>
> Hmmm, for square pixel sampling the frequency is not 13.5MHz - it's
> 12.2727 (actually 12 + 3/11) MHz.
Yep, and if you divided 6
On Thu, 30 Dec 2004, Steven Boswell II wrote:
> could find at Best Buy that day, cost US$60. Note
> that I'm using a composite-video cable, even
> though my VCR can put out an S-VHS signal. The
> issue here is who does the color separation. If I
> play a VHS tape and use an S-VHS cable to carry
On Fri, 31 Dec 2004, Steven Boswell II wrote:
> Eh? I thought VHS videotapes were composite
> video, and that composite video means the
> intensity/color/sync were all mixed together in
> the same signal. Am I wrong?
VHS tapes aren't composite. Laserdisks are. Couldn't tell you about beta or
C
On Fri, 7 Jan 2005, Steven M. Schultz wrote:
> It does sound though like you're aiming at a specified size and if so
> then you'll need to hold the bitrate constant and vary the quality.
> Vbr works the other way - holds the quality constant but varies the
> bitrate ;)
Obvi
On Sun, 9 Jan 2005, Steven M. Schultz wrote:
> On Sun, 9 Jan 2005, Dik Takken wrote:
> > bandwidth. Why does the CBR encoder not use -q 4 to keep the bitrate
> > as high as the requested bitrate?
>
> Because -q enabled VBR mode? ;) In 'cbr' mode the '-q' setting
> is ignored because
On Sun, 9 Jan 2005, Steven M. Schultz wrote:
> On Sun, 9 Jan 2005, Trent Piepho wrote:
>
> > I thought that Dik meant the effective -q never went below 8, even though
> > it go have gone all the way to 4 and still be within the target bitrate.
>
> If that's ha
On Wed, 19 Jan 2005, Richard Ellis wrote:
> encode it. Otherwise, once I had test1, test2, ... testx, I would
> have forgotten what setting was used for testy. And maintaining that
I prefer to use URGHA~1.MPG, URGHA~2.MPG, ... URGHA~x.MPG
---
On Thu, 20 Jan 2005, Jonathan Woithe wrote:
> > > Yup :). figured as much and started shooting at it with CC='gcc-3.3'
> > > and CXX='g++-3.3', with a good about of success. the resulting error
The cvs verion of mplex has a build process that is the worst example automake
hell I've ever seen.
On Wed, 19 Jan 2005, James Klicman wrote:
> I think it would be beneficial if all of the yuv4mpeg utilities added
> an Xmetadata tag to it's output which included it's name and arguments.
Now that's a good idea. There is a dataformat used for scientific data called
NetCDF. Standards conforming n
On Wed, 19 Jan 2005, Steven M. Schultz wrote:
> On Wed, 19 Jan 2005, Trent Piepho wrote:
>
> > That's it! You can compile and link mplex with one single g++ command!
>
> I don't see anywhere in that one line the building of the libmplex
> shared libra
On Wed, 19 Jan 2005, Steven M. Schultz wrote:
> On Wed, 19 Jan 2005, Trent Piepho wrote:
>
> > Nothing uses the libmplex shared library, so that's not a problem.
>
> mplex uses it.
It doesn't need to be a library, you can just compile all the source into a
sin
On Thu, 20 Jan 2005, Michael Hanke wrote:
> Am Donnerstag 20 Januar 2005 11.09 schrieb Dave Dodge:
> > On Wed, Jan 19, 2005 at 07:31:45PM -0800, Trent Piepho wrote:
> > > On Wed, 19 Jan 2005, Steven M. Schultz wrote:
> > [...]
> > > Have you tried upgrading autoco
On Thu, 20 Jan 2005, Steven Boswell II wrote:
> Eh? It was my understanding that the lines of the
> top field were stored at even y indices, and the
> lines of the bottom field were stored at odd y
> indices, in the YCbCr data returned by
> y4m_read_frame(). The code for y4m_read_fields()
> certa
On Thu, 20 Jan 2005, Steven Boswell II wrote:
> OK, I'm pretty sure I understand this. But
> wouldn't I have to have 4:4:4 data (i.e. 720x480
> chroma data to go along with my 720x480 intensity
You only need 4:2:2 or 4:1:1, something that isn't subsampled vertically. 1:2
or 1:4 horizontal subsa
On Tue, 25 Jan 2005, E.Chalaron wrote:
> I was wondering what could be the most efficient method to slow down a movie.
> I have here some Super 8mm material that I reshoot frame by frame in ppm
> files.
Most efficient would be to create a custom soft-pulldown that goes from 18 to
25 or 50 since
On Tue, 25 Jan 2005, E.CHALARON wrote:
> On Tue, 2005-01-25 at 15:40, Trent Piepho wrote:
>
> > Most efficient would be to create a custom soft-pulldown that goes from 18
> > to
> > 25 or 50 since you are using pal. Something like 2:3:3:3:2:3:3:3:3 will
> > conver
On Wed, 26 Jan 2005, E.Chalaron wrote:
> Anyway I have another small thing here.
> A 400 ft reel of Super 8 comes to 28800 individual frames, which is obviously
> too much to handle for bash/cat
Did you really take 28800 individual pictures by hand?
> I know that
> find . -name \*.tga | xargs
On Thu, 27 Jan 2005, Maarten de Boer wrote:
> > the following is (of course) sending me back an error
> >
> > find . -name \*.ppm | ppmtoy4m | blabla
>
> How about
>
> find . -name \*.ppm -exec ppmtoy4m {} \; | blabla
That won't work, as you can't just cat y4m streams together. The have headers
On Thu, 27 Jan 2005, Lehmeier Michael wrote:
> I record from a TV card with the following command:
> mencoder -tv driver=v4l2:input=3:adevice=/dev/dsp:forceaudio tv:// -ovc
> lavc -oac pcm -lavcopts vcodec=mpeg4:vbitrate=3000:keyint=50 -endpos
> 700mb -vf pp=lb -o out.avi
>
> As a test I tried the
mpeg2enc doesn't seem to work correctly when I use the -M option for multi-cpu
encoding.
I tired encoding a stream with these options:
-f 5 -B 299 -S 700 -K kvcd -a 2 -p -g 6 -G 25 -b 2500 -q 3 --dualprime-mpeg2
and then the same exact options with -M 2 added.
Without -M 2, mpeg2enc generates a
On Wed, 2 Feb 2005, Steven M. Schultz wrote:
> On Wed, 2 Feb 2005, Trent Piepho wrote:
>
> > mpeg2enc doesn't seem to work correctly when I use the -M option for
> > multi-cpu
> > encoding.
>
> Did you do a 'cvs update' recently (within the l
On Tue, 15 Feb 2005, Steven M. Schultz wrote:
> Go thru the references and you'll find that NTSC full frame is 704x480
> NOT 720x480. If you really want 720x480 I'll get to that in a minute
> or two...
Actually, you'll find the full frame is 710.85x486. This number is difficult
On Tue, 15 Feb 2005, Steven M. Schultz wrote:
> On Tue, 15 Feb 2005, Trent Piepho wrote:
>
> > There is no need to do anything special for 720x480 instead of 704x480, you
> > can use the same math.
>
> What about the difference in SAR between D1 and DV/DVD? If i
On Sat, 21 May 2005, Matt wrote:
> Hello all,
>
> I have an input file which was rendered in 720x406 (1.77:1) but, I need
> to encode it for dvd which means 720x480. Is there some what to tell
> mpeg2enc to fill out the top and bottom borders without regenerating the
> content?
>
> If not, is the
On Tue, 24 May 2005, Steven M. Schultz wrote:
>
> There are tools in mjpegtools that can fix up the header (it's a bit
> ugly but it works ;)). You can use 'y4mtoyuv' to strip off the bogus
> header, and then use 'yuvtoy4m ...' to explicity specify all attributes
> of the
On Wed, 15 Jun 2005, Steven M. Schultz wrote:
> mpeg2enc -D 10 -G 15 -b 6400 -c --dualprime-mpeg2 -E -10 -f 8 -q 2 -K
> tmpgenc -4 1 -2 1 -o $N.m2v
> --
>
> Hardly seems worth the cpu cycles to do the telecine removal.
>
> Anyone care to guess why encoding 20
On Thu, 16 Jun 2005, Steven M. Schultz wrote:
> On Wed, 15 Jun 2005, Trent Piepho wrote:
>
> > On Wed, 15 Jun 2005, Steven M. Schultz wrote:
> > > mpeg2enc -D 10 -G 15 -b 6400 -c --dualprime-mpeg2 -E -10 -f 8 -q 2
> > > -K tmpgenc -4 1 -2 1 -o $N.m2v
> >
On Thu, 16 Jun 2005, Steven M. Schultz wrote:
> On Thu, 16 Jun 2005, Matto Marjanovic wrote:
>
> >"If mpeg2enc is told to encode N seconds of material with a target
> > bitrate of M bits/second... then the resulting file should be
> > roughly the N*M bits long, no matter what it is enc
On Wed, 29 Jun 2005, Oliver Seufer wrote:
> > > 1. sox NAME.wav -t raw -x -s -w -c2 -r48000 NAME.lpcm
> > > 2. mplex -S 0 -f 8 -V -o NAME.mpg NAME.lpcm NAME.m2v
> > >It make no different if I also use "-L 48000:2:16"
> > > 3. Try to play this file with mplayer and xine. Video is OK, but Sound
>
> So, if I have 24000:1001 material and I want to encode for NTSC DVD, I
> need to specify -F 4 -p (not -F 1 -p). This way, the encoded file has a
> DVD-compliant frame rate (3:1001) with the proper MPEG flag telling
> the decoder to do pulldown (to reconstruct the 24000:1001 video from the
> e
On Sun, 22 Jan 2006, Bob Stia wrote:
> On Saturday 21 January 2006 05:41, Andrew Stevens wrote:
> > >
> > > **ERROR: [mplex] Can't find next AC3 frame: @ 349129984 we have 04c3 -
> > > broken bit-stream?
> > > linux:/workspace # ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> >
> > AC3 audio frames have a he
On Fri, 10 Mar 2006, Ronald S. Bultje wrote:
> one of those should turn off AGC, the datasheet isn't totally clear to
> me, both controls are called AGC (see page 46 and 48 of the datasheet on
> the driver website if you're interested). After reloading the driver,
I think there was a setting calle
On Fri, 17 Mar 2006, Steven M. Schultz wrote:
>
> MPlayer's slightly off - but 1.36 is quite close to 1.33. MPlayer
> is printing the DAR and 1.36 is ~4/3 which is correct (unless your
> video is anamorphic 16:9 ;)).
mplayer is right about the DAR. If you do the math, (720*10)/
On Sat, 18 Mar 2006, Steven M. Schultz wrote:
> On Sat, 18 Mar 2006, Trent Piepho wrote:
>
> > mplayer is right about the DAR. If you do the math, (720*10)/(480*11) =
>
> Actually mplayer either off or the input stream is incorrect.
>
> Take a 720x480 MPEG-2 f
On Thu, 28 Sep 2006, Andrew Piecka wrote:
> 2. There are some odd image artifacts that appear at certain spots on an
> image that look like a checkerboard. I originally got the DC10+ with
> Pinnacle Studio and had never noticed this image problem when recording
This looks a lot like chroma noise
On Fri, 7 Mar 2008, Andrea Giuliano wrote:
> Okay, you and Burkhard suspect radio interference. But you have not seen
> the full pictures I sent to Bernhard Praschinger. In those picture you
> could see that the pattern is not spread all over the frame: the trunks
> of the trees, and the rocks too,
On Mon, 10 Mar 2008, Andrea Giuliano wrote:
> Trent Piepho wrote:
> >
> > It looks a lot like chroma interference with the luma signal. It could be
> > caused by an incorrect comb filter setup in the video decoder.
>
> What do you mean exactly? Is there some v4l con
On Thu, 13 Mar 2008, Bernhard Praschinger wrote:
> Andrea Giuliano wrote:
> > I found this interesting link:
> >
> > http://www.linuxtv.org/v4lwiki/index.php/Color_problem_patch
> >
> > that could be of some help. The pictures there show exactly the same
> > problem I get. The author first thought
: Jean Delvare <[EMAIL PROTECTED]>
> Cc: Trent Piepho <[EMAIL PROTECTED]>
> Cc: Ronald S. Bultje <[EMAIL PROTECTED]>
> ---
> Trent, this bug was introduced by this patch of yours:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=603d6f2c8f9
On Wed, 3 Sep 2008, Jean Delvare wrote:
> Restore the default pixel format to YUYV as it used to be before
> kernel 2.6.23. It was accidentally changed to BGR3 by commit
> 603d6f2c8f9f3604f9c6c1f8903efc2df30a000f.
Default pixel format should only matter for people doing cat /dev/video0,
and in tha
On Wed, 3 Sep 2008, Jean Delvare wrote:
> I see the following as a definitive improvement compared to the
> previous situation. It's probably possible to improve it further and I
> welcome comments in that direction. In general I would like to know how
> other Zoran developers and users feel about
On Mon, 16 Mar 2009, [ISO-8859-1] Facundo Ariel P?rez wrote:
> I've a Miro DC10 plus card running with ubuntu 8.10 ( 64 bits
> kernel 2.6.27 ) on a intel dual core using the zr3606? module as
> driver. As far as I've read (
> http://mjpeg.sourceforge.net/driver-zoran/cards.php ) it is supposed
> th
e this in it. Patch is fine.
Acked-by: Trent Piepho
>
> diff --git a/drivers/media/video/zoran/zoran_driver.c
> b/drivers/media/video/zoran/zoran_driver.c
> index 092333b..0db5d0f 100644
> --- a/drivers/media/video/zoran/zoran_driver.c
> +++ b/drivers/media/video/zoran/zor
st
format in the array doesn't have the requested type then num will still be
-1 when it's compared to fmt->index and there will appear to be a match.
Restructure the loop so this can't happen. It's simpler this way too. The
unnecessary check for (unsigned)fmt-&
On Mon, 30 Dec 2002 [EMAIL PROTECTED] wrote:
> > It's time consuming, definately, but the results are worth it.
>
> For material that you want to keep on a long term basis this might be
> true. But I am looking for PVR functionality here. Record a one-hour
> television show, watch it, delete it.
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 in size. I converted it
Try lowering the resolution and quality the
On Mon, 30 Dec 2002, Steven M. Schultz wrote:
>
> The two .mpg files:
>
> -rw-rw-r-- 1 sms wse 144355260 Dec 30 18:55 chicken-y4mscaler.mpg
> -rw-rw-r-- 1 sms wse 146821024 Dec 30 16:45 chicken-yuvscaler.mpg
>
> Not bad at all!
Does the smaller output size actually mean y4m
On Tue, 31 Dec 2002, Andrew Stevens wrote:
> It would be mega-fantastic if we could tweek the drivers to capture MJPEG at
> SVCD resolution. I think the Zoran chipset / video decoders can actually
> support this. The necessary driver tweaking would be pretty fiddly
> though...
I don't that
On Fri, 7 Feb 2003, Steven Boswell wrote:
> >>Can you recall any of the nasty details of what made you dislike the
> >>card so much?
> >
> >My biggest problem with the LML33 was that Linux Media Labs had this
> >awesome card with killer specs on paper, it looked like exactly what I
> >needed to do
On 14 Mar 2003, scott wrote:
> I have an NTSC 30fps interlaced laserdisc with some footage which I am
> told was originally 24fps. I have run lavrec, then yuvscaler -M
> LINE_SWITCH and the result looks good, except frames 4/5 from each
> sequence of 5 have a interlace effect. I then run yuvkinec
On Sat, 2 Aug 2003, Steven M. Schultz wrote:
> > From: Ronald Bultje <[EMAIL PROTECTED]>
> > Yes, we had that before. I don't know what it was. Either it was a bug
> > in nasm (we've had that a few times), or it was a bug in too high
> > optimization, or it was something else that was our bug. Try
On 3 Aug 2003, Ronald Bultje wrote:
> Hey Trent,
>
> On Sun, 2003-08-03 at 00:09, Trent Piepho wrote:
> > I don't think "fixes" is really the correct term, more appropriate would be
> > "masks". If the code fails with -O3, then there is eithe
The help from the configure script no longer lists the --with-jpeg-mmx option,
even though it appears to still exist. If the script doesn't guess where
jpeg-mmx is, there is no error most users (especially those who don't know to
look) are going to notice. The result is no MMX jpeg, which is a pr
On Tue, 26 Aug 2003, Martin Samuelsson wrote:
> The man page has this to say:
>
>-l num
> Specifies the nummber of loops (default: 0 loops )
> When this option is not used the given range of images is only
> processed once. If you use this option and as
On Mon, 3 Nov 2003, Andrew Stevens wrote:
> > Hmmm, without the -I 0 I only get about 15 Frame/sec on my Athlon
> > 2800. Does -I 0 make that big of a difference?
>
> -I 0 really does make that big a difference. If you know you don't have
> interlaced material then you should always us
On Mon, 1 Dec 2003, Ronald Bultje wrote:
> On Mon, 2003-12-01 at 00:06, Steven M. Schultz wrote:
> > As a temporary measure you can try editing the compat function
> > posix_memalign to return an aligned address. NOTE: this will result
> > in a pointer that can NOT be passed to 'free(
On Tue, 16 Dec 2003, Richard Ellis wrote:
> > 6 or 8GB/s L2. The cache size is 256k/CPU, 64k L1. At 550MB/s, it
> > SHOULD be able to push enough to keep the frames encoding at 100%
> > CPU, in theory.
>
> Yes, but just one 720x480 DVD quality frame is larger than 256k in
> size, so a 256k cache
On Tue, 16 Dec 2003, Steven M. Schultz wrote:
> > First off a bit of background to the multi-threading in the current stable
> > branch. First off:
> >
> > - Parallelism is primarily frame-by-frame. This means that the final phases
> > of the encoding lock on completion of the reference frame
On Fri, 19 Dec 2003, Andrew Stevens wrote:
> The next bottlenecks would be the run-length coding and the use of variance
> instead of SAD in motion compensation mode and DCT mode selection. Sadly
Is SAD really any faster to calculate than variance? SAD uses an absolute
value-add operation whil
On Fri, 19 Dec 2003, Steven M. Schultz wrote:
> On Fri, 19 Dec 2003, Trent Piepho wrote:
>
> > On Fri, 19 Dec 2003, Andrew Stevens wrote:
> >
> > Is SAD really any faster to calculate than variance? SAD uses an absolute
> > value-add operation while variance is
75 matches
Mail list logo
