After FLV passes through flvmeta, the playhead will jump to a specific frame when FLV is paused

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Encode a .mov file to .flv using ffmpeg on the command line, putting one
keyframe per frame.
2. Pass this .flv through flvmeta
3. Now pause the .flv in Wimpy FLV Player
(http://www.wimpyplayer.com/products/wimpy_standalone_flv_player.html)
after playing or scrubbing and the playhead indicator on the bottom will
jump to a specific time each time (though the image will not update). This
can be reproduced in another FLV players, but Wimpy is free.

What is the expected output? What do you see instead?

I'd expect it not to do this.

After pausing for a few seconds, the playhead for the FLV will jump to the
same time each time.  The frame displayed does not update, though.

I first noticed this in my own custom built FLV player using Flex 3.0.2 and
thought it was something in my code, but then notice that other FLV players
would do the same (hence why I tell you to use Wimpy to reproduce the problem).

What version of the product are you using? On what operating system?

Mac OS 10.5, Intel using flvmeta 1.0.7, I've tried multiple FLVs and it
does the same each time, each one's playhead jumping to a specific time
when paused

Please provide any additional information below.

Here are example files:
http://danieldixon.com/forum_posts/before_flvmeta.flv
http://danieldixon.com/forum_posts/after_flvmeta.flv (will jump to frame
278 every time)

Original issue reported on code.google.com by onedans...@gmail.com on 24 Jan 2009 at 5:47

[GoogleCodeExporter]

Just to verify, I took every FLV I tried with flvmeta and ran them through 
Facebook's
flvtool++ and the skipping is now gone. Let me know if I can give you more
information to track down this cause of this issue.

http://danieldixon.com/forum_posts/after_flvtool.flv

Original comment by onedans...@gmail.com on 24 Jan 2009 at 6:46

[GoogleCodeExporter]

I suspect this is a problem related to the handling of the "onLastSecond" 
metadata
tag, because the pausing causes the indicator to skip exactly to the last 
second of
the video when resuming the playback.

I reproduced the problem by using FLVTool2 to inject metadata to the
before_flvmeta.flv file. I expected that result since just like FLVmeta, 
flvtool2
injects the "onLastSecond" event, while flvtool++ does not.

The upcoming 1.1 version of FLVmeta will offer the option to omit the injection 
of
that specific tag, since it seems the only way to avoid this problem.

Strangely, I could only reproduce that odd behaviour with your file, probably 
because
each frame is a keyframe.

Out of sheer curiosity, is there a specific reason you're encoding the file in 
such a
way ? IMHO, using only keyframes kind of defeats the purpose of video 
compression,
because each frame will have to contain all image information, instead of only
differential information as found in interframes.

Could you please give me the exact command-line you use to encode your files 
that way ?

Original comment by marc.noi...@gmail.com on 24 Jan 2009 at 3:20

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Thanks for the quick reply.  I admit the keyframe-per-frame is a unique use 
case, but
it's a requirement for the application I'm working on as the user needs to be 
able to
go frame-by-frame on the media if he desires.  Since you can only seek to whole
keyframes...

Here's the command I'm using (though I don't remember if this was the one used 
for
the example files I gave...I pulled it out from a while ago because I needed
something I could post online):

ffmpeg -i input.mov -g 1 -f flv -s 768x432 -ar 22050 -b 10000000 -r 24 
output.flv

Original comment by onedans...@gmail.com on 24 Jan 2009 at 3:40

[GoogleCodeExporter]

As or r96, the trunk version supports the command-line option -l or 
--no-lastsecond
that omits the insertion of the onLastSecond metadata tag.

You might want to try the latest revision to see whether it fixes that bug.

Original comment by marc.noi...@gmail.com on 4 Jun 2009 at 2:47

• Changed state: Fixed

[GoogleCodeExporter]

All issues are verified in production.

Original comment by marc.noi...@gmail.com on 15 Mar 2010 at 8:53

• Changed state: Verified