[PATCH] mythtranscode: --fifoinfo reports aspect ratio of first uncut frame

[Lawrence Rust <lvr@…>]

This fixes a problem using the --fifoinfo option to report the format of a recording. When using a cutlist the first few frames may be cut and the format of the first uncut frame may be different from the first physical frame.

This fixes a problem when using nuvexport etc if the recording starts in widescreen e.g. for adverts but switches to 4:3 for the feature.

[Github]

mythtranscode: --fifoinfo reports aspect ratio of first uncut frame

This fixes a problem using the --fifoinfo option to report the format of a recording. When using a cutlist the first few frames may be cut and the format of the first uncut frame may be different from the first physical frame.

This fixes a problem when using nuvexport etc if the recording starts in widescreen e.g. for adverts but switches to 4:3 for the feature.

Fixes #10301

Signed-off-by: Lawrence Rust <lvr@…> Signed-off-by: Gavin Hurlbut <ghurlbut@…>

Branch: master Changeset: 638192e2893033e14716aff72ea2a9e945f9cc87

[beirdo]

I don't believe this will affect nuvexport in any way as we do not use --fifoinfo. However, the patch seems sound, and doesn't break anything in my testing.

[mythtv@…]

I believe this fix actually causes problems, as it seems to use the actual frame size assuming square pixels.

For instance, I have many DVB recordings at 704x576 with a DAR of 16:9, so that the output frame size is 1024x568. When mythtranscode -fifoinfo is run I get FifoVideoAspectRatio 1.77778 as expected, but adding -honorcutlist now gives me FifoVideoAspectRatio 1.22222.

I am afraid I am not sure what the correct call is (having never read any of the source), but I am assuming it is the following line of the patch which needs changing to get the output frame size, rather that the source size:

video_aspect = player->GetVideoAspect();

[Karl Egly]

split out the new bug into #11605, I can reproduce it on master