Problem with recorded mp4 files

Hi,

I am using the Livu iPhone app to stream to a Wowza server (2.2.4), and recording the stream. I am using the code listed below to rename and move the recorded file after the live stream has finished.

Occasionally I get one of these errors:

  1. The file is not renamed and moved, as if my code was not executed at all. The resulted mp4 file is also unplayable (like in problem 2).

  2. The recorded mp4 file is renamed and moved but is unplayable. As far as I can say, it is missing its mp4 header.

Any idea what can cause that?

Thanks,

Eyal.

public void onWriteComplete(IMediaStream stream, File file)
		{
			getLogger().info("ModuleWriteListener.onWriteComplete["+stream.getContextStr()+"]: "+file);
			//Long streamEndTIme = stream.getVideoTC();
			Long streamTime = stream.getElapsedTime().getTime();
			//Date streamDate=new Date();
			//streamDate.setTime(0);
			Date date = new Date();
			Long streamEndTime = date.getTime();
			date.setTime(streamEndTime - streamTime);
			DateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");
			String dateStr = dateFormat.format(date);
			String ravID = file.getName().substring(0, file.getName().lastIndexOf('.'));
			if (ravID.length() > 4) ravID = ravID.substring(ravID.length() - 4);
			getLogger().info("ModuleWriteListener: Date = " + dateStr);
			String newFileName = file.getParentFile().getAbsolutePath() + "\\" + 
				ravID + "\\" + ravID + "-" + 
				dateStr.substring(0,4) + dateStr.substring(5,7) + dateStr.substring(8,10) + "-" +
				dateStr.substring(11,13) + dateStr.substring(14,16) + dateStr.substring(17,19) + "." + stream.getExt();   
			copyfile (file.getAbsolutePath(), newFileName);
			registerFileByUrl(ravID);
		}

For occasional failure in recording applications, the usual cause is network problems during the recording. That is the fragile factor.

Richard

I really am not sure why you are getting this error. If you can send us steps to reproduce the problem then we will look into it. We need reproducible steps to debug the problem.

Charlie

I think so. In these cases onWriteComplete never runs, you said, suggesting network interruption is the cause, the file was not properly written and complete. I think this is to be expected at least occasionally where the stream source for the recording is a mobile device. It might be good to grab recordings in smaller chunks somehow. You could use the LiveStreamRecord API.

Richard

Yes, actually, I checkeed, and Wowza should be able to close a file in a failed connection situation if it had been capturing a stream. So I’m not sure. Are the unplayable videos large and different sizes? I.e., does it look like some recording occurred?

You will have to capture more detail about an incident including corresponding log files, or more better yet tell us how to reproduce.

To test, are you streaming the videos to Flash app like Wowza SimpleVideoStreaming. Did you try to play in VLC and look at Tools > Codec Details, or open in GSpot?

Richard

I think you did find the problem:

VLC does not support the audio or video format “undf”

Richard

Actually, “undf” probably, obviously, means “undefined”, i.e., corrupt. So I guess that is not new info.

Richard

It is my understand, as I said previously, that Wowza can/should be able to close a file that was being recorded when a connection was lost, but evidently not always. It would be useful to find out what the factor(s) are to failure in this case. Let us know if you can find anything in common to these corrupt recordings.

Richard

We discussed this. It will be difficult to get this to work. The only solution would be to record to FLV (which is less complicated) then convert to MP4 using ffmpeg:

ffmpeg -i test.flv -acodec copy -vcodec copy test.mp4

Richard

You can inject cuepoints into mp4 container with Wowza 3.0.3.05

Richard

Yes, h.264 video and AAC or MP3 audio in .flv container.

Remove mp4: prefix from stream name in the encoder (or from stream name in StreamManager) to record to .flv

Richard

No, you can’t do it in configuration files. It is either in the encoder (maybe hidden from you) or in StreamManager.

Richard

Eyal,

The file needs to be in quicktime (.mp4) container. They should already contain h.264 and AAC or MP3, so this might work:

ffmpeg -i input.flv -acodec copy -vcodec copy output.mp4

However, you might want to do more for iOS playback. There are ffmpeg examples specifically for iOS devices here:

https://www.wowza.com/docs/how-to-encode-video-on-demand-content

Richard

You are using Livu, the stream source is mobile device, which are not very reliable in many situations. I think that has to be the weakness in your system, I don’t know how Wowza can compensate or mitigate that. Recording the h.264 video to flv initially, then converting, is a good idea.

Richard

Richard,

What container use the live-record application?

I can put some properties for save the file into MP4 container, I’m streaming into H264/aac.

Thanks,

Ale

Richard,

Sorry I miss something, I’m asking if possible save de files using MP4 Container… I see than the current Container is FLV, but I’m using H264 codec for stream, and will be great have all into MP4 container, not FLV. I can setting someting for save direcly into MP4?

I don’t see the relation with cuepoints, possible I don’t understand something.

Thanks,

Ale

By network problem, you mean Internet? If the connection is lost it damages the recording?

If onWriteComplete never runs, it can explain why the file is not copied and renamed (as this is what my code does), but why is it damaged - totally un playable. Seems like header missing. Can’t Wowza detect the lost connection and finishes neathly?

It’s difficult to reproduce the problem since it’s happens sporadically. I could not find a clear characteristic to its cause. Opening the file in VLC give this error:

VLC does not support the audio or video format “undf”.

It’s seems to me like the file is totally missing it’s header.

Looking at the logs, I think this lines corresponds to a damaged file:

WARN server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - RTPStream.idle[1680506560:live/definst:khl0331]: Close RTSP/RTP session. Session timeout: 90000

ERROR server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - QTWriterContextTrackAtomBase.getBlock: java.io.EOFException

ERROR server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - QTWriterContextTrackAtomBase.getBlock: java.io.EOFException

ERROR server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - QTWriterContextTrackAtomBase.getBlock: java.io.EOFException

ERROR server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - QTWriterContextTrackAtomBase.getBlock: java.io.EOFException

ERROR server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - QTWriterContextTrackAtomBase.getBlock: java.io.EOFException

ERROR server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - QTWriterContextTrackAtomBase.getBlock: java.io.EOFException

ERROR server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - QTWriterContextTrackAtomBase.getBlock: java.io.EOFException

ERROR server comment 2011-10-07 06:55:48 - - - - - 222140.359 - - - - - - - - QTWriterContextTrackAtomBase.getBlock: java.io.EOFException

Thanks,

Eyal.

I guess you mean the log lines. Well I confirmed that another damaged file has created the same errors. However, please help me understand what this error is, and what may cause it.