Formaatlimiet van 4GB voor videobestanden kan opgeheven worden in Android 11

De volgende versie van Android kan mogelijk een einde brengen aan de bestandsformaatlimiet van 4GB voor video-opnames. Nu nog splitst Android cameravideo in delen van maximaal 4GB zonder dat gebruikers dat merken.

Volgens XDA, dat de aankomende wijziging vond in AOSP Gerrit, waar de broncode van Android besproken wordt, is het een kwestie van een 64bits-offset gebruiken in de mpeg4writer. Nu is dat nog een 32bits-offset. Het staat echter nog niet vast dat deze commit daadwerkelijk in een volgende versie van Android terechtkomt, maar met de ontwikkelingen op het gebied van smartphone-camera's zou het wel welkom zijn.

Volgens XDA stamt het gebruik van een 32bits-limitatie uit begin 2014. Destijds was video opnemen in 4k nog relatief zeldzaam; de Galaxy Note 3 was net uit en was een van de eerste telefoons met de functie. Echter, nu dat opslagruimte, bestandssystemen en cameratechnologie allemaal significante stappen vooruit hebben gezet, is de kans behoorlijk wat groter dat gebruikers tegen deze limiet van 4GB aan gaan lopen.

Hoewel het 'aan elkaar naaien' van meerdere mp4-bestanden wegens deze beperking gewoon mogelijk is, moeten gebruikers daar wel een losse app van een derde partij voor gebruiken, wat niet ideaal is. Vandaag de dag kan de 4GB-limiet op een Pixel 4 met 12 minuten opnemen bereikt worden, met 4k30fps met een bitrate van 48Mbps.

XDA speculeert dat de beperking in de volgende grote versie van Android, versie 11, zal verdwijnen. Daarvan verwacht het de eerste bèta in maart, precies een jaar na de 10-bèta.

Reacties (51)

[Creesch]

Voordat men zich afvraagt waarom er een limiet bestaat, dit heeft waarschijnlijk te maken met het bestaan van externe sd kaarten. Deze zijn (waren) over het algemeen in fat32 geformatteerd aangezien dit en een gratis te gebruiken formaat is en omdat deze geen rechten systeem kent. Dit laatste is belangrijk aangezien externe sd kaarten (net zoals usb sticks) op verschillende systemen gebruikt worden en je daar niet altijd dezelfde gebruikers hebt en je niet plotseling uitgesloten worden van bestanden of mappen.

De maximale grote van bestanden op fat32 geformatteerde kaartjes is 4gb.

Tegenwoordig hebben steeds minder telefoons de mogelijkheid om opslag uit te breiden via een sd kaartje dus wellicht dat men daarom heeft besloten de limiet te verwijderen. Of wellicht komt er exfat support aan, dit was een voorheen gesloten formaat die relatief recentelijk door Microsoft is opengesteld.

[Reactie gewijzigd door Creesch op 23 juli 2024 17:25]

[batjes]

Staat in het artikel waarom dit limiet bestaat.

De mpeg4writer, een lib van Android, gebruikte een 32bit lengte voor het bouwen van videobestanden. Dit wordt nu met Android 11 geupdatet naar een 64bit lengte, waardoor videos langer dan 4gb opgeslagen kunnen worden.

Het heeft in dit geval niets te maken met het gebruikte bestandssysteem. Dit is een antiek limiet waar Google laks mee om gegaan is. Het was niet zo'n probleem want opslag was vroeger toch niet zo groot en de meeste videos zijn maximaal enkele minuten. Maar dat er in 2019 nog met 32bit variables gewerkt wordt door een 'modern' OS is gewoon beschamend.

Dit soort onzin van Google zorgt er o.a. dus voor dat fabrikanten geen zin hebben elke Android release te moeten herbouwen voor gebruikers. Er zijn fabrikanten die zelf dit 32bit limiet eerder al opgelost hadden, zoals bv Sony.

[Reactie gewijzigd door batjes op 23 juli 2024 17:25]

[Jimbolino]

Het heeft in dit geval niets te maken met het gebruikte bestandssysteem.

https://android-review.go...right/MPEG4Writer.cpp#b67
gelukkig staat in de comment precies waar de limiet voor bedoeld was:

// 2^32-1 : max FAT32
// filesystem file size
// used by most SD cards

[Reactie gewijzigd door Jimbolino op 23 juli 2024 17:25]

[Jay-v]

Dat zal er zeker wel mee te maken kunnen hebben, de max filesize op FAT32 is immers 4GB. De reden hiervoor is dat het veld voor filesize 32 bit is. Een pixel telefoon ondersteund bijvoorbeeld alleen FAT32 via sdcard (via usb) en geen exFAT.

