Reprise du message précédent :
c'est dallas le monde de la video !!!!!!

BlackSunSoft a écrit a écrit : Ah oui, je savais même plus que j'avais lancé le topic... L'auteur de l'OGM se balade de temps en temps sur le forum, j'ai pas encore eu le temps de m'en occuper.   Sinon le TMF/MCS va commencer a etre codé dans 2 semaines en theorie, Ingo Ralf Blum quitte mon forum et declare le projet MediaXW (Ogg vorbis dans AVI) comme 'failed'. Il quitte mon forum car il se concentre sur ses exams...   Sinon moi je vais bien je suis encore tombé en panne de moto ce matin       Il y a quelques divergences sur le forum de Doom9, certains n'aiment pas le TMF/MCS, d'autres oui...

 
 
j'vais dire 2-3 trucs sur mes impressions sur l'ogm...
y'a un truc qui me chiffonne assez sévère déjà c'est l'idée que c'est pas splittable c'est pas cool... Apres réflexion la seule solution que je vois serait de faire un divx avec audio non compressé, puis apres de compresser l'audio [que on coupe donc a partir des 2 fichiers avi] pour remuxer via graph edit apres... C'est assez batard et ca me plait pas trop
Pour ce qui est de la qualité et des résultats, avec les dernieres version c'est 'parfait'... Pour info, l'ogm commence a etre utilisé en sous-terrain (w***z world) donc c'est plutot un bon point de voir qu'il arrive à percer là bas.
Pour ce qui est du TMF, ca me parait une bonne idée, cependant, y'a encore kke chose qui m'embete:
je trovue que ca serait bien pratique de pouvoir muxer dans les données du TMF en interne ou en externe les données:
par exemple, dans un divx en TMF avec une langue, il serait bien pratique de pouvoir inclure en externe une autre langue (qui pourrait ptet contenir aussi des subs en +)
en gros:
faire un TMF avec un flux vidéo, et un flux audio
une second TMF avec d'autres flux (audios, subs, autres vidéos, etc) et faire en sorte d'avoir un launcher 'avancé' (tjrs en TMF ? pkoi pas) qui récupère les infos des différents fichiers pour les muxer correctement.
Le but (faut bien qu'y en ai un sinon ) serait de pouvoir splitter un divx en 2CD proprement:
un CD avec la vidéo et UNE langue et un second avec le reste, au moment de la lecture, on copie les files voulus sur le DD et on lance le tout...
résultat, gain de place, et gain de qualité aussi...
 
NB: j'étais loin de me douter que PowerDiVX avait dans son corps de francais

Et oui PowerDivX est français

j'ai fait deux divx avec son en ogg un en xvid no problem et u en divx 4 no problem non plus enfin je n'arrive qu'a les luires sous win2k et wmp4 powerdivx plente à tout les coups et sous windows 98 impossible des les lires (erreur quartz.dll) si quelqu'un a une expklication à cela merci de vos réponses
 
 
doit je réinstaller windows 98  
????

non faut remettre des filtres.

lesquels ???

-> codec divx
-> codec xvid
-> filtres ogg [nvelle version d'ailleurs qui a kkes bugs mais qui apporte pas mal de nouveautées]
 
/!\ en regle générale, pour l'ogm je vous conseille fortement de n'utiliser pour l'instant QUE MP6.4 si le fichier a plusieurs flux [faites un tour sur doom9.org, il a remis à jour le tuto sur l'ogm a jour ]
 
l'ogm a fait pas mal de progres depuis le début fev et est bien parti pour remplacer l'avi *rapidement*
 
le tmf/acm peche par son absence vivement que le projet de codage soit lancé

Le codage a dejà commençé et les premiers codes sources sont dispo sur mon forum  

http://www.stud.fernuni-hagen.de/q5045045/History.txt
 
Ben finalement j'ai lancé l'extension .ogm et l'auteur l'a adopté

BlackSunSoft a écrit a écrit : http://www.stud.fernuni-hagen.de/q5045045/History.txt   Ben finalement j'ai lancé l'extension .ogm et l'auteur l'a adopté

 
bonne idée ça evitera les confusions permanente avec le format audio ogg

J'ai été obligé quand même de developer une fonction pour reconnaitre un OGG audio d'un OGG Media  

Oxygen3 a écrit a écrit :   je trovue que ca serait bien pratique de pouvoir muxer dans les données du TMF en interne ou en externe les données: par exemple, dans un divx en TMF avec une langue, il serait bien pratique de pouvoir inclure en externe une autre langue (qui pourrait ptet contenir aussi des subs en +) en gros: faire un TMF avec un flux vidéo, et un flux audio une second TMF avec d'autres flux (audios, subs, autres vidéos, etc) et faire en sorte d'avoir un launcher 'avancé' (tjrs en TMF ? pkoi pas) qui récupère les infos des différents fichiers pour les muxer correctement. Le but (faut bien qu'y en ai un sinon ) serait de pouvoir splitter un divx en 2CD proprement: un CD avec la vidéo et UNE langue et un second avec le reste, au moment de la lecture, on copie les files voulus sur le DD et on lance le tout... résultat, gain de place, et gain de qualité aussi...

 
Ben ca c'est pas en rapport avec le format en lui même mais plutôt les softs qu'il y a autour. Tu peux très bien avoir un AVI avec juste la video et un fichier WAV à coté, je suppose qu'avec Graphedit tu peux mélanger pour faire ensuite ta video !
 
Sinon comme l'as dit BlackSunSoft le parser commence à etre codé. Alors si les programmeurs ont des idées, désirs : qu'ils s'expriment ! (en particulier au niveau de l'API, pour l'instant on est sur un read/write de fichier)

     
justement, les filtres de graph edit sont en path absolu et non pas en path relatif (enfin on peut en theorie les faire mais apres ca marche plus la relecture ...)
c'est tréééé reloud ...
-> c'est pour ca que ca serait cool d'avoir ca réimplémenté mais mieux [y doit y avoir un blem dans l'encodage du filter ]
 
[citation]
Sinon comme l'as dit BlackSunSoft le parser commence à etre codé. Alors si les programmeurs ont des idées, désirs : qu'ils s'expriment ! (en particulier au niveau de l'API, pour l'instant on est sur un read/write de fichier)  
[/citation]
oué
je sais

EH HO ! arrêtez vos conneries
je crois que vous parlez de l'avi sans connaissance de cause... l'avi vieux? alors qu'actuellement les soft n'utilisent que 20% des capas de l'avi... vous déconnez :halalala...:cajoline
 
en effet il est possible dans un fichier avi de faire des choses du style :
3 vidéos, 4 pistes 5.1 par vidéos, n soustitres par langues dans trois formats (srt...), des résumés, des infos connexes, des screenshots, et l'original soundtrack dans un seul et unique avi ne pose pas de pb (heu si la taille du disque...)
 
de plus c'est compatible avec tous les soft (vdub....) sous mac unix (linux) windows et dieux seul sait quoi encore...
même les professionnels de la vidéo ont compris l'intêret de conserver cette compatibilité.. et on créé un standart ouvert : odml (dont le soft utilisant 20% des capas est vdub et c'est le plus abouti....)
je peux fournir de la doc et d'autres choses
il y a 1 an je pensais que l'avi c'était de la merde, pour un projet linux j'ai créé un lecteur avi, sous odml, depuis j'ai compris les intêrets :
rapidité de recherche
possibilité d'étendre le format à l'infini
on peut le couper n'importe où
possibilité de synchro => on peut facilement faire du streaming à partir de l'avi....
 
 
ALORS ARRETEZ DE DECONNER....
surtout que l'ogg ne fait pas l'unanimité et qu'en plus il sera écrasé par le aac (que j'ai pu tester et dont les qualité sonores en 64kb sont celles d'un mp3 128+)
 
bruce, blacksun, je vous mail en privé pour discus
 
je remercie Atlantis (mon frère pour m'avoir prévenu d'une telle connerie)
eet dont j'utilise le compte suite à des problèmes sur le mien
 
à don entendeur salut !
et sans rancunes

-> multi sources container ... tu as essayé ? pke bon je dis pas que la théorie le permet, mais la pratique, c'est pas génial
-> syncrho parfaite...   tu le fait avec du MP3 en VBR ou de l'ogg et on en reparle?
-> déplacement facile ... lis un ogm avec justement 3 flux vidéos, 10 flux audios, 50 subs si ca t'ammuse, déplace toi dans le fichier, et ta rapidité de recherche on en reparle...
-> couper n'importe ou... soit, mais le acm aura aussi ces points particuliers vu que c'est pas un format spécial streaming
-> streaming en avi? HAHAHAHA   ok, tu peux faire du stream en mp3 aussi, mais est-ce que le fichier est prévu pour ? réponse je crois pas, y'a pas justement comme dans le ogg [container OGG] les bits de correction d'erreur avancé qui font aussi que c'est pas splitable facilement
 
sans rancunes
[je dis pas que l'avi c'est pas cool, mais que les fonctions actuelles que l'ont a avec l'avi sont nulles ou trop limités, et que l'inclusion d'autres trucs dedans ce fait à l'aide de bidouilles ... [genre l'ogg]

 
Amusant, j'étais en train de tester Psytel AAC en 2.11 sur certains samples en lisant cela. J'aimerais bien avoir le nom de l'encodeur sur lequel s'est appuyé ton test ou expérience d'écoute. Parce qu'à ma connaissance, l'AAC n'est pas vraiment optimisé pour descendre aussi bas. D'ailleurs, à 64 k/s, que ce soit avec Liquifier ou Psytel, c'est aussi mauvais que le mp3 classique : le wma, le mp3pro et l'ogg sont largement supérieurs. A 128, l'AAC est excellent certes.
 
Peut-être la technologie SBR, la même que pour le mp3pro, peut expliquer cette impression de bonne qualité. Mais tout de même, je doute que le gain par rapport au mp3 soit de 50%. Cela m'étonnerais fort.
 

 
J'ai bien envi de te dire la même chose.

Bon, là j'avoue faut que tu me disent comment tu stream de l'AVI ?
 
Et le but du MCF est de proposer de la concurrence au MP4 en plus de l'avi. regardez donc les specs sur www.powerdivx.com dans la sections Articles

euh là c'est moi, Atlantis, qui reprend la main (mon frangin a encore oublié son pass     ).
j'en connais moins que lui, mais je suis d'accord avec un truc : même vdub n'utilise pas 20% des spécif (j'espère qu'il va trouver le temps de vous mailler ça). le mp3 vbr est déjà prévu, mais ni vdub, NI NANDUB n'utilisent les bits se synchro ...
 
et dans le fichier MCF (lien de blacksun) ... la moitié est déjà posé dans le standard de l'avi. par contre faudra qu'on me dise l'intéret d'un V.Framerate ...  
mais c'est vrai qu'il y a de l'ecc ... mais bon perso je m'en tape complètement, car les films qu'on trouve sur le net et la qualité d'encodage ...   (et encore je sais pas si c'est pas prévu avec l'avi)  
 
bon de toutefaçon il y a pas le feu à la barraque, le plus fort l'emportera (quoique en informatique ...     )
 

ouaip    

euh pour le aac, c'est rien c'est le combat perso de mon frangin . le pb l'aac c'est que la théorie qui est derrière est suffisamment balaize pour que les industriels soient intervenus, ralenti le projet, (et même arrété complètement passé un temps) => beaucoup de programmeurs d'origine ont quité le projet, dégoutés, à ce qu'il parait .
et mp3pro and co. sont toujours basés sur de la T.Fourier ...
 
mais bon c'est complètement hors sujet ici donc ... (et pis faut que je retourne au taff )

bon retrouvé mon pass merci atlantis...            
voici les soit disant avantages de l'ogg :            
- Vorbis gives you excellent sound quality already at 64kBit (Give it try !!)            
je ne polemiquerai pas dessus....            
           
- All channels in Ogg have timestamps. You will never have to deal anymore with            
   syncronisation problems            
l'odml permet aussi l'utilisation des timestamps, seulement vdub (ou nandub) ne font qu'utiliser la possibilité d'étendre l'avi au delà de 1Go (et en plus il le font mal : au lieu de créer de chunck de 1Go dans le même avi (j'usqu'à 4 (taille fichier max fat32 : 4Go) sous win et à comcurence          
de 4 petaoctet sous linux   ) il font des fichier avi indépendants.            
           
           
- My filters support the IAMStreamSelect interface. I.e. if you use more than one soundtrack you            
   will not get a mixture of all channels as with AVI but Media Player will offer you choosing            
   the language        
ah   c'est nouveau ça??? je crois que vous confondez une chose : les bug microsofts et les spécifs de l'avi...        
l'avi n'est plus la propriété de crosoft ....        
je reconnais que l'utilisation du WAV comme format audio dans l'AVI n'est pas forcément judicieux (peut être au début mais   )      
     
je retrouve un lien vers les spécif odml (je les ai en pdf mais je ne peux pas attacher de fichier ici) et je reposte      
     
 

   
si tu utilise les outils crosoft, c'est normal : ils ne sont pas "odml compliant" : les headers sont bien odml mais les outils n'utilisent encore que l'avi original...    
   

   
utilise les streams de synchro et voili mais aucun outils ne les inclus (même vdub) : je suis allé voir dans les hexa...    
   

   
encore une facilité des stream de synchro....    
   

   
je reconnais que le streaming n'est pas le fort de l'avi mais je me dis de plus en plus que le streaming n'est pas utile dans un container : ce que dois fournir un container c'est une facilité de recherche, de déplacement... vous aimez vous les 3 ou 4 secondes de 'prebuffer' du médiaplayer perso non....    
   

   
par contre dans l'avi rien ne nous empêche de créer un flux de 'CRC' facilement coupable....  [/quote]  
et je pense que c'est au format vidéo d'inclure des CRC et pas au container. un container doit être simple   mais efficace....  
 
 
je vous présente mes excuses pour le message incendiaire mais je pense que l'on veut créer un nouveau standard sans connaître les possibilités de l'ancien.... on a déjà eu assez de mal sous linux pour obtenir des soft vidéo de qualité... alors si on viens rajouter des trucs
de plus j'utilise Vdub et je trouve ce soft génial (et très pratique)... pensez y : d'autres ont essayé de supprimer l'avi et ils se sont tous cassé les dents....

http://www.the-labs.com/Video/odmlff2-avidef.pdf  
je peux fournir des .h  de qualité à ceux qui veulent des headers odml...

Atlantis a écrit a écrit : euh là c'est moi, Atlantis, qui reprend la main (mon frangin a encore oublié son pass     ). j'en connais moins que lui, mais je suis d'accord avec un truc : même vdub n'utilise pas 20% des spécif (j'espère qu'il va trouver le temps de vous mailler ça). le mp3 vbr est déjà prévu, mais ni vdub, NI NANDUB n'utilisent les bits se synchro ...

 
Effectivement, les logiciels peuvent toujours contourner les difficultés engendrées par une mauvaise conception. Le but du MCF est justement de connaitre ces erreurs de conception et de les corriger pour faire un truc neuf !
 
Il a simplement les avantages de l'AVI moins pas mal d'inconvenients. C'est aussi simple que ca.

cityhunterxyz a écrit a écrit : je vous présente mes excuses pour le message incendiaire mais je pense que l'on veut créer un nouveau standard sans connaître les possibilités de l'ancien.... on a déjà eu assez de mal sous linux pour obtenir des soft vidéo de qualité... alors si on viens rajouter des trucs de plus j'utilise Vdub et je trouve ce soft génial (et très pratique)... pensez y : d'autres ont essayé de supprimer l'avi et ils se sont tous cassé les dents....

 
Avery Lee qui a créé VirtualDub est parfaitement conscient des limitations de l'AVI (voir le long article sur son site pour s'en convaincre). Donc il y a de fortes chances pour qu'il passe lui aussi au MCF. (sinon, ca serait pas très dur de faire une nouvelle version qui le supporte)
 
