[umtauscher]

Thanks, what I was wondering if that means that XBMC will not be able to play those files for a long time - perhaps never?
Its really a pain because every recording from German public HD channels has to be converted to make it playable.
XBMC on OSX plays them without problems btw.
Cheers
Umtauscher

[Memphiz]

How do you record german HD tv? I'm using tvheadend and it stores them as mkv already. But my german HD channels (only ard, zdf and arte) are interlaced so the problem on ios is that those don't get hardware decoded and the A4 is to slow for doing it in software. So you got HD channels which are progressive? (for even having a chance of smooth playback on ios when the ts problem wouldn't be there)?

[umtauscher]

Hmm, I was under the impression that ARD, ZDF and ARTE are transmitting 720p which should not be interlaced, is it?
I simply transfer the files from my VU+ which is the original transport stream.

[Memphiz]

I have tested the test files posted some posts before. I can tell you that the hw decoder just won't accept those. There is no black screen for them like in eden anymore cause we detect now that the hw decoder won't do it and fall back to software decoding. This is no solution for ios of course because the hardware on atv2 and A4 ios devices doesn't have the balls for handling it.

Same is for the german free HD streams. Sorry guys - thats the price for the closed ios platforms.

Transcoding the stream into mkv fixes things that make the hw decoder happy as it seams. But its not really a matter of the ts container but of the initial stream itself.

[jayjayuk1234]

I have tested the test files posted some posts before. I can tell you that the hw decoder just won't accept those. There is no black screen for them like in eden anymore cause we detect now that the hw decoder won't do it and fall back to software decoding. This is no solution for ios of course because the hardware on atv2 and A4 ios devices doesn't have the balls for handling it.

Same is for the german free HD streams. Sorry guys - thats the price for the closed ios platforms.

Transcoding the stream into mkv fixes things that make the hw decoder happy as it seams. But its not really a matter of the ts container but of the initial stream itself.

Hi Memphiz,

I am a little confused by this statement, it appears to contradict itself a bit

The statement that the HW decoder won't accept it since the ios devices doesn't have the balls for handling it, yet simply switching containers with no re-encoding and it is able to handle the streams without breaking a sweat it would seem?

I assume you mean, the ios devices cannot handle the stream using software? which is obvious i guess, and even if it did, hw decoding is still preferable. Why would we want software decoding anyway?

Furthermore, the same applies with VLC and it too also falls over trying to re-encode the HD versions of these TS files, and i can assure you that my PC certainly has 'the balls' for handling it.

Is there an easier way for us to understand this? in laymans terms?

I'm not aware how XBMC handles containers, does it open them and gain access to the underlying streams within? if so, there should be no difference between the 2 containers?

I have taken some error output logs from VLC and have noted that it complains a lot about headers, could it be that there is another issue here? and it's not just simply a hardware problem, since it doesn't appear to make a lot of sense?

Who coded the HW decoder? The XBMC team?

Why can't the HW decoder deal with HD TS Files?

I appreciate it may not work currently, but i simply cannot imagine it is nothing more than a fairly simple fix? but you seem to suggest it will never work and the HW decoder is a completed project

Please explain

Regards

Jay

[Memphiz]

The hw decoder is hardware built by apple. And i just wanted to tell that the initial poster here said that these ts streams result in a black screen. WIth current xbmc code they won't end in a black screen but in stuttering therefore. The blackscreen was there because we feed the stream to the hw decoder who then just didn't decode anything from that so the video image was black. Now we are that "smart" to detect that these streams won't be decoded by the hw decoder and don't even try it - but instead fall back to software decoding (which results in stutter on these platforms.

We could just refuse to play those completly if you like that better?

And no there are no laymans terms for it cause i already tried to use those. If i start to tell you words like SPS and PPS NAL units, and PAFF, MBAFF then you would go into dummy mode even harder.

1. Its not a simple fix (why do users always think we are stupid enough for not finding out easy fixes??)
2. The interfacing for talking to the hw decoder was written by davilla/team xbmc so to say by reverse engineering apples binaries (since apple doesn't tell anyone how to use the hw decoder or which streams he supports or not)
3. Changing container from ts to mkv might not change the stream - but might change/fix the metadata of the stream (this might be sent on the start of the movie (avcc/avc-1) or continously throughout the stream (annex-b/byte stream)). It might even switch over from annex-b to avcc or vice versa. So in a fact it won't change the encoded data - but the metadata.

[jayjayuk1234]

The hw decoder is hardware built by apple. And i just wanted to tell that the initial poster here said that these ts streams result in a black screen. WIth current xbmc code they won't end in a black screen but in stuttering therefore. The blackscreen was there because we feed the stream to the hw decoder who then just didn't decode anything from that so the video image was black. Now we are that "smart" to detect that these streams won't be decoded by the hw decoder and don't even try it - but instead fall back to software decoding (which results in stutter on these platforms.

We could just refuse to play those completly if you like that better?

And no there are no laymans terms for it cause i already tried to use those. If i start to tell you words like SPS and PPS NAL units, and PAFF, MBAFF then you would go into dummy mode even harder.

1. Its not a simple fix (why do users always think we are stupid enough for not finding out easy fixes??)
2. The interfacing for talking to the hw decoder was written by davilla/team xbmc so to say by reverse engineering apples binaries (since apple doesn't tell anyone how to use the hw decoder or which streams he supports or not)
3. Changing container from ts to mkv might not change the stream - but might change/fix the metadata of the stream (this might be sent on the start of the movie (avcc/avc-1) or continously throughout the stream (annex-b/byte stream)). It might even switch over from annex-b to avcc or vice versa. So in a fact it won't change the encoded data - but the metadata.

Hi,

Firstly, you have assumed my post as a criticism? perhaps the language barrier has caused this, either way, please drop the supercillious nature of your replies... i was merely trying to understand the problem, not make criticisms of the XBMC team!

It is very easy to overlook simple fixes, for all i know XBMC didn't even know this problem existed.

The reason i asked for it in laymans terms was because i assumed you were an authority on the subject, and not necessarily for my benefit, there are others who read these forums

Anyway... back to my point

I think somewhere here we have agreed it can be fixed with software, since we know the hardware will play it, provided that the hw interface (or some other software) alters the metadata (or whatever) beforehand, whether this is too much effort for XMBC team to bother with, or not is beside the point i guess..

So my point was, it is NOT impossible as you claimed, just not worth doing... maybe?

Thanks for reading

[davilla]

As I've stated each time this 'issue' comes up, it is not possible, I repeat, not possible to fix this issue given that we cannot determine if the media is really interlaced content or not until we actually start decoding it. If we blindly accept it and try to decode something that is really interlaced, then xbmc will crash&burn. So the choice is, a) kick back to ffmepg and live or b) accept it and possibly crash&burn. The choice is obvious.

Now if someone thinks they can do better, they are more than welcome to start coding up a solution and submitting a patch or pull request. If you don't code or don't understand the details of SPS and PPS NAL units, and PAFF, MBAFF, then please stop trying to oversimplify this issue. It's not simple, it's not a trival fix and we have spent a lot of time already looking into ways to resolve it.

[jayjayuk1234]

As I've stated each time this 'issue' comes up, it is not possible, I repeat, not possible to fix this issue given that we cannot determine if the media is really interlaced content or not until we actually start decoding it. If we blindly accept it and try to decode something that is really interlaced, then xbmc will crash&burn. So the choice is, a) kick back to ffmepg and live or b) accept it and possibly crash&burn. The choice is obvious.

Now if someone thinks they can do better, they are more than welcome to start coding up a solution and submitting a patch or pull request. If you don't code or don't understand the details of SPS and PPS NAL units, and PAFF, MBAFF, then please stop trying to oversimplify this issue. It's not simple, it's not a trival fix and we have spent a lot of time already looking into ways to resolve it.

I see, thanks for the explanation.

Btw, how many frames need reading before you can detect all of the above?

I would imagine then that you have thought about simply reading in small chunk of the file, decoding it and getting the info needed and then resetting back to the start of the stream... may take a few seconds longer for ts files, buy hey...

[davilla]

All of them as those flags can change on any frame/field.

[jayjayuk1234]

All of them as those flags can change on any frame/field.

Alright, so SD TS containers are fine,i assume they are being played using software decoding

I've noticed that there is a separate .meta file stored along with both SD and HD files on my Vu Duo box, it has the same filename as the actual container, but just has the .meta extension, perhaps this contains the missing information?

I could upload this meta file, if someone wants to take a look, but i assume XBMC currently doesn't look for seperate files with meta data, and maybe it never will......

it's a shame, as at the moment, i have recorded programs on the hdd, which XBMC can access via ftp, but without remux, i can't play the HD Files,i should imagine dreamboxes store the transport streams the same way

Thankyou for your time davilla ( and patience lol ), it is much appreciated.

[Memphiz]

the .meta file is unrelated to the videostream for sure.

[bootmonster]

So the choice is, a) kick back to ffmepg and live or b) accept it and possibly crash&burn. The choice is obvious.

Could you not make this an option that can be chosen using advancesettings.xml. Something like force hardware decode HD TS files, with the warning that interlaced files will crash xbmc. Do so at your own risk etc.

As long as the end user is savvy enough to understand whether or not their files are compatible then it won't affect the average user, as (I would suspect) that many who are wishing to do this have a bit of a grasp of things a little more technical.

[Memphiz]

There is no benefit of allowing this. I have not found one single file yet which will work with the hardware decoder when we normally detect that it isn't supported. (it doesn't crash & burn but just gives a black video screen).

So whats the point?

[Gkarg]

Hi
Has the new iPad with A5x or the new new iPAD with A6x enough power to play these 1080i ts files with software encoding and deinterlacer ? Any experiences so far ?

Many thanks
Gkarg