In a crude attempt to run VDR's Transfer-Mode without using a cRemux (and thus avoiding all the extra buffering and processing) I am trying to send the payload of the TS packets directly to the device.
The attached patch implements cDevice::PlayTS() and handles video and audio packets with fixed PIDs (just for testing).
I do get audio and video (using a FF-DVB card as output device), but there are some distortions. From all the debug output I've made there doesn't seem to be anything wrong - even the TS continuity counters check out (except for the initial one, which is to be expected).
Am I missing something obvious here?
Maybe somebody on the list can find out what's wrong here - or can argue why this attempt can't work in the first place.
If you try the patch, just change the hardcoded PIDs in cDevice::PlayTS() to whatever video and audio PID the channel has you're going to test with.
Klaus
On 02/02/08 16:27, Klaus Schmidinger wrote:
In a crude attempt to run VDR's Transfer-Mode without using a cRemux (and thus avoiding all the extra buffering and processing) I am trying to send the payload of the TS packets directly to the device.
The attached patch implements cDevice::PlayTS() and handles video and audio packets with fixed PIDs (just for testing).
I do get audio and video (using a FF-DVB card as output device), but there are some distortions. From all the debug output I've made there doesn't seem to be anything wrong - even the TS continuity counters check out (except for the initial one, which is to be expected).
Am I missing something obvious here?
Maybe somebody on the list can find out what's wrong here - or can argue why this attempt can't work in the first place.
If you try the patch, just change the hardcoded PIDs in cDevice::PlayTS() to whatever video and audio PID the channel has you're going to test with.
Nevermind, I just found it myself: it must be +5 instead of +4 in
inline int TsPayloadOffset(const uchar *Data) { return (Data[3] & ADAPT_FIELD) ? Data[4] + 5 : 4; }
Now it works - and Transfer-Mode never switched as fast as this :-)
Klaus
On 02/02/08 16:59, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
Now it works - and Transfer-Mode never switched as fast as this :-)
Have you never tried my syncearly patch?
Sorry, but I never found the time to try it.
By sending the TS payload data directly to the device, audio appears almost instantaneously - which I believe is what the syncearly patch does, too, right?
Plus it saves two ringbuffers (one in cTransfer and one in cRemux) and one extra thread - sounds like some simplification to me ;-)
Of course I'll need to see how this behaves in every day live, and all the audio track handling needs to be adjusted accordingly. But for the moment it looks good to me.
Klaus
On Feb 2, 2008 8:14 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 02/02/08 16:59, Reinhard Nissl wrote:
Have you never tried my syncearly patch?
Sorry, but I never found the time to try it.
By sending the TS payload data directly to the device, audio appears almost instantaneously - which I believe is what the syncearly patch does, too, right?
Maybe you should make some time to try his patches so you won't have to spend time creating code that already exists. ;)
On 02/02/08 18:01, VDR User wrote:
On Feb 2, 2008 8:14 AM, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 02/02/08 16:59, Reinhard Nissl wrote:
Have you never tried my syncearly patch?
Sorry, but I never found the time to try it.
By sending the TS payload data directly to the device, audio appears almost instantaneously - which I believe is what the syncearly patch does, too, right?
Maybe you should make some time to try his patches so you won't have to spend time creating code that already exists. ;)
Well, I didn't write code that already existed - I eliminated unnecessary code ;-)
Klaus
Klaus Schmidinger schrieb:
On 02/02/08 16:27, Klaus Schmidinger wrote:
In a crude attempt to run VDR's Transfer-Mode without using a cRemux (and thus avoiding all the extra buffering and processing) I am trying to send the payload of the TS packets directly to the device.
The attached patch implements cDevice::PlayTS() and handles video and audio packets with fixed PIDs (just for testing).
[ .. ]
Nevermind, I just found it myself: it must be +5 instead of +4 in
inline int TsPayloadOffset(const uchar *Data) { return (Data[3] & ADAPT_FIELD) ? Data[4] + 5 : 4; }
Now it works - and Transfer-Mode never switched as fast as this :-)
I don't know what causes this issue, but with this patch enabled, VDR refuses to play radio-channel (audio) with the radio-plugin (with RDS enabled). When i disable the radio-plugin, audio works; when i remove the patch, audio works with the plugin enabled.
-> i removed this patch.
regards, Friedhelm.
On 02/10/08 18:39, Friedhelm Büscher wrote:
Klaus Schmidinger schrieb:
On 02/02/08 16:27, Klaus Schmidinger wrote:
In a crude attempt to run VDR's Transfer-Mode without using a cRemux (and thus avoiding all the extra buffering and processing) I am trying to send the payload of the TS packets directly to the device.
The attached patch implements cDevice::PlayTS() and handles video and audio packets with fixed PIDs (just for testing).
[ .. ]
Nevermind, I just found it myself: it must be +5 instead of +4 in
inline int TsPayloadOffset(const uchar *Data) { return (Data[3] & ADAPT_FIELD) ? Data[4] + 5 : 4; }
Now it works - and Transfer-Mode never switched as fast as this :-)
I don't know what causes this issue, but with this patch enabled, VDR refuses to play radio-channel (audio) with the radio-plugin (with RDS enabled). When i disable the radio-plugin, audio works; when i remove the patch, audio works with the plugin enabled.
-> i removed this patch.
I never suggested that anybody should actually use this patch. It was just a first test regarding switching from PES to TS.
Klaus
-
Friedhelm Büscher -
Klaus Schmidinger -
Reinhard Nissl -
VDR User