#27 size restrictions for MP@ML or MPEG1 exceeded! (1280x960)

closed-invalid
nobody
capture (20)
5
2004-06-10
2004-05-15
No

Hi Karl,

I'am running Debian GNU/Linux "testing" and xvidcap ver 1.1.3 (your Debian package).
I'am trying to capture my desktop with this commande line :

$xvidcap --gui no --audio no -v --file /goinfre/capture.mpeg --frames 0 --fps 25 --cap_geometry 1280x960+0+0

I got this output :

job.job_set_file(): Original dimensions: 1280 * 960
job.job_set_file(): Original dimensions: 1280 * 960
control.InitControl(): Original dimensions: 1280 * 960
Current settings:
frames per second = 25.000000
video encoding = MPEG1
file pattern = /goinfre/capture.mpeg
verbose level = 1
frames to store = 0
time to capture = 0.000000 sec
autocontinue = no
compression level = 0
quality (jpeg) = 75
input source = shm (16)
capture pointer = white
capture audio = no
- input = /dev/audio
- sample rate = 8000
- bit rate = 8
- channels = 1
animate command = animate "%s" -delay %d &
make video command= ppm2mpeg "%s" %d %d %d %d %f %d &
edit frame command= display "%s" &
help command = MANPATH=/usr/local/X11/man rxvt -e man xvidcap &
missing -66 milli secs (40 needed per frame), pic no 0
missing -79 milli secs (40 needed per frame), pic no 1
missing -51 milli secs (40 needed per frame), pic no 2
missing -40 milli secs (40 needed per frame), pic no 3
missing -39 milli secs (40 needed per frame), pic no 4
...
<CTRL-C>

When I try to play my captured movie with mplayer the video is too fast
and I get an error message from mplayer :

$mplayer /goinfre/capture.mpeg
MPlayer dev-CVS--3.3.3 (C) 2000-2004 MPlayer Team

CPU: Advanced Micro Devices Athlon MP/XP Thoroughbred 1801 MHz (Family: 6, Stepping: 0)
Detected cache-line size is 64 bytes
MMX2 supported but disabled
SSE supported but disabled
CPUflags: MMX: 1 MMX2: 0 3DNow: 1 3DNow2: 1 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX 3DNow 3DNowEx

Reading config file /etc/mplayer/mplayer.conf
Reading config file /home/cscm/.mplayer/config
Reading /home/cscm/.mplayer/codecs.conf: Can't open '/home/cscm/.mplayer/codecs.conf': No such file or directory
Reading /etc/mplayer/codecs.conf: 64 audio & 174 video codecs
Font /home/cscm/.mplayer/font/font.desc loaded successfully! (206 chars)
Failed to open /dev/rtc: Permission denied (/dev/rtc should be readable by the user.)
Using usleep() timing
Can't open input config file /home/cscm/.mplayer/input.conf: No such file or directory
Input config file /etc/mplayer/input.conf parsed: 53 binds
Opening joystick device /dev/input/js0
Can't open joystick device /dev/input/js0 : Permission denied
Can't init input joystick
Setting up LIRC support...
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support.
You will not be able to use your remote control.

Playing /goinfre/capture.mpeg.
Cache fill: 0.00% (0 bytes) AVI file format detected.
AVI_NI: No audio stream found -> no sound.
AVI: No audio stream found -> no sound.
VIDEO: [mpg1] 1280x960 24bpp 25.000 fps 10147.2 kbps (1238.7 kbyte/s)
size restrictions for MP@ML or MPEG1 exceeded! (1280x960)
VIDEO: MPEG1 1280x960 (aspect 1) 25.000 fps 10147.2 kbps (1268.4 kbyte/s)
SDL: Using driver: x11
Disabling DPMS
==========================================================================
Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
VDec: vo config request - 1280 x 960 (preferred csp: Mpeg PES)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
The selected video_out device is incompatible with this codec.
VDecoder init failed :(
Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.3.1
Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG 1 or 2 (libmpeg2))
==========================================================================
Audio: no sound
Starting playback...

I think that the important warning/error message is :
size restrictions for MP@ML or MPEG1 exceeded! (1280x960)

I can't play captured files with xine (v0.99.1) : unsupported codec

What's wrong with my setup? How can I this this bug?
Does xvidcap allow "big screen" capture?

Thanks a lot

