Re: [Mjpeg-users] mplex not recognizing mpeg1 from mencoder

[Steven M. Schultz]

On 4 Jan 2004, Florin Andrei wrote:

> > Are you sure that was the cause or was it pusing the bitrate too high
> > and generating streams out of spec on the peaks?   As I recall the
> > stuttering was caused by -b 9000.
> 
> Ok, i can't reproduce the problem now, and i'm using 8500 kbps, so
> perhaps you're right.

AH, ok - I was hoping my memory hadn't developed a parity error ;)

But, you also may be right...

Believe it or not I've created a DVD that hardware/standalone players
have absolutely no trouble with but software players (such as Ogle
and Apple's DVD Player) either spew errors about or artifact badly.
I think Xine will do ok since it uses libmpeg2 for the decoding.

A query has been sent asking if an option can be added to disable
DPME upon request.  It is not required to implement DPME in the no
B frame case and it seems that some _software_ players do not 
implment DP.

Cheers,
Steven Schultz



---
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] mplex not recognizing mpeg1 from mencoder

[Florin Andrei]

On Sun, 2004-01-04 at 17:23, Steven M. Schultz wrote:
> On 4 Jan 2004, Florin Andrei wrote:
> 
> > MPEG2 without B frames makes some DVD players choke. The default
> 
> What player is so braindamaged and standards non-compliant as to
> choke on an *optional* part of the MPEG-2 specs?   (B frames are 
> optional).
> Are you sure that was the cause or was it pusing the bitrate too high
> and generating streams out of spec on the peaks?   As I recall the
> stuttering was caused by -b 9000.

Ok, i can't reproduce the problem now, and i'm using 8500 kbps, so
perhaps you're right.

-- 
Florin Andrei

http://florin.myip.org/



---
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] mjpegtools 1.6.2 release candidate 3 online

[Steven M. Schultz]

On 4 Jan 2004, Florin Andrei wrote:

> # pkg-config --cflags mjpegtools
> -I/usr/local/include/mjpegtools

> Which is wrong, because i installed mjpegtools in /usr not in /usr/local
> Then i forced -I/usr/include/mjpegtools to the CFLAGS and all was ok.

> This happened when using 1.6.1.92. Please fix.

To quote the Cylon from Battlestar Galactica:  "By your command".



Actually nothing to do - the cvs version's been fixed for quite some
time.  No idea when it was done, but I just ran a test and the
mjpegtools.pc file correctly contained $prefix in all the right
places when "./configure --prefix=/usr" was done.

Now that mplex has been fixed the 1.6.1.93 or whatever the next
RC-N is called (3 or 4 , something like that ;)) should be up in a
couple days (right Ronald?).

Cheers,
Steven Schultz



---
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] mjpegtools 1.6.2 release candidate 3 online

[Florin Andrei]

On Sat, 2003-11-29 at 18:03, Steven M. Schultz wrote:
> On 29 Nov 2003, Florin Andrei wrote:
> 
> > In file included from export_yuv4mpeg.c:42:
> > /usr/include/mjpegtools/yuv4mpeg.h:29:25: mjpeg_types.h: No such file or
> > directory
> > /usr/include/mjpegtools/yuv4mpeg.h:33:27: mjpeg_logging.h: No such file
> 
>   Ah, in that case "-I/usr/include/mjpegtools" added to CFLAGS will
>   work.
> 
>   There are 2 ways to do that:
> 
>   1) mjpegtools is pkg-config enabled, so 
> 
>   pkg-config --cflags mjpegtools

Unfortunately, the result of it is:

# pkg-config --cflags mjpegtools
-I/usr/local/include/mjpegtools

Which is wrong, because i installed mjpegtools in /usr not in /usr/local
Then i forced -I/usr/include/mjpegtools to the CFLAGS and all was ok.

This happened when using 1.6.1.92. Please fix.

-- 
Florin Andrei

http://florin.myip.org/



---
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] Remuxing split VCD-files

[Robert Kesterson]

On Mon, 05 Jan 2004 00:05:50 +0100, Lehmeier Michael <[EMAIL PROTECTED]> 
wrote:
On Sat, 2004-01-03 at 18:13, Robert Kesterson wrote:
On Sat, 03 Jan 2004 16:01:28 +0100, Lehmeier Michael <[EMAIL PROTECTED]>
wrote:
> My problem: They have been split at a later time without care, just
> brutally hacked apart at a certain point of the file.
Do you mean brutally hacked apart like "split"?
Yes, like split.
When I said "split", I meant the unix utility of the same name.  Split 
just breaks a file into pieces of whatever size you tell it to.  It has 
nothing to do with mpeg or video -- it splits any file into pieces.