Pour ce qui est de Linux, c'est justement le but de faire un truc portable et utilisable aussi bien sous Windows, Linux, MacOS, etc.

arf, lis plus calmement ...  

Faudrait qu'on discute des API pour le Splitter MCF, j'aimerais bien IAMStreamSelect Interface comme pour l'OGM, c'est cool et ça m'evite de refaire du code (I am a lazy boy, in a crazy worrrrrrld, Life is Dedynamic). Par contre j'aime pas utiliser les LCID pour les languages comme pour les DVD, je prefere recuperer la description...

ouais un truc portable... je viens de finir de lire les spec de l'"ogm" et je ne vois vraiement pas ce qu'il apporte... moi ce que je vois (après réflexion) c'est que l'avi permet de se déplacer rapidement dans les streams, peut être étendu à l'infini sans problème de compatibilité, qu'il est déjà lisible sous windows, linux, atari, mac os, 99% des unix.... et que depuis l'odml c'est un standard ouvert....
de plus ce n'est pas un problème de conception mais des bugs crosoft : la limitation 1Go ne viens que de crosoft et pas de l'avi...
fournissez des liens vers le MCF : je vais aller voir... mais si cela n'apporte rien (ou pas grand chose comme l'OGG) alors je resterai sur l'AVI...

www.powerdivx.com pour le MCF, il y a les specs (section articles), le forum ou tu y verras les developpers

