After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 777188 - dcaparse: parses dts from audiocd wrongly
dcaparse: parses dts from audiocd wrongly
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-01-12 18:44 UTC by christophe vr
Modified: 2018-11-03 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
dcaparse: output caps with depth=16, and custom dcadepth (1.73 KB, patch)
2017-03-20 11:10 UTC, Vincent Penquerc'h
none Details | Review

Description christophe vr 2017-01-12 18:44:51 UTC
Hi I just discovered a possible issue about the dca parser of dts audio with cd as origin. Research has showed that all those audio cd's do respect the base dts standards , but well did put a 0 to the last two data bits , this to avoid ears problems and speakers destruction in older base stereo systems who are only using downmixed versions. The data part self is still of a depth off 16 (16 bits) but the cap after parsing does report a depth of 14 which is wrong. So in case off use of cap pass-trough the target systems do expect the data buffer 2 bits shorter then it actually is. This means dts audio coming from a cd is reported with a cap :

"CAP audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)14, block-size=(int)1024, frame-size=(int)4096"

While it actually is a real data buffer whit should have a cap of: 

"CAP audio/x-dts, framed=(boolean)true, rate=(int)44100, channels=(int)6, endianness=(int)1234, depth=(int)16, block-size=(int)1024, frame-size=(int)4096"

And I also think that the endianess should be (int) 4321 .
Comment 1 christophe vr 2017-01-12 19:27:29 UTC
as extra info I added here two links to media coming from audio cd for test purposes about the dca parser and build caps by the parser.

https://www.dropbox.com/s/6xngtwz8g7abxbn/Youre-My-Heart-Youre-My-Soul.dts?dl=1

https://www.dropbox.com/s/mrdlp1noi924kda/surroundTestDTS-dtsonly.dts?dl=1
Comment 2 Vincent Penquerc'h 2017-03-20 11:10:06 UTC
Created attachment 348307 [details] [review]
dcaparse: output caps with depth=16, and custom dcadepth

The 14/16 was done deliberately, so I'm not sure this patch is OK. There might be other samples on which this breaks I suppose.
Comment 3 christophe vr 2017-03-31 12:05:08 UTC
Hi I tried, but it still does not work on a stb. But analyzing further.
Yes with the 14/16 the buffer which is finally pushed does has already the first byte of next sync word into it. This can't work.
On top of it and that is a stb driver issue , the driver does not support little endian for the time , this means that even if the buffer send from out of gstreamer using dcaparse is right it still would not work.
Comment 4 christophe vr 2017-03-31 12:21:34 UTC
Also on a stb , the audio DTS audio of type HD MASTER-AUDIO does work passtrough (this means it is parsed ok by dcaparse) But for some stb's who do not have dts codecs on board we normally use the plugin dtsdec or gst-libav (avdec_dca).

On a stb the package audioparsers (plugin good is also installed) since off course we need also parsing off ac3 and so on , those codecs are on board by almost all stb's. 

Now for the media samples off type HD master-audio and using dtsdec or avdec_dca does not work if audioparsers dcaparser is installed (the other dts codecs  are well working with downmix).

If I do :

"gst-launch-1.0 ---gst-debug-no-color filesrc location=dts_hd_master_audio_sound_check_7_1_lossless-DWEU.mkv \
! matroskademux name=demux demux. ! queue ! h264parse ! dvbvideosink demux. ! queue ! avdec_dca ! audioconvert ! audioresample ! dvbaudiosink"

The HD master audio plays fine on a stb using downmix.

If I do :

"gst-launch-1.0 \
playbin uri=file:///media/VIDAUD/test/dts_hd_master_audio_sound_check_7_1_lossless-DWEU.mkv"

It does not work with HD master-audio with other dts codecs it is ok.

If on that stb I remove the libgstaudioparsers.so . It works for all dts audio with :

"gst-launch-1.0 \
playbin uri=file:///media/VIDAUD/test/dts_hd_master_audio_sound_check_7_1_lossless-DWEU.mkv"

I 'm trying to find where in to gstreamer code I could set that in case the DTS stream does not has a valid static cap into the stb customed audiosink, then the downmix if installed will be used (dtsdec or eventually gst-libav avdec_dca) That is well so but it would be nice that the dcaparse is not used since it is not required in that case. Then all dts audio works fined downmixed to S32LE raw
Comment 5 christophe vr 2017-03-31 12:40:32 UTC
here the link to a good HD master audio sample .

"https://www.dropbox.com/s/d34395ofwz18yxb/dts_hd_master_audio_sound_check_7_1_lossless-DWEU.mkv?dl=1"
Comment 6 christophe vr 2017-04-01 06:21:24 UTC
I did some extra checks, by a stb.

For some stb's without internal dts codecs at all. The required customed dvbaudiosink build without dtscaps then, gstreamers plugins good audioparsers build without dcaparser (removed dcaparse.c/h adapted MakeFile.am and plugin.c for that)

When using gst-libav (avdec_dca) the dts types who are playing (downmixed then)
standard DTS OK , DTS master-audio ok.
Dts audio (14 bits little endian) not ok (stream error) , Dts Hd 96/24 in vob container not ok. 

When using the dtsdec plugin , all dts audio plays 100 % without dcaparser parser.
Comment 7 GStreamer system administrator 2018-11-03 15:16:03 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/343.