Issue 32 in flvmeta: allow for correct output metadata (keyframe byte positions) without adding metadata to video file
flv...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 32 by wgordonw1: allow for correct output metadata (keyframe byte
positions) without adding metadata to video file
http://code.google.com/p/flvmeta/issues/detail?id=32
This is more of an enhancement but I do not have the option to set the
issue type.
If you use /dev/null (or your os of choice's equivalent) as your output
file and get the metadata returned from flvmeta using the json/xml/yaml
response the byte positions returned are incorrect because the output is
calculated assuming that the file has the additional metadata bytes.
It would be nice to have a flag that corrects this and does not write the
metadata to the flv file... instead only returning the metadata as flvmeta
output.
This is useful if when storing metadata seperated from the flv file which
allows access to the metadata before downloading the flv file. In this
case writing the metadata to the flv file is redundant and wastes disk
space.
Additionally, it would be even nicer if this mode would also wipe all
existing metadata from the flv file, effectively minimizing the flv
filesize.
flv...@googlecode.com
Status: Accepted
Owner: marc.noirot
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low
Comment #1 on issue 32 by marc.noirot: allow for correct output metadata
(keyframe byte positions) without adding metadata to video file
http://code.google.com/p/flvmeta/issues/detail?id=32
Hmm, yes, the option you're asking for is already there, it's the -D/--dump
command, which does precisely this: dump the existing metadata of the given
input file to stdout. You DO NOT have to specify an output file, since this
command wouldn't use it anyways.
As for removing metadata from the input file, it can indeed be interesting
in some cases, even though I have once remarked that it makes FLV files
unplayable in most video players.
flv...@googlecode.com
Comment #2 on issue 32 by wgordonw1: allow for correct output metadata
http://code.google.com/p/flvmeta/issues/detail?id=32
Keyframe metadata requires the --update option. Also, the --update option
appears to omit the width and height metadata for my test files. I propose
a modification to
the feature request that results in the second cases output, except that it
does not actually write the resulting metadata to the flv file, rather it
only returns the
metadata as json output (or whatever format was specified). The
filepositions array would be different, because the final flv file would
not have the extra metadata
bytes at the beginning of the file, but the rest of the data should be the
same. It should not simply dump the preexisting metadata from the flv,
rather it would
generate and return new flvmeta metadata, but skip writing the new metadata
to file. I will attach a sample file that contains metadata from the first
case for testing.
The way I would imagine the workflow to go is as follows:
1) run the source file through flvmeta using the proposed feature to
remove metadata from the flv file.
2) run the metadataless file through flvmeta to return metadata without
adding metadata to file.
3) store generated metadata seperately from the flv file.
This would allow the metadata to be preloaded before the flv playback
begins so that the player can present the user with details of the video
typically only known
after the flv playback has started.
Since the metadata is know to the player before playback begins, the player
has no need for the metadata to be present in the flv file. The metadata
in the flv file
would be a waste of bandwidth and file storage space.
This example demonstrates that the dump option does not offer the described
functionality:
cmd = '"%s" --all-keyframes --print-metadata
--json "%s"'%(flvmeta_path,flvpath)
"metadata": {
"audiocodecid": 2,
"audiodatarate": 93.75,
"audiosamplerate": 44100,
"audiosamplesize": 16,
"duration": 40.046,
"filesize": 15362806,
"framerate": 1000,
"height": 720,
"stereo": true,
"videocodecid": 7,
"videodatarate": 2968.55078125,
"width": 1280
}
commandline:
cmd = '"%s" --all-keyframes --update --print-metadata
--json "%s"'%(flvmeta_path,flvpath)
"metadata": {
"audiocodecid": 2,
"audiodatarate": 93.8009459949,
"audiodelay": 0,
"audiosamplerate": 44100,
"audiosamplesize": 16,
"audiosize": 498945,
"canSeekToEnd": true,
"cuePoints": [],
"datasize": 1272,
"duration": 40.024,
"filesize": 15363810,
"framerate": 24.0105936438,
"hasAudio": true,
"hasCuePoints": false,
"hasKeyframes": true,
"hasMetadata": true,
"hasVideo": true,
"keyframes": {
"filepositions": [
1262,
1324,
22808,
952771,
2498473,
2768447,
3318220,
4229438,
4923787,
5551343,
6464061,
7366399,
8173405,
8717428,
9151400,
9484216,
10007252,
10442635,
11718508,
12390689,
13076906,
13380694,
13957421,
15363790
],
"times": [
0,
0,
1.334,
3.336,
7.257,
8.258,
9.551,
12.637,
14.347,
16.433,
18.56,
20.479,
22.105,
23.648,
24.608,
25.567,
26.735,
27.819,
30.864,
32.657,
34.826,
35.827,
37.287,
39.998
]
},
"lastkeyframetimestamp": 39.998,
"lasttimestamp": 39.998,
"metadatacreator": "flvmeta 1.1",
"metadatadate": "2010-09-20T13:19:09",
"stereo": true,
"videocodecid": 7,
"videodatarate": 2897.10099721,
"videosize": 14853589
}
The sample file is just a short clip from a tv show. The video was encoded
using x264 and the audio was added via ffmpeg.
Attachments:
55d9ef8b41aec24b9218137d2b1cadf9.flv 2.4 MB
flv...@googlecode.com
Comment #3 on issue 32 by marc.noirot: allow for correct output metadata
http://code.google.com/p/flvmeta/issues/detail?id=32
55d9ef8b41aec24b9218137d2b1cadf9.flv out.flv
{"hasMetadata":true,"hasVideo":true,"hasAudio":true,"duration":40.024,"lasttimestamp":39.998,"lastkeyframetimestamp":39.998,"width":320,"height":176,"videodatarate":391.102838297,"framerate":24.0105936438,"audiodatarate":93.8009459949,"audiosamplerate":44100,"audiosamplesize":16,"stereo":true,"filesize":2525214,"videosize":2015180,"audiosize":498945,"datasize":1085,"metadatacreator":"flvmeta
1.1-r206","metadatadate":"2010-09-21T12:32:00","audiocodecid":2,"videocodecid":7,"audiodelay":0,"canSeekToEnd":true,"hasCuePoints":false,"cuePoints":[],"hasKeyframes":true,"keyframes":{"times":[0,0,1.334,3.336,7.257,8.258,9.551,12.637,14.347,16.433,18.56,20.479,22.105,23.648,24.608,25.567,26.735,27.819,30.864,32.657,34.826,35.827,37.287,39.998],"filepositions":[1075,1136,20039,174935,424350,471592,558118,710270,817510,923506,1071095,1219024,1347065,1433087,1500760,1554366,1640764,1709329,1917793,2026494,2138687,2187542,2282608,2525194]}}
Seems like I can't reproduce the width/height problem with the sample file,
I indeed get 320x176 in the metadata.
> The metadata in the flv file would be a waste of bandwidth and file
> storage space.
well to json, to store the metadata.
Also, if the metadata have to be sent in their own HTTP request, we'll
instead have a bandwidth overhead.
Anyways, I'll try to implement the "--reset" command to remove metadata
from the file.
I can also recommend you another solution that doesn't require a
modification to the source code of flvmeta :
you can use the --full-dump command to get a parseable dump of the file's
tags, and then parse it to generate
metadata, including keyframe indices, which are easy to find from the
XML/YAML/JSON output.
flv...@googlecode.com
Status: WontFix
Comment #4 on issue 32 by marc.noi...@gmail.com: allow for correct output
http://code.google.com/p/flvmeta/issues/detail?id=32
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings