Converting TS into AVI possible?

[Asimo]

I have a TS file with the following codecs:
video: H264 - MPEG-4 AVC (part 10)(h264)
audio: MPEG AAC Audio (mp4a)

The original TS file is 40 secs and 2.6Mbyte, and plays well in VLC.
I'd like to convert this TS into avi format, without too much loss in video and audio quality.


Test 1
I use the sout module with avi muxer. It produces a 2.0Mbyte avi without any audio stream.
This avi cannot be played with Media Player or other players using DirectShow. Sadly, only VLC can play it. It should be a codec problem.

vlc.exe test.ts -vvv -I dummy --sout=#:std{access=file,mux=avi,dst="test.avi"}

Test 2
I switched to ffmpeg muxer (and I installed the ffdshow-tryouts pack).
It produces a 2.35Mbyte avi, which can be played with Media Player (via ffdshow-tryouts codecs), but there is no audio.
However, VLC shows an MPEG AAC Audio (mp4a) in there, but no audio either.
When I switch to Statistics tab there are only 46 blocks decoded. In the original stream, there are approx. 1600 blocks decoded.
Furthermore, all DirectShow players show the video is 28 minutes long instead of the original 40 secs.
When playing, the first 40 secs video plays well, but then comes 27 minutes void (no video).
I played it through an Audio Grabbing directshow interface, which captures only 12 bytes audio constantly!
To compare, from a normal video, the interface captures an average 500msec long buffer.
Maybe vlc produces a buggy audio stream?
VirtualDub complains about "Variable bitrate audio detected. VBR audio in AVI is non-standard and you may encounter sync errors" Bitrate: 56.5 kbps. However, VirtualDub cannot recompress the audio (no decompressor found).

vlc.exe test.ts -vvv -I dummy --sout=#:std{access=file,mux=ffmpeg,dst="test.avi"}

Test 3
I decided to transcode the audio into mp3, to hear something. I use a very low 32Kbit bitrate for the audio.
But it generates a huge 5.9Mbyte avi, which is almost 2.5x bigger than the original file.
VLC can play the video+audio well, but Media Player plays the video only.
VirtualDub complains about "An invalid nBlockAlign value of zero in the audio stream format".

vlc.exe test.ts -vvv -I dummy --sout=#:transcode{acodec=mp3,ab=32}:std{access=file,mux=ffmpeg,dst="test.avi"}

Test 4
I load the avi into VirtualDub then save it with "Direct Stream Copy" for both audio and video, to keep the
original codecs. The result is a much friendier 2.2Mbyte avi, which can be played in Media Player and VLC well.
So why Test 3 produces such a big file?


My question is, is it possible to convert the TS file into AVI with the following requirements:

• no video recompression (the audio stream may be recompressed)

• the video can be played with a Windows DirectShow player (like Media Player) maybe with an additional codec-pack

• the avi file size is not (considerably) bigger than the original

The 3rd test is promising. Maybe there is an additional command line switch? Or there is an error in VideoLan?
I've checked the 1.1.7 and 1.1.2 versions.

[Asimo]

I have a quick workaround until I can do this properly with VLC alone. The solution combines the Test 3 and Test 4 experiences.

After converting the TS to AVI in Test 3, I call Virtualdub cmd line version to correct the resulted video file.

Code: Select all

vlc.exe test.ts -vvv -I dummy --sout=#:transcode{acodec=mp3,ab=32}:std{access=file,mux=ffmpeg,dst="test.avi"} vdub.exe /i avicorr.scr test.avi test2.avi

The trick lies in the arbitrary named avicorr.scr "script" file:

Code: Select all

VirtualDub.Open(VirtualDub.params[0]); VirtualDub.video.SetMode(0); VirtualDub.audio.SetMode(0); VirtualDub.SaveAVI(VirtualDub.params[1]);

This simple script opens the converted avi, then saves it into a new avi, while setting Direct Stream Copy mode for both video and audio streams. So no recompression involved, and vdub do this job fast. Not elegant but works.

[Asimo]

I can easily replicate the problem with an ordinary AVI by converting it into a TS file then converting it back into AVI.
Maybe this can help to identify the problem without having to have a TS file at hand.

Step 1, take the original avi then convert it into a H264/MP4A TS file:

Code: Select all

vlc.exe test-orig.avi -I dummy --sout=#:transcode{acodec=mp4a,ab=64,vcodec=h264}:std{access=file,mux=ts,dst="test-new.ts"}

Step 2, take this new TS file then convert it back into AVI and change only the audio:

Code: Select all

vlc.exe test-new.ts -I dummy --sout=#:transcode{acodec=mp3,ab=32}:std{access=file,mux=ffmpeg,dst="test-new.avi"}

This new AVI will be 2.4x times bigger than the new TS. And when I process it with VirtualDub (only Direct Stream Copy - no transcoding or recompression) the AVI size falls below the new TS file (approx. 85%).

What is this extra bytes that inflates the converted AVI so much?

[Asimo]

More thoughts on this AVI size inflation problem.

For size comparison, in my previous example, the new TS file is 3.4Mbytes. The converted new AVI is 8Mbytes.
When saving out the audio stream with vdub, the wav file is only 220Kbytes. The video without the audio is only 2.6Mbytes.
The 220K + 2.6MB = 2.8MB, so there must be 5.2MB garbage in the AVI produced by VLC.

Without any audio stream, VLC produces a reasonable sized AVI. It is almost equal to the size produced by vdub previously.

Code: Select all

vlc.exe test-new.ts -I dummy --sout=#:transcode{acodec=none}:std{access=file,mux=ffmpeg,dst="test-new.avi"}

