ericmckean / webm

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

Recent builds from git cause Firefox and other applications to not be able to play WebM files #744

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What is the expected behavior? What do you see instead?

Firefox, Totem, and other applications that rely on libvpx should be able to 
play WebM files that they officially have support for.  What happens instead is 
that the video files that would work otherwise are reported by the applications 
to appear broken, corrupted, or otherwise invalid.

What version are you using? On what operating system?

I am running Fedora 20, 64-bit.  Using git bisect, I determined the error was 
introduced in commit a4f30a5023b0216bf3681f87c7f35a8ee09027a4, which was merged 
in commit fb8c246b70d7403c8ef9eb638d4492d7854423cb.  The commit immediately 
before the merge does not cause this problem, while every commit I tried after 
that does.

Can you reproduce using the vpxdec or vpxenc tools? What command line are
you using?

The issue is not present in either vpxenc nor vpxdec, it seems.  I've only seen 
the problem in 3rd-party applications using libvpx.

Please provide any additional information below.

This is the results of git bisect:

[basilgohar@tufaah libvpx]$ time git bisect bad
a4f30a5023b0216bf3681f87c7f35a8ee09027a4 is the first bad commit
commit a4f30a5023b0216bf3681f87c7f35a8ee09027a4
Author: Frank Galligan <fgalligan@google.com>
Date:   Thu Feb 6 17:13:08 2014 -0800

    Add VP9 decoder support for external frame buffers

    Added support for external frame buffers to libvpx's VP9 decoder.
    If the external frame buffer functions are set then libvpx will
    call the get function whenever it needs a new frame buffer to
    decode a frame into. And it will call the release function
    whenever there are no more references to that buffer.

    Change-Id: Id2934d005f606af6e052fb6db0d5b7c02f567522

:040000 040000 7ed368d3360a488b9bc61115a01cac66da39a31d 
8a343d2552beaa6ce8d8c7042a4fd80554ad3605 M      test
:040000 040000 2ca02192b81320ac4749d18f55a94208e8bb2a2b 
765a87a792ee7263e937535e2d42664f09523bfb M      vp8
:040000 040000 608fefd39d007c90350824c4e82ffa153e8e5e59 
eb7c7f86acff26406853a1c7d8dfa1ba0bc38b6e M      vp9
:040000 040000 80d9815f25c2134542c30dba0cbb79529ea1cb3e 
2b55cbcb4a4a6a365069d96d7e7cc1784621c397 M      vpx
:100644 100644 98d1550a5d92073563c758304030c5ada2f65930 
f91d454802d71afdce0ed3c4699a6d6baacfb0bc M      vpxdec.c
real 0.06
user 0.03
sys 0.02

Original issue reported on code.google.com by basilgo...@gmail.com on 25 Mar 2014 at 7:33

GoogleCodeExporter commented 9 years ago
I haven't heard of any other 3rd party apps having an issue. I know it works in 
Chrome and I just tried HEAD (2ec04d1f84aba18359eb28e0f781994aecba3527) with 
ffplay on linux. I also tried fb8c246 with ffplay and didn't have any issues.

Original comment by fgalli...@google.com on 26 Mar 2014 at 5:42

GoogleCodeExporter commented 9 years ago
Are you building and installing libvpx locally and attempting to use it with 
existing applications on fedora? You may be running into this:
https://bugzilla.redhat.com/show_bug.cgi?id=1068664

Original comment by jz...@google.com on 26 Mar 2014 at 6:48

GoogleCodeExporter commented 9 years ago
It seems that libvpx ABI has been broken again without bumping the SONAME: 
http://upstream-tracker.org/versions/libvpx.html

Original comment by smart...@gmail.com on 27 Mar 2014 at 11:40

GoogleCodeExporter commented 9 years ago

Original comment by renganat...@google.com on 3 Apr 2014 at 10:12

GoogleCodeExporter commented 9 years ago
Will be fixed with upcoming release. WontFix because we won't be backporting a 
fix to 1.3.

Original comment by johannko...@google.com on 6 Nov 2014 at 1:08