If so, can't you just cat
them back together?
I could, if I had the originals.
If they were split with "split", then catting them back together would 
produce the original.  But I'm guessing from your other messages that this 
isn't what was done.

I seem to recall a tool called "mp3cat" that would concatenate elementary 
streams and demux program streams, but I don't think I ever used it.  A 
quick google search found it at 
http://www.tux.org/pub/packages/orphaned/broadcast2000/mpeg2movie.html -- 
maybe that would work?

--
  Robert Kesterson
  [EMAIL PROTECTED]
---
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] mplex not recognizing mpeg1 from mencoder

[Steven M. Schultz]

On 4 Jan 2004, Florin Andrei wrote:

> MPEG2 without B frames makes some DVD players choke. The default

What player is so braindamaged and standards non-compliant as to
choke on an *optional* part of the MPEG-2 specs?   (B frames are 
optional).

Are you sure that was the cause or was it pusing the bitrate too high
and generating streams out of spec on the peaks?   As I recall the
stuttering was caused by -b 9000.  That can work with commercial
pressed DVDs but some players have problems with RECORDABLE media
at high bitrates due to the lesser reflectivity of the media.

> What would be the new -R setting to imitate the old behaviour? Would it
> be "-R 2"?

Yep, that's the old behaviour.   

I have a hunch that any problems with -R 0 are due to other factors
and not the lack of B frames.   

Hmmm - having said all that it might be that DPME (Dual Prime Motion
Estimation) might be a possible  problem area - can't recall if that was
required or not.   It is possible to have no B frames and not use
DPME (but no B frames are a requirement to use DPME - at least at
[EMAIL PROTECTED]).   If anything I'd have expected an old portable (Audiovox)
to have a problem with no B frame based SVCD and it sailed right thru.

Steven Schultz



---
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] mplex not recognizing mpeg1 from mencoder

[Florin Andrei]

On Fri, 2004-01-02 at 16:29, Steven M. Schultz wrote:

> Actually most of the speed up was done by changing the defaults to
> omit B frames ("-R 0")

I do not agree with that decision.
MPEG2 without B frames makes some DVD players choke. The default
settings should attempt to be "safe" and should not generate streams
that might not work.

What would be the new -R setting to imitate the old behaviour? Would it
be "-R 2"?

-- 
Florin Andrei

http://florin.myip.org/



---
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] Compare yuvscaler and y4mscaler

[Steven M. Schultz]

On Sun, 4 Jan 2004 [EMAIL PROTECTED] wrote:

> I am encoding from a 672x272 AVI movie.

Ah, ok.   

> > Ah, I see the "-vf expand :504" in the mplayer command.   Why is that
> > present?   Perhaps if that was left out things would work better.
> 
> It adds black borders at the top and bottom of the video, bringing the

I think that is what the '-I matte=' option of y4mscaler is for.

> the frame size to 672x504, which gives an aspect ratio of 4:3. Omitting
> the expansion from mplayer does not help y4mscaler.

I didn't see the 672x272 (and thought perhaps you were coming from
a DVD).

> mplayer also hard codes a subtitle stream into the video stream. It is
> being put at the bottom black border.

What happens if you expand to just 480 instead of 504?   That would
give a size of 640x480 which is also 4/3 and is a NTSC frame size.

> > Is the data really progressive?   If so then the 'interlace: none'
> > is correct.  
> 
> Yes, it is progressive.

Ok - was curious about that because that is one of the things that
is often not set up right in the yuv4mpeg header.

> > > Adding the option "-I norm=NTSC" to the y4mscaler command line does
> > > not help (the error message is the same from y4mscaler).
> 
> Where can I ask about it?

Right here - the author of y4mscaler hangs out here on occasion ;)

Cheers,
Steven Schultz



---
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] Compare yuvscaler and y4mscaler

[romildo]

