Project

General

Profile

Bug #2209

Missing video width/height on subscriptionStart

Added by Sam Stenvall about 10 years ago. Updated about 10 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
Category:
Parsers
Target version:
-
Start date:
2014-08-10
Due date:
% Done:

0%

Estimated time:
Found in version:
master - ~100 commits
Affected Versions:

Description

From time to time, tvheadend doesn't send any width/height in the subscriptionStart message. This causes XBMC to attempt to open a hardware decoder surface with 0x0 dimensions which can crash VAAPI completely. I reported it in https://github.com/FernetMenta/xbmc/issues/246 but I guess the real fix would be to figure out why tvheadend doesn't always have the dimensions ready.

Would be great to be able to fix this since it's currently causing my HTPC to crash from time to time when switching channels.

I'll gladly test any patches!

History

#1

Updated by Sam Stenvall about 10 years ago

After some digging through the code with extra logging enabled I have determined that when parser_set_stream_vparam() is called, the elementary stream's dimensions may be zero, but at the end of the function the values are always correctly updated. This means that the parser itself (the MPEG-2 and the H.264 parser respectively) works correctly in that they are able to determine the correct values. The problem seems to be that the subscription is started and the video stream details are sent in subscriptionStart before the first packets have been processed, which means from time to time (1 every 20 times roughly) the stream details are missing.

@perexg @adamsutton do you have any ideas on how to fix it?

Looking at my configuration files, all services have their dimensions parsed and stored, I don't know why those values are used instead of 0x0.

#2

Updated by Jaroslav Kysela about 10 years ago

The service->es_width and es_height values seem correctly restored in src/service.c .

I think that the issue is when the service is used the first time with the matroska parser. In this time, these values are zero...

#3

Updated by Jaroslav Kysela about 10 years ago

Looking further to the code.. I think that it's XBMC fault.. TVH will send another subscriptionStart message when the widht and height values are know... So XBMC should postpone video processing until the values are know.

#4

Updated by Sam Stenvall about 10 years ago

@perexg I don't use the Matroska muxer at all. I'm currently "production testing" all the recent fixes for this issue (one fix in the addon, one fix in VAAPI/XBMC and your tsfix branch), so far so good.

#5

Updated by Andy Brown about 10 years ago

  • Status changed from New to Resolved

resolved in master

#6

Updated by Jaroslav Kysela about 10 years ago

  • Status changed from Resolved to Fixed

Also available in: Atom PDF