I'll follow your directions when I get a chance. May be a week or two before I
get to it, but I'll do it.
-- Ray
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX
. Just thought you might want some feedback :-)
-- Ray
Stefan M. Fendt wrote:
Ray Cole schrieb:
I grabbed the latest yuvdenoise from the repository and noticed it
core dumps.
Should be fixed...
Stefan
---
This SF.net email
I grabbed the latest yuvdenoise from the repository and noticed it core dumps.
I checked into it - it allocates the frameX[] buffers to be only half the size
needed, therefore overwriting memory (at line 777). The reason is lwidth in my
stream is 2*width. The buffer sizes are computed from
I realize this is a strange question...but if you eject the disk when it starts
skipping, and let it cool for maybe 5 minutes, then insert the disk again and
fast-forward to that part of the movie does it continue to skip at the exact
same place, or does it play fine for a while again and then
I had this problem as well (running 1.4 of libtool) and simply edited the 2
Makefile's that use this to remove '--tag=CC'. Didn't seem to have any ill
effects :-)
-- Ray
Steven M. Schultz wrote:
On Tue, 4 Jan 2005, edouard wrote:
Anyway Libtool has been upgraded to the latest version
I do hope you weren't offended that I said it was slow :-) I do appreciate that it is a
better filter, and I also have noticed the downfalls of yuvdenoise (the 'after image'
effect you mentioned). However my source generally doesn't have a lot of noise, and so I
use yuvdenoise -l 1 -m 1 -n 1
I'm using 0.4.9-pre1 of ffmpeg and it appears to produce good AC3 output. Some
versions before this gave similar problems to what you encountered - my
amplifier didn't like it and 1 of the 2 DVD players didn't like it either.
-- Ray
Steven M. Schultz wrote:
On Thu, 30 Dec 2004, Steven Boswell
I've encoded several things since successfully compiling from CVS last week and it seems to me
the quality has noticeably improved. I originally built from CVS wanting to try y4mdenoise, but
it is just too slow for me to use. However I do use y4mspatialfilter right before yuvdenoise, so
my
information, and in fact I get the right look
no matter what horizontal resolution I give.
-- Ray
Steven M. Schultz wrote:
On Wed, 29 Dec 2004, Ray Cole wrote:
I tried recording at 704x480 and 720x480, and you are correct that if I put
a piece of paper to measure the size of some objects
at
least 2.57, but at least I didn't get this AC_DEFINE message :-)
All I'm really wanting to try is the new y4mdenoise stuff. Sigh :-)
-- Ray
Ray Cole wrote:
Well, I think I was in the wrong branch. I now re-fetched the code
without specifying a branch. It looks like more modern stuff. Anyway
Got it. I ran aclocal, autoconf, and automake separately (without using
autoreconf) and ended up with a functioning setup. Odd...
Anyway, I ran ./configure, then make, and now have a new set of executables to
play with that appear to work :-)
-- Ray
Ray Cole wrote:
Ugh. I give :-)
I
Glad to see someone else has the same type of problems :-) I'm using automake
1.8.5 and autoconf 2.59. I get a ton of AM_CONDITIONAL errors. I'd love to
try out some of the changes that have happened over the past year but can't
(sniff).
processing .
Running libtoolize...
You should add the
I got past the autogen.sh stuff. Now I'm getting a plain ol' compiler error:
mpeg2encoptions.cc: In member function `int
MPEG2EncOptions::InferStreamDataParams(const MPEG2EncInVidParams)':
mpeg2encoptions.cc:149: error: `mpeg_valid_framerate_code' undeclared (first
use this function)
, please use m4_pattern_allow.
See the Autoconf documentation.
-- Ray
Ray Cole wrote:
I got past the autogen.sh stuff. Now I'm getting a plain ol' compiler
error:
mpeg2encoptions.cc: In member function `int
MPEG2EncOptions::InferStreamDataParams(const MPEG2EncInVidParams)':
mpeg2encoptions.cc
I'd installed autoconf from source. I do have a /usr/local/share/aclocal-1.8
directory. I tried creating a symbolic link from /usr/local/share/aclocal-1.8
to /usr/share/aclocal but I get the exact same results :-( I assume there is
some sort of conflict left behind by the fact I used to
Yep, I'm getting further. I'm now to the point where I am just missing some
.m4 files. I'll have to restore those. Will try again tomorrow or so.
Thanks for your help!
-- Ray
---
SF email is sponsored by - The IT Product Guide
Read honest
I had this issue with my bt card. The video tape looked just fine on TV, but when I
captured it would studder - it was duplicating frames, sometimes just a single field
(which was really weird). The bttv module has a 'vcr_hack' option that eliminated
this problem. I don't know if something
Speaking of timestamp issues... :-) I'd reported such a problem and had believed it
had to do with pulldown, but I've since switched away from using pulldown to encoding
interlaced. The counter on my set-top DVD player does really weird things - counts
very, very eradically - sometimes even
2004, Ray Cole wrote:
Speaking of timestamp issues... :-) I'd reported such a problem and had
believed it had to do with pulldown, but I've since switched away from
using pulldown to encoding interlaced. The counter on my set-top DVD
player does really weird things - counts very, very
But you should be watching the movie and not the player's display :)
My wife agrees... :-)
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo
mpeg2enc -f 8 -q 5 -a 2 -g 6 -G 18 -E -10 -N 1.0 -z t -4 2 -2 2 -r 16 -o file.m2v
Is it possible to have less that 200+ character lines? ;)
It used to be longer :-)
What are you using to do the playback? Ogle? Xine? MPlayer?
Standalone player?
mplayer and 2
-R0 is the one that seems to trigger it. The file size turns out being about 15%
smaller than with '-R 2', but the quality drops really bad.
I'm hoping to put a 1-second or so clip up soon that exhibits the problem.
-- Ray
On Wed, 28 Jan 2004 08:20:14 +0100
HI!
Ray Cole wrote:
I
(same happened when I upped -2 - file got smaller...)
-- Ray
On Fri, 23 Jan 2004 19:55:03 -0600
Ray Cole [EMAIL PROTECTED] wrote:
With the same parameters as 1.6.1.92, I'm seeing terrible quality problems.
Parameters used:
mpeg2enc -f 8 -q 5 -a 2 -g 6 -G 18 -E -10 -N 1.0 -z t -4 2 -2 2 -r
The material is at least not visibly noisy. I only denoise using yuvdenoise in 'fast'
mode to help lower the bitrate just a hair to catch some of the noise that isn't
necessarily visible.
Hmmm...as for a sample, I should be able to get a clip to you over the next day or
two. I no longer have
ffmpeg has AC3 encoding capability. At one time though (I have not
tried it recently) it did not produce DVD compatible files (the
channelassignment/rematrixing-coefficients were not correct). You
There were some changes made to ffmpeg about 6 months ago, maybe a little
PROTECTED] wrote:
On Wed, 14 Jan 2004, Ray Cole wrote:
I had this issue with the CVS version as well. I had to make a change to
utils/cpu_accel.c to use memalign rather than posix_memalign in bufalloc(). It
now looks like this:
Have you done a 'cvs update' recently
Thanks for the information. I was never real clear which 'c' values to use. Might be
useful to update the man page to indicate reasons to lower/raise it.
I'd been using nuppelrec for about 6 months with good results run through yuvkineco -
an occasional glitch but not bad. I modified
I've recently purchased a large HD and have started recording raw images. I just
wasn't happy with the various codecs I'd been using to record.
What I've found is yuvkineco worked better on the material that had undergone lossy
compression than it works on the raw-recorded clips. It seems to
Has anyone else noticed that while a DVD generated with mpeg2enc ifogen works in
their standalone player that the standalone player doesn't count seconds evenly? I've
noticed my standalone player with DVDs I generate counts something like '1, 2,
3...delay...4, 5, 6...delay', and the time
In previous posts I had discussed that I'd had to force CBR in previous releases but
would give VBR a try next time I encoded. I gave it a try and it does indeed work. I
used -q 6 with no specification of bitrate (guess that defaults to 750 bps) and it
used about 3/4 of the CD (140 minute
:18 -0500
Ray Cole [EMAIL PROTECTED] wrote:
Yep, I see the following:
INFO: [mpeg2enc] SETTING 3DNOW and EXTENDED MMX for QUANTIZER!
INFO: [mpeg2enc] SETTING EXTENDED MMX for MOTION!
INFO: [mpeg2enc] SETTING MMX for TRANSFORM!
INFO: [mpeg2enc] SETTING EXTENDED MMX for PREDICTION
I've made hundreds of DVDs using the VBR logic and they all
play fine on a variety of standalone players ranging from an
old Audiovox portable to a Philips (which will play anything it
seems).
I'm sure it works now, but it's one of those situations where cbr is working
.
-- Ray
On Sun, 24 Aug 2003 22:23:03 -0700 (PDT)
Steven M. Schultz [EMAIL PROTECTED] wrote:
On Sun, 24 Aug 2003, Ray Cole wrote:
I downloaded the source and built it. It seems to run about 4x slower
than 1.6.1. Any ideas?
Get a new watch? ;-)With out some numbers I find
I downloaded the source and built it. It seems to run about 4x slower than 1.6.1.
Any ideas?
---
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
Someone (I would assume it was Kevin Atkinson, the author of the above filter but
can't find the message now...) posted recently about temporal-med and wanted feedback.
I've been using it for a little over a week now and it seems to really work well. I
get a little bit of interference because
Can you use 'tee' to accomplish it?
mkfifo pipe1
mkfifo pipe2
tee pipe1 pipe2 $1 /dev/null
yuvscaler ... pipe1
mplayer ... pipe2
wait
'tee' will take data from '$1' and write to pipe1 and pipe2 (and also to stdout,
therefore the redirection of its stdout to /dev/null, although you could
Never mind...I was passing '-c 0' to it. Apparently that was causing the pain :-)
-- Ray
On Sun, 17 Aug 2003 08:24:09 -0500
Ray Cole [EMAIL PROTECTED] wrote:
I've got a problem with yuvkineco that I'm hoping someone can help with. A number
of files I use yuvkineco on turn out not having
On Mon, 30 Jun 2003 22:04:15 -0500
Ray Cole [EMAIL PROTECTED] wrote:
Say, that worked! Thanks! I haven't actually performed an mpeg2enc on it yet
(didn't want to wait that long to know if the patch was going to work or not), but
the output from -c looks perfect.
-- Ray
On Mon, 30 Jun
the patch hitoshi.kawamata will do the trick.
I'll cross my fingers :-)
-- Ray
On Mon, 30 Jun 2003 19:02:54 -0500
Ray Cole [EMAIL PROTECTED] wrote:
Attached is the output. See around 1:40:00 where it starts to get out of sync.
-- Ray
On Mon, 30 Jun 2003 00:16:29 -0400
[EMAIL PROTECTED
.
Thank you bug report.
Ray Cole [EMAIL PROTECTED] writes:
I've been using yuvkineco/mpeg2enc for pulldown. It stays perfectly in sync until
it reaches around 100 minutes into the video. Then it gets WAY out of sync. It
isn't slowly getting out of sync at 100, it just suddenly gets out
I've been using yuvkineco/mpeg2enc for pulldown. It stays perfectly in sync until it
reaches around 100 minutes into the video. Then it gets WAY out of sync. It isn't
slowly getting out of sync at 100, it just suddenly gets out of sync.
Any ideas?
If I use shorter videos that are less than
41 matches
Mail list logo