On Sun, Jan 04, 2004 at 02:51:18PM -0800, Steven M. Schultz wrote:
> 
> On Sun, 4 Jan 2004 [EMAIL PROTECTED] wrote:
[...]
> >   yuvscaler -v 0 -O SVCD -n n
> > 
> > as a filter. What would be the scaling method whose resulting
> > quality best aproximates to the yuvscaler call above?
> 
>   Hmmm, what does yuvscaler use by default?  I thought it was a simple
>   box or resample filter and that you had to specify the better 
>   'bicubic' one with the -M BICUBIC option.

I have borrowed the yuvscaler command line (and other pieces too)
from the mencvcd script that comes with mplayer. I have had
no clue about specifying a scaling method. I will be doing so
for now on.

[...] 
 
> > $ mplayer -noframedrop -vo yuv4mpeg -nosound -v -osdlevel 0 \
> > the.two.towers.avi -sub the.two.towers.srt -subpos 78 \
> > -vf expand=:504
> > $ cat stream.yuv |
> >   y4mscaler -O preset=SVCD |
> >   mpeg2enc -v 0 -I 0 -s -f 5 -V 230 -S 800 -a 2 -F 1 -n n -4 2 -2 1 \
> > -b 2800 -B 284 -q 6 -K FILE=matrix.txt -R 0 -E -11 \
> > -o the.two.towers.m2v
> > 
> > But y4mscaler gives the messages:
> > 
> >INFO: [y4mscaler] Input Stream Header:
> >INFO: [y4mscaler] <<<   frame size:  672x504 pixels (508032 bytes)
> >INFO: [y4mscaler] <<<   frame rate:  239759/1 fps (~23.975900)
> >INFO: [y4mscaler] << >INFO: [y4mscaler] <<< sample aspect ratio:  ?:?
> > **ERROR: [y4mscaler] Unknown norm; cannot determine SVCD format.
> 
>   That's probably because the input frame size doesn't match one of
>   the NTSC sizes (Nx480).   x504 is a very strange size, isn't it?
>   NTSC would be 640x480 or so  wouldn't it?

I am encoding from a 672x272 AVI movie.

>   Ah, I see the "-vf expand :504" in the mplayer command.   Why is that
>   present?   Perhaps if that was left out things would work better.

It adds black borders at the top and bottom of the video, bringing the
the frame size to 672x504, which gives an aspect ratio of 4:3. Omitting
the expansion from mplayer does not help y4mscaler.

mplayer also hard codes a subtitle stream into the video stream. It is
being put at the bottom black border.

>   Is the data coming from a DVD?   If so then do not have mplayer 
>   expand/zoom the data - leave it as 720x480 and then y4mscaler will
>   see that it is a NTSC stream.

Data is not coming from DVD, but from an AVI file.

>   mplayer's yuv4mpeg output does not seem to get the header fields
>   right.   That's why the sample aspect shows up as unknown "?:?".
> 
>   Is the data really progressive?   If so then the 'interlace: none'
>   is correct.  

Yes, it is progressive.

> > Adding the option "-I norm=NTSC" to the y4mscaler command line does
> > not help (the error message is the same from y4mscaler).
> 
>   That is a bit of a mystery

Where can I ask about it?

Regards.

Romildo


---
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

[Mjpeg-users] mencvcd script

[JoeHill]

I'm not sure if this is the proper channel to ask about the mencvcd script, so
let me know in whatever appropriate manner ;-)

Anyhow, I have a DivX file which I encoded to SVCD, the picture quality was
great but the sound was waay off, and I suspect it is because of my use of
incorrect command line switches.

First, I could not simply do:

mencvcd  -svcdout 

because I got this error:

++ WARN: [yuvscaler] Could not infer norm (PAL/SECAM or NTSC) from input data
(frame size=576x432, frame rate=11988011:50 fps)!!**ERROR: [yuvscaler] No
norm specified, cannot determine VCD output size. Please use the -n
option!**ERROR: [mpeg2enc] Could not read YUV4MPEG2 header: system error (failed
read/write)!

So I did some playing around, and tried this:

$mencvcd  -svcdout -vfr 4 -tvnorm n .avi

and it successfully encoded, but the sound was way *behind* the video, by about
15- 20 seconds.

Before I try playing around again (this takes a lng time), should I be going
for a *higher* video framerate, or lower? I can't wrap this poor holiday-boozing
noggin around it right now...

Thanks all!

-- 
JoeHill ++ ICQ # 280779813
Registered Linux user #282046
Homepage: www.orderinchaos.org
+++
"In the long run, there is no capitalism without conscience; there is no wealth
without character."-- George W. Bush on Wall Street, July 9, 2002 

