I have no idea what the problem is, but...
a) By "All Green" do you mean the output is a plain green picture,
or does the output simply have a greenish tint to it?
>> Can you encode you fils on the command line without using the lav2mpeg
>> script.
>> You command looks like that than:
>
...
>>y4mscaler -S option=sinc:8 ...
>>
>> will perform very high quality scaling and I think the artifacts
>> will disappear.
>
>The sinc* kernels are very bad at removing noise. IMHO, the
>cubic* kernels are better for this job...
A factor to consider (for why the sharp
>> > The sinc* kernels are very bad at removing noise. IMHO, the
>> > cubic* kernels are better for this job...
I'm guessing that the cause behind Nicholas' HO is that the cubic kernels
remove a lot of the *lower* frequency content --- the taper of such filters
in frequency space is very grad
>From: =?ISO-8859-1?Q?Thomas_B=F6rkel?= <[EMAIL PROTECTED]>
>Date: Tue, 27 Jan 2004 15:06:59 +0100
>
>HI!
>
>Sorry to reply on the list, but your host ist blacklisted, so I cannot
>send email to you.
(This message is meant for *me*, right? Lots of people on this list,
and quite a few ev
Hiya,
I think you and Romildo are suffering from similar problems. (And I
just got Romildo's post, too --- the re-ordering and delays on the
Sourceforge lists are really crazy these days.)
>> >I tried to use some automatic guesses from y4mscaler, but they did not
>> >do what's IMHO righ
[lazily catching up on a weekend's email... easy ones first...]
>On Fri, 2004-02-06 at 02:16, Maarten De Boer wrote:
>> lavplay file.avi
>> only output a plain green screen. but
...
>> the avi file has been recorded with dvgrab --format dv2
>
>lavplay doesn't support DV.
>
>Ronald
That'
Hi, Paul,
>I'm not having a problem with the tools per se, but a
>problem with my DVD player. I need to fool it. Question
>below code.
...
>The problem is, my DVD player cuts off 10 or so pixels from
>each side, and 15 or so from the top and bottom. When I try
>to play the VCD it render
>> Somehow, the latest/current lavplay (and thus glav) works on my machine,
>> at least on the one NTSC "dv2" format AVI I use for testing stuff (only
>> one I tried).
>
>interesting... how did you get this dv2 avi? with dvgrab?
Yes, dvgrab... (from two years ago, probably. !)
-matt m.
>> I found the problem. It is concerned with lavtools. I was
>> recording the fooprint using lavrec. Apparaently, it produced many
>> pixels (at least 10% per image) with YUV out of the spec
>> (16<=Y<=235, 16<= u,v <= 240). Since matteblend.flt is programmed
>> using the exact spec, a lot of
>> The specification was created this way on purpose, to give some room
>> for ringing and over/under-shoot in both the signal acquisition and
>> the digital operations that follow. The pixels should only need to
>> be clipped to the [16,235]/[16/240] range when converted to R'G'B'...
>
>> I have a problem with SVCD still picture creation.
>>
>> The Quality of SVCD still pictures is less good than of VCD-Stills
>> because mpeg2enc will always output interlaced Video-Streams.
>>
>> Using ppmtoy4m with option -I p and/or mpeg2enc with option -I 0
>> it's all the same. I ne
Christian Effenberger,
You must cease distribution of "3CaDo_BASE.lha" and "ViCaDo_TOOLS.lha"
immediately.
"ViCaDo_TOOLS.lha" contains software which has been released to you under
the GNU Public License. Your redistribution, however, fails to:
a) provide a copy of that license, and indi
>On Sat, 2004-02-28 at 14:08, Carlos Sierra wrote:
>> I've been using mp2enc from long but in the last release from the debian
>> unstable repository it crashes whe the filename specified with -o option is
>> too long.
...
>
>It has always been like that. We reserve MAX_NAME_SIZE (defined
> I know that this is going to be a strange question ;)
(I would expect no less.)
> The first thought I had was to simply take lines 0, 2, 4, ... 720
> from the first frame and call that field 1, then take the corresponding
> lines (0,2,4,...) from the next frame and call
>> Check cinelerra --- see what it says about your video's field order. (If
>> it doesn't say anything, then you *know* it is broken.) The source DVD
>> is not necessarily bottom-field first (or even top-field first); if not,
>> cinelerra needs to account for that when it produces a DV fi
>> Is there a way of telling how a DVD has been encoded in terms of field
>> order?
>
> For that I use a program called "dvdview" against the decrypted
> .vob file. At log level 3 (-v 3) you get info like this:
...
>PictureHeader:
...
> top field first: false
...
> r
>> Debugging the temporal order (addressed in the MJPEG Howto):
>Do you mean that I should write a better decription there. Or is it
>enougth ?
I'll have to take a better look. I remember that section of the
"MJPEG Howto" being kind of MJPEG-centric, mixing together some
phenomena and missi
>I think I've at least partially solved this problem. Over the weekend I
>tried encoding with the the "-z t" mpeg2enc option and the result was
>noticeably better when played back on the hardware player. mpeg2enc claimed
>the frame order of the incoming stream was bottom first, so the above
>In an effort to avoid replying to individuals without a copy to the list
>I set up a kmail profile that would always bcc the list. Having just
>tried it, I got:
...
>Obviously it is not happy at what I have done, but why? I'm trying to
>make things as tidy and problem-free as possible,
>I've installed mjpegtools from cvs. Trying to build y4mscaler, which
>fails here:
>
>g++ -DYS_VERSION_MAJOR=0 -DYS_VERSION_MINOR=7 -DYS_VERSION_PATCH=0 -O2
>-march=athlon-xp -m3dnow -msse -mfpmath=sse -I/usr/include/mjpegtools
>-I/usr/include/mjpegtools/mpeg2enc -I/usr/include/mjpegtool
>The reason is that we don't trust jpeg-mmx to be a fullblown replacement
>for libjpeg - it still has some bugs that would need to be ironed out
>before it could be released "into the wild" .-)
>
> Gernot Ziegler,
Hej, Gernot,
Out of curiousity, how (and how much) does "jpeg
>> You you have to take a look at the center, oft the first field or
>> something like that.=20
>
>Yeah, funny enough, the black frame search I did in mplayer looked at
>the centre of the frame and worked it's way towards the top and bottom
>of the frame for just that reason, however, that d
>> Out of curiosity, does the noise of the uncompressed recording look
>> worse in black frames than regular ones, or is it only after mpeg
>> compression that things look bad? If the latter, than perhaps you want
>
> The latter. I see the blocks/splotches all the time in dark scenes.
>I have a jpeg image.
>I want to put it as a still into a VCD.
>I do not know its dimensions.
...
>Any easy solutions?
Yep: y4mscaler.
http://www.mir.com/DMG/stills.html
http://www.mir.com/DMG/Software/y4mscaler.html
-matt m.
--
>I am trying to create an interlaced MPEG2 stream using mpeg2enc, but
>mpeg2enc warns me that I am feeding it progressive video and the chroma of
>the output is all messed up. It says:
>
>++ WARN: [mpeg2enc] Interlaced encoding selected with progressive input!
>++ WARN: [mpeg2enc] (This
>On Tue, 6 Jul 2004, Matto Marjanovic wrote:
>
>> mpeg2enc only knows what the stream header tells it --- pipe the output
>> of mplayer into "head -1" and you can see for yourself. My guess is
>> that mplayer is indicating "Ip" for "progress
>jpeg2yuv -n 1 -f 25 -I p -j original_photo_file.jpg | \
>y4mscaler -I sar=1:1 -O sar=PAL -O size=720x576 -O chromass=420_MPEG2 -S
> option=sinc:6 | \
> mpeg2enc -q 4 -f 8 -I 0 -4 1 -2 1 -D 10 -h -o output.m2v
>
> Note: if you get the sample aspect frame size correct then you
>
>If I run:
>
>mp2enc -o /path/file.mp2 < audio.wav
>
>and the string "/path/file.mp2" is over 80 characters long then
>mp2enc corrupts the output filename. I'm using mjpegtools-1.6.2
>and compiled with gcc-3.2.2.
Didn't this come up already just a few months ago?
There is a "MAX_NAME_SIZE
Just a note:
Two new micro-versions of y4mscaler are available now:
o v0.6.2 -- compiles with MJPEGtools 1.6.2 (how convenient).
o v0.7.1 -- compiles with current CVS MJPEGtools.
The main improvement is some fixes to allow compiling with gcc-3.4
(thanks to Michael "ahze" Johnson for disc
>
...
>Maybe this info should be compiled into a text file distributed with the
>sources so people can have one place to read up on all the gory details
>concerning aspect ratios in NTSC, PAL, VCD, SVCD, DVD, HDTV and wide screen
>formats.
See "http://www.mir.com/DMG/"; for a good chunk
>Thank You very much, but these two days I am trying to solve some problems
>I can't pipe lav2yuv | y4mscaler | mpeg2enc because mpeg2enc every time
>says that he can't manage interlaced video.
I have a suspicion that you haven't done enough reading, but the start of
this thread is long gone
[I have time for one easy question --- here's the easy answer:]
>have a bit of captured interlaced video and a ppm picture. I want to
>combine them into a single interlaced MPEG2 stream that looks like this:
...
>STEP 1:
...
>cat picture.ppm | ppmtoy4m -F 25000:1000 -I t -L | yuv2lav -f a
Hi, all,
Version 8.0 of y4mscaler is now available from its usual place:
http://www.mir.com/DMG/Software/y4mscaler.html
(I decided the original major.minor.patch version numbering was
a bit over the top --- when would it ever get to "1.0"? Hence
the jump from 0.7.1 to 8.0.)
This version
Err, between this:
>From: Jonathan Black <[EMAIL PROTECTED]>
>Date: Wed, 19 Jan 2005 21:17:08 +0100
>
>On Wed, Jan 19, 2005 at 10:02:45AM -0800, Steven Boswell II wrote:
>> Right before I call yuvkineco, I call yuvcorrect to
>> change bottom-field-interlacing to
>> top-field-interlacing.
>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 h
(Usual place: http://www.mir.com/DMG/Software/ )
This minor update does two.five things:
o Actually change the default kernel from 'linear' to something else.
o Implement Keys' 4th-order cubic kernel --- as 'cubicK4' ---
as suggested by Nicholas Boos.
o Make 'cubicK4' the defa
>> This minor update does two.five things:
>>
>>o Implement Keys' 4th-order cubic kernel --- as 'cubicK4' ---
>> as suggested by Nicholas Boos.
>>
>>o Make 'cubicK4' the default kernel.
>
> Oh, so the default is cubicK4 rather than sinc:6 (which I believe
> was m
>>INFO: [mpeg2enc] Aspect ratio code: 1 = 1:1 pixels
>
> Oops - but I think I know what caused that problem...
...
> It's probably necessary to specify the output SAR (-O sar=) before
> you give the size (-O size). That's so that y4mscaler knows
> what output sample
>here is the line I am using
>
>cat *.ppm | ppmtoy4m -F 18000:1000 -L | y4mscaler -I sar=1:1 -O size=720x576
>-O chromass=420_MPEG2 -O sar=PAL | yuvdenoise -b 20,20,680,536 -r 16 -t 2 -c
>80 -F -L 160 | mpeg2enc -r 16 -I 0 -B 96 -g 6 -G 15 -a 1 -H -4 2 -2 1 -F 2 -f
>8 -M 2 -p -o test_pull
>From: Trent Piepho <[EMAIL PROTECTED]>
>Date: Wed, 26 Jan 2005 12:55:50 -0800 (PST)
>
>On Wed, 26 Jan 2005, E.Chalaron wrote:
...
>> I know that
>> find . -name \*.tga | xargs -n1 tgatoppm | ppmtoy4m | blabla
>
>Try this:
>find . -name \*.tga | xargs -n1 cat | ppmtoy4m
>I have troubles using the "active" option from y4mscaler,
>When I specify a region : the output is nill, getting rid of the -I active
>and I have something
>here is my comand line :
>
>(find . -name \*.ppm | xargs cat) | ppmtoy4m -F 25:1 -L -S 420mpeg2 | \
>yuvdenoise -F -r 16 -t 2 | y4
>As soon as I get rid of -I active, the thing is going very well :-( ??
>Am I using bad values ???
Nope, the values are fine, but they are triggering a bug.
(I remember this problem arising before, somewhere, but I don't remember
what the resolution was.)
...
> INFO: [y4mscaler] ===
>From: "E.Chalaron" <[EMAIL PROTECTED]>
...
>> What happens if you do not use the 'tl' and let y4mscaler default
>
>same stuff, though I have not tried cc explicitely
>Yuvscaler is handling the job properly now...
("not segfaulting" != "properly")
-matt m.
--
>I think I must be doing something silly: every time I try to pipe the
Excellent intuition... :)
>output of either png2yuv or ppmtoy4m into mpeg2enc, mpeg2enc complains:
>
> ERROR: [mpeg2enc] Could not read YUV4MPEG header: bad stream or frame
>header!
>
>Command lines:
> png2yuv -
>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 SECO
>On Thu, 16 Jun 2005, Matto Marjanovic wrote:
...
>> One would expect the _quality_ of the encoding to vary though. With the
>> 24fps input, mpeg2enc should have more room in the same file to store
>> real information. With the telecined input, mpeg2enc will squa
>This is my first post in this list so hi !
Howdy!
>Hope you could help in this as i am a begginner in the video world.
>What i am trying to achieve is to take a video stream, extract couple of
>frames, modify them (add another picture on top) and put them back in to
>the video stream.
>
>> >Everythings work not too bad except i can notice a luminance difference
>> >between frame i had extracted and the rest of the video stream. It is
>> >like a white transparent shadow (it s more visible from Quicktime Player
>> >though ...)
>> ...
>> >So i concluded y4mtoppm or ppmtoy4m is
>> One thing though: in the frame you sent me, about 10% of the pixels
>> are clipped in the initial conversion to R'G'B' --- these are Y'CbCr
>> values in the orginal frame which lie outside of the R'G'B' color
>> cube. When they are clipped (projected/forced into the R'G'B' cube),
>>
>I have an MJPEG AVI that I wish to split into a series of JPEGs.
>I've tried using lavtran, like so:
>
>bash% lavtrans +n -o image%05d.jpeg -f i vid.AVI
>
>but it generates JPEGS with empty huffman tables (0x0 DHT).
Beware that the JPEG's in an MJPEG stream (thus, those dumped out
by lav
>From: John Gay <[EMAIL PROTECTED]>
>Date: Sun, 23 Oct 2005 16:20:21 +
...
>I'm starting with a set of png images, 1290X1080 which I want to make into a
>wide-screen DVD format.
>
>But if I use something like this:
>png2yuv -j xw_test%02d.png -f 25 -I p | y4mscaler -I sar 1:1 -O
>p
>Any suggestions on how to fix this would be greatly appreciated.
>Went to use DVDStyler last week and got hit with the below:
...
> INFO: [ppmtoy4m] chroma subsampling: 4:4:4 (no subsampling)
> INFO: [ppmtoy4m] Output Stream parameters:
> INFO: [ppmtoy4m] frame size: 720x480
>From: Andrew Stevens <[EMAIL PROTECTED]>
>Date: Fri, 2 Dec 2005 00:05:32 +0100
...
>Hi Steven,
>
>> Basically the 1920x1080 material is padded and encoded as 1920x1088
>> (since 1088 is a multiple of 16 and 1080 is not) but a value is set in
>> the sequence that says "only dec
>Greetings,
>Thanks for all your hard work. Combined with DVDAuthor, this is an
>amazing tool. Recently, I found I needed to offset my ac3 7310ms (yes, I
>know, that's big) to sync with my video. Quite a few errors later,
...
>stream), then using that new ac3 (with 0.7310s added) in Mpl
>I want to generate a static MPEG2 video stream that's compatible with
>the DVD specifications (either NTSC or PAL). I can deal with the MPEG2
>and DVD part, I just don't know how to generate a YUV that has the same
>image repeated over and over.
"man pnmtoy4m"
In particular, the '-n N' and
>Hi all
>I have something odd here.
>
>I get my footage in XGA (1024*768) Mov (422 uncompressed using libquicktime).
>
>If I transform these mov in dv files such as :
>
>qttoy4m my_super8.mov | y4mscaler -O CHROMASS=420jpeg \
>| y4mtoppm | \
>| ppm2raw -a -2 > my_super8.dv
>
>Well...
>Has anyone seen this error when trying to build y4mscaler 9.0 with the
>current CVS of mjpegtools on Opensuse 10.3?
>
>make all
>g++ -DYS_VERSION_MAJOR=9 -DYS_VERSION_MINOR=0 -O2
>-I/usr/local/include/mjpegtools -I/usr/local/include/mjpegtools/mpeg2enc
>-I/usr/local/include/mjpegtools/m
>I'm just trying to convert a bunch of frames into a movie. The doc's
>said I could do this:
>
>jpeg2yuv -v 2 -n25 -I p -f 25 -b 1 -j pyramid???.jpg > pyramid.yuv
Heh-heh, funny you should ask (esp. if you are also subscribed to
mjpeg-developer).
*I* would say, use ppmtoy4m instead (perh
Yay! *Two* users
> One small patch though is what I needed for getopt() on the systems
> here. Seems setting optind to 0 isn't the right thing:
"That would be a bug, Bob."
It should be 1; I guess my system is more forgiving. (Debian Unstable,
with gcc-2.95.4 and glibc-2.3.1.
Hey, Steve, out of curiousity,
>smil2yuv bugs8.smil | \
>y4mscaler -I active=696x468+12+4 -O sar=1:1 -O size=640x480 -S option=cubic | yuvplay
>
> INFO: [y4mscaler] Input Stream Header:
> INFO: [y4mscaler] <<< frame size: 720x480 pixels (518400 bytes)
> INFO: [y4mscaler] <<< fra
>> How did you get a source stream with 480 lines and NTSC framerate,
>> but with PAL sample aspect ratio (59:54) ??
>
> You know - that caught my eye too - it didn't feel right (should be
> 11:10, right?).
Yep. (Well, 10:11 actually.)
And this is what triggered the segfault prob
>awds59.6-> smil2yuv bugs8.smil | od -c | head
>000Y U V 4 M P E G 2 W 7 2 0 H
>0204 8 0 F 3 0 0 0 0 : 1 0 0 1
>040I b A 5 9 : 5 4 \n F R A M E \n
Just a note that might c
Version 0.2.0 of y4mscaler is now available on-line at:
http://www.mir.com/DMG/Software/y4mscaler.html
The webpage now has a preliminary spectral comparison of the various
scaling kernels that are available.
(In response to a question from sms: yes, y4mscaler is slower than
yuvscaler, but,
>Version 0.2.0 of y4mscaler is now available on-line at:
>
> http://www.mir.com/DMG/Software/y4mscaler.html
In case anyone has downloaded this since my last message, please do it
again...
The previous version was compiled without any optimization enabled.
I just uploaded a "-O2" version.
> You rang? ;)
>
> 14000 frames (~8 minutes) of data captured (by another Canopus convert)
> from a VHS tape and on its way to SVCD.
>
> 1)
> smil2yuv -a $N.wav $N.smil | \
> y4mshift -n -6 | \
> yuvdenoise -S 0 -r 16 -t 5 -l 3 -b 20,56,
>Hi Matto,
Hey, Andrew, happy new year,
>I haven't had a chance to look at the code so I don't know how wide the
>H-scaling filter can be.
A filter can be as wide as it wants to be --- the code is quite general
in that regard (hence not as fast as it could be for any given filter).
> H
>> I have an MPEG2 video stream which I'm looking to convert from
>> 4:3 to 16:9. The actual video is 16:9 anamorphic but Quicktime and
>> my DVD player play it as 4:3. Is there a tool which can change the
>> flag in the MPEG stream so it indicates it is 16:9?
>
>If you only want to set the
I just put up the source (and gcc-3.2-precompiled binaries) to version 0.3.0
of y4mscaler at:
http://www.mir.com/DMG/Software/
The kernel comparison table is likewise updated.
New features:
- Two windowed-sinc kernels (Lanczos window), "sinc4lan" and "sinc8lan".
Bug fixes:
- Miscellan
>|So, what's the deal? Is this an actual error in
>|yuvdenoise/medianfilter, or an expected artifact from denoising the
>There are definitively errors/inaccuracies in the lav-tools concerning the
>range of YUV-values. yuvdenoise tends to broaden the [16-235]-range of Y.
Not just the
>There is a simple scenario I used to test theese things: I created a jpeg
>with colorbars of known RGB-values ( grey0(=black), grey8, ...,
>grey255(=white), and similar for red, green, blue ). Then I duplicated the
>file many times and made a YUV stream of it using jpeg2yuv. I piped this
>st
Hiya, Ralf et al,
>But nevertheless, there is work to do identifying/fixing the
>non-compliant tools one by one. Which tools are known to be compliant?
>Which have clearly identified problems with value-ranges? Which have an
>unknown state?
It would indeed be good to keep track of such info
> I told y'all I was moving! I should be responsive & so forth
>in about a month! I'm sorry this happened right as I was becoming an
>mjpegtools developer! It certainly wasn't planned that way!
>
>:-)
(For a guy who is so busy moving, you've been pretty chatty over the
last couple of da
I would suggest starting here:
http://www.mir.com/DMG/aspect.html
and see what gets answered. (Not everything, but it is a start.)
-matt m.
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Someth
>Cool. Maybe I should try this from another angle, given that I
>capture at 352x480, and say, by experimentation, that I discover that
>I need to crop 57 lines from the top and 57 lines from the bottom to
>be rid of the black, bit-wasting bars.
Hmm... how many bits do true black bars waste?
>If you plan HW playback it is not wise to crop the images to a unusal
>size. You should use there the yuvscaler -I
>ACTIVE_widthxheight+xoffset+yoffset for setting everything outside the
>area to real black. You can also use yuvdenoise for that.
I second that. And, to plug my own program:
Isn't this:
>True enough. But the cropping tool is mencoder, which is quite
>generic. From what I have been told, A'rpi (mencoder
>author/maintainer) doesn't much care for interlace output, so
>everything is (de-interlaced to) progressive anyway.
mutually exclusive with this:
>Well, sin
>> ? ;^)
>
>No, not really. A'rpi not caring about interlaced output devices
>simply means that he does not design around/for them. He is not
>actively plotting against them or anything, just apathetic about them.
"Your donation of only 5 dollars a week, less than the price of a
double
>On Tue, 2003-02-11 at 07:21, Martin Collins wrote:
>> On 10 Feb 2003 20:40:29 -0800
>> Florin Andrei <[EMAIL PROTECTED]> wrote:
>>
>> > What is the same typical image rescale for PAL?
>> > 720x576 --> ??? - is it 720x540?
>>
>> Of the 720 width line only 704 pixels have image info. PAL
>In case you're interested, I've *finally* posted smilutils to kino CVS.
Still cool.
>Please feel free to report issues or patches (or new tools?) via the
>kino-dev mailing list.
And here is another patch, to add the 4:1:1 mode I mentioned a few weeks ago.
With the patch, if you specify "-
>> With the patch, if you specify "-i 2" to smil2yuv, then the output
>> stream will be in the 4:1:1 subsampling mode native to NTSC DV ---
>> which can then be converted properly to 4:2:0 by y4mscaler. (The
>
> Uh, does this mean what I think it means? That all this time
> sm
> Hmmm, I wonder if y4mscaler can be used simply to do the 411 -> 420
> conversion even in the situation where no scaling is being requested.
You bet --- it is all just scaling after all:
The chroma planes are being scaled by (2/1, 1/2) and the luma plane is
getting (1/1, 1/1) (w
> Now a y4mscaler question...
>
> When should, if ever, the "-O chromass=420_MPEG2" be used?
When the output is going to be MPEG-2 encoded. The "DVD" and "SVCD" presets
automatically set this. (420_JPEG is correct for MPEG-1 and MJPEG.)
As you may expect, the output mode will
> So if a "preset" is not being used and the output is going to be
> MPEG-2 encoded then it is necessary to specify the '-O chromass'
> option. Correct?
Yep.
-matt m.
---
This sf.net email is sponsored by:ThinkGeek
Welco
>> the CVS version of MJPEG tools. Where should the 'yuvfps' utility fall
>> in the YUV filter chain ?
>>
>> yuvfps -> yuvmedian -> yuvdenoise -> yuvscaler
>>
>> or
>>
>> yuvmedian -> yuvdenoise -> yuvscaler -> yuvfps
>
>I would use: ... -> yuvfps -> yuvdenoise -> yuvscaler -> ...
>for the not interlaced video:
>Framerate: Order: AVR Bitr. MAX Bitr:
>3:1001 D F S 25932004576400
>3:1001 F D S 26110004608400
>24000:1001 D F S 23044004138000
>24000:1001 F D S 23052004143600
>24:1D F S 23092004348000
>24:1F D
Hi, all,
Sorry for the extended delay. y4mscaler v0.4.0 source and x86 binaries
are now available, at the usual spot:
http://www.mir.com/DMG/Software/y4mscaler.html
The delay was because I was planning to put up a good clear demonstration of
the benefits of using smil2yuv and y4mscale
>The binary works fine, but when compiling I get:
...
>Is "DBG" a standard function or macro that I don't seem to have, or is
>the definition missing in the source?
>
>Also, there is no y4m-config.h in the src directory, so I grabbed it
>from 0.3.0.
Yah, I screwed up, and forgot to package
>Could someone explain exactly when and where the NTSC setup (Y'+16)
>should be added?
The "+16" is not NTSC setup. It is simply footroom in the Y'CbCr encoding
scheme for digital pixel data. NTSC setup is part of the spec for *analog*
transmission.
>This much I think I know:
>
>For NTS
...okey-doke, tarball version 0.4.1 is available, with the missing files.
This time I actually tried unpacking it and compiling it.
-matt m.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_
>I understand that the lowest "legal" Y' value is 16. I assume it comes
>right off my camera in the range 16-235? But the libdv and kino
Yep -- off the camera in 16-235 range.
>documentation led me to believe that to get the same brightness on a
>computer monitor as I would get playing back
> Yep -- off the camera in 16-235 range.
(Ok, I fibbed...)
>Ok, I decided to test this out, and found some surprises. I have a
>Canon ZR40, a nothing-special DV camcorder that also records from
>video in or just digitizes and passes the video through via ieee1394.
I'll try out my Sony
> The >235 Y' values aren't uncommon --- I've seen that referred to as
> "Superwhite". These values don't map to anything in R'G'B', though,
> and need to be clipped if working in R'G'B'. Otherwise, consider it
>
>Actually, my current denoise color-correction uses RGB, so I
>> > > > Ok, so I just discovered that yuvmedianfilter has a -I switch for
>> > > > interlaced inputs (it switches to separate field filtering).
>> >
>> > Shouldn't this be something that yuvmedianfilter should set
>> > automatically from the incoming yuv4mpeg header?
>>
>> Hmmm, inte
>I tried to use jpeg2yuv tools to convert sequence of JPEG files to MJPEG
>(motion JPEG) avi movie. All works fine but I have had a quality loss
>because of recompression of JPEG images.
...
>Could somebody write me how to make MJPEG AVI from a list of JPEG files
>without image recompression
> You hit the nail on the head on this one. I build scalers
> (and hence pre and reconstruction filters) for my job. Quite
> apart from my normal struggle just to halfways find time to
> properly develop mpeg2enc this means that I can't easily do
> this for the proj
>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
And that's pretty much all I know; good luck!)
-matt m.
>On Fri, 2003-03-14 at 23:54, Matto Marjanovic 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
>> >LI
> Does the y4mtoppm utility understand the 4:1:1 output from
> "smilutils -i 2"?Be nice to get PPM and skip the intermediate
> conversion (instead of 411 -> 420 -> RGB simply 411 -> RGB).
Nope. Even better would be to have it understand 4:4:4 output (since
y4mscaler will d
>> From: Matto Marjanovic <[EMAIL PROTECTED]>
>> > Does the y4mtoppm utility understand the 4:1:1 output from
>> > "smilutils -i 2"?Be nice to get PPM and skip the intermediate...
>>
>> Nope. Even better would be to have it und
Hiya,
> yuvfps reports:
>cat stream.yuv | yuvfps -v2 > debout
> INFO: [yuvfps] yuv2fps (version 0.1) is a general frame resampling utility
>for yuv streams
> INFO: [yuvfps] (C) 2002 Alfonso Garcia-Patino Barbolani
><[EMAIL PROTECTED]>
> INFO: [yuvfps] yuv2fps -h for help, or m
1 - 100 of 129 matches
Mail list logo
