Error encoding flash videos - ERROR org.ffmpeg - [flv @ 0x70790100] Error, Invalid timestamp=280, last=280

[GoogleCodeExporter]

Xuggler fails to encode certain videos on youtube. It logs the above
message indicating an issue with timestamps.

Art had looked at a very similar issue in June, that applied to all video
content at youtube that had H264/ACC video and audio codecs.  The fix
supplied resolved this issue well.  See
http://code.google.com/p/xuggle/issues/detail?id=165  for more details on
this issue.

However I have found a problem with certain other videos from youtube.com,
though these tend to be longer duration videos.  If I was reading off a
stream its normally 6 or more minutes into the video before Xuggler/ffmpeg
hits this issue.

What steps will reproduce the problem?
1. Download the following video content (95MB)
http://www.4shared.com/file/116539940/6d3cdb95/CarRacesANavyFighterJet.html

2. Using the Converter.java program shipped with xuggler try and decode
this video and you will get the above mentioned error.
./src/com/xuggle/xuggler/Converter.java. try and adapt the video bit rate
for example.

Expected output is an encoded flash video file.

Actual output is nothing. No output file is produced as the following error
is logged and program faile.

OS is RHL 5.2. Suns JDK version 1.6.  Applies to 64bit and 32 bit architecture.

Thanks
Declan

Original issue reported on code.google.com by harrison...@gmail.com on 7 Jul 2009 at 3:39

[GoogleCodeExporter]

We'll see what we can do for 3.1

Original comment by art.cla...@gmail.com on 7 Jul 2009 at 3:53

• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Should be fixed in r798.

Nitty gritty detail:

When you set the time base of an IStreamCoder to 1/frame-rate, you have the 
advantage
of working in a time base that most codecs (e.g. WM2) that support that frame 
rate
can work with.

The downside is you need to convert between stream timebases (for example, in 
your
input file the FLV stream has a resolution of 1/1000, but when re-encoding as 
FLV
Converter.java, the frame-rate of the output and hence the encoder's timebase is
1/(29.92)) and rounding can occur.

This resulted in Xuggler eventually getting rounding errors when converting
timestamps, which would eventually lead to Xuggler trying to encode two 
pictures with
the same timestamp -- which MPEG2 encoders generally can't handle.

There are two solutions to the problem:

One, if Xuggler detects that timestamps are going to overlap after conversion, 
it
will drop the second picture.  The change I committed does that.  You can use
IStreamCoder.getNumDroppedFrames() to see how many frames have been dropped 
since the
last call to IStreamCoder.open()

The other work around (to ensure Xuggler-based programs don't drop pictures) is 
to
set your IStreamCoder timebase to the highest resolution timebase your codec can
support (so for FLV, you could set it to 1/1000).  In this case the rescaling 
is a
no-op an no precision is lost.  Converter.java doesn't do this because it has to
encode ANY format to ANY format and so must choose the 
lowest-common-denominator, but
if you know you're always converting to FLV containers with the Screen FLV 
encoder,
you can safely set your IStreamCoder timebase to 1/1000.

I'm sure that didn't make sense, but the result is your test file now 
re-encodes with
Converter.java, although at the expense of having to drop a few frames here and 
there
due to rounding problems (in your test file, about 1 out of 100 frames randomly
interspersed).  See if you notice :)

See here for timebase concepts:
http://wiki.xuggle.com/Concepts

Original comment by art.cla...@gmail.com on 9 Jul 2009 at 12:18

• Changed state: Fixed

[GoogleCodeExporter]

Hi Art

Your explanation makes a lot of sense, I read the Wiki you guys put up that 
helped to
explain what time bases are and how the effect video, it was very helpful.

I will do both of the things you suggest. I will sync down and build the latest 
"tip
of the tree" subversion source tree. I will also explicitly set the timbase for 
my
output flv files to be 1/1000.  My output in this case will always be flv so it
should work well for me.

Thanks
Declan

Original comment by harrison...@gmail.com on 9 Jul 2009 at 8:47