
Before we can publisize NUT, nutmerge need to be complete, or at least compliant by rejecting any unknown codec/format. What exactly is the point of nutmerge? If I use lavf and lavc framers, then it's just get a slightly lightweight ffmpeg and nothing more. The alternative, doing it all from scratch was fun for a bit, but now it's just NIH. So, what should be done with it? - ods15

Oded Shimon wrote:
Before we can publisize NUT, nutmerge need to be complete, or at least compliant by rejecting any unknown codec/format.
What exactly is the point of nutmerge? If I use lavf and lavc framers, then it's just get a slightly lightweight ffmpeg and nothing more. The alternative, doing it all from scratch was fun for a bit, but now it's just NIH. So, what should be done with it?
Reject everything but mpeg4+mp3 and vorbis and leave it as example application. I guess another issue is updating lavf... lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero

On Thu, Aug 17, 2006 at 10:09:46AM +0300, Oded Shimon wrote:
Before we can publisize NUT, nutmerge need to be complete, or at least compliant by rejecting any unknown codec/format.
What exactly is the point of nutmerge? If I use lavf and lavc framers, then it's just get a slightly lightweight ffmpeg and nothing more. The alternative, doing it all from scratch was fun for a bit, but now it's just NIH. So, what should be done with it?
either reject unknown codecs (and optionally add support for a few more common ones), or use libavformat for input and just use the libnut muxer for output. imo it's very useful to have a program that uses libnut for muxing so that multiple independent implementations can be used and tested against one another, but reimplementing every single demuxer/framer isn't very useful. rich

On Thu, Aug 17, 2006 at 11:01:10AM -0400, Rich Felker wrote:
On Thu, Aug 17, 2006 at 10:09:46AM +0300, Oded Shimon wrote:
Before we can publisize NUT, nutmerge need to be complete, or at least compliant by rejecting any unknown codec/format.
What exactly is the point of nutmerge? If I use lavf and lavc framers, then it's just get a slightly lightweight ffmpeg and nothing more. The alternative, doing it all from scratch was fun for a bit, but now it's just NIH. So, what should be done with it?
either reject unknown codecs (and optionally add support for a few more common ones), or use libavformat for input and just use the libnut muxer for output. imo it's very useful to have a program that uses libnut for muxing so that multiple independent implementations can be used and tested against one another, but reimplementing every single demuxer/framer isn't very useful.
You can do this without nutmerge by adding several nut muxers in lavf ... - ods15

On Thu, Aug 17, 2006 at 11:59:50PM +0300, Oded Shimon wrote:
On Thu, Aug 17, 2006 at 11:01:10AM -0400, Rich Felker wrote:
On Thu, Aug 17, 2006 at 10:09:46AM +0300, Oded Shimon wrote:
Before we can publisize NUT, nutmerge need to be complete, or at least compliant by rejecting any unknown codec/format.
What exactly is the point of nutmerge? If I use lavf and lavc framers, then it's just get a slightly lightweight ffmpeg and nothing more. The alternative, doing it all from scratch was fun for a bit, but now it's just NIH. So, what should be done with it?
either reject unknown codecs (and optionally add support for a few more common ones), or use libavformat for input and just use the libnut muxer for output. imo it's very useful to have a program that uses libnut for muxing so that multiple independent implementations can be used and tested against one another, but reimplementing every single demuxer/framer isn't very useful.
You can do this without nutmerge by adding several nut muxers in lavf ...
Yes but this isn't appropriate for lavf.. The last thing we need in there is more cruft, external library options, etc. On the other hand, what about this: make nutmerge support only a few specific codecs for input from avi or other popular containers, but also support nut files as input and support any arbitrary codec when the input file is nut. This way you could use it to remux nut files, add/delete tracks, etc. And unless something is horribly broken, doing avi->nut with ffmpeg followed by nut->nut with nutmerge should give bit-identical results to doing the avi->nut directly with nutmerge, so you can use it for comparisons with the lavf implementation too. Rich
participants (3)
-
Luca Barbato
-
Oded Shimon
-
Rich Felker