[PATCH] updated diff for libdvdread-0.9.5
Hi, Attached is the patchset for libdvdread, updated for version 0.9.5. -- Emanuele Giaquinta
On Fri, Jan 27, 2006 at 02:40:30PM +0100, Emanuele Giaquinta wrote:
Attached is the patchset for libdvdread, updated for version 0.9.5.
We talked about this on IRC, but here are some public comments: I think this is desirable, especially since that release incorporates quite a few of our patches. But this patch cannot be applied directly to CVS, we would have to drop in the libdvdread release and apply the patch on top of that. Ideal would be patches that moved our internal libdvdread to the latest version. Since there was apparently a big indent run on all the libdvdread sources, a separate patch for the cosmetic changes would be ideal. Diego
Here it is a patch that moves the internal libdvdread to the last version; it doesn't include any cosmetic.
On Sun, Mar 19, 2006 at 09:17:56AM +0100, Emanuele Giaquinta wrote:
Here it is a patch that moves the internal libdvdread to the last version; it doesn't include any cosmetic.
Could you please provide a cosmetics-only diff as well. I'll try to find some time to look into this soon. Diego
On 3/19/06, Diego Biurrun <diego@biurrun.de> wrote:
Could you please provide a cosmetics-only diff as well. I'll try to find some time to look into this soon.
Here it is. -- Emanuele Giaquinta
On Sun, Mar 19, 2006 at 09:17:56AM +0100, Emanuele Giaquinta wrote:
Here it is a patch that moves the internal libdvdread to the last version; it doesn't include any cosmetic.
You have removed some of the modification notices from the file headers. This is wrong, please update your patch. Diego
On 3/20/06, Diego Biurrun <diego@biurrun.de> wrote:
You have removed some of the modification notices from the file headers. This is wrong, please update your patch.
Can't I just add, with a patch on top of the former two and only to the files modified in libdvdread_changes.diff, the header below? * Modified for use with MPlayer, changes contained in libdvdread_changes.diff. * detailed CVS changelog at http://www.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/ -- Emanuele Giaquinta
On Mon, Mar 20, 2006 at 01:08:41PM +0100, Emanuele Giaquinta wrote:
On 3/20/06, Diego Biurrun <diego@biurrun.de> wrote:
You have removed some of the modification notices from the file headers. This is wrong, please update your patch.
Can't I just add, with a patch on top of the former two and only to the files modified in libdvdread_changes.diff, the header below?
* Modified for use with MPlayer, changes contained in libdvdread_changes.diff. * detailed CVS changelog at http://www.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/
I don't see why you need to remove it in the first place. Let's try to keep diff pollution to a minimum. Small nit about the patch: You forgot to bump the libdvdread version number in FILES. Diego
On Mon, Mar 20, 2006 at 06:50:29PM +0100, Diego Biurrun wrote:
On Mon, Mar 20, 2006 at 01:08:41PM +0100, Emanuele Giaquinta wrote:
On 3/20/06, Diego Biurrun <diego@biurrun.de> wrote:
You have removed some of the modification notices from the file headers. This is wrong, please update your patch.
Can't I just add, with a patch on top of the former two and only to the files modified in libdvdread_changes.diff, the header below?
* Modified for use with MPlayer, changes contained in libdvdread_changes.diff. * detailed CVS changelog at http://www.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/
I don't see why you need to remove it in the first place. Let's try to keep diff pollution to a minimum.
Small nit about the patch: You forgot to bump the libdvdread version number in FILES.
I think we should try to benchmark this. I'm not sure what the best way to benchmark a demuxer is, though. Will something like mplayer -benchmark -vo null -ao pcm:file=/dev/null do the trick? Diego
Hi,
I think we should try to benchmark this. I'm not sure what the best way to benchmark a demuxer is, though. Will something like
mplayer -benchmark -vo null -ao pcm:file=/dev/null
In theory, mencoder -ovc copy -oac copy -o /dev/null or so... And for MPlayer -ao null should work fine I think... Greetings, Reimar Döffinger
On Mon, Mar 20, 2006 at 07:25:32PM +0100, Reimar Döffinger wrote:
I think we should try to benchmark this. I'm not sure what the best way to benchmark a demuxer is, though. Will something like
mplayer -benchmark -vo null -ao pcm:file=/dev/null
In theory, mencoder -ovc copy -oac copy -o /dev/null or so... And for MPlayer -ao null should work fine I think...
Sure? From the man page: null Produces no audio output but maintains video playback speed. Use -nosound for benchmarking. Diego
On Mon, 20 Mar 2006 19:57:27 +0100 Diego Biurrun <diego@biurrun.de> wrote:
On Mon, Mar 20, 2006 at 07:25:32PM +0100, Reimar Döffinger wrote:
I think we should try to benchmark this. I'm not sure what the best way to benchmark a demuxer is, though. Will something like
You want to benchmark the stream here, not the demuxer. Try -dumpstream perhaps.
Sure? From the man page:
null Produces no audio output but maintains video playback speed. Use -nosound for benchmarking.
Yep ao null will sleep. Albeu
Alban Bedel wrote:
I think we should try to benchmark this. I'm not sure what the best way to benchmark a demuxer is, though. Will something like
You want to benchmark the stream here, not the demuxer. Try -dumpstream perhaps.
Sure? From the man page:
null Produces no audio output but maintains video playback speed. Use -nosound for benchmarking.
Yep ao null will sleep.
I tried to make a fix for that recently, in order to benchmark the faad update patch ....and I got lost. If it's at all practical and anybody sees how, it could be useful to have the "-ao null -benchmark combination" not sleep. Maybe I just missed the right way to do it. -Corey
This patch fixes the rtp demuxer with the new libdvdread; ifo_types.h needs the macros UINT8_MAX UINT16_MAX and INT32_MAX, in stdint.h, which are not defined when the language is c++ unless __STDC_LIMIT_MACROS is defined. -- Emanuele Giaquinta
Updated patches for libdvdread. -- Emanuele Giaquinta
On Wed, Mar 22, 2006 at 10:45:02PM +0100, Emanuele Giaquinta wrote:
This patch fixes the rtp demuxer with the new libdvdread; ifo_types.h needs the macros UINT8_MAX UINT16_MAX and INT32_MAX, in stdint.h, which are not defined when the language is c++ unless __STDC_LIMIT_MACROS is defined.
Patch applied, thanks. Diego
On Tue, Apr 18, 2006 at 04:42:02PM +0200, Diego Biurrun wrote:
On Wed, Mar 22, 2006 at 10:45:02PM +0100, Emanuele Giaquinta wrote:
This patch fixes the rtp demuxer with the new libdvdread; ifo_types.h needs the macros UINT8_MAX UINT16_MAX and INT32_MAX, in stdint.h, which are not defined when the language is c++ unless __STDC_LIMIT_MACROS is defined.
Patch applied, thanks.
Incidentally, using UINT8_MAX UINT16_MAX and INT32_MAX is absolutely idiotic. These are not system-specific limits but the numbers 255, 65535, and 2147483647. Rich
Rich Felker wrote:
On Tue, Apr 18, 2006 at 04:42:02PM +0200, Diego Biurrun wrote:
On Wed, Mar 22, 2006 at 10:45:02PM +0100, Emanuele Giaquinta wrote:
This patch fixes the rtp demuxer with the new libdvdread; ifo_types.h needs the macros UINT8_MAX UINT16_MAX and INT32_MAX, in stdint.h, which are not defined when the language is c++ unless __STDC_LIMIT_MACROS is defined.
Patch applied, thanks.
Incidentally, using UINT8_MAX UINT16_MAX and INT32_MAX is absolutely idiotic. These are not system-specific limits but the numbers 255, 65535, and 2147483647.
That doesn't necessarily make it idiotic to use symbolic names for them; it makes the code (potentially/arguably) more readable, by referring to the reason why this specific number is being used instead of just having an apparently arbitrary number. I've done vaguely similar things in some of my own code, a few times in the past, albeit with names I defined myself rather than more broadly general ones. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Wed, Apr 19, 2006 at 04:32:06AM -0400, The Wanderer wrote:
Rich Felker wrote:
On Tue, Apr 18, 2006 at 04:42:02PM +0200, Diego Biurrun wrote:
On Wed, Mar 22, 2006 at 10:45:02PM +0100, Emanuele Giaquinta wrote:
This patch fixes the rtp demuxer with the new libdvdread; ifo_types.h needs the macros UINT8_MAX UINT16_MAX and INT32_MAX, in stdint.h, which are not defined when the language is c++ unless __STDC_LIMIT_MACROS is defined.
Patch applied, thanks.
Incidentally, using UINT8_MAX UINT16_MAX and INT32_MAX is absolutely idiotic. These are not system-specific limits but the numbers 255, 65535, and 2147483647.
That doesn't necessarily make it idiotic to use symbolic names for them; it makes the code (potentially/arguably) more readable, by referring to the reason why this specific number is being used instead of just having an apparently arbitrary number. I've done vaguely similar things in some of my own code, a few times in the past, albeit with names I defined myself rather than more broadly general ones.
(1<<8)-1, etc. are quite readable and explicit at the same time.. Same goes for 0xff, 0xffff, ... Rich
Rich Felker wrote:
On Wed, Apr 19, 2006 at 04:32:06AM -0400, The Wanderer wrote:
Rich Felker wrote:
Incidentally, using UINT8_MAX UINT16_MAX and INT32_MAX is absolutely idiotic. These are not system-specific limits but the numbers 255, 65535, and 2147483647.
That doesn't necessarily make it idiotic to use symbolic names for them; it makes the code (potentially/arguably) more readable, by referring to the reason why this specific number is being used instead of just having an apparently arbitrary number. I've done vaguely similar things in some of my own code, a few times in the past, albeit with names I defined myself rather than more broadly general ones.
(1<<8)-1, etc. are quite readable and explicit at the same time.. Same goes for 0xff, 0xffff, ...
Point. I wouldn't find the former syntax especially readable, but that's almost certainly because I'm not yet intuitively familiar with the concept of bitshifting; the latter syntax is quite comprehensible to me. I'm not necessarily willing to start calling the use of the symbolic names idiotic, but I am willing to concede the issue. ^_^ -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Secrecy is the beginning of tyranny.
On Thu, Mar 23, 2006 at 03:22:32PM +0100, Emanuele Giaquinta wrote:
Updated patches for libdvdread.
I've just synced with 0.9.5 finally, thanks for your help with this. Diego
participants (7)
-
Alban Bedel -
Corey Hickey -
Diego Biurrun -
Emanuele Giaquinta -
Reimar Döffinger -
Rich Felker -
The Wanderer