Messages

You might just have no compatible Decoder. (I do not remember if the Microsoft DTV is working, on some OS it works on some it does not work, it depends on some License restrictions of Microsoft).
This can happen.
Can you please describe the symptoms, if you try to play back tv?
Is Audio playing back? If not, it might just be a missing Audio Decoder?

These standalone filters, might help:
http://mpc-hc.org/downloads/

Marten

The sad thing is that I tried to contact them, offering patches on libcec.
But the maintainers never answered....

Marten

Please test the current git. I hope it is fixed now.

You can ignore the weird frame sizes, they are in deinit first frame log messages correct.

Marten

I will keep the audio header continuity test.
It is part of the all the other sanity checks and also ffmpeg/libav use a continuity test.
It is very likely that you are not experiencing any problems without the test.
But the odds are high that someelse does has problems.
So I will leave it in the code.

Marten

@winschrott
Thanks for the fix, I have included it in my git.
I will leave the header continuity check, since I think it can prevent playing back garbage. (May be the counter should be decreased).

Marten

No idea, here compiles everything successfully. May be a different cec version?

Marten

Thanks, for your analysis.

I try to got with 1), but I changed one function call, so hopefully remote is now working.
It would be nice, if you can test current git.

Can you please clarify your comment to 2).
I am a bit confused. So without the CEC_OPCODE_STANDBY handler, everything works as in 1)? Do you have also the problem with the remote?

Marten

One user has troubles with using cec with his television.
Therefore I am trying to implement handlers for cec message, which are not handled before.
Unfortunetely these changes are causing problems with other tvs.
I am trying to get a stable implementation again. (In the moment it seems, that some messages are handled twice).

Can you please try the following things (all independently and in multiple combinations, so that I can figure out, which new functio is causing the problems):
1) Uncomment the lines in changePowerstate, does this help? Is the behaviour changed?
2) In ceccommand, there are three handled commands: CEC_OPCODE_STANDBY, CEC_OPCODE_DECK_CONTROL, CEC_OPCODE_PLAY. Can you comment them one by one and determine which one of these is causing troubles ?
3) Comment the lines in cecSourceActivated and try if this causing the troubles.

Thanks, this will help me to figure out to make vomp compatible to more tvs.

Marten

In order to understand it, I need a small test video.

Marten

There are other sanity checks in this function.
All with an if clause and continue.

Marten

Sometimes the error correction does not work and then some packets are missing.
All I have figured out that the stream was out of synch, and the resynch occured at some, which looked like an mpeg audio header but was actually inside  the audio frame.
I adapted than the mechanism, that also libav uses to detect these cases.

Marten

How do you know that it is error free?
Just by playing it back by a software?

This only proves that the error detection of the software is better. If you want to know if it is really broken, you have to use the Hex editor.

The pes packets are delivered to "DeliverMediaPacket(MediaPacket packet, const UCHAR* buffer,                  UINT *samplepos) " in audioomx.cc, you can get the audio stream from there in write it to a file. This is what I usually do to check the stream.
Also if there is a error in audio stream processing, it is probably there.

Marten

No the idea does not help.
The whole stream is out of sync, after the broken stream.
There is a beginning of an audio frame detected which is not the beginning of the audio frame.
Then the algorithm continues to search for the frame.
So that check ensures, that is synching faster.

Marten

You can choose a chirp or a audio drop out.
In case of sirwio, the file was propably damaged in the beginning. (Visible artefacts in the video).
The question is only how gentle the audio is turned off.

You can play with "if (mp3sameheadercount>4) {" in audioomx. May be a value of 2 or 3 is better than 4.

Marten

I have looked at sirwios sample. (The other one is too big...., I need short samples, downloading or debugging will be a pain otherwise)

I have implemented a function, which assumes if the mpeg audio header changes frequently,
that the audio is not in synch or broken. Therefore the audio is discarded until the format stays the same. (inspired by libav's code).

This might solve your problem with mpeg audio.
Now in my git.

Marten