Change display aspect ratio is misleading

[kieranjol]

Hey, as discovered at the Tate workshops, the change display aspect ratio recipe (that i wrote)is misleading,as it also transcodes to prores.As stream copy doesn't work with a filter, specifying a codec is required . @dericed wrote a better one in his 'change stream properties' script,which uses field_order,but from my limited tests, this doesn't work with Matroska,only mov(probably mp4 too?).

I think the setfield script should stay in but a better explanation is required so that the re-encode is made more obvious.

[dericed]

Hi Kieran, I should clarify that the -c copy -aspect move would only change the aspect ratio of the container if this is possible. If the stream you are copying includes its own aspect ratio, such as DV or FFV1, then the result could be conflicting. For instance if DV is in MOV and both the DV and MOV note an aspect ratio, then -c copy -aspect would change the MOV aspect ratio but not the DV aspect ratio (changing the DV aspect ratio could not be done with -c copy).

[kieranjol]

I just realised that even though I used aspect ratio in the title of this issue, I was referring to the field order script.
Thanks for clarifying the aspect ratio situation, as well. It's great to have your input on this stuff! I'm getting settled back in so I'll send on a new pull request for both tomorrow if someone else doesn't get to it first.

[dericed]

Interlacement is the same issue, also with DV and FFV1 v3.

[kieranjol]

Out of curiosity, is -vf setsar the only way to change the aspect ratio at a codec level with ffmpeg? Is it a similar case with -vf setfield? As stream copy mode is not applicable when using -vf, is there any lossless method of aspect ratio change within ffmpeg?

[pjotrek-b]

I know this thread is old, but... :wink:

I've dealt with this a long time ago, but my understanding is that it'd require codec-specific routines to change SAR/DAR/PAR inside the codec's bitstream without re-encoding.

So far, I think ffmpeg only provides to (a) override it using container's metadata, or (b) re-encode.

Would be great to have institutions fund implementing such bitstream-fix functionality in e.g. MediaConch?

[retokromer]

Why not directly in FFmpeg and provide an interface in MediaConch?

[pjotrek-b]

You're right. That'd be even better. And probably easier sustainable.

[dericed]

You can use -c:v copy -field_order tt (tt, tb, bt, or bb) to change the container's interlacement flag during a copy, but maybe streams (dv, ffv1, prores, etc) store their own interlacement data so potentially this command just causes contradictions.

[retokromer]

Is this issue still one, @kieranjol?

[ablwr]

Repeating @retokromer's question?

[privatezero]

is this still an issue or can it be closed?

[pjotrek-b]

I think changing field order without re-encoding still has some issues...

Just recently stumbled over a case where, even with re-encoding, the "original scan order" (Mediainfo-speak) was remembered (v210/MOV to FFV1/MOV).

I remember trying the ffmprovisr recipe (as well as "-top 1"), without luck.

Nevertheless: This thread is very confusing (parts aspect ratio, parts field-order). Maybe better to close it (and start a new one if necessary)?

[kieranjol]

I agree with the confusion,there's too much going on here. I think new issues could be raised for more specific parts of this question.

[ablwr]

This thread seems neglected.

[todrobbins]