alfianrahmn / xuggle

Automatically exported from code.google.com/p/xuggle
0 stars 0 forks source link

Youtube downloaded videos do not decode correctly #165

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
From declan <harrison.declan (at) googlemail.com>:
Hi Art

Im using xuggler-3 which I downloaded last week.

You can replicate this issue by downloading the following flash video
from
http://www.4shared.com/file/112875794/22e6627e/BritishIrishLionsVsSouthernKings.
html
.   Ive only set up this file sharing account today so I hope you can
access it ok.

This video came from youtube.com today; though most of the youtube
videos appear to cause the same effect.

As for soruce code. I was able to reproduce this issue using the
sample Converter.java demo program that comes with xuggler.  If you
could use that you should see this issue "ERROR org.ffmpeg - [flv @
0x3446c30] Error, Invalid timestamp=1, last=3"

Original issue reported on code.google.com by art.cla...@gmail.com on 19 Jun 2009 at 4:23

GoogleCodeExporter commented 8 years ago
The root issue is that when decoding libav doesn't return the correct
opaque_reordered context.  It works in ffmpeg.c because it doesn't use
opaque_reordered, and it works in ffplay because ffplay just displays, but 
doesn't
re-encode the data.

Workaround is hard -- this file is just lying about the packet (perhaps 
deliberate
Youtube obsfucation), but we may be able to programatically detect this.

Original comment by art.cla...@gmail.com on 19 Jun 2009 at 4:25

GoogleCodeExporter commented 8 years ago
Fixed in r700 (I think -- still need to wait for exhaustive suite to finish).

Here's the problem: Youtube is incorrectly setting the H264 timestamps on 
packets,
and then libav is getting confused.

The workaround: If for some reason the opaque pts returned from libav is LESS 
than
our calculated next timestamp, then we assume we've hit this bug and instead 
use the
packet pts.  Seems to pass all tests, but we may need to special case the check 
to
only FLV containers if it trips up other formats.

Declan, can you verify the fix works for you?

Original comment by art.cla...@gmail.com on 19 Jun 2009 at 5:40

GoogleCodeExporter commented 8 years ago
Hi Art 

I would be glad to take this fix and verify it.

Do I need to download and build the source code as specified here 
http://www.xuggle.com/xuggler/downloads/build.jsp.

So I need to take the latest source tree from subversion svn checkout 
http://xuggle.googlecode.com/svn/trunk/java/xuggle-xuggler xuggle-xuggler

I will get started on this now and get back to run when I have run some tests 
on the 
specific videos.

Declan

Original comment by harrison...@gmail.com on 19 Jun 2009 at 9:35

GoogleCodeExporter commented 8 years ago
Hi Art

I downloaded and built the latest version of the source code on RHL5, without 
any issues.

Verified this fix by testing against a few of the youtube.com flash videos that 
I had
downloaded previously. I was able to decode and encode these videos without 
issues. 
I also verified that other flash videos (non youtube.com ones) were still able 
to be
encoded.

This fix looks good to me.

Thanks again for sorting this out so quickly.

Declan

Original comment by harrison...@gmail.com on 19 Jun 2009 at 11:04