"It was like watching a whore pretend to be dean of Southern Methodist
University's School of Theology."-- Molly Ivins and Lou Dubose, "Bushwhacked"


---
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] Compare yuvscaler and y4mscaler

[romildo]

On Sun, Jan 04, 2004 at 09:28:30AM -0800, Steven M. Schultz wrote:
> 
> On Sun, 4 Jan 2004 [EMAIL PROTECTED] wrote:
> 
> > How do y4mscaler and yuvscaler compare when scaling a video stream for MPEG2
> > encoding for SVCD, in terms of speed and image quality?
> 
>   I've found y4mscaler to be better.  Depending on the scaling method
>   chosen (and y4mscaler offers many to choose from) the speed can be
>   very fast to fairly slow.   You have the choice of (and you can see
>   this with 'y4mscaler -S option=help') linear, quadratic, cubic, 
>   cubicCR, cubicB, and sinc:N (where you can choose how many taps are
>   used - value of N is open to debate, the higher the value the slower
>   the speed but higher quality - reasonable value is 4, I tend to use 8).

How does its speed compare to yuvscaler when encoding to
similar quality (it that is possible anyway)? I have been
using yuvscaler with the command line call:

  yuvscaler -v 0 -O SVCD -n n

as a filter. What would be the scaling method whose resulting
quality best aproximates to the yuvscaler call above?

> 
>   The other thing I use y4mscaler for is the chroma space conversion -
>   usually to go from 4:1:1 to 4:2:0 but I have on occasion used it to
>   create 4:2:2 or 4:4:4 content for testing.

I do not know yet when a chroma space conversion is needed.
In fact, I have not yet studied about chroma space. I think
that for the processing I have done up to know it was not
needed. Is there a specific situation where chroma space
conversion is required?

>   The presets are quite useful and do a good job of intuiting the
>   correct proceedure. [...]

Do the presets set a good scaling method? Or should I worry
about learning them to choose one?

>   Try it, I think you'll like it ;)

I am trying it with the following commands:

$ mkfifo -m 660 stream.yuv
$ mplayer -noframedrop -vo yuv4mpeg -nosound -v -osdlevel 0 \
the.two.towers.avi -sub the.two.towers.srt -subpos 78 \
-vf expand=:504
$ cat stream.yuv |
  y4mscaler -O preset=SVCD |
  mpeg2enc -v 0 -I 0 -s -f 5 -V 230 -S 800 -a 2 -F 1 -n n -4 2 -2 1 \
-b 2800 -B 284 -q 6 -K FILE=matrix.txt -R 0 -E -11 \
-o the.two.towers.m2v

But y4mscaler gives the messages:

   INFO: [y4mscaler] Input Stream Header:
   INFO: [y4mscaler] <<<   frame size:  672x504 pixels (508032 bytes)
   INFO: [y4mscaler] <<<   frame rate:  239759/1 fps (~23.975900)
   INFO: [y4mscaler] <<

Re: [Mjpeg-users] Remuxing split VCD-files

[Lehmeier Michael]

Okay, since I didn't have my original material anymore and re-encoding
the VCD is not really an option, I used a sledgehammer solution.

I created an a couple of frames long, black video sequence and put it at
the beginning of each video file.
mplex then recognizes it as video stream and although it gives a couple
of complaints, it continues muxing.

This works for mplex (most of the times) and my players (most of the
times).
It is dirty, it is bad, but it is better than a VCD encoded twice.

-- 
Lehmeier Michael <[EMAIL PROTECTED]>


---
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] problem with mplex and lpcm (Andrew Stevens please read!)

[Robert W. Fuller]

I was using the software player xine.  I will have an opportunity to 
test with hardware in the near future.  I am building up to authoring my 
first DVD.  I've done a lot of SVCD's but recently acquired a DVD 
writer.  When I get my first DVD authored to my statisfaction, I'll try 
both with and without "-W mplayer_hdr" and let you know the results on 
my hardware player.  Thank you for the reply!

Andrew Stevens wrote:

Gert, Robert,

Thanks very much for the LPCM feedback.   It is *extremely* interesting to get 
real feedback on some of these fiddly issues.  Just a quick question: are the 
noise problems Robert had with a hardware player or software?  If hardware, 
this would indicate there is a 'funny' alignment constraint in DVD for LPCM 
audio sectors a bit akin the really awful things done to MP2 audio in VCD.

