[Mjpeg-users] average higher than max
mpeg2enc -v 0 -I 1 -f 8 -b 9500 -F 4 -n n -a 2 -o "v1.m2v" -q 6 -R 0 -c -g 1 -4 2 -2 1 -K hi-res Source is DV. If i encode like 1200 frames or so and multiplex the result, all is fine. But if i encode only like the first 200 frames, mplex believes the average bitrate is higher than the max: INFO: [mplex] Average bit-rate : 9497200 bits/sec INFO: [mplex] Peak bit-rate: 9019200 bits/sec If i replace hi-res with something more normal, like tmpgenc (or that neat half-hi-res half-tmpgenc matrix) then i don't get the abnormal report from mplex. If i increase -q to 8, then i don't get the abnormal "average higher than max" situation anymore. Does that mean that hi-res requires a very high bandwidth, so i have to reduce the pressure by increasing -q ? Why do i get the problem when encoding only the beginning, but not when encoding the whole DV/AVI file? By the looks of it, the high-motion scenes are quite a while after the start. Is it likely that i'll run into trouble with a "average higher than max" DVD played on set-top boxes? -- Florin Andrei http://florin.myip.org/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] Audio is out of sync.
Hello,
I am trying to convert a avi stream captured by dvgrab to mpeg format, But when I play
final
output
using mplayer, audio is not in sync. I am using following commands,
#!/bin/bash
in_file=$1
out_file=$1
lav2yuv ${in_file}.avi 2>err | mpeg2enc -v0 -f 8 -o ${out_file}.m2v
lav2wav ${in_file}.avi >l
mp2enc -v0 -b 224 -r 44100 -o ${out_file}.mp2 http://antispam.yahoo.com/whatsnewfree
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Update on: mpeg2enc current cvs segfault ?
On Mon, 2003-12-01 at 00:06, Steven M. Schultz wrote: > As a temporary measure you can try editing the compat function > posix_memalign to return an aligned address. NOTE: this will result > in a pointer that can NOT be passed to 'free()' - which makes this an > unacceptable solution in the long term (but as an experiment it would > be worth trying). Is this function called often? If not, it can be easily worked around by creating a linked list of allocated pointers from posix_memalign(). Then, return (ret + 3) &~ 3. In posix_memalign_free, check the given pointer against each value in the list (listval + 3) &~ 3 and free listval. If we don't call this too often, this will have no measurable performance effects. Ronald -- Ronald Bultje <[EMAIL PROTECTED]> Linux Video/Multimedia developer --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Update on: mpeg2enc current cvs segfault ?
On Mon, 1 Dec 2003, Ronald Bultje wrote: > On Mon, 2003-12-01 at 00:06, Steven M. Schultz wrote: > > As a temporary measure you can try editing the compat function > > posix_memalign to return an aligned address. NOTE: this will result > > Is this function called often? If not, it can be easily worked around by > creating a linked list of allocated pointers from posix_memalign(). > Then, return (ret + 3) &~ 3. In posix_memalign_free, check the given > pointer against each value in the list (listval + 3) &~ 3 and free > Well, it'd be either 16 or 64 byte alignment but the same thing could be done of course. That is what I suggested Nicolas try as an experiment - adjust the value returned from the compatibility posix_memalign() function to see if the problem goes away. That would be the conclusive proof that the alignment is indeed the cause of the problem. > If we don't call this too often, this will have no measurable > performance effects. It's not the performance issue at all - the function isn't called often enough to make a difference. The goal was to allocate memory that could be released by calls to the standard free() function and not have the calling program remember which buffers were allocated by posix_memalign() and which were allocated by malloc() The encoder shared library will be used outside of mpeg2enc so I do not think it is reasonable to insist that callers of the functions in libmpeg2encpp.so have to track which buffers need posix_memalign_free() and which need free(). At the moment the buffers are not free'd so it does not matter if the return value from posix_memalign() is suitable for free(). That will not always be true though so a longer term solution needs to be found. Cheers, Steven Schultz --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Update on: mpeg2enc current cvs segfault ?
On Mon, 1 Dec 2003, Ronald Bultje wrote:
> On Mon, 2003-12-01 at 00:06, Steven M. Schultz wrote:
> > As a temporary measure you can try editing the compat function
> > posix_memalign to return an aligned address. NOTE: this will result
> > in a pointer that can NOT be passed to 'free()' - which makes this an
> > unacceptable solution in the long term (but as an experiment it would
> > be worth trying).
>
> Is this function called often? If not, it can be easily worked around by
> creating a linked list of allocated pointers from posix_memalign().
> Then, return (ret + 3) &~ 3. In posix_memalign_free, check the given
> pointer against each value in the list (listval + 3) &~ 3 and free
> listval.
How about this? It will malloc and free the aligned pointers in constant
time. It needs only a trivia change to make it work on 64 bit systems.
/* This assumes that pointers must be padded to 32-bit alignment. */
/* align = power of 2 to align on, e.g 0= 8-bits, 1 = 16 bits, 2 = 32 bits */
void *align_malloc(size_t size, int align)
{
void *p; uintptr_t l;
if(align<2) align=2; /* pad to at least 32 bits for the pointer */
/* allocate a bit of extra space for a pointer and the alignment */
p = malloc(size+(1
Re: [Mjpeg-users] Update on: mpeg2enc current cvs segfault ?
Hi Nicolas, Back from a Weekend at my Parter's parents... ;-) Although I normall develop on a Debian 'unstable' machine my house server is a pure 'woody' box. How are you building? I'd like to replicate the issues you're having with mplex and/or mpeg2enc. However, I've found the default automake/automake setup seems to screw up... so it is hard to figure out exactly what it is you're building! cheers, Andrew --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Update on: mpeg2enc current cvs segfault ?
On Mon, Dec 01, 2003 at 08:37:14AM -0800, Steven M. Schultz wrote: > > On Mon, 1 Dec 2003, Ronald Bultje wrote: > > > On Mon, 2003-12-01 at 00:06, Steven M. Schultz wrote: > > > As a temporary measure you can try editing the compat function > > > posix_memalign to return an aligned address. NOTE: this will result > > > > Is this function called often? If not, it can be easily worked around by > > creating a linked list of allocated pointers from posix_memalign(). > > Then, return (ret + 3) &~ 3. In posix_memalign_free, check the given > > pointer against each value in the list (listval + 3) &~ 3 and free > > > Well, it'd be either 16 or 64 byte alignment but the same thing > could be done of course. > > That is what I suggested Nicolas try as an experiment - adjust the > value returned from the compatibility posix_memalign() function to > see if the problem goes away. That would be the conclusive proof > that the alignment is indeed the cause of the problem. I just tried an experiment. I added a printf just after the assignment to the piqf pointer in quant_non_intra_sse to print out the value of the address being passed into the line: mulps_m2r( *(mmx_t*)&piqf[0], xmm2 ); where it is segfaulting for me. The value of &piqf[0] for my setup was 0x40eb7008, which is 8 byte aligned, but not 16 byte aligned. So, then I just tried hardwiring the mulps_m2r line to say: mulps_m2r( *(mmx_t*)0x40eb7010, xmm2 ); where 0x40eb7010 is 16 byte aligned. Yes, I realize this will produce garbage output from mpeg2enc, I just wanted to see if changing the alignment of the pointer fixed it. Well, when I recompiled mpeg2enc, with the hardwired 0x40eb7010 pointer value, it ran like charm, running through all the frames in the test yuv stream I sent Andrew about a month ago so he could test and see if it was input data causing the trouble. So it looks like the address for the piqf pointer needs to be 16 byte aligned, and at least with glibc 2.1.2 it's only getting 8 byte alignment from glibc. PS - I tested the hardwired setup with 0x40eb7008, and it segfaulted with that value hardwired in. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] average higher than max
Hi, This is a known small Bug that relates to the way the peak bit-rate is calculated. It would be a pain to fix and the peak rate is only calculated for this 'user information' message anyway so it has been around for a while because its harmless :-( >INFO: [mplex] Average bit-rate : 9497200 bits/sec >INFO: [mplex] Peak bit-rate: 9019200 bits/sec > > Why do i get the problem when encoding only the beginning, but not when > encoding the whole DV/AVI file? By the looks of it, the high-motion > scenes are quite a while after the start. > > Is it likely that i'll run into trouble with a "average higher than max" > DVD played on set-top boxes? Basically it is 'peak' number thats wrong (it tends to underestimate a little). Andrew --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Update on: mpeg2enc current cvs segfault ?
On Mon, 1 Dec 2003, Richard Ellis wrote: > I just tried an experiment. I added a printf just after the > assignment to the piqf pointer in quant_non_intra_sse to print out > mulps_m2r( *(mmx_t*)&piqf[0], xmm2 ); > > The value of &piqf[0] for my setup was 0x40eb7008, which is 8 byte > aligned, but not 16 byte aligned. So, then I just tried hardwiring > the mulps_m2r line to say: > > mulps_m2r( *(mmx_t*)0x40eb7010, xmm2 ); > where 0x40eb7010 is 16 byte aligned. Yes, I realize this will > produce garbage output from mpeg2enc, I just wanted to see if... This does confirm it though - P4 SSE instructions require 16 byte alignment and while older glibc versions have posix_memalign there is a bug that causes it to not behave as expected. > So it looks like the address for the piqf pointer needs to be 16 byte > aligned, and at least with glibc 2.1.2 it's only getting 8 byte > alignment from glibc. Hmmm, &piqf needs to be aligned? The data accessed by dereference (*piqf) needs to be aligned but the pointer itself? I see that piqf is initialized with 'i_quant_matf' but I have not traced the logic beyond that point. Perhaps the problem isn't only in glibc, but the compiler and how it is aligning data tables? Steven Schultz --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] average higher than max
On Mon, 2003-12-01 at 10:38, Andrew Stevens wrote: > >INFO: [mplex] Average bit-rate : 9497200 bits/sec > >INFO: [mplex] Peak bit-rate: 9019200 bits/sec > > > Basically it is 'peak' number thats wrong (it tends to underestimate a > little). But other than that, and if the peak is below the max value specified by the DVD standards, it should be ok on standalone DVD players, right? -- Florin Andrei http://florin.myip.org/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] average higher than max
Hallo > > >INFO: [mplex] Average bit-rate : 9497200 bits/sec > > >INFO: [mplex] Peak bit-rate: 9019200 bits/sec > > > > > > Basically it is 'peak' number thats wrong (it tends to underestimate a > > little). > > But other than that, and if the peak is below the max value specified by > the DVD standards, it should be ok on standalone DVD players, right? Right. 9.4Mbit is rather high. auf hoffentlich bald, Berni the Chaos of Woodquarter Email: [EMAIL PROTECTED] www: http://www.lysator.liu.se/~gz/bernhard --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