[Reactie gewijzigd door Jay-v op 23 juli 2024 17:25]

[batjes]

O.a. Samsung, Sony, OPPO, Asus en Huawei ondersteunen exfat, custom roms zoals Lineage OS bv ook. Net zo goed als dat de interne opslag dit limiet ook niet heeft. Dat de Pixel het niet ondersteund.... wederom ligt het probleem dan bij Google.

Het limiet zat toch echt in de gebruikte library, mpeg4writer. Zie ook de link uit het artikel: https://android-review.go...m/frameworks/av/+/1198379

[Jay-v]

Ik snap dat de limiet in de lib zit, dat wil echter niet zeggen dat dat de ENIGE limiet is.

"Het heeft in dit geval niets te maken met het gebruikte bestandssysteem.", dat klopt dus niet. Dat andere fabrikanten het ondersteunen is prima, dat maakt het echter nog geen standaard onderdeel van Android.

[Gimmeabrake]

Dat andere fabrikanten het ondersteunen is prima, dat maakt het echter nog geen standaard onderdeel van Android.

Dat hoeft ook niet, ondersteuning voor filesystems zit namelijk in Linux, niet in Android. Een deel van de filesystems die Linux ondersteunt zit ingebakken in de kernel (bijv. ext4 en btrfs), een deel wordt ingeladen via kernel modules (bijv. zfs). Sommige filesystems kan Linux ook in userspace draaien (bijv. met fuse, hoewel ik betwijfel of Android dat gebruikt). Welke filesystems er beschikbaar zijn ligt aan degene die de rom maakt, de telefoonproducent dus. Het project Android zelf heeft daar weinig mee te maken.

[Reactie gewijzigd door Gimmeabrake op 23 juli 2024 17:25]

[deadinspace]

Een deel van de filesystems die Linux ondersteunt zit ingebakken in de kernel (bijv. ext4 en btrfs), een deel wordt ingeladen via kernel modules (bijv. zfs).

Alle Linux filesystem drivers kunnen in de kernel gebakken worden (niet ongebruikelijk voor embedded systemen vziw), of als module gecompiled zijn en run-time ingeladen (gebruikelijk voor desktop- en serversystemen). Daarin bestaat geen verschil tussen bv ext4, btrfs, xfs, of fat32. De enige uitzondering is rootfs(ramfs), welke altijd in de kernel gebakken wordt.

Het is in de meeste general-purpose systemen tegenwoordig gebruikelijk om alle filesystems als module te bouwen en tijdens het booten in te laden vanuit een initramfs. Op mijn desktop bijvoorbeeld gebruik ik ext4, en die is ingeladen als module:

% mount | grep "on / "
/dev/mapper/crypt-root on / type ext4 (rw,relatime,discard,errors=remount-ro)

% lsmod | egrep "^ext4"
ext4 737280 3

.

Welke filesystems er beschikbaar zijn ligt aan degene die de rom maakt, de telefoonproducent dus. Het project Android zelf heeft daar weinig mee te maken.

Nouja, Android gebruikt Linux (de kernel), dus de filesystems die standaard door Android ondersteund worden zijn in principe dus de filesystems waarvoor Linux standaard drivers heeft. En aangezien Microsoft exFAT beschermde met patenten zat dit niet standaard in Linux.

En ja, je hebt gelijk dat de telefoonproducent kan kiezen welke standaard drivers aan en uit staan, en in principe ook extra drivers (zoals bijvoorbeeld voor exFAT) toe kan voegen, maar dat toevoegen is wel een extra stap die dus tijd (en dus geld) kost. Het feit dat exFAT support niet standaard in Linux (en dus Android) zit is daarmee wel degelijk een drempel.

Maar Microsoft heeft recentelijk aangekondigd exFAT vrij te geven en graag in de Linux kernel te willen zien, en exFAT support is ook daadwerkelijk verschenen in de meest recente kernel, dus daarmee vervalt die drempel voortaan! Het zou me om eerlijk te zijn niks verbazen dat het weghalen van de 4GiB beperking in dit artikel hiermee samenhangt, omdat dit alles een bredere acceptatie van exFAT mogelijk maakt

[Reactie gewijzigd door deadinspace op 23 juli 2024 17:25]

[Frenziefrenz]

Android heeft bewuste, extreem vervelende beperkingen in de MediaProvider, dus wat de kernel ondersteunt doet niet terzake. Die beperkingen kun je eruit slopen, zie bv. hier.

[TeraMod]

