8

In this thread, a VLC developer says that VLC cannot play partially downloaded mp4 files because the info is stored at the end of the file. But recently when I tested the same, adding a mp4 task in Chrome and passing the partial .crdownload to VLC, it worked. VLC played the mp4 without a glitch. I didn't let the download finish and stopped the player in the middle to save bandwidth, but I believe it would have played the entire media while Chrome was still downloading it. I was also able to seek through the video, which some unfinished video formats won't allow. What to make of this? I'm doing a media streamer as a pet project and really wanna know if I can initiate the download and pass the media to vlc via command line after certain amount of bytes are downloaded.

1 Answer 1

12

MP4 files can have the metadata chunk at the beginning or at the end. It is usually at the end for freshly encoded files because the encoder might not know what values to write until it's done encoding the whole video (especially the parts needed for seeking).

But when preparing MP4 files for online streaming, it is common to move metadata to the beginning, e.g. as described in this blog post. (In other words, you're not the first to want to do this – it's everyday business for web browsers.)

Note: Although the post shows a full re-encode being done, I am not sure whether that is actually needed – it should be enough to just remux with -codec copy -movflags faststart and avoid the quality loss.


There are tools you can use to see the actual structure of a given MP4 file, e.g.:

$ AtomicParsley test.m4a -T
Atom ftyp @ 0 of size: 24, ends @ 24
Atom free @ 24 of size: 8, ends @ 32
Atom mdat @ 32 of size: 4038152, ends @ 4038184
Atom moov @ 4038184 of size: 58035, ends @ 4096219
     Atom mvhd @ 4038192 of size: 108, ends @ 4038300
     Atom trak @ 4038300 of size: 57386, ends @ 4095686
         Atom tkhd @ 4038308 of size: 92, ends @ 4038400
         ...
     Atom udta @ 4095686 of size: 533, ends @ 4096219
         Atom meta @ 4095694 of size: 525, ends @ 4096219
             Atom hdlr @ 4095706 of size: 33, ends @ 4095739
             Atom ilst @ 4095739 of size: 279, ends @ 4096018
                 Atom ©nam @ 4095747 of size: 31, ends @ 4095778
                 ...
Segmentation fault (core dumped)

Here mdat contains the actual audio/video data (just a single audio stream in this case) and moov contains the metadata (e.g. moov.udta.meta.ilst.©nam is the track title).

4
  • Can't applications like VLC just try to figure it out or something (without the metadata)? And sometimes the metadata at the end is already available etc...
    – Andrew
    Commented Jan 3, 2021 at 8:20
  • Ah. I'm reading that sometimes the MP4 is compressed. If the info needed to decompress is then unavailable (i.e. at the end of the file), then it wouldn't be able to decompress. That would make sense.
    – Andrew
    Commented Jan 3, 2021 at 8:25
  • Maybe an off-topic question here but because metadata of a video can contain a lot of things (date, phone/camera used to record), is it a common practice to strip metadata away when a user uploads a video to one of the big sites (Instagram/YouTube)?
    – nocomment
    Commented Feb 10, 2021 at 12:35
  • It varies; you'll have to download and inspect the files yourself (using ffprobe and exiftool). Videos usually don't carry as much metadata than as photos do. Some of it is kept, some of it isn't. Geolocation is often stripped by public social sites (e.g. Twitter). Camera model might be stripped on social sites, though it is deliberately kept on photo-sharing sites. Sometimes the metadata is simply lost during format conversion, or removed by the CDN rather than by the actual website. Commented Feb 10, 2021 at 13:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .