Bug Video is not smooth after broadcaster switch 4:3<->16:9
#16
I think I can, I need only wait for broadcaster to get stream like this. Will mkv recorded by tvheadend enough? Or full mux stream dump will be better?
Reply
#17
(2014-03-12, 22:14)adamsutton Wrote: @giaur the issue definitely exists, I've checked the code and discussed with Andreas. His take on it is that explicitly including this in the mux metadata should not be necessary, it implies a broken player. However as usual we'll almost certainly have to fix it rather than get XBMC to sort itself out. But I have started looking.

Do you provide a value for aspect ration when opening the stream? In this case pvr sets a forced aspect ratio for the stream which won't be reset if a later change is detected by decoder. You can either always set it or never.
Reply
#18
(2014-03-13, 10:16)giaur Wrote: I think I can, I need only wait for broadcaster to get stream like this. Will mkv recorded by tvheadend enough? Or full mux stream dump will be better?

a ts recording would be better because I can play this through pvr demuxer.
Reply
#19
Ok, I think I can create dump in 2-3 days, I only need to look when broadcaster is going to emit some older material in 4:3. So I will provide full mux dump.
Reply
#20
@FernetMenta if you're referring to iAspect or something in the PVR stream properties then yes it is being set.
Reply
#21
(2014-03-13, 12:31)negge Wrote: @FernetMenta if you're referring to iAspect or something in the PVR stream properties then yes it is being set.

fAspect, right? If fAspect is zero, we use pixel aspect ratio we get from decoder. if fAspect is >0, we force this ratio.
Reply
#22
Sample .ts for testing:
https://mega.co.nz/#!XZFmTBSA!KoUcGT3odo...ETjqgxXD2I

This is raw untouched dump of entire dvb-t mux. You can find 16:9 to 4:3 change for channel name Polsat, time about 0:42
Reply
#23
I think the plan is that we're going to simply remove setting that value in pvr.tvh (hts) given XBMC assumes that's a forced value rather than the "guide" it was assumed to be.

Adam
Reply
#24
@giaur I can reproduce with mainline master but the switch is fine with my master branch.
Reply
#25
(2014-03-13, 22:48)adamsutton Wrote: I think the plan is that we're going to simply remove setting that value in pvr.tvh (hts) given XBMC assumes that's a forced value rather than the "guide" it was assumed to be.

Adam

You are on the safe side if you announce it by your demuxer. Not all decoders may be capable of feeding this information back to player.
Reply
#26
(2014-03-14, 09:32)FernetMenta Wrote: @giaur I can reproduce with mainline master but the switch is fine with my master branch.
So tvheadend changes will not be neccasary? I have compiled beta1 and this issue is still there. When are you going to merge your branch to mainline? Or please tell me where is your branch located, and I will compile from your branch and I will not wait until it's merged.
Reply
#27
https://github.com/FernetMenta/xbmc

Quote:So tvheadend changes will not be neccasary?

Give it a try. It may have a wrong aspect ration after a change because the forces one overrides the one set by decoder.
Reply
#28
I'll try your version. However in beta1 from mainline, aspect ratio after change seems to be ok
Reply
#29
Bump..

RC3 is out, stable Gotham soon. So please tell me how do you plan this issue to be fixed? Any tvheadend changes/workaround od rather xbmc side changes?

Can we expect it to be completly fixed in near future - xbmc, tvheadend or both? I assume this issue is confirmed, so what next?
Reply
#30
It was fixed a long time ago in the pvr.tvh addon.
Reply

Logout Mark Read Team Forum Stats Members Help
Video is not smooth after broadcaster switch 4:3<->16:90