The VideoLAN Forums

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!

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)

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.

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,