avi files >1G do not seek with WMP

[Carl Eugen Hoyos]

(bug 194)
If an avi output file is bigger than ~1G, the file starts to play fine with WMP, but seeking is impossible, this works fine if the file is remuxed with MEncoder.

The following file plays fine with WMP, seeking works as expected:

$ ffmpeg -f lavfi -i testsrc=s=pal -f s16le -ac 2 -ar 48k -i /dev/zero -vcodec dvvideo -acodec pcm_s16le -fs 900M out09.avi

The following file also plays fine with WMP, playback stops when the user tries to seek:

$ ffmpeg -f lavfi -i testsrc=s=pal -f s16le -ac 2 -ar 48k -i /dev/zero -vcodec dvvideo -acodec pcm_s16le -fs 1100M out11.avi
ffmpeg version N-48954-g06af724 Copyright (c) 2000-2013 the FFmpeg developers
  built on Jan 16 2013 12:08:10 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --disable-indev=jack
  libavutil      52. 15.100 / 52. 15.100
  libavcodec     54. 89.100 / 54. 89.100
  libavformat    54. 60.101 / 54. 60.101
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter     3. 32.100 /  3. 32.100
  libswscale      2.  1.103 /  2.  1.103
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[lavfi @ 0x2539940] Estimating duration from bitrate, this may be inaccurate
Input #0, lavfi, from 'testsrc=s=pal':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 720x576 [SAR 1:1 DAR 5:4], 25 tbr, 25 tbn, 25 tbc
[s16le @ 0x253b0c0] max_analyze_duration 5000000 reached at 5013333 microseconds
[s16le @ 0x253b0c0] Estimating duration from bitrate, this may be inaccurate
Guessed Channel Layout for  Input Stream #1.0 : stereo
Input #1, s16le, from '/dev/zero':
  Duration: N/A, bitrate: 1536 kb/s
    Stream #1:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Output #0, avi, to 'out11.avi':
  Metadata:
    ISFT            : Lavf54.60.101
    Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv420p, 720x576 [SAR 1:1 DAR 5:4], q=2-31, 200 kb/s, 25 tbn, 25 tbc
    Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> dvvideo)
  Stream #1:0 -> #0:1 (pcm_s16le -> pcm_s16le)
Press [q] to stop, [?] for help
frame= 7248 fps=431 q=0.0 Lsize= 1074263kB time=00:04:49.92 bitrate=30354.5kbits/s
video:1019250kB audio:54360kB subtitle:0 global headers:0kB muxing overhead 0.060863%

The file can be "fixed" with the following MEncoder command line:

$ mencoder out11.avi -ovc copy -oac copy -o outmenc.avi

[tateu]

I don't know if it's the same issue as I am having, it sounds similar. I cannot even open AVI's > 1GB in Windows Media Player if they are bgr24 rawvideo. I have found a fix for my issue. On line 270 of libavformat/avienc.c it currently says "/* suggested buffer size */ FIXME set at the end to largest chunk" but no one has ever added the FIXME.

I've attached two patches which work for me. The first one I think is definitely needed and changes the dwSuggestedBufferSize attribute of the strh header. The 2nd one doesn't seem 100% necessary but it sets the dwMaxBytesPerSec and dwSuggestedBufferSize attributes of the avih header to 0. VirtualDub and Mencoder both set this dwSuggestedBufferSize attribute to 0. VirtualDub sets this dwMaxBytesPerSec attribute to a value very close to (strh->dwSuggestedBufferSize * frame_rate) and Mencoder sets it to 0.

[Carl Eugen Hoyos]

Please send patches to ffmpeg-devel, they receive more attention there.

[Carl Eugen Hoyos]

Replying to tateu:

I don't know if it's the same issue as I am having, it sounds similar. I cannot even open AVI's > 1GB in Windows Media Player if they are bgr24 rawvideo.

I tested the following command line:
$ ffmpeg -f lavfi -i testsrc -vcodec rawvideo -pix_fmt bgr24 -fs 1100M out.avi
The output file plays fine with Windows Media Player.
Please provide your failing command line together with the complete, uncut console output.

[Carl Eugen Hoyos]

The original problem is only reproducible with pcm audio, if ac3 (or mp2) encoding or no audio is selected, seeking with WMP works fine.

[tateu]

ffmpeg -f lavfi -i testsrc=size=1280x720 -vcodec rawvideo -pix_fmt bgr24 -fs 1100M out.avi

To see the issue I am talking about, individual frame sizes need to be larger than the default value that FFMpeg uses for strh->dwSuggestedBufferSize, which is 1,048,576 bytes. Your command line produces a 320x240 file and each frame is only 230,400 bytes (320 * 240 * 3). testsrc=size=1280x720 produces a file where each frame is 2,764,800 bytes. You also need to disable any 3rd party AVI directshow splitters to make sure it is only a vanilla Windows Media Player attempting to play the file. Haali media splitter can take over from Windows and make the file playable.

My issue seems to be slightly different than yours, then. I had tried your example without audio since I'm on Windows and don't have -i /dev/zero as an input source. My patch fixes my issue but does not fix yours.

[Carl Eugen Hoyos]

Replying to tateu:

My issue seems to be slightly different than yours, then. I had tried your example without audio since I'm on Windows and don't have -i /dev/zero as an input source.

You can use the following command line to produce video and audio:
$ ffmpeg -f lavfi -i testsrc -f lavfi -i "aevalsrc=sin(2*PI*t*440)"

