iPhone 16 Pro and Pro Max compression issues

[paulsizer]

Current behavior

I seem to be having issues compressing videos recorded on iPhone 16 Pro and 16 Pro Max devices that are in the high efficiency setting for capturing video. This videos are in a .mov video file.

If I record a video on my iPhone 14 Pro the video compresses as normal but when testing with a video recorded on the 16 Pro models and trying to compress it results in the exact same file being returned.

 LOG  video_uri file:///Users/paul/Library/Developer/CoreSimulator/Devices/E1C94F32-6F84-4F57-81F3-A319169E3518/data/Containers/Data/Application/ECA070E0-4A5D-4BFA-8417-E22FBBEFFBBE/Library/Caches/ImagePicker/D3444CB1-7380-424B-ACBB-B55682266498.mov
 LOG  size 73619152
 LOG  compressedVideo file:///Users/paul/Library/Developer/CoreSimulator/Devices/E1C94F32-6F84-4F57-81F3-A319169E3518/data/Containers/Data/Application/ECA070E0-4A5D-4BFA-8417-E22FBBEFFBBE/Documents/D3444CB1-7380-424B-ACBB-B55682266498.mov
 LOG  compressedSize 73619152

Expected behavior

The file compresses to a MP4 file

Platform

• iOS

React Native Version

0.74.1

React Native Compressor Version

1.9.0

Reproducible Steps And Demo

import { Video } from 'react-native-compressor';
import * as FileSystem from 'expo-file-system';

export const compressVideo = async (video_uri, onProgress) => {
  const uriParts = video_uri.split('/');
  const filename = uriParts[uriParts.length - 1];

  const newUri = `${FileSystem.documentDirectory}${filename}`;
  await FileSystem.copyAsync({
    from: video_uri,
    to: newUri,
  });
  const { size } = await FileSystem.getInfoAsync(video_uri);
  console.log('video_uri', video_uri);
  console.log('size', size);

  const compressedVideo = await Video.compress(
    newUri,
    { compressionMethod: 'manual',
      progressDivider: 10,
      minimumFileSizeForCompress: 1,
      maxFileSizeForCompress: 100,
      bitrateMultiplier: 0.8,
      compressQuality: 'medium', },
    (progress) => {
      const progressPercentage = parseInt(progress * 100);
      onProgress(progressPercentage);
    }
  );

  const { size: compressedSize } = await FileSystem.getInfoAsync(compressedVideo);
  console.log('compressedVideo', compressedVideo);
  console.log('compressedSize', compressedSize);


  return compressedVideo;
};

[github-actions]

👋 @paulsizer
Thanks for opening your issue here! If you find this package useful hit the star🌟!

[mbiang]

I too am seeing this bug on iOS devices. The compressor (version 1.9.0) is returning the original uncompressed URL.

Here is the code I am using:

compressorResult = await VideoCompressor.compress(
  uri,
  { compressionMethod: 'auto' },
  progress => {
    if (!isExpoGo && SHOW_PROGRESS) {
      this.setState({ currentProgress: progress });
    }
  },
);

[paulsizer]

Any help with this and how to go about fixing this? Seems to be mostly happening with iPhone 16 users on my end.

[paulsizer]

@numandev1 Any info on this?

[cmlad]

Same issue here, I get a few progress updates, up to like 0.008, and then it returns the original URI no matter what params I use. It doesn't matter if I use HEVC or H264. Using 16 Pro Max.

With an XS Pro Max things work.

[yuriiburov]

the same here
also happens on iPad 10th generation
"react-native-compressor": "^1.9.0",
"react-native": "0.75.4"

[LazyGeniuss]

I had the same issue. I converted the file to MP4 format using ffmpeg-kit-react-native and then compressed it, and it worked.

[paulsizer]

@LazyGeniuss I did the same in the end and used ffmpeg-kit-react-native for conversion and compression.

[paulsizer]

@LazyGeniuss What were your params for ffmpeg-kit-react-native? Could you share?

[LazyGeniuss]

@paulsizer I used this command as this single command handle both compression and conversion.

-i ${inputFile} -c:v mpeg4 -crf 40 -preset slow ${outputFile}.

Before executing this command you have create a outputFile with mp4 extension.

For detailed explanation about each param you can to https://transloadit.com/devtips/reducing-video-file-size-with-ffmpeg-for-web-optimization/

[LazyGeniuss]

I dug further into this issue and found that this library uses NextLevelSessionExporter under the hood, which is unable to process the APAC audio codec. The following comment provides the fix for the problem.

NextLevel/NextLevelSessionExporter#49 (comment)

[numandev1]

@LazyGeniuss can you make a pull request for this fix?

[numandev1]

@LazyGeniuss let me make PR for it

[numandev1]

@paulsizer @LazyGeniuss could someone check if this issue is fixed in 1.10.1-alpha.0 or not, so I can release proper version after verification

[LazyGeniuss]

@numandev1 It works.

[numandev1]

v1.10.1 released

[numandev1]

can someone check the 1.10.3 version if this version fixes the issue or not

[numandev1]

@LazyGeniuss ?

[LazyGeniuss]

@numandev1 Tried 1.10.3, it works fine