Discussion

  • Karl H. Beckers

    Karl H. Beckers - 2004-05-19
    • status: open --> open-invalid
     
  • Karl H. Beckers

    Karl H. Beckers - 2004-05-19

    Logged In: YES
    user_id=782084

    (update: labelling Invalid [not a bug])
    The message you're seeing is not a but but a feature ...
    or so you might say ;) ... also, it is probably completely
    unrelated to the problem you're seeing.

    Look at those lines:
    missing -66 milli secs (40 needed per frame), pic no 0
    missing -79 milli secs (40 needed per frame), pic no 1
    missing -51 milli secs (40 needed per frame), pic no 2
    missing -40 milli secs (40 needed per frame), pic no 3
    missing -39 milli secs (40 needed per frame), pic no 4

    They are telling you that your machine doesn't have enough
    time to capture the frames quickly enough. Now, if you're
    going to play back that movie it will have too few frames,
    thus fill too little time, thus play back too fast (see the FAQ).

    With the enourmous capture size you've specified, you
    certainly don't want to use the -v option and you'll also
    want to have a REALLY BEEFY machine. Again, see the
    FAQ for what to do to get the most out of your capture.
    Still, I'd say 98:1 you're just asking too much of your
    machine.

    As for the other msg., that's a warning message because
    you're encoding a video that's not mpeg compliant. Well,
    pick a size that is and you won't be getting that. It shouldn't
    harm, though. Also, make sure all your players have the
    right set of codecs built in ... there's no end to the problems
    that can arise from incorrectly built/installed/configured
    video players.

    I (for one) use mplayer as my reference. If it works there
    (and is not a M$ codec) it should in principle work in other
    players, too.

    Karl.

     
  • Nowicki Christophe

    Logged In: YES
    user_id=513575

    Hi Karl,

    Sorry for the delay.

    > (update: labelling Invalid [not a bug])
    Yes, It's not really a bug

    > With the enourmous capture size you've specified, you
    > certainly don't want to use the -v option and you'll also
    > want to have a REALLY BEEFY machine. Again, see the
    > FAQ for what to do to get the most out of your capture.
    > Still, I'd say 98:1 you're just asking too much of your
    > machine.
    I do have a really beefy machine. I think so :
    Dual Athlon MP :

    $grep bogompis /proc/cpuinfo
    bogomips : 3591.37
    bogomips : 3591.37
    df -h

    RAID 0 :

    $time dd if=/dev/zero of=test bs=1M count=256
    256+0 records in
    256+0 records out
    268435456 bytes transferred in 1.604953 seconds (167254411
    bytes/sec)
    dd if=/dev/zero of=test bs=1M count=256 0.01s user 1.60s
    system 100% cpu 1.606 total

    Do you think that's it not enough?
    It was my first guest too, but look at this capture :

    https://meuh.dyndns.org/~cscm/capture.mpeg

    My CPU is not fully used (50-50% ~= 20% system speed).
    The must be a problem with my setup? don't you think so?
    Is it possible to record raw frames with xvidcap?
    Did you test xvidcap on an SMP machine?

    Thanks a lot

     
  • Nowicki Christophe

    • status: open-invalid --> closed-invalid
     
  • Karl H. Beckers

    Karl H. Beckers - 2004-06-11

    Logged In: YES
    user_id=782084

    Hi,
    I haven't done any real-life benchmarks with xvidcap and I
    mistrust
    generic performce parameters ... like MIPS or Megahertz and
    stuff.

    I don't think the storage is awfully relevant here. If you
    have a cached
    filesystem that should be alright for the amount of data
    we'll be writing
    (... this is just my gut feeling ...). You might want to try
    a filesystem using
    main memory (though I don't know how to do that with Linux
    off the
    top of my head. On Solaris it's called tmpfs)

    The CPU needs to grab each frame from the X11 memory to
    xvidcap's
    memory though X APIs. Also, this won't gain from SMP machines
    because the video capture and the encoding is a single
    thread and can't
    really be made parallel. The only thing today which gains
    from a second
    CPU is audio capture which resides in a separate thread.
    However, you
    still have a mutex lock for writing the stream. That plus
    the fact that
    audio capture is comparatively light-weight means: SMP
    doesn't help
    you.

    I've been thinking about separating capture from encoding (a
    capture
    thread gets the frames and dumps them into a pipe from where an
    encoding thread takes them as fast as it can). This might
    allow me to
    give the capture thread a higher priority and generally have
    it never
    wait. When we get there, you will get some more out of a
    second CPU.
    However, this is way in the future because I have loads of
    other things
    to do for 1.1.4 and it would require another major code
    redesign
    because right now most everything happens from the GUI main
    loop.
    That would need to be changed (which certainly is a good
    thing anyway
    but quite some work).

    What will always slow you down big-time is the -v option
    because you'll
    be writing to a tty which is always SLOW (might be somewhat
    better
    if you redirect output to a file).

    So, the only thing I can suggest is: Do your own benchmark
    starting
    with a small capture size and slowly increase that. Do smth.
    like
    "gvidcap --fps 24 --time 120" then "time mplayer
    <generatedfile>"
    the result should be similar for capture sizes 50x50 or 150x150
    (also watch the number of frames mplayer displays). Test
    with your
    full-screen capture, compare the numbers and then work up
    slowly
    from 300x300, again. ... watch the numbers. (And send them to
    me, if you do ;) )

    Again, if your bogomips are derived from 2 CPUs my guess is
    that's too slow. Your values are roughly 3 times the numbers
    on my
    300 Mhz PIII laptop. If they're from 2 CPUs, then each is
    just 1.5
    times as fast as my laptop, and then from my XP I can just say:
    You're never going to get near capturing that size.

    Karl.

     

Log in to post a comment.