The VideoLAN Forums

Hi all,

after deeply searching how to replex on the fly my old VDR PES/TS samples and recordings for mediatomb[1] I've detected that (c)vlc does copy the video ES from the 001.vdr but change the audio codec from DTS 5.1 to eac3 2.1 which is not what I want. I've tried
and always ffprobe reports an eac3 2.1 audio stream. Is there a way to force sout module not to transcode the audio streams like LPCM, DTS, AC3, AC3 DVB[2], and MPEG2 into an AC3 2.1 stream?
Interesting the video codec and layout is not changed with the lines above

I've also seen that the "es" module does not transcode but the audio stream(s) are not in sync with the video stream anymore ... this sound logical as now two or more sout channels write to the same file. Also the "transcode" module does not have the acodec=copy nor does an empty `{}' help.

Werner

[1] I'm using mediatomb to replay not only on VDR/PC but also on the TV as well as on the oppo
[2] AC3 DVB is AC3 without a Substream Header that is plain AC3 frames in payload of the first Private Stream

Stream output does not transcode unless explicitly requested.

Stream output does not transcode unless explicitly requested.

Does this mean I should file a bug? The version is vlc-2.0.8a and the resulting audio stream differs

IN Stream #0:1[0x88]: Audio: dts (DTS), 48000 Hz, 5.1(side), s16, 1536 kb/s
OUT Stream #0:1[0x88]: Audio: eac3, 24000 Hz, 2.1, s16, 72 kb/s

done with

IMHO there could be a bug in the substream header of the PS1 stream in the resulting Mepg-PS file. A od -v -t x1 shows in the orignal
and in the result
which does not fulfill the specs ... compare the substream header between the PS1 start 00 00 01 bd
and the DTS sync word 7f fe 80 01 ... IMHO substream audio header after the PTS is wrong in the result
as it should IMHO look like `88 01 00 01' and not `88 00 00 00' that is the DTS substream number 0x88
followed by the next byte the DTS frame count and followed by two bytes for the offset into the
payload that is 00 01

Indeed my old xlist c++ scanner tool from the old bitstreamout vdr plugin does not find any DTS stream in the resulting j.mpg but this c++ code uses the ISO audio substream header for the PS1 ES

Just done a now xlist identifies the DTS substream but ffprobe fails ... maybe there is also some problem with the PS1 header as well. On the first sight the length is 5 bytes in comparision to the 8 bytes of the original. The PTS bit is set as well but the header is not double word aligned (the missing three bytes of the header lenght ) ... maybe ffprobe can not handle this?

I've been pondering about it ... and AFAICR some older hardware decoders based on e.g. Big-Endian ARM do have problems if byte streams are not word aligned. I can remember on an AV7110 that accessing odd-numbered addresses in memory (that is not word aligned data) had caused trouble, that is that one had to read byte by byte which was much slower than reading even-numbered addressed words at once this becasue it was not possible to read word correct accross this boundary. Nevertheless reading and utilizing words on Big-Endian is a pleasure as I've learned on AV7110 as it makes it much more easier to analyze MPEG streams and also to encapsulate AC3, DTS or even MPEG2-Audio accrodingly to IEC/ISO 61937 into S/P-DIF (IEC/ISO 60958).