After these tests, I thought the problem should coming from the MP3 part. But without the ffmpeg muxer, the AVI size won't inflated so much.
The resulted AVI is only 2.82MB. But this video cannot be played with MediaPlayer as I pointed it out earlier.

Code: Select all

vlc.exe test-new.ts -I dummy --sout=#:transcode{acodec=mp3,ab=32}:std{access=file,mux=avi,dst="test-new.avi"}

So the problem comes from the MP3 + FFMPEG combination?
With the mp2a codec the result is the same as with the mp3 codec. It must be the same lib I think.
It was hard to find an audio codec other than an mpeg variant. I choose a52 and the AVI size inflated as much as with mp3.

Is there a problem with the ffmpeg muxer?

Ok then. Let's see what can VLC does with the original avi.
The original avi is an MPEG-4 Video (DX50) with a PCM S16 audio, and is 15MB big.
This command produces a 8MB AVI, which can be downsized by vdub to 2.9MB as we seen before.
So this problem has nothing to do with the TS file or transcoding from a TS file.

Code: Select all

vlc.exe test-orig.avi -I dummy --sout=#:transcode{acodec=mp3,ab=32,vcodec=h264}:std{access=file,mux=ffmpeg,dst="test-new.avi"}

This test case proves that there must be something wrong with the ffmpeg muxer itself.
I remove the video stream (vcodec=none) and left an mp3 audio only. The resulted file is 5.6MB.
Unfortunately, I cannot save the audio with vdub (complains about the missing video stream), but if I subtract the real mp3 length of a 0.3MB, I got the 5.3MB garbage size. The audio can be heard with VLC.

Code: Select all

vlc.exe test-orig.avi -I dummy --sout=#:transcode{acodec=mp3,ab=32,vcodec=none}:std{access=file,mux=ffmpeg,dst="test-new.avi"}

I'm able to view this "audio only" avi with a hex-editor, to see what is inside.
There are repating bytes jammed into the real audio data:

30 30 77 62 00 00 00 00

These 8 bytes repeat 105 times (= 8*105 = 840 bytes) then 105 bytes real audio data follows. This pattern repeats through the whole file.

Examinig further the file, the data starts at 0x1612 (after many zeroes and header information).
The pattern ends at 0x2040A3. After this point, the pattern changed like this:

30 30 77 62 00 00 00 00 | 00 00 00 00 04 00 00 00
30 30 77 62 00 00 00 00 | 00 00 00 00 74 00 00 00
30 30 77 62 00 00 00 00 | 00 00 00 00 7C 00 00 00
30 30 77 62 00 00 00 00 | 00 00 00 00 84 00 00 00
etc.

The file ends at 0x596BC0. This is quite big area: 3.57MB!

If I assume this data useless, then there is a 2108050 bytes data inflated with those 840 bytes pattern.
So 105/840 = 12.5% valid data means 263506 bytes = 257KB, which seems the real MP3 audio length.

If I replace the ffmpeg muxer with the standard avi muxer, the AVI size is only 291KB.

Code: Select all

vlc.exe test-orig.avi -I dummy --sout=#:transcode{acodec=mp3,ab=32,vcodec=none}:std{access=file,mux=avi,dst="test-new.avi"}

In this case, the data starts at somewhere 0x2800 and ends at 0x40265. After this point, there is a similar pattern I seen in the previous big avi after 0x2040A4. This range is 0x40266-0x48E15. This is much shorter than the previous example, only 35KB. So the valid data length is approx. 252518 bytes = 247KB.

Conclusion: there must be a bug in the ffmpeg muxer which inflates the audio stream with strange bytes.

Could somebody please verify this weird behaviour in the source code?

(Maybe I should change the topic to "ffmpeg audio problem" or something like this)

[solazy]

Hello Asimo ,
I guess someone from Vlc staff will probably ask you to share this little TS file (2.6Mbyte) on rapidshare or megaupload etc... so they can try what you already did.
Also it would be interesting to get this file, for curious members who convert files into Avi, using Vlc or another converter.

[Asimo]

Hello Solazy,

Thank you for your reply. There is no need to download and test the TS file.
In my tests I figured out that there must be a problem in the ffmpeg muxer (libavformat?).

Anyway, I've tried to test the ffmpeg library alone, and downloaded the following cmd line version:

libavutil 50. 3. 0 / 50. 3. 0
libavcodec 52.27. 0 / 52.27. 0
libavformat 52.32. 0 / 52.32. 0
libavdevice 52. 2. 0 / 52. 2. 0
libswscale 0. 7. 1 / 0. 7. 1
libpostproc 51. 2. 0 / 51. 2. 0
built on Apr 21 2009 13:44:38, gcc: 4.2.4 (TDM-1 for MinGW)

...and converted the original AVI by removing the video stream and transcoding the audio into mp3:

Code: Select all

ffmpeg -i test-orig.avi -vn -acodec libmp3lame -ab 32k test-new.avi

The result is a fine 289KB "audio only" AVI, without those extra bytes. MediaPlayer is able to play this file.
(Remember, the same settings in VLC produces a 5.6MB file!)

So, this proves that the ffmpeg library is fine, if I did not miss something.

This led me to think there is a bug in VLC and FFmpeg interop.

[Asimo]

To close the original question: there is a way to convert the TS file into AVI without recompressing the video stream, the file size is not bigger than the original, and the video can be played via the Windows' DirectShow interface:

Code: Select all

ffmpeg.exe -i orig.ts -vcodec copy -acodec libmp3lame -ab 32k new.avi

And we have a new topic: what's wrong with VLC + FFmpeg muxer?