IssueTracker

I have tried both without any call to setMaxFileSize (and setMaxDuration) method and by explicitly requesting unlimited size by passing 0 and -1 (two tests) to setMaxFileSize. My device was running latest firmware (Android 4.4.4). It could be a firmware limitation, but other users are experiencing the same problem (don't know if on the same device, see https://stackoverflow.com/questions/2793471/android-what-is-mediarecorders-maximum-maxfilesize) but I think there could be a limitation in underlying Android classes.

I am not c++/linux expert but looking at AuthorDriver.cpp source code (https://android.googlesource.com/platform/external/opencore/+/8dea89784955d6a02ab971f67e2a8315f1e88aa4/android/author/authordriver.cpp), even though the method AuthorDriver::setMaxDurationOrFileSize accepts a long (row 694 int64_t limit) it is casted to uint32 before calling the method SetMaxFileSize (row 717-730) and this does not make me wonder why the recording stops at 4096 MB (32bit max value). Is this done on purpose for some other reasons and more important can this limitation be removed ?

    if (limit_is_duration) {
        // SetMaxDuration's first parameter is a boolean "enable", we enable
        // enforcement of the maximum duration if it's (strictly) positive,
        // otherwise we take it to imply disabling.
        ret = durationConfig->SetMaxDuration(
                limit > 0, static_cast<uint32>(limit));
    } else {
        // SetMaxFileSize's first parameter is a boolean "enable", we enable
        // enforcement of the maximum filesize if it's (strictly) positive,
        // otherwise we take it to imply disabling.
        ret = durationConfig->SetMaxFileSize(
                limit > 0, static_cast<uint32>(limit));
    }

[Comment deleted]

        (Row 698 - 701 of authordriver.cpp

        if (limit > 0xffffffff) {
                        // PV API expects this to fit in a uint32.
                        return PVMFErrArgument;
                }
        )

The problem seems to be PvmfComposerSizeAndDurationInterface which defines the aMaxFileSizeBytes parameter as uint32 (see https://android.googlesource.com/platform/external/opencore/+/master/nodes/common/include/pvmf_composer_size_and_duration.h row 75 and 88) in these two functions

virtual void GetMaxFileSizeConfig(bool& aEnable, uint32& aMaxFileSizeBytes) = 0;

virtual PVMFStatus SetMaxFileSize(bool aEnable, uint32 aMaxFileSizeBytes) = 0;



Any plan to update this interface (and all the classes implementing it) to uint64 ? As it regards the final file format MP4 should support "64bit addressing" (i.e. files over 4GB) with "co64" atom.

I would like to bump this request.

4GB limits with the Galaxy S7 and 4k video recording with high bitrates is silly.

4GB is a super stupid limited.
It make Android Phone like a toy.
My phone have a good camera, But just record 15 mins.

So any method to overcome this problem? a workaround?

Disclaimer: information / code is for free yet with no warranty (Apache License, Version 2.0)

Using Android-28 SDK, Android Studio 3.2.1, Ubuntu 18.04 development VM:

    @SuppressWarnings("unused")
    final long longVariableOverflowTestNoWarning = 2047 << 20;
    @SuppressWarnings("unused")
    final long longVariableOverflowTestWarning = 2048 << 20;

Android Studio 3.2.1 code checker warns for overflow regarding longVariableOverflowTestWarning variable.
public native void MediaRecorder.setMaxFileSize(long max_filesize_bytes)
is using a long parameter.

Allegedly, the limit is even stricter 2GB rather than 4GB.
It may be just a static check false negative and 3 GB will still work; it is not clean to have overflow warning ignored, though.


+1 feature request:

Maybe add setMaxFileSizeMB to allow larger files?

May you give insights of the correct type to use for 64 bits values?

Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO.

Submitted https://issuetracker.google.com/issues/155575514 as a follow-up.