My patch fixes my issue but does not fix yours.

Please post your patch to ffmpeg-devel (alternatively, you can open a new ticket, but it makes more sense to fix it).

[rupa]

Replying to cehoyos:
I am also facing similar issue when I try to play the AVI files that are bigger than 1 GB in Windows Media Player.
My AVI files have following configuration:
-MJPEG Video 960x720@26fps
-PCM Audio 16 bits/16KHz/1 channel
Please let me know if there is any fix available for this issue ?

(bug 194)
If an avi output file is bigger than ~1G, the file starts to play fine with WMP, but seeking is impossible, this works fine if the file is remuxed with MEncoder.

The following file plays fine with WMP, seeking works as expected:

$ ffmpeg -f lavfi -i testsrc=s=pal -f s16le -ac 2 -ar 48k -i /dev/zero -vcodec dvvideo -acodec pcm_s16le -fs 900M out09.avi

The following file also plays fine with WMP, playback stops when the user tries to seek:

$ ffmpeg -f lavfi -i testsrc=s=pal -f s16le -ac 2 -ar 48k -i /dev/zero -vcodec dvvideo -acodec pcm_s16le -fs 1100M out11.avi
ffmpeg version N-48954-g06af724 Copyright (c) 2000-2013 the FFmpeg developers
  built on Jan 16 2013 12:08:10 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --disable-indev=jack
  libavutil      52. 15.100 / 52. 15.100
  libavcodec     54. 89.100 / 54. 89.100
  libavformat    54. 60.101 / 54. 60.101
  libavdevice    54.  3.102 / 54.  3.102
  libavfilter     3. 32.100 /  3. 32.100
  libswscale      2.  1.103 /  2.  1.103
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
[lavfi @ 0x2539940] Estimating duration from bitrate, this may be inaccurate
Input #0, lavfi, from 'testsrc=s=pal':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 720x576 [SAR 1:1 DAR 5:4], 25 tbr, 25 tbn, 25 tbc
[s16le @ 0x253b0c0] max_analyze_duration 5000000 reached at 5013333 microseconds
[s16le @ 0x253b0c0] Estimating duration from bitrate, this may be inaccurate
Guessed Channel Layout for  Input Stream #1.0 : stereo
Input #1, s16le, from '/dev/zero':
  Duration: N/A, bitrate: 1536 kb/s
    Stream #1:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
Output #0, avi, to 'out11.avi':
  Metadata:
    ISFT            : Lavf54.60.101
    Stream #0:0: Video: dvvideo (dvsd / 0x64737664), yuv420p, 720x576 [SAR 1:1 DAR 5:4], q=2-31, 200 kb/s, 25 tbn, 25 tbc
    Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo -> dvvideo)
  Stream #1:0 -> #0:1 (pcm_s16le -> pcm_s16le)
Press [q] to stop, [?] for help
frame= 7248 fps=431 q=0.0 Lsize= 1074263kB time=00:04:49.92 bitrate=30354.5kbits/s
video:1019250kB audio:54360kB subtitle:0 global headers:0kB muxing overhead 0.060863%

The file can be "fixed" with the following MEncoder command line:

$ mencoder out11.avi -ovc copy -oac copy -o outmenc.avi

[Carl Eugen Hoyos]

The issue with dwSuggestedBufferSize should be fixed since e705d0ce

[mahesh]

Replying to cehoyos:

I am also facing the same issue. I have tested with latest release version ffmpeg-20140520-git-7d25af1-win32.

Please suggest how to get the fixed source code.

I have used the following command:

"ffmpeg -f dshow -i audio="Microphone (High Definition Aud" -f dshow -i video="USB 2.0 Camera" -r 26 -s 960x720 -vcodec mjpeg -acodec pcm_s16le -ac 1 -ar 16000 test.avi" 

"The issue with dwSuggestedBufferSize should be fixed since e705d0ce" what this indicate ? "e705d0ce" Is it a latest version or allready released version ?
Please clarify ASAP

[Carl Eugen Hoyos]

Regression since e738cee9

[marksfink]

I'm on g4160900 and I'm still seeing this issue. Any AVI file with PCM audio greater than 1G in size stops playing at the 1GB point in WMP. I can move the slider bar past the fail point and it will resume play until 2GB, and fails, I move the slider bar past that and it resumes play, etc.

Something is still wrong here.

[marksfink]

Correction: mencoder remuxing does not work! The failure occurs at a slightly different place in the video -- close to the same spot but not quite which is why I missed it earlier. Bottom line: I'm seeing the same issue with mencoder AVI files.

When I create AVI files with VirtualDub, they play fine in WMP; however they show index errors in other software. Ffmpeg files show no errors, but they don't play fully in WMP (if they are > 1GB). Ironic!

[marksfink]

I resolved the issue by installing LAVFilters and using its AVI splitter instead.

I created a graph in Graphedit. The Microsoft AVI splitter fails at the 1GB points. The LAV AVI splitter works fine. Also the AVISource filter in AVISynth works fine. So my best guess is that this is an issue with the MS AVI splitter, but if there is anything that could be done to produce clean AVI files that also work with MS's AVI splitter, it would be "nice".

[Elon Musk]

Does this still happens?

[Michael Niedermayer]

No reply in 3 month, thus assuming it was fixed, please reopen if its not fixed

[Carl Eugen Hoyos]

Fixed by Tobias Rapp in b4fbad2634c4f9d094dbe000c794fa277ecd678e