Recorded files get choppy playback

[Nguyen_Ha]

Hello everyone, I’ve just installed the newest version 4.8.26+4 and tried to restream and record my IP cam stream (RTSP H265 / AAC). There is no sound in the HLS playback with VLC, codec info as below

The recorded file playback has sound but in very choppy quality. No rewind or forward play, just like a corrupted file

There is no hint in the logs except these lines

2023-12-16      20:40:16        ICT     comment server  INFO    200     -       [live/_definst_/cam6.stream] LiveStreamRecorderMP4.stopRecording() filename=/usr/local/WowzaStreamingEngine/content/cam6.stream_2023-12-16-20.38.02.244-ICT_0.mp4       -       -       -       767.113 -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -       -
2023-12-16      20:40:16        ICT     comment server  WARN    200     -       QTWriterUtils.writeMOOVAtom[/usr/local/WowzaStreamingEngine/content/cam6.stream_2023-12-16-20.38.02.244-ICT_0.mp4]: File duration requires 64-bit atom structures. File may not play properly in QuickTime for Windows. -       -       -       767.121 -       

What’s the problem here?

[Nguyen_Ha]

I forgot to mention I’m using Hikvision cameras after reading this post. Is there any specific problem with their codec and Wowza?

Hikvision cameras and Wowza

Hi did you solve the issue ? I have the exactly same problem. thanks

[Nguyen_Ha]

It’s weird that ffmpeg bring me better files, no choppy, able to rewind

Here is the ffprobe outputs of my 2 record files

Wowza Record

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'content/cam6.stream_1.mp4':
  Metadata:
    major_brand     : f4v
    minor_version   : 0
    compatible_brands: isommp42m4v
    creation_time   : 2023-12-17T13:31:57.000000Z
  Duration: 11:38:20.62, start: 0.000000, bitrate: 2 kb/s
    Stream #0:0(eng): Video: h264 (Main) (avc1 / 0x31637661), yuvj420p(pc, bt709), 1920x1080, 823 kb/s, 13.08 fps, 25 tbr, 90k tbn, 50 tbc (default)
    Metadata:
      creation_time   : 2023-12-17T13:31:57.000000Z
      handler_name    : WowzaStreamingEngine
      encoder         : WowzaStreamingEngine
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 16000 Hz, mono, fltp, 25 kb/s (default)
    Metadata:
      creation_time   : 2023-12-17T13:31:57.000000Z
      handler_name    : WowzaStreamingEngine

FFMPEG record

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'content/cam6.ff.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    title           : HIK Media Server V4.72.109
    encoder         : Lavf57.83.100
    comment         : HIK Media Server Session Description : standard
  Duration: 00:01:13.41, start: 0.000000, bitrate: 1981 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 1920x1080, 1916 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 16000 Hz, mono, fltp, 76 kb/s (default)
    Metadata:
      handler_name    : SoundHandler

It seems like Wowza did not record at the correct framerate (25fps) and got data loss

[Nguyen_Ha]

Finally, I found these error logs about RTP/AVSyncMethod

WARN    server  comment 2023-12-17      19:38:04        -       -       -       -       -       426.976 -       -       -       -       -       -       -       -       RTPDePacketizerBase.Waiting for RTCP packet. See docs for (Application.xml: RTP/AVSyncMethod and RTP/MaxRTCPWaitTime).
WARN    server  comment 2023-12-17      19:38:08        -       -       -       -       -       430.776 -       -       -       -       -       -       -       -       RTCPHandler.isTimeSyncReady: Hit MaxRTCPWaitTime synchronizing on system clock.

and following exlaination in this thread, i changed the RTP/AVSyncMethod property to the systemclock and the AV streams seem to be synced correctly and I was able to view the stream.

Impact of using RTP AVSyncMethod systemclock versus senderreport

Hi, Yes, I received the timeout. This particular device didn’t work with senderreport or rtptimecode, the only way I could view the stream is with systemclock. Is there any system or stream impact to using systemclock? Essentially, what are the potential downsides or gotchas to using systemclock versus the default (senderreport) or the fallback (rtptimecode) since neither of those worked for this particular camera. Thanks, Dan

Thank you, community.