I'm getting a floating point exception in mplex at the following line in
mpastrm_in.cpp:
framesize =
mpa_bitrates_kbps[version_id][layer][bit_rate_code] *
mpa_slots[layer] *1000 /
mpa_freq_table[version_id][frequency];
The sum of the audio
/* MPEG audio V2.5 */
{11025,12000,8000,0},
/* RESERVED */
{ 0, 0, 0, 0 },
/* MPEG audio V2 */
{22050,24000, 16000,0},
/* MPEG audio V1 */
{44100, 48000, 32000, 0}
};
Robert W. Fuller wrote:
I'm getting a floating point exception in mplex
gets past printing out the header info.
Robert W. Fuller wrote:
Okay so here's the deal. It's doing a division by zero. version_id is
3 and frequency is 3. That corresponds to 0 in mpa_freq_table.
Isn't Gentoo cool? I've built my entire system with the -g flag for
debuggin
Ok it's not a function of the file size.
Huh. I don't get it. Any ideas?
Robert W. Fuller wrote:
Now I'm truly baffled. This seems to be a function of the size of the
LPCM file. With this file size, I get the FP exception:
-rw-r--r-- 1 edison users 430811612 Jun 19 01:04
Note that I created
this lpcm file with sox as usual: "sox audio.wav -r 48000 -w -c 2 -s -x
audio.raw; mv audio.raw audio.lpcm." This is an extraordinary
coincidence perhaps?
Robert W. Fuller wrote:
Ok it's not a function of the file size.
Huh. I don't get it. Any ideas?
Attached is the patch that corrects this problem. Thank you for your
patience.
Robert W. Fuller wrote:
I'll be damned. That IS the problem. My LPCM data happens to look like
MPEG_AUDIO. Ok so here's the deal, the following code in interact.cpp
needs to be re-arranged so LPCM c
0 -w -c 2 -s -x
audio.raw; mv audio.raw audio.lpcm." This is an extraordinary
coincidence perhaps?
Robert W. Fuller wrote:
Ok it's not a function of the file size.
Huh. I don't get it. Any ideas?
Robert W. Fuller wrote:
Now I'm truly baffled. This seems to be a function of the
CMStream::Probe( *bs ) )
{
mjpeg_info ("File %s looks like an LPCM Audio stream.",
bs->StreamName());
bs->UndoChanges( undo );
streams.push_back( new JobStream( bs, LPCM_AUDIO) );
++audio_tracks;
I've been working with video capture and trying to get mplex to properly
incorporate an LPCM stream. When I play the resulting .mpg, I can hear
the audio with a ton of noise. Something is not quite right and I
haven't figured it out yet. Here's what I'm doing with the 48K audio:
sox 48k.w
What version of mplex are you using? I'm looking at the source code for
mjpegtools-1.6.1.92 and there is no "-W" option to mplex.
Gert Vervoort wrote:
sox 48k.wav -r 48000 -w -c 2 -s -x audio.raw
mv audio.raw audio.lpcm
mplex -f8 -L48000:2:16 video.m1v audio.lpcm -o video.mpg
OR mpl
Did you build your version of mplex out of CVS? What CVS command do you
use to fetch this? Are you just using an updated version of mplex, or
the entire mjpegtools? What works for you, Gert?
Thank you.
Robert W. Fuller wrote:
What version of mplex are you using? I'm looking at the s
I have version 1.6.1.90 of mjpegtools. There does not seem to be a -W
mplayer_hdr option. Do I need .92 ?
Gert Vervoort wrote:
sox 48k.wav -r 48000 -w -c 2 -s -x audio.raw
mv audio.raw audio.lpcm
mplex -f8 -L48000:2:16 video.m1v audio.lpcm -o video.mpg
OR mplex -f8 video.m1v audio.
What version of mplex are you using? I'm looking at the source code for
mjpegtools-1.6.1.92 and there is no "-W" option to mplex.
Gert Vervoort wrote:
sox 48k.wav -r 48000 -w -c 2 -s -x audio.raw
mv audio.raw audio.lpcm
mplex -f8 -L48000:2:16 video.m1v audio.lpcm -o video.mpg
OR mpl
Gert,
The "-W mplayer_hdr" option to the CVS version of mplex solved my noise
with LPCM problem. Thank you!
Regards,
Rob
Gert Vervoort wrote:
Robert W. Fuller wrote:
Did you build your version of mplex out of CVS? What CVS command do
you use to fetch this? Are you just using
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 w
--- Begin Message ---
I cannot seem to import yuv4mpeg files. I get the error message "Start
of frame is not FRAME" from transcode. What does this mean?
I'm using streamer to create the yuv4mpeg files. They work fine with
mjpegtools 1.6.1.92. I can play them with yuvplay and use them with
Please disregard this message. The problem was solved. Transcode was
patched.
I accidentally sent this from an unsubscribed address, and the moderator
just now let it through. That will teach me to use different e-mail
addresses for related lists!
Robert W. Fuller wrote
--- Begin Message ---
When you export from a quicktime file to yuv4mpeg, transcode sets the
frame order to "progressive/none." This does not work well with
programs like "yuvkineco" which will not perform de-interlacing unless
the frame order is "unknown". I think it would be better for trans
eader format?
Regards,
Rob
Steven M. Schultz wrote:
On Wed, 7 Jan 2004, Robert W. Fuller wrote:
When you export from a quicktime file to yuv4mpeg, transcode sets the
frame order to "progressive/none." This does not work well with
programs like "yuvkineco" which will not perfo
Anybody know of a good simple binary file editor for Linux that can
handle 30 GB files without a problem? If so, I can simply edit the
YUV4MPEG header to suit me. By the way, the yuv4mpeg man page is quite
good.
Robert W. Fuller wrote:
This should have gone to the list
I was looking at the source code, and I don't see any difference. Also,
when I use cmp -l on the output, it appears to be the same! I have
version 1.6.1.90.
Maybe I haven't had enough sleep?
---
This SF.net email is sponsored by: Perforce
I can see that using sed would be quite simple. However, I don't want
to wait for a 30 GB file to be re-written. Looking at the man page, I
see there is an "--in-place" option for sed. I guess I better delve
into sed some more. I wonder if I can tell it to stop after the first
"\n" to avoid
Very clever.
I found something like this works fine:
sed -e "1s/Ip A0/I\? A0/"
Rather than using a global edit, I told it only to change the first line
("1s"). According to my tests, sed seems to respect line numbers for
edits. Limiting sed to the first line seems safer than doing a global
e
I asked this question on the video4linux list and I'm not sure that
everybody answering the question understood the question as well as the
mpeg2enc tool.
My understanding is that in the US NTSC is broadcast bottom field
first. Thus, the TV will display the bottom field, then the top field.
Very clever.
I found something like this works fine:
sed -e "1s/Ip A0/I\? A0/"
Rather than using a global edit, I told it only to change the first line
("1s"). According to my tests, sed seems to respect line numbers for
edits. Limiting sed to the first line seems safer than doing a glob
25 matches
Mail list logo
