The ideal container format #3
Replies: 4 comments 7 replies
-
|
Name it MPEG-X, essentially 7z archive with alike content: It could also sort of address some legacy JPEG problems: For some cases a single ".mpp" file should suffice. (XVG) Attention shall be taken to not retrace the serious failure of SVG: [1] https://www.google.com/search?hl=en&gl=us&num=100&q=site:adobe.com/creativecloud/file-types+PSD|3DS|DWG Which means the MPP itself doesn't promote (though support) embedding raw vector sources right inline. The format defining such vector sources shall be named XVG. |
Beta Was this translation helpful? Give feedback.
-
|
The simplest exemplar: Done with the SMPTE non-sense: |
Beta Was this translation helpful? Give feedback.
-
|
= Where major current container formats exactly failed = ... |
Beta Was this translation helpful? Give feedback.
-
|
@MasterInQuestion, the formatting in this thread is utterly unreadable. What's happened? |
Beta Was this translation helpful? Give feedback.
-
|
For Markup/Markdown related: And I'm avoiding the over-interpretation of Markdown. I do exhaustive research on all possibilities of valid representations. Does the formatting somehow appear unintended in some interfaces? |
Beta Was this translation helpful? Give feedback.
-
@MasterInQuestion, that's not possible in GitHub-flavoured Markdown, unfortunately. Both you and I would agree that plain text involves indentation to maintain readability, I presume? That's impossible in GHFM, because the renderer doesn't support anything like searKing/preview-vscode#96 (comment). Even then, it shan't be rendered.
That's very true, except that it's meant to be achieved via CSS. Wrangling HTML (generated from Markdown) that isn't styled in that manner isn't the way to achieve it. It breaks all other features that you've attempted to employ, as verbosely aforestated.
They would, if you were using real footnote syntax. You're not - you're using link abstraction syntax. What you're looking for is Don't just invent syntaxes - I've created conlangs, and it's a multi-year undertaking that usually renders itself fruitless. I'll provide an example of what actually is valid MD: MasterInQuestion @ CE 2024-05-28 18:18:26 UTC: [https://github.com/exiftool/exiftool/issues/94#issuecomment-1546820018](https://github.com/exiftool/exiftool/issues/94#issuecomment-1546820018) Based on the context of a few posts that have gone missing asserting CFR (Constant Frame Rate) and superiority of MP4.
----
MKV may be favored for having less restriction on the media formats (codecs) to contain. Any post-analog adequately designed container format (codec too) should be able to handle arbitrary frame rate (and VFR). For digital media, there's really no frame rate (nor time base [^1]): only presentation timestamps (PTS).
MP4 is far from the most optimal container format. (so is MKV) [^4] For the typical application (local media playback), the container may not even be needed.
[^1]: For typical timestamp implementations: time base shouldn't be of concern. But when tailored to optimize for specific applications: time base may actually become a thing.
Typical high-precision timestamps are based on Int64 and of a granularity of μs (i.e. 1/1,000,000 time base). Which should allow a max duration of (( (2^63 - 1) / 1,000,000 / (3,600 * 24) / 365.2425 ≈ 292,277 )) years in this configuration. However support for granularity smaller than 1/10,000 may be pointless for common systems. (unreachable target accuracy for underlying system; due to beyond threshold latency [^3]) [^2] And using Int32 instead may provide relatively significant performance benefit in certain cases. Thus an alternative configuration based on Int32 and of granularity of ms (1/1,000 s) is plausible: Which should still allow a max duration of (( (2^31 - 1) / 1,000 / (3,600 * 24) ≈ 24.8551348 )) days. (and max 1,000 FPS)
[^2]: Significant amount of audio handling are of 48,000 Hz. (1/48,000 < 1/10,000 indeed) But what handles the final audio playback is typically dedicated hardware (not software based on CPU [Precisely, general purpose processors.]). And which should load far more than 1 sample at once (more than 1 sample per frame), and is [FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics)) like.
Note audio playback is somewhat different than video: the sample value (content) is uttered at the timestamp but not maintained across the whole duration.
[^3] The system's latency may be estimated using `while ( 1 ) { printTS(); };` alike structure. E.g. in Bash:
```shell
x0="${EPOCHREALTIME%%.*}";
while true;
do {
x1="$EPOCHREALTIME";
x2="${x1%%.*}";
["$x2" == "$x0"] && continue;
echo -E "$x1";
x0="$x2";
};
done;
#
# Less likely to work:
# [[
# while true; do { ["${EPOCHREALTIME##*.}" -eq 0] && echo -E "$EPOCHREALTIME"; }; done;
#]]
#
```
[^4]: Why exactly? MP4 had the information critical [^1] for media playback stored at 1 location (usually near the end of file; or the start of file). Such design has caused some problems. [See [FFmpeg's documentation](https://ffmpeg.org/ffmpeg-formats.html#matroska) on related muxers.] . Timestamps could be wrapped as part of each packet (encoded frame), thereby achieve superior performance meanwhile getting rid of all aforementioned problems. Such was somewhat done in MKV. But of significant overhead. (complicated "cues", and many more)
More on the topic: [https://github.com/MasterInQuestion/talk/discussions/3](https://github.com/MasterInQuestion/talk/discussions/3)
1. "moov atom", in MP4 terminology. Mostly contained the presentation timestamps, and frame dimensions.
---
The ideal container format should be based on a general purpose container format: 7z should be a good start point.
---
MasterInQuestion @ CE 2023-05-14 09:55:21 UTC: [https://github.com/exiftool/exiftool/issues/94#issuecomment-1546859236](https://github.com/exiftool/exiftool/issues/94#issuecomment-1546859236) https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Containers#mpeg-4_mp4
The description covers more than just H.264: intended for all codecs (both audio/video) in general. It's a functional analysis on the underpinnings: whose validity is irrelevant of whether particular implementations work or not.
Unnecessary elements may indeed exist (or even be required). But indeed they do not have to.
I've never seen self-referencing footnotes until now, but it is valid. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the formatting insights. My primary focus is to avoid the over-interpretation had rendered texts, unjustifiably differed from their Plain Text source. I take every step cautiously. Compare the rendered side-by-side. |
Beta Was this translation helpful? Give feedback.
-
|
@MasterInQuestion, you're missing the point. As it is, your markup is rendered as Markdown on GitHub. There is no option to choose the IANA Media Type you want your text rendered as, outside of files in repositories. This means that you not adhering to GH's MD implementation has rendered your comment nigh unreadable. The undermentioned is what I see: |
Beta Was this translation helpful? Give feedback.
-
|
The content appears within the expectation. The syntax of this document is sort of an experiment: It's possible to be written in some other less "GOTO", but more verbose manner. I guess your parsing difficulties primarily originated from not recognizing the outline. |
Beta Was this translation helpful? Give feedback.
-
[[
[ MasterInQuestion @ CE 2024-05-28 18:18:26 UTC:
https://github.com/exiftool/exiftool/issues/94#issuecomment-1546820018
Based on the context of a few posts that have gone missing asserting CFR (Constant Frame Rate) and superiority of MP4.
----
MKV may be favored for having less restriction on the media formats (codecs) to contain.
Any post-analog adequately designed container format (codec too) should be able to handle arbitrary frame rate (and VFR).
For digital media, there's really no frame rate (nor time base [1]): only presentation timestamps (PTS).
MP4 is far from the most optimal container format. (so is MKV) [4]
For the typical application (local media playback), the container may not even be needed.
[ [1]
For typical timestamp implementations: time base shouldn't be of concern.
But when tailored to optimize for specific applications: time base may actually become a thing.
Typical high-precision timestamps are based on Int64 and of a granularity of μs (i.e. 1/1,000,000 time base).
Which should allow a max duration of (( (2^63 - 1) / 1,000,000 / (3,600 * 24) / 365.2425 ≈ 292,277 )) years in this configuration.
.
However support for granularity smaller than 1/10,000 may be pointless for common systems. (unreachable target accuracy for underlying system; due to beyond threshold latency [3]) [2]
And using Int32 instead may provide relatively significant performance benefit in certain cases.
.
Thus an alternative configuration based on Int32 and of granularity of ms (1/1,000 s) is plausible:
Which should still allow a max duration of (( (2^31 - 1) / 1,000 / (3,600 * 24) ≈ 24.8551348 )) days. (and max 1,000 FPS) ]
[ [2]
Significant amount of audio handling are of 48,000 Hz. (1/48,000 < 1/10,000 indeed)
But what handles the final audio playback is typically dedicated hardware (not software based on CPU [ Precisely, general purpose processors. ]).
And which should load far more than 1 sample at once (more than 1 sample per frame), and is FIFO like.
Note audio playback is somewhat different than video: the sample value (content) is uttered at the timestamp but not maintained across the whole duration. ]
[ [3]
The system's latency may be estimated using `while ( 1 ) { printTS(); };` alike structure.
E.g. in Bash:
[[
]] ]
[ [4]
Why exactly?
MP4 had the information critical [1] for media playback stored at 1 location (usually near the end of file; or the start of file).
Such design has caused some problems. [ See FFmpeg's documentation on related muxers. ]
.
Timestamps could be wrapped as part of each packet (encoded frame), thereby achieve superior performance meanwhile getting rid of all aforementioned problems.
Such was somewhat done in MKV. But of significant overhead. (complicated "cues", and many more)
More on the topic:
https://github.com/MasterInQuestion/talk/discussions/3
[1] "moov atom", in MP4 terminology. Mostly contained the presentation timestamps, and frame dimensions. ]
----
The ideal container format should be based on a general purpose container format: 7z should be a good start point. ]
----
[ MasterInQuestion @ CE 2023-05-14 09:55:21 UTC:
https://github.com/exiftool/exiftool/issues/94#issuecomment-1546859236
https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Containers#mpeg-4_mp4
The description covers more than just H.264: intended for all codecs (both audio/video) in general.
It's a functional analysis on the underpinnings: whose validity is irrelevant of whether particular implementations work or not.
Unnecessary elements may indeed exist (or even be required).
But indeed they do not have to. ]
]]
Beta Was this translation helpful? Give feedback.
All reactions