Login at Kodi Home

quietvoid · (This post was last modified: 2020-12-21, 01:13 by quietvoid.)

(2020-12-20, 01:44)fandangos Wrote: @quietvoid where did you find the plex ffmpeg source code?

https://downloads.plex.tv/ffmpeg-source/...c85.tar.gz
I didn't add any custom code other than fixing Plex's MKV code since it was not working on top of 4.3.

However I'm not sure if the missing block ID is necessary, since with the patch PR only, ffmpeg could create side data from the file.
Thanks for the work on this, if you need something I can help test as well.

I'll look into your git but I'm not sure if you've put up Kodi side changes on there yet?

As for aforementioned ffmpeg patch, there's a missing line in the PR I made: https://github.com/quietvoid/FFmpeg/blob...1435-L1436.
Maybe once there's working code the PR/patch could be improved to be acceptable to ffmpeg upstream.

sk83 · 2020-12-21, 01:39

(2020-12-20, 23:58)fandangos Wrote:
(2020-12-20, 23:55)hoppel118 Wrote:
(2020-12-20, 21:24)fandangos Wrote: Ok, good news, managed to get it working.

Only problem to solve, to change into DV from a mkv file only when this kind of file is playing.
But success ))

Yes!!! Fantastic news!

Do you have a github repository?

Any chance that you bring that code to FFmpeg?

Regards Hoppel
FFmpeg changes:
https://github.com/fandangos/FFmpeg/tree...e/4.3-kodi

Changes needed in Kodi, soon. Still work in progress.

EDIT: Oh, you mean like doing a Pull Request on their git? Ahm, no way, the source of this code is plex.
It might get merged on kodi's ffmpeg fork but I'm not sure of anything.

Again, this is awesome work. Now, I've succesfully built kodi using your ffmpeg repo. Which changes are needed to DVDVideoCodecAndroidMediaCodec? Would you mind posting a diff or your source code?
Can't wait to use Kodi again, been using Emby for a while due to it supporting DV MKV.

fandangos · 2020-12-21, 01:39

(2020-12-21, 01:00)quietvoid Wrote:
(2020-12-20, 01:44)fandangos Wrote: @quietvoid where did you find the plex ffmpeg source code?
https://downloads.plex.tv/ffmpeg-source/...c85.tar.gz
I didn't add any custom code other than fixing Plex's MKV code since it was not working on top of 4.3.

However I'm not sure if the missing block ID is necessary, since with the patch PR only, ffmpeg could create side data from the file.
Thanks for the work on this, if you need something I can help test as well.

I'll look into your git but I'm not sure if you've put up Kodi side changes on there yet?

As for aforementioned ffmpeg patch, there's a missing line in the PR I made: https://github.com/quietvoid/FFmpeg/blob...1435-L1436.
Maybe once there's working code the PR/patch could be improved to be acceptable to ffmpeg upstream.

I've noticed that missing line, it's there on my fork of ffmpeg 4.3 from xbmc.

And not yet for the Kodi side changes, I still have to work just a little longer on it, or else everything you play would be Dolby Vision.

MrMagic · 2020-12-21, 01:44

(2020-12-21, 01:39)fandangos Wrote: And not yet for the Kodi side changes, I still have to work just a little longer on it, or else everything you play would be Dolby Vision.

Great to read there is progress on this. Hopefully we can try your apk soon. I wouldn't even mind running a separate version just to play the DV movies Smile

Any chance you will be compiling this with a different package name so we can run it in parallel to other versions?

fandangos · 2020-12-21, 02:09

(2020-12-21, 01:44)MrMagic Wrote:
(2020-12-21, 01:39)fandangos Wrote: And not yet for the Kodi side changes, I still have to work just a little longer on it, or else everything you play would be Dolby Vision.
Great to read there is progress on this. Hopefully we can try your apk soon. I wouldn't even mind running a separate version just to play the DV movies

Any chance you will be compiling this with a different package name so we can run it in parallel to other versions?

Yes, I have a regular version of Kodi here that I don't want to mess with.
I'm testing with a different package name here.

sk83 · 2020-12-21, 02:36

(2020-12-21, 01:39)fandangos Wrote: And not yet for the Kodi side changes, I still have to work just a little longer on it, or else everything you play would be Dolby Vision.