Een deel van de filesystems die Linux ondersteunt zit ingebakken in de kernel (bijv. ext4 en btrfs), een deel wordt ingeladen via kernel modules (bijv. zfs).

Dat ligt geheel aan de configuratie van de kernel. Je kan (bijna) elk bestandsysteem in de kernel inbakken. Of als module configureren, zelfs ext4 en btrfs.

[Creesch]

Klopt

Echter, nu dat opslagruimte, bestandssystemen en cameratechnologie allemaal significante stappen vooruit hebben gezet

Wellicht heb ik iets te veel ingezoomd op één van de factoren maar een factor is het zeker.

Maar dat er in 2019 nog met 32bit variables gewerkt wordt door een 'modern' OS is gewoon beschamend.

Rare conclusie in mijn ogen, als dit resulteert in een specifieke limiet die ook samenhangt met bepaalde opslag beperkingen is het een prima reden om 32bit variabelen te blijven gebruiken. Het is simpelweg de meest eenvoudige aanpak om te zorgen dat gebruikers niet tegen rare zaken aanlopen bij het gebruik van externe opslag. Het alternatief is dat je voor elke opslag locatie moet bepalen wat het bestandssysteem is en als dat er één is met een 4gb beperking dit alsnog ook toepassen op het opslaan van video bestanden.

[Gimmeabrake]

Maar dat er in 2019 nog met 32bit variables gewerkt wordt door een 'modern' OS is gewoon beschamend.

Dit soort onzin van Google zorgt er o.a. dus voor dat fabrikanten geen zin hebben elke Android release te moeten herbouwen voor gebruikers.

Dus het is beschamend dat ze het in 2019 pas fixen, maar door dit soort onzin moeten fabrikanten alles herbouwen. Het is mij niet helemaal duidelijk of je de fix nou een goede zaak vindt of niet...

Overigens: of een fabrikant hiervoor van alles moet herbouwen is maar de vraag. Ik weet niet hoe die mpeg4writer-library precies met andere code interfacet, maar het kan best wel eens zijn dat Sony & co. eigenlijk niets hoeven te doen, behalve dan een nieuwe versie van die lib gebruiken.

[Reactie gewijzigd door Gimmeabrake op 23 juli 2024 17:25]

[xbeam]

Hele Grote kans dat het limiet van mpeg4writer gebaseerd is op de limieten van fat32

[HoeZoWie]

Hele Grote kans dat het limiet van mpeg4writer gebaseerd is op de limieten van fat32

Precies, maar ook "exFat" heeft al een tijdje ze entree in Linux vs Android, gedaan, dus dat is het niet.
Het gedrag van het bestand systeem, exFat is meer NTFS zonder de security, dan het een extentie is van Fat32, gezien de specificaties.

Maar.....
Voeg ik hiermee iets toe, in de discussie?
Nee niet echt..., ik verklaar louter.

[xbeam]

Waarschijnlijk, nee 100 procent zeker hebben ze de lib’s in de tijd geschreven met de beperking van fat32 in het achterhoofd en nooit de noodzaak gezien om deze te update. Omdat het ook met exfat prima werkte en nog veel systemen in omloop waren met fat32.

Zelfs nu kom ik regelmatig nog fat32 tegen. En camera’s zoals Sony die nog steeds de video’s op delen in blokken van 4Gig omdat software er prima mee overweg en er bij een export toch gewoon 1 bestand van maakt.

[Reactie gewijzigd door xbeam op 23 juli 2024 17:25]

[Jxx]

Exfat is toch ook gratis

[Creesch]

Ondertussen wel, maar dat is relatief recent pas gratis gemaakt. Voorheen moesten daar licentiekosten over betaald worden.

[grasnek]

Ik denk niet dat het aan 'aankomende exfat support' ligt. Mijn Galaxy S8+ is al bijna 3 jaar op de markt en snapt dat namelijk al jaren gewoon als ik er een 128GB SD kaartje wat exfat geformatteerd is in steek. En een 64GB exfat USB stick werkt ook prima.

[Xeneonic]

Google heeft een deal met Samsung gesloten waarbij Samsung support mag geven voor exfat (En NTFS). Dit is volgens mij al mogelijk sinds de galaxy S4, maar dat zou ook eerder kunnen zijn. Dit is een best bijzondere deal maar niet per-se exclusief. Ik weet zo niet welke andere manufacturers deze mogelijkheid hebben. Ik heb in ieder geval een Google Pixel 3a XL (een maand geleden gekocht), momenteel op Android 10, en ik kan je met zekerheid vertellen dat exfat/NTFS niet mogelijk is zonder 3rd party tools (Ik gebruik Paragon bijvoorbeeld als 3rd party tool)

