Mp4 stream recorded with live-record has wrong duration

Wowza Streaming Engine
1

Hello,

since this issue shown a few times, I decided to post a message on the support forum.

I am using Wowza 3.0.2 to stream and record a video using live-record streaming type (with file append). Every now and then, usually when a long video is recorded (3-4+ hours, but today happened also with a 1:30 hours video) and the stream is stopped and restarted 1 or more times, the recorded file shows a totally wrong duration of some 20+ hours when played in JW Player or checked with ffmpeg; trying to skip to a time past the true length of the recording hangs the player. Here is the output of ffmpeg for the file recorded today:

ffmpeg -i qqusPfWdnj.mp4
ffmpeg version N-33316-g825dd13-syslint, Copyright (c) 2000-2011 the FFmpeg developers
  built on Oct  6 2011 16:00:25 with gcc 4.1.2 20080704 (Red Hat 4.1.2-51)
  configuration: --prefix=/usr/local/cpffmpeg --enable-shared --enable-nonfree --enable-gpl --enable-pthreads --enable-libopencore-amrnb --enable-decoder=liba52 --enable-libopencore-amrwb --enable-libfaac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --extra-cflags=-I/usr/local/cpffmpeg/include/ --extra-ldflags=-L/usr/local/cpffmpeg/lib --enable-version3 --extra-version=syslint
  libavutil    51. 19. 0 / 51. 19. 0
  libavcodec   53. 19. 0 / 53. 19. 0
  libavformat  53. 14. 0 / 53. 14. 0
  libavdevice  53.  4. 0 / 53.  4. 0
  libavfilter   2. 43. 6 /  2. 43. 6
  libswscale    2.  1. 0 /  2.  1. 0
  libpostproc  51.  2. 0 / 51.  2. 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x6cf6780] multiple fourcc not supported
    Last message repeated 1 times
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x6cf6780] Invalid SampleDelta in STTS -899056682
Seems stream 1 codec frame rate differs from container frame rate: 50.00 (50/1) -> 24.92 (299/12)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'qqusPfWdnj.mp4':
  Metadata:
    major_brand     : f4v
    minor_version   : 0
    compatible_brands: isommp42m4v
    creation_time   : 2012-07-12 04:47:51
  Duration: 25:22:55.00, start: 0.000000, bitrate: 51 kb/s
    Stream #0:0(eng): Audio: mp3 (.mp3 / 0x33706D2E), 44100 Hz, mono, s16, 96 kb/s
    Metadata:
      creation_time   : 2012-07-12 04:47:51
    Stream #0:1(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 697 kb/s, 24.99 fps, 24.92 tbr, 90k tbn, 50 tbc
    Metadata:
      creation_time   : 2012-07-12 04:47:51

Moreover, streams recorded using this setup cannot be edited with ffmpeg or Adobe Premiere, since the video processing stops as soon as the frame where the file has been appended for the first time is reached.

Please help me in solving this issue.

2

Does such a file play correctly in Wowza SimpleVideoStreaming example player, or JW Player? Is the seek bar too long?

Is versioning instead of appending an option?

Richard

3

I’m just not sure with all these other things (video editing) in the mix. FFmpeg can stitch the pieces together. If you are only streaming to Flash RTMP clients you can stitch together with this method (But there are duration issues with this too):

https://www.wowza.com/docs/how-to-insert-a-pre-roll-or-mid-roll-for-video-on-demand-playback-in-flash-rtmp-client

Richard

4

If there is still a .tmp file alongside the .mp4, then it is corrupt, unusable and unfixable.

Richard

5

The container has the wrong metadata. “-map_metadata -1” might clear that out. Running through ffmpeg will reset the timecodes. Try one of these:

fmpeg -i “$INPUT” -vcodec copy -acodec copy reset.mp4;

fmpeg -i “$INPUT” -map_metadata -1 -vcodec copy -acodec copy reset.mp4;

Test with ffprobe to verify A/V have the same duration:

ffprobe -show_streams “$INPUT”;

ffprobe -print_format csv -show_frames “$INPUT” > info.txt;

If the first ffprobe command doesn’t show the duration use the second. Look at the beginning and the end to see if there are extra audio or video frames. If so, you can crop it with ffmpeg “-t” command.

Joining cropped clips should always work without de-sync issues.

Just a hunch: It seems Wowza has recoded extra information when the stream was stopped and started. Perhaps this scenario can be avoided by forcing Wowza to close the stream, when publishing stops, and restart a new appended recording when it starts again. Perhaps by shortening some timeout value somewhere.

6

Good question. Unfortunately the video has been edited (Adobe Premiere could see the stream real duration and process the video, but not the audio, so the audio was extracted with Leawo Video Converter - which couldn’t process the video, instead, and saw the “fake” duration for the stream - and then audio and video track were remuxed with Adobe Premiere) and the original file has been overwritten.

Versioning could be an option, but then I will have to manually join the versioned file after the stream is over, and this can potentially lead to more issue (i.e.: audio desynch). Also, I would like the process to be automated, but I can’t think of a “maximum time” after which I can be sure that the stream of an event is over and won’t be resumed, so I can safely join all versioned files in a single one. Or maybe I can just join files as soon as they are closed… Hmm, what do you suggest to do?

7

Hello,

I am posting again in this thread since I experienced the issue once more, after some months of nice Wowza behavior.

I tried with the “-map_metadata -1” command with no luck: ffmpeg gives me the following error

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x284d780] Invalid SampleDelta in STTS -2115814036

then it hangs at the very first frame with the following output:

frame= 1 fps= 0 q=-1.0 size= 13kB time=00:00:00.04 bitrate=2750.0kbits/

frame= 1 fps= 0 q=-1.0 Lsize= 69296kB time=00:00:00.04 bitrate=14191834.6kbits/s

video:13kB audio:66976kB global headers:0kB muxing overhead 3.443536%

Furthermore, I can use ffmpeg to demux the audio track, but trying to demux the video track gives the following output after just 1 frame:

frame= 1 fps= 0 q=-1.0 Lsize= 13kB time=00:00:00.04 bitrate=2740.4kbits/s

video:13kB audio:0kB global headers:0kB muxing overhead 0.000000%

I still have to investigate alternatives to append.

8

hello, i had the same problem with “versioning” - the stream has been stopped and re-started and the latest file test.mp4 is corrupted

Using Atom Inspector, mdhd of sound track shows “timescale 90000 and duration 334348369470” - holy cow

mdhd of video media track shows “timescale 90000 and duration 1007910” which is correct

If anyone wants to debug the stream, I can upload it to Google drive.

Thanks

9

If there is still a .tmp file alongside the .mp4, then it is corrupt, unusable and unfixable.

Richard

There is no tmp