Welcome to mp4ff Discussions!

[TobbeEdgeware]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[alitteration]

Hello there,

I'm really not very familiar with go lang sadly, but I really appreciate the efforts you've put in that nice tool :)

I was wondering if you wouldn't mind helping me in what needs to be done to generate an EC-3 init for such information

StreamIndex Type="audio" QualityLevels="1" TimeScale="10000000" Language="eng" Name="audio_eng" Chunks="3224" Url="QualityLevels({bitrate})/Fragments(audio_eng={start time})">
<QualityLevel Index="0" Bitrate="192000" CodecPrivateData="00063F000000AF87FBA7022DFB42A4D405CD93843BDD0600200F00" FourCCData="0600200F00" SamplingRate="48000" Channels="6" BitsPerSample="16" PacketSize="768" AudioTag="65534" FourCC="EC-3"/

I saw in the test there is dec3Hex := "0000000e646563330c00200f0202"
but i don't know how to generate this from CodecPrivateData.

[Diniboy1123]

A bit late to the party, but I spent a great while on figuring out this one as well as I am building an mss to mpd converter on the fly, so I can watch my local broadcaster's Playready protected stream I pay for on Android TV with Kodi (unfortunately they only support mss).

First I couldn't make sense out of it, spent ages on Googling existing implementations. Most open-source players either bake in a generic init segment, usually with AAC (as that's documented even by Microsoft, for AAC CodecPrivateData is the audioSpecificConfig) or they create some valid dec3 box with FSCod, channelMask etc.

Then I collected a bunch of samples I found on the internet and noticed that AF87FBA7022DFB42A4D405CD93843BDD is a repeating pattern in all of them. With some Github search I actually found the solution in Bento4.

Seems like the raw bytes you get after AF87FBA7022DFB42A4D405CD93843BDD (which seems to be the MFAudioFormat_Dolby_DDPlus GUID) is in reality the hex representation of the dec3 box you need. mp4ff parses that just fine.

Here is a sample code.

I hope that's useful to someone. I know it's out of scope for this project, but since it has been asked and I also found my way here while looking for answers, I thought I will drop my findings here.

[tobbee]

@Diniboy1123 Nice catch. A small comment on your sample code is that you hard-coded the channel mask 3F00 which is the standard 5.1 audio channels (L, R, C, LFE, Ls, Rs). For some content, you may have a different set of channel.

[Diniboy1123]

I don't read the mask at all, but judging by the code from Bento4, I assumed that its always 2 bytes. I assumed that the dec3 box at the end contains the correct mask. Do you mean that I should extract the mask, because the dec3 box might be insufficient for getting the correct one?

Edit: Dec3Box's ChannelInfo()'s channelmap value seems similar to the mask. That's why I assumed that its safe to discard the first bytes of CodecPrivateData as your lib does a better job usually than me at unpacking certain values. :D

[tobbee]

Yes it is two bytes. It is duplicated information so it is both in the dec3 box and at the start of the string. It is a like writing channel information both in a DASH MPD Representation and inside the init segment. The init segment should be enough, and typically has the finally say, but it is still best if the information is right in the MPD for early parsing and judgment.

[Diniboy1123]

Ah, makes sense. However in mpeg-dash's case I see a good reason for doing this. You can display metadata on your player interface without requesting individual init segments just by parsing manifests. This can save a lot of data if you have a lot of live channels and just want to list metadata, but don't want to start playback (eg. channel listing or when you have many different init segments in one mpd). In MSS's case however the data is present duplicated in the same file. Okay, a bit earlier in the string, but that isn't too much of an optimization imo since you will likely read the whole string once you process the XML...

But in that case I believe I will leave my sample code as-is. For my use case I have to parse the whole string and I believe for MSS when you want to generate your init segment, you most likely want to read the box out of the string completely (although many open source players use hardcoded init segments to my surprise). Thanks for the correction though, it might be useful for someone else.

[tobbee]

