Video: Remove non-ffmpeg AVI support #118409

Aras Pranckevicius · 2024-02-17T15:46:02+01:00

2024-02-17 15:46:02 +01:00

Blender had a very limited (only uncompressed or MJPEG frames) .avi file support, for both reading and writing. This is something that ffmpeg can fully do.

This is an experiment to remove all of that. 3500 lines of code gone, primary motivations being:

ffmpeg can read and write .avi files just fine, including ones with uncompressed or MJPEG frames.
Blender's ffmpeg integration could also be taught to produce uncompressed or MJPEG .avi files, but TBH I don't see a particular reason to do that. Modern formats like H264 are better in every way, and already support "lossless" option if needed.
Before starting to play back any movie strip within VSE, Blender today first does: 1) check if file exists (~1ms on Windows), 2) check if it's a video file understood by ffmpeg, or by avi (5-10ms), 3) actually open said file, in 99% cases via ffmpeg (5-10ms), 4) start decoding it. Doing steps 2) and 3) together is largely redundant, and removal of separate avi decoding codepath does allow to simplify step 2 a bit, i.e. reduce the stall that happens in VSE whenever a new movie strip starts playing.
The "Lite" blender build configuration was excluding both ffmpeg and avi anyway, so that config is something that can't read nor write any movies.

User visible changes:

In scene image output type, under Video section now there's only Ffmpeg Video (AVI Raw and AVI JPEG are gone)
Whenever loading an existing file, if output was one of AVI Raw / AVI JPEG, it is set to Ffmpeg Video.
- Note: I have not tried to intelligently map previous AVI Raw / AVI Jpeg to some ffmpeg presets, just set to default (h264). Not sure if extra cleverness is needed.

Performance tests: I tested whether there's any measurable performance difference in rendering out a movie with ffmpeg vs the old AVI options. In short, I can't see any. Rendering out 2000 frames of Sprite Fright data set, on Windows/Ryzen5950X, all of these options take ~1 minute. Difference is in file sizes:

AVI RAW: 10301MB
AVI JPEG (default 90 quality): 654MB
ffmpeg H264 (all defaults): 54MB
ffmpeg H264 (lossless, keyframe interval 1): 2235MB

Blender had a very limited (only uncompressed or MJPEG frames) .avi file support, for both reading and writing. This is something that ffmpeg can fully do. This is an experiment to remove all of that. 3500 lines of code gone, primary motivations being: - ffmpeg can read and write .avi files just fine, including ones with uncompressed or MJPEG frames. - Blender's ffmpeg integration could also be taught to produce uncompressed or MJPEG .avi files, but TBH I don't see a particular reason to do that. Modern formats like H264 are better in every way, and already support "lossless" option if needed. - Before starting to play back any movie strip within VSE, Blender today first does: 1) check if file exists (~1ms on Windows), 2) check if it's a video file understood by ffmpeg, or by avi (5-10ms), 3) actually open said file, in 99% cases via ffmpeg (5-10ms), 4) start decoding it. Doing steps 2) and 3) together is largely redundant, and removal of separate avi decoding codepath does allow to simplify step 2 a bit, i.e. reduce the stall that happens in VSE whenever a new movie strip starts playing. - The "Lite" blender build configuration was excluding _both_ ffmpeg and avi anyway, so that config is something that can't read nor write any movies. User visible changes: - In scene image output type, under Video section now there's only Ffmpeg Video (AVI Raw and AVI JPEG are gone) - Whenever loading an existing file, if output was one of AVI Raw / AVI JPEG, it is set to Ffmpeg Video. - Note: I have not tried to intelligently map previous AVI Raw / AVI Jpeg to some ffmpeg presets, just set to default (h264). Not sure if extra cleverness is needed. Performance tests: I tested whether there's any measurable performance difference in rendering out a movie with ffmpeg vs the old AVI options. In short, I can't see any. Rendering out 2000 frames of Sprite Fright data set, on Windows/Ryzen5950X, all of these options take ~1 minute. Difference is in file sizes: - AVI RAW: 10301MB - AVI JPEG (default 90 quality): 654MB - ffmpeg H264 (all defaults): 54MB - ffmpeg H264 (lossless, keyframe interval 1): 2235MB

👀 1 🚀 6

Aras Pranckevicius added 3 commits 2024-02-17 15:46:12 +01:00

3e36ebc6af AVI: remove io/avi source files

05af05643e AVI: remove WITH_AVI code paths

buildbot/vexp-code-patch-linux-x86_64 Build done. Details

buildbot/vexp-code-patch-lint Build done. Details

buildbot/vexp-code-patch-darwin-x86_64 Build done. Details

buildbot/vexp-code-patch-darwin-arm64 Build done. Details

buildbot/vexp-code-patch-windows-amd64 Build done. Details

buildbot/vexp-code-patch-coordinator Build done. Details

f7e1613933 AVI: hide AVI Raw/Jpeg options

Upon older file load, change video output to Ffmpeg video

Aras Pranckevicius added 1 commit 2024-02-17 15:59:24 +01:00

86123bcf81 AVI: fix Linux build

"None" clashes with preprocessor macro defined by X11 headers, so
change that to NotAnim

Aras Pranckevicius added 1 commit 2024-02-17 16:00:57 +01:00

buildbot/vexp-code-patch-lint Build done. Details

buildbot/vexp-code-patch-linux-x86_64 Build done. Details

buildbot/vexp-code-patch-darwin-arm64 Build done. Details

buildbot/vexp-code-patch-darwin-x86_64 Build done. Details

buildbot/vexp-code-patch-windows-amd64 Build done. Details

buildbot/vexp-code-patch-coordinator Build done. Details

13e1c4026d Fix debug build