Moi qui suis plus porté sur l'audio que sur le reste, le MCF apporte la synchro entre audio et video en natif ! Il y a un timecode par frame audio/video/autre.
Ni l'AVI ni l'OGM ne l'ont à ma connaissance (ODML, connais pas).

En lisant le document PDF sur l'OpenDML, je vois qu'il y a un timecode. Donc à priori ca pourrait marcher.
Donc j'invite tous les gens qui connaissent un peu (plus que moi) ce format à aller en discuter sur le forum de PowerDivX dans la section MCF. Ca sert à rien d'inventer la roue si elle existe déjà !

premières impressions MFC :
-> utilise big endian : nécessitera une conversion sur 90% du marché
-> les zones d'infos sont fixées : on retrouve le problème du mp3, lorsque les zones ne suffiront plus il faudra faire un second header, ne permet pas de faire du 'custom', les champs utilisent de la place même s'ils ne sont pas utilisés (au contraire de l'avi)
 
je continue de lire....

 
C'est vrai. Comme les x86 sont en little endian et que ce format sera utilisé la plupart du temps sur ce genre de machine, C con de devoir tjs faire la conversion. Par contre peut-être que c'est mieux pour l'electronique ou le réseau (pour pouvoir l'embarquer). Le MPEG est en quoi ? (audio et video)
 

 
C'est vrai, j'ai pensé à ca hier. C'est con de réserver de la place pour des infos quand elles n'ont pas lieu d'être. D'un autre coté ca simplifie grandement le codage et donc moins d'erreurs possibles, plus facile à supporter. En gros le minimum d'infos nécessaire a été mis pour chaque type de flux/bloc. Je crois qu'on peut ensuite ajouter des meta-informations.

