GNOME Bugzilla – Bug 703913
tsdemux: LPCM audio track not detected
Last modified: 2018-11-03 13:16:40 UTC
Summary: * Bad: LPCM audio is ignored in tsdemux plugin. Description: Overview: I am trying to play a mpeg ts file with h264 video and lcpm audio in it. But "mpegtsdemux" is ignoring the audio and source pad is created only for video. I added logs in "mpegtsdemux and tsdemux" and printed stream_id and stream_type for the same. It is stream_id=0xbd and stream_type=0x83. I saw in the tsdemux and mpegtsdemux source code that stream_type=0x83 is mapped to ST_BD_AUDIO_AC3_TRUE_HD and is not handled. But vlc is recognizing it as DVD lpcm audio. I used "dvbsnoop" ubuntu utility to analyze the stream. Below is what it says about audio section.(for one of the ts packets) Sync-Byte 0x47: 71 (0x47) Transport_error_indicator: 0 (0x00) [= packet ok] Payload_unit_start_indicator: 1 (0x01) [= Packet data starts] transport_priority: 0 (0x00) PID: 68 (0x0044) [= ] transport_scrambling_control: 0 (0x00) [= No scrambling of TS packet payload] adaptation_field_control: 1 (0x01) [= no adaptation_field, payload only] continuity_counter: 0 (0x00) [= (sequence ok)] Payload: (len: 184) ==> PES-stream: 189 (0xbd) [= private_stream_1] But "mpegtsdemux and tsdemux" src pad claims the it can candle "audio/x-private-ts-lpcm" and "audio/x-lpcm". SRC template: 'audio_%04x' Availability: Sometimes Capabilities: audio/mpeg mpegversion: 1 audio/mpeg mpegversion: 4 stream-format: adts audio/x-lpcm width: { 16, 20, 24 } rate: { 48000, 96000 } channels: [ 1, 8 ] dynamic_range: [ 0, 255 ] emphasis: { false, true } mute: { false, true } audio/x-ac3 audio/x-eac3 audio/x-dts audio/x-private-ts-lpcm I am using 0.10.22.3 version of gstreamer bad plugings but the issue is seen in 1.x also. Steps to Reproduce: Actual Results: Only video pad is created and audio is ignored. Expected Results: It should handle both audio(LPCM) and video as src pad capability says. Platform: On ubuntu 12.04
Hi, could you provide a sample file ? I still am having a hard time finding any "official" specifications/documents concerning those "legacy" stream_type.
Sample file I am using is of huge size 90Mb to attached here. Is there a ftp kind of thing you are using. If so please provide me details. I will upload it there.
Googling for "free upload service" on the internet should give you plenty of sites where you can upload the file. Then provide the link to it here.
The first few kB might be enough to reproduce the problem: head --bytes=750k foo.ts > head.ts then attach head.ts to this bug report (but a full file would better)
Created attachment 248810 [details] sample test case Sample test case to reproduce the issue.
Thats exactly what I was trying to do. I have attached first 750Kb of my sample file here. and I have truncated first 5Mb of sample file and uploaded in wikisend which you can download using following link http://wikisend.com/download/289624/test.ts Note: Time to live is 7 days
So I have a fix to expose stream_type 0x83 ... but I have no idea which of the following types it is: audio/x-lpcm audio/x-private1-lpcm audio/x-private-ts-lpcm
Created attachment 248828 [details] [review] tsdemux: Support 0x83 stream_type It seems to be legacy DVD LPCM ... but needs further checks
Have you verified you fix with "dvdlpcmdec"
Hi, I'm going through this. I do not think dvdlpcmdec will decode LPCM in a TS. The header seems to be different as per http://stnsoft.com/DVD/ass-hdr.html compared to what it should be in TS Edward, Have got hold of SMPTE doc which which explains AES3 data in TS. It's at http://hackipedia.org/File%20formats/Codecs/audio/AES/S302m-2002%20-%20Mapping%20of%20AES3%20Data%20into%20an%20MPEG-2%20Transport%20Stream.pdf Regards, Jagadish
And according to this, it says the stream_type should be 6(Private data) and LPCM detection should happen through registration descriptor(just like in case of AC3)
Can you provide a patch properly detecting this case (with the BSSD descriptor) ?
-- 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-bad/issues/100.