Aras Pranckevicius added 1 commit 2024-02-17 16:04:43 +01:00

buildbot/vexp-code-patch-lint Build done. Details

buildbot/vexp-code-patch-linux-x86_64 Build done. Details

buildbot/vexp-code-patch-darwin-x86_64 Build done. Details

buildbot/vexp-code-patch-darwin-arm64 Build done. Details

buildbot/vexp-code-patch-windows-amd64 Build done. Details

buildbot/vexp-code-patch-coordinator Build done. Details

556296ed5e Format

Aras Pranckevicius commented

2024-02-17 20:00:46 +01:00

@blender-bot build

Aras Pranckevicius changed title from ~~WIP: Video: Remove non-ffmpeg AVI support~~ to Video: Remove non-ffmpeg AVI support

2024-02-17 20:01:43 +01:00

Aras Pranckevicius added this to the Video Sequencer project 2024-02-17 20:01:54 +01:00

Campbell Barton commented

2024-02-18 23:52:50 +01:00

On balance I'd rather keep this functionality although I realize the case for doing so isn't all that strong.

I think it's good if we can maintain multiple "video" back-ends, it avoids being tied too closely to a single video codec implementation. When we remove a "generalized" interface making it FFMPEG only, typically going back the other way is much more difficult.
I mostly build with FFMPEG disabled, there is some minor benefit in being able to generate and read a "simple" video format.

The multiple back-end argument assumes we might need to add another in the future, or switch away from FFMPEG at some point - neither seem all that likely.

An alternative to your PR could be to set WITH_CODEC_AVI=OFF for release builds, it means we ensure multiple implementations are available and the down-sides you mention for release builds are gone.

Typically the overhead of maintaining additional code would be reason enough to remove code where possible, in practice I don't think this is such an issue for this area of the code.

On balance I'd rather keep this functionality although I realize the case for doing so isn't all that strong. - I think it's good if we can maintain multiple "video" back-ends, it avoids being tied too closely to a single video codec implementation. When we remove a "generalized" interface making it FFMPEG only, typically going back the other way is much more difficult. - I mostly build with FFMPEG disabled, there is some minor benefit in being able to generate and read a "simple" video format. The multiple back-end argument assumes we *might* need to add another in the future, or switch away from FFMPEG at some point - neither seem all that likely. An alternative to your PR could be to set `WITH_CODEC_AVI=OFF` for release builds, it means we ensure multiple implementations are available and the down-sides you mention for release builds are gone. Typically the overhead of maintaining additional code would be reason enough to remove code where possible, in practice I don't think this is such an issue for this area of the code.

Aras Pranckevicius commented

2024-02-19 08:36:32 +01:00

@ideasman42 I guess a counterpoint, is that just because something compiles (i.e. a "different video backend"), does not necessarily mean it actually works. Actual case in point: today, the existing non-ffmpeg AVI reading code, apparently produces garbage: see image, VLC window is how it's supposed to look like, but within blender without ffmpeg it is decoded wrong.

@ideasman42 I guess a counterpoint, is that just because something compiles (i.e. a "different video backend"), does not necessarily mean it actually works. Actual case in point: today, the existing non-ffmpeg AVI reading code, apparently produces garbage: see image, VLC window is how it's supposed to look like, but within blender without ffmpeg it is decoded wrong. ![Clipboard01.png](/attachments/f183aaf4-b344-415d-ad50-315a69f36d63)

Clipboard01.png

127 KiB

❤️ 1

Brecht Van Lommel commented

2024-02-19 13:13:05 +01:00

My vote would be to remove this code. I think the abstraction mainly gets in the way and is not that difficult to restore in the unlikely event we switch to something else than ffmpeg. And leaving this as a feature for developers building without ffmpeg doesn't seem worth it.

👍 2

Sergey Sharybin commented

2024-02-19 15:30:07 +01:00

I am with Brecht here, but from a perspective who was deeper involved into maintenance of video IO: I too think the code is to be removed to simplify maintenance of the code.

I could have been convinced that compiling with FFmpeg could be problematic, but now their API is quite stable, and we do provide precompiled libraries for all platforms. And the cost of the FFmpeg enabled is not that big.

The UI level is also important. I'd rather to have a single Video output option, and make that to work as good as possible than to provide non-obvious choice.

I am with Brecht here, but from a perspective who was deeper involved into maintenance of video IO: I too think the code is to be removed to simplify maintenance of the code. I could have been convinced that compiling with FFmpeg could be problematic, but now their API is quite stable, and we do provide precompiled libraries for all platforms. And the cost of the FFmpeg enabled is not that big. The UI level is also important. I'd rather to have a single Video output option, and make that to work as good as possible than to provide non-obvious choice.

👍 1

Sergey Sharybin approved these changes 2024-02-20 10:34:25 +01:00

Aras Pranckevicius added 1 commit 2024-02-20 13:08:09 +01:00

58c8173c5c Merge branch 'main' into remove_avi

# Conflicts:
#	source/blender/blenloader/intern/versioning_400.cc
#	source/blender/io/avi/intern/avi_mjpeg.cc

Aras Pranckevicius merged commit f09c7dc4ba into main

2024-02-20 13:15:59 +01:00

Aras Pranckevicius referenced this issue from a commit

2024-02-20 13:16:00 +01:00

Video: Remove non-ffmpeg AVI support

Aras Pranckevicius deleted branch remove_avi

2024-02-20 13:16:02 +01:00

Aras Pranckevicius referenced this pull request

2024-03-22 10:41:41 +01:00

Cleanup: Remove unused AviCodecData #119777

Aras Pranckevicius referenced this issue from a commit

2024-03-22 12:18:00 +01:00

Cleanup: Remove unused AviCodecData

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Video: Remove non-ffmpeg AVI support #118409