[jfdsdjhfuetppo]--Message édité par robUx4--[/jfdsdjhfuetppo]

pour les techniques : voici un extrait de mon header qui explique comment l'avi est constitué    
:  
   
/* short description of the AVI file format  
 #define <size> 32 bit size of the data enclosed in {}  
   
 the file : RIFF(size){'AVI '....} <=> RIFF****AVI ....  
 be carefull of the space char that follow AVI, **** is the size in oct grouped  
 by 8bit  
   
  form of AVI (maybe RIFF...) :  
   
 riff avi format :  
 ->'XXXX' =fourcc  
 ->(XXXX) =size  
 ->for exemple RIFF(3F030201)'AVI 'LIST... will be in file RIFF0102033FAVI LIST....  
 -> note :space after AVI, little indian format , (size) is the size of the data (begining after the (size))  
  for the exemple below : size when given is in hexa  
  in the example : the (size) of the first list is the size of all sub-tabed data begin at h (from hdrl)  
   
RIFF (size) 'AVI '      
->LIST (size) 'hdrl'  
--->'avih' (0038)  
--->LIST (size) 'strl'    <-stream 00    
----->'strh' (0038)  
----->'strf' (????)  
----->'indx' (3ff8)      
----->'vprp' (0064)    
--->LIST (size) 'strl'    <-stream 01    
----->'strh' (0038)  
----->'strf' (????)  
----->'indx' (3ff8)    
--->LIST (size) 'strl'    <- stream 02    ----->'strh' (0038)  
----->'strf' (????)  
----->'indx' (3ff8)      
--->LIST (size) 'odml'  
----->'dmlh' (????)      
->LIST (size) 'INFO'     --->'ISFT'(size)  
--->....  
->'JUNK' (size)  (optional)  
->LIST (7f??????) 'movi'      
--->'00dc' (size)    
--->'01wb' (size)    
--->...  
--->'ix00' (size)      
--->...  
--->'02ix' (size)      
--->'idx1' (00??????)          
RIFF (7F??????) 'AVIX'  
->'JUNK' (size)        
->LIST (size) 'movi'  
--->'00dc' (size)        
RIFF (7F??????) 'AVIX'      
->'JUNK' (size)          
->LIST (size) 'movi'  
--->'00dc' (size)        
   
new chunk or list type can be defined since application must ignore uknown chunk or list...  
The actual data is contained in subchunks within the 'movi' LIST chunk.  The first two characters of each data chunk are the stream number with which that data is associated.  
   
The grouping into LIST 'rec' chunks implies only that the contents of the chunk should be read into memory at the same time.  This grouping is used for files specifically intended to be played from CD-ROM.  
   
The index chunk at the end of the file should contain one entry for each data chunk in the file.  
   
*/  
   
