audio timestamp reset

[ceewanna]

When I playback the video with mpv, I often get these lines and I am not so sure it has to do with my hardware or video file.

Invalid audio PTS: 28.926000 -> 50.308000
Reset playback due to audio timestamp reset.

Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).

My log file is motionplus.log.
My camera config files have this netcam_high_params preset=ultrafast,crf=32 which I often include in ffmpeg to get the file size as small as possible.

[Mr-Dave]

Yes. I have to get back to this one....it is a difficult one to solve on the audio pts. I'd note that the ultrafast and crf do not affect anything for the netcam_params.

[ceewanna]

On netcam_params, I suppose I won't make use it with the settings/parameters. Instead I would use movie_quality to trim down output file size, or I would make use of on_movie_end to execute ffmpeg to shrink each file.

[ceewanna]

I am looking forward to making full use of motionplus, i.e. with audio PTS issue above resolved.

Over the past one year, I feel grateful for having motion in operations at my farmland. It works fine and surprisingly consumes virtually no extra cpu work load even with almost 10 cameras (passthrough mode).

Recently I have just been able to build motionplus and have done some testing & setup. There seems to be more settings for threshold variables which I haven't been able to figure out much. So far both motion and motionplus seem to run along each other fine, except some output videos from motionplus seem to get the above error when replayed by mpv (the screen will get stuck in gray).

[Mr-Dave]

I just tried a few sources (file, rtsp) and did not get an issue. Can you post a gist of the Motion log at debug level where it is recording from that camera (full log). Also paste a ffprobe of the resulting movie. I can then try to replicate the source, Motion configuration and result.

[ceewanna]

I have this for you; however, I am not sure whether this meets your requirements or not. Please let me know if anything else needed.

logfile loglevel 8
motionplus.log

Sample file
ch3-barn-20230228-115415.mp4
Invalid audio PTS: 14.592000 -> 37.234000
Reset playback due to audio timestamp reset.

ffprobe command used:
ffprobe -v quiet -print_format json -show_format -show_streams -show_packets ch3-barn-20230228-115415.mp4 > ch3-ffprobe.txt

ffprobe output
ch3-ffprobe.txt

Observation
audio pts jumped from 14.xx to 37.234 in ch3-ffprobe.txt

[ceewanna]

Today I also do some test on my camera by reading and writing audio and video packets using pyav. My observations are as follows.

1. One camera having video only doesn't seem to face this pts problem.
2. The other camera having both video and audio face this pts problem from time to time. Audio seems to hit the problem more often.
3. The pts issue seems to show up in my python code as "non monotonically increasing dts to muxer in stream 1"
4. My test code loop has two types of condition: 1) skip packet is None, and 2) skip packet.dts is None. The first condition seems to result in "Invalid audio PTS" when play back by mpv.

For your inspection, this is my python code.
`

import av, cv2
from fractions import Fraction

cam = 'ch1-door'
# cam = 'ch9-hik'
url = "rtsp://localhost:8554/"+cam

source = av.open(url, metadata_encoding='utf-8') 
output = av.open(cam+'.mp4', mode='w')

in_to_out = {}
fps = 25
for i, stream in enumerate(source.streams):
	print(stream.type, stream)
	match stream.type:
		case 'video':
			in_to_out[stream.type] = output.add_stream(template=stream)
		case 'audio':
			in_to_out[stream.type] = output.add_stream(template=stream)
		case 'subtitle':
			in_to_out[stream.type] = output.add_stream(template=stream)
		case 'data':
			in_to_out[stream.type] = output.add_stream(template=stream)
		case default:
			pass

count = 0
demux = iter(source.demux())
try:
	while True:
		packet = next(demux)
		# if packet is None: continue
		if packet.dts is None: continue

		# make use of video 
		if packet.stream.type == 'video':
			for frame in packet.decode():
				img = frame.to_ndarray(format='bgr24').copy()
		packet.stream = in_to_out[packet.stream.type]
		try:
			output.mux(packet)
		except av.error.ValueError as err:
			print(err)
		
		count += 1
		if count > 25*60: break
	
finally:
	output.close()
	source.close()`

I have no idea if motion/motionplus use anything similar to pyav I tested above. Anyway I just recently learned about this pyav and my curiosity after seeing this invalid PTS in motionplus led me to trying this test code. Not sure if this has anything to do with motionplus or not. I suppose it has something to do with how stable the camera sending in packets and the way av package establish pts/dts from the time it receives packet.

[ceewanna]

I just happened to test motionplus again lately and the issue above has gone. Thank you so much.
Could you possibly share what was the cause and solution made?