HI!
The Windows program "TMPGEnc DVD Author" in its newest version (older
version did not warn) complains about GOP size too long for MPEGs that I
encoded with mjpegtools 1.6.2.
According to the mjpegtools manual, the default GOP size should be OK
for PAL and NTSC and I do not alter it with my
HI!
Steven M. Schultz wrote:
The problem is not mpeg2enc and probably not with the memory.
Are you using the nvidia drivers?
nvidia:__insmod_nvidia_O ...
Yes. NVidia 6111.
Using Suse 9.0, kernel 2.4.21-266-smp4G, mjpegtools 1.6.2.
I've had a couple times when the machine (dual At
HI!
Ronald S. Bultje wrote:
I got a kernel oops while mpeg2enc was running. When I tried the same
encoding again later (after reboot), the machine froze.
That implies broken memory, or you've overclocked a but too much.
I have tested the memory with memtest86 (several passes) with no problems.
The
HI!
Richard Ellis wrote:
Maybe heat?
Mpeg2enc will push your CPU to run at 100% power for quite a lengthy
amount of time, and if your CPU cooler is not able to handle the heat
load, you can get crashes and freezes.
Hm, according to sensors, the heat is not too much (60 degrees celsius).
Also, are y
HI!
I got a kernel oops while mpeg2enc was running. When I tried the same
encoding again later (after reboot), the machine froze.
This is the first time, I had problems with mpeg2enc. I tested the
memory and hard disks (with smart) and there seem to be no hardware errors.
Anyone any idea?
Using
HI!
Richard Ellis wrote:
What type of system (cpu) is being used? SSE, MMX,
MMX-Extended, ???
P3-866. Don't know exactly, what type of extra instructions this
one has.
P3 class has MMX, maybe MMX-extended, and the initial implementation
of SSE. If you watch the mpeg2enc startup messages, it sh
HI!
Steven M. Schultz wrote:
As I wrote in another thread: I have a still example, I think, for that
problem: http://www.boerkel.de/q.zip
Initially, to me, that just looks like a variation on the grey
blocks/splotches that always seem appear during dark scenes. I wonder
if
HI!
Ray Cole wrote:
I realize a sample would be worth 1GB words...but unless I pop the old processor back in place (which I hate doing because the CPU fan is so darn difficult to get off/on...I hate the clip on it...) I don't think I'm going to be able to reproduce it.
As I wrote in another threa
HI!
Ronald Bultje wrote:
it's my pleasure to announce the official release of mjpegtools 1.6.2.
Is there a list of changes somewhere?
For example, where could I read, that from .93 on, -R 0 was the default?
Thanks!
Thomas
---
The SF.Net em
HI!
In some scenes, the background of my MPEG2 is "pixelizing" (ist this a
word?) every second or so. It's some kind of mosaic effect. The original
AVI does not have this.
It is more noticable on my Toshiba player on TV than with xine on a TFT
display.
I have tried "-q 4 -K tmpgenc -b 9000 -
HI!
Andrew Stevens wrote:
I was able to confirm it is the default of '-R 0' that was causing poor
quality. If I use '-R 0' on 1.6.1.92 I get the same flood of artifacts
that I get with 1.6.1.93.
at least something broken.I haven't heard any other feedback so it could
a build problem...
Some
HI!
Matto Marjanovic wrote:
>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 even involved in this thread.
Right. ;-)
Who/what blacklisted my host? We've been re
Apparently, this is almost solved by setting -R 2. Thanks to Ray!
Thomas Börkel wrote:
HI!
I have made some tests encoding an NTSC AVI (Xvid) to MPEG2 with
transcode/mpeg2enc.
If I use -q 2 or -q 3, I get pulsating (every second or so) block
artefacts in the background, which I get not with
HI!
Matto Marjanovic wrote:
>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 even involved in this thread.
Right. ;-)
Who/what blacklisted my host? We've been re
HI!
Ray Cole wrote:
I was able to confirm it is the default of '-R 0' that was causing poor quality. If I use '-R 0' on 1.6.1.92 I get the same flood of artifacts that I get with 1.6.1.93.
I have also some strange artifacts with .93 (although I don't know about
.92). What -R setting should I use
HI!
Sorry to reply on the list, but your host ist blacklisted, so I cannot
send email to you.
I tried to use some automatic guesses from y4mscaler, but they did not
do what's IMHO right.
Example:
I have an NTSC AVI with 640x352 16:9. I want to transcode it to MPEG2
NTSC 4:3 (720x480).
According
HI!
Steven M. Schultz wrote:
I can see light vertical stripes in bright scenes in my encoded result.
I seem to recall transcode's -Z scaling causing problems for someone
else in the past.
A (much) better way to perform scaling is to use 'y4mscaler'. You can
find y4mscaler
HI!
Bernhard Praschinger wrote:
Hallo
I can see light vertical stripes in bright scenes in my encoded result.
I can't see them in the original AVI (Xvid).
How large ist the stripe ?
Do you scale (guessed from the -Z option) the picture ?
If yest does it also happen when you don't scale it ?
That
HI!
I have an example to download and would be glad to hear comments:
http://www.boerkel.de/q.zip
Forgot to mention: File size is 1.5 MB.
Thomas
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Developmen
HI!
I can see light vertical stripes in bright scenes in my encoded result.
I can't see them in the original AVI (Xvid).
Using transcode 0.6.12, mjpegtools .93 (RC 4), xvidcore 1.0b3 like this:
transcode -i "$1" -Z 720x352 -Y-64
-w 5000 --pulldown --export_fps 0,4 --export_asr 2 -V -M 4 -y
mpeg2
HI!
I have made some tests encoding an NTSC AVI (Xvid) to MPEG2 with
transcode/mpeg2enc.
If I use -q 2 or -q 3, I get pulsating (every second or so) block
artefacts in the background, which I get not with -q 4.
I have an example to download and would be glad to hear comments:
http://www.boerke
HI!
Steven M. Schultz wrote:
A lower -q (2 or 3) gets me higher file sizes, so shouldn't it also be
potentially better quality?
Yes, it will give better quality. That may or may not be visible :)
I have a problem with -q 2 and 3. See seperate thread.
Ah, it's letterboxed so you have
HI!
In the mjpegtools HowTo, I read that a quality factor below 4 is not
recommended (= not necessary?). Is this still true?
A lower -q (2 or 3) gets me higher file sizes, so shouldn't it also be
potentially better quality?
I want to encode about 43 minutes of video with 720x480 final size (4:
HI!
Andrew Stevens wrote:
I was able to encode NTSC SVCD -> NTSC DVD with .92 and transcode
(although with wrong timestamps). .93 crashes after about 16 MB result
file size. How can I provide more info to fix this?
Try doing the encode step by step with intermediate files.
Did it. And I disovere
HI!
Andrew Stevens wrote:
With 1.6.1.92,
timestamp in NTSC movies was wrong. This seems to be fixed in .93, but I
was wondering.
Do you really mean timestamp? There was a rate control issue in .92
Maybe it was that. Other tools showed the wrong length of the encoded movie.
With .93 and trans
HI!
Where can I found the release notes for new versions of mjpegtools (I
did not find anything up to date in the source archive)? With 1.6.1.92,
timestamp in NTSC movies was wrong. This seems to be fixed in .93, but I
was wondering.
With .93 and transcode, I got some warnings during encoding
26 matches
Mail list logo