Proper parsing of DTS-HD MA streams
Good evening, I am writing to revive a discussion on proper parsing of DTS-HD MA in dca_parser.c and mpegts.c. There were discussions of both issues in June/July of this year. However, it looks as though the discussion lost steam, someone went on vacation, adequate samples weren't provided in time, etc. Most recent Fox and Sony blu-ray disks are coming out with DTS-HD MA audio tracks, and it would be nice to at least be able to pull out the DTS core. I have uploaded a sample to upload.mplayerhq.hu as /DTS-HD-MA/bond_sample_dtshdma.m2ts. Two issues are at play here. The first is the fact that the mpegts.c parser is not able to parse the m2ts and find the DTS-HD track, a discussion begun (and ultimately dying) here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048387.html The second issue is the fact that DTS-HD tracks are not playing properly in dca_parser.c because of an apparent variable frame size. Discussion here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048498.html I have uploaded a sample, tested the former patch and found it to more or less work (although I understand it needs to be done a certain way to be committed) and have uploaded a sample as requested in that long-ago thread. I stand ready to provide other samples, samples of greater size, and otherwise do whatever I can to assist in solving this problem. Thanks a lot. Robert
On Tue, Nov 25, 2008 at 06:11:56PM -0800, Robert McNamara wrote:
Good evening,
I am writing to revive a discussion on proper parsing of DTS-HD MA in dca_parser.c and mpegts.c.
There were discussions of both issues in June/July of this year. However, it looks as though the discussion lost steam, someone went on vacation, adequate samples weren't provided in time, etc. Most recent Fox and Sony blu-ray disks are coming out with DTS-HD MA audio tracks, and it would be nice to at least be able to pull out the DTS core. I have uploaded a sample to upload.mplayerhq.hu as /DTS-HD-MA/bond_sample_dtshdma.m2ts.
Two issues are at play here. The first is the fact that the mpegts.c parser is not able to parse the m2ts and find the DTS-HD track, a discussion begun (and ultimately dying) here:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048387.html
The second issue is the fact that DTS-HD tracks are not playing properly in dca_parser.c because of an apparent variable frame size. Discussion here:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-June/048498.html
I have uploaded a sample, tested the former patch and found it to more or less work (although I understand it needs to be done a certain way to be committed) and have uploaded a sample as requested in that long-ago thread. I stand ready to provide other samples, samples of greater size, and otherwise do whatever I can to assist in solving this problem. Thanks a lot.
Robert
Thank you for the sample. I'll try to find some time to improve parser.
Kostya schrieb:
Thank you for the sample. I'll try to find some time to improve parser.
See here how to properly parse and skip DTS-HD blocks: http://forum.doom9.org/showthread.php?p=1183481#post1183481 https://ffdshow-tryout.svn.sourceforge.net/svnroot/ffdshow-tryout/branches/l... Search for "blownUpHeader". Regards, madshi.
On Wed, Nov 26, 2008 at 1:08 AM, madshi <dear at madshi.net> wrote:
Kostya schrieb:
Thank you for the sample. I'll try to find some time to improve parser.
See here how to properly parse and skip DTS-HD blocks:
http://forum.doom9.org/showthread.php?p=1183481#post1183481
https://ffdshow-tryout.svn.sourceforge.net/svnroot/ffdshow-tryout/branches/l...
Search for "blownUpHeader".
Regards, madshi. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Thank you Kostya and Madshi both for looking into this. I'm thrilled to see that a lot of the heavy lifting is already done and hope that this will be a snap. In what may be an unpopular move, I've updated the previous patches to mpegts.c/h to properly parse the tracks. I know there was some resistance to this before, but perhaps since we're starting fresh, cool heads can prevail and we can figure out a way that it makes sense to get this committed. I've changed the patch somewhat to create a case for TrueHD to point at the MLP codec (I think it was mistakenly included in AC3 before) and I've added stream definition for LPCM so that it at least is parse correctly in m2ts. I tested pointing Bluray LPCM at CODEC_ID_PCM_S16LE, but that seems not to work properly just yet so I left it out. I have tested these parser updates and found them to work with LPCM (0x80, even though it is technically misidentified as mp1), DTS-HD (0x85), and DTS-HD MA (0x86). I don't have any disks that include E-AC-3 (0x84) or MLP/TrueHD (0x83) so I wasn't able to test those. I should note that the parser hangs entirely on these samples without the patches. With this patch applied, ffmpeg -i infile works as expected and picks up all the tracks in all of my disks (about 30). Thanks, guys. Robert
I tested pointing Bluray LPCM at CODEC_ID_PCM_S16LE
Blu-Ray LPCM can be 16bit or 24bit (or 20bit stored as 24bit). Also there's a 4 byte header in every LPCM PES packet.
I don't have any disks that include E-AC-3 (0x84) or MLP/TrueHD (0x83) so I wasn't able to test those.
There is only one sample available world wide with E-AC3 and that is from a Dolby demo disc. So we can forget about that for now. It's not needed in real life. I've uploaded an AC3/TrueHD sample and two LPCM samples here: (1) http://madshi.net/hd_dolby_true_hd.m2ts (2) http://madshi.net/LPCM-3-1.m2ts (3) http://madshi.net/lpcm-96-kHz.m2ts Here are the reports for those 3 samples from my tool "eac3to": (1) M2TS, 1 video track, 1 audio track, 0:00:12 1: h264/AVC, 1080i60 /1.001 (16:9) 2: TrueHD/AC3, 7.1 channels, 96khz (embedded: AC3, 5.1 channels, 640kbps, 48khz) (2) M2TS, 1 video track, 2 audio tracks, 1 subtitle track, 0:00:09 1: h264/AVC, 1080p24 /1.001 (16:9) 2: RAW/PCM, 2.0 channels, 16 bits, 48khz, -376ms 3: RAW/PCM, 3/1 channels, 16 bits, 48khz, -376ms 4: Subtitle (PGS) (3) M2TS, 1 video track, 1 audio track, 0:00:03 1: h264/AVC, 1080i60 /1.001 (16:9) 2: RAW/PCM, 7.1 channels, 24 bits, 96khz If there are any questions, just let me know... Regards, madshi.
There is only one sample available world wide with E-AC3 and that is from a Dolby demo disc. So we can forget about that for now. It's not needed in real life.
Good to know. I'm actually attaching a version of the patch that removes the LPCM parsing for right now-- it seems that some streams parse fine, and some get hung up. Not sure why, and it's over my pay grade to find out.
I've uploaded an AC3/TrueHD sample and two LPCM samples here:
(1) http://madshi.net/hd_dolby_true_hd.m2ts (2) http://madshi.net/LPCM-3-1.m2ts (3) http://madshi.net/lpcm-96-kHz.m2ts
Thanks a lot for this. It helped.
<http://madshi.net/lpcm-96-kHz.m2ts>
Here are the reports for those 3 samples from my tool "eac3to":
(1) M2TS, 1 video track, 1 audio track, 0:00:12 1: h264/AVC, 1080i60 /1.001 (16:9) 2: TrueHD/AC3, 7.1 channels, 96khz (embedded: AC3, 5.1 channels, 640kbps, 48khz)
FFMPEG Output with patch applied: Input #0, mpegts, from 'hd_dolby_true_hd.m2ts': Duration: 00:00:12.01, start: 600.000000, bitrate: 22213 kb/s Program 1 Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 29.97 tb(r) Stream #0.1[0x1100]: Audio: mlp, 96000 Hz, 7.1, s16 I didn't try the other two since the LPCM parsing is problematic at the moment (probably because it's defaulting to MP1 as the codec). Here is the output of a DTS-HD stream with the patch applied, though, just to show that it's working. AFAICT Bluray audio PIDs start at 0x1100 and increment from there, so it's pretty easy to tell when a track isn't being parsed. Input #0, mpegts, from '/MythMedia/movies/For Your Eyes Only.m2ts': Duration: 02:07:59.29, start: 11.650667, bitrate: 31823 kb/s Program 1 Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 23.98 tb(r) Stream #0.1[0x1100]: Audio: dca, 48000 Hz, 5.1, s16, 1536 kb/s Stream #0.2[0x1101]: Audio: ac3, 48000 Hz, stereo, s16, 224 kb/s Stream #0.3[0x1102]: Audio: ac3, 48000 Hz, stereo, s16, 224 kb/s Stream #0.4[0x1103]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s Stream #0.5[0x1104]: Audio: ac3, 48000 Hz, stereo, s16, 224 kb/s Stream #0.6[0x1105]: Audio: ac3, 48000 Hz, stereo, s16, 224 kb/s Stream #0.7[0x1106]: Audio: ac3, 48000 Hz, stereo, s16, 224 kb/s On unpatched ffmpeg, the parser just hangs and has to be Ctrl-C'd. Hopefully this is adequate to get the mpegts improvements committed so that Kostya can have an easier time of getting the DCA parsing working. To summarize, all stream IDs except for E-AC-3 (0x84) in this patch have been tested and are working properly. As Madshi mentions, this one does not exist in the wild, but it doesn't seem to be harmful to include it to be as complete as possible. I have tested stream copies of these audio tracks and they are working correctly. Hopefully someone can take a quick look at this and commit if appropriate. Thanks, Robert
On 11/26/2008 06:30 PM, Robert McNamara wrote:
On Wed, Nov 26, 2008 at 1:08 AM, madshi<dear at madshi.net> wrote:
Kostya schrieb:
Thank you for the sample. I'll try to find some time to improve parser.
See here how to properly parse and skip DTS-HD blocks:
http://forum.doom9.org/showthread.php?p=1183481#post1183481
https://ffdshow-tryout.svn.sourceforge.net/svnroot/ffdshow-tryout/branches/l...
Search for "blownUpHeader".
Regards, madshi. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Thank you Kostya and Madshi both for looking into this. I'm thrilled to see that a lot of the heavy lifting is already done and hope that this will be a snap.
In what may be an unpopular move, I've updated the previous patches to mpegts.c/h to properly parse the tracks. I know there was some resistance to this before, but perhaps since we're starting fresh, cool heads can prevail and we can figure out a way that it makes sense to get this committed. I've changed the patch somewhat to create a case for TrueHD to point at the MLP codec (I think it was mistakenly included in AC3 before) and I've added stream definition for LPCM so that it at least is parse correctly in m2ts. I tested pointing Bluray LPCM at CODEC_ID_PCM_S16LE, but that seems not to work properly just yet so I left it out. I have tested these parser updates and found them to work with LPCM (0x80, even though it is technically misidentified as mp1), DTS-HD (0x85), and DTS-HD MA (0x86). I don't have any disks that include E-AC-3 (0x84) or MLP/TrueHD (0x83) so I wasn't able to test those.
I should note that the parser hangs entirely on these samples without the patches. With this patch applied, ffmpeg -i infile works as expected and picks up all the tracks in all of my disks (about 30).
Git-friendly patch attached so patchwork will catch it up. -Vitor
From robert.mcnamaraatgmail.com Sun Jan 23 17:16:21 2011 From: robert.mcnamaraatgmail.com (Robert McNamara) Date: Sun, 23 Jan 2011 17:16:21 +0100 Subject: [PATCH] Properly parse and skip DTS-HD blocks Message-ID: <mailman.464.1295799488.1307.ffmpeg-devel@mplayerhq.hu>
--- libavformat/mpegts.c | 12 ++++++++++++ libavformat/mpegts.h | 5 +++++ 2 files changed, 17 insertions(+), 0 deletions(-) diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c index 48aca43..037d16f 100644 --- a/libavformat/mpegts.c +++ b/libavformat/mpegts.c @@ -616,6 +616,11 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t *section, int section_len /* now create ffmpeg stream */ switch(stream_type) { + case STREAM_TYPE_AUDIO_HDMV_LPCM: + case STREAM_TYPE_AUDIO_HDMV_DTS_HD: + case STREAM_TYPE_AUDIO_HDMV_DTS_HD_MASTER: + case STREAM_TYPE_AUDIO_HDMV_TRUEHD: + case STREAM_TYPE_AUDIO_HDMV_EAC3: case STREAM_TYPE_AUDIO_MPEG1: case STREAM_TYPE_AUDIO_MPEG2: case STREAM_TYPE_VIDEO_MPEG1: @@ -968,12 +973,19 @@ static AVStream* new_pes_av_stream(PESContext *pes, uint32_t code) codec_type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_AAC; break; + case STREAM_TYPE_AUDIO_HDMV_TRUEHD: + codec_type = CODEC_TYPE_AUDIO; + codec_id = CODEC_ID_MLP; + break; case STREAM_TYPE_AUDIO_AC3: + case STREAM_TYPE_AUDIO_HDMV_EAC3: codec_type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_AC3; break; case STREAM_TYPE_AUDIO_DTS: case STREAM_TYPE_AUDIO_HDMV_DTS: + case STREAM_TYPE_AUDIO_HDMV_DTS_HD: + case STREAM_TYPE_AUDIO_HDMV_DTS_HD_MASTER: codec_type = CODEC_TYPE_AUDIO; codec_id = CODEC_ID_DTS; break; diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h index 896836d..6b09455 100644 --- a/libavformat/mpegts.h +++ b/libavformat/mpegts.h @@ -54,9 +54,14 @@ #define STREAM_TYPE_VIDEO_VC1 0xea #define STREAM_TYPE_VIDEO_DIRAC 0xd1 +#define STREAM_TYPE_AUDIO_HDMV_LPCM 0x80 #define STREAM_TYPE_AUDIO_AC3 0x81 #define STREAM_TYPE_AUDIO_DTS 0x8a #define STREAM_TYPE_AUDIO_HDMV_DTS 0x82 +#define STREAM_TYPE_AUDIO_HDMV_TRUEHD 0x83 +#define STREAM_TYPE_AUDIO_HDMV_EAC3 0x84 +#define STREAM_TYPE_AUDIO_HDMV_DTS_HD 0x85 +#define STREAM_TYPE_AUDIO_HDMV_DTS_HD_MASTER 0x86 #define STREAM_TYPE_SUBTITLE_DVB 0x100 -- 1.7.1 --------------050207020403090505070106--
participants (4)
-
dear＠madshi.net -
kostya.shishkov＠gmail.com -
robert.mcnamara＠gmail.com -
vitor1001＠gmail.com