Tue 02 Dec 2008 03:04:05 PM UTC, comment #14:
Yes, onMetaData handlers are now called by FLVParser also for Gstreamer. So this should be fixed.
|
Tue 02 Dec 2008 02:57:24 PM UTC, comment #13:
Is there a better fix yet?
|
Wed 30 Apr 2008 12:37:43 PM UTC, comment #12:
I'll keep this open to track the "better" fix.
|
Wed 30 Apr 2008 10:09:31 AM UTC, comment #11:
This is non-blocker now, as it doesn't break make check
anymore.
Bjacques: if you don't have reasons to keep open please close.
|
Mon 07 Apr 2008 08:50:51 AM UTC, comment #10:
I've applied the patch to head....
|
Mon 07 Apr 2008 07:57:01 AM UTC, comment #9:
This is back to blocker, as the patch (applied to 0.8.2) was
never applied to head.
Note that the multiple calls bug prevents build slaves
to complete to success on make check, which is annoying.
I'm for applying the hackish patch until bjacques works
out a better one.
|
Tue 29 Jan 2008 11:26:26 PM UTC, comment #8:
Yes, the metadata in an FLV file are the same AMF objects used by RTMP, SharedObject, and LocalConnection. So it should be easily possible to extract the metadata as proper AMF objects for the right handling of each type. LocalConnection also supports a remote function call type of functionality, so it sounds ike FLV metadata does as well.
|
Tue 29 Jan 2008 09:18:51 PM UTC, comment #7:
This patch demonstrates how it's supposed to work. Since onMetaData is only encounted once in the file, this prevents it from being called twice on my system.
However, this is a hackish patch so I won't apply it as is.
(file #14900)
|
Tue 29 Jan 2008 10:01:11 AM UTC, comment #6:
So, to recap:
1) FLV may contain "notify" tags (0x12) with a function name
to be invoked (among others..)
2) Gstreamer handles such tags as generic GST_MESSAGE_TAG
message, dropping the function name information (info loss here)
3) Gnash calls an hard-coded onMetaData function when receiving
GST_MESSAGE_TAG
Now, depending on your gstreamer setup you may get GST_MESSAGE_TAG
messages from other elements of the pipeline, whoever wants to
signal something...
So, to inspect is:
- Whether it's possible to access more info about the message
from within gstreamer (what was the original message including
function name, if needs be?)
That's all.
Possible future improvements:
- Parse the FLV with custom code, probably the RTMP
parser
|
Tue 29 Jan 2008 09:24:34 AM UTC, comment #5:
I did what comment #4 suggests and I confirm an arbitrary
function is invoked...
|
Tue 29 Jan 2008 09:15:25 AM UTC, comment #4:
Tip for next testing (from Company again):
just take an FLV, open it in a hex editor and replace the string "onMetaData" with "HammerTime" and see if adobe's player calls a function named "HammerTime"
|
Tue 29 Jan 2008 09:04:55 AM UTC, comment #3:
Company belives that FLV is just a captured RTMP stream;
and NetConnection is the base RTMP object, being specially
setup for FLV when the constructor argument is NULL
(like handling seeking in a different way).
All speculation, but worth thinking about.
Flvtool might be useful for testing:
http://www.inlet-media.de/flvtool2
|
Tue 29 Jan 2008 09:00:18 AM UTC, comment #2:
This url:
http://osflash.org/documentation/rtmp#rtmp_datatypes
Shows that the FLV tag types are a subset of the RTMP ones:
http://osflash.org/flv#flv_tag
|
Tue 29 Jan 2008 08:53:32 AM UTC, comment #1:
Company reporta that our handing of "metadata" is naive,
in that META tags in the flv are not necessarely just metadata
but can also be function call requests.
He suggests to read more about FLV.
|
Tue 29 Jan 2008 05:06:24 AM UTC, original submission:
Depending on your gstreamer setup, NetStream.onMetaData may be called more than once. For example, in NetStream-SquareTest, the test relies on the fact that onMetaData is called only once. However, this is not guaranteed; onMetaData will simply be called when the video handler decides to check if there is any metadata waiting to be handled.
So the question is: is Gnash's behaviour legal? From the docs I gather that onMetaData will be called before playback (like we do) "as the player encounters onMetaData". But that does not necessarily mean "accumulate and then send".
Does anybody have any thoughts on how we should do this?
|