Set-top boxes show wrong Aspect Ratio on HD content

[jdachik01]

Source material does not matter.

Any HD content done at standard resolutions (1280x720 or 1920x1080) displays as "Aspect Ratio: 1:1" in TS Reader. TS Reader is showing what most set-top boxes show.

I have found that adjusting the resolution to an "incorrect" resolution - e.g. 1270x720, or 1290x720 - fixes the issue, but that is not a solution. The only difference in the CLI output generated by ffmpeg is the SAR, which is 1:1 when 1280x720 is the size selected, and a different value when an "incorrect" resolution is specified. Could there be a flag that ffmpeg is setting at 1:1 which should be 16:9?

ffmpeg -v 9 -loglevel 99 -i C:\lngm1210h.mpg -s 1280x720 -aspect 16:9
-threads 8 -vcodec mpeg2video -vb 13010k -minrate 13010k -maxrate 13010k -muxrat
e 13600k -bufsize 1835000 -r 59.94 -pix_fmt yuv420p -bf 2 -g 15 -ss 0 -y -acodec

mp2 -ar 48000 -ab 192k -copyts -f mpegts 169test.mpg 2>169LOG.log

[jdachik01]

Log of 1280x720

[jdachik01]

Log of 1270x720

[jdachik01]

Link to download TS Reader Lite:

​http://www.tsreader.com/tsreader/TSReaderLite2.8.46g.exe

[Carl Eugen Hoyos]

Afaict, a sample aspect ratio of 1:1 is correct for your 1280x720 output file and that is also what FFmpeg shows or do I miss something.

[jdachik01]

I'm aware that is correct.

The problem is that TS Reader shows the Aspect Ratio (DAR) as 1:1

Set-top boxes also must be reading this because they display the HD, 16:9 content as 1:1 (square).

Please download TS Reader from the link and see for yourself.

Thank you for looking at this.

[jdachik01]

FYI - this problem does not exist on the latest 64-bit Windows build of ffmbc:

​http://code.google.com/p/ffmbc/

It *does* exist with the 32-bit version.

Hoping to get it fixed on all versions of ffmpeg and ffmbc.

[Carl Eugen Hoyos]

Replying to jdachik01:

FYI - this problem does not exist on the latest 64-bit Windows build of ffmbc:

​http://code.google.com/p/ffmbc/

It *does* exist with the 32-bit version.

Please provide short samples of all three variants (ffmbc x 2 and ffmpeg), if possible made with identical command lines.

[jdachik01]

About to attach numerous files:

.mpg files made with each
.jpg showing TS Reader analysis
.log log of each

Each used same command line:

ffmxxx -v 9 -loglevel 99 -i 169test.mov -t 2 -s 1280x720 -aspect 16:9 -threads 8 -vcodec mpeg2video -vb 13010k -minrate 13010k -maxrate 13010k -muxrate 13600k -bufsize 4M -r 59.94 -pix_fmt yuv420p -bf 2 -g 15 -ss 0 -y -acodec mp2 -ar 48000 -ab 192k -f mpegts outputfile.mpg 2>outputlog.log

[jdachik01]

Had to redo with -t 1 to get file size under limit.

You can ignore 169test-ffmbc64.2.mpg - uploaded by accident.

Thanks again.

[Carl Eugen Hoyos]

Do I understand correctly that the problem is not so much the output of your analyser software but that set-top-boxes play the output file(s) with an incorrect display aspect ratio?

[jdachik01]

That is correct.

I only mention/include TS Reader because it is the only program I can find that shows the issue that is causing the set-top box to incorrectly display the video.

[fredt]

Based on code analysis and looking at the ffmbc fix, the solution is to modify mpeg12enc.c

When the aspect ratio equal exactly a valid mpeg2 aspect ratio, the wrong aspect ratio is sent in the aspect_ratio field in the mpeg sequence header. In that scenario the error difference will be zero because they match exactly. Because of the < sign, the current algorithm will select the second best error difference ignoring perfect match thus causing the error.

STB use the sequence header to display the right format on screen.

The fix is to change line 267 in function mpeg1_encode_sequence_header:

if (error < best_aspect_error) {

best_aspect_error = error;
s->aspect_ratio_info = i;

}

To this:

if (error <= best_aspect_error) {

best_aspect_error = error;
s->aspect_ratio_info = i;

}

[Carl Eugen Hoyos]

Please send your patch (made with git format-patch or at least git diff) to the ffmpeg-devel mailing list where it can be reviewed. Patches on this bug tracker are generally ignored, this is even more relevant for tickets like this one that developers cannot easily reproduce themselves.

[Carl Eugen Hoyos]

Should be fixed by Frederic Turmel in b217e1b0