[Fermion]

Samsung zal eerder bij Microsoft aan de deur moeten kloppen voor het gebruik van NTFS en exfat, zij hebben de rechten.

[sohus]

Laat Samsung en Microsoft nu net uitgebreid samenwerken op Android.

[MsG]

Samsung is ook de enige die de storage als een schijfletter kan tonen als je de telefoon aan de pc hangt. Bij alle andere fabrikanten wordt het een MTP-apparaat bij aansluiten waar je niet eens rechtstreeks naartoe kan opslaan vanuit programma's, omdat het geen schijfletter structuur heeft.

[Balance]

Ter aanvulling: Android is gebaseerd op de Linux-kernel, die sinds versie 5.4 ondersteuning voor exFAT heeft gekregen.

[fapkonijntje]

De meeste telefoons draaien op een 4.x kernel.

[Dutch2007]

zover ik weet is google wel bezig om er voor te zorgen dat android op de mainline kernel kan draaien, dan heb je opeens veel betere support

zie ook: nieuws: Google wil dat Android op mainline Linux-kernel gaat draaien

[HuisRocker]

Zou fijn zijn als er inderdaad exfat support komt.
Bijvoorbeeld, vanwege de beperkingen van fat32 heb ik al mijn USB sticks van 64GB en hoger al lang geleden naar exfat omgezet.

[Gustaaf437]

Dit lijkt me een beetje ver gezocht. Veel oudere decoders ondersteunen alleen 32-bit offsets, maar omdat in bijna alle decoders tegenwoordig support is ingebouwd voor 64-bit offsets is het gebruiken van 64-bit offsets nu veilig.

[dasiro]

dat is niet de reden voor DEZE limiet, die staat in het artikel.

[Creesch]

Klopt, belangrijke reden was dan ook het gebruikte bestandssysteem.

Echter, nu dat opslagruimte, bestandssystemen en cameratechnologie allemaal significante stappen vooruit hebben gezet

Met name relevant voor externe opslag aangezien daar zeker toen nog fat32 het meest logische formaat was met een 4gb limiet.

[Abdel1412]

Niet alleen camera opnames hebben dit probleem, ook met interne schermopname stopt de opname abrupt wanneer de limiet is bereikt.

Dit is erg vervelend wanneer je bijvoorbeeld net als ik video games opneemt in HR. Nu moet ik steeds weer een nieuwe schermopname uitvoeren terwijl dit vaak midden in een actie moment plaatst vind ( pubg mobile)

[Reactie gewijzigd door Abdel1412 op 23 juli 2024 17:25]

[HollowGamer]

Dat is best vreemd, hij moet toch gewoon doorgaan en het enkel splitsen (lees veder schrijven in een nieuw bestand) in meerdere bestanden:

Nu nog splitst Android cameravideo in delen van maximaal 4GB zonder dat gebruikers dat merken.

Ontopic:
Het 'aan elkaar naaien' (concatenate) kan uit ervaring best even duren of niet altijd goed gaan (out-of-sync audio/video), met deze wijziging is dat gelukkig niet meer nodig is.

Denk dat het een vereiste is om een 64-bit sock te hebben, anders kan het OS het niet wegschrijven lijkt me? Is dat dan niet mede de reden dat het splitsen dus wel moet aangezien niet elke sock 64-bit is?

[Reactie gewijzigd door HollowGamer op 23 juli 2024 17:25]

[watercoolertje]

Denk dat het een vereiste is om een 64-bit sock te hebben, anders kan het OS het niet wegschrijven lijkt me? Is dat dan niet mede de reden dat het splitsen dus wel moet aangezien niet elke sock 64-bit is?

In principe schrijf je de hele tijd kleine stukjes (soort streamen) ipv in 1 keer een hele grote file, dus je hardware hoeft niet voor 4GB adressen bij te houden bij het schrijven van 4GB aan data.

Denk eerder dat het tegenwoordig vanzelfsprekend is dat alle gebruikte filesystems over dat limiet heen kunnen, dat is wel eens anders geweest en daarom een limiet wat nog vrij lang gehanteerd is.

Voor dat hele 64-bit voor consumenten beschikbaar was in computers kon je files van meerdere TB maken op een 32-bit systeem, moet je wel het juiste filesystem gebruiken natuurlijk.

[Reactie gewijzigd door watercoolertje op 23 juli 2024 17:25]

[brammieman]