I think this is where I am now. By forcing the "video/dolby-vision" mime type and the amc-dvh1 codec for HEVC streams no matter what, it triggers the Dolby Vision badge on my TV whenever i play a HEVC file.

For non-HDR movies, this severely shifts the colors and makes it unwatchable. For HDR10 streams, it also triggers the Dolby Vision badge, but the movie is actually watchable - probably because of the HDR10 base layer in mosts DV streams.

But - this makes me wonder. How can we be sure that the actual DV metadata is being used for DV streams, and not just the HDR10 base layer? The DV badge on the TV can apparently not be trusted.

fandangos · (This post was last modified: 2020-12-21, 02:44 by fandangos.)

(2020-12-21, 02:36)sk83 Wrote:
(2020-12-21, 01:39)fandangos Wrote: And not yet for the Kodi side changes, I still have to work just a little longer on it, or else everything you play would be Dolby Vision.

I think this is where I am now. By forcing the "video/dolby-vision" mime type and the amc-dvh1 codec for HEVC streams no matter what, it triggers the Dolby Vision badge on my TV whenever i play a HEVC file.

For non-HDR movies, this severely shifts the colors and makes it unwatchable. For HDR10 streams, it also triggers the Dolby Vision badge, but the movie is actually watchable - probably because of the HDR10 base layer in mosts DV streams.

But - this makes me wonder. How can we be sure that the actual DV metadata is being used for DV streams, and not just the HDR10 base layer? The DV badge on the TV can apparently not be trusted.

Here I'm forcing:
m_mime = "video/dolby-vision";
m_formatname = "amc-hevc";

And I tried using MKTAG and MKBETAG for the if stantement but nothing.

Basically what's left is
If (this is really Dolby Vision)
{
m_mime = "video/dolby-vision";
m_formatname = "amc-hevc";
};
break;

And that's it. The part in bold is what I'm trying to figure out but it's late and I really need some rest.

And testing metadata... only with HD Fury or similar, which I don't have.

sk83 · 2020-12-21, 10:43

(2020-12-21, 02:43)fandangos Wrote:
(2020-12-21, 02:36)sk83 Wrote:
(2020-12-21, 01:39)fandangos Wrote: And not yet for the Kodi side changes, I still have to work just a little longer on it, or else everything you play would be Dolby Vision.

I think this is where I am now. By forcing the "video/dolby-vision" mime type and the amc-dvh1 codec for HEVC streams no matter what, it triggers the Dolby Vision badge on my TV whenever i play a HEVC file.

For non-HDR movies, this severely shifts the colors and makes it unwatchable. For HDR10 streams, it also triggers the Dolby Vision badge, but the movie is actually watchable - probably because of the HDR10 base layer in mosts DV streams.

But - this makes me wonder. How can we be sure that the actual DV metadata is being used for DV streams, and not just the HDR10 base layer? The DV badge on the TV can apparently not be trusted.

Here I'm forcing:
m_mime = "video/dolby-vision";
m_formatname = "amc-hevc";

And I tried using MKTAG and MKBETAG for the if stantement but nothing.

Basically what's left is
If (this is really Dolby Vision)
{
m_mime = "video/dolby-vision";
m_formatname = "amc-hevc";
};
break;

And that's it. The part in bold is what I'm trying to figure out but it's late and I really need some rest.

And testing metadata... only with HD Fury or similar, which I don't have.

I tried the same approach with the MKTAG with the same results. May I ask why your'e using the amc-hevc decoder? This results in a black screen for me.

sk83 · 2020-12-21, 12:24

@fandangos

Added some logging to DVDVideoCodecAndroidMediaCodec to see the actual values of the MK/MKBETAGS, as well as the value of m_hints.codec_tag:

Code:
CLog::Log(LOGINFO, "M_HINTS_CODEC_TAG: %d", m_hints.codec_tag);

CLog::Log(LOGINFO, "dvhe_b: %d", MKBETAG('d', 'v', 'h', 'e'));

CLog::Log(LOGINFO, "dvh1_b: %d", MKBETAG('d', 'v', 'h', '1'));

CLog::Log(LOGINFO, "dvcC_b: %d", MKBETAG('d', 'v', 'c', 'C'));

