live.Downloader's output file corruption

[ping]

Please follow the guide below

• Issues submitted without this template format will be ignored.
• You will be asked some questions and requested to provide some information, please read them carefully and answer completely.
• Do not post screenshots of error messages or code.
• Put an x into all the boxes [ ] relevant to your issue (like so [x]).
• Use the Preview tab to see how your issue will actually look like.

---

Before submitting an issue make sure you have:

• [x] Read the README
• [x] Patched MoviePy
• [x] Searched the bugtracker for similar issues including closed ones

Purpose of your issue?

• [ ] Bug report (encountered problems/errors)
• [ ] Feature request (request for a new functionality)
• [ ] Question
• [x] Other

---

Describe your issue

An IG stream sometimes, possibly due to bandwidth, starts with a low resolution for the first second before stepping up to return higher-resolution segments. This results in the first segment saved (usually XXXXX-0.m4v) having a smaller resolution than the rest of the subsequent segments.

This situation causes a corrupted file when the segments are merged.

[ping]

Changes in 283902741855104c6dc2dd53521c5f031601c82b:

• If a change in resolution is detected, the downloader will attempt to generate a separate video file.
• As a result, downloader.stitch() now returns list of generated filenames.
• The filename format for these separate files are: <output_filename>-<n>.mp4

• The Downloader also has a new property segment_meta, a dict with a structure similar to:

  {
    "XXXXXXXXXXXXXXXX-0.m4v": "324p"
    "XXXXXXXXXXXXXXXX-1001.m4v": "480p",
    "XXXXXXXXXXXXXXXX-1002.m4v": "480p",
    "XXXXXXXXXXXXXXXX-1003.m4v": "480p"
  }

  where the dict keys are the video segment names and the corresponding value is the resolution label (may vary). You may wish to store this segment meta information if you want to process the segments manually instead of relying on downloader.stitch().