Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Two Questions

Help
2006-09-14
2013-04-24
  • hi, xvidcap is great, thanks very much for a great tool! I have a few unanswered questions, these are the start! :)

    1. Can I use a newer (im building from the trunk) or my own version of ffmpeg codecs?

    2. Can I output to STDOUT?

    Thanks
    Nick

     
    • Nick
      Nick
      2006-09-15

      Actually from the trunk i don't think (1) is neccessary however, what i'd like to do is create a realtime stream from xvidcap to the network.

      With ffmpeg cmd line tool it's possible, is it possible with xvidcap directly?

      Thanks

       
    • 1) not really (theoretically yes, but practically prolly no)
      2) yes "xvidcap --format avi --codec mpeg4 --aucodec mp3 --file -"

      You need to explicitly specify your settings for (2). Also (this is dependant on libavcodec) not all formats lend themselves to piping equally well. And I've personally not been able to use the output as input to ffserver (though I haven't tried VERY hard).

       
    • Nick
      Nick
      2006-09-18

      I gave up myself with ffserver, it's too badly documented for me to get anywhere fast. I'm trying to do a proof of concept for live streaming (must be mpeg2 codec) but getting a little stuck at the moment. I know it can be done, it's just working out just how atm. :)

      I've gone back to something i know works well for streaming vlc. The command i'm using is:

      xvidcap --mf --fps 25 --cap_geometry 640x480+0+0 --quality 75 --codec mpeg2 --format mpeg2 --audio yes --audio_channels 2 --aucodec mp2 --gui no --file - | vlc - --sout '#std{access=mmsh,mux=asfh,dst=:8080}'

      Which seems to display at least the first frame correctly but doesn't update, any idea why?

       
    • Hmm,
      don't really know streaming well, but when trying ffserver, I've learned that formats are treated differently by clients when streamed. AVI, so I've heard, would be transferred to the client completely before it displays it. The MPEG2 format might be problematic, too. It is MPEG2 PS Format (a.k.a. VOB File) after all. The only genuine streaming format in xvidcap as a good start might be ASF.
      But as I said, this is just guessing a direction and I'm not saying this guess deserves the label "educated".

      Karl.

       
      • aah,
        btw. can you test piping xvidcap output to a file, then stopping the capture and later "cat" the file to vlc? If that works, xvidcap's output cannot be completely wrong.

        Karl.

         
    • Nick
      Nick
      2006-09-19

      hi thanks again for your help again. If i record in mpeg2 ps format and playout stream seperately using vlc (vlc test.mpg --sout '#std{access=mmsh,mux=ts,dst=:8080}' ref:http://www.videolan.org/doc/streaming-howto/en/ch03.html) I can view the stream correctly (although it plays back a little fast but i'm sure thats another issue i can fix).
      So i think it must be something to do with the pipe'ing of the data from xvidcap to vlc.

      I get the following with vlc in vebose mode:

      [00000378] packetizer_mpegvideo packetizer debug: size 640x480 fps=25.000
      [00000350] mpeg_audio packetizer debug: MPGA channels:2 samplerate:22050 bitrate:32
      [00000296] main stream output debug: adding a new input
      [00000303] main private debug: adding a new input
      [00000303] mux_asf private debug: adding input
      [00000303] mux_asf private debug: adding mp3 header
      [00000296] main stream output debug: adding a new input
      [00000303] main private debug: adding a new input
      [00000303] mux_asf private debug: adding input
      [00000303] main private warning: late buffer for mux input (1338535)
      [00000303] main private warning: late buffer for mux input (1068509)

      If i run xvidcap on with vebose i see:

      missing -108 milli secs (40 needed per frame), pic no 0
      missing -108 milli secs (40 needed per frame), pic no 1
      missing -97 milli secs (40 needed per frame), pic no 2
      missing -96 milli secs (40 needed per frame), pic no 3
      missing -97 milli secs (40 needed per frame), pic no 4
      missing -96 milli secs (40 needed per frame), pic no 5
      missing -96 milli secs (40 needed per frame), pic no 6

      what does this mean?
      Thanks
      Nick

       
    • Nick
      Nick
      2006-09-19

      As well as getting vlc to read the file in i tried 'cat'ing the recorded file to vlc and that worked fine too.

      I have now just tried

      xvidcap -vvv --mf --fps 25 --cap_geometry 640x480+0+0 --quality 75 --codec mpeg2 --format mpeg2 --audio yes --audio_channels 2 --aucodec mp2 --gui no --file - | cat > test-cat.mpg

      to see if it was the stdout of xvidcap getting corrupted somehow. but playing that back as a stream seems fine too, though i did get some messages

      [00000302] main http server debug: Connection from 10.170.99.30
      [00000314] ps demuxer warning: garbage at input, trying to resync...
      [00000314] ps demuxer warning: found sync code
      [00000314] ps demuxer warning: garbage at input, trying to resync...
      [00000314] ps demuxer warning: found sync code
      [00000314] ps demuxer warning: garbage at input, trying to resync...
      [00000314] ps demuxer warning: found sync code
      [00000294] main input debug: EOF reached
      [00000294] main input debug: closing input
      [00000350] main packetizer debug: removing module "mpeg_audio"

      Is there any tools you know of that will analyse an mpeg2 file?

       
    • actually, what I meant was the other way around: recording to file, then cat'ing to vlc. But you're right the better test is recording to pipe and cat'ing to file, then cat'ing the file to vlc.

      the output you've seen with --verbose tells you about frame drop. When the next frame is to be scheduled for capture you're missing # ms, like you captured frame 1, the next one is to be scheduled, but encoding frame 1 took longer than the 40 ms time for a single frame (e.g. 108 ms longer). Hence you've missed around 2 frames for this go. To rule out this as a potential problem I'd pick a very small capture size (like 100x100) which should speed up things.

      The bit "late buffer for mux input" might point at such a cause ... like: the data might not come in fast enough for it to be streamed. Of course, there might be ways of treating this gracefully, but I don't know how well vlc behaves here.

      If the problem persists with a very small resolution, and you can still first pipe to file, then pipe the file to vlc, I'd try to contact the vlc developers. And if you do, I'd appreciate being CC'ed as that might end in a long overdue FAQ entry.

      Karl.

       
      • Also,
        doesn't the link you posted say:
        "asfh: this is a special version of the ASF muxer, that should be used for MMSH streaming. MMSH is the only supported output method. Supported codecs are the same as for ASF."
        ... and you are NOT using asf format or msmpegv3 codec?!?

         
    • on my dapper box I can't seem to get this to work:
      xvidcap --mf --fps 10 --cap_geometry 100x100+0+0 --quality 75 --codec ms_div3 --format asf --audio no --gui no --file - | vlc - --sout '#std{access=mmsh,mux=asfh,dst=:8080}'
      VLC media player 0.8.4 Janus
      [00000274] main private: creating httpd
      [00000274] access_output_http private error: failed to create avahi client: Daemon not running
      [00000277] main private error: url still registered:/
      [00000276] main http daemon: httpd doesn't reference any host, deleting
      [00000272] stream_out_standard private error: no suitable sout access module for `mmsh/asfh://:8080'
      [00000271] main stream output error: stream chained failed for `std{access=mmsh,mux=asfh,dst=:8080}'
      [00000270] main input error: cannot start stream output instance, aborting
      [00000261] main playlist: nothing to play

      same with your command line :(
      what vlc version are you on, 0.8.4?

       
    • Nick
      Nick
      2006-09-19

      thanks, been busy with a few other things this afternoon. I'm using videolan-client-0.8.5-1.fc5.
      I run on a pretty powerful box, it's dual xeon 3ghz with 4GB ram (i know it shouldn't need it, but it was lying around so i grabbed it :)

      Also when i made the attempts earlier (after post #4) I had changed the sout line of vlc to use the ts mux, the first post was not 100% correctly explaining what i actually needed -

      '#std{access=mmsh,mux=ts,dst=:8080}'

      I've just attempted to use http transport instead with a lower res and it works, although delayed somewhat -

      xvidcap -v --mf --fps 25 --cap_geometry 300x300+0+0 --quality 75 --codec mpeg2 --format mpeg2 --audio yes --audio_channels 2 --aucodec mp2 --gui no --file - | vlc -vvv - --sout '#std{access=http,mux=ts,dst=:8080}'

      then using http://<server>:8080 in vlc client. So encoding speed seems a little low as if i try with a higher resolution 640x480 the client stops recieving after a short time and i see

      [00000303] main private warning: late buffer for mux input (2819309)
      [00000303] main private warning: late buffer for mux input (2767077)
      [00000313] ps demuxer warning: garbage at input, trying to resync...
      [00000313] ps demuxer warning: found sync code
      [00000303] main private warning: late buffer for mux input (3007441)
      [00000303] main private warning: late buffer for mux input (2967904)

      in the vlc verbose output. I'm getting hundreds of lines of the "late buffer for mux input" as well. Will try tomorrow with a fresh head!

      On a bit of a tangent, I also wondered if you'd thought about adding a cmd line switch that allowed specifying the window ID as you can do with "import" utility of imagemagick (ref: http://www.linuxdevcenter.com/pub/a/linux/2004/03/04/screen_capture_movies.html\)?

      Cheers

       
      • about the input selection by window id ... haven't yet seen that this would be a big plus if used just for positioning the input frame. If this is used for following the window around if you move it, it might be more interesting altogether. Feel free to add an RFE.

        The other thing around performance is that encoding IS heavy. I cannot do 800x600 on my 3Ghz P4 HT enabled at 10fps without frame loss. On my Athlon XP 2100 (with around 1.8 Ghz, I think) I can. While xvidcap is multithreaded, now, the most expensive part, of course, (video encoding) is in a single thread. I should enable -pthreads in ffmpeg again ... disabled it for testing the mutex_assertion bug.

        I guess I'll raise a poll for capture results on various platforms.

         
    • actually I was wrong: I HAVE pthreads enabled in the included ffmpeg

       
    • ... and I cannot see it actually USE multiple CPUs.

      When my P4 system gets frame drop it is always running at 50% idle time flat (which is 46% user time and 4% sytem time). This is very probably saying the one of the CPUs (note that this is a single CPU and single core with HyperThreading, though) is running at max load.

      Actually, since I'm passing --enable-pthreads to ffmpeg's configure the costly motion estimation bit should be multi-threaded and therefore able to use multiple CPUs in parallel. I'd ask on the ffmpeg-devel list, but they'll just tell me to read the source, again ;) ... which I might end up actually doing.

      The fun thing is: Trying to optimize libavcodec with --tune=pentium4 actually yields worse results for me than leaving it alone:

      pentium4:
              500x500 1000 frames @ 10 fps
              : fps 7.33 1001 frames in 136.48 seconds
              : fps 7.35 1001 frames in 136.19 seconds

      x86 generic:
              500x500 1000 frames @ 10 fps
              : fps 7.52 1001 frames in 133.16 seconds
              : fps 7.63 1001 frames in 131.16 seconds

       
      • ahh, and I was meaning to say that I'm planning to do some profiling on xvidcap eventually. But since I'll have to learn how to do that first, it might slip the 1.1.4 release. Will try to manager between rc2 and final, though.