Re: [Mjpeg-users] [Mjpeg-developer] yuvdenoise performance patch
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" > To: mjpeg-users@lists.sourceforge.net > Sent: Tuesday, October 12, 2010 6:17:56 AM > Subject: Re: [Mjpeg-users] [Mjpeg-developer] yuvdenoise performance patch > > > gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../utils -O3 -funroll-all-loops > -ffast-math -march=nocona -mtune=nocona -g -O2 -I/sw/include -no-cpp-precomp > -D_THREAD_SAFE -Wall -Wunused -MT main.o -MD -MP -MF .deps/main.Tpo -c -o > main.o main.c > > main.c: In function ‘filter_plane_median_sse2’: > > main.c:814: warning: unused variable ‘cnt’ > > main.c:813: warning: unused variable ‘avg’ > > main.c: In function ‘main’: > > main.c:1332: error: PIC register ‘ebx’ clobbered in ‘asm’ > > main.c:1337: error: PIC register ‘ebx’ clobbered in ‘asm’ > > make[2]: *** [main.o] Error 1 > > make[1]: *** [all-recursive] Error 1 > > make: *** [all] Error 2 > > Hi Christian, > I'm not sure how to fix your particular issue, but it seems that there are > quite a few instances of that issue in Google that you might want to > research: > > http://www.google.com/search?q=error%3A+PIC+register+%E2%80%98ebx%E2%80%99+clobbered+in+%E2%80%98asm%E2%80%99&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a > > scott > > > -- > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > ___ > Mjpeg-users mailing list > Mjpeg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mjpeg-users > -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [Mjpeg-developer] yuvdenoise performance patch
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
> file
> > and look for the sse2 or whatever flag.
>
> There is no /proc/ directory on MacOS X.
>
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 support that might not be there. I.e., the cpu supports sse2
but you're not actually able to use it. Probably not much of issue on OSX.
Easy fix would just be the change the sse detection asm to save and restore
ebx.
__asm__ volatile("pushl %%ebx ; cpuid ; popl %%ebx" : "=d"(d) : "a"(1) :
"ecx");
or better
uint32_t tmp;
__asm__ volatile("movl %%ebx, %1; cpuid; movl %1, %%ebx" : "=d"(d),
"=&g"(tmp) : "a"(1) : "ecx");
The latter is safer in general, as you can't use push or pop around any asm
code that has a parameter with a constraint that allows memory references.
The memory reference might be relative to esp, in which case the push/pop
would move it. Or it might not be relative to esp, in which case the
push/pop doesn't move it. So there's no way to adjust for it.
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [Mjpeg-developer] yuvdenoise performance patch
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 support that might not be there. I.e., the cpu supports
> >> sse2 but you're not actually able to use it. Probably not much of issue
> >> on OSX.
> >>
> >> Easy fix would just be the change the sse detection asm to save and
> >> restore ebx.
> >>
> >> __asm__ volatile("pushl %%ebx ; cpuid ; popl %%ebx" : "=d"(d) : "a"(1) :
> >> "ecx");
> >>
> >> or better
> >>
> >> uint32_t tmp;
> >> __asm__ volatile("movl %%ebx, %1; cpuid; movl %1, %%ebx" : "=d"(d),
> >> "=&g"(tmp) : "a"(1) : "ecx");
> >>
> >> The latter is safer in general, as you can't use push or pop around any
> >> asm code that has a parameter with a constraint that allows memory
> >> references. The memory reference might be relative to esp, in which
> >> case the push/pop would move it. Or it might not be relative to esp, in
> >> which case the push/pop doesn't move it. So there's no way to adjust
> >> for it.
> > I tested your better version. And it compiles here on my linux and Intel
> > osx box. I did also a quick test with the new version on the linux box.
> > And it works well.
> >
> > So I would appreciate a feedback if it works on a mac.
>
> Thanks for looking into this, but I get:
>
> gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../utils -O3 -funroll-all-loops
> -ffast-math -march=nocona -mtune=nocona -g -O2 -I/sw/include -no-cpp-precomp
> -D_THREAD_SAFE -Wall -Wunused -MT main.o -MD -MP -MF .deps/main.Tpo -c -o
> main.o main.c
> main.c: In function ‘main’:
> main.c:1339: error: PIC register ‘ebx’ clobbered in ‘asm’
> make: *** [main.o] Error 1
>
Looks like you didn't actually change the needed lines.
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [Mjpeg-developer] yuvdenoise performance patch
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 detection asm to save and
> >>>> restore ebx.
> >>>>
> >>>> __asm__ volatile("pushl %%ebx ; cpuid ; popl %%ebx" : "=d"(d) : "a"(1)
> :
> >>>> "ecx");
> >>>>
> >>>> or better
> >>>>
> >>>> uint32_t tmp;
> >>>> __asm__ volatile("movl %%ebx, %1; cpuid; movl %1, %%ebx" : "=d"(d),
> >>>> "=&g"(tmp) : "a"(1) : "ecx");
> >>>>
> >>>> The latter is safer in general, as you can't use push or pop around
> any
> >>>> asm code that has a parameter with a constraint that allows memory
> >>>> references. The memory reference might be relative to esp, in which
> >>>> case the push/pop would move it. Or it might not be relative to esp,
> in
> >>>> which case the push/pop doesn't move it. So there's no way to adjust
> >>>> for it.
> >>> I tested your better version. And it compiles here on my linux and
> Intel
> >>> osx box. I did also a quick test with the new version on the linux box.
> >>> And it works well.
> >>>
> >>> So I would appreciate a feedback if it works on a mac.
> >>
> >> Thanks for looking into this, but I get:
> >>
> >> gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../utils -O3 -funroll-all-loops
> >> -ffast-math -march=nocona -mtune=nocona -g -O2 -I/sw/include
> -no-cpp-precomp
> >> -D_THREAD_SAFE -Wall -Wunused -MT main.o -MD -MP -MF .deps/main.Tpo -c
> -o
> >> main.o main.c
> >> main.c: In function ‘main’:
> >> main.c:1339: error: PIC register ‘ebx’ clobbered in ‘asm’
> >> make: *** [main.o] Error 1
> >
> > Looks like you didn't actually change the needed lines.
>
> No, I didn't but Bernhard did:
> +
> #if defined(__SSE2__)
>int d = 0;
> - __asm__ volatile("cpuid" : "=d"(d) : "a"(1) : "ebx", "ecx");
> +/* __asm__ volatile("cpuid" : "=d"(d) : "a"(1) : "ebx", "ecx"); */
> + __asm__ volatile("movl %%ebx, %1; cpuid; movl %1, %%ebx" : "=d"(d),
> "=&g"(tmp) : "a"(1) : "ecx");
>if ((d & (1 << 26))) {
>mjpeg_info("SETTING SSE2 for standard
> Temporal-Noise-Filter");
>temporal_filter_planes = temporal_filter_planes_sse2;
>
The second cpuid call below this one needs to be fixed as well.
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [Mjpeg-developer] yuvdenoise performance patch
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: yuvdenoise/main.c
> ===
> RCS file: /cvsroot/mjpeg/mjpeg_play/yuvdenoise/main.c,v
> retrieving revision 1.71
> diff -u -r1.71 main.c
> --- yuvdenoise/main.c 14 Oct 2010 16:57:54 - 1.71
> +++ yuvdenoise/main.c 15 Oct 2010 17:58:13 -
> @@ -1336,7 +1336,8 @@
> mjpeg_info("SETTING SSE2 for standard
> Temporal-Noise-Filter");
>temporal_filter_planes = temporal_filter_planes_sse2;
>
> - __asm__ volatile("cpuid" : "=d"(d) : "a"(0x8001) :
> "ebx", "ecx");
> +/*__asm__ volatile("cpuid" : "=d"(d) : "a"(0x8001) :
> "ebx", "ecx");*/
> + __asm__ volatile("movl %%ebx, %1; cpuid; movl %1, %%ebx" :
> "=d"(d) : "a"(0x8001) : "ecx");
>
Not quite right. It should look the exactly the same as the first one, with
"=&g"(tmp) as an output, except the number after the "a"
should still be 0x8001.
--
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [patch] [media] zoran: remove duplicate ZR050_MO_COMP define
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 I fixed the zoran kernel driver to work with tv apps like mplayer, xawtv, and tvtime. It's not v4l1 only. The compressed capture OTOH, I don't think was every updated to work with V4L2 compressed capture spec. Probably because lavtools also wasn't updated to use V4L2 compressed capture. This driver does serve as a nice reference for any complex video hardware, since it does uncompressed capture, video overlay, and compressed capture. I'm not aware of any other driver than can do all three. As these are PCI cards, they can't really be used in newer computers anyway. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] What is causing this error
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)))
> {
> free(buf);
> buf = memalign(pgsize, size);
> }
Could this be done at configure time? Check the glibc version or have
autoconf run a test program to see if posix_memalign works?
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Dropped sound sequences
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 that > situation it would be the responsibility of the creator to insure > that all files are equal qualities that match the original format. > Or a separate util to strip the format info. Also, mpeg2enc could > be instructed to ignore subsequent format info. Or you could do what I did. I wrote a program called y4mcat, that works like cat but for y4m files. It reads the header from each file first, and if they all match, properly cats them stdout. By reading the header first, you avoid running mpeg2enc for 10 hours only to find out one of your jpg files was the wrong resolution. Not that I've ever done that. If there is an interest, I'll submit it to the mjpegtools project. I added support for syntax such as: lav2yuv foo.el | y4mcat header.y4m - "|ppmtoy4m -n 10 -r image.ppm" | mpeg2enc That would cat the y4m file (or pipe) called header.y4m, the output of lav2yuv as the standard input, and them the output of the ppmtoy4m command. I even added support for the sendfile() syscall for y4m files. It lowers CPU usage a lot, not that cating a file uses much, but it's still an impressive improvement. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Encoding aspect ratio for SVCD
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 every 4th line, rather than > by doing any quality interpolation. Far better to do the scaling If if the DVD player does do quality interpolation, you're still wasting one fifth of your bits encoding the lines it interpolates away. 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 you encode. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Encoding aspect ratio for SVCD
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 you encode. > > Do such TVs have enough vertical pixels to honestly display the > compressed image, or do they just effectively perform analog You never know, but that features is usually only found on high end sets. Like the ones that can display progessive scan DVD at 480p or 540p/720p 4:3 HD sets. I'm sure someone has compared 16:9 in the TV vs in the DVD player for some sets. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] DVD frame rate
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 > > 8 - 60.0 > > So things like 20 or 18 are NOT legal MPEG-2 (besides which they > can't be produced by mpeg2enc ;)). To get 18, couldn't you use 60 fps with a 3:3:4 pulldown? Same concept as a 24 to 60 via 2:3 pulldown. You need some way to tell mpeg2enc to insert repeat last field commands like it can do with a 2:3 pulldown. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Interlacing a progressive stream?
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 computer via firewire? I guess if you wanted to play it back on a HDTV set, you would need a set with a firewire input, or a DVI-HDCP input and a videocard with a DVI output that worked with a TV set. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Monitoring BUZ recordings.
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, the buz is almost the same. I did have problems if I tried to start and stop overlay while capturing, and I don't know if that's fixed. Just make the window really small. B. Buy a second cheap non-codec TV card, feed the buz output into it, watch via your computer with that card. C. Add a feature to lavrec to write out a jpeg file every X frames. Should be easy to do. Now you can just look at the jpeg. D. Just listen to the audio via your sound card's line out, and tell by that. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
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 have no trouble setting my bt848 to capture at 720x480. This is since before v4l1 existed. --- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] CVS version of mpeg2enc vs the last 'release'
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, so I assume I'm OK, but could give > capturing at 704x480 a shot. See this, http://www.arachnotron.nl/videocap/site/capture_area2.html In short, if you are converting to DVD, you want to tell your card to capture at 13.5 MHz. This is the rate specified in the standards and the rate the DVD will be played back at. Most capture card drivers have a fixed idea about what length of a line, in microseconds, they should capture. If the driver thinks is should capture a line 53.33 us long, then 720 pixels gives you a sample rate of 13.5 MHz. If the driver thinks a line is 52.15 us long, then you only get 704 samples. Finally, a 52.67 us long line is 711 samples at 13.5 MHz. All of those line length are used by something. 53.33 was specified by CCIR-601 and is used by DVDs, SVCDs, DV, and professional systems. 52.67 is the active length as specified in the NTSC standard, and is also used in the bt848 datasheet. 52.15 is used by VCDs, DVDs in 704x480 mode, and 640x480 square pixel captures. So which does you card use? If you look at that page, they have a DVD or SVCD test track which you can play on a DVD player. Capture it and compare to the original image. By comparing the scale lines, you can tell what you card is doing. Of course, if you have an open source driver, you can just look at the source to see what the driver is using, and change it to the correct value for what you want. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] CVS version of mpeg2enc vs the last 'release'
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 640 pixels by 12 3/11 MHz you get 52.15 microseconds, the same things you get if you divide 704 pixels by 13.5 MHz. > TV stations when they are broadcasting a digital stream use 704x480. > That's also what they use internally (well, they use 486 lines Are you sure about that? D1 video is 720 pixels at 13.5 MHz, as specified in the ITU-R.601 standard. I know that if you check most (all?) DVDs, you will find that they do in fact have 720 pixels (@ 13.5MHz) of information. The 8 pixel border on each side is not just black. > analog processing. It doesn't make sense to get 720 samples where > only 704 were broadcast. Does it? There are reasons to get 720 samples when you only care about the inner 704, which is why R.601 specified 720 samples and not 704. Many scaling and other image processing algorithms have edge effects. The extra border provides a safe area for processing artifacts that keeps the important part of the image clear. Another reason is that while a digital image has no trouble putting a 0 value black pixel next to a full value white pixel, such a singal cannot be created by analog systems as it would require too much (as in infinite) bandwidth. Starting the picture early provides a safe border for ringing effects caused by the change from the blanking interval to active pixels. > It might also be possible to dig around in the bttv-driver.c module > in the kernel and combine that with the Bt8x8 datasheets (which I had At which point you would find... .v4l2_id= V4L2_STD_NTSC_M, .name = "NTSC", .swidth = 768, .totalwidth = 910, .scaledtwidth = 910, xsf = (width*scaledtwidth)/swidth; geo->hscale = ((totalwidth*4096UL)/xsf-4096); HSCALE is the register of interest, it controls the effective sampling rate. So for NTSC, after some algebra: HSCALE = (768 / width - 1) * 4096 And with a little math and the datasheet: Effective Sampling Rate = 14.32 MHz / (HSCALE/4096 + 1) Combine the two... Effective Sampling Rate = 14.32 * (width / 768) and Width = Effective Sampling Rate/14.32 * 768 So, 13.5 Mhz you would want to request a width of 13.5/14.32 * 768 or 724 pixels! If you ask for 720, you're getting a sample rate of 13.425 MHz. I think the driver is wrong to set swidth to 768, which gives a capture length of 54.63 us. Better would be 764, for a capture length of 53.33 us, the R.601 standard. I'm guessing 768 was chosen because it's divisible by 16, but I can't see any reason why this value needs to be divisible by 16. > All in all it's an area I'm glad I moved out of :) But do you know what sample rate your canopus is using? It's supposed to use 13.5 since it's DV, but does it? Without datasheets and a driver to dig through, how can you know? --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Example: using y4mdenoise to achieve near-perfection with videotapes
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 it > from the VCR, then the VCR is doing color > separation. My Canopus ADVC-300 box has Not so! The format used on VHS and SVHS tapes has luma and chroma recorded separately. If you use the S-video connector, your VCR isn't doing color separation as the signals are already separate. When you use the composite output, your VCR is actually combining the signals and then they are getting re-separated by the canopus. Of course, if your tape's original source was broadcast TV, then the VCR did do color separation. It was done when you recorded composite TV signal. I suppose that if the original tape was made on a VCR with poor Y-C separation, that re-combining the signals on playback and then re-separating them in the canopus might give you better quality. > "raw2yuv -i 2" generates raw YUV data from DV > data, but with a 4:1:1 color scheme instead of > 4:2:0. In English, that means the color plane is > 720x480 instead of 360x240, like it needs to be I think you've got a typo there, 4:1:1 would be 180x480. 720x480 would be called 4:4:4. DV-NTSC is 4:1:1 and DV-PAL is 4:2:0, DVD and ATSC use 4:2:0, and D1 is 4:2:2. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Example: using y4mdenoise to achieve near-perfection with videotapes
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 CED. Of course if you recorded off TV, then it did start as a composite signal before it got to your VCR. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] y4mdenoise (in CVS) now does 2 processors!
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 ;) Obviously, CBR mode doesn't hold the instantaneous bitrate constant, by making every frame exactly the same size. Rather, it holds the bitrate constant over some short interval. Probably a hundred frames as most. When trying to fit something on a DVD or CD, all you care about is that the bitrate is constant over the *entire stream*. You could easily have higher than average bitrate for several thousand frames, followed by a lower than average for several thousand more. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] y4mdenoise (in CVS) now does 2 processors!
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 the encoder is controlling it and I have seen > the effective -q go down to 3 or less. > > With CBR the encoder will vary the 'quality' - look at the "quant=" > lines that get logged and you'll see the effective "-q" as the > encoder is running. 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. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] y4mdenoise (in CVS) now does 2 processors!
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 happening it's a Bug. It might start out at 8 but > with 'cbr' I've seen the encoder vary (and over a wide range) the > effective -q in order to keep close to the specified bitrate. Even if the CBR mode didn't have this bug, it's still fundamentally at a disadvantage vs VBR. The reality is that a given stream will have some parts which are more complex and need more bits to encode than other parts. In VBR mode the encoder can use fewer bits for the easy parts and more bits for the hard parts. In CBR mode the encoder is forced to waste bits on the easy parts when the extra bits result in little improvement, and then it is forced to drop quality on the hard parts when using some extra bits would result in a large improvement. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Achieving near-perfection with NTSC videotapes of 24fps films
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 --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplexing DTS streams, nearly
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. This is all you need to do to build CVS mplex, if you build the mjpeg library in the utils directory first. This works with both egcs-2.91.66 and gcc-3.2.2, and probably every other verion of g++ there is too. It doesn't matter which verions of automake, autoconf and libtool you have. # remove dead code that isn't used rm vector.cpp vector.hpp # remove Z/Alpha files rm zalphastrm.hpp zalphastrm_in.cpp zalphastrm_out.cpp # compile and link everything! g++ -DHAVE_CONFIG_H -I ../utils -I.. *.cpp ../utils/.libs/libmjpegutils.a That's it! You can compile and link mplex with one single g++ command! That's it, one command that fits on one line! For some reason autohell needs a ONE THOUSAND LINE Makefile to do this, and it doesn't even work! When a package that is so simple it doesn't even need a makefile has a build process so complex that people are told they need to switch distributions to build it, that's a sign autohell has gone seriously out of control. Getting mjpegtools CVS to build on my old system was 10 times harder than getting mplayer to, and given that mplayer is about 100 times more complex than mjpegtools, that says something about the mjpegtools build process, and that something isn't good. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Achieving near-perfection with NTSC videotapes of 24fps films
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 netcdf files have a history attribute, and every time you pass them through some program to modify them, that program will add the operation (usually as a copy of the command line) to the history. No reason you couldn't add history metadata to the yuv4mpeg header. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplexing DTS streams, nearly
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 libraries - that's what most of the build stuff is for. Nothing uses the libmplex shared library, so that's not a problem. > > That's it, one command that fits on one line! For some reason autohell > > needs > > a ONE THOUSAND LINE Makefile to do this, and it doesn't even work! > > Makefile.am is 76 lines long and guess what? Works flawlessly on > everything from an obsolete BSD variant up thru OS/X on to several > different Linux distributions and a modern BSD variant or two. I've never found a system where it worked flawlessly, and from the traffic on this list, it seems I'm far from alone. I could write a normal makefile, that creates the (unnecessary) library, and it would be a less than 76 lines, and a lot less than one thousand lines. > > process so complex that people are told they need to switch distributions to > > build it, that's a sign autohell has gone seriously out of control. > > auto* is a bit of a mess in general but I can't call a 76 line > automake file "seriously out of control". It does have minimum > versions of the autohell tools required but that's not unusual. The minimum versions must be very bleeding edge, when redhat 9 and slackware 10 don't even have them. Besides that, mplex isn't a complex program, it doesn't need bleeding edge versions of autohell to compile. The build process is far more complex than it needs to be, and a lot of people are having trouble building it as a result. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplexing DTS streams, nearly
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 single program with one command, and it words fine. > Most of the problems arise from older systems where folks have > piecemeal upgraded things - that results in a mixed bag of old Have you tried upgrading autoconf on an old system? It's nearly impossible. > >I could write a normal makefile, that creates the (unnecessary) library, and > >it > > It's only unnecessary if you don't want to run mplex :) No, I can run mplex just fine without the library. It's faster too, since the shared library uses PIC code. In a degenerate case, you can turn a program with n source code files into n-1 shared libraries and one front-end program. There is no reason to do this, just like there is no reason to create a mplex shared library that only one program uses. It just creates unnecessary complexity. > > would be a less than 76 lines, and a lot less than one thousand lines. > > Sigh - you're fixated, just like the MPlayer/ffmpeg crowd, on the > size of the generated files and not the smaller human editable file. The "human" editable files are still large, and the generated files, when you can even generate them in the first place, result in a build process that is far more complex than it needs to be. I think simplicity is a virtue and complexity should be avoided. Seems the MPlayer/ffmpeg crowd agrees. Do you think something should be done in the most complex way possible? > > The minimum versions must be very bleeding edge, when redhat 9 and slackware > > No, not really. But their also not years old either (RH9 went end of > life a some time back - they're up to fedora 3 or whatever now). I'm still using a system based on redhat 5. It works fine. Built the cvs version of mplayer with almost no problems. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplexing DTS streams, nearly
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 autoconf on an old system? It's nearly > impossible. > > > > Well, yes and no. Installing updated vesions of the autotools is > > pretty straightforward if you're used to installing things from source. > [snip] Back when I first installed Linux, we didn't even have these new-fangled package managers! Installing from source and building your own kernel was the ONLY way. You want binaries? We got your SunOS and OSF/1 and Ultrix right here, WTF is Linux? Now days I think rpm, apt, etc. are a god-send to keeping a system organized and working. > > That will leave you with a clean, new autotools in your path. You can > > run autogen.sh and it should just ignore whatever versions happen to > > be installed by the system packages. > > > > That's the good news. Now for the bad news... > The bad news are that the mjpegtools do not live alone... There are tons of > programs which come with their own m4 macros. If you are using rpm, you will > certainly break a lot of dependencies. It is hard to know if these > dependencies are important or can be ignored... > > I believe that rpm has become something like a (one of a few) standard(s) of > making a system manageable with small effort. And the auto* tools do not come > with a *.spec file. Exactly what I was going to say. Once you install autohell from source, you've just broken rpm or whatever package management system you're using. You'll probably have two versions installed on top of each other using each other's files in random and broken ways. And good luck upgrading your packages or using something like up2date. Your m4 macros from other packages are now broken. Some are probably incompatible with the new version of autohell, so you'll just have to stop using that software. You can't build any software that doesn't yet work with the bleeding edge verion of autohell either. But what's really wrong about all this, is that a bleeding edge verion of autohell isn't needed at all. mjpegtool's build process isn't complex, there simply isn't any reason to make building it so hard. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Achieving near-perfection with NTSC videotapes of 24fps films
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() > certainly suggests that too. Which means I don't > see how interpreting the data as a frame or as two > fields changes the storage format of chroma or > anything else. If you have a progressive frame in 4:2:0, then the first chroma line is the average from lines 1 and 2. The second chroma line is the average of 3 and 4. If you have an interlaced frame, the first chroma line is the average of the first two lines of the first field. With the fields interleaved, they are lines 1 and 3. The second choroma line is from the first two lines of the second field, which are lines 2 and 4. Assuming top field first. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Achieving near-perfection with NTSC videotapes of 24fps films
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 subsampling is ok. BTW, the zoran mjpeg cards produce 4:2:2 and DV is 4:1:1... > data) in order to fix the chroma properly? Can I > even get that? Also, when dealing with an NTSC Depends on what you mean by properly. If you subsampled chomra to 4:2:0 in progressive mode, then you can't create what you would have gotten if you had subsampled in interlaced mode to begin with. But you can upsample to 4:2:2, then downsample in interlaced mode and at least try to cope. It's better than leaving the chroma as it is and pretending it was interlaced. > signal of something that was originally 24 fps, > i.e. the "not really interlaced" case, wouldn't > the color be subsampled according to progressive > frame rules? NTSC is not chroma subsampled vertically. Native NTSC chroma format is considered to be 4:2:2. Of course NTSC is analog and digital things like 4:2:2 and 4:2:0 don't apply, but you get the idea. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] pulldown or yuvfps
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 you are using pal. Something like 2:3:3:3:2:3:3:3:3 will convert 18 to 25. It would be a lot easier if you used NTSC framerates. Or you could covert to 25fps with yuvfps, but doing that will encode the duplicate frames, wasting bits. It won't be as smooth either. > The original are playing at a nominal rate of 18 fps. > Once encoded in mpeg2, grany is almost running through the TV screen. > I thought that pulldown would be an option to bring 18 to 24 but obviously > not since mpeg2enc is complaining about the rate The pulldown mpeg2enc uses incrases the frame rate by a ratio of 4:5. 24fps becomes 30. 18 would become 22.5 The reason mpeg2enc is complaining is that you are trying to use NTSC frame rates with pal sized frames. > ++ WARN: [mpeg2enc] 3:2 Setting frame rate code to display rate = 5 > (30.000fps) 30 fps is for NTSC. >INFO: [mpeg2enc] Horizontal size: 720 pel >INFO: [mpeg2enc] Vertical size: 576 pel This sized for PAL. >INFO: [mpeg2enc] Aspect ratio code: 1 = 1:1 pixels This is wrong, your pixels are not 1:1. Pick aspect code 2. > cat *.ppm | ppmtoy4m -F 18000:1000 -L | -F 18:1 would be sufficient. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] pulldown or yuvfps
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 > > convert 18 to 25. It would be a lot easier if you used NTSC framerates. > > Well not being a programer neither leaving in US/Canada It's gonna be a > little difficult... You'll need to be a programmer to add custom soft-pulldown support to mpeg2enc. NTSC just makes the pulldown a nicer sequence that will be smoother to watch. > > Or you could covert to 25fps with yuvfps, but doing that will encode the > > duplicate frames, wasting bits. It won't be as smooth either. > > > Ok I supected so ... It because a soft-pulldown can duplicate fields while yuvfps needs to act on whole frames. With a 2:3:3:etc pulldown, some fields are shown for 40 milliseconds, some for 60 milliseconds. With a frame based duplicator, you'll see some frames for 40 ms and some for 80 ms. Since NTSC has a faster flield rate, it would be 33ms vs 50 ms. > > The pulldown mpeg2enc uses incrases the frame rate by a ratio of 4:5. 24fps > > becomes 30. 18 would become 22.5 > > the difference between 22.5 and 25 is not huge ... No, it's not. You could use yuvcorrect to lie about your framerate, and change it from 18 to 20. Your movie will play about 11% fast now. You don't have audio to worry about, that's nice. Then a 2:3 pulldown will covert 20 to 25. Except. > > > ++ WARN: [mpeg2enc] 3:2 Setting frame rate code to display rate = 5 > > > (30.000fps) > > I assumed with this error that mpeg2enc pulldown will work only for NTSC > and therefore my question. y4mscaler however says to get it in PAL, so I > guess mpeg2enc would have follow. I understand then that -p will not > work in my case at all. It looks like mpeg2enc overrides your framerate with an NTSC one when you use the -p switch. It doesn't have to, it looks like a programming oversight. I wonder if you could just let mpeg2enc make you a 30 fps mpeg file, then change the rate code in the header from 5 to 3 to make it pal again? I don't know enough about mpeg to know if that will work. > > >INFO: [mpeg2enc] Aspe > > This is wrong, your pixels are not 1:1. Pick aspect code 2. > > I use a progressive camera I thought that pixels were 1:1. Probably are, but you used y4mscaler to change them from 1:1 to to 59:54. If you are making a pal DVD, you want your pixels to be 59:54 (or 118:81 if widescreen), or nothing will play it correctly. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] more telecine stuff
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 -n1 tgatoppm | ppmtoy4m | blabla
Try this:
find . -name \*.tga | xargs -n1 cat | ppmtoy4m
or
find . -name \*.tga -exec cat {} \; | ppmtoy4m
If find is not finding the files in the correct order, you may want
to do something like:
find .-name \*.tga | sort | xargs -n1 cat | ppmtoy4m
> An option would be to save in TGA.
If you used a digital camera, didn't it produce jpeg files? You'd get the
best quality be going from jpeg to y4m directly, without the ppm step.
Converting from jpeg to ppm involves a colorspace conversion (YUV->RGB) as
well as chroma re-sampling (4:2:0 -> 4:4:4). Going from ppm to y4m involves
converting back to YUV and 4:2:0. The files would probably be a lot smaller
too!
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] more telecine stuff
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
and interal structure that will be messed up. I wrote a program y4mcat that
lets you do this, but it wouldn't be useful in this case.
> find . -name \*.ppm | while read filename; do ppmtoy4m $filename; done |
Same problem, you can't cat the output from multiple ppmtoy4m streams together.
It'd be slower too, to restart ppmtoy4m for each frame.
You'd get better speed with something like:
find -name \*.ppm | xargs -n200 cat | ppmtoy4m
cat can't take 28800 files on the command line, but it can take more than 1.
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] lav2yuv problems with mencoder material
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 following line: > lav2yuv out.avi | yuvscaler -O VCD | mpeg2enc -s -o mpg.mpg lav2yuv only works on mjpeg avi files, it can't do other codecs like mpeg4. You need to use mplayer to generate the yuv4mpeg stream from the avi. mkpipe stream.yuv mplayer -vo yuv4mpeg:aspect=59/54 -nosound -benchmark -vf scale=352:288 out.avi & mpeg2enc -s -f 1 -o out.mpv < stream.yuv This will send yuv4mpeg output from mplayer into a pipe, which mpeg2enc will then read. This way you don't need the HUGE yuv file on disk. The scaler in mplayer is much much faster than yuvscaler, so use it with -vf scale and avoid calling yuvscaler. The aspect override requires a patch to mplayer that the mplayer people won't accept, so you'll probably want to omit it. Use the -n p -a 2 options in mpeg2enc to override the incorrect aspect info mplayer emits. To encode the audio, I've been doing this: mencoder -ovc frameno -oac toolame -toolameopts br=224 -o out.mpa.avi out.avi mplayer -dumpaudio -dumpfile out.mpa out.mpa.avi rm out.mpa.avi You can use lavc instead of toolame, but I've heard toolame is suposed to be better quality, while lavc is about twice as fast. You could always encoder to mp2 when you capture your tv program, instead of using pcm, if you have enough cpu for it. It seems that mencoder will only output an avi file, so you have to write an avi with the mpeg audio, then use mplayer to dump the audio out of the avi file. Once you have the mpa and mpv MPEG-ES files, you multiplex them a MPEG-PS file with mplex, and then that can be mastered into a vcd image with vcdimager. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] problem with mpeg2enc and -M option
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 stream of about 550 MB that mplex (with options -f 5 -r 0 -V) will accept without trouble. I can create a svcd with vcdimager and watch it on my DVD player with no problems. With -M 2, mpeg2enc doesn't have any trouble generate a mpeg2 stream. However, when I try to mplex it, mplex complains there are multiple sequences, and I need to put a %d in the filename: INFO: [lt-mplex] Scanned to end AU 1 ++ WARN: [lt-mplex] No seq. header starting new sequence after seq. end! INFO: [lt-mplex] Scanned to end AU 5 ++ WARN: [lt-mplex] No seq. header starting new sequence after seq. end! [snip] INFO: [lt-mplex] Video e0: buf= 13783 frame=01 sector=0006 INFO: [lt-mplex] New sequence commences... INFO: [lt-mplex] Video e0: buf= 186544 frame=17 sector=0103 ++ WARN: [lt-mplex] Stream e0: data will arrive too late sent(SCR)=13644802 required(DTS)=13629198 ++ WARN: [lt-mplex] Video e0: buf= 214883 frame=003666 sector=00014608 ++ WARN: [lt-mplex] Stream e0: data will arrive too late sent(SCR)=23705009 required(DTS)=23689248 [snip] ++ WARN: [lt-mplex] Stream e0: data will arrive too late sent(SCR)=73429807 required(DTS)=73036045 ++ WARN: [lt-mplex] Video e0: buf= 0 frame=019483 sector=00081855 **ERROR: [lt-mplex] Too many frame drops -exiting The first sequence results in an mpeg file that is only 238k. I also get many buffer overflow errors, and the stream won't multiplex. If I try to make a svcd, it skips like crazy on my dvd player. Again, if I do everything exactly the same but omit the -M 2 flag, everything works fine, but my CPUs are less utilized. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] problem with mpeg2enc and -M option
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 last week or 10 days)? You're right, it looks like it was fixed between when I noticed the problem and actually got around to sending an email. I had to do make clean after the cvs update, or mpeg2enc would crash. It seems the Makefile is missing some dependencies, but since it's autohell I have no idea how to fix it. --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] aspect ratio for converting stills into mpeg
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 for digital systems, so we round down to the nearest multiple of 16 and use 704x480 instead. > IF you really want (or need) 720x480 you have a couple choices: > > 1) Pad (as per the references above) the 704x480 scaled image with > > 2) Pretend (as I have seen in several books) that the SAR is really > 9:10 instead of 10:11. I have seen the distinction drawn between There is no need to do anything special for 720x480 instead of 704x480, you can use the same math. 1) Horizontal only scaling Output Width = Input Width * Input SAR / Output SAR Output Height = Input Height 2) Vertical only scaling Output Width = Input Width Output Height = Input Height / Input SAR * Output SAR If you are going from a non-anamorphic DVD to a computer, the input SAR is 10/11, and the output is 1/1. The input height is 480 and the input width is 704 or 720. Want to scale vertically and get 720x480? 480 / (10/11) * (1/1) = 528, use 720x528 Want to scale vertically and get 704x480? 480 / (10/11) * (1/1) = 528, use 704x528 Want to scale horizontally and get 704x480? 704 * (10/11) / (1/1) = 640, use 640x480 Want to scale horizintally and get 720x480? 720 * (10/11) / (1/1) = 654.54, use 654x480 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] aspect ratio for converting stills into mpeg
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 it's not D1, DVD, and DV all use a sampling rate of 13.5 MHz and have the same sample aspect ratio. I have no idea where 9:10 would come from, expect as some sort of compromise value, like the MPEG1 list of SARs. > Pick up a book on FCP-HD or Adobe's "Premiere" (Photoshop even has > a NTSC DV preset that uses 9:10 and 720x534). If you want 720x486 output, you would use 720x534 input. From the simple formula I posted before: Output Height = Input Height / Input SAR * Output SAR Output Height = 534 / (1/1) * (10/11) = 485.45 Think of the relation like this: 720x486 (10:11) <=> 720x534 (1:1) Read as, "720 by 486 with a sample aspect ratio of 10 to 11 is equivalent to 720 by 534 with a sample aspect ratio of 1 to 1." > > If you are going from a non-anamorphic DVD to a computer, the input SAR is > > He's going, as I recall from computer to DVD so it'd be from 1:1 to > non-square. I suppose when I used "input" and "output" it confused things. You are just finding what resolution and SAR is equivalent to another resolution and SAR, it doesn't matter which direction you are going. > What does seem to be confusing me (perhaps others too) is that there > is the SAR of 10:11 (ratio of 12.272727 and 13.5MHz) and the > "NTSC DV" SAR of 9:10 which is used by some fairly highend video > editors. Sounds like they are just approximating 10/11 = 0.9090909090... to 0.9? > > If you are going from a non-anamorphic DVD to a computer, the input SAR is > > 10/11, and the output is 1/1. The input height is 480 and the input width > > is > > Or 9/10 depending which book was last consulted :) Can you find anything on the web that defines D1/DVD/DV as having a 9/10 SAR? > I'm not sure if fiddling with the numbers (if I put 720x528 in I can > get 720x480 out) instead of padding 704 to 720 is the right thing to > do. If you think about it, it's not different at all. Start with 720x528 and scale to 720x480 or start with 704x528, pad 8 pixels on each side to get 720x528, and then scale to 720x480. The only difference is do you want the 8 pixel border to be black or do you want to stick something there? > > Want to scale vertically and get 720x480? > > 480 / (10/11) * (1/1) = 528, use 720x528 > > > Want to scale vertically and get 704x480? > > 480 / (10/11) * (1/1) = 528, use 704x528 > > Huh? The same vertical size being used? That's making the assumption > that the 720x480 image is a 4:3 image and I thought that was not Where do you get the idea that a 720x480 image is 4:3? > > IF you have Wx480 being a 4:3 image then W can only be 704 for a SAR > of 10:11. Only way I see of getting 720 is to fudge things with the > assumption that 720x480 represents a 4:3 image OR use a SAR of 9:10. It much simpler than all that. 720x480 with a SAR of 10:11 isn't a 4:3 image. Just as 720x528 with a SAR of 1:1 isn't 4:3. There is no need to go to 9:10 land. > the 4:3 image - that's true for 10:11 but what about 9:10 which is > a number I've seen used. Wouldn't that make 720x534 -> 720x480 > the right thing to do? Either that or pad 704x480 to 720x480. IF the SAR was 9:10 for DV, the math is simple: 480 / (9/10) * (1/1) = 533.33 But it's not 9:10, it's 10:11. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] properly encode 720x406
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 there a method that others might recommend? I wrote a program y4mpad to do this, yuvscaler didn't want to just pad an image. > Does anyone have a good idea why this might be? Is this related to the > fact that the image size is incorrect? The rest of the material looks Probably. My JVC DVD player can play SVCD with strange sizes, it properly pads with with black on top and bottom. I make 704x360 letterboxed SVCDs all the time. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] scaling HDTV -> DVD
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 stream (in essence generate a new complete header). I also made a patch for mplayer that fixes the header. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Re: 24fps vs 30fps - why bother? :)
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% fewer frames gives the same file > size as encoding all of the frames? You are specifying a bitrate of 6400 bits per SECOND. Not bits per frame. Same number of seconds, same bitrate, so the encoder will try to produce a file with the same size. If you look at the Q values used, the second encode at 24fps should be using lower (better) Q values than the first one, because you gave it more bits to spend on each frame. Also keep in mind that the 20% of frames that you removed are the easiest 20% to compress, because they are exactly like the ones that came before them. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Re: 24fps vs 30fps - why bother? :)
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 > > > -- > > > You are specifying a bitrate of 6400 bits per SECOND. Not bits per frame. > > Used mpeg2enc for long? Yes. > > If you have then you know the '-b' value is in units of kbits/sec > (kbit = 1000). Sorry, I forgot the 'k'. Can you please forgive my typo? > Who said anything about bits/frame? Certainly not I.There were > sizes given but not in any context of bits/frame. > > Where was any mention off bits/frame given? Sure was, from your email. 30fps: -rw-r--r-- 1 sms sms 4106845567 Jun 14 05:29 sinbad-30R0dp.m2v INFO: [mplex] No. Pictures: 158065 INFO: [mplex] No. I Frames:10538 avg. size 61285 bytes INFO: [mplex] No. P Frames: 147527 avg. size 23460 bytes INFO: [mplex] Average bit-rate : 6229600 bits/sec 24fps: -rw-r--r-- 1 sms sms 4042399041 Jun 15 01:21 sinbad-24R0.m2v INFO: [mplex] No. Pictures: 126450 INFO: [mplex] No. I Frames: 8430 avg. size 65807 bytes INFO: [mplex] No. P Frames: 118020 avg. size 29551 bytes INFO: [mplex] Average bit-rate : 6131600 bits/sec Bytes per frame, bits per frame, kbits per frame, it's the same idea. It was also implied. You seemed to expect that after removing 20% of the frames, the bitrate would go down 20%. That implies average bits per frame should say the same. But that is not how the rate control works, it tries to achieve the specified average bits per second. > The numbers were long term average over the entire encoding - the > average frame SIZES were given for comparision. It's plain to see > there is very little variation no matter what parameters are used > for the encoding or if 20% of the frames are dropped or not. The average number of bits per I frame is 7.3% larger and for P frame it's 26% larger. Overall, the average bits/frame is 23% larger for the 24 fps encode. The number of frames is 20% less. So the bits/second is 1.23 * .80 = 98.4% or 1.6% less for 24fps than 30fps. > > The frames that are dropped are the ones that are the hardest to > encode because they contain mismatched fields (thus the expectation > that compression would be better). You knew that of course and just > forgot it. mpeg2enc should use field based encoding for 3:2 pulldown material. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Re: 24fps vs 30fps - why bother? :)
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 encoding." > > Well - that's not how it read ;) What was written was far too > easy to read as: "that's bits/frame and you don't know what units > you're using". I was trying to make it clear that since the bit rate is base on time, as long as the source is the same length, in seconds, the output should be the same length. You really didn't need to bite my head off and ignore that what I wrote was a correct explanation of why changing the frame rate without changing the bitrate does not effect the resulting file size. > That has the builtin assumption that all the bits it was given > were being used, right? If it's 'under budget' at 30fps then > reducing the amount of data to be encoded by 20% should result > in being even further 'under budget'. Right? The part that was encoded at 6400 kbits/sec should still be 6400 kbits/sec. The part that was encoded at less, which wasn't much since the average bitrate was 6230, could end up taking 20% less space, since there are 20% fewer frames. But the fields you threw out were the ones which were duplicated by other fields, and so, information wise, you didn't remove anything. I imagine that if you increased your gop length for thr 24 fps encode, so that the number of I-frames per second was the same, the bit rate would increase to be even closer to the 30 fps encode. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex and lpcm bug?
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 > > >make just a noise. > > > > If you compare the bytes in NAME.wav and NAME.lpcm, are they > > byte-swapped? (They should be). If not, then you should remove the -x > > option to sox. > The "-x" option of sox only swaps bytes if nessasary. I started my > first test with just cutting of the wav header with dd. The resulting > NAME.lpcm was the same. It is also the same if I don't use the "-x" > option.o I think the question is, are you feeding mplex big-endian data or not? Try this: sox NAME.wav -t raw -x -s -w -c2 -r48000 NAME1.lpcm sox NAME.wav -t raw-s -w -c2 -r48000 NAME2.lpcm hexdump NAME1.lpcm | head -1 hexdump NAME2.lpcm | head -1 Are the two lpcm files byteswapped from each other? I tried this, and it worked for me. ~$ hexdump foo.raw | head -1 000 c901 7101 7702 f801 8203 0203 c703 5303 ~$ hexdump bar.raw | head -1 000 01c9 0171 0277 01f8 0382 0302 03c7 0353 In this case, one of these files will work, and one will not. Are you getting both files the same? Or are you trying both with mplex and getting incorrect sounding output from both? --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2enc 1.6.2: how to use -p for 24fps source?
> 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 > encoded 3:1001) at play time. When you use -F 4 -p, the mpeg file has its framerate set to 30 fps, but there are only 24 frames encoded per second. The encoder puts in repeat field flags that tell the decoder to do the pulldown, which has the effect of converting 24 frames into 30 frames. So it's more correct to say that the decoder contructs 3:1001 video from a 24000:1001 source, as opposed to the other way around. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex problem
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 header that starts with a 16-bit byte-aligned > > 'syncword' 0x0b77 and includes a encoded frame-length. The DVR I rent from Comcast with Microsoft software failed to record last weeks episode of 'Lost', which was new and isn't going to be re-run. Thankfully I was able to download the episode in 540p with AC3 sound. Comcast refunded my DVR free when I called to complain, apparently they have known for some time that the software will randomly fail to record things. It seems no matter how many bananas they give the monkeys at Microsoft, they fail to write working DVR software or the complete works of Shakespeare. Makes me wonder how it is they are employed while I am not. None of my computers can play a 540p mpeg4 file. So, enter mjpegtools to transcode the file to a DVD which I can watch on my TV. But, it looks like whoever captured the show off the HD digital broadcast had a few corrupt bits in the AC3 audio. There also appear to be synchronization errors everywhere they spliced the stream to cut out the commercials. It looks like one frame will be cut short, then the next valid frame will start immediately after. When I try to mux the mpeg system stream, mplex dies with the synchronization error we have become so familiar with recently. > > - Grab the source code and modify the AC3 reader loop so it simply ignores > > some number of broken CRC's and just extrapolates from previous AC3 frames > > instead of giving up immediately. Not rocket-science (see > > mplex/ac3stream.cpp - its obvious whats going on). I looked at doing this, but decided that the io stream class used by the AC3 reader didn't provide the capabilities to do what I wanted. So, I wrote a new, better, IO stream class. It's much more efficient and more capable. At least more capable in ways that appeared, to me, to be important. I then wrote an AC3 re-synchronization program that uses this class. The result works! I was able to have mplayer dump the AC3 into a fifo, have my program read that fifo and send the re-synchronized AC3 to another fifo, and finally have mplex read the re-synchronized audio from that fifo. I produced a DVD which appears to have correct audio sync. Now my wife and I can watch last week's 'Lost', just in time for the DVR to mess up this week's episode. Most of the work was writing the stream I/O library. Specifically the CRC-16 function used to check the CRCs of the AC3 frames. Rather than just copy some code from ac3dec, I wanted to know how it worked and how to derive my own CRC lookup table. To do this I needed to figure out how to perform a CRC without a lookup table. I found one way to do this is to consider the bits of the initial CRC and the data byte to be symbolic variables. Then perform the symbolic bitwise math of 8-bits worth of CRC computation. Then write code that will directly compute the resulting expression. I started doing this with pencil and paper, but quickly got bored after computing about two bits worth. So I wrote a symbolic bitwise math system and used it to compute the result for me. CRC table and C version in hand, I decided it would interesting to write an assembly language version. Actually writing the function was easy enough, but getting gcc interface to the asm block and select registers well was harder. But it proved fruitful, as I found an excellent howto I hadn't read before that told me about the undocumented %b and %h modifiers, which allow one to refer to the high and low bytes of a gcc selected register. I had previously lamented that this appeared impossible. So, I started by trying to watch an episode of Lost that Microsoft's broken software failed to record, and ended up learning how to write better gcc inline assembly. And if you've read this far, and want to try to fix an AC3 stream you have, you can download my ac3 resyncer at http://www.speakeasy.net/~xyzzy/download/ac3resync-1.0.tar.gz --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Re: Question about AGC for the DC10+
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 called "VCR mode"? It may have been the DC10+'s video output chip and not the input chip. I wonder if this could be related to macrovision style AGC scrambling? > just see if the flickering goes away. If one of those works for you, I > can add a setting so that future users will be able to enable this > option in their modprobe.conf or using some graphical kernel > configuration tool (such as what redhat/suse ship). Is there anyway to fiddle these at runtime? Say with a proc interface? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] black bands with yuvdeinterlace?
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)/(480*11) = 1.3636. If you used the resolution 704x480 then it would be exactly 4:3, as (704*10)/(480*11) = 1.. The Rec 601 resolution of 720x480 is slightly wider than 4:3, as 720 pixels are more than enough to get the entire image and provide some padding beyond that. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] black bands with yuvdeinterlace?
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 file and play it and note that 1.33 is printed: In THIS case, mplayer is wrong! Here, the mpeg2 format doesn't specify the SAR, instead there are a few choices for the DAR, like 4:3 or 16:9. The 720x480 MPEG2 file says the DAR is 4:3, but really if you displayed the whole 720 pixels, it would be wider than 4:3. You could say that due to the limitations of the mpeg2 format, the file's header is wrong. Still, this case is so common, mplayer should know better. The math is simple, sample aspect ratio times width in pixels over height in pixels equals display aspect ratio. Do you not agree with this formula? > VIDEO: MPEG2 720x480 (aspect 2) 29.970 fps 7500.0 kbps (937.5 kbyte/s) > Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. > > Plain as day "Movie-Aspect is 1.33:1". The (aspect 2) means this file specifies DAR ratio number 2, which is 1.33:1. mplayer is just printing that bit from the header again when says movie-aspect is 1.33:1. > VIDEO: MPEG2 704x480 (aspect 2) 29.970 fps 7500.0 kbps (937.5 kbyte/s) > Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. Ok, SAR is the same for both of these samples. The resolution is different, 704 vs 720. How can the DAR be the same? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Image artifacts when recording with lavrec and DC10+
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 in the luma signal. Are you using the s-video input or the composite? The difference between the drivers probably has something to do with the filter selection. Maybe there is something like regspy that will let you find out what the pinnacle drivers are programming the saa7110a with. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Zig-zag pattern on every frame...
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, are only affected very little, if even > not at all. Could an interference affect some colors and not other? I'm > not expert of interference, nor of colors, indeed? > > So here is a link to one of those frames: > > http://www.webalice.it/sarkiaponius/0669.jpg 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. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Zig-zag pattern on every frame...
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 configuration I should > check? Where is this filter set up? I've seen this in the bttv driver, if one turns off the comb (notch really, bt848 didn't have a true comb filter) filter like one would do for S-video, but then setup for composite. You can also see it in the cx88 driver if you select the wrong filter, which was something the driver used to do. It would be something in the setup of the video decoder chip, but I don't know what chip that is for the DC30 or how it works. You could also see it in crosstalk between the luma and chroma signal if you have a bad s-video cable. But that isn't an issue with composite. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Zig-zag pattern on every frame...
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 it was a comb filter issue, but > > then he proposed a patch to cx88-core.c related to a different topic. That was a comb filter issue. An incorrect notch filter use to remove the chroma signal from the luma was being used on on the cx88 driver, but it has since been fixed. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [PATCH] zr36067: Fix RGBR pixel format
On Wed, 3 Sep 2008, Jean Delvare wrote:
> The zr36067 driver is improperly declaring pixel format RGBP twice,
> once as "16-bit RGB LE" and once as "16-bit RGB BE". The latter is
> actually RGBR. Fix the code to properly map both pixel formats.
> Signed-off-by: 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=603d6f2c8f9f3604f9c6c1f8903efc2df30a000f
> which was merged in kernel 2.6.23. Can you please review and ack this
> fix? Thanks.
You're right, it looks like I missed the 'X' when I added this little used
format. Does the pixfmt-test program in v4l2-apps check out ok?
Acked-by: Trent Piepho <[EMAIL PROTECTED]>
>
> drivers/media/video/zoran_driver.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.27-rc5.orig/drivers/media/video/zoran_driver.c 2008-09-03
> 10:20:36.0 +0200
> +++ linux-2.6.27-rc5/drivers/media/video/zoran_driver.c 2008-09-03
> 12:47:04.0 +0200
> @@ -134,7 +134,7 @@ const struct zoran_format zoran_formats[
> }, {
> .name = "16-bit RGB BE",
> ZFMT(-1,
> - V4L2_PIX_FMT_RGB565, V4L2_COLORSPACE_SRGB),
> + V4L2_PIX_FMT_RGB565X, V4L2_COLORSPACE_SRGB),
> .depth = 16,
> .flags = ZORAN_FORMAT_CAPTURE |
>ZORAN_FORMAT_OVERLAY,
>
>
> --
> Jean Delvare
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [PATCH] zr36067: Restore the default pixel format
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 that case maybe something like 24-bit BGR is better? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [PATCH, RFC] zr36067: Rework the V4L buffer allocation
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 this change, if there are > major objections, etc. And of course I welcome reports from testers :) I remember this comming up before when I wanted to change it. I think it makes the most sense to try to use the highmem or bigphysarea first if they are there, then fall back to kmalloc with no limits. If kmalloc fails one can always return ENOMEM. An option to allocate some buffers on module load might be a good idea. But going forward, it's probably desirable to convert the driver to use the video-buf system. I think Mauro's mentioned this before. I'm pretty sure video-buf now has support for contiguous buffers as well as vmalloced buffers. But using both at the same time like zr36067 does might cause problems. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Miro DC10+ capture resolution
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 > the card to capture at full pal/ntsc resolutions ( > Norms: PAL, SECAM (768x576 @ 25 fps), NTSC (640x480 @ 29.97 fps)) > > The issue is that the v4l2-ctl --all command reports ( gets from > driver ? ) a 192/144 resolution capture capability. > Where should I check ? I mean, in XP the card > works fine at full resolution, but in linux it does not. You probably need to increase the value of the v4l_bufsize module parameter. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [PATCH] zoran: invalid test on unsigned
On Sun, 26 Apr 2009, Roel Kluin wrote: > fmt->index is unsigned. test doesn't work > > Signed-off-by: Roel Kluin > --- > Is there another test required? This is an old driver and I think back in v4l1 the indexes weren't all unsigned. There were a number of tests like 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/zoran_driver.c > @@ -1871,7 +1871,7 @@ static int zoran_enum_fmt(struct zoran *zr, struct > v4l2_fmtdesc *fmt, int flag) > if (num == fmt->index) > break; > } > - if (fmt->index < 0 /* late, but not too late */ || i == NUM_FORMATS) > + if (i == NUM_FORMATS) > return -EINVAL; > > strncpy(fmt->description, zoran_formats[i].name, > sizeof(fmt->description)-1); > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [PATCH] zoran: invalid test on unsigned
On Mon, 27 Apr 2009, Alan Cox wrote:
> On Sun, 26 Apr 2009 17:45:07 +0200
> Roel Kluin wrote:
> > fmt->index is unsigned. test doesn't work
> >
> > Signed-off-by: Roel Kluin
> > ---
> > Is there another test required?
> >
> > +++ b/drivers/media/video/zoran/zoran_driver.c
> > @@ -1871,7 +1871,7 @@ static int zoran_enum_fmt(struct zoran *zr, struct
> > v4l2_fmtdesc *fmt, int flag)
> > if (num == fmt->index)
> > break;
> > }
> > - if (fmt->index < 0 /* late, but not too late */ || i == NUM_FORMATS)
> > + if (i == NUM_FORMATS)
> > return -EINVAL;
>
> If it's unsigned then don't we need i >= NUM_FORMATS ?
That part of the patch is fine. It turns out there is another problem that
already existed in this function. It's clearer with a few more lines of
context.
int num = -1, i;
for (i = 0; i < NUM_FORMATS; i++) {
if (zoran_formats[i].flags & flag)
num++;
if (num == fmt->index)
break;
}
if (i == NUM_FORMATS)
return -EINVAL;
/* stuff to return format i */
The v4l2 api enumerates formats separately for each buffer type, e.g. there
is one list of formats for video capture and a different list for video
output. The driver just has one list of formats and each format is flagged
with the type(s) it can be used with. So when someone requests the capture
format at index 2 we search the list and return the 3rd capture format we
find. Since we don't know how many capture formats there are (NUM_FORMATS
is the number of formats in the driver's single list, i.e. the union of all
format types) we can't reject an index that is too large until after
searching the whole list.
The problem with this code is if someone requests a format at fmt->index ==
(unsigned)-1. If the first 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.
Here's a patch to redo the function that should fix everything:
zoran: fix bug when enumerating format -1
If someone requests a format at fmt->index == (unsigned)-1 and the first
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->index < 0 found by Roel Kluin
is removed this way too.
Signed-off-by: Trent Piepho
diff -r 63eba6df4b8a -r c247021eb11c
linux/drivers/media/video/zoran/zoran_driver.c
--- a/linux/drivers/media/video/zoran/zoran_driver.cMon Apr 27 12:13:04
2009 -0700
+++ b/linux/drivers/media/video/zoran/zoran_driver.cMon Apr 27 12:25:51
2009 -0700
@@ -1871,22 +1871,20 @@ static int zoran_querycap(struct file *f
static int zoran_enum_fmt(struct zoran *zr, struct v4l2_fmtdesc *fmt, int flag)
{
- int num = -1, i;
-
- for (i = 0; i < NUM_FORMATS; i++) {
- if (zoran_formats[i].flags & flag)
- num++;
- if (num == fmt->index)
- break;
- }
- if (fmt->index < 0 /* late, but not too late */ || i == NUM_FORMATS)
- return -EINVAL;
-
- strncpy(fmt->description, zoran_formats[i].name,
sizeof(fmt->description)-1);
- fmt->pixelformat = zoran_formats[i].fourcc;
- if (zoran_formats[i].flags & ZORAN_FORMAT_COMPRESSED)
- fmt->flags |= V4L2_FMT_FLAG_COMPRESSED;
- return 0;
+ unsigned int num, i;
+
+ for (num = i = 0; i < NUM_FORMATS; i++) {
+ if (zoran_formats[i].flags & flag && num++ == fmt->index) {
+ strncpy(fmt->description, zoran_formats[i].name,
+ sizeof(fmt->description) - 1);
+ /* fmt struct pre-zeroed, so adding '\0' not neeed */
+ fmt->pixelformat = zoran_formats[i].fourcc;
+ if (zoran_formats[i].flags & ZORAN_FORMAT_COMPRESSED)
+ fmt->flags |= V4L2_FMT_FLAG_COMPRESSED;
+ return 0;
+ }
+ }
+ return -EINVAL;
}
static int zoran_enum_fmt_vid_cap(struct file *file, void *__fh,
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] any mpeg2 encoder faster than mpeg2enc?
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. Getting near-DVD quality in a > small amount of space would sure be nice, but not at the expense of > taking 8-10 hours to encode it. If you just want a PVR, then why not keep the recording in mjpeg form? Sure it takes up more space then mpeg2, but what costs more, a 100GB+ ide drive or a hardware mpeg2 compression card? Of course hardware mpeg for linux isn't possible at this time anyway, but large harddrives work fine, so it's not like that's even a real choice. I haven't been following the thread that closely, but have you tried mpeg2enc without using any scaling or de-noising? Those steps are very cpu intensive and if you're not looking for quality... --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] any mpeg2 encoder faster than mpeg2enc?
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 then, it sounds like you have them set very high, 10Gb/hour. I've used around 2-3 GB/hour and it looks a lot nicer than recordings I do with my SVHS vcr. > > Of course hardware mpeg for linux isn't > > possible at this time anyway, > > Have you seen any of the discussion recently about the PVR 250? It sounded like "not working" was the answer. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] y4mscaler v0.2.0 available
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 y4mscaler is "better"? Running your video though a Gaussian blur filter would increase the compression ratio, put it's probably not what most people would consider an improvement. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Optimizing quality for SVCDs
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 can be done. The zoran mjpeg chip can only do power of 2 scaling ratios. I'm pretty sure the video decoder chip used only works at a fixed resolution. You'd have to replace a clock crystal to get it to work at another resolution. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] LML33 vs. Canopus ADVC-100
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 DVD quality captures. Only problem is that they did not > >write any drivers for Linux. [...] > > Holy crap! I would have expected LML to actually care about > high-quality drivers and providing support. LML originally wrote some drivers for their card, but they weren't very good and didn't use the V4L interface (they probably pre-dated V4L though..) Then the open source drivers for the Buz & DC10+, which use the same Zoran chip as the LML33 (but are only $60), was written and much better than LML's driver. So now they tell you to use that one. The problem with the zoran chipsets cards, DC10+, LML33, Buz, etc., isn't so much the drivers, but rather that the zoran PCI implementation is one of the worst ever created. If you happen to have a working hardware config (like 440BX chipset and no SB live card), it will work fine. Otherwise, stability is pretty much hopeless. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Help with revert 2-3 pulldown, please
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 yuvkineco -F 4 and > this interlace effect is gone, but the 5th frame is an almost exact copy > of the 4th frame, so the motion seems to stutter. Is there anything > that can be done about this? You need to create a 24fps mpeg file, or you will either get interlacing, studdering, or motion artifacts. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Re: [Mjpeg-developer] Re: mjpegtools compileproblem (fwd)
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 with the > > latest nasm you can get and try latest CVS of jpeg-mmx. > > It was a bug in using too high an optimization level (-O3). As > Bernhard mention (and I discovered a while back) using -O2 (or simply > -O) fixes the problem. I don't think "fixes" is really the correct term, more appropriate would be "masks". If the code fails with -O3, then there is either A) a bug in the code, or B) a bug in the optimizer. Using a different optimization level level doesn't fix either one. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Re: [Mjpeg-developer] Re: mjpegtools compileproblem (fwd)
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 either A) a bug in the > > code, or B) a bug in the optimizer. Using a different optimization level > > level doesn't fix either one. > > You're right, sorry for the word confusion. > > Since most developers don't see the problem, and since nobody sees it at > "standard test levels" (-O0), I'd assume it's a compiler bug. Code bugs > would show up specifically at -O0. Not really, there are plenty of bugs that don't show up at lower optimizations. One bug that I recently fixed was in some FORTRAN code that failed when compiled with optimizations. Turns out that someone had declared a library routine as subroutine when it was really a function. In C terms, a library function returned double, but prototype in the include file said it was void. This meant that the the compiler didn't pop the return value off the floating point stack after the function returned. Without optimizations, this didn't happen to cause a noticeable problem, but that's just luck. With optimizations, multiple simple expressions got combined into one more complex, and floating point stack intensive, expression. This then caused the floating point stack to overflow, resulting in random corruption of calculations that had nothing what so ever to do with the real bug. The source that needed to be compiled without optimizations didn't even have a bug! The incorrect prototype was in a different source file that could be compiled with or without optimizations. If the compiler didn't have a special floating point stack checker as a debug option, something like this would next to impossible to fix. There's a real example of a bug that only appeared with optimizations, but was a bug in the code none the less. It might seem that jpeg-mmx is fixed with -O2, but the problem is probably still there. You might change something in totally unrelated code in AC3 audio decoding that causes the compiler to use one more floating point register, and then it comes back to bite you even with -O2. Worse yet, the guy working on AC3 will have no clue that he's triggered a bug in jpeg-mmx, and (sadly, I speak from experience here) spend days trying to figure out why the hell his code isn't working, going over every line again and again trying to find a bug that isn't there. --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] mjpeg 1.6.1.90 libjpeg-mmx configure change
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 pretty big slowdown. Why does the configure script check to see that g77 works? Is someone planning to create a codec in FORTRAN? The horror, the horror... --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Mjpegtools 1.6.2 rc1 (Upgrading!)
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 number 1, jpeg2yv > will loop forever writing the image to stdout. When you use n > 1 > it will loop. n-time till it finishes. Wouldn't this be so much simpler? -l num Specifies the number of loops (default: 1 loop) The ranges of images will be looped through `num' times, by default just once. The value of 0 will loop indefinitely. The -n option in ppmtoy4m and lavpipe use 0 to mean all. For lav2yuv it's -f 0 to mean all frames. jpeg2yuv and png2yuv use -1 for all. I suggest using -n for frame count. head and tail use -n for line for number of lines. -f seems like it should take a filename as an argument, like tar and grep. Why is it, jpeg2yuv and ppmtoy4m? How about jpegtoy4m? YUV also refers a colorspace, while y4m is probably only used to refer to a stream format also known as YUV4MPEG, read with functions like y4m_read_stream_header(). --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
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 use it. One of the many many > things for the list is a quick and dirty interlace-detector that activates > this if the frame looks to have significant decorrelation between adjacent > lines. What is it about interlacing that makes it so hard? I can see how trying to detect interlaced vs progressive source, or an inverse-telecin filter, would be extra work. But is a 720x480x30fps interlace source really any different than a 720x240x60fps progressive source? --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Update on: mpeg2enc current cvs segfault ?
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()' - which makes this an
> > unacceptable solution in the long term (but as an experiment it would
> > be worth trying).
>
> Is this function called often? If not, it can be easily worked around by
> creating a linked list of allocated pointers from posix_memalign().
> Then, return (ret + 3) &~ 3. In posix_memalign_free, check the given
> pointer against each value in the list (listval + 3) &~ 3 and free
> listval.
How about this? It will malloc and free the aligned pointers in constant
time. It needs only a trivia change to make it work on 64 bit systems.
/* This assumes that pointers must be padded to 32-bit alignment. */
/* align = power of 2 to align on, e.g 0= 8-bits, 1 = 16 bits, 2 = 32 bits */
void *align_malloc(size_t size, int align)
{
void *p; uintptr_t l;
if(align<2) align=2; /* pad to at least 32 bits for the pointer */
/* allocate a bit of extra space for a pointer and the alignment */
p = malloc(size+(1
Re: [Mjpeg-users] -M 2/3 on SMP is slower than -M 0
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 per CPU isn't helping too much overall > considering how many frames there are in a typical video to be A 720x480 4:2:0 frame is about 512KB, at 550MB/sec there is enough memory bandwidth to encode at about 1000 frames/sec if all you had to do was read the data. Obviously the encoder runs somewhat slower than that, so each byte of data must be accessed multiple times. That's where the cache helps. > Of course, Andrew would be much better suited to discuss mpeg2enc's > memory access patterns during encoding, which depending on how it > does go about accessing memory can better make use of the 256k of > cache, or cause the 256k of cache to be constantly thrashed in and > out. I seem to recall that one of the biggest performance bottlenecks of mpeg2enc is they way it accesses memory. It runs each step of the encoding processes and en entire frame at a time. It's much more cache friendly run every stage of the encoding process on a single macroblock before moving on the to next macroblock. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] -M 2/3 on SMP is slower than -M 0
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 (prediction and DCT > > If one were using closed and fixed length GOPs would it make > sense to parallelize the encoding of complete GOPs? Each cpu > could be dispatched a set of N frames that comprise a closed GOP and > a master thread could write the GOPs out in the correct order. But what about bit allocation? You need to know how big the last GOP was to figure out how many bits you can use for the next GOP. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] -M 2/3 on SMP is slower than -M 0
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 while variance is multiply-add. Multiply-add is usually the most heavily optimized operation a cpu can perform. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] -M 2/3 on SMP is slower than -M 0
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 multiply-add. Multiply-add is usually > > the most heavily optimized operation a cpu can perform. > > Au contraire. Multiply is a lot slower than abs(). All abs() has > to do is flip a sign bit (effectively) and that's going to be a lot In floating point, all you have to do is flip a sign bit. But with integers, it's not so easy. There is no instruction for absolute value in MMX, you have to use a four instruction sequence and two registers. Slower than squaring a value, which only takes two instructions. Though you can cleverly combine an unsigned subtraction and absolute value operation into four instructions total, and perform it on eight unsigned bytes at a time. So you can compute an absolute value of differences quite a bit faster under MMX than I was thinking you could. Clearly SAD would be faster than variance. Another advantage of SAD is that you can find an intermediate result easier than with variance. That way you can short-circuit the SAD calculation if you have already reached the best SAD already found. > faster than any multiply. And aren't there MMX2/SSE abs+add > instructions - that would make abs/add quite fast. I finally found a mmx2 reference, and you're right about that. MMX2 added psadbw, packed sum of absolute differences. If you have 8-bit unsigned data it makes computing SAD pretty darn easy, you can find the SAD of 8 pixels in one instruction. Though why did mpeg2enc use variance in the first place? Maybe it's a better estimator than SAD for motion compensation fit? > At any rate I checked out ffmpeg's mpeg2 encoding vs mpeg2enc on > my G4 Powerbook. Yes, ffmpeg has a big speed advantage (~2x) but The level of altivec optimizations ffmpeg vs mpeg2 is probably an important factor in any speed difference, and one that wouldn't matter for other CPUs, which the level of MMX/MMX2/SSE optimizations makes a large difference. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