cheers,

	Andrew

 





---
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] Compare yuvscaler and y4mscaler

[Steven M. Schultz]

On Sun, 4 Jan 2004 [EMAIL PROTECTED] wrote:

> How does its speed compare to yuvscaler when encoding to
> similar quality (it that is possible anyway)? I have been

I haven't measured it - scaling is the least cpu intense activity
that's going on so that has never been the bottleneck.

>   yuvscaler -v 0 -O SVCD -n n
> 
> as a filter. What would be the scaling method whose resulting
> quality best aproximates to the yuvscaler call above?

Hmmm, what does yuvscaler use by default?  I thought it was a simple
box or resample filter and that you had to specify the better 
'bicubic' one with the -M BICUBIC option.

> I do not know yet when a chroma space conversion is needed.

You most likely do not have to worry about it unless you're 
using use DV data in its original 4:1:1 format.

> needed. Is there a specific situation where chroma space
> conversion is required?

If you use either ffmpeg or smil2yuv to get 4:1:1 data then eventually
that needs to be converted to 4:2:0 before going to mpeg2enc.   
Filtering (such as yuvdenoise for example) is best performed on the
original data (before it has been converted, resampled, whatever) - thus
I obtain 4:1:1 data with 'smil2yuv -i 2 inputfile.dv', do whatever
filtering (yuvmedianfilter, yuvdenoise, etc) is needed and then
'y4mscaler -O chromass=420_MPEG2' just before the 'mpeg2enc' command.

> Do the presets set a good scaling method? Or should I worry
> about learning them to choose one?

No, the scaling method still needs to be selected.   A _very_ good one
is "-S option=sinc:4", but another good one (perhaps better for SVCD
use) is "-S option=cubicCR"

> $ mplayer -noframedrop -vo yuv4mpeg -nosound -v -osdlevel 0 \
> the.two.towers.avi -sub the.two.towers.srt -subpos 78 \
> -vf expand=:504
> $ cat stream.yuv |
>   y4mscaler -O preset=SVCD |
>   mpeg2enc -v 0 -I 0 -s -f 5 -V 230 -S 800 -a 2 -F 1 -n n -4 2 -2 1 \
> -b 2800 -B 284 -q 6 -K FILE=matrix.txt -R 0 -E -11 \
> -o the.two.towers.m2v
> 
> But y4mscaler gives the messages:
> 
>INFO: [y4mscaler] Input Stream Header:
>INFO: [y4mscaler] <<<   frame size:  672x504 pixels (508032 bytes)
>INFO: [y4mscaler] <<<   frame rate:  239759/1 fps (~23.975900)
>INFO: [y4mscaler] <<INFO: [y4mscaler] <<< sample aspect ratio:  ?:?
> **ERROR: [y4mscaler] Unknown norm; cannot determine SVCD format.

That's probably because the input frame size doesn't match one of
the NTSC sizes (Nx480).   x504 is a very strange size, isn't it?
NTSC would be 640x480 or so  wouldn't it?

Ah, I see the "-vf expand :504" in the mplayer command.   Why is that
present?   Perhaps if that was left out things would work better.

Is the data coming from a DVD?   If so then do not have mplayer 
expand/zoom the data - leave it as 720x480 and then y4mscaler will
see that it is a NTSC stream.

mplayer's yuv4mpeg output does not seem to get the header fields
right.   That's why the sample aspect shows up as unknown "?:?".

Is the data really progressive?   If so then the 'interlace: none'
is correct.  

> Adding the option "-I norm=NTSC" to the y4mscaler command line does
> not help (the error message is the same from y4mscaler).

That is a bit of a mystery

Steven Schultz



---
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

[Mjpeg-users] mencvcd script

[JoeHill]

I'm not sure if this is the proper channel to ask about the mencvcd script, so
let me know in whatever appropriate manner ;-)

Anyhow, I have a DivX file which I encoded to SVCD, the picture quality was
great but the sound was waay off, and I suspect it is because of my use of
incorrect command line switches.

First, I could not simply do:

mencvcd  -svcdout 

because I got this error:

