[Ffmpeg-devel] Re: ffmpeg-devel Digest, Vol 18, Issue 91

Rahul Ray rahul.ray
Thu Sep 14 01:18:51 CEST 2006


I have a quick question - more from a user perspective.

I have an analog camera that is connected to box with a IP address.
I can address that camera ( video) by: rstp://12.12.12.123/cam=1/

The video is mpeg4. I would like to work on live streaming to analyze
the video ( object detection etc.).

How can I do it using ffmpeg ?

Any help would be greatly appreciated.

-best,
Rahul

On 9/13/06, ffmpeg-devel-request at mplayerhq.hu
<ffmpeg-devel-request at mplayerhq.hu> wrote:
> Send ffmpeg-devel mailing list submissions to
>         ffmpeg-devel at mplayerhq.hu
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> or, via email, send a message with subject or body 'help' to
>         ffmpeg-devel-request at mplayerhq.hu
>
> You can reach the person managing the list at
>         ffmpeg-devel-owner at mplayerhq.hu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ffmpeg-devel digest..."
>
>
> Today's Topics:
>
>    1. Re: [PATCH] enable libswscale (V?ctor Paesa)
>    2. Re: [PATCH] fix mpegaudiodec on ARM and benchmark (Diego Biurrun)
>    3. Re: upsampling of subsampled video data (Michael Niedermayer)
>    4. Re: [PATCH] enable libswscale (Michael Niedermayer)
>    5. Re: Re: V4L grab.c patch for Grayscale (Michael Niedermayer)
>    6. Re: [PATCH] Cygwin vhook, always static avformat (Diego Biurrun)
>    7. Re: upsampling of subsampled video data (Baptiste Coudurier)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 13 Sep 2006 23:06:55 +0200 (CEST)
> From: V?ctor Paesa <wzrlpy at arsystel.com>
> Subject: Re: [Ffmpeg-devel] [PATCH] enable libswscale
> To: "FFMpeg development discussions and patches"
>         <ffmpeg-devel at mplayerhq.hu>
> Message-ID:
>         <1498.204.104.55.241.1158181615.squirrel at mail.arsystel.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> Here is attached my patch to port imlib2 vhook to swscaler.
>
> I also attach a simple test case.
>
> While testing the port of imlib2 vhook to swscale, I noticed that blue is
> swapped for red in PIX_FMT_RGBA32 if using swscaler.
>
> My platform is x86, could it be a side effect of little-endianess?
>
> I had applied the "convert-swscale-alternative-swsonly.diff" patch (Aug,
> 31st), maybe this issue is solved in the more recent "convert-swscale.diff"
> (Sep, 11th) but I was not able to apply that patch to the FFmpeg source tree,
> "convert-swscale.diff" looks intended for MPlayer.
>
> Regards,
> V?ctor Paesa
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: ffmpeg.swscale.imlib2-vhook.1.diff
> Type: application/octet-stream
> Size: 3425 bytes
> Desc: not available
> Url : http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060913/1e40f94f/ffmpeg.swscale.imlib2-vhook.1-0001.obj
> -------------- next part --------------
> Version used as reference, in /usr/local/bin
> FFmpeg version SVN-r6027, Copyright (c) 2000-2004 Fabrice Bellard
>   configuration:  --enable-mp3lame --enable-a52 --disable-static --enable-shared --enable-pthreads --enable-avisynth --enable-gpl
>   libavutil version: 49.0.0
>   libavcodec version: 51.11.0
>   libavformat version: 50.5.0
>   built on Aug 20 2006 01:37:22, gcc: 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
>
>
> Version being tested, in ../ (tests are run were vhooks are built)
> FFmpeg version SVN-r6232, Copyright (c) 2000-2004 Fabrice Bellard
>   configuration:  --enable-mp3lame --enable-a52 --disable-static --enable-shared --enable-pthreads --enable-swscaler --enable-avisynth --enable-gpl
>   libavutil version: 49.0.0
>   libavcodec version: 51.14.0
>   libavformat version: 50.5.0
>   built on Sep 13 2006 21:58:18, gcc: 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
>
> Patches applied (just needed in Cygwin, due to not allowed undefined symbols):
> ffmpeg.cygwin.vhook.11.patch
> ffmpeg.swscale.makefile-vhook.1.patch
> ffmpeg.swscale.configure.2.patch
>
> Patches applied (for any platform):
> convert-swscale-alternative-swsonly.diff
>
> # You'll need pamgradient, pnmtopng (part of the Netpbm tools) to run test.
> pamgradient red green blue yellow 720 576 | pnmtopng  > input.png
>
> # Run command with imlib2 unpatched and patched.
> export FONTPATH=/usr/share/imlib2/data/fonts/
> /usr/local/bin/ffmpeg -f image2 -i input.png -vhook '/usr/local/bin/vhook/imlib2.dll -c blue -F notepad/72 -t Hello -y 200' -f image2  output_org.ppm
> ../ffmpeg -f image2 -i input.png -vhook './imlib2.dll -c blue -F notepad/72 -t Hello -y 200' -f image2  output.ppm
>
>         # Test results: foreground text appears in blue, but background Red and Blue channels are swapped when using swscaler.
>
>
>
> Hi,
>
> While testing the port of imlib2 vhook to swscale, I noticed that blue is swapped for red
> in PIX_FMT_RGBA32 if using swscaler.
>
> My platform is x86, could it be a side effect of little-endianess?
>
> I had applied the "convert-swscale-alternative-swsonly.diff" patch (Aug, 31st), maybe this issue is
> solved in the more recent "convert-swscale.diff" (Sep, 11th) but I was not able to apply that patch
> to the FFmpeg source tree, "convert-swscale.diff" looks intended for MPlayer.
>
> Regards,
> V?ctor
>
> ------------------------------
>
> Message: 2
> Date: Wed, 13 Sep 2006 23:44:01 +0200
> From: Diego Biurrun <diego at biurrun.de>
> Subject: Re: [Ffmpeg-devel] [PATCH] fix mpegaudiodec on ARM and
>         benchmark
> To: FFMpeg development discussions and patches
>         <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20060913214401.GA2420 at biurrun.de>
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Sep 13, 2006 at 10:38:40PM +0300, Siarhei Siamashka wrote:
> > On Wednesday 13 September 2006 12:27, Diego Biurrun wrote:
> >
> > > On Wed, Sep 13, 2006 at 10:52:07AM +0200, Guillaume POIRIER wrote:
> > > > On 9/12/06, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:
> > > > >Also it is not quite related to ffmpeg, but mplayer can't be
> > > > >configured to use HAVE_IWMMXT, so it does not use full optimizations
> > > > >on xscale cpu such as yours, maybe it is a good idea to fix it?
> > > >
> > > > Yes, sure. I'm quite confident that all it takes it to add a configure
> > > > check.
> > >
> > > Yes, patch welcome.
> >
> > In the mean time here is a patch for ffmpeg configure script adding
> > armv5te instructions support detection (pretty much a copy-paste from
> > iwmmxt detection). Also changed mpegaudiodec.c to use this new
> > HAVE_ARMV5TE define.
> >
> > --- configure (revision 6244)
> > +++ configure (working copy)
> > @@ -1526,6 +1540,9 @@
> >      echo "3DNow! Builtins  $mm3dnow"
> >  fi
> >  if test $cpu = "armv4l"; then
> > +    echo "ARMv5TE enabled  $armv5te"
> > +fi
> > +if test $cpu = "armv4l"; then
> >      echo "IWMMXT enabled   $iwmmxt"
> >  fi
>
> No need for the extra if check here, it's identical to the one above.
>
> Patch applied with that small modification.
>
> Diego
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 13 Sep 2006 23:54:50 +0200
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] upsampling of subsampled video data
> To: FFMpeg development discussions and patches
>         <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20060913215449.GD7106 at MichaelsNB>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> On Wed, Sep 13, 2006 at 03:42:54PM -0400, Dan Maas wrote:
> > > No, the banding is an artifact of the bad colorspace conversion. If
> > > you treat the YUV data as the original picture then the codecs
> > > reproduce it quite well. The mistake is treating the RGB as the source
> > > (unless it's genuine RGB-10 or 12...)
> >
> > I've done experiments with non-dithered 8-bit YUV converted directly
> > from floating-point RGB. The steps between successive 8-bit luma
> > levels are still big enough to be visible on a good TV monitor (output
> > via analog component from an Aja uncompressed video I/O
> > unit). Dithering is necessary when using 8-bit YUV if you want to get
> > perfectly smooth gradients. (10-bit YUV is OK without dithering).
> >
> > Note that I'm talking about digitally generated images with perfectly
> > clean black-to-white gradients. On noisy images, like anything
> > captured with a real video camera, the problem is less apparent.
> >
> > The codec problem is that, to a lossy codec operating in frequency
> > space, dithering looks like a very low-energy signal at very high
> > frequency. So it's usually the first thing that is dropped to reduce
> > the bitrate. With most DV and MPEG-2 encoders my experience is that
> > carefully dithered, subtle gradients just end up as 8x8 blocks of
> > solid color, with all of the high-frequency content knocked out.
>
> which isnt wrong or is it? the high freq noise after all isnt correct
> and its pretty hard to represent low energy coefficients if the lowest
> (quantized) values you can store are larger, the problem rather is that
> either the dc coefficient has to be quantized to coarsly or that even if
> its quantized finely enough the idct will not do any dithering and will
> thus output a constant 8bit colored block, there are 3 ways to fix that
> 1. design or choose a video codec which works with more then 8bit per
> sample
> 2. design a video codec which does dithering in the idct and loop filter
> (dunno if that would have any sideeffects)
> 3. use a good postprocessing filter, mplayer -vf spp should remove all
> banding artifacts, if not change its options a little or try -vf uspp
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 14 Sep 2006 00:02:42 +0200
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] [PATCH] enable libswscale
> To: FFMpeg development discussions and patches
>         <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20060913220242.GE7106 at MichaelsNB>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi
>
> On Wed, Sep 13, 2006 at 11:06:55PM +0200, V?ctor Paesa wrote:
> > Hi,
> >
> > Here is attached my patch to port imlib2 vhook to swscaler.
> >
> > I also attach a simple test case.
>
> vhook patches look ok
>
> btw, you seem to be interrested in video filtering stuff, maybe you would
> want to add mplayer/libmpcodecs support to ffmpeg? :)
> yes iam searching for a volunteer to do that ...
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 14 Sep 2006 00:06:35 +0200
> From: Michael Niedermayer <michaelni at gmx.at>
> Subject: Re: [Ffmpeg-devel] Re: V4L grab.c patch for Grayscale
> To: FFMpeg development discussions and patches
>         <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20060913220635.GF7106 at MichaelsNB>
> Content-Type: text/plain; charset=us-ascii
>
> Hi
>
> On Wed, Sep 13, 2006 at 04:13:06PM -0400, Michael Benjamin wrote:
> > Is there more I should do for this patch?
>
> no patch looks ok
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In the past you could go to a library and read, borrow or copy any book
> Today you'd get arrested for mere telling someone where the library is
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 14 Sep 2006 00:08:31 +0200
> From: Diego Biurrun <diego at biurrun.de>
> Subject: Re: [Ffmpeg-devel] [PATCH] Cygwin vhook, always static
>         avformat
> To: FFMpeg development discussions and patches
>         <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <20060913220831.GB2420 at biurrun.de>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Tue, Sep 12, 2006 at 11:08:51PM +0200, V?ctor Paesa wrote:
> > > On Mon, Sep 11, 2006 at 12:42:21AM +0200, V?ctor Paesa wrote:
> > >> > On Sat, Sep 09, 2006 at 03:52:09PM +0100, M?ns Rullg?rd wrote:
> > >> >> V?ctor Paesa <wzrlpy at arsystel.com> writes:
> > >> >> >
> > >> >> > --- ffmpeg-old/configure      2006-09-01 17:44:56.000000000 +0200
> > >> >> > +++ ffmpeg/configure  2006-09-09 15:59:44.890625000 +0200
> > >> >> @@ -874,6 +880,14 @@
> > >> >>
> > >> >> +if test "$targetos" = "CYGWIN" ; then
> > >> >> +    if test "$lstatic" = "yes" ; then
> > >> >> +        vhook="no"
> > >> >> +    fi
> > >> >> +fi
> > >> >
> > >> > This should with the rest of the cygwin specific bits.
> > >> >
> > >> I would need a hint on how to do that, I wrote this chunk after the
> > >> configure options are parsed so that $lstatic is set.
> > >> Should I parse the --enable/disable-static options?
> > >
> > > Look around line 1360, there are some vhook checks anyway.  Integrating
> > > it at this position would be cleaner.
> > >
> > OK, thanks, it makes sense.
> >
> > Patch attached.
>
> Patch applied with a slight simplification and an informative message
> when vhooks get disabled for static builds.
>
> This must have been one of the patches with the highest number of
> revisions.  Your tenacity and willingness to accomodate review after
> review has finally paid off.  Rejoice, it's in :)
>
> Diego
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 14 Sep 2006 00:32:39 +0200
> From: Baptiste Coudurier <baptiste.coudurier at smartjog.com>
> Subject: Re: [Ffmpeg-devel] upsampling of subsampled video data
> To: FFMpeg development discussions and patches
>         <ffmpeg-devel at mplayerhq.hu>
> Message-ID: <45088707.3080305 at smartjog.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi
>
> Michael Niedermayer wrote:
> > [...]
> > 1. design or choose a video codec which works with more then 8bit per
> > sample
>
> H264 supports 10 to 12 bit per sample. DnxHD, JPEG 2000 also. D-Cinema
> specs requires 12 bits XYZ samples for jp2k.
>
> --
> Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
> SMARTJOG S.A.                                    http://www.smartjog.com
> Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
> Phone: +33 1 49966312
>
>
> ------------------------------
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
> End of ffmpeg-devel Digest, Vol 18, Issue 91
> ********************************************
>




More information about the ffmpeg-devel mailing list