Fijn dat het opgelost wordt maar moet zeggen dat ik er in persoonlijk de praktijk weinig last van had. Schiet best wel wat video maar zelden zo lang ononderbroken. Al merk ik nu met 4k 60fps ook dat de bestanden flink groter worden.

[parend]

Heb nooit genoeg geheugen gehad intern om het te proberen maar op mijn microsd lukt het al sinds de note1 om bestanden groter dan 4GB op te slaan. 1 keer moest ik zelf kloten toen in overgestapt was op Sony. Maar alle Samsungs geen problemen ondervonden met exfat.

[cdwave]

Naast exfat ondersteunt vrijwel elk ander bestandsysteem bestanden die veel groter zijn dan 4GB, zelfs het stokoude ext2 kan daarmee overweg. Dat (veel) telefoons geen ext2/3/4 op een SD kaart ondersteunen heb je fijn te danken aan Google die om onbekende reden die support niet in de kernel heeft zitten.

Leuk detail om te weten is dat standaard DVDs ook geen bestanden groter dan 4GB kunnen opslaan. Interessante keus geweest voor een read-only medium die in het leven geroepen is om een filmbestand van maximaal 9GB op te slaan...

[Creesch]

Dat (veel) telefoons geen ext2/3/4 op een SD kaart ondersteunen heb je fijn te danken aan Google die om onbekende reden die support niet in de kernel heeft zitten.

Is best een logische verklaring voor, veel gebruikers zullen er vanuit gaan dat ze hun SD kaart ook gewoon in een cardreader in hun pc kunnen stoppen. Dit zijn veelal windows computers waar historisch fat32 het meest logische formaat was om te ondersteunen (exfat is pas recentelijk open geworden). Je wil ook formaten vermijden die aan rechtenbeheer doen om vergelijkbare redenen, het is nogal zuur als je bestanden van je telefoon niet te benaderen zijn omdat ze gelockt zijn voor een andere gebruiker die op de betreffende computer niet eens bestaat.

[cdwave]

Voordat je dat kunt doen zul je toch eerst de SD kaart moeten omzetten naar ext4, een nogal bewuste actie van de gebruiker. Dat de kernel ext4 ondersteunt wil niet zeggen dat je SD kaart dan ook automatisch opnieuw geformatteerd wordt (formatteren doet de kernel niet eens, daar is een userspace programma voor nodig) of iets in die richting.

Bovendien speelt het probleem van Windows ondersteuning alleen maar als je de SD kaart eruit haalt en in je PC steekt (aangezien google ook de superhandige mass-storage functie van android 4 om zeep heeft geholpen). De sharing functies gebruiken allemaal de filesystem toegang van de kernel, en dus is het helemaal transparant hoe het ding benaderd wordt.

Overigens, Windows zou natuurlijk gewoon ext2/3/4 support toe kunnen voegen. Dat ze dat nooit gedaan hebben is een politiek/marketing/strategie dingetje, maar heeft geen technische reden.

[Mushroomician]

Nu nog splitst Android cameravideo in delen van maximaal 4GB zonder dat gebruikers dat merken.

Ligt er natuurlijk wel aan welke gebruik je bent.

[michaelkamen]

XDA speculeert dat de beperking in de volgende grote versie van Android, versie 11, zal verschijnen.

Moet dat niet zijn "..., zal verdwijnen"?
(De beperking van 4 GB is er al)

[Reactie gewijzigd door michaelkamen op 23 juli 2024 17:25]

[sypie]

Geachte Redactie

[mutley69]

Die limiet heeft te maken met het bestandsysteem.

[blorf]

Niet die van Linux. Een ext2 bestandssysteem ging al tot 2048GB. Dit is een level lager, storage via de Android GUI.

[Kimbo72]

En wat betreft het opnemen van telefoongesprekken?
Komt dat ook weer terug?
Wel zo handig als bedrijven zich niet aan de afspraken houden dan heb je altijd een bewijs wat er is afgesproken.

[SadisticPanda]

Gaat op mijn samsung al sinds mijn S1. (wel enkel echte telefoon, voip neemt die niet op)

[JayPe]

Terug

Het kon. Maar kan niet meer.

[SadisticPanda]

Mijn s9_doet het ook. S10 geen idee.

[Jxx]

Ja dit staat voor mij op nummer 1 op het lijstje

[GekkePrutser]

Oh hopelijk gaat de Android File Transfer app voor Mac nu eindelijk ook eens werken met files die groter zijn dan 4GB. Dat ding is echt onbruikbaar nu.

[Martinspire]

Kunnen ze niet beter alle 32bit zaken eruit halen? Gewoon 1 grote change zodat dit nergens meer voor komt?