bon j'ai du virer les commentaires : cela dépassait trop, et les tab ne sont pas prises en compte...  
   
explication :  
au début de l'avi on trouve la liste des headers, chaque flux (stream) possède un header (strh), et optionellement un format (strf), un index (indx), des propriétés aditionelles (vprp)... et on peut en rajouter puisque toute application qui ne comprend pas la 'chunk' doit l'ignorer....  
ici nous avons un fichier constitué de 3 streams (par ex video, audio, timecode) faisant entre 3 et 4 Go (1 chunk AVI plus 2 AVIX (avi extension)  
les données sont dans le chunck MOVI :  
**dc ou **wb : numero de stream +dc ou wb : les données  
ix** : partial index pour stream **  
**ix : timecode stream  
   
la chunck INFO contient des info additionnelles : lieux temps, software utilisé, nom de la personne ayant digitalisé... entout près de 23 champs que l'on peut étendre à volonté (ce sont des chuncks).le fait que le format ne soit pas fixé a pour conséquences : on n'utilise que la place réellement nécessaire, mais l'update nécessite la recopie entière du fichier... à mon avi ces chunck devraient se trouver dans les strl de description, permettant ainsi de stocker des infos par stream en plus des infos globales (on peut le faire ce n'est pas interdit)  
   
chaque chunck ou list est suivi de sa taille, cela permet de sauter les morceaux que l'on ne veux pas (au premier abord c'est de la perte de place mais cela permet de se déplacer plus vite dans le fichier)  
   
