sout without transcoding audio codec

[bitstreamout]

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

Code: Select all

cvlc --sout='#standard{all,keep,access=file,mux=ps,dst=j.mpeg}' 'dts Piano/2001-07-02.00:20.99.99.rec/001.vdr' cvlc --sout='#file{all,keep,access=file,mux=ps,dst=j.mpeg}' 'dts Piano/2001-07-02.00:20.99.99.rec/001.vdr' cvlc --sout='#gather:standard{all,keep,access=file,mux=ps,dst=j.mpeg}' 'dts Piano/2001-07-02.00:20.99.99.rec/001.vdr'

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

[Rémi Denis-Courmont]

Stream output does not transcode unless explicitly requested.

[bitstreamout]

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

Code: Select all

video/Tests> ffprobe 'dts Piano/2001-07-02.00:20.99.99.rec/001.vdr' ffprobe version 1.0.5 Copyright (c) 2007-2012 the FFmpeg developers [...] Input #0, mpeg, from 'dts Piano/2001-07-02.00:20.99.99.rec/001.vdr': Duration: 00:00:19.04, start: 0.280633, bitrate: 8914 kb/s Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x480 [SAR 32:27 DAR 16:9], 7500 kb/s, 25.67 fps, 59.94 tbr, 90k tbn, 59.94 tbc Stream #0:1[0x88]: Audio: dts (DTS), 48000 Hz, 5.1(side), s16, 1536 kb/s video/Tests> cvlc --play-and-exit --sout="#standard{all,keep,access=file,mux=ps,dst=j.mpg}" 'dts Piano/2001-07-02.00:20.99.99.rec/001.vdr' VLC media player 2.0.8 Twoflower (revision 2.0.8a-0-g68cf50b) [0x1338d88] main interface error: no suitable interface module [0x11b37c8] main libvlc error: interface "globalhotkeys,none" initialization failed [0x1338d88] dummy interface: using the dummy interface module... [0x7fe7d00040c8] mux_ps mux: Open [0x7fe7d0c469e8] dts decoder: DTS channels:6 samplerate:48000 bitrate:1536000 [0x7fe7d00040c8] mux_ps mux: Close [0x11c72f8] main playlist: end of playlist, exiting video/Tests> ffprobe j.mpg ffprobe version 1.0.5 Copyright (c) 2007-2012 the FFmpeg developers [...] Input #0, mpeg, from 'j.mpg': Duration: 00:00:18.95, start: 1006.477689, bitrate: 8903 kb/s Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x480 [SAR 32:27 DAR 16:9], 7500 kb/s, 25.67 fps, 59.94 tbr, 90k tbn, 59.94 tbc Stream #0:1[0x88]: Audio: eac3, 24000 Hz, 2.1, s16, 72 kb/s

[bitstreamout]

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

Code: Select all

0730574 00 00 00 00 01 bd 07 ec 81 80 08 21 00 01 cc d3 0730614 ff ff ff 88 01 00 01 7f fe 80 01 fc 3c 7d c2 77

and in the result

Code: Select all

0162200 00 00 00 00 01 bd 07 e9 80 80 05 21 3f 73 72 9f 0162220 88 00 00 00 7f fe 80 01 fc 3c 7d c2 77 00 0d 3a

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

[bitstreamout]

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

[bitstreamout]

Just done a

Code: Select all

sed -ri 's@\x88\x00\x00\x00\x7f\xfe\x80\x01@\x88\x01\x00\x01\x7f\xfe\x80\x01@g' j.mpg

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?

[bitstreamout]

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).