I see on this forum, and out on the web, most people are talking about Segments, and very little about Fragments, even doing a search of "segments vs fragments" brings back items about segments. As a developer/coder myself, i can use whatever extension i choose, so are .m4s and .m4f the same, or are they a true type, and have meaning?
The only way i can download the video and audio files, is using a script after i open the MPD, to find the url to the file directory. If i use YT-DLP with the MPD, it only grabs part of the files, since the MPD is very dynamic, it will add the video and audio parts, depending on where the time is in the player. For example, you start the video, it will start at 0 and preload about 5 parts such as 0, 1, 2, 3, 4 however, if you skip ahead a minute or two, then it will grab the file need for that time index, and could end up with 0,1,2, 15, 16, 17 so the MPD is ever changing, so had to go another route, and just download via script. Also each time, the MPD changes the MPD link name will also change.
The reason i am asking if they are the same, is for how to put all the pieces together. i tried a few ways with FFMPEG using the cat-mux method, but it is not happy at all, since i need to merge it like init.mp4 -> 0.m4f -> 1.m4f = merged.mp4, and i will also need to do this with the audio and uses the same type of extensions but need the m4a so that would look like TK_init.mp4 -> TK0.m4f -> TK!.m4f = merged.m4a.
I am also doing this on a Windows box, have not tried on a Linux box to see if maybe FFMPEG is more Linux friendly. So my real issue could be Windows, and would not be shocked LOL.
+ Reply to Thread
Results 1 to 4 of 4
I can not assist as far as far as the video creation is concerned but here is my take on the interpretation of the two words.
Fragments: Parts of a whole but some parts are missing.
Segments: Parts of a whole but all parts are present. (typically collected in the right order)
One typically see the former when downloading torrents. The client receives parts but not in the correct order. But it knows the order and builds up the final item when it gets them all. If the client can not get all the parts the download is incomplete and, in the case of a video, will not play correctly if at all.
In a non-video example there was some recent news of the discovery of some 'fragments' of a biblical scroll. So here, again, the scroll is not complete.
That is kind of how i was looking at, they are both words for "parts", and the definition for the "Fragments" does make a lot of sense, for what i am seeing, not all parts are there, just the needed parts at that time.
In someways i was hoping that there was a difference in the the two, it would explain a lot. so back to to drawing board LOL.
Dash fragments may use .m4s or .m4f as the extension name in the source url.
Both are the same type of file structurally.
The fragments always need to be concatenated using the init fragment first, followed by the sequential fragments.
The type of concatenation must be raw binary, without any changes or manipulation. The fragment files must be joined together end-to-end, with each fragment file retaining the exact same binary content.
If you can't use the mpd manifest to accomplish this using yt-dlp, the alternatives are to just binary copy the fragments together, or construct a post-hoc manifest.
Or, write a yt-dlp replacement that can dynamically parse (and update from) the live stream manifest mpd url.
I don't know if ffmpeg does a raw binary concatenation. It probably treats all of the dash fragments as mp4 type files and does manipulation as part of the concatenation process. This won't work.