++ WARN: [yuvscaler] Could not infer norm (PAL/SECAM or NTSC) from input data
(frame size=576x432, frame rate=11988011:50 fps)!!**ERROR: [yuvscaler] No
norm specified, cannot determine VCD output size. Please use the -n
option!**ERROR: [mpeg2enc] Could not read YUV4MPEG2 header: system error (failed
read/write)!

So I did some playing around, and tried this:

$mencvcd  -svcdout -vfr 4 -tvnorm n .avi

and it successfully encoded, but the sound was way *behind* the video, by about
15- 20 seconds.

Before I try playing around again (this takes a lng time), should I be going
for a *higher* video framerate, or lower? I can't wrap this poor holiday-boozing
noggin around it right now...

Thanks all!

-- 
JoeHill ++ ICQ # 280779813
Registered Linux user #282046
Homepage: www.orderinchaos.org
+++
"In the long run, there is no capitalism without conscience; there is no wealth
without character."-- George W. Bush on Wall Street, July 9, 2002 

"It was like watching a whore pretend to be dean of Southern Methodist
University's School of Theology."-- Molly Ivins and Lou Dubose, "Bushwhacked"


---
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

[Mjpeg-users] problems with lml33

[Douglas Fraser]

Sirs:

Thank-you for the suggestions on tuning the driver-zoran.  I have tried
different v4l_nbufs and anything else I could see but to no affect.  I have
included a syslog dump of one of my capture attempts, in the hope that it
will point something out to the more knowledgeable.

Something of note is that if I set the video input source to black or house
color bars, it will capture all day long.  If the source is set to live
video it fails after a minute or so.  Obviously black or bars will compress
much better then a moving video source, so does this suggest timing, or
buffer size?  Could it be in the capture program (lavrec) and not the
driver?

Thank-you for any help
Douglas Fraser


from my last email:
The system is an ASUS P4S533-MX (SIS651 chipset) with a 2gig celeron.  The
LML33.23 card has IRQ10 by itself. Gentoo linux 2.4.20-r9

I also have a DC10Plus card that I can swap in place of the LML33, of course
it works just fine with both versions of the driver.  I would like to be
able to use the LML33, the DC10Plus is slated for another machine.

I also tried moving the LML33 into a machine with a P3 1gig and intel
chipset, failed the same way.



lavrec -n256 -b1024 -in -d1 -fa -a0 --file-flush 1 test-%20d.avi
++ WARN: [lavrec] Unable to set negative priority for main thread
++ WARN: [lavrec] Pthread Real-time scheduling for main thread could not be
enabled
++ WARN: [lavrec] Closing file(s) and exiting - Output file(s) my not be
readable due to error
**ERROR: [lavrec] Error syncing on a buffer: Timer expired

total time open to close 01:09

driver set to debug=4
11:44:21 localhost kernel: LML33[0]: zoran_open(lavrec, pid=[1633]),
users(-)=0
11:44:21 localhost kernel: LML33[0]: check_jpg_settings() - dec: 1, Hdcm: 1,
Vdcm: 1, Tdcm: 1
11:44:21 localhost kernel: LML33[0]: check_jpg_settings() - x: 0, y: 0, w:
720, y: 240
11:44:21 localhost kernel: LML33[0]: lml33_init()
11:44:21 localhost kernel: LML33[0]: jpeg_codec_sleep() - sleep
GPIO=0x8500
11:44:21 localhost kernel: LML33[0]: jpeg_codec_sleep() - wake
GPIO=0x8700
11:44:21 localhost kernel: LML33[0]: jpeg_codec_sleep() - wake
GPIO=0xaf00
11:44:21 localhost kernel: LML33[0]: jpeg_codec_sleep() - sleep
GPIO=0xad00
11:44:21 localhost kernel: LML33[0]: enable_jpg(IDLE)
11:44:21 localhost kernel: LML33[0]: VIDIOCSCHAN - channel=0, norm=1
11:44:21 localhost kernel: LML33[0]: VIDIOCGCHAN - channel=0
11:44:21 localhost kernel: LML33[0]: VIDIOCGCAP
11:44:21 localhost kernel: LML33[0]: BUZIOC_G_PARAMS
11:44:21 localhost kernel: LML33[0]: BUZIOC_S_PARAMS
11:44:21 localhost kernel: LML33[0]: check_jpg_settings() - dec: 0, Hdcm: 1,
Vdcm: 1, Tdcm: 1
11:44:21 localhost kernel: LML33[0]: check_jpg_settings() - x: 0, y: 0, w:
720, y: 240

