Wrong DIDL-Lite bitrate and size informations giving issues while transcoding

[digitalmediaserver]

Wrong DIDL-Lite bitrate and size informations giving issues while transcoding

[Nadahar]

@Sami32 I'm aware that there's a lot of stuff that's wrong/missing, including bitrates, sizes etc. My plan was to rewrite the whole thing from scratch, as I don't see much hope for "fixing" the code that's already there. So many wrong assumptions are made, but there's also a lack of available information.

I don't know a proper way to get the bitrate when transcoding, I don't know if one exists. Taking the first 2,5 seconds is likely to be very wrong, as many videos start with some kind of intro which probably has a lower bitrate than the rest. Also, we'd need to know the maximum bitrate, which isn't possible without probing the whole file. In addition, we need to know this long before playback is started, at the browsing stage. In short, it's not possible to get this information in time.

My plan is different; I'm planning to only transcode to defined DLNA profiles. The profiles have defined bitrate (and other) constraints, so my idea is to tell the transcoding engine to keep the bitrate within the defined limit. As I understand the DLNA standard, the information in the DIDL should then be the defined maximum bitrate, not the actual bitrate.

As it is now, DLNA profiles aren't used (or, the little DLNA information sent is wrong). It's impossible to tell how it would work if implemented correctly as long as it is so much non-compliance, so I'm simply ignoring these problems until it is reimplemented.

[Sami32]

Yes 😄

[Sami32]

Sorry...i feel that it's not clear as i would like, but i miss the words and write what i think is the more near than french.
Yes, i use anterior, as "before", "less than"; "inférieur" or "moins que" in french, so "less than" is good for me to remember, thanks 😉

[Sami32]

Surely the cleanest and best approach, that's an advantage of working without users 😉

Some users want play their "camera" AVI videos, so i don't really have choice for the quick fix, IMO...

[Sami32]

Following your post, i should have added that you could be surprised by the future MediaInfo DLNA's profiles support 😉

[Nadahar]

@Sami32 I really don't see how a quick fix could be done, as the information simply isn't there. The only thing I can think of is to make a "guesstimation" where you use the source codecs and their bitrates, resolution etc into account and then use some pre-defined conversion value between the different formats and apply that "guesstimate factor" to the source bitrate. It sounds like quite å project to me, but I guess something could be done, although that's the kind of solution one would end up having to adjust for eternity.

[Sami32]

I mean really quick 😉
Not one imperfect that will need eternal adjustement.

I just used the bandwidth limitation set inside the renderer configuration file because thet are set their to follow the renderer specifications limiting the bitrate, but only for video having an original bitrate superior to 200 Mb/s, as all the renderers that i saw with limitation followed the same limitation, at least the far more popular one.

Still a more quick way is to hardcode the 25 MB/s bitrate value to be set in the DIDL while the original bitrate is superior to 200 Mb/s

[Nadahar]

@Sami32 I didn't quite understand that. When you say "superior" - do you mean greater than? In any case, I don't quite see the point of just trying to "cheat" the renderer. If the bitrate are greater than what the renderer can handle, I doubt playback will be very nice. Or, did I simply misunderstand you?

[Sami32]

Yes, i meant > ("supérieur" in french)

I was not clear, precise, so misunderstanding was easy. When i transcode with a FFmpeg custom option set into the renderer i made sure that the bitrate will be not more of 25 MB/s, but as the code is now, the bitrate set into the DIDL string will be totally wrong and more important, not supported by the renderer that freeze, as your with AAC having high bitrate.
So i just trick the bitrate value set into the DIDL string.

Do i was more clear this time ❓

[Nadahar]

@Sami32

Do i was more clear this time ❓

I guess you meant "Was I clearer this time?" If so, I guess somewhat but I still don't quite follow you. If a file is transcoded with a bitrate limitation (as a transcoder parameter), then I'd say it would be correct to use that bitrate limitation in the DIDL. The problem might be to know this when the DIDL is created, but if that is known that isn't really "tricking" IMO. The logic would have to make sure that the media would really be transcoded with that limit though. Is this what you're doing?

[Sami32]

Yes 😄

[Nadahar]

@Sami32 While we're at it, do you mean "less than" when you say "inferior" as well? Anterior is another word you use that I don't understand, is sounds like "older than" or "more ancient than" to me, but that often doesn't make sense in the way you use it.