Publish/play live stream (MPEG-TS) failed !!!

Hi friends,

I’m stuck with this problem for many nights, so please help, someone!

I’m trying to stream H.264 video in MPEG-TS container (using FFMPEG) to Wowza, and play the output (using VLCPlayer), but it does not work.

I’m following the steps as instructed at https://www.wowza.com/docs/how-to-publish-and-play-a-live-stream-mpeg-ts-based-encoder(MPEG-TS-based-encoder

  1. I stream out using FFMPEG as follows:

ffmpeg -i sample.mp4 -f mpegts udp://localhost:10000

Wowza is installed on the same machine, and sample.mp4 contains H.264 video.

  1. The contents of mpegts.stream file is as follows:

udp://0.0.0.0:10000

  1. I started receiving stream in the Wowza Stream Manager page, by specifying MediaCaster type as ‘rtp’, and Stream Name as ‘mpegts.stream’

  2. I try to play the live stream using VLC Player, by giving the following URL (in Open Network Stream option):

rtsp://localhost:1935/live/mpegts.stream

VLC Player is also installed on the same machine.

VLC Player throws out the error

“Your input can’t be opened: VLC is unable to open the MRL ‘rtsp://localhost:1935/live/mpegts.stream’. Check the log for details.”

I checked in %appdata%/vlc folder (Windows), but could not figure out where to find VLC’s log file. (I guess I need to post this part in VLC forum!)

Additional tests/info:

Then I checked the live stream output using Adobe Flash Player (RTMP), using the page at

[install-dir]/examples/LiveVideoStreaming/client/live.html, by specifying

Server: rtmp://localhost/live

Stream: mpegts.stream

The page did not display the video either. The Start button though turned to Stop, and there were no errors displayed.

