After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 597847 - Windows Media Player won't play large files produced by avimux
Windows Media Player won't play large files produced by avimux
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.14
Other Linux
: Normal normal
: 0.10.17
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-08 19:23 UTC by Tim Crews
Modified: 2009-10-13 15:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim Crews 2009-10-08 19:23:12 UTC
The following issue is observed across multiple versions of GStreamer, starting as early as plugins-good version 0.10.11, and continuing through at least 0.10.14.  I've looked at the changes made between 0.10.14 and (current), and I don't see anything that would affect this issue.

Our development platform is Ubuntu Linux, i386.  The problem exists on at least Hardy and Jaunty.

We have a gstreamer-based application that is making AVI files containing image/x-j2c data in the video stream.  Users play these files on Windows PCs, using Windows Media Player software and the Morgan JPEG2000 codec.

However, if the files exceed 4GB in size, Windows Media Player will not play them.  It complains that it "might not support the file type or might not support the codec".  Under these conditions (as described in the related bug report...), we have them use the so-called "Media Player Classic" media player, which successfully plays the file.

If we use mencoder (based on ffmpeg and libavformat) to re-mux the AVI file, e.g.:
    mencoder large.avi -oac copy -ovc copy -o fixedLarge.avi

the resulting large AVI file plays fine on Windows Media Player.

I have discussed this issue with users "bilboed", "wtay", and "_tim" on the #gstreamer IRC channel, and they requested that I write this bug.  They requested that I attach log file output that comes from the following commands:

<bilboed>	tcrews, produce the log with GST_DEBUG=2,avi*:5 gst-launch-0.10 filesrc location=large.avi ! avidemux ! fakesink > large1.log
<bilboed>	tcrews, produce the log with GST_DEBUG=2,avi*:5 gst-launch-0.10 filesrc location=large.avi ! avidemux ! fakesink 2> large2.log

There were two AVI files that I made to support this bug report
    large.avi -- 4GB file recorded by our application.  Does not play in Windows Media Player
    fixedLarge.avi -- large.avi re-muxed by mencoder as described above.  Plays in WMP.

I ran bilboed's suggested two commands for both files, resulting in
    large1.log - stdout output for large.avi avidemux
    large2.log - stderr output for large.avi avidemux
    fixedLarge1.log - stdout output for fixedLarge.avi avidemux
    fixedLarge2.log - stderr output for fixedLarge.avi avidemux


These log files are found in the attached (15MB) tarball, wmp_issue_logs.tgz. WARNING!  Because these are detailed debug logs for very large AVI files, this tarball expands to about 200MB!  If there is a subset of this data that you want to see, let me know how I should filter the results.

I have also submitted a related issue (...) about files smaller than 4GB not playing under different conditions.
Comment 1 Tim Crews 2009-10-08 19:30:11 UTC
The related issue is https://bugzilla.gnome.org/show_bug.cgi?id=597848.
Comment 2 Tim Crews 2009-10-09 04:08:29 UTC
Sorry, the log files were too large to attach to this bug directly.  They can be found at http://code-affinity.com/wmp_issue_logs.tgz
Comment 3 Wim Taymans 2009-10-13 11:11:56 UTC
There is no special difference in those two logs. Can you see if this improves something:

commit 50110d022d8ad2c17255446c143672ed261efd2f
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Tue Oct 13 13:08:33 2009 +0200

    avi: lower max file size
    
    Make a constant of the max file size and lower the value to what ffmpeg does,
    hopefully improving compatibility with windows media player.
    
    See #597847
Comment 4 Wim Taymans 2009-10-13 12:39:29 UTC
any chance you could upload one of the bad big files? I tried generating some big jp2k files but it will take me ages to generate 5GB with a software encoder.
Comment 5 Wim Taymans 2009-10-13 15:54:32 UTC
I created a 1.2GB gdp payloaded 1280x1024 series of videotestsrc jpeg2000 encoded files. Then I muxed this into avi. The resulting file created an avi superindex and was not playable on WMP. mencoder on the file made it work. Then I started to look at the differences between the working and failing avi. After experimenting with some fields and flags, it seems that WMP needs a valid bufsize in the stream header.

Patch below calculates this buffer size correctly and makes the file play on WMP. Please check if it also works for you, if not, reopen this bug.

commit df0335e65b2fb7113692998f370b7215c7b36dee
Author: Wim Taymans <wim.taymans@collabora.co.uk>
Date:   Tue Oct 13 17:46:22 2009 +0200

    avimux: calculate suggested buffer size
    
    Calculate the suggested buffer size based on the largest chunk in the file.
    
    See #597847