MediaReaderFLV.open: Metadata Appears to Be Bad

Wowza Streaming Engine
1

I’m trying to play a FLV file to Wowza, but the following message is displayed in the error logs:

MediaReaderFLV.open: Metadata Appears to Be Bad: RPHChamda15seg.flv

What does this error?

How to solve?

Tks,

2

It might actually contain h.264 video. Try using mp4: prefix to play it:

mp4:RPHChamda15seg.flv

Richard

3

The mp4: tells us the file format to use. The mp4: prefix is for mov or mp4 files. It is required.

Charlie

4

I’m not sure how to manage it, but it is better if you use mp4 container and extension for h.264 video content.

Richard

5

Did you record the file using Wowza? You can record to a mp4 container by using mp4: prefix in the stream name. You can do it in the encoder if you are using RTMP push encoder, or in StreamManager if you are using MediaCaster stream.

Richard

6

Jake,

Is it h.264 video recorded to mp4, and not using mp4: prefix?

Richard

7

Jake,

I did a lot of testing recently of LiveStreamRecord with the included Flash app and HTTP interfaces using the recordOptions including append and versioning options, and it all worked in that package with those two examples.’

Richard

8

Jake,

I see, I didn’t know you were recording to s3 mount. That is a known problem. It can work for very small recordings, but beyond that it won’t work. You can use this to move automatically when recording is finished:

https://www.wowza.com/docs/how-to-move-recordings-from-live-streams

Richard

9

You have to use “-2” for the start value for a live stream. Sounds like you did not do that.

Richard

10

Great, thanks for the update. Yes, all streams have to be in same app/instance

Richard

11

I am pretty sure this message concerns vod playback, not live. So something is getting mixed up.

Richard

12

The Application.xml goes below the /conf folder not the /applications folder

Yours should be here:

[wowza-install-dir]/conf/live/Application.xml

Richard

13

I’m seeing this error with a file recorded by Wowza. (MediaReaderFLV.open: Metadata appears to be bad:)

Any thoughts on why that might happen?

Thanks,

Jake

14

No it’s just plain old spark video with nellymoser audio.

I am using this in combination with an s3fs mount. If the file is called something like 1.flv then the file is corrupt… but if I use a word like page.flv the file works fine. So I don’t know exactly where the issue is. If I don’t use s3fs then all works well… so I don’t think it’s a Wowza issue. Strange that if using a number then the file is corrupt.

If there are any ideas why this might happen or how to fix it and still leave the name intact that would be great.

I’ll report back with my future findings.

Thanks,

Jake

15

I am not using the default stream type… but using the live-lowlatency type… which I then use the IMediaStreamActionNotify2 implementation to record the stream. I notice that if I do not try to append onto the end of the file… it records fine. If I specify that the file needs to be appended onto and the file doesn’t exist… it causes a corrupt file to be written.

Jake

16

I am seeing this in the logs… hope it sheds some light on the issue:

2011-09-06 18:41:31 UTC comment server ERROR 500 - getLastTC[1]: java.lang.NullPointerException - - - 298.90

Thanks,

Jake

17

It seems there is a problem with the reading file logic in append mode. I saw this in the IMediaWriter docs:

boolean localAppend = this.parent.isAppend();
if (isFirst)
{
        // determine the staring timecode
        // if we are appending we get it from the existing
        // flv file, if new file its zero
        long startTC = 0;
        if (newFile.exists())
        {
                if (localAppend)
                        startTC = FLVUtils.getLastTC(newFile);
else {
if (versionFile)
        FileUtils.versionFile(newFile);
else

I’m assuming it has something to do with the machine IO or something when operating on that file. I do see in the working directory of s3fs that the file is created and exists with 107 bytes or so… but in the actual s3 repo the file has 0 bytes even though it exists. It isn’t until the whole file is written to disk that it is persisted to s3.

When doing a straight record it records properly… but it must be looking for a file to append onto… and if one doesn’t exist it must put things in a weird state.

Jake

18

Of course if the file didn’t exist… then it shouldn’t try to append onto it… it’s probably hitting some code block I don’t have access to check out. If the file doesn’t exist… then why wouldn’t it default to just a record implementation. In the same code block section as mentioned above it is coded to do just that.

Jake

19

I’m doing this pretty straightforward… but if there is anything I can/should tweak to fix this up please let me know.

LiveStreamRecorder recorder = new LiveStreamRecorder();
		synchronized (recorders)
		{
			LiveStreamRecorder prevRecorder = recorders.get(stream_name);
			if (prevRecorder != null){
				prevRecorder.stopRecording();
			}
			recorders.put(stream_name, recorder);
		}
		// If you want to record data packets
		recorder.setRecordData(true);
		boolean append = true;
		// start recording
		recorder.startRecording(stream, append);
20

Were you recording to an s3fs mounted file system? I found that to be the problem.

I have come up with a work around… by setting the file to record to a local location… and then when done copying it to the s3 repo that wowza is using as it’s content store.

I’d love to just have it work directly with the s3fs mount… but for now I’ve got a bandaid… but any headway on getting it to natively work would be awesome.

Thanks,

Jake