## set -n 256 -b 1024 --file-flush 1 in lavrec just to see if it made any
difference

11:44:21 localhost kernel: LML33[0]: BUZIOC_REQBUFS - count=256,
size=1048576
11:44:21 localhost kernel: LML33[0]: jpg_fbuffer_alloc() - 16384 KB
allocated
11:44:21 localhost kernel: LML33[0]: mmap(MJPEG) of 0x40ae5000-0x41ae5000
(size=16777216)
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=0
11:44:21 localhost kernel: LML33[0]: jpeg_codec_sleep() - wake
GPIO=0xaf00
11:44:21 localhost kernel: LML33[0]: enable_jpg(MOTION_COMPRESS)
11:44:21 localhost kernel: LML33[0]: jpeg_start
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=1
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=2
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=3
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=4
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=5
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=6
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=7
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=8
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=9
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=10
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=11
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=12
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=13
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=14
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=15
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=16
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=17
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=18
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=19
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=20
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=21
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=22
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=23
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=24
11:44:21 localhost kernel: LML33[0]: BUZIOC_QBUF_CAPT - frame=25
11:44:21 localhost kernel: LML33[0]: BUZIO

Re: [Mjpeg-users] Remuxing split VCD-files

[Steven M. Schultz]

On Sun, 4 Jan 2004, Lehmeier Michael wrote:

> > Do you have the original source material to perform encoding from?
> 
> Alas, no.

Sigh, I was afraid of that ;(

> > the file 'stream.dump' was correctly recognized as a MPEG-ES stream
> 
> You probably hit a lucky spot.
> Here it doesn't work.

The test was flawed I think by using a "VOB" type of file - those
can be cut on 2KB boundaries without too much damage,  a VCD like
stream (such as what you have to work with) is probably corrupted
by that method of editing.

> > If that method does not work for you then, alas, reencoding I think
> > is the only way to salvage the situation.
> 
> :(

If mplayer can recognize the files then you can use '-vo yuv4mpeg'
to assist in the reencoding.   I never had great success with
mplayer getting the YUV4MPEG2 header correct though - that is why
there is a 'yuv4mpeg' utility in mjpegtools.

Something like this may work (I forget the PAL sample aspect ratio -
you could probably just leave the '-a' option out and use the value
mplayer generates):

  mplayer -vo yuv4mpeg | yuv4mpeg -w 352 -h 288 -i t -r 25:1 -a X:Y | \
 mpeg2enc -o output.m1v -f 1 ...

Good Luck!

Cheers,
Steven Schultz



---
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] Compare yuvscaler and y4mscaler

[Steven M. Schultz]

On Sun, 4 Jan 2004 [EMAIL PROTECTED] wrote:

> How do y4mscaler and yuvscaler compare when scaling a video stream for MPEG2
> encoding for SVCD, in terms of speed and image quality?

I've found y4mscaler to be better.  Depending on the scaling method
chosen (and y4mscaler offers many to choose from) the speed can be
very fast to fairly slow.   You have the choice of (and you can see
this with 'y4mscaler -S option=help') linear, quadratic, cubic, 
cubicCR, cubicB, and sinc:N (where you can choose how many taps are
used - value of N is open to debate, the higher the value the slower
the speed but higher quality - reasonable value is 4, I tend to use 8).

The other thing I use y4mscaler for is the chroma space conversion -
usually to go from 4:1:1 to 4:2:0 but I have on occasion used it to
create 4:2:2 or 4:4:4 content for testing.

The presets are quite useful and do a good job of intuiting the
correct proceedure.  For example if you send 720x480 frames into
"y4mscaler -O preset=CVD"  it will do "the right thing" by cropping
8 pixels from each side and performing a 2->1 downscale to 352x480
(and not do the simplistic but wrong 720->352 scaling).

Try it, I think you'll like it ;)

Cheers,
Steven Schultz



---
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] Remuxing split VCD-files

[Lehmeier Michael]

Steven M. Schultz wrote:

> Do you have the original source material to perform encoding from?

Alas, no.

> I tried a brief experiment on a .mpg file - I used "dd" to cut a >
section
> from the middle of the file (attempting to simulate the 'hacked apart'
> you mention).  Then I used mplayer to dump the video stream.

