Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gst-plugins-bad gst-plugins-bad
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 973
    • Issues 973
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 104
    • Merge requests 104
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gst-plugins-badgst-plugins-bad
  • Issues
  • #1615
Closed
Open
Issue created Jul 01, 2021 by Edward Hervey@bilboed🤘Owner

mxfmux creates invalid files

While going over mxfdemux refactoring, I noticed that mxfmux creates invalid files. This is an attempt at summarizing the various issues.

Note: There are various ways to store content in MXF. But mxfmux only works in interleaved mode, i.e. all tracks (input data) are interleaved into one essence container. Furthermore, it only supports frame wrapping of content (i.e. each input buffer is wrapped as a KLV).

FATAL : Interleaving not time coherent

When using frame-wrapped interleaved (i.e. multiple tracks in an essence container), the various items contained in a Content Package should be time-aligned.

i.e. each Content Package should contain:

  • Content for one video frame
  • Optional : Content for the equivalent audio data in time
  • Optional : Content for data/anc in time

But currently ... what happens is that mxfmux doesn't check the duration of the content, and instead puts one input buffer of each type in each Content Package. When the duration of each essence buffer is different... this results in breaking the above requirement. For example, we end up with each Content Package containing 40ms of 25fps video and 30ms of audio.

=> mxfmux should put all corresponding audio/data/anc for the given picture time/duration into the same Content Package. Also see "Different edit rates for interleaved content" below

FATAL : No delta entries for reordered content

From "S377-1:2019 11.2.3 Index Table Segment" at the bottom of "Table 28 – Structure of Index Entry Array"

The Temporal Offset shall be only applied for Essence Elements whose PosTableIndex value in the Element Delta is -1.

The temporal_offset field (used to figure out PTS from DTS) in individual index table segment entries are filled correctly ... but in order for this to be taken into account, there needs to be an associated delta entry (with a pos_table_offset of -1) in the index table segment specifying which Item (in a Content Package) should use this temporal offset.

Not great : No delta entries for all interleaved content

This is an extension of the above. While there is no hard requirement to provide delta entries for all Items that might be present in a content package ... if we need to put one we might as well put all the other. This will also be required to be able to specify "fractional positional offsets" of Content Items which aren't perfectly aligned to the Content Package Rate (ex: 30ms audio in a 25fps table).

FATAL : Using different "edit rates" on interleaved tracks

Currently mxfmux is potentially using different edit rates for tracks interleaved in the same essence container, this is not allowed

From S377-1:2019 "9.4.2 The MXF timing model"

The value of Edit Rate shall be identical for every timeline Essence Track of the Top-Level File Package.

The value of Edit Rate of the timeline Essence Tracks of one Top-Level File Package need not match the Edit Rate of the Essence Tracks of the other Top-Level File Packages.

From S377-1:2019 "9.5.5 Top-Level File Packages"

  1. All Essence Tracks of a Top-Level File Package shall have the same value of Edit Rate. All other Tracks of a Top-Level File Package should have the same value of Edit Rate as the Essence Tracks.
Edited Jul 05, 2021 by Edward Hervey
Assignee
Assign to
Time tracking