A little more digging reveals that the CodecPrivateData should be a hex-encoded version of the the WAVE_FORMAT_EXTENSIBLE structure when the the AudioTab="65534". That format seems to be specified at https://learn.microsoft.com/en-us/windows/win32/api/mmeapi/ns-mmeapi-waveformatex. It doesn't help me to decipher the full string, though.

[thawancavalcante]

Hello there,
Can i use mp4ff to create different types of resolutions and fps?
I want to convert a .mp4 to HLS with multi-bitrate option.
Thanks

[tobbee]

mp4ff just does packaging/unpackaging of video, audio and subtitles, but does not change the actual encoded video or audio.

To change bitrate or resolution you need to use an encoder like x264/x265 directly or via ffmpeg etc.
Regarding HLS, mp4ff can generate segments in fMP4 format, but not the playlists needed.

[thawancavalcante]

Thank you for the explanation

[Diniboy1123]

Hi,

I am looking for some opinions on SdtpBox. I am writing an mss to mpd converter and I noticed that my local provider appends this sdtp box to each avc1 media segment.

Unfortunately as a private person I don't have the spare resources to buy the ISO standard to check it out myself, so I tried to read the source from mp4ff and to my understanding this box is used to mark sample dependencies for easier seeking... This document mentions that it's "smooth like" to have sdtp inside traf. I assume they meant that its commonly used with smooth streaming... For now I am stripping that box out when serving the chunks for MPEG-DASH, because I haven't seen a single other service doing that and playback works just fine this way too.

What do you think, is it worth keeping for MPEG-DASH? Any downsides?

PS: Would you consider setting up Github sponsorships? I wouldn't mind sending a few bucks, this project has made it possible for me to watch soccer.

[tobbee]

@Diniboy1123 It's a bit strange that your reference mentions sdtp inside traf, since the only parent container listed is in the ISOBMFF standard is stbl inside the trak box in the moov box.

The StdpBox is describing samples inside the moov box, so it is only of relevance for "progressive" file, and not for segmented files like DASH, HLS, and MSS can signal the same information via sample flags in the trun box.

The GPAC guys are of course aware of that so they describe different possibilities like using both stdp and trun.

I would definitely drop the stdp and only use trun signaling, since that is according to the standard, and extra boxes means extra overhead.
The MSS spec also specifies to use TrunBox with the possibility of sending SampleFlags, and does not mention sdtp.

The main use I see of sdtp is for translating back and forth to trun sample data when one converts between progressive and fragmented formats.

PS. Regarding Github sponshorship, I'll need to check with my company, but glad to hear that you would consider sponsoring the project

[Diniboy1123]

Thanks for the quick and detailed reply. It really helps a newbie like me to avoid certain rabbit holes.

Find a sample encrypted chunk here: video_1_enc.zip I made sure it's zipped and password protected, because I am not sure if Github strips certain metadata from uploaded files. Pass is simply encrypted.

The chunk is raw, as-in untouched. Just how the provider served it.

I don't have keys for this, I don't even really need one personally, but I can run mp4dump on it and it claims sdtp is indeed inside traf:

[moof] size=8+3517
  [mfhd] size=12+4
    sequence number = 204840566
  [traf] size=8+3493
    [tfhd] size=12+8, flags=8
      track ID = 7
      default sample duration = 200000
    [trun] size=12+412, flags=205
      sample count = 100
      data offset = 3472
      first sample flags = 2000000
    [sdtp] size=8+104
    [6D1D9B0542D5-44E6-80E2-141D-AFF757B2] size=24+20
    [A2394F525A9B-4F14-A244-6C42-7C648DF4] size=28+2804, flags=2
      sample info count = 100
    [D4807EF2CA39-4695-8E54-26CB-9E46A79F] size=24+37
[mdat] size=8+1853296

No idea why would they claim "smooth-like" then in the GPAC docs. But based on your input, I can see that it makes sense to strip away.

you would consider sponsoring the project

Sponsoring is probably a big word, I am a university student with a limited budget, but since this project saves me the costs of paying for 2 extra STBs each month, I saved loads so I wouldn't mind the possibility.