Send Motion-user mailing list submissions to

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to

You can reach the person managing the list at

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."

Today's Topics:

   1. Re: clip quality issues (B?lint Tak?cs)


Message: 1
Date: Thu, 15 Aug 2019 10:30:08 +0200
From: B?lint Tak?cs <>
To: Motion discussion list <>
Subject: Re: [Motion-user] clip quality issues
Content-Type: text/plain; charset="utf-8"

I am also able to display both the rtsp / rtmp streams without any errors,
hiccups, frame freezes or gaps with ffplay on the same machine, over long

Attached ffplay reports. I cannot see any errors at all.


On Thu, Aug 15, 2019 at 9:24 AM B?lint Tak?cs <> wrote:

> Hi tosiara,
> Thanks for your answer.
> The fps was originally set to 30, then I have put something large there,
> just to make sure this is not the effect of clamping a "catch-up" part of
> the stream where perceived fps may be higher.
> I have set it now to 25 to match the original, and the issue remains. But
> the event_new_video log entries are now maxing out at 25 fps.
> I cannot reproduce the same configuration exactly over rtsp. The camera
> provides 3 streams: 640x352@5ps, 896x512@25fps, 2560x1440@25fps (or
> @30fps with NTSC - tried and no changes), and I am intending to use the
> middle one.
> All three streams are available over rtmp, but only the first and the last
> seems to be available over rtsp - or at least I could not find any resource
> providing a link for the middle one. The camera allows tuning parameters of
> the first and the last stream, but not the middle one.
> The least resolution looks working without errors in rtmp in motion, but
> it also has the artefacts in rstp. I still would prefer the middle one as
> the resolution/fps of the first is quite weak.
> The last one's bandwidth is too large to be consistently streamed over all
> my outdoor wifi connection, although only occassional freezes occur in
> other clients. ffmpeg can again record it almost perfectly to a file.
> I have attached the logs when cameras set to rtsp connection over the
> first and the last stream (I had to cut the second as the list does not
> allow >500kB attachments). They are full of errors. The clips themselves
> get worse with rtsp - they show lots of artefacts, smearing and
> disappearance of lower parts of the frames. In addition, the original
> repeated and missing frame issue still remains.
> I have just recorded a clip with passthrough where the timestamps looked
> at least good enough to flip through the clip frame by frame. The problem
> looks like lots of repeated frames early on, then a big gap of, say, half a
> minute follows later.
> Regards,
> Balint
> On Wed, Aug 14, 2019 at 10:23 AM tosiara <> wrote:
>> And do you really need 1000 FPS in your config?
>> # Maximum number of frames to be captured per second.
>> framerate 1000
>> I'd suggest to specify the real framerate here
>> On Wed, Aug 14, 2019 at 11:21 AM tosiara <> wrote:
>>> RTSP "generates lots of artifacts" and RTMP "have frame repeats and
>>> missing segments" sounds as pretty much the same
>>> Could you please set up your cameras as RTSP, run the same test once
>>> again and reupload the motion.log?
>>> On Wed, Aug 14, 2019 at 11:15 AM B?lint Tak?cs <> wrote:
>>>> Hi,
>>>> I am trying to use motion for my 4x RLC-WS411 camera setup over 896x512
>>>> 25 fps streams.
>>>> OS is Ubuntu 18.04, first trying the official package, then the latest
>>>> git master that I have compiled myself.
>>>> My problem is that motion output clips that seems to have frame repeats
>>>> and missing segments. However, running "ffmpeg -i rtmp://URL -vcodec copy
>>>> -acodec copy out.mp4 "runs without problems, and the generated clips are
>>>> perfect.
>>>> I am connecting through rtmp as rtsp generates lots of artifacts. The
>>>> connection is wifi, and the connection does seem to have drops, but
>>>> generally, this stream is possible to view without any problems in the
>>>> camera's own client. (The high quality stream is over the available
>>>> bandwidth.)
>>>> The CPU is an 8-core Ryzen. 'top' shows motion to run at 30-50% on one
>>>> core (with 4 cams). Also has a relatively weak Nvidia 610 card, but I
>>>> suspect it is not used anywhere.
>>>> I have also noticed that with movie_passthrough on, the recorded .mp4
>>>> clips seems to have garbled timestamps, at least VirtualDub gets quite
>>>> confused when reading them, showing impossible lengths. Sometimes this
>>>> occurs with passthrough off as well, and the motion clips or pictures also
>>>> have this problem.
>>>> Also noticed that with movie_passthrough off, the recorded clips are
>>>> 30x bigger in size.
>>>> I have tried the following:
>>>> 1. recoding frames with picture save. At the problematic parts, motion
>>>> outputs the same frame repeatedly. It does not seem to skip frames that
>>>> time, only later.
>>>> 2. flipping options netcam_use_tcp and movie_passthrough, no change.
>>>> 3. increasing framerate, pre_capture, post_capture values to large
>>>> numbers. No change.
>>>> 4. removing filters to limit the impact of processing - no change.
>>>> 5. Given the .logs had lots of resizing messages, I have tried
>>>> increasing the packet ring buffer size in netcam_rtsp.c from 30 to 512.
>>>> This seems to have a positive effect if passthrough is off, the pauses are
>>>> smaller, although the repeated frame issue remains.
>>>> Attached my current motion.conf I am using to experiment with, a camera
>>>> setup, and a sample .log file.
>>>> I have also noticed that the .log has this impossible entries like
>>>> "event_new_video: Source FPS 751"; maybe that gives a hint.
>>>> Any ideas what to try?
>>>> Many thanks for your help,
>>>> Balint
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffplay-rtmp.log
Type: application/octet-stream
Size: 114405 bytes
Desc: not available
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffplay-rtsp.log
Type: application/octet-stream
Size: 132010 bytes
Desc: not available



Subject: Digest Footer

Motion-user mailing list


End of Motion-user Digest, Vol 158, Issue 27

Reply via email to