On 3/18/07, Martin Wache [EMAIL PROTECTED] wrote:
I switched the repacking of in my vdr... I don't think that it is
necessary.
Bye,
Martin
Hi,
I would like to disable the repacker in my VDR implementation as I think it
might be responsible for sync problems in transfer mode between my
On 3/18/07, Georg Acher [EMAIL PROTECTED] wrote:
That's a bit difficult, since our vdr has no exact mainline equivalent.
It may contain parts from different vdr versions. But as I've heard, it
should work also on a full featured card without any modifications. Maybe
you need to tweak the
Hi,
Martin Wache wrote:
I agree that it is cleaner to have an index file which points to
complete frames, but I never experienced any problems without repacking.
So it seems to me that only xine's libmpeg2 has the problem to drop
incomplete frames. This was annoying when moving cutting marks
On Sun, Mar 18, 2007 at 01:26:03PM +0100, Reinhard Nissl wrote:
I switched the repacking off in my vdr... I don't think that it is
necessary.
Maybe you are right. The benefit of avoiding memcpys when repacking is
done already during the TS to PES transformation is void as long as one
Hi,
Is there a patch available with your modifications?
Thanks
Halim
On So, Mär 18, 2007 at 04:30:02 +0100, Georg
Acher wrote:
On Sun, Mar 18, 2007 at 01:26:03PM +0100, Reinhard Nissl wrote:
I switched the repacking off in my vdr... I don't think that it is
necessary.
Maybe you
On Sun, Mar 18, 2007 at 05:25:00PM +0100, Halim Sahin wrote:
Hi,
Is there a patch available with your modifications?
That's a bit difficult, since our vdr has no exact mainline equivalent.
It may contain parts from different vdr versions. But as I've heard, it
should work also on a full
Hi,
Georg Acher wrote:
The new repacker may have some issues with AC3 or some audio-only channels,
but maybe it's worth to have a look at its code...
svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/
I'll have a look at it the next days.
I must admit, that the repacker classes were
Reinhard Nissl schrieb:
Hi,
Stefan Lucke wrote:
Dumping the first 16 bytes of audio packets we get, shows the following:
ff fc a4 0d b6 64 88 55 33 65 56 54 44 21 33 33
ff fc a4 0d 54 6a 88 65 33 44 56 54 33 33 33 33
ff fc a4 0d 02 a4 88 55 33 54 66 44 43 33 33 33
99 77 1b e6 34 b2 5f
Hi,
Reinhard Nissl schrieb:
Hi,
Martin Wache wrote:
Is there a reason why the cAudioRepacker is used in transfer mode and
during recordings, but not while replaying?
Well, when cAudioRepacker was active while recording, then there is no
need for it when replaying such a recording.
On Saturday 17 March 2007 23:11, Martin Wache wrote:
Hi,
Reinhard Nissl schrieb:
And old recordings will
vanish as time passes by.
I don't buy this argument. I know that there are VDR users with large
archives of recordings, do you want to tell them that they can't use
them any
On Saturday 17 March 2007 22:05, Martin Wache wrote:
I attached a patch with make the softdevice use av_read_frame(), it has
still some issues, but it solves the problems Stefan reports.
Martin, thats really great.
Thank you.
This solves the issue I had with playback of some old recordings.
Hi,
Martin Wache wrote:
Is there a reason why the cAudioRepacker is used in transfer mode and
during recordings, but not while replaying?
Well, when cAudioRepacker was active while recording, then there is no
need for it when replaying such a recording.
Wouldn't it make more sense to use
12 matches
Mail list logo