Send Motion-user mailing list submissions to
motion-user@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
motion-user-requ...@lists.sourceforge.net
You can reach the person managing the list at
motion-user-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Re: Motion Project (John Baker)
2. Re: Motion Project (tosiara)
3. Re: Motion Project (John Baker)
4. Re: mpjpeg fails on wansview 1080p (Kenneth Lavrsen)
----------------------------------------------------------------------
Message: 1
Date: Sun, 07 Aug 2016 18:25:15 +0100
From: John Baker <jba...@dryfish.org.uk>
Subject: Re: [Motion-user] Motion Project
To: motion-user@lists.sourceforge.net
Message-ID:
<1470590715.1197507.688437857.711e1...@webmail.messagingengine.com>
Content-Type: text/plain
I'm more confused. How does an external coder work? I've got a Pi so
would appreciate anything that makes encoding a faster process on an ARM
chip. I'm using mpeg4 as that's the most reliable.
On Sun, Aug 7, 2016, at 06:12 PM, tosiara wrote:
> The advantage is that you can use ANY codec for video files and still
> keep
> SWF for timelapse (which is MPEg2 with support of resuming videos). And
> external encoder is the only way to utilize more than one cpu core. For
> example, on a low power ARM device internal encoder will bloat single
> core
> and drop frames. While with 'x264' encoder you can capture and encode
> 1280p@30fps stream
------------------------------
Message: 2
Date: Sun, 7 Aug 2016 20:33:14 +0300
From: tosiara <tosi...@gmail.com>
Subject: Re: [Motion-user] Motion Project
To: Motion discussion list <motion-user@lists.sourceforge.net>
Message-ID:
<CACHTdwTvZK=qtr6zc5jlt9j6nqu5wywijguki0ui+fqpqwd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I agree, param description is confusing and needs to be updated. I will
file an issue and propose a patch as soon as we migrate and the repo is
available for bug filing
For now try using ext pipe.
Set ffmpeg_output_movies off
And use, for example, x264 encoder:
extpipe x264 - --input-res %wx%h --fps %fps --bitrate 2000 --preset
ultrafast --quiet -o %f.mp4
Give it a try
On Sun, Aug 7, 2016 at 8:25 PM, John Baker <jba...@dryfish.org.uk> wrote:
> I'm more confused. How does an external coder work? I've got a Pi so
> would appreciate anything that makes encoding a faster process on an ARM
> chip. I'm using mpeg4 as that's the most reliable.
>
> On Sun, Aug 7, 2016, at 06:12 PM, tosiara wrote:
> > The advantage is that you can use ANY codec for video files and still
> > keep
> > SWF for timelapse (which is MPEg2 with support of resuming videos). And
> > external encoder is the only way to utilize more than one cpu core. For
> > example, on a low power ARM device internal encoder will bloat single
> > core
> > and drop frames. While with 'x264' encoder you can capture and encode
> > 1280p@30fps stream
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Sun, 07 Aug 2016 18:39:19 +0100
From: John Baker <jba...@dryfish.org.uk>
Subject: Re: [Motion-user] Motion Project
To: motion-user@lists.sourceforge.net
Message-ID:
<1470591559.1199291.688441657.762ad...@webmail.messagingengine.com>
Content-Type: text/plain
What external application will do a better job than ffmpeg? I thought
ffmpeg was optimised for various chip architectures?
I still don't follow ffmpeg_video_codec. What are the correct options
and when? It sounds like for timelapse, there are two (swf and mpeg4),
and for motion video, there is a wider list. If so, do we need two video
codec options, one for timelapse and one for motion detection?
But why would I want two - I'd like one type for all videos produced.
On Sun, Aug 7, 2016, at 06:33 PM, tosiara wrote:
> I agree, param description is confusing and needs to be updated. I will
> file an issue and propose a patch as soon as we migrate and the repo is
> available for bug filing
>
> For now try using ext pipe.
> Set ffmpeg_output_movies off
> And use, for example, x264 encoder:
>
> extpipe x264 - --input-res %wx%h --fps %fps --bitrate 2000 --preset
> ultrafast --quiet -o %f.mp4
>
> Give it a try
>
> On Sun, Aug 7, 2016 at 8:25 PM, John Baker <jba...@dryfish.org.uk> wrote:
>
> > I'm more confused. How does an external coder work? I've got a Pi so
> > would appreciate anything that makes encoding a faster process on an ARM
> > chip. I'm using mpeg4 as that's the most reliable.
> >
> > On Sun, Aug 7, 2016, at 06:12 PM, tosiara wrote:
> > > The advantage is that you can use ANY codec for video files and still
> > > keep
> > > SWF for timelapse (which is MPEg2 with support of resuming videos). And
> > > external encoder is the only way to utilize more than one cpu core. For
> > > example, on a low power ARM device internal encoder will bloat single
> > > core
> > > and drop frames. While with 'x264' encoder you can capture and encode
> > > 1280p@30fps stream
> >
> > ------------------------------------------------------------
> > ------------------
> > _______________________________________________
> > Motion-user mailing list
> > Motion-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/motion-user
> > http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
> >
> ------------------------------------------------------------------------------
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
------------------------------
Message: 4
Date: Sun, 7 Aug 2016 20:28:14 +0200
From: Kenneth Lavrsen <kenn...@lavrsen.dk>
Subject: Re: [Motion-user] mpjpeg fails on wansview 1080p
To: motion-user@lists.sourceforge.net
Message-ID: <aaf63efa-d07c-18fe-ac41-11b025d4c...@lavrsen.dk>
Content-Type: text/plain; charset="windows-1252"
The libmicrohttpd seems like a good plan. Light. What I meant was like -
do not assume Apache installed or require that the apache libs are used.
That would kill Motion on a small box.
I like your idea with libmicrohttpd
Kenneth
On 07-Aug-16 18:56, Mr Dave wrote:
> The digest authentication has been issue for a while and I believe
> does need to be addressed. Many of the current cameras will only
> support digest or no authentication. In this situation, we are
> forcing the user to leave the camera open to the world. I am planning
> on investigating the use of that external microhttp lib for both the
> streaming components as well as the non RTSP cameras. The RTSP
> cameras use the ffmpeg libraries so addressing those would be a
> different solution.
>
> Dave
> On 8/7/2016 7:55 AM, tosiara wrote:
>> Kenneth,
>>
>> the was suggestion to use libmicrohttpd which seems a good choice and
>> is really not too heavy for motion:
>> https://github.com/Mr-Dave/motion/pull/94#issuecomment-159535262
>>
>> On Sun, Aug 7, 2016 at 1:24 PM, Joseph Heenan <jos...@heenan.me.uk
>> <mailto:jos...@heenan.me.uk>> wrote:
>>
>> 2 doesn?t seem a particularly high priority to me given that the
>> camera works with motion using rtsp (which does support digest
>> auth), but I may have missed something.
>>
>> Joseph
>>
>>
>>> On 7 Aug 2016, at 08:08, tosiara <tosi...@gmail.com
>>> <mailto:tosi...@gmail.com>> wrote:
>>>
>>> So here we have two issues:
>>> 1. motion should better handle 401 or any non-200 http status
>>> and show user friendly error
>>> 2. digest auth support
>>>
>>> The first would probably be an easy code change
>>> But the second would be a challenge. We can implement digest
>>> auth. Or. There was a discussion already to replace all the
>>> manual http code by some web library that provides better
>>> support and better maintained. But that requires also quite a
>>> lot of efforts to change the code
>>>
>>> On Sun, Aug 7, 2016 at 9:25 AM, John Baker
>>> <jba...@dryfish.org.uk <mailto:jba...@dryfish.org.uk>> wrote:
>>>
>>> So being more awake this morning, I now spot the problem.
>>> The camera
>>> wishes to use HTTP digest authentication, which I guess
>>> motion doesn't
>>> support (another on the todo list Mr Dave / Joseph ?:).
>>>
>>>
>>> http://stackoverflow.com/questions/2384230/what-is-digest-authentication
>>>
>>> <http://stackoverflow.com/questions/2384230/what-is-digest-authentication>
>>>
>>> Example:
>>>
>>> > HEAD /mjpeg/stream.cgi?chn=0 HTTP/1.1
>>> > Host: 192.168.0.102
>>> > User-Agent: curl/7.49.1
>>> > Accept: */*
>>> >
>>> < HTTP/1.1 401 Unauthorized
>>> < WWW-Authenticate: Digest realm="IPCamera Login",
>>> nonce="f35b3a998c0b964d21d99da3f8880f14", qop="auth"
>>>
>>> > HEAD /mjpeg/stream.cgi?chn=0 HTTP/1.1
>>> > Host: 192.168.0.102
>>> > Authorization: Digest username="visitor", realm="IPCamera
>>> Login", nonce="f35b3a998c0b964d21d99da3f8880f14",
>>> uri="/mjpeg/stream.cgi?chn=0",
>>> cnonce="MWY1N2M3NmUzMjNlODIxM2ZjMzAxYTcyNTIzMjA0MTY=",
>>> nc=00000001, qop=auth,
>>> response="3bb6cbc93342432432421104ebeed5c3a"
>>> > User-Agent: curl/7.49.1
>>> > Accept: */*
>>> >
>>> < HTTP/1.1 200 OK
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Motion-user mailing list
>>> Motion-user@lists.sourceforge.net
>>> <mailto:Motion-user@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/motion-user
>>> <https://lists.sourceforge.net/lists/listinfo/motion-user>
>>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>>> <http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Motion-user mailing list
>>> Motion-user@lists.sourceforge.net
>>> <mailto:Motion-user@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/motion-user
>>> <https://lists.sourceforge.net/lists/listinfo/motion-user>
>>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>>> <http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Motion-user mailing list
>> Motion-user@lists.sourceforge.net
>> <mailto:Motion-user@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/motion-user
>> <https://lists.sourceforge.net/lists/listinfo/motion-user>
>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>> <http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Motion-user mailing list
>> Motion-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/motion-user
>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Motion-user mailing list
> Motion-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
------------------------------
_______________________________________________
Motion-user mailing list
Motion-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/motion-user
End of Motion-user Digest, Vol 123, Issue 23
********************************************
