File transcoded by VLC contains 20% of redundant/dummy info?

[madRat]

Hello!

I've faced a problem with transcoding to MPEG4 (see my post MPEG4 ASP transcoding issues) and after some more in-depth analysis of resulting mp4 files I have found a bug:
The resulting file transcoded by VLC seems to contain a log of dummy/redundant information. In particular, I see a lot of small blocks filled with 0xFF. When I pack the transcoded video with GZip I obtain up-to 20% compression. I consider this as a major bug since when we stream video we just waste about 20% of traffic/bitrate. I've tried to transcode with ffmpeg and found no 0xFF-blocks and GZip shows only 5% of compression as expected.

I have uploaded the source and the transcoded videos to the internet, so that everyone can easily check it:

Source file: http://aldebaran.spb.ru/vlc/source.avi

Transcoding command lines and files:

1. Ffmpeg (CentOS) transcoding
ffmpeg -i source.avi -f mp4 -s 320x240 -vcodec mpeg4 -r 25 -b 300K -acodec mp3 -ab 48k ffmpeg.no-bframes.mp4
Result: http://aldebaran.spb.ru/vlc/ffmpeg.no-bframes.mp4
Compress ratio = 4%.

2. Vlc 0.8.6d (CentOS) transcoding
TRANSCODE='#transcode{vcodec=mp4v,venc=ffmpeg,fps=25,vb=300,width=320,height=240,acodec=mp3,samplerate=32000,channels=1,ab=48,threads=2}'
STORE="standard{access=file,mux=mp4,dst=vlc.no-bframes.mp4}"
vlc $1 --sout=$TRANSCODE:$STORE vlc:quit
Result: http://aldebaran.spb.ru/vlc/vlc.no-bframes.mp4
Compress ratio = 12%.

3. Vlc 0.8.6f (Win32) transcoding (cause i transcode from GUI i can show command line )
Result: http://aldebaran.spb.ru/vlc/vlc.win32.no-bframes.mp4
Compress ratio = 17%.

I would appreciate any help or just hints related to this issue. Looking forward to your comments!

[madRat]

Hello!
Is there anybody who can reproduce the problem? Is there anybody who tried and failed to reproduce the problem?

PS. Is there anybody out there? (C)

[PureVirtual]

madRat, I didn't try to reproduce the problem but I noticed by accident a couple of weeks ago while transcoding video with Windows version of VLC, that the same video content weights significantly much (about 20%) when saved using TS than using MP4 as container. I thought it's rather strange, but I'm new to video compression, so I didn't pay much attention to that.

[madRat]

I have found what is wrong with transcoded MPEG4 file: All MPEG4 Video's P-frames contain incorrect modulo_time_base field.

According to documentation, modulo_time_base field should almost always be 0, and very rarely be 1. It is said that it is almost impossible modulo_time_base to be greater than 1. That's probably why the field is encoded in 1-based scale of notation.

According to our tests for all the encoded P-frames the modulo_time_base field is constant and equals to 1604, which is 1604 bits long (200 bytes long) in 1-based notation. That's why the transcoded file contains up-to 20% of 0xFF bytes.

We would greatly appreciate any help on this topic! Can anybody advice us what is the best way to resolve the situation?

Sincerely,