enfin pour les problèmes de group : rien n'interdit de rajouter après le chunck odml un chunck grps  
   
de même pour les soutritres : rajouter un flux de soustitre, prévoir un header pour avoir une interface générique sous titres.....  
   
autre truc passé sous silence : il existe d'autres extention dans odml permettant d'encoder sur un taille et d'afficher sur une autre. c'est utilisé dans les DVD et cela permet de gagner du bitrate (l'oeil est moins sensible aux horizontales qu'aux verticales, ou l'inverse donc on peut compresser plus en h qu'en V....)    
   
à méditer

[jfdsdjhfuetppo]--Message édité par cityhunterxyz--[/jfdsdjhfuetppo]

Je suis pas sûr d'avoir tout compris mais, le pb d'avoir bcp d'infos pas forcément nécessaires au débt d'un stream c'est pas franchement limitatif, peut-être au niveau du streaming C tout (le MCF est pas fait pour ca à la base, c'est plus un format d'édition).
 
Sinon si tous ces trucs existent... Qui les utilisent ?
 
L'idée c'est aussi de fédérer pas mal de développeurs (en faisant un truc plus simple, clair). Ce que les formats propriétaires auront plus de mal à faire (faudra des sous dans ce cas là).
 
OpenDML est ouvert ? Mais qui l'a créé ? Où sont les vrais specs ?

Ca va mieux en le disant :
http://www.matrox.com/videoweb/new [...] dmlff2.htm
 
