Known Participant

Question

Duration metadata in recorded stream incorrect

Forum|Forum|17 years ago
August 1, 2008
8 replies
3897 views

Hi.

I'm streaming live video through FMS 3 and passing the streams to another FMS application to be recorded. While recording, I inject some custom metadata into the stream. Once recording is finished, I move the flv to another location and update my database with the metadata contained in the stream for later reference. All this succeeds without a problem.

However, only sometimes, the default 'duration' metadata (note - I never mess with the duration metadata, merely insert my own fields that are required for other reasons) is COMPLETELY wrong! I know this for a number of reasons:

1 - Another table in my database has information on the duration of the recording via another method, and the metadata in the flv no where near reflects this value
2 - I use Rich FLV ( http://www.richapps.de) to view the metadata and the duration contained in the metadata does not relate to the total time of the movie in these flv's with the corrupt metadata.
3 - The actual length of the movie in seconds is not this number or anywhere NEAR this number.

For instance, I have an flv where the duration metadata is 17023.024 seconds long, which equates to over 4 hours. But according to Rich FLV, the total time is 5 mins 37 seconds. I know this is right, as the actual movie IS 5mins 37 seconds long. I'm assuming that Rich FLV takes the Stream.length(streamname) property for the total time to get this correct value.

When I try and stream the recorded movie later from FMS with an FLV player I made, the total NetStream time is taken from the duration metadata. That means that I'm trying to play a movie that the player thinks is over 4 hours long, but is really only just over 5 minutes long. When seeking past the 5:37 mark, the movie obviously stops and has issues, as there is no movie to actually play! This problem is causing big issues!

I've tried to re-create this issue to try and find a cause, but it just seems random that this happens! But it's not once or twice, or even all the time, - but it is a LOT!

Has anyone seen this before? Is this a known bug with the metadata in FMS??? Are there other bugs that might relate to this?

Any advice / knowlegde appreciated!!

Cheers,
K.

This topic has been closed for replies.

A

Anonymous

hi,

i'm having the same issue here :|

i'm streaming live from fms and recording the live stream on the server at the same time. some metadata are injected into the file as well (not affecting the stream length) but it looks like that randomly, something goes wrong and when playing back a recorded stream, the duration is not correct.

at first i thought it could have been something that had to do with the netstream not being closed correctly once finished recording or some bug i missed along the way but, after months of head banging on my keyboard and various recoding of the app, i eventually came up to this post (i wish i had found it earlier on...).

i realised that something was wrong and not depending on the code, by checking the file size of the recorded stream on the server soon after recording ended and soon after playback began: file size didn't change but stream duration was up to 12 minutes or so, sometimes 5 minutes, some other times 20 minutes ... this doesn't always happen and occurs 'only' few times but unfortunately i can't consider it as a sort of 'solution' to the problem.

the last post is dated 'Nov 7, 2008' so, a bit 'dated'. i hope this problem has been solved by adobe or someone else because it would be really 'sour' to have to rebuild the entire app or throw it away, after years of work, just because something is not working properly and the issue is not dependent on the code...

thanks in advance

gg

G

Gipoh

Known Participant

Hi karnal69,
I will try some things myself to see if I can get it to work. I will let you know if it works out.

Creation site internet | Radin | Jeux Concours | Echantillons

Kristian WrightAuthor

Known Participant

Hi!

I'm still having MAJOR issues with metadata!! I can insert custom metadata into my live stream on an onPublish event, and it works most of the time. But for the times it does not work, I try and add it again later, maybe 2 minutes into the streaming. The ns.send("@setDataFrame", "onMetaData", objMetadata) ALWAYS returns 'true', but the metadata is NEVER there!!

I've done some tests with only sending 1/2 of the metadata I want into the stream, then trying to send all of the metadata later into the stream a minute or 2 later. The 1/2 that I send on the onPublish event is always there, but the rest of the metadata on the second insert is NEVER there! I've also tried to clear the metadata before trying to insert it again with ns.send("@clearDataFrame", "onMetaData"), which returns 'true' as well indicating a successful clear, but I see on the client that the partial metadata I first sent IS STILL THERE!!! It is NEVER cleared!! Also, the 'full' metadata I sent after the clear is not there, even though it says that the insert was successful. I'm left with my 1/2 metadata I initially sent, which should never happen!

So essentially my situation is that I can never add metadata to a live stream a short time-span after it initially publishes, and I can never clear what is there!!

What the hell is going on??!!!

Can anyone help me here? Does anyone have any idea on what's going on??

Thanks in advance,
K.

B

bswett

Participant

I'm noticing this problem too. I have a video that is around 75-80 seconds. Its duration is reported as 180 seconds.

Did you ever find a solution to the problem?

B

bswett

Participant

I found the answer in my case... I was recording and playing multiple videos on the same stream. Apparently that really is a bad idea.

Kristian WrightAuthor

Known Participant

Another point to note is that once I start publishing to the recording app, I get the metadata of the stream with

objMetadata = Stream.getOnMetaData("streamname");

and trace the properties of the objMetadata object every 1/2 second (this is purely for debugging purposes while I work out what the hell is going on). But for around the first 30 seconds, nothing is output! Then all of a sudden, the output starts tracing to screen. IF my customduration metadata is there, it has its initial value as indicated in my post above (for example 7), and never increments. But more interestingly, the duration metadata that FMS automatically inserts might say 39.076 once the traces start coming through! So I would at least think that my customduration would be around 39 give or take. Also the FMS duration says 39.076, but then it stays at the same value for a while, even though it's being traced every 1/2 a second, then it might say 71.200, then stays the same for about 30 seconds, then 104.863 and so on.

This makes sense if this is only being updated in memory every 30 seconds or so (the docs state that the 'data keyframe is a special data message that can be added to a live stream and stored in the memory of the server'), but then it also means that when reading it, we will never know if this is actually correct! I mean if I connect and get the metadata and the duration says 71, I'm going to assume that I connected to the live stream 71 seconds in, but it could have been saying 71 for the past 20 seconds, and I'm really 91 seconds into the live stream!

K.

Kristian WrightAuthor

Known Participant

UPDATE:

Unfortunately I can't seem to recreate the duration metadata error with my debug app - it just truly seems random!!

So as a work-around I'm setting a timer to run every second and add a new customduration metadata field. But sometimes this 'works' and sometimes no metadata at all is inserted. And when I say 'works', I mean it does insert something SOMETIMES, but only once at a seemingly random time! My insertion function could run for 130 times say, each time the ns.send("@setDataFrame", "onMetaData", objMetadata) returns true indicating to me a successful insertion, but the onMetadata at the other end might give me the customduration metadata as 7 instead of 130!! It seems it only gets inserted once and ALWAYS under 10 seconds... If it ever even gets inserted at all!!

I think I'm officially going insane...

K.

Kristian WrightAuthor

Known Participant

I've tried FLVCheck but it's giving me the same issues.

When using the -d 0 parameter, the check says 'passed', but I know this is wrong. Also, I tried -m to fix corrupt metadata and a new file was created. This indicated to me that there WAS an issue with the metadata, and this was now fixed. When checking the metadata in the original and the new file, they were both the same, corrupt number - no change! Repeated attempts with the -m parameter made no additional copy, so FLVCheck thinks that the metadata is correct! But the timer on my player takes the total time from the metadata, and it says 4 hours 43 mins (17023.024 seconds), but again, when playing it through till the end, it stops at 5 mins 37 seconds (337 seconds), which is the REAL duration of the flv.

A difference of 1 or 2 seconds might be acceptable, but a difference of 16,686 seconds simply is not.

So it seems that FLVCheck can neither detect this properly, nor fix it... Even if it could fix it, it would be a workaround that would be a lot of overhead to check each one (I'm creating over 100 flv's per day), correct if required etc. And this never solves the reason of WHY this is happening in the first place!

This is a serious issue/bug, as if the default metadata inserted by FMS cannot be trusted, or even detected and fixed by other Adobe tools that are designed for that sole purpose, that brings serious doubts into the value of this product!

K.

A

Anonymous

Try using FLVCheckTool.exe to fix metadata. Documents link indicate that it can fix metadata tag.
http://livedocs.adobe.com/flashmediaserver/3.0/docs/help.html?content=06_admintasks_11.html

I hope it helps.

O

osipls

Participating Frequently

Could you record stream without injecting custom metadata and check duration in this case? Do you still have same issue? Thanks

Kristian WrightAuthor

Known Participant

Unfortunately no - this is in a live production environment at them moment and we must have the metadata embedded in the stream. We didn't notice this issue in testing before release as it does not occur much. In the time I wrote my original posting to the time of this one, we've recorded over 50 streams with the custom metadata and they all have the correct duration. So I don't think that the custom metadata is the cause - otherwise we'd be getting this issue every time. But I'm pretty sure within the next day or so, at least 1 will come through with all metadata fields correct except for the duration.

A point a colleague mentioned was that sometimes we don't just record a stream, but append to a previous recording. I'm unsure at this stage if the flv's with the corrupt duration are in fact streams that were appended together, but I'm going to put more debugging in to see if this is the case. I'll keep this thread updated on the results.

But for now, it's still causing issues...

Cheers,
K.

Kristian WrightAuthor

Known Participant

UPDATE:

I've tried to get the length of the flv by Stream.length("filename") but it seems that this gives me the duration metadata!! Again I know this is wrong, as Stream.length("filename") gives me the EXACT value as the metadata, even though we know this is wrong. Thinking about it, it seems that RichFLV simply loads the entire flv into the application and can get the duration from there, hence giving me the right duration. However this is totally inappropriate for a live, on-demand streaming environment, where my flv's can be over 1 hour.

I've still not debugged the reason as to WHY this is happening at all, but it looks like I'm going to have to write a new application and try and 'break' it and see if I can recreate this, and send it off to Adobe.

Speaking of Adobe, I understand that this is not their official support forum and this is intended for end user discussion, but does NO-ONE at Adobe ever read these threads? Surely this would be a great way to find/track bugs etc, as we seem to have here.....

K.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded