#10 Hombre, está claro que esa sería la mejor opción de todas. Particularmente, creo que lo que ocurre es que los autores del programa o aplicación en cuestión están más centrados en el programa y sus funciones, que en tener que desarrollar la interfaz gráfica, que además, muchas veces se utiliza para crear un modelo que pueda reportar ingresos al autor, como por ejemplo pasa con PDF toolkit ( www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ ).
Tradicionalmente, ffmpeg ha tenido versiones gráficas, como por ejemplo WinFF ( winff.org/ ) o Avanti ( www.avanti.arrozcru.org/ ). Pero crear una interfaz gráfica, aunque pueda parecer sencillo, también es un trabajo bastante delicado, en el que hay que cuidar la experiencia de usuario, capacidad multiplataforma, entre varios otros temas.
Pero vamos, resumiendo, estoy de acuerdo contigo, sería ideal cubrir todos los flancos. Creo que normalmente se intenta priorizar simplemente para enfocarse en el producto en cuestión.
#5 Simplemente por una razón: son más prácticos y se pueden automatizar. En tu comentario entiendo que lo estás viendo desde el punto de vista de un usuario final, pero piensa por ejemplo, en un servicio como Youtube. Cuando un usuario envía un video (que puede estar en cualquier formato) se puede preprocesar con ffmpeg y hacer tareas concretas (convertir a otros formatos más eficientes, crear varias versiones con diferente resolución, generar miniaturas, etc...). En el caso de crear un programa con interfaz gráfica, sólo sería factible para el usuario final. Por eso, el objetivo siempre suele ser crear una versión de terminal y luego un "front-end" o versión gráfica que use esa versión de terminal. Hoy en día, la mayoría de los programas con interfaz gráfica para convertir videos utilizan ffmpeg "por detrás", de forma transparente al usuario.
En el artículo se comentan algunas cosas básicas (prácticas o muy comunes), pero se pueden hacer cosas mucho más avanzadas. Pero como bien dices, no se puede comparar con Vegas, Premiere u otros, que están orientados a otro público más concreto.
Respecto a lo de reducir o aumentar la calidad, totalmente de acuerdo. Lo modificaré.
#12 Años usando y recomendando Free AVG y NUNCA me ha pasado nada de eso (ni consumo excesivo de recursos, ni fiabilidad escasa ni incompatibilidades con nada), aunque si es verdad que la última versión es bloatware y muy molesta con el paso a versión de pago. Desventajas de ser gratuito.
#17 Te recomiendo informarte un poco sobre WebVTT. Es una propuesta de w3 (borrador) para dotar de subtítulos a elementos multimedia (video, audio...) en un formato no propietario, y poder utilizarlo directamente en una web sin necesidad de plugins o elementos de terceros, directamente en el HTML:
#3 respecto al tema de validar números flotantes, pueden usarse patrones de validación con expresiones regulares con HTML5 (sin necesidad de Javascript): codepen.io/manz/pen/OPogRR
Ese ejemplo rápido, cumple con tu ejemplo (permitiendo enteros o flotantes de máx. 4 decimales). Luego habría que refinar bien la expresión regular si quieres casos más concretos (rangos mínimos y máximos, excluir el cero, etc...).
Por eso digo, hay casos y casos. Yo creo que la de CSS3 no prosperó porque justo cuando se meneó ocurrió el problema de hosting (y se cerró antes de que se pudiera solucionar). Como nadie la volvió a enviar, pues pasó desapercibida. Pero bueno, es mi opinión.
#5 aunque no va directamente en contra de las normas ( meneame.wikispaces.com/Meneatiqueta ), no suelo hacerlo porque muchos lo ven como SPAM (y en cierta parte lo entiendo, hay mucho envío propio indiscriminado).
Creo que todos los que escribimos artículos pensamos que lo que acabamos de publicar es "lo mejor que existe" y que "todo el mundo debería verlo" (a veces con razón, pero muchas veces sin ella). Los autores nos dejamos llevar por el tiempo y esfuerzo que le dedicamos a publicar un artículo (la mayoría de mis artículos suelo tardar varios días en prepararlos) y por ello acabamos siendo poco neutrales al valorarlo: si nos votan negativo la noticia, pensamos que están siendo injustos con nosotros o nuestro trabajo, y si nos votan positivo "se está haciendo justicia". Es muy difícil ser neutral al valorar algo en estas circunstancias.
Pienso que lo ideal es que la comunidad decida si subirlo (o si el artículo es interesante o no). Puede ser bueno y no ser publicado porque no interesa a la comunidad, porque en ese momento hay otros artículos más interesantes y pasa desapercibido o simplemente porque el artículo es una mierda. Pueden incluso ocurrir cosas más estrambóticas, como cuando publiqué la chuleta de CSS3 ( www.emezeta.com/articulos/css3-cheatsheet-chuleta-css ), que pensaba que sería un éxito en Menéame, pero fue enviada justo cuando mi hosting hacía unos cambios urgentes y acabó cerrándose y pasando desapercibida.
PD: Desconozco si @gallir lo tiene contemplado, pero creo que sería interesante la posibilidad de asociar un dominio a un usuario, de modo que repercuta de alguna forma en mi cuenta de usuario y poder ver usuarios de menéame que también son editores, etc... Aunque me imagino que es un tema complejo.
#6 Creo que tienes razón, pero no he encontrado ninguna referencia decente. En Apple tienen este documento (2001) donde indican el formato MOV (QTFF) que utilizaban: developer.apple.com/standards/qtff-2001.pdf
¿Tienes alguna referencia más apropiada sobre el año en el que empezó? Así lo modifico y lo aclaro.
#10 Desde el punto de vista técnico, creo que si es una involución. Se retrocede de un sistema mejorado y más actual a algo anterior con desventajas de mantenimiento. Pero estoy totalmente de acuerdo contigo, puede ser una opción totalmente válida dependiendo de las necesidades del usuario (certero el símil de la terminal).
#7 Está en la lista, Jekyll (por cierto, tiene una versión oscura llamada Hyde ) pertenece a la categoría de generadores estáticos y eso merece otro artículo dedicado sólo a ellos. Hay muchos, y muy buenos.
Tradicionalmente, ffmpeg ha tenido versiones gráficas, como por ejemplo WinFF ( winff.org/ ) o Avanti ( www.avanti.arrozcru.org/ ). Pero crear una interfaz gráfica, aunque pueda parecer sencillo, también es un trabajo bastante delicado, en el que hay que cuidar la experiencia de usuario, capacidad multiplataforma, entre varios otros temas.
Pero vamos, resumiendo, estoy de acuerdo contigo, sería ideal cubrir todos los flancos. Creo que normalmente se intenta priorizar simplemente para enfocarse en el producto en cuestión.