[gstreamer-bugs] [Bug 601236] [flvmux] script tag with index gets written at end of file, contains all tags

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Thu Nov 12 02:14:20 PST 2009


https://bugzilla.gnome.org/show_bug.cgi?id=601236
  GStreamer | gst-plugins-good | git

--- Comment #3 from Jan <wulczer at wulczer.org> 2009-11-12 10:14:15 UTC ---
So I have a preliminary patch that reserves enough space in the metadata to
write 128 index entries (the current code never writes more than 128 index
entries, so it seemed like a good constant). 128 keyframes is not a lot, but if
you don't want to rewrite the whole file, you need to put the limit somewhere.

After eos, the muxer would seek to the appropriate position in the metadata (by
sending a BYTES new segment - logic copied from avimux), write the index and
fill in the remaining space (if there's any) with a filler, like a
"ROAAA...RGH" string entry, in the onMetaData script tag.

The fact the in my current patch it *is* using that string is one of the
reasons I'm not attaching it yet ;) Anyone has a better idea for a sciprt tag
filler?

There's a problem that if downstream doesn't accept the new segment (think live
streaming), the consumer will see a giant ROAAARGH property in the metadata. Of
course this can be thought of as acceptable (and the muxer could get a property
disabling any index writing logic whatsoever).

All that's a bit kludgy, I'm not sure if it's worth it at all if there are
numerous 3rd party tools to index FLV files. I would go as far as suggest to
make the property that disables index writing default to true and if someone
really wants to have an index (with at most 128 entries!) and a silly filler
string written out by gst, let them enable it.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.




More information about the Gstreamer-bugs mailing list