question about metadata output

[flvdude]

Hi,

I have a question about the metadata output for files I am creating.
They are flv files that contain h264 video and mp3 audio. I am
creating the video with x264 and the audio with ffmpeg's mp3 lame
encoder. The keyframe data is confusing me and I am hoping someone
can explain to me what the funny results mean.

here is an example of a keyframe result extracted from the json output
of the metadata:
"keyframes": {
"filepositions": [
547,
609,
1870861
],
"times": [
0,
0,
5.005
]
}

Why are two keyframes at time 0 returned? I notice that they are
about 50 bytes apart. What part of the flv file is represented by the
byte range 547-608? If it is video, why does it have a duration of
zero? Is it an informational packet or something?

[Marc]

> Why are two keyframes at time 0 returned?  I notice that they are
> about 50 bytes apart.  What part of the flv file is represented by the
> byte range 547-608?  If it is video, why does it have a duration of
> zero?  Is it an informational packet or something?

For what I know of the H.264 format, the first tag contains
informations about the stream. I'm using this tag to identify the
video stream resolution (W x H).
It's still a part of the video stream, and the video decoder needs it.

I think there's a limitation in the FLV format itself, because there
aren't many different types of frames (keyframes, interframes,
disposable interframes, generated keyframes, command frames).

FLVmeta just indexes every keyframe (first type) it meets, assuming
they really are keyframes (video frames to which the flash player can
seek).

However, the muxer (I often use ffmpeg to generate FLV files
containing H.264/AAC streams) will write the first frame as a keyframe
without a duration, and the next video frame as a keyframe too,
correctly this time, therefore creating two keyframes at timestamp 0.

I'm not sure it's very important, the flash client will probably
choose the first one it meets in case it's asked to seek at zero.

Regards,
Marc

[flvdude]

Well I didn't mean to imply I thought it was something wrong with
flvmeta. All of the different tools (well I guess I only check
against yamdi this specific time) produce basically the same output.
I was just wondering if you knew what the segment of the file was. I
am working on a flash video player and I was curious about what that
specific part of the video file was because I noticed it on all h264
files I tested. I noticed that the flash byte decoder wouldn't play
without that first segment of the file so I was just trying to find
out more about it.

[Marc]

Yes indeed, I was puzzled too when I first noticed this behaviour, and
flvmeta, yamdi, flvtool++, flvtool2 all output the same keyframe data.

I know you didn't think something was wrong with flvmeta, but I think
I can modify flvmeta to NOT generate more than one keyframe index per
timestamp.
That would actually reduce the output file size by a few bytes, which
would not be a bad thing, after all :)

For what I know, the first tag contains an AVC_SEQUENCE_HEADER with an
AVCDecoderConfigurationRecord, from which I read the first Sequence
Parameter Set.
That's all I know about it :)
The rest of my AVC code is pretty hackish and uses information found
in the doom9 forums and from hints from Dark Shikari himself.

Regards,
Marc

[Marc]

Here is the patch against the trunk:

Index: src/update.c
===================================================================
--- src/update.c (revision 205)
+++ src/update.c (working copy)
@@ -464,13 +464,15 @@

/* add keyframe to list */
if (flv_video_tag_frame_type(vt) ==
FLV_VIDEO_TAG_FRAME_TYPE_KEYFRAME) {
- if (!info->have_keyframes) {
+ /* do not add keyframe if the previous one has the
same timestamp */
+ if (!info->have_keyframes || (info->have_keyframes &&
info->last_keyframe_timestamp != timestamp)) {
info->have_keyframes = 1;
+ info->last_keyframe_timestamp = timestamp;
+ amf_array_push(info->times,
amf_number_new(timestamp / 1000.0));
+ amf_array_push(info->filepositions,
amf_number_new((number64)offset));
+
+
}
- info->last_keyframe_timestamp = timestamp;
- amf_array_push(info->times,
amf_number_new(timestamp / 1000.0));
- amf_array_push(info->filepositions,
amf_number_new((number64)offset));
-
/* is last frame a key frame ? if so, we can seek to
end */
info->can_seek_to_end = 1;
}

[flvdude]

Actually, please do not remove this "feature". At least keep it in as
an optional flag. I am working on a byte range streaming player and
this small info packet turned out to be what I needed to allow
transitioning between files encoded at different bitrates.

I was actually hoping to propose a feature request for flvmeta. I
happened upon this document:
http://help.adobe.com/en_US/FlashMediaServer/3.5_Deving/WS5b3ccc516d4fbf351e63e3d11a0773d56e-7fea.html#WSEC11E19A-4AAC-41cc-96A3-7C93D4593F19
and it states that in order to prevent audio artifacts when swapping
between files that you should make the transition on the audio sample
that immediately preceeds the keyframe that you wish to swap to.
Would it be possible to add an additional array to the keyframes
metadata object that contains the "audio file position" of the sample
before the keyframe at that time if the file hasAudio?

I think that the additional data would allow for near seamless (maybe
even occasionally seamless) transitions using byte range streaming.
This is nice because streaming files in this manner requires no server
side setup. In my particular use case this was a requirement.

Thanks

[flvdude]

By the way... flvmeta is really nice. I like it a lot and am now
using it exclusively over the other tools that are available. I
really appreciate the work you have put in to this project.

On Sep 10, 4:32 am, Marc <marc.noi...@gmail.com> wrote:

[flvdude]

I just saw the commit notes that you use a command line switch to
handle this. Great news. What do you think about the audio sample
byte offset?