Computación WikiProject | |
Sección de codificación
Cita: "Motion JPEG utiliza una forma con pérdida de compresión intracuadro basada en la transformada de coseno discreta (DCT). Esta operación matemática convierte cada cuadro / campo de la fuente de vídeo del dominio del tiempo en el dominio de la frecuencia (también conocido como dominio de transformación)". I cree que se ha producido un error. Al igual que la compresión de imágenes JPEG, el DCT debería convertir el dominio de posición espacial en el dominio de frecuencia espacial dentro de la imagen única. Si realmente se trata de una conversión de frecuencia temporal a temporal, contradice lo que sé de MJPEG y contradice la afirmación de que cada imagen de cuadro JPEG se codifica independientemente de los cuadros adyacentes y que esta parte de la codificación es compresión intracuadro. Quizás alguien que realmente sepa con certeza podría hacer la corrección, ya que mi conocimiento es teórico y me faltan detalles específicos sobre MJPEG. Dynamicimanyd ( charla ) 19:25, 22 de marzo de 2011 (UTC)
Sección de cámaras digitales
A través del uso intensivo del tiempo pasado, esta sección implica que MJPEG en cámaras digitales es solo de interés histórico y ya no se usa en estas cámaras. Esto no es cierto ya que todavía se están lanzando nuevas cámaras con funciones de películas MJPEG y creo que esta sección debería reformularse. Esta sección también establece que dichas cámaras solo graban hasta 320x240 a un máximo de 15 fps; nuevamente, esto no es cierto ya que ahora son comunes resoluciones como 640x480 a 30 fps. Cpc464 ( conversación ) 11:42, 16 de junio de 2008 (UTC)
Un comentario sobre la sección 'críticas': la primera viñeta enfatiza la existencia de "preocupaciones de compatibilidad" de MJPEG, mientras que en la última viñeta, la "amplia compatibilidad" se atribuye al formato. ¿El autor del texto, o un experto en el área, aclararía esta contradicción? Ataúdes usados anteriormente ( charla ) 20:07, 4 de junio de 2008 (UTC)
¿Alguien más está confundido por estas declaraciones?
"La calidad resultante de la compresión de video intracuadro es independiente del movimiento en la imagen, que difiere del video MPEG, donde la calidad a menudo disminuye cuando el metraje contiene mucho movimiento".
"Antes del reciente aumento de la codificación MPEG-4 en los dispositivos de consumo, una forma de escaneo progresivo de MJPEG también tuvo un uso generalizado en, por ejemplo, los modos de" película "de las cámaras digitales fijas, lo que permite la codificación y reproducción de video a través del hardware de compresión JPEG integrado con solo Una modificación de software. Una vez más, la calidad resultante se reduce notablemente en comparación con la compresión MPEG a una tasa de bits similar, particularmente porque el sonido (cuando se incluye) a menudo era PCM sin comprimir o ADPCM de baja compresión (y baja demanda de procesador) ".
Leí el primero en decir que MJPEG puede ofrecer mejor calidad que MPEG, particularmente cuando hay mucho movimiento. La segunda afirmación parece contradecir eso. ¿Cómo puede decir " De nuevo , la calidad resultante se reduce notablemente ..." cuando no se decía nada en ese sentido antes en el artículo?
—El comentario anterior sin firmar fue agregado por SalsaShark42 ( talk • contribs ).
- La primera declaración fue engañosa. Lo cambie. Parecía dar la impresión de que MJPEG proporcionaba mejor calidad que MPEG cuando hay mucho movimiento, pero esa es una impresión incorrecta. El grado de superioridad de compresión de la tecnología MPEG más antigua (MPEG-1, por ejemplo) sobre JPEG fue principalmente el resultado de la predicción entre cuadros. Si no usa la predicción entre cuadros, obtiene aproximadamente la misma capacidad de compresión que JPEG. No peor. Simplemente no mejor. En cierto modo, es como decir que si no comprime las imágenes de video en absoluto y simplemente usa PCM en su lugar, obtiene la ventaja de que la calidad no varía en función del contenido de frecuencia espacial de la imagen. Quizás la compresión no varía, pero tampoco es muy buena. O tal vez es como decir que si mete su dinero debajo del colchón en lugar de en una cuenta de ahorros, entonces tiene la ventaja de que su tasa de retorno (del cero por ciento) es independiente de las fluctuaciones de la tasa de interés del mercado. - Mulligatawny 23:47, 26 de septiembre de 2006 (UTC)
- Más allá de estos comentarios sobre la sección de Críticas ... ¿tal vez deba contrarrestarse con una sección de "ventajas" (aunque soy reacio a tratar de pintar este formato como objetivamente "bueno")? Por ejemplo, solo requiere hardware de codificación / decodificación relativamente simple y energía de procesamiento / batería, es simple extraer cuadros individuales como imágenes fijas (de calidad cuestionable pero consistente), permite una edición con precisión de cuadros sin volver a codificar (solo asegúrese de tienen una alta tasa de datos originales para obtener buenos resultados), etc. Las críticas allí son válidas, pero en este momento es más bien unilateral. 77.102.101.220 ( conversación ) 22:37, 6 de noviembre de 2009 (UTC)
¿Alguien puede decirme la mejor manera de guardar archivos de video Motion Jpeg como archivos MP4? Cuando reproduzco estos archivos, se ven bien, pero cuando trato de guardarlos, se rompen y se ven muy suaves. —El comentario anterior sin firmar fue agregado por Photogold ( charla • contribuciones ).
Se afirma que existen múltiples formatos de MJPEG, pero ¿no mencionó dónde encontrar especificaciones para ellos? (no firmado)
"Estas características no deben subestimarse, ya que muchas aplicaciones en el procesamiento de imágenes en tiempo real de alta velocidad de fotogramas requieren una solución estable de código abierto que se pueda implementar fácilmente con un impacto mínimo en la carga del procesador. [Cita requerida]".
No es una cita, sino una pequeña explicación. Los sistemas de edición de video no lineales a menudo necesitan decodificar el video en la CPU en lugar de en la GPU porque la GPU está configurada para mostrar cuadros en lugar de procesarlos. A menudo, también necesitan decodificar 2 secuencias de video simultáneamente para implementar efectos simples como crossfade y wipe. La decodificación de una única transmisión HD puede afectar gravemente a la CPU. Decodificar dos transmisiones de video HD más cualquier procesamiento que se realice en ellas es mucho trabajo para la CPU. Otra consideración para el sistema de edición no lineal de video (NLE) y algunas otras aplicaciones, que este artículo no toma en cuenta es que si un sistema necesita omitir cuadros para mantenerse al día en tiempo real, un sistema que use compresión entre cuadros podría depender de marcos que fueron desechados. En un programa como Cinelerra, los complementos pueden necesitar fotogramas anteriores para cada salida de fotograma y si necesita aún más fotogramas para reconstruir esos fotogramas debido al códec, entonces el número de fotogramas necesarios puede ser muy alto. Incluso si intenta sincronizar los fotogramas no omitidos con los fotogramas completos en la secuencia original, la necesidad de complementos de efectos para los fotogramas anteriores puede frustrar eso. Si tiene un patrón repetido de un fotograma completo seguido de 9 fotogramas incrementales, la visualización de cada dos fotogramas aún requiere decodificar cada fotograma. Mostrar cada quinto fotograma requiere decodificar los primeros 6 fotogramas de cada grupo, por lo que se encontrará decodificando el 60% de los fotogramas en lugar del 20%. Si aplica un complemento que necesita el fotograma anterior para cada fotograma procesado, debe decodificar los 10 fotogramas (100%) incluso al mostrar cada quinto porque necesita decodificar el décimo fotograma para obtener el fotograma anterior para el 11 y decodificar el décimo requiere decodificar los 9 fotogramas anteriores. Por tanto, es una ventaja un formato de codificación en el que cada cuadro se puede decodificar independientemente de los demás. Whitis ( charla ) 04:40, 30 de abril de 2008 (UTC)
Historia
¿Sería apropiada una fecha de primer uso / implementación / distribución? Recuerdo vagamente que QuickTime 2.0 introdujo compatibilidad con la reproducción y la codificación. No tengo fecha para eso, ¿quizás 1991? Aunque en ese momento los discos duros eran tan pequeños que se preguntaba por qué los usaría. Dlamblin ( charla ) 16:08, 18 de marzo de 2010 (UTC)
Solo una nota rapida
La mención de Cambozola en los enlaces de la página a alguna entrada de la wiki de queso en lugar de la wiki del applet de Java real (si hay una) o el sitio web. Lo encontré divertido, pero ... Pensé en mencionarlo. —Comentario anterior sin firmar agregado por 98.225.255.118 ( charla ) 06:12, 28 de mayo de 2009 (UTC)
Video de muestra
No pude encontrar un video de muestra, así que creé uno y lo coloqué en http://jjc.freeshell.org/turning_pages.html Siéntase libre de usarlo si necesita un video de dominio público. Funciona en Apple Quicktime y el tótem de Fedora. No es muy emocionante, solo yo pasando las páginas de un libro de 1922. Jrincayc ( charla ) 03:07, 25 de mayo de 2009 (UTC)
El video de muestra no funciona : comentario anterior sin firmar agregado por 83.244.151.122 ( conversación ) 09:26, 3 de febrero de 2016 (UTC)
Términos de los laicos
En términos simples, la cuantificación es un método para reducir de manera óptima una gran escala numérica (con diferentes ocurrencias de cada número) en una más pequeña, y el dominio de transformación es una representación conveniente de la imagen porque los coeficientes de alta frecuencia, que contribuyen menos a la imagen superior que otros coeficientes, son valores característicamente pequeños con alta compresibilidad.
¿Qué parte de todo esto es en términos profanos? Propongo reescribir o eliminar "En términos sencillos". - Psignoret ( charla ) 01:10, 22 de abril de 2011 (UTC)
No ser un contenedor
A diferencia de, por ejemplo, Motion JPEG 2000 (y los formatos de video comunes) que permiten el transporte de audio, el más antiguo (e incompatible con) Motion JPEG no codifica ningún audio, ya que es simplemente una concatenación de cuadros JPEG fijos. [1] Sin embargo, en un formato de contenedor adecuado, por ejemplo, AVI, se puede proporcionar audio.
Esto es engañoso. Es muy poco común que un formato de video sea también un formato contenedor. De hecho, es norma que empaque AV1 / H.264 / H.265 en un contenedor adecuado como MKV, AVI, TS, MP4, ... Quitaría todo el párrafo de la introducción. No es relevante para MJPEG que MJPEG2000 también defina un contenedor para audio. - 84.112.125.136 ( conversación ) 12:05, 23 de agosto de 2020 (UTC)
- Estoy de acuerdo en que el párrafo es engañoso (la parte "y formatos de video comunes" es simplemente incorrecta, ya que ningún formato de codificación de video común incluye audio como parte de su especificación), además de que utiliza una discusión anónima en Stack Overflow como referencia, que no es una fuente confiable . Así que eliminé el párrafo.— JM ( charla ) 15:36, 23 de agosto de 2020 (UTC)