C'est donc officiellement supporté par Microsoft depuis un moment...
Alors pourquoi l'utilisation de l'AVI est encore si pourrie ? (qui n'a jamais eu de décalage de son dans un AVI ?)

normalement le lien donne sur les vrai spec : odml n'est qu'une modif de l'avi....
la base de l'avi est dispo chez crosoft gratuitement et est bien documenté sur pas mal de sites
ceux qui ont ecrit la spec voulaient combler les lacunes et le format est a peu pres complet
actuellement le soft le plus abouti en matiere odml est nandub... mais je pense qu'il n'utilise pas plus de 20 a 30% des possibilités
à nous de les utiliser
 
le header est dispo sur demande....

   
parce que crosoft n'a changé que les headers et pas le soft derrière....    
sous linux y a po de pb euh si les codecs

[jfdsdjhfuetppo]--Message édité par cityhunterxyz--[/jfdsdjhfuetppo]

Si tu veux la liste des ajouts par rapport à l'AVi (2.0 je suppose) :
 
http://mediacontainer.sourceforge.net/
 
Est-ce qu'il y a dans la liste (Main advantages over AVI) des choses qui existent dans l'AVI (mis là par erreur donc) ?

• Easier and faster to read        

easier : peut être, faster pense pas, l'avi est optimisé pour des lectures de blocs => on peut pas faire plus rapide.        

• The file can be read sequentially, so it is fast to play it from slow medias, like CDs        

c'est le cas de l'avi aussi.....      
       

• Error detection (it can tell you the position, so that you can re-download that specific part)        

pas implémenté dans l'avi, peut être facilement ajouté....      
       

• Can be burnt to CD-R in mode 2 form 2, allowing you to put 15% more data on a disc.        

je vois pas le rapport....        
     

• Can play non-damaged parts even if the file is badly damaged        

je pense qu'un fichier sans header aura du mal a fonctioner (c'est ce que j'appelle badly damaged)        
     

• Incomplete downloads work without slow conversion or things like that (kind of streaming)        

on n'utilise pas les stream d'index d'odml => un gros index a la fin   s'il merde  on est dans la merde.      
     

• Extended Info (like ID3 in MP3) and attaching files        

Extended Info is in fixed position, so it can be easily read by search-engines etc.        
idem avi, mais seul nandub utilise les champs info....      
     

• Interlace without codec supporting it        

donnee de style data : pas de codec, pas de format.... on n'est pas non plus oblige d'avoir un codec supportant le fichier non plus : j'ai pas d'aac sous win, et je crée mes avi sous win      
     

• Non-1:1-pixels (used in DVDs, SVCDs and VCDs), can improve image-quality        

odml extension....      
     

• Stereo-vision (yes, 3D-movies; shutter-glasses or other hardware required though)        

pas impossible, je vais voir....      
     

• Contains information on where to get codecs for playing the content        

champs info...      
     

• Separates by format (not by codec, like AVI)        

????????      
     

• Subtitles and PNG-titles, without external files        

possible aussi....      
     

• Variable framerates        

odml extension si je me souviens bien, mais utilité ???      
     

• Truely working variable bitrates        

ah les bugs crosoft      
     

• Contents, information of filetype and the original size of the file can be read in DOS or any other OS, without MCF-utils        

et sous linux je ne peux pas lire les infos....      un éditeur hexa peut le faire => n'importe quel soft peut le faire...
 

• Gamma-correction (better quality and same look on different platforms, like Mac/PC)        

odml je crois.... mais a verifier    
     

• Supports DVD-like menus and other goodies (we don't support forced copyright-screens though)        

non, peut être ajouté...    
     

• Solid standard; not a pile of hacks        

   
   
  (ceci ne s'adresse pas au lecteur mais est le résultat de la comparaison)

[jfdsdjhfuetppo]--Message édité par cityhunterxyz--[/jfdsdjhfuetppo]

1 bidouille

 
Ben moi l'intéret je le vois en GROS !
 

 
C'est sûr. Mais toujours dans l'optique du CD, s'il est endommagé à endroit c'est encore lisible...
 

 
Donc, bidouille (2) (c'est pas en natif)
 

 
Bidouille ? (3)
 

 
Bidouille (4)
 

 
Bidouille ? (5)
 

 
Ben si tu veux faire un plan ralenti, ou acceléré tu changes le bitrate et tu gardes les mêmes frames... Pas sûr que ca sera utilisé rapidement, mais bon...
 

 
On en revient toujours là !
Alors qu'avec le MCF et son parser DirectShow ca sera de l'histoire ancienne.
 

 
Bidouille ?
 

 
Bidouille ?
 

 
C'est la clef de tout !
Tout est prévu dès le départ. Et ca reste extensible comme on veut.
 
SInon j'ai vu que pour l'OpenDML le truc pour synchroniser c'est de mettre un chunck vide à un moment pour dire où en est le son et la video... Alors que tous les trucs pros utilisent un timecode.
 
Comme l'AVI/RIFF on peut lui rajouter pas mal de choses (quasiment tout) mais ca reste un truc bancal. Avery Lee disait d'ailleurs qu'il était impossible de mettre du MPEG1/2 dans de l'AVI... (c'est possible avec le MCF, sans bidouille)

c'est lourd d'avoir a corriger les annerie deux fois....  en gras mes commentaires
 
 

   
1 bidouille    
non un stream de crc comme c'est le cas en degise sous mcf  
 

     
Ben moi l'intéret je le vois en GROS !    
il n'y a aucun rapport entre le format de fichier et le format de cd.... comme si on ne pouvais plus graver de avi sur un dvd ou autre chose du meme style  
   

   
   
C'est sûr. Mais toujours dans l'optique du CD, s'il est endommagé à endroit c'est encore lisible...    
   
dans le cas de l'avi si l'on utilise les odml c'est le cas... les frizzes dû a des data mauvaises viennent des codec et non pas du format le contenant, actuellement vdub et autre soft n'utilisent que le chunk idx1 en fin de fichier pour les indexes alors qu'un fichier odml possède un stream d'index (qui n'est pas utilise), resultat si la fin est naze on a du mal a se deplacer, mais vous utilisez des pelles en plastiques pour contruire la tou effel... et vous vous plaigniez...  
 

   
  onc, bidouille (2) (c'est pas en natif)    
non pas dans la version 1, mais c'est dans la version 2 (odml ) puisque nandub le permet et que cela marche tres bien c'est reconnu par l'explorer....sous 95    
 

   
   
Bidouille ? (3)    
non...norme... lourd....    
 

   
   
Bidouille (4)    
et quand tu voudra trois angles tu fera comment ? tu rajoute un stream.... son truc c'est seulement de grouper des streams... banal...  
   

   
   
Bidouille ? (5)    
non extension, tu connais le codec divx? et bien il traite des donnees et les converti en image, tu connais le codec sub? non, c'est normal il n'existe pas, mais il transforme des text en images... et les incruste sur l'image  
   

   
   
Ben si tu veux faire un plan ralenti, ou acceléré tu changes le bitrate et tu gardes les mêmes frames... Pas sûr que ca sera utilisé rapidement, mais bon...    
dans ce cas c'est supporte par odml  
   

   
   
On en revient toujours là !    
Alors qu'avec le MCF et son parser DirectShow ca sera de l'histoire ancienne.    
vous utilisez de la merde et vous continuez, corrigez les bug, faites votre propre avi reader (comme vdub ou sous linux) et vous n'aurez plus de pb, que quelqu'un ose dire 'j'ai eu des problemes de synchro sous vdub...' que je rigole....le pb viens des player pas de l'avi : quand la desynchro se produit (des fois 5 a 10s sous bplay) j'ouvre sous vdub et oh miracle y'a pu.... bizarre.....  
   

   
   
Bidouille ?    
norme, a verifier  
   

   
   
Bidouille ?    
lourd? nnnnnnnnnnnnooooooooooooooooooonnnnnnnnn!!!!!!  
   

   
   
C'est la clef de tout !    
Tout est prévu dès le départ. Et ca reste extensible comme on veut.    
tu sais pourquoi y a de moins en mois de personnes qui utilisent les id3? je vais te le dire : la version 1 ne permet rien et la version 2 n'est pas lisible partout... si on fixe les headers en incluant des specificites alors on ne peut pas faire evoluer... c'est le cas du mp3, tu prevois tout, et 6 mois plus tard y'a quelqu'un qui en veut plus, puisque tout etait prevu, tu cree un nouvel header et plus personne ne les utilises....  
   
SInon j'ai vu que pour l'OpenDML le truc pour synchroniser c'est de mettre un chunck vide à un moment pour dire où en est le son et la video... Alors que tous les trucs pros utilisent un timecode.    
et le sage montra la lune et l'idiot regarda le doigt... tu as lu mon post sur le format avi? et bien relis le : tu y trouvera un stream de time codes    
 
Comme l'AVI/RIFF on peut lui rajouter pas mal de choses (quasiment tout) mais ca reste un truc bancal. Avery Lee disait d'ailleurs qu'il était impossible de mettre du MPEG1/2 dans de l'AVI... (c'est possible avec le MCF, sans bidouille)  
 
.........tu sais dans de l'avi on met du mpeg4, on en met aussi dans des mpg, on en met aussi dans de l'asf.... alors du mpeg2 ou 1 et bien on peut aussi.......  
 
 
c'est lourd surtout que je suis en qwerty....

[jfdsdjhfuetppo]--Message édité par cityhunterxyz--[/jfdsdjhfuetppo]

Je crois que t'as oublié qqchose