> dd if=foo.mpg of=bar.mpg skip=23 bs=2k count=100
> mplayer -dumpvideo bar.mpg

> the file 'stream.dump' was correctly recognized as a MPEG-ES stream
> suitable for use with mplex.

You probably hit a lucky spot.
Here it doesn't work.

> If that method does not work for you then, alas, reencoding I think
> is the only way to salvage the situation.

:(

-- 
Lehmeier Michael <[EMAIL PROTECTED]>


---
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

[Mjpeg-users] Compare yuvscaler and y4mscaler

[romildo]

Hello.

How do y4mscaler and yuvscaler compare
when scaling a video stream for MPEG2
encoding for SVCD, in terms of speed
and image quality?

Regards.

Romildo
-- 
Prof. José Romildo Malaquias[EMAIL PROTECTED]
Departamento de Computação   [EMAIL PROTECTED]
Univ. Federal de Ouro Preto  http://uber.com.br/romildo


---
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_id78&alloc_id371&op=click
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Re: [Mjpeg-users] WARN: [mplex] - a problem?

[Al Bogner]

Am Sonntag, 4. Januar 2004 16:01 schrieb Andrew Stevens:
> On Sunday 21 December 2003 20:26, Al Bogner wrote:
> > After every mplex from different sources I get this warning:
> > "++ WARN: [mplex] Discarding incomplete final frame MPEG audio
> > stream c0!"

Hi Andrew!

> > Is this a serious problem or can I ignore this?

> This is harmless it simply mplex saying that the last frame of mpeg
> audio (a very hundredths of a second of audio) was not completely
> present in the MP2 file you multiplexed.
>
> This is very common if you re-multiplex stuff 'ripped' from existing
> MPEG streams as the 'frames' don't align with the 'sectors' of an
> MPEG stream.

The mpeg-stream was created by a Win-Program, called Vegas Video.

> However: if you are encoding audio to MP2 using mp2enc or lame there
> may be a subtle bug lurking someplace. Can you let me know if this is
> the case?

No, this was not the case.

Al


---
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] WARN: [mplex] - a problem?

[Andrew Stevens]

On Sunday 21 December 2003 20:26, Al Bogner wrote:
> After every mplex from different sources I get this warning:
> "++ WARN: [mplex] Discarding incomplete final frame MPEG audio stream
> c0!"
>
> Is this a serious problem or can I ignore this?

Hi Al,

This is harmless it simply mplex saying that the last frame of mpeg audio (a 
very hundredths of a second of audio) was not completely present in the MP2 
file you multiplexed.

This is very common if you re-multiplex stuff 'ripped' from existing MPEG 
streams as the 'frames' don't align with the 'sectors' of an MPEG stream.

However: if you are encoding audio to MP2 using mp2enc or lame there may be a 
subtle bug lurking someplace. Can you let me know if this is the case?

cheers,

Andrew



---
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] problem with mplex and lpcm (Andrew Stevens please read!)

[Andrew Stevens]

Gert, Robert,

Thanks very much for the LPCM feedback.   It is *extremely* interesting to get 
real feedback on some of these fiddly issues.  Just a quick question: are the 
noise problems Robert had with a hardware player or software?  If hardware, 
this would indicate there is a 'funny' alignment constraint in DVD for LPCM 
audio sectors a bit akin the really awful things done to MP2 audio in VCD.

cheers,

Andrew



---
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

[Andrew Stevens]

> 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.

> 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.

There are really very very few MMX-only current CPUs.   Basically everything 
after K6 with MMX supports the psadbw instruction.

> Though why did mpeg2enc use variance in the first place?  Maybe it's a
> better estimator than SAD for motion compensation fit?

Its just not that simple.  It uses SAD for 'coarse' motion estimation and 
switches to variance for the final selection of the particular motion 
estimation mode.  This combination provides a good speed/quality trade-off.
Experiments with 'only variance' were unimpressive in their quality 
improvements and 'only SAD' costs quite a lot of quality for modest speed 
gain.   All the 'low hanging fruit' in the current motion estimation 
algorithm has long since been picked...

> 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.

You have to be very careful to compare like coding profiles, motion search 
radii and suchlike too.  

Its easy to be twice as fast if your simply trying half as hard to find a good 
encoding.   However, there *are* bottlenecks in mpeg2enc.   For a real speedy 
mode predictive motion estimation algorithms would need to be used.

Andrew



---
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