Since Voukoder doesn't support WebM or animated WebP, use these formats for transparent video:
## Best Options for Transparent Video in Voukoder:
### 1. **QuickTime (.mov) with PNG codec** (Recommended for lossless)
- In Voukoder's Video settings:
- **Codec**: Select "PNG" (if available) or "QuickTime PNG"
- **Container**: QuickTime (.mov)
- Supports full alpha channel transparency
- Lossless quality
### 2. **QuickTime (.mov) with ProRes 4444** (Best quality/size balance)
- **Codec**: ProRes 4444
- Supports alpha channel
- High quality with good compression
- Widely compatible
### 3. **QuickTime (.mov) with Animation codec** (Lossless alternative)
- **Codec**: Animation
- Full alpha support
- Lossless
- Larger file sizes
### 4. **AVI with PNG or Uncompressed codec**
- If QuickTime isn't available, AVI with PNG or uncompressed codecs can preserve alpha
## Steps in Voukoder:
1. Go to the **Output** tab in Voukoder
2. Set the container to **QuickTime (.mov)** or **AVI**
3. In the **Video** tab → **Encoder** tab, select a codec that supports alpha (PNG, ProRes 4444, or Animation)
4. Ensure your source has an alpha channel (transparent background)
5. Click **Apply** and **OK**
Note: The codec options depend on your Voukoder installation and available encoders. If you don't see PNG or ProRes 4444, check the **Options** or **Side data** tabs for alpha channel settings.
If you share which codecs you see in Voukoder, I can suggest the best option from your list.
---
_**User (2025-12-26 23:26Z)**_
use ffmpeg to re-export rainypet.mov as an animated webp with alpha.
---
_**Agent (model default, mode Agent)**_
---
Checking for `rainypet.mov` and converting it to an animated WebP with alpha using ffmpeg.
Converted `rainypet.mov` to an animated WebP with alpha. The conversion:
- **Input**: ProRes 4444 with alpha (yuva444p12le, 2000x2000, 60 fps)
- **Output**: Animated WebP with alpha (yuva420p)
- **Result**: `rainypet.webp` (5,036 KiB) in the `rainypet` directory
The WebP preserves the alpha channel and loops. The file is ready to use.
---
_**User (2025-12-26 23:26Z)**_
I'm using Shutter Encoder to make it a transparent webm to make things simplest. What does this rainbow artifacting indicate? I keep running into it.
---
_**Agent (model default, mode Agent)**_
---
Rainbow artifacting in transparent WebM usually indicates chroma subsampling or color space conversion issues. Checking the source video properties to diagnose:
| Web Search Results | | Rainbow artifacting in your transparent WebM videos created with Shutter Encoder typically indicates issues related to color space conversion or codec settings during the encoding process. To address this problem, consider the following steps:<br/><br/>1. **Disable GPU Decoding and Filtering**: Some users have reported that disabling GPU decoding and filtering in Shutter Encoder resolves transparency issues. To do this:<br/> - Open Shutter Encoder.<br/> - Go to the "Options" menu.<br/> - Uncheck "Use GPU decoding" and "Use GPU filtering."<br/> - Proceed with your conversion as usual.<br/><br/> This approach has been effective in preserving transparency during WebM exports. ([community.adobe.com](https://community.adobe.com/t5/premiere-pro-discussions/problem-with-export-of-transparent-webm-video/m-p/15222624/highlight/true?utm_source=openai))<br/><br/>2. **Ensure Proper Codec Selection**: When converting videos with transparency, it's crucial to select a codec that supports alpha channels. In Shutter Encoder:<br/> - Choose "VP9" as the codec.<br/> - In the "Advanced Features" section, enable the "Alpha Channel" option.<br/><br/> This configuration helps maintain the transparency of your video. ([support.socialive.us](https://support.socialive.us/support/solutions/articles/67000698528-using-shutter-encoder-to-convert-videos-to-webm-format-to-use-as-overlays?utm_source=openai))<br/><br/>3. **Verify Source File Integrity**: Ensure that your original video file has a proper alpha channel and is free from artifacts. If the source file contains issues, they may persist after conversion.<br/><br/>4. **Update or Reinstall Shutter Encoder**: Software updates can introduce changes that might affect functionality. If you started experiencing issues after an update, consider reinstalling the previous stable version of Shutter Encoder.<br/><br/>By following these steps, you should be able to mitigate the rainbow artifacting in your transparent WebM videos. |
</details>
</tool-use>
---
---
Trying a different approach to check the video properties:
Rainbow artifacting in transparent WebM usually comes from chroma subsampling or color space conversion. Your source is ProRes 4444 (4:4:4, full chroma), and WebM/VP9 often encodes to 4:2:0, which can cause these artifacts.
## Solutions for Shutter Encoder:
### 1. **Force 4:4:4 chroma subsampling**
- In Shutter Encoder, use VP9 with alpha
- In advanced/custom options, add: `-pix_fmt yuva444p` or `-pix_fmt yuva420p`
-`-lag-in-frames 0` - Reduces encoding delay that can affect alpha
The rainbow pattern is likely from chroma subsampling (4:4:4 → 4:2:0) or incorrect color space handling. Ensuring proper pixel format and disabling GPU processing usually resolves it.
---
_**User (2025-12-26 23:26Z)**_
artifacting is the result, rainypet.webm
---
_**Agent (model default, mode Agent)**_
---
Checking `rainypet.webm` and re-encoding with settings that preserve alpha and avoid chroma subsampling artifacts:
Checking the existing WebM file and preparing a fix command. The rainbow artifacting is likely from chroma subsampling or color space conversion. Creating a corrected version:
3. VP9 encoding settings that don't properly handle alpha channels
This command should eliminate the rainbow artifacts while preserving transparency.
---
_**User (2025-12-26 23:26Z)**_
@pwsh (5-69) still busted. it's a problem in the original recode to webm, this re-recode can't get rid of the issue.
---
_**Agent (model default, mode Agent)**_
---
The artifacting was introduced during the initial encode, so re-encoding the WebM won't fix it. We need to encode from the original source with proper color space handling. Checking the source file and trying a better encoding approach:
The source is CineForm (CFHD) with `gbrap12le` (12-bit RGBA). Converting RGB to YUV with chroma subsampling is likely causing the artifacting. Encoding from the original source with better color space handling:
1.**yuva444p** avoids chroma subsampling (4:4:4 instead of 4:2:0)
2.**Explicit format conversion** (`format=gbrap,format=yuva420p`) ensures proper RGB→YUV conversion
3.**Color matrix specification** ensures correct color space handling
Start with the first command (yuva444p). If VP9 doesn't support it, use one of the alternatives. The rainbow artifacting is from improper chroma subsampling during RGB→YUV conversion, so these should fix it.
---
_**User (2025-12-26 23:26Z)**_
@pwsh (70-502) still broken.
---
_**Agent (model default, mode Agent)**_
---
VP9 only supports `yuva420p` (4:2:0), which can cause chroma artifacts. Trying AV1 (libaom-av1), which supports better formats, and a more explicit color space conversion:
<summary>Tool use: **web_search** • Searched web `ffmpeg RGB to YUV conversion rainbow artifacting gbrap yuva420p color matrix fix` • **1** results</summary>
| Title | URL | Chunk |
|-------|-----|-------|
| Web Search Results | | I'm sorry to hear that the previous solutions didn't resolve the rainbow artifacting issue in your WebM file. This problem often arises from chroma subsampling during the conversion process, especially when handling videos with transparency.<br/><br/>**Alternative Approach: Using FFmpeg for Transparent WebM Encoding**<br/><br/>To ensure better control over the encoding process and potentially eliminate the artifacting, you can use FFmpeg directly. Here's how:<br/><br/>1. **Install FFmpeg**: If you haven't already, download and install FFmpeg from the official website: [FFmpeg Downloads](https://ffmpeg.org/download.html).<br/><br/>2. **Open Command Prompt or Terminal**: Navigate to the directory containing your source video file.<br/><br/>3. **Run the Following Command**:<br/><br/> ```bash<br/> ffmpeg -i input.mov -c:v libvpx-vp9 -pix_fmt yuva420p -b:v 0 -crf 30 -g 150 -auto-alt-ref 1 -metadata:s:v:0 alpha_mode="1" output.webm<br/> ```<br/><br/> **Explanation of the Command**:<br/><br/> - `-i input.mov`: Specifies your input file. Replace `input.mov` with the actual filename.<br/><br/> - `-c:v libvpx-vp9`: Sets the video codec to VP9, which supports transparency.<br/><br/> - `-pix_fmt yuva420p`: Specifies the pixel format with an alpha channel.<br/><br/> - `-b:v 0 -crf 30`: Sets the quality of the output. Adjust the CRF value (e.g., 20 for higher quality, 30 for lower) as needed.<br/><br/> - `-g 150`: Sets the GOP size, which can affect quality and file size.<br/><br/> - `-auto-alt-ref 1`: Enables the use of alternate reference frames, improving quality.<br/><br/> - `-metadata:s:v:0 alpha_mode="1"`: Ensures the alpha channel is recognized in the output file.<br/><br/> - `output.webm`: Specifies the name of the output file.<br/><br/>**Additional Tips**:<br/><br/>- **Avoid Chroma Subsampling Issues**: Ensure that the pixel format (`-pix_fmt yuva420p`) is correctly set to handle transparency without introducing artifacts.<br/><br/>- **Disable GPU Processing**: If you're using software that utilizes GPU acceleration, consider disabling it, as GPU processing can sometimes introduce artifacts in videos with transparency.<br/><br/>By using FFmpeg with the above settings, you should achieve a transparent WebM file without the rainbow artifacting. If the issue persists, please provide more details about your source file and the exact steps you're following, so I can offer more targeted assistance. |
</details>
</tool-use>
---
---
Trying a more explicit color space conversion using the `zscale` filter for better RGB→YUV conversion:
The rainbow artifacting is likely from incorrect RGB→YUV color range conversion. Your source is 12-bit RGB (gbrap12le), likely full range. Try these commands:
**Method 1: Using zscale filter (best for color conversion):**
The key is handling the color range (full vs limited). RGB sources are often full range, and the conversion must preserve that. Start with Method 1 (zscale) as it typically handles this best.
If these still show artifacts, the issue may be in Shutter Encoder’s settings. Check:
- Color range settings (full vs limited)
- Color space/color matrix settings
- Disable any automatic color space conversion
Try Method 1 first and let me know if the artifacts persist.
---
_**User (2025-12-26 23:26Z)**_
@pwsh (503-552)
---
_**Agent (model default, mode Agent)**_
---
Fixing the zscale syntax. The matrix parameter format was incorrect. Providing corrected commands:
The zscale error was due to invalid syntax. The colorspace filter (Method 1) is the most reliable for RGB→YUV conversion with proper range handling. The `range=pc` parameter ensures full range RGB is handled correctly.
Try Method 1 first; it should eliminate the rainbow artifacting by properly converting the RGB color space to YUV.
---
_**User (2025-12-26 23:26Z)**_
@pwsh (553-750) they're all broken
---
_**Agent (model default, mode Agent)**_
---
The colorspace filter warning "Input range not set, assuming tv/mpeg" indicates it isn't detecting the input range. Trying explicit input range settings and an alternative approach:
| Web Search Results | | I'm sorry to hear that the previous solutions didn't resolve the rainbow artifacting issue in your transparent WebM exports using Shutter Encoder. This artifacting is often due to chroma subsampling and color space conversion problems during the encoding process.<br/><br/>**Potential Causes:**<br/><br/>1. **Chroma Subsampling:** VP9, the codec used for WebM, typically employs 4:2:0 chroma subsampling, which can lead to color artifacts, especially in areas with sharp color transitions.<br/><br/>2. **Color Space Conversion:** Improper conversion from RGB to YUV color spaces can introduce artifacts if not handled correctly.<br/><br/>**Recommended Solutions:**<br/><br/>1. **Disable GPU Processing in Shutter Encoder:**<br/><br/> Some users have reported that disabling GPU decoding and filtering in Shutter Encoder helps preserve transparency and reduces artifacts. ([community.adobe.com](https://community.adobe.com/t5/premiere-pro-discussions/problem-with-export-of-transparent-webm-video/m-p/15222321/highlight/true?utm_source=openai))<br/><br/> - **Steps:**<br/> - Open Shutter Encoder.<br/> - Go to the "Preferences" or "Settings" menu.<br/> - Locate options related to GPU processing, decoding, or filtering.<br/> - Disable these options.<br/> - Restart Shutter Encoder and attempt the conversion again.<br/><br/>2. **Use Alternative Encoding Tools:**<br/><br/> If the issue persists, consider using other encoding tools that offer more control over color space and chroma subsampling settings. For instance, FFmpeg provides detailed options for handling color spaces and subsampling.<br/><br/> - **FFmpeg Command Example:**<br/><br/> ```bash<br/> ffmpeg -i input.mov -c:v libvpx-vp9 -pix_fmt yuva420p -b:v 0 -crf 30 -g 150 output.webm<br/> ```<br/><br/> - `-pix_fmt yuva420p` ensures the use of a pixel format that supports transparency.<br/> - Adjust `-crf` (constant rate factor) for quality; lower values yield higher quality.<br/> - `-g` sets the GOP (Group of Pictures) size; adjust as needed.<br/><br/>**Additional Considerations:**<br/><br/>- **Software Updates:** Ensure that you're using the latest version of Shutter Encoder, as updates may address known issues.<br/><br/>- **Community Support:** Engage with the Shutter Encoder community or forums for insights and potential solutions from other users who might have faced similar issues.<br/><br/>If these steps don't resolve the artifacting, providing more details about your source file's specifications and the exact settings used during encoding can help in diagnosing the problem more accurately. |
</details>
</tool-use>
---
---
The colorspace filter isn't detecting the input range. Try these with explicit input range settings:
**Method 1: Explicit input range (pc/full range):**
- Using `scale` filter with explicit `in_range=full:out_range=full` parameters
- Adding `flags=accurate_rnd+full_chroma_int` for better chroma handling
- Method 2 converts to 444 first, then subsamples to 420 (may reduce artifacts)
Try Method 1 first. If artifacts persist, it may be a limitation of VP9's 4:2:0 chroma subsampling with RGB sources. In that case, consider AV1 (Method 3) or a different format.
---
_**User (2025-12-26 23:26Z)**_
oh, they've been fine all along, it's just VLC can't read the codec properly.
---
_**Agent (model default, mode Agent)**_
---
The rainbow artifacting was from VLC’s VP9 alpha decoding, not the encodes. This is a known VLC issue with VP9 alpha in WebM.
To verify the files are correct, try:
- Chrome/Edge (good VP9 alpha support)
- Firefox (good VP9 alpha support)
- MPV (better VP9 alpha support than VLC)
- PotPlayer (Windows)
Your WebM files are likely fine. The encodes with proper color space conversion should work in browsers and other players that handle VP9 alpha correctly.
If you need to test in VLC, you could try updating VLC, but browsers are the most reliable for WebM with alpha.
1. Alpha is present (`TAG:alpha_mode=1`), but ffprobe shows `yuv420p` instead of `yuva420p`; the alpha is likely embedded.
2. Color space is `unknown`, which can cause VLC decoding issues.
3. Color range is `tv` (limited), while the source was full range RGB.
The `unknown` color space may be why VLC shows artifacts. The file should work in browsers that handle VP9 alpha. If you want to improve VLC compatibility, you could re-encode with explicit color space metadata, but since browsers work, it may not be necessary.
---
_**User (2025-12-26 23:26Z)**_
output to animated webp?
---
_**Agent (model default, mode Agent)**_
---
Converting `rainypet.webm` to an animated WebP with alpha:
The issue is likely that the WebM→WebP path isn't extracting the alpha channel. Converting from the original MOV (which has proper alpha) should fix it. The `format=yuva420p` filter in the second command forces alpha extraction from the WebM.
Try the first command (from MOV) first; it should produce a proper animated WebP with alpha.
---
_**User (2025-12-26 23:26Z)**_
if ffmpeg can read alpha from a webm, it can output alpha to an animated webp, surely?
---
_**Agent (model default, mode Agent)**_
---
If ffmpeg can read alpha from WebM, it should output it to WebP. The output showed `yuv420p` instead of `yuva420p`, so alpha may be getting dropped. Try explicitly preserving alpha:
The first command uses a filter to force `yuva420p` (with alpha) before encoding. The second explicitly sets the pixel format. Since ffmpeg reads the alpha from WebM (`alpha_mode=1`), one of these should preserve it in the WebP output.
Try Method 1 first; the `format=yuva420p` filter ensures alpha is in the pipeline before encoding.
---
_**User (2025-12-26 23:26Z)**_
@pwsh (802-1053) they're all broken.
---
_**Agent (model default, mode Agent)**_
---
Noting that the last command (line 970) outputs `yuv420p` (no alpha), while the others show `yuva420p` with `alpha_mode=1`. VP9 alpha extraction may be unreliable. Converting directly from the original MOV to ensure alpha is preserved:
Start with the first command (from MOV) for the most reliable result.
---
_**User (2025-12-26 23:26Z)**_
this is from the MOV. @pwsh (991-1053) the output looks fine as a thumbnail but when opened in chrome 1. it's extremely slow 2. the background flashes different shades of gray 3. the frames freak out and leave after images
---
_**Agent (model default, mode Agent)**_
---
The output shows `bgra` (RGB) instead of YUV, and there's a warning about RGB-to-YUV conversion. The frame timing and disposal may also be off. Fixing the encoding:
| Web Search Results | | I understand you're encountering issues when converting your MOV file with an alpha channel to an animated WebP using FFmpeg, resulting in unexpected artifacts such as afterimages and gray frames. This problem often arises due to the complexities involved in handling transparency and color spaces during the conversion process.<br/><br/>**Potential Causes:**<br/><br/>1. **Color Space Conversion Issues:** MOV files with alpha channels are typically in RGB color space, while WebP uses YUV. Improper conversion between these color spaces can lead to artifacts.<br/><br/>2. **Frame Disposal and Timing Settings:** Animated WebP files require precise frame disposal and timing settings. Incorrect configurations can cause frames to overlap or display incorrectly.<br/><br/>**Recommended Solution:**<br/><br/>To address these issues, consider the following approach:<br/><br/>1. **Use the `libwebp_anim` Encoder:**<br/><br/> The `libwebp_anim` encoder in FFmpeg is specifically designed for creating animated WebP files and handles alpha channels more effectively.<br/><br/> **Command:**<br/><br/> ```bash<br/> ffmpeg -i input.mov -c:v libwebp_anim -lossless 1 -loop 0 -preset default -an -vsync 0 output.webp<br/> ```<br/><br/> **Explanation:**<br/><br/> - `-c:v libwebp_anim`: Specifies the use of the `libwebp_anim` encoder.<br/><br/> - `-lossless 1`: Enables lossless encoding, preserving image quality.<br/><br/> - `-loop 0`: Sets the animation to loop indefinitely.<br/><br/> - `-preset default`: Uses the default encoding preset for a balance between speed and quality.<br/><br/> - `-an`: Disables audio processing.<br/><br/> - `-vsync 0`: Disables frame dropping and duplication, maintaining the original frame rate.<br/><br/> This method has been effective for users facing similar issues. ([stackoverflow.com](https://stackoverflow.com/questions/54097180/converting-a-mov-to-webp?utm_source=openai))<br/><br/>**Additional Considerations:**<br/><br/>- **FFmpeg Version:** Ensure you're using an up-to-date version of FFmpeg, as support for animated WebP and related features has improved over time.<br/><br/>- **Alternative Tools:** If issues persist, consider using dedicated tools like [Video2WebP](https://mattj.io/video2webp/), which provides a user-friendly interface for converting videos to animated WebP format.<br/><br/>By following this approach, you should be able to convert your MOV file with an alpha channel to an animated WebP without encountering the artifacts you've described. |
</details>
</tool-use>
---
---
Try these fixes for animated WebP frame issues:
**Method 1: Lossless encoding (recommended for animations):**
-`-fps_mode passthrough` — modern replacement for `-vsync 0`
- Method 3 reduces frame rate to 30fps to cut file size
Start with Method 1 (q:v 70). If it’s still too large, try Method 2 (q:v 60) or Method 3 (30fps). This should reduce the bitrate and improve playback performance.
---
_**User (2025-12-26 23:26Z)**_
@pwsh (928-1053) same result.
---
_**Agent (model default, mode Agent)**_
---
Bitrate is still high (~43 Mbps). At 2000x2000 and 60fps, each frame is large. Reducing resolution and frame rate:
At 2000x2000 and 60fps, the bitrate is too high for smooth playback. Method 3 (1000x1000 at 30fps) should reduce the bitrate significantly and improve playback. Try Method 3 first.
---
_**User (2025-12-26 23:26Z)**_
@pwsh (1006-1053)
---
_**Agent (model default, mode Agent)**_
---
Removing the conflicting `-r` parameter when using `-fps_mode passthrough`:
At 250x250, the bitrate should be much lower and playback should be smooth. The second command also reduces to 30fps for a smaller file.
---
_**User (2025-12-26 23:26Z)**_
the playback issue is fixed. the frames are still leaving afterimages; it's just slapping one frame directly on top of the next, without regard for how the transparency will allow the previous frame to be seen.
---
_**Agent (model default, mode Agent)**_
---
Frames are compositing without proper disposal. Animated WebP may not handle transparent frame disposal well. Trying lossless encoding and checking for disposal-related encoder options:
| Web Search Results | | The issue you're encountering, where previous frames are visible through transparent areas in your animated WebP, is likely due to the frame blending and disposal settings during encoding. In the WebP format, each frame can specify how it blends with the previous frame and how it disposes of itself before the next frame is rendered. If these settings aren't configured correctly, it can result in artifacts where remnants of previous frames are visible.<br/><br/>To address this, you can adjust the blending and disposal methods during the encoding process. FFmpeg's native WebP muxer has had issues with frame blending settings in the past, leading to such artifacts. A patch was proposed to set the blending method to "do not blend" and the disposal method to "do not dispose" to prevent these issues. ([ffmpeg.org](https://ffmpeg.org/pipermail/ffmpeg-devel/2015-June/174631.html?utm_source=openai))<br/><br/>To implement this in your FFmpeg command, you can use the `-disposition` option to set the frame disposal method and the `-blend` option to set the blending method. Here's how you can modify your command:<br/><br/>```bash<br/>ffmpeg -i input.mov -vf "format=yuva420p" -c:v libwebp -disposition:v:0 0 -blend 0 -loop 0 -an output.webp<br/>```<br/><br/>In this command:<br/><br/>- `-disposition:v:0 0` sets the disposal method to "do not dispose."<br/>- `-blend 0` sets the blending method to "do not blend."<br/>- `-loop 0` ensures the animation loops indefinitely.<br/><br/>By explicitly setting these parameters, you can control how each frame interacts with the previous one, preventing the issue of previous frames showing through transparent areas.<br/><br/>If the problem persists, consider updating your FFmpeg to the latest version, as improvements and bug fixes related to WebP encoding have been made over time. Additionally, ensure that your source video has a proper alpha channel and that it's being preserved throughout the encoding process. |
</details>
</tool-use>
---
---
Trying explicit frame disposal settings. WebP animations may not handle transparent frame disposal well. Try these:
Animated WebP has limited frame disposal support for transparency. Method 2 (via GIF) may work better, or consider WebM (Method 4) or APNG (Method 3) for transparent animations. Try Method 1 first; if it still shows afterimages, try Method 2 or 4.
