Menu
▾
▴
openquicktime-devel — Developers mailing list for OpenQuicktime
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(17) |
Feb
(10) |
Mar
(17) |
Apr
(17) |
May
|
Jun
(2) |
Jul
(11) |
Aug
(12) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
(6) |
| 2003 |
Jan
(32) |
Feb
(14) |
Mar
(4) |
Apr
|
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
(2) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(9) |
| 2007 |
Jan
(5) |
Feb
(9) |
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(5) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jozef H. <jh...@us...> - 2003-11-16 06:45:57
|
Hello, Yann, you left comments in oqt_write_stsz about what does and what does not work in qt6, but it seems that setting sample size to 1 as it is currently produces files that crash both oqtplayer and xine. I'm suggesting to set sample_size to the actual sample size and for example to leave total_entries at the original value (sample count). This would be my reading of the spec. Please tell me if this is known not to work before I get the chance to test it out on a windows box. Another issue is that sourceforge's CVS server seem to be more often down than up. So no commit for now... Have a nice day, jh |
|
From: Capt. S. *-J. <st...@3i...> - 2003-10-07 19:13:38
|
Congrats :) It really is about time too :) On Wednesday, October 8, 2003, at 12:03 AM, Nicholas Humfrey wrote: > > Hi, > > > I have just released OpenQuicktime version 2.0 Alpha 1. Nothing new=20 > recently I'm afraid but I thought it was about time that the source=20 > code escaped CVS ! > > So this is *very* Alpha software - lots of bugs there still. > > > However hopefully the new cleaner API is fairly fixed now and I hope=20= > that we should be able to maintain source (and binary?) comparability=20= > from now on... > > > I haven't had much time to do work on OpenQuicktime for a bit - but=20 > looking back at it, I really think it has a lot going for it - perhaps=20= > this release will re-kindle some interest in the project. > > > Cheers, > > nick. > -- This is only the beginning! Capt. Stux *-Jedi =20 mailto:st...@3i... 3ivx=AA is a registered international trademark. Really. **** DISCLAIMER **** "This e-mail and any attachments thereto may contain information which=20= is misleading and/or protected by vain legally positivistic rights and are supposedly intended for the sole use of the recipient(s) named above.=20 Any use of the information contained herein (including, but not limited to, reading it by accident, on the loo, or word of mouth in any form) by persons other than the designated recipient(s) is, um, well, prohibited. If you have received this e-mail in error, accident, humour, mischievous bcc, mailing list glitch, recursive bounce of a co-recipient, sendmail bug, yet another winsock worm, Claire Swire, or the sender just stuffed=20= up because your name was next to the proper one in his address book, please notify the sender either by telephone or by e-mail (yeah we know, as if you would, but then you'd be amazed, some people) and delete the=20 material from any computer. This means empty your Trash and Recycle Bin, of=20 course. And zero the data just in case. Do it six times so the feds can't get at it. Oh, and don't forget your RAM chips; take them out of your computer for at least a day so the transistors can reset. And for chrissake don't leave them in your freezer because we read on Slashdot how that can inhibit the degenerative process. Thank you for your cooperation." |
|
From: Nicholas H. <nj...@ec...> - 2003-10-07 14:04:06
|
Hi, I have just released OpenQuicktime version 2.0 Alpha 1. Nothing new recently I'm afraid but I thought it was about time that the source code escaped CVS ! So this is *very* Alpha software - lots of bugs there still. However hopefully the new cleaner API is fairly fixed now and I hope that we should be able to maintain source (and binary?) comparability from now on... I haven't had much time to do work on OpenQuicktime for a bit - but looking back at it, I really think it has a lot going for it - perhaps this release will re-kindle some interest in the project. Cheers, nick. |
|
From: Yann <ya...@3i...> - 2003-06-10 17:19:40
|
Hi Nick, As you want ... calling it 2.0 alpha 1 would do it ;) Anyway, my next checkin may rebreak everything, but I can't release it so= on as it's not ready ... Yann. ----- Original Message ----- From: "Nicholas Humfrey" <nj...@ec...> To: "Alexander Lechner" <ale...@ve...> Cc: <ope...@li...> Sent: Tuesday, June 10, 2003 7:02 PM Subject: Re: [Openquicktime-devel] lib/Makefile.am: Double iods.c No - I don't think this was intentional ? I have removed the duplicate line... Really, really need to make a release. Perhaps I will make a pre-release, so that people not using CVS can at least see what is going on... ? nick. At 11:08 +0200 10/6/03, Alexander Lechner wrote: >Hi all! > >Looking and trying to compile oqt the linker gave me multiple defined >symbols because in lib/Makefile.am iods.c is linked in twice! >Is this intended? >Thanks, > >Alex >-- >Alexander.Lechner @ vertigo-systems.de >Engelbertstra=DFe 30 | phone: +49-221-2405472 >D-50674 K=F6ln | fax: +49-221-34892616 > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The best >thread debugger on the planet. Designed with thread debugging features >you've never dreamed of, try TotalView 6 free at www.etnus.com. >_______________________________________________ >Openquicktime-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openquicktime-devel ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Openquicktime-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openquicktime-devel |
|
From: Nicholas H. <nj...@ec...> - 2003-06-10 17:03:46
|
No - I don't think this was intentional ? I have removed the duplicate line... Really, really need to make a release. Perhaps I will make a pre-release, so that people not using CVS can at least see what is going on... ? nick. At 11:08 +0200 10/6/03, Alexander Lechner wrote: >Hi all! > >Looking and trying to compile oqt the linker gave me multiple defined >symbols because in lib/Makefile.am iods.c is linked in twice! >Is this intended? >Thanks, > >Alex >-- >Alexander.Lechner @ vertigo-systems.de >Engelbertstra=DFe 30 | phone: +49-221-2405472 >D-50674 K=F6ln | fax: +49-221-34892616 > > > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The best >thread debugger on the planet. Designed with thread debugging features >you've never dreamed of, try TotalView 6 free at www.etnus.com. >_______________________________________________ >Openquicktime-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openquicktime-devel |
|
From: Alexander L. <ale...@ve...> - 2003-06-10 09:08:52
|
Hi all! Looking and trying to compile oqt the linker gave me multiple defined symbols because in lib/Makefile.am iods.c is linked in twice! Is this intended? Thanks, Alex --=20 Alexander.Lechner @ vertigo-systems.de Engelbertstra=DFe 30 | phone: +49-221-2405472 D-50674 K=F6ln | fax: +49-221-34892616 |
|
From: Nicholas H. <nj...@ec...> - 2003-05-21 19:18:19
|
Just a quick note to say that thanks to Ciaran Wills, Motion JPEG A support is now in CVS. Thanks Ciaran ! nick. |
|
From: Nicholas H. <nj...@ec...> - 2003-05-15 08:19:57
|
Hi Ciaran, I have a feeling that this might be fixable by changing the options passed to dlopen() somewhere. However as you suggested it would perhaps be a good idea to link the plugins with -lopenqucktime. I cant see any harm in linking them against the library (anyone?) but it will involve changing a few Makefiles ! Out of interest, what application are you writing ? Will try and get it done today... nick. At 18:03 +0100 13/5/03, Ciaran Wills wrote: >Hi all, > >My knowledge of the intricacies of dynamic linking is limited, so I'd be >grateful if anyone could clear up a couple of questions (all this is on >linux). > >I'm writing a plugin for another application, and my plugin in turn uses >OpenQuicktime. When my plugin is loaded the linker breaks loading the >codecs; it can't find the oqt_allocate_video_codec function, which is in >libopenquicktime.so. > >This doesn't happen in the executable->openquicktine->codec case, only >with executable->myplugin->openquicktime->codec. > >So the problem is the dynamic linker won't search the libs my plugin was >linked against for linking the codec. The workaround I found was to >compile the codecs with -lopenquicktime so they have a dependency on >openquicktime.so > >Looking at the dlopen man page suggested linking with -rdynamic might >work, but it doesn't :( > >Can anyone shed any light on this? Or alternatively, how do I modify >the autoconf stuff so the codecs are built with -lopenquicktime? > >Ciaran. > > >------------------------------------------------------- >Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >The only event dedicated to issues related to Linux enterprise solutions >www.enterpriselinuxforum.com > >_______________________________________________ >Openquicktime-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openquicktime-devel |
|
From: Ciaran W. <cia...@fr...> - 2003-05-13 17:03:55
|
Hi all, My knowledge of the intricacies of dynamic linking is limited, so I'd be grateful if anyone could clear up a couple of questions (all this is on linux). I'm writing a plugin for another application, and my plugin in turn uses OpenQuicktime. When my plugin is loaded the linker breaks loading the codecs; it can't find the oqt_allocate_video_codec function, which is in libopenquicktime.so. This doesn't happen in the executable->openquicktine->codec case, only with executable->myplugin->openquicktime->codec. So the problem is the dynamic linker won't search the libs my plugin was linked against for linking the codec. The workaround I found was to compile the codecs with -lopenquicktime so they have a dependency on openquicktime.so Looking at the dlopen man page suggested linking with -rdynamic might work, but it doesn't :( Can anyone shed any light on this? Or alternatively, how do I modify the autoconf stuff so the codecs are built with -lopenquicktime? Ciaran. |
|
From: Nicholas H. <nj...@ec...> - 2003-05-06 09:42:22
|
Hi, Yes- not sure what the default version of automake RedHat 9 comes with (automake --version ?) but I am using version 1.7... Cheers, nick. At 15:14 -0700 5/5/03, Gregory Brauer wrote: >Gregory Brauer wrote: >> >>When I attempt to bootstrap the latest CVS tree I get the following >>automake errors: > >I think this did the trick... In the bootstrap script I changed the >line: > >automake --add-missing --copy > >to > >automake-1.6 --add-missing --copy > > >and it made it through the bootstrap and configure. > >Greg > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Openquicktime-devel mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openquicktime-devel |
|
From: Gregory B. <gr...@wi...> - 2003-05-05 22:14:55
|
Gregory Brauer wrote: > > When I attempt to bootstrap the latest CVS tree I get the following > automake errors: I think this did the trick... In the bootstrap script I changed the line: automake --add-missing --copy to automake-1.6 --add-missing --copy and it made it through the bootstrap and configure. Greg |
|
From: Gregory B. <gr...@wi...> - 2003-05-05 21:46:51
|
When I attempt to bootstrap the latest CVS tree I get the following automake errors: aclocal.m4: 790: `AM_PROG_INSTALL' is obsolete; use `AC_PROG_INSTALL' aclocal.m4: 791: `AM_PROG_INSTALL' is obsolete; use `AC_PROG_INSTALL' aclocal.m4: 1110: `AM_PROG_INSTALL' is obsolete; use `AC_PROG_INSTALL' automake: configure.in: required file `build/install-sh' not found automake: configure.in: required file `build/mkinstalldirs' not found automake: configure.in: required file `build/missing' not found configure.in: 48: required file `build/ltconfig' not found automake: installation error: cannot open `/usr/share/automake/header-vars.am' Any hints on how to fix this... I don't know much about automake. I tried editing the aclocal.m4 file and manually re-running the automake step of the bootstrap, but I still get the file not found errors. Greg |
|
From: Jozef H. <jh...@ho...> - 2003-03-27 09:22:49
|
Hi, Oh, yeah, I checked with cvs annotate, _I_ actually did change that. I didn't (intend to) remove caching, and I fixed a bug doing that particular change. It used to produce one chunk of garbaged audio after a seek! The meaning of "current_chunk" was interpreted differently at different locations in the code. Now the variable is updated at the same time as the cache. So it means "the chunk in the cache". Or did I break something? Sorry for the delay, had DSL problems. jh _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus |
|
From: Yann <ya...@3i...> - 2003-03-19 22:22:53
|
Hello everybody,
I've got a question regarding the old caching of the current audio chunk we
did in the previous code of OQT.
It seems that somebody (Jozeph?) removed it , ... well, to be precise, the
field is still in the track structure, but all the seeking functions don't
update it anymore ... I saw that external movie references have been added,
and it's way cool, but I don't see why it should require removing current
chunk caching ???
I'm asking that cause I'm updating the Directshow 3ivx Media Splitter with a
new version of OQT and it used those informations ... especially when
seeking, it's very important to be able to set a sample position and
retrieve the corresponding chunk...
For example, the old :
OPENQUICKTIMELIB_API int OQT_STDCALL oqt_set_audio_position(oqt_t *file, int
track, oqt_int64 sample)
{
oqt_int64 offset, chunk_sample;
oqt_int32 chunk;
oqt_trak_t *trak;
if(track>=0 && track < file->total_atracks)
{
trak = file->atracks[track].track;
file->atracks[track].current_position = sample;
// printf("BEFORE oqt_chunk_of_sample track %d sample %li\n", track,
sample);
oqt_chunk_of_sample(&chunk_sample, &chunk, trak, sample);
file->atracks[track].current_chunk = chunk;
// printf("AFTER oqt_chunk_of_sample chunk %d chunk_sample %d\n", chunk,
chunk_sample);
offset = oqt_sample_to_offset(trak, sample);
// printf("AFTER oqt_sample_to_offset offset %li\n", offset);
oqt_set_position(file, offset);
}
return 0;
}
has been replaced by
OPENQUICKTIMELIB_API int OQT_STDCALL oqt_set_audio_position(oqt_t *file, int
track, oqt_int64_t sample)
{
oqt_int64_t offset, chunk_sample;
oqt_int32_t chunk;
oqt_trak_t *trak;
oqt_int32_t sd_id;
if(track>=0 && track < file->total_atracks)
{
trak = file->atracks[track].track;
file->atracks[track].current_sample = sample;
// printf("BEFORE oqt_chunk_of_sample track %d sample %li\n", track,
sample);
oqt_chunk_of_sample(&chunk_sample, &chunk, trak, &sd_id, sample);
// atrack->current_chunk is the chunk currently in the buffers,
// don't change it until we really update the buffers
// printf("AFTER oqt_chunk_of_sample chunk %d chunk_sample %d\n", chunk,
chunk_sample);
offset = oqt_sample_to_offset(trak, &sd_id, sample);
// printf("AFTER oqt_sample_to_offset offset %li\n", offset);
file->data_file = oqt_file_from_sd_id(file, trak, sd_id);
oqt_set_position(file->data_file, offset);
}
return 0;
}
Comments and explanations welcome :)
Yann.
|
|
From: Nick H. <nj...@ec...> - 2003-03-14 12:10:11
|
Hi, yes - I have had the same problems under Debian - however this is not the correct fix - it breaks the build on most other platforms. The problem is that the path to the SDL include directory is not being passed to the compiler correctly. I thought I had found a fix - but it looks like it didn't work. I have added this to the Bug tracker. Cheers, nick. >hello > >Without this patch, I can't compile the CVS version on my Debian Sid >with libsdl1.2-dev package (1.2.5) > >Thanx > > >Attachment converted: Macintosh HD:oqtplayer.diff (TEXT/R*ch) (000870A1) |
|
From: Georges S. <geo...@sp...> - 2003-03-13 20:13:18
|
--- OpenQuicktime-original/player/oqtplayer.c 2003-01-03 21:18:27.000000000 +0100 +++ OpenQuicktime/player/oqtplayer.c 2003-03-13 20:48:31.000000000 +0100 @@ -35,10 +35,10 @@ #include <fcntl.h> #include <string.h> -#include <SDL.h> -#include <SDL_byteorder.h> -#include <SDL_thread.h> -#include <SDL_mutex.h> +#include <SDL/SDL.h> +#include <SDL/SSDL_byteorder.h> +#include <SDL/SSDL_thread.h> +#include <SDL/SSDL_mutex.h> #include <openquicktime/openquicktime.h> |
|
From: Capt. S. *-J. <st...@3i...> - 2003-02-28 13:11:59
|
On Friday, February 28, 2003, at 11:06 PM, Nick Humfrey wrote: > I have added a Todo list to the OpenQuicktime website. > > http://www.openquicktime.org/todo.php > > > > This is generated from the SourceForge Bug and Feature trackers. > > If there are any bugs you feel like fixing - then assign yourself to=20= > it and fix it ! > > Similarly if there is a bug/feature missing from the lists then please=20= > submit away ! Fairly cool :) can I suggest perhaps adding a SF [BUG#] to the list, with perhaps a=20 link back to the source forge bug detail -- This is only the beginning! Capt. Stux *-Jedi =20 mailto:st...@3i... 3ivx=AA is a registered international trademark. Really. **** DISCLAIMER **** "This e-mail and any attachments thereto may contain information which=20= is misleading and/or protected by vain legally positivistic rights and are supposedly intended for the sole use of the recipient(s) named above.=20 Any use of the information contained herein (including, but not limited to, reading it by accident, on the loo, or word of mouth in any form) by persons other than the designated recipient(s) is, um, well, prohibited. If you have received this e-mail in error, accident, humour, mischievous bcc, mailing list glitch, recursive bounce of a co-recipient, sendmail bug, yet another winsock worm, Claire Swire, or the sender just stuffed=20= up because your name was next to the proper one in his address book, please notify the sender either by telephone or by e-mail (yeah we know, as if you would, but then you'd be amazed, some people) and delete the=20 material from any computer. This means empty your Trash and Recycle Bin, of=20 course. And zero the data just in case. Do it six times so the feds can't get at it. Oh, and don't forget your RAM chips; take them out of your computer for at least a day so the transistors can reset. And for chrissake don't leave them in your freezer because we read on Slashdot how that can inhibit the degenerative process. Thank you for your cooperation." |
|
From: Nick H. <nj...@ec...> - 2003-02-28 12:07:12
|
I have added a Todo list to the OpenQuicktime website. http://www.openquicktime.org/todo.php This is generated from the SourceForge Bug and Feature trackers. If there are any bugs you feel like fixing - then assign yourself to it and fix it ! Similarly if there is a bug/feature missing from the lists then please submit away ! Cheers, nick. |
|
From: Nick H. <nj...@ec...> - 2003-02-27 18:19:37
|
Audio encoding is now behaving correctly (apart from MP3 - I'm working on it !). Comparisons between audio tracks created by real QuickTime and OpenQuicktime show that they are almost identical :-) Taken from website: Jozef has written a DV to movie importer called 'oqtimport_dv'. The oqtavi2mov and oqtmash2mov utilities have been apropriately renamed and moved to the 'import' directory. The oqtextractvideo and oqtextractaudio utilies have been renamed to oqtexport_audio, oqtexport_ppm and oqtexport_compressed. Jozef has also been working on support for reference movies - where the data for the movie is stored in a file(s) external to the movie file. I also noticed that Allen Day <all...@uc...> has writing a Perl interface to get metadata about movies using OpenQuicktime (Coool !) I added a link from the OpenQuicktime website. Cheers, nick. |
|
From: Gregory B. <gr...@wi...> - 2003-02-14 18:50:43
|
Thanks for the info... I hadn't heard of the "pitch" terminology before. Using --rgb gives a segfault, though. 1 video track(s) 1 audio track(s) Video track 1/1, 180x135 at 29.970000 fps, length 30 s (900 frames). Using colormodel 32-bit BGRA, no scaling supported. Colormodel not supported by the codec: we will use conversion. Audio track 1/1 at 22050 sps, 1 channel(s), length 30 s (661500 samples). Fatal signal: Segmentation Fault (SDL Parachute Deployed) This is the movie in question, for reference. http://www.greentowel.com/images/GreenTowel_GasMoney.mov Thanks again. Greg |
|
From: Antoine M. <Ant...@en...> - 2003-02-14 12:26:04
|
> oqtplayer spit this at me with one particular movie that it > didn't want to play. I'm just curious what it means... > > Thanks. > > Greg Brauer > gr...@wi... > > > > 1 video track(s) > 1 audio track(s) > > Video track 1/1, 180x135 at 29.970000 fps, length 30 s (900 frames). > Using preferred colormodel planar YVU 420 (YV12). > Using colormodel planar YVU 420 (YV12), scaling supported. > Audio track 1/1 at 22050 sps, 1 channel(s), length 30 s (661500 samples). > Error: YUV impossible: pitches not compatible with OpenQuicktime. Hi! Here is what happens: when oqtplayer wants direct YUV output, it creates YUV overlays, passing a width and height of video_width (here, 180), and expects SDL to return a SDL_Overlay with pitch=video_width for Y plane, and video_width/2 for U and V planes. The pitch is the number of bytes between two consecutive rows in the plane, which may be slightly larger than the width of the plane (here video_width or video_width/2 depending on the plane) times the number of bytes for one pixel in the plane (here 1 byte/pixel in each plane) due to alignment problems (we may like the address of each row to be 4-byte aligned, which is not the case if pitch=video_width/2=90 !). There is currently no way to force the actual pitch of the video decompressed by OpenQuicktime (it is always video_width for Y and video_width/2 for U and V) to match the one choosen by SDL. I guess I will implement in the player an extra copy that converts from OQT pitches to SDL. (But, as Stux pointed out, the fact that the height is odd may be an extra problem.) Meanwhile, the --rgb option should do the trick (while not taking benefit of your hardward YUV). Hope this helps, - Antoine |
|
From: Capt. S. *-J. <st...@3i...> - 2003-02-14 08:15:59
|
On Friday, February 14, 2003, at 05:39 AM, Gregory Brauer wrote: > > oqtplayer spit this at me with one particular movie that it > didn't want to play. I'm just curious what it means... > > Thanks. > > Greg Brauer > gr...@wi... > > > > 1 video track(s) > 1 audio track(s) > > Video track 1/1, 180x135 at 29.970000 fps, length 30 s (900 frames). > My guess is the height of 135 is essentially very hard to decode with=20= YV12 YV12 is a 4:2:0 subsampling which means it only works with even=20 dimensions. Apple QuickTime would handle this by buffering to a larger buffer and=20 then clipping. Try forcing output to a non YV12 colour model... > Using preferred colormodel planar YVU 420 (YV12). > Using colormodel planar YVU 420 (YV12), scaling supported. > Audio track 1/1 at 22050 sps, 1 channel(s), length 30 s (661500=20 > samples). > Error: YUV impossible: pitches not compatible with OpenQuicktime. > -- This is only the beginning! Capt. Stux *-Jedi =20 mailto:st...@3i... 3ivx=AA is a registered international trademark. Really. **** DISCLAIMER **** "This e-mail and any attachments thereto may contain information which=20= is misleading and/or protected by vain legally positivistic rights and are supposedly intended for the sole use of the recipient(s) named above.=20 Any use of the information contained herein (including, but not limited to, reading it by accident, on the loo, or word of mouth in any form) by persons other than the designated recipient(s) is, um, well, prohibited. If you have received this e-mail in error, accident, humour, mischievous bcc, mailing list glitch, recursive bounce of a co-recipient, sendmail bug, yet another winsock worm, Claire Swire, or the sender just stuffed=20= up because your name was next to the proper one in his address book, please notify the sender either by telephone or by e-mail (yeah we know, as if you would, but then you'd be amazed, some people) and delete the=20 material from any computer. This means empty your Trash and Recycle Bin, of=20 course. And zero the data just in case. Do it six times so the feds can't get at it. Oh, and don't forget your RAM chips; take them out of your computer for at least a day so the transistors can reset. And for chrissake don't leave them in your freezer because we read on Slashdot how that can inhibit the degenerative process. Thank you for your cooperation." |
|
From: Gregory B. <gr...@wi...> - 2003-02-13 18:40:00
|
oqtplayer spit this at me with one particular movie that it didn't want to play. I'm just curious what it means... Thanks. Greg Brauer gr...@wi... 1 video track(s) 1 audio track(s) Video track 1/1, 180x135 at 29.970000 fps, length 30 s (900 frames). Using preferred colormodel planar YVU 420 (YV12). Using colormodel planar YVU 420 (YV12), scaling supported. Audio track 1/1 at 22050 sps, 1 channel(s), length 30 s (661500 samples). Error: YUV impossible: pitches not compatible with OpenQuicktime. |
|
From: Jozef H. <jh...@ho...> - 2003-02-04 10:30:01
|
Hello and sorry for the spamming... Just a quick notice that the xvid and divx plugins now use "shitowax"'s (Yann's?) support for .mp4's "esds" atom to get the famous decoder configuration (thanks!), so that you can play the video part of .mp4 files if you have one of the codecs installed. An interface with faad (and faac for encoding) needs to be done, in order to support "mp4a". DX50 registers for "mp4v" with merit 80 and "XVID" uses merit 85. So I guess that for 3ivx 90 would be a reasonable choice unless the encoding is conform too, in which case it merits 100. Looking forward to a release of 3ivx for linux! ;) jh -- Don't accept your dog's admiration as conclusive evidence that you are wonderful. -- Ann Landers |
|
From: Capt. S. *-J. <st...@3i...> - 2003-02-01 14:39:31
|
On Sunday, February 2, 2003, at 01:34 AM, Capt. Stux *-Jedi wrote: > The codec is currently limited to Simple Profile, but writes a well=20 > formed, high-quality, compact bitstream :) I meant, the encoder... the decoder handles Advanced Simple Profile=20 MPEG4v1 or v2 with multiple bframes, qpel and 1 warp point GMC Also, 3ivx has some of the best post-filters available (and they're fast... if we can get GCC to compile them ;)) -- This is only the beginning! Capt. Stux *-Jedi =20 mailto:st...@3i... 3ivx=AA is a registered international trademark. Really. **** DISCLAIMER **** "This e-mail and any attachments thereto may contain information which=20= is misleading and/or protected by vain legally positivistic rights and are supposedly intended for the sole use of the recipient(s) named above.=20 Any use of the information contained herein (including, but not limited to, reading it by accident, on the loo, or word of mouth in any form) by persons other than the designated recipient(s) is, um, well, prohibited. If you have received this e-mail in error, accident, humour, mischievous bcc, mailing list glitch, recursive bounce of a co-recipient, sendmail bug, yet another winsock worm, Claire Swire, or the sender just stuffed=20= up because your name was next to the proper one in his address book, please notify the sender either by telephone or by e-mail (yeah we know, as if you would, but then you'd be amazed, some people) and delete the=20 material from any computer. This means empty your Trash and Recycle Bin, of=20 course. And zero the data just in case. Do it six times so the feds can't get at it. Oh, and don't forget your RAM chips; take them out of your computer for at least a day so the transistors can reset. And for chrissake don't leave them in your freezer because we read on Slashdot how that can inhibit the degenerative process. Thank you for your cooperation." |
40 messages has been excluded from this view by a project administrator.
