[Rejected] Onvideoformatchange is now triggered when aspect ratio changes in the stream (1 Viewer)

[flyinj]

The tsreader only triggered onformatchange event on resolutionchanges within the stream not aspect-only changes. Due to good code base this was pretty straight forward. I made this against revision:26177
My blue button thanks in advance

 

[arion_p]

Why would you want to trigger OnVideoFormatChanged when aspect ratio changes? The video format is still the same, there is no need to change codecs, no need to rebuild/reconnect the graph.

 

[flyinj]

To tell the Playback software, that the Geometry of the video has changed (for example from anamorph 16:9 to 4:3 which only differ in aspect ratio). I thought something like that was the purpose of that event, but being new to the mp code i could as well be wrong. At least one gets an additional way of knowing the current aspect ratio of the current video (except from decoderfilter). But maybe the idea is only of use when applying that patch as well:
https://forum.team-mediaportal.com/...tc-325/fix-several-aspect-ratio-issues-85539/
.

 

[flyinj]

I'd really like to hear some feedback on this, because this helps displaying correct aspect ratio despite using certain buggy codecs like mpc decoder for example, or am I the only one who wants that working?

 

[JoeSmith]

AW: Onvideoformatchange is now triggered when aspect ratio changes in the stream

not a dev, but arions answer suggest that onvideoformatchange has nothing to do with the aspect ratio (16:9, 4:3) but rather the video format (divx, xvid, ...) and the codec that is used for that type of video format when building the graph. But i might be wrong.

 

[tourettes]

Re: AW: Onvideoformatchange is now triggered when aspect ratio changes in the stream

not a dev, but arions answer suggest that onvideoformatchange has nothing to do with the aspect ratio (16:9, 4:3) but rather the video format (divx, xvid, ...) and the codec that is used for that type of video format when building the graph. But i might be wrong.

Yep. It is just wrong way to use the existing interface since it is intended for a different use than the proposed aspect ration change. It will be just wrong to rebuild the graph if aspect ration changes. Codecs should be fixed instead.

 

[flyinj]

Ok, but what about introducing a new event just for that purpose? Would that be more acceptable?. That way at least no redundant graph rebuild is triggered.
I'm aware that this wasn't needed if all codecs were playing by the rules, but thats not always the case.
And thanks for reply.

 

[tourettes]

Ok, but what about introducing a new event just for that purpose? Would that be more acceptable?. That way at least no redundant graph rebuild is triggered.
I'm aware that this wasn't needed if all codecs were playing by the rules, but thats not always the case.

I think graph rebuilding is the workaround that makes the badly behaving codecs to work correctly. Unless there is some interface that could be used to notify the codecs about the AR change it wont help. But if there is some way to notify the codecs then adding a new event indeed would be the correct way to handle it.

 

[flyinj]

As far as i've understood, scaling (which includes stretching the videos to the correct aspect ratio) is essentially done by MediaPortal and not by the renderer part of the Graph (that functionality seems indeed requested off by MediaPortal code).
So workaround is to make Mediaportal know the correct aspect ratio (thats what currently happens at my setup), works like this:

1) Abuse the OnVideoFormatchanged event in the tsreader code to get the aspect ratio changeinformation handed over to mediaportal (thats done by the patch above)
2) the data essentially ends up in the structure returned by g_player.getvideoformat()
3) Change the planescene.InternalPresentImage function to use the the ar data of g_player.getvideoformat() instead
the original argument (which is often false when mpc or other bad codec is used) under "sane" circumstances (currently these are: we are using an intrenal player and the videoformatstructure is valid)
(that is done by that patch:
https://forum.team-mediaportal.com/...tc-325/fix-several-aspect-ratio-issues-85539/

(if it was a good idea to split it up like that is another question))

for 1) there is a good way of doing that (new event)
is 2) ok? Should that data go to a new member of one of the tsreaderplayer classes, or sth. completely different?
is 3) ok, or is the whole idea of bypassing the Filtergraph a bad thing?

Thanks very much for your input.
P.S.:

[...]
I think graph rebuilding is the workaround that makes the badly behaving codecs to work correctly. [...]

At leat in the case of mpc decoder this seems not true according to my testing. Thats the reason why i think, the tsreader should tell the renderer the aspect resolution directly(bypassing the filtergraph).