CLog::Log(LOGINFO, "dvvV_b: %d", MKBETAG('d', 'v', 'V', 'C'));

CLog::Log(LOGINFO, "dvhe: %d", MKTAG('d', 'v', 'h', 'e'));

CLog::Log(LOGINFO, "dvh1: %d", MKTAG('d', 'v', 'h', '1'));

CLog::Log(LOGINFO, "dvcC: %d", MKTAG('d', 'v', 'c', 'C'));

CLog::Log(LOGINFO, "dvvC: %d", MKTAG('d', 'v', 'v, 'C'));

Which generates this output:

Code:
INFO <general>: M_HINTS_CODEC_TAG: 0

2020-12-21 10:54:43.198 T:10961    INFO <general>: dvhe_b: 1685481573

2020-12-21 10:54:43.198 T:10961    INFO <general>: dvh1_b: 1685481521

2020-12-21 10:54:43.198 T:10961    INFO <general>: dvcC_b: 1685480259

2020-12-21 10:54:43.198 T:10961    INFO <general>: dvvV_b: 1685476931

2020-12-21 10:54:43.198 T:10961    INFO <general>: dvhe: 1701344868

2020-12-21 10:54:43.198 T:10961    INFO <general>: dvh1: 828929636

2020-12-21 10:54:43.198 T:10961    INFO <general>: dvcC: 1130591844

2020-12-21 10:54:43.198 T:10961    INFO <general>: dvvC: 1131837028

Seems like the m_hints.codec_tag is always 0 for MKV containers, tested with SDR, HDR10 and DV HEVC.

For MP4/MOV containers m_hints.codec_tag seems to work. I get 1701344868(which corresponds to MKTAG('d','v','h','e'), 828929636(MKTAG('d','v','h','1'), and last, 828601960 for an ordinary HDR10 MP4.

So it seems like a method for getting the codec_tag from MKVs needs to be implemented.

fandangos · 2020-12-21, 13:46

(2020-12-21, 12:24)sk83 Wrote: @fandangos

Added some logging to DVDVideoCodecAndroidMediaCodec to see the actual values of the MK/MKBETAGS, as well as the value of m_hints.codec_tag:

Code:
CLog::Log(LOGINFO, "M_HINTS_CODEC_TAG: %d", m_hints.codec_tag); CLog::Log(LOGINFO, "dvhe_b: %d", MKBETAG('d', 'v', 'h', 'e')); CLog::Log(LOGINFO, "dvh1_b: %d", MKBETAG('d', 'v', 'h', '1')); CLog::Log(LOGINFO, "dvcC_b: %d", MKBETAG('d', 'v', 'c', 'C')); CLog::Log(LOGINFO, "dvvV_b: %d", MKBETAG('d', 'v', 'V', 'C')); CLog::Log(LOGINFO, "dvhe: %d", MKTAG('d', 'v', 'h', 'e')); CLog::Log(LOGINFO, "dvh1: %d", MKTAG('d', 'v', 'h', '1')); CLog::Log(LOGINFO, "dvcC: %d", MKTAG('d', 'v', 'c', 'C')); CLog::Log(LOGINFO, "dvvC: %d", MKTAG('d', 'v', 'v, 'C'));

Which generates this output:

Code:
INFO <general>: M_HINTS_CODEC_TAG: 0 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvhe_b: 1685481573 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvh1_b: 1685481521 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvcC_b: 1685480259 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvvV_b: 1685476931 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvhe: 1701344868 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvh1: 828929636 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvcC: 1130591844 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvvC: 1131837028

Seems like the m_hints.codec_tag is always 0 for MKV containers, tested with SDR, HDR10 and DV HEVC.

For MP4/MOV containers m_hints.codec_tag seems to work. I get 1701344868(which corresponds to MKTAG('d','v','h','e'), 828929636(MKTAG('d','v','h','1'), and last, 828601960 for an ordinary HDR10 MP4.

So it seems like a method for getting the codec_tag from MKVs needs to be implemented.

Nice, thanks for helping out.

Yes I suspect it would be always 0 and when something like that happens in my experience I just try to find something else.
If you look at your log you will see Side Data, this is one option.

Quote:INFO <general>: ffmpeg[0x2fbb06e040X]: DOVI configuration record: version: 1.0, profile: 7, level: 6, rpu flag: 1, el flag: 1, bl flag: 1, compatibility id: 6

This is done by av_packet_get_side_data

That's option number 1.

The second is to do something like MediaInfo did:

https://github.com/MediaArea/MediaInfoLi...11f3b2aff4

Quote:switch (BlockAddIDType)
{
case 0x64766343: // dvcC
case 0x64767643: // dvvC
Element_Name("Dolby Vision Configuration");
dvcC();
break;
case 0x68766345:
Element_Name("Dolby Vision EL HEVC");
#if MEDIAINFO_TRACE
if (Trace_Activated)
{

The first method would be much cleaner and have higher chances of being merged.
The problem is that I suck at writting C++ from scratch.

Now next problem, here with the Nvidia Shield TV Pro (2019) I got no black screen with "amc-hevc" and the movie plays just fine, colors seemed ok, tried with UHD BD Remux.
With "amc-dvhe" I get a ton of stuttering.
And I have not tested amc-dvh1.

So yeah... this will be a little bit harder but I think we can do it.

sk83 · 2020-12-21, 17:42

(2020-12-21, 13:46)fandangos Wrote:
(2020-12-21, 12:24)sk83 Wrote: @fandangos

Added some logging to DVDVideoCodecAndroidMediaCodec to see the actual values of the MK/MKBETAGS, as well as the value of m_hints.codec_tag:

Code:
CLog::Log(LOGINFO, "M_HINTS_CODEC_TAG: %d", m_hints.codec_tag); CLog::Log(LOGINFO, "dvhe_b: %d", MKBETAG('d', 'v', 'h', 'e')); CLog::Log(LOGINFO, "dvh1_b: %d", MKBETAG('d', 'v', 'h', '1')); CLog::Log(LOGINFO, "dvcC_b: %d", MKBETAG('d', 'v', 'c', 'C')); CLog::Log(LOGINFO, "dvvV_b: %d", MKBETAG('d', 'v', 'V', 'C')); CLog::Log(LOGINFO, "dvhe: %d", MKTAG('d', 'v', 'h', 'e')); CLog::Log(LOGINFO, "dvh1: %d", MKTAG('d', 'v', 'h', '1')); CLog::Log(LOGINFO, "dvcC: %d", MKTAG('d', 'v', 'c', 'C')); CLog::Log(LOGINFO, "dvvC: %d", MKTAG('d', 'v', 'v, 'C'));

Which generates this output:

Code:
INFO <general>: M_HINTS_CODEC_TAG: 0 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvhe_b: 1685481573 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvh1_b: 1685481521 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvcC_b: 1685480259 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvvV_b: 1685476931 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvhe: 1701344868 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvh1: 828929636 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvcC: 1130591844 2020-12-21 10:54:43.198 T:10961 INFO <general>: dvvC: 1131837028

Seems like the m_hints.codec_tag is always 0 for MKV containers, tested with SDR, HDR10 and DV HEVC.

For MP4/MOV containers m_hints.codec_tag seems to work. I get 1701344868(which corresponds to MKTAG('d','v','h','e'), 828929636(MKTAG('d','v','h','1'), and last, 828601960 for an ordinary HDR10 MP4.

So it seems like a method for getting the codec_tag from MKVs needs to be implemented.

Nice, thanks for helping out.

Yes I suspect it would be always 0 and when something like that happens in my experience I just try to find something else.
If you look at your log you will see Side Data, this is one option.

Quote:INFO <general>: ffmpeg[0x2fbb06e040X]: DOVI configuration record: version: 1.0, profile: 7, level: 6, rpu flag: 1, el flag: 1, bl flag: 1, compatibility id: 6

This is done by av_packet_get_side_data

That's option number 1.

The second is to do something like MediaInfo did:

https://github.com/MediaArea/MediaInfoLi...11f3b2aff4

Quote:switch (BlockAddIDType)
{
case 0x64766343: // dvcC
case 0x64767643: // dvvC
Element_Name("Dolby Vision Configuration");
dvcC();
break;
case 0x68766345:
Element_Name("Dolby Vision EL HEVC");
#if MEDIAINFO_TRACE
if (Trace_Activated)
{

The first method would be much cleaner and have higher chances of being merged.
The problem is that I suck at writting C++ from scratch.

Now next problem, here with the Nvidia Shield TV Pro (2019) I got no black screen with "amc-hevc" and the movie plays just fine, colors seemed ok, tried with UHD BD Remux.
With "amc-dvhe" I get a ton of stuttering.
And I have not tested amc-dvh1.

So yeah... this will be a little bit harder but I think we can do it.

You can disregard the black screen bug. After a restart it plays fine with the amc-hevc codec. So it seems like it's the mime type that matters.

Regarding the ffmpeg log entry, I'm not seeing it. I have a suspicion I'm not building with your FFMPEG-fork - Is the correct place in the source treea

Code:
tools/depends/target/ffmpeg

I'm also seeing the ffmpeg source in

Code:
tools/depends/target/binary-addons/aarch64-linux-android-21-debug/build/ffmpeg/src/ffmpeg/

sk83 · 2020-12-21, 20:49

(2020-12-21, 17:42)sk83 Wrote: Regarding the ffmpeg log entry, I'm not seeing it. I have a suspicion I'm not building with your FFMPEG-fork - Is the correct place in the source treea
Code:
tools/depends/target/ffmpeg
I'm also seeing the ffmpeg source in

Code:
tools/depends/target/binary-addons/aarch64-linux-android-21-debug/build/ffmpeg/src/ffmpeg/

I was right re. the ffmpeg fork. I was building with the master branch, i.e. none of your changes was included. Still played DV though...

I've been trying to trace the m_hints struct through the code base, and this is how I _think_ it goes:

Code:
m_hints.codec_tag - CDVDStreamInfo.codec_tag - CDemuxStream.codec_fourcc - AVStream.codecpar.codec_tag

CDemuxStream can be of many types, one of them is CDemuxStreamVideoFFMPEG(DVDDemuxFFmpeg.cpp).
Internally CDemuxStreamVideoFFMPEG seem to operate on AVStream objects, which comes from ffmpeg. It seems AVStream has a codecpar.codec_tag property which needs to be set correctly for MKV files.

fandangos · 2020-12-21, 21:54

Ok, this is not my work alone.

@quietvoid started it by pulling ffmpeg source from Plex, doing diff on that and creating the first PR on Kodi's fork of FFMpeg requesting those changes.

After that, I have to thank @fritsch which is an amazing teacher and @lrusak that basically solve it all.

The FFMpeg changes needed are here:
https://github.com/fandangos/FFmpeg/tree...e/4.3-kodi

The changes needed in Kodi are here:
https://github.com/xbmc/xbmc/pull/18965

Build comming soon.

sk83 · 2020-12-21, 22:07

(2020-12-21, 21:54)fandangos Wrote: Ok, this is not my work alone.

@quietvoid started it by pulling ffmpeg source from Plex, doing diff on that and creating the first PR on Kodi's fork of FFMpeg requesting those changes.

After that, I have to thank @fritsch which is an amazing teacher and @lrusak that basically solve it all.

The FFMpeg changes needed are here:
https://github.com/fandangos/FFmpeg/tree...e/4.3-kodi

The changes needed in Kodi are here:
https://github.com/xbmc/xbmc/pull/18965

Build comming soon.

Awesome. Will try it out.

I just managed to get it to work myself, but it has to be considered a hack,

Adding

Code:
st->codecpar->codec_tag = MKBETAG('d','v','c','C');

to matroskadec.c in mkv_parse_dvcc_dvvc() results in m_hints.codec_tag being set for DV MKV streams.
This can then be checked for with MKTAG/MKBETAG checks in DVDVideoCodecAndroidCodec.cpp, and setting the mime accordingly makes it work. 11 lines total Wink

Your solutions looks fare more correct. Thanks!

hoppel118 · (This post was last modified: 2020-12-21, 22:41 by hoppel118.)

(2020-12-21, 21:54)fandangos Wrote: The FFMpeg changes needed are here:
https://github.com/fandangos/FFmpeg/tree...e/4.3-kodi

The changes needed in Kodi are here:
https://github.com/xbmc/xbmc/pull/18965

Build comming soon.

Am I getting you right? Does this code work?

Regards Hoppel