MP4 file not being written but FLV is

Wowza Streaming Engine
1

Hi,

We’ve got a strange issue. We are doing a live video post using an RTMP feed. The broadcaster is using:

rtmp://ouringestpoint:1935/rtmplive/mp4:NewLayout/somestream

I have a server-side module that is triggered when the write is complete that moves the resulting MP4 file into a specific directory depending on the stream name. This all seems to work fine IF I use something like ffmpeg to send the stream, e.g.:

ffmpeg -f video4linux2 -i /dev/video0 -vcodec libx264 -f flv rtmp://ouringestpoint:1935/rtmplive/mp4:NewLayout/ricktest01

However, when our client (using their application) tries it, the live stream occurs, you can watch it live, but when it’s over the system writes an FLV file and never writes the MP4 file. I’m not sure if my module is ever triggered. Their application is iPhone based, I don’t know what libraries they’re using.

Any ideas? Could this be the application versus application instance (stream name) problem? I thought that only affected VOD playback.

2

Hi there.

What version of Wowza are you running?

Can you please confirm that your custom module is writing the FLV file to a specified directory, or if the file is being saved to the [install-dir]/content directory.

If you are running a Wowza version previous to Wowza 4.x, and the custom module is working as expected but not creating an .mp4, it could be because previous versions of Wowza recorded to .flv. You can specify the recordings be saved to .mp4 by editing [install-dir]/conf/Server.xml and change:

<Streams>
    <DefaultStreamPrefix>flv</DefaultStreamPrefix>
</Streams>

And change to:

<Streams>
	<DefaultStreamPrefix>mp4</DefaultStreamPrefix>
</Streams>

If you are running Wowza 4.x, and/or your module is not working as expected, you could try the Wowza ModuleMediaWriterFileMover:

How to move recordings from live streams (ModuleMediaWriterFileMover)

I hope this helps.

Salvadore

3

We are running 3.5.2. Note that my custom module does not write an MP4–it expects to move an existing MP4 once it has been written by Wowza. Again, using ffmpeg as the encoder (see my previous post), Wowza DOES write an MP4 file. When that’s complete, my module is triggered and it moves the MP4 to the appropriate spot. It is only when the client uses their iPhone application to publish that the system only writes an FLV file. I can enable logging on my module to see if it is triggered, but my guess is that it is not. I don’t know if this is because their iPhone app doesn’t close the stream cleanly or what, but an MP4 is never written when their iPhone app is used.

4

I should also add that this only occurs if a path is used in the stream name. If they publish to “rtmp://ouringestpoint:1935/mp4:somestreamname” then the MP4 is written. It is if they publish to “rtmp://ouringestpoint:1935/mp4:NewLayout/somestreamname” that the MP4 isn’t written and only the FLV is.

5

There is no “DefaultStreamPrefix” property in any of the XML config files on our server, and no “” stanza in Server.xml, so I’m not sure where to put this. Should it go in the application’s Application.xml file?

6

Sorry about the long delay in responding to this. Getting the customer to help out here is a bit, well, difficult.

We did trace the issue back to the client’s library. To publish, they simply hand a complete URL such as:

rtmp://ourserver/rtmplive/definst/mp4:NewLayout/ricktest06

to the library and it would split things at the last “/”. Everything before that was the application name, and everything after it was the stream name. Hence the stream name wasn’t prefixed by “mp4:”, so it wrote FLV files. They got a beta version of the library and now they can specify the application and stream name and things are good as far as that’s concerned.

We’ve hit another problem. I use the above publishing URL to have ffmpeg stream my web camera. I then try to watch the live streams.

Using an OSMF player to play “http://ourserver/rtmplive/definst/NewLayout/ricktest06/manifest.f4m” seems to work (although there is a huge delay…possibly something from ffmpeg). However, if I try to play “http://ourserver/rtmplive/definst/NewLayout/ricktest06/playlist.m3u8” using Safari on a Macbook Air, I get the m3u8 file, but we get 404s on the chunklists associated with it and the m3u8 file itself has a MIME type of “application/vnd.apple.mpegurl” (which Safari can’t handle).

Am I doing something wrong here? What would be correct live URLs for people to watch the streams?

7

Actually, more research shows that the client’s library is still splitting the app, app instance and stream names at the wrong spot. We’re working on that.

I’ll keep you posted.

8

Yup. Got it sorted. We recoded the strings handed to the beta version of the client library and it’s all better now. Thanks for the help, gang! This was driving me crazy!

9

If you have not done so, you could change the default prefix Wowza records to from .flv to .mp4 as described in my last post and see if that helps.

If it does not, please do enable logging for your module, and run a test from the iPhone app, then zip up your /conf and /log folders and send them to support@wowza.com for a closer look. Please include a link to this thread as a reference.

Thank you.

Salvadore

10

I see, you are right. They added the ability to change the default prefix in Wowza 4.x as well. Sorry about that.

But it may be that you are using the wrong URL.

Try it like this:

rtmp://ouringestpoint:1935/NewLayout/mp4:somestreamname

Salvadore

11

Hello there,

This could be caused by application configurations, audio/video codec dependencies, bit rate/profile to high, as well as other causes.

You might try a clean application and test streaming to that application, making sure the profile is “main” or “baseline”. And, or you could zip up your /conf and /logs folders and send then to support@wowza.com to open a ticket.

Thank you.

Salvadore