Wowza installation was tested earlier by successfully playing a hosted video (same mp4 file with H264 video) using VLC Player. (rtsp://localhost:1935/vod/mp4:sample.mp4)

Query: I saw in the Wowza user guide that for re-streaming of an MPEG-TS stream, the Streams/StreamType property in Application.xml needs to be ‘rtp-live’. Whereas the same property as described in the MPEG-TS streaming tutorial section is ‘live’. Which is correct? Or do both work?

I tried changing it to ‘rtp-live’, but it did not make any difference.

Any help or pointers or comments on this sad situation, will be highly appreciated.

Regards

Arun-Jyothi

Arun-Jyothi,

One quick check, make sure the mpegts.stream file is not actually mpegts.stream.txt

What do you see in the access log after you start the stream in StreamManager?

It can be helpful to run Wowza in stand-alone mode (/bin/startup.bat) to see log output in real time.

StreamType “live” is best, and correct if you are using StreamManager to start the stream.

Richard

Windows hides known extension. Your file has .txt extension, that’s the problem

Richard

I think I missed the “not” in that sentence, and your logs show that the .stream file is right. Sorry to jump to (wrong) conclusion.

It looks like a UDP port problem, either a firewall on that server or a router or other point in your network is blocking or not port forwarding (router) UDP ports.

Richard

The problem is your ffmpeg command.

Try this one:

C:\Program Files\ffmpeg\bin>ffmpeg -i “%WMSAPP_HOME%/content/sample.mp4” -re -vcodec libx264 -g 60 -vb 150000 -strict experimental -acodec aac -ab 96000 -ar 48000 -ac 2 -vbsf h264_mp4toannexb -f mpegts udp://127.0.0.1:10000?pkt_size=1316

Something to consider: If you’re just going to be streaming VOD content you probably don’t need ffmpeg/vlc. Just follow the VOD tutorial.

p.s. I tried your ffmpeg command and got the same results. I tried the one here and it worked.

streamType:02 indicates that the video is MPEG2, not H.264.

In VLC, you’ll need to enable logging. I have it installed on Windows. From the Tools menu > Preferences. Click on Show ALL settings to get to Advanced > Logging.

-Lisa

Hi Richard,

Thanks very much for your response.

Yes, I verified that the mpegts.stream file does not have an additional .txt extension. (On Windows, it does not show the Notepad application icon that’s typical of .txt file extensions.)

I hope Wowza access log means the console log, displayed on the screen. When Wowza server is started, this is the last message displayed:

INFO server comment - Wowza Media Server is started!

When I start the stream using Stream Manager, the following messages are displayed:

(I’m not sure if so much of the log is required, anyway here goes…)

INFO application app-start definst live/definst

INFO server comment - RTPMediaCaster.create[15961328]

INFO server comment - RTPMediaCaster.init[15961328]

INFO server comment - RTPMediaCaster.Reconnector[15961328:live/definst:mpegts.stream]: start: 1

INFO server comment - HTTPStreamManager.onHTTPRequest: Publish stream successfully started [live/definst]: flv:mpegts.stream

INFO server comment - RTPSessionDescriptionDataProviderBasic.getStreamInfo[live/definst]: URI: udp://0.0.0.0:10000

INFO stream create - -

INFO stream publish mpegts.stream -

INFO server comment - RTPUDPTransport.bind[live/definst]: /0.0.0.0:10000

INFO server comment - RTPMediaCaster.Reconnector[15961328:live/definst:mpegts.stream]: done: 1

INFO server comment - RTPMediaCaster.streamTimeout[15961328:live/definst:mpegts.stream]: timeout:12000 diff:12004 reason:101

INFO server comment - RTPMediaCaster.resetConnection[15961328:live/definst:mpegts.stream]:

INFO server comment - RTPMediaCaster.closeRTPSession[15961328:live/definst:mpegts.stream]

INFO server comment - RTPUDPTransport.unbind[live/definst]; /0.0.0.0:10000

INFO stream unpublish mpegts.stream -

INFO stream destroy mpegts.stream -

INFO server comment - RTPMediaCaster.Reconnector[15961328:live/definst:mpegts.stream]: start: 2

INFO server comment - RTPSessionDescriptionDataProviderBasic.getStreamInfo[live/definst]: URI: udp://0.0.0.0:10000

INFO stream create - -

INFO stream publish mpegts.stream -

INFO server comment - RTPUDPTransport.bind[live/definst]: /0.0.0.0:10000

INFO server comment - RTPMediaCaster.Reconnector[15961328:live/definst:mpegts.stream]: done: 2

It seems to go on in a loop, so I’m stopping here, hoping it will help you guess what’s going on! Please let me know if you need more lines of the log.

Also, I think I’m running Wowza in standalone mode. On Windows, I run the Start/All Programs/Wowza Media Server 2.2.4/Wowza Startup option. I hope it’s the same as executing the batch file /bin/startup.bat.

Thanks, I will use StreamType ‘live’.

A few things to add:

  1. I have disabled Firewall on the system, just to ensure ports like 1935, 8080, 80, 554 etc. are not blocked.

  2. I’m using the developer version of Wowza. (Our customer will be buying the product, after we complete the evaluation for them). So I’m hoping this is not a limitation of the developer version.

  3. I’ve tried the test setup (FFmpeg → Wowza → VLC) on both Windows and Linux (separately), and had the same results. On Windows, FFmpeg was running on Ubuntu on top of VirtualBox.

Thanks again,

Ram

Windows hides known extension. Your file has .txt extension, that’s the problem

Richard

I think I might have misled you with my earlier comment that “Windows does not show the Notepad application icon that’s typical of .txt file extensions.”

Yes, Windows hides known extensions. And also displays the appropriate application icon for known extensions.

What I meant to convey was that Windows does NOT display the Notepad application icon for mpegts.stream file.

Further, I double checked it in the dos console (cmd.exe), and it does NOT have a .txt extension.

Moreover, I have the same issue on a similar Wowza set up on an Ubuntu box too. There too, the mpegts.stream file does NOT have a .txt extension.

Please let me know if you need any other information.

Thanks again,

Ram

Thanks, Richard. I’ll check the UDP port possibility tomorrow and revert.

Meanwhile, a couple of trials that I did today caused some changes in the Wowza logs.

  1. I changed the IP address in the FFmpeg command, from localhost to 0.0.0.0.

That is, ffmpeg -i sample.mp4 -f mpegts udp://0.0.0.0:10000

INFO stream publish mpegts.stream -

INFO server comment - RTPUDPTransport.bind[live/definst]: /0.0.0.0:10000

INFO server comment - RTPMediaCaster.Reconnector[28497887:live/definst:mpegts.stream]: done: 1

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket[0x100]: streamType: 0x2

INFO server comment - RTPDePacketizerMPEGTS.handleRTPPacket: audioPID[MP3]: 0x101

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket: Incomplete packet: 1504:1472

INFO server comment - UDPTransport.firstPacket: bind:/0.0.0.0:10000 msg:/127.0.0.1:43340

INFO server comment - RTPMediaCaster.streamTimeout[28497887:live/definst:mpegts.stream]: timeout:12000 diff:12008 reason:101

INFO server comment - RTPMediaCaster.resetConnection[28497887:live/definst:mpegts.stream]:

INFO server comment - RTPMediaCaster.closeRTPSession[28497887:live/definst:mpegts.stream]

INFO server comment - RTPUDPTransport.unbind[live/definst]: /0.0.0.0:10000

INFO stream unpublish mpegts.stream -

INFO stream destroy mpegts.stream -

INFO server comment - RTPMediaCaster.Reconnector[28497887:live/definst:mpegts.stream]: start: 2

INFO server comment - RTPSessionDescriptionDataProviderBasic.getStreamInfo[live/definst]: URI: udp://0.0.0.0:10000

INFO stream create - -

INFO stream publish mpegts.stream -

INFO server comment - RTPUDPTransport.bind[live/definst]: /0.0.0.0:10000

INFO server comment - RTPMediaCaster.Reconnector[28497887:live/definst:mpegts.stream]: done: 2

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket: Incomplete packet: 1504:1472

INFO server comment - UDPTransport.firstPacket: bind:/0.0.0.0:10000 msg:/127.0.0.1:43340

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket[0x100]: streamType: 0x2

INFO server comment - RTPDePacketizerMPEGTS.handleRTPPacket: audioPID[MP3]: 0x101

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket: Incomplete packet: 1504:1472

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket: Incomplete packet: 1504:1472

INFO server comment - CommandInterfaceCommandShutdownServer.invoke: Shutting down server.

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket: Incomplete packet: 1504:1472

INFO vhost vhost-stop defaultVHost -

INFO application app-stop definst live/definst

INFO server comment - RTPMediaCaster.shutdown[28497887:live/definst:mpegts.stream]: mpegts.stream

INFO server comment - RTPMediaCaster.disconnect[28497887:live/definst:mpegts.stream]

INFO server comment - RTPMediaCaster.closeRTPSession[28497887:live/definst:mpegts.stream]

INFO server comment - RTPUDPTransport.unbind[live/definst]: /0.0.0.0:10000

INFO stream unpublish mpegts.stream -

INFO stream destroy mpegts.stream -

Please note the warning messages in the log, that wasn’t there earlier.

That is,

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket: Incomplete packet: 1504:1472

  1. Taking a clue from the above warning message, I tried specifying the packet size explicitly. That is, ffmpeg -i sample.mp4 -f mpegts udp://0.0.0.0:10000?pkt_size=1316

Also made a corresponding change in mpegts.stream, like udp://0.0.0.0:10000?pkt_size=1316 (not sure if it is really required, I’m not able to find that link now, where I saw someone has posted this packet size!)

Now that warning message is gone!

INFO stream create - -

INFO stream publish mpegts.stream -

INFO server comment - RTPUDPTransport.bind[live/definst]: /0.0.0.0:10000

INFO server comment - RTPMediaCaster.Reconnector[2698418:live/definst:mpegts.stream]: done: 2

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket[0x100]: streamType: 0x2

INFO server comment - RTPDePacketizerMPEGTS.handleRTPPacket: audioPID[MP3]: 0x101

INFO server comment - LiveStreamPacketizerSanJose.handlePacket: Audio codec: MP3

INFO server comment - LiveStreamPacketizerCupertino.init[live/definst/mpegts.stream]: chunkDurationTarget: 10000

INFO server comment - LiveStreamPacketizerCupertino.init[live/definst/mpegts.stream]: chunkDurationTolerance: 500

INFO server comment - LiveStreamPacketizerCupertino.init[live/definst/mpegts.stream]: audioGroupCount: 3

INFO server comment - LiveStreamPacketizerCupertino.init[live/definst/mpegts.stream]: playlistChunkCount:3

INFO server comment - MediaStreamMap.getLiveStreamPacketizer: Create live stream packetizer: cupertinostreamingpacketizer:mpegts.stream

INFO server comment - CupertinoPacketHandler.startStream[live/definst/mpegts.stream]

INFO server comment - LiveStreamPacketizerCupertino.handlePacket[live/definst/mpegts.stream]: Audio codec:MP3 isCompatible:true

INFO server comment - MediaStreamMap.getLiveStreamPacketizer: Create live stream packetizer: smoothstreamingpacketizer:mpegts.stream

INFO server comment - LiveStreamPacketizerSmoothStreaming.startStream[live/definst/mpegts.stream]

INFO server comment - LiveStreamPacketizerCupertino.endChunkTS[live/definst/mpegts.stream]: Add chunk: id:1 a/v/k:140/0/0 duration:10080

INFO server comment - LiveStreamPacketizerSmoothStreaming.addFragment[live/definst/mpegts.stream]: Add chunk: type:audio id:2 count:84 duration:2016

INFO server comment - LiveStreamPacketizerSmoothStreaming.addFragment[live/definst/mpegts.stream]: Add chunk: type:audio id:3 count:84 duration:2016

INFO server comment - LiveStreamPacketizerSmoothStreaming.addFragment[live/definst/mpegts.stream]: Add chunk: type:audio id:4 count:84 duration:2016

INFO server comment - LiveStreamPacketizerSmoothStreaming.addFragment[live/definst/mpegts.stream]: Add chunk: type:audio id:5 count:84 duration:2016

INFO server comment - LiveStreamPacketizerSmoothStreaming.addFragment[live/definst/mpegts.stream]: Add chunk: type:audio id:6 count:84 duration:2016

INFO server comment - LiveStreamPacketizerSanJose.endChunkTS[live/definst/mpegts.stream]: Add chunk: id:2 a/v/k:418/0/0 duration:10032

But at the end of the day, VLC Player is still not able to play the stream. It still gives the same error “Your input can’t be opened: VLC is unable to open the MRL ‘rtsp://localhost:1935/live/mpegts.stream’. Check the log for details.”

And I haven’t been able to locate the VLC log file yet, neither on Windows nor on Ubuntu!

Thanks anyway,

Ram

Hi Richard,

I checked the UDP ports with Wireshark, and everything appears ok. It shows inbound traffic (from ffmpeg) on port 10000 and outgoing traffic (from Wowza) on port 1935.

Thanks,

Ram

streamType:02 indicates that the video is MPEG2, not H.264.

Thanks, Lisa. But FFmpeg reports that the video encoding type is H.264. That is, “ffmpeg -i sample.mp4” command. And I guess the “-f mpegts” option on the ffmpeg command puts video (and audio) into an MPEG2-Transport Stream container. I hope that’s what you mean when you say the video is MPEG2?

Thanks, I followed the steps you told, and specified the log file name (in a folder where I have write permission). However, when VLC threw the error “Your input can’t be opened: VLC is unable to open the MRL ‘rtsp://localhost:1935/live/mpegts.stream’. Check the log for details.”, I went and checked in that folder, and I could not find the log file. Not sure what’s happening, but it looks like it’s not creating the log file. (Anyway, this one’s really for the VLC forum!)

Thanks,

Ram

BTW, it looks like I made a (major) mistake while posting my 2nd observation last Friday. Sorry folks, please find (below) the corrected observation (abridged).

  1. Taking a clue from the warning message

“WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket: Incomplete packet: 1504:1472”,

I tried specifying the packet size explicitly. That is, ffmpeg -i sample.mp4 -f mpegts udp://0.0.0.0:10000?pkt_size=1316

Also made a corresponding change in mpegts.stream, like udp://0.0.0.0:10000?pkt_size=1316

Now that warning message is gone!

Last Friday, I’d thought that VLC Player is still not able to play the stream, but I was wrong.

In fact VLC was playing the audio, without playing the video! It was that I hadn’t noticed it because the speakers were muted. (I was so keenly looking for video to appear that I’d overlooked audio!)

Besides, the PLAY button had changed to PAUSE.

It was my mistake to think/post that VLC threw the same error as before. In fact, VLC did not throw an error in this trial.

So today, I replaced FFmpeg with VLC (streaming mode) as the video source (MPEG-TS encoder) to Wowza. The player is still VLC (another instance).

This time I was able to get a couple of video frames to display, in addition to playing audio. In an entire playback time of >10 minutes, only 2 (random?) video frames were displayed. It was looking as if the audio played smoothly, whereas the video was stuck somewhere badly.

Some progress, but miles away from sleep! Any help will still be much appreciated.

It worked !!!

Thank you #randall

Now with all ffmpeg arguments in place, it is working fine.

Sample.mp4 in contents folder was used for testing and now the video is getting streamed in both VLC and flash player (live: coming along with Wowza). It is getting played exactly as the source file. We tried it in PCs connected in local network and the video is getting streamed.

I did few more experiments like changing the IP: 127.0.0.1 to , removed the packet size from mpegts.stream file and also tried ffmpeg without -vbsf argument.

All the tests mentioned above worked fine.

Sincere thanks to Richard and Lisa

Hoping to have discussions in future as well …