ffmpeg - Override/Set ISFT Metadata?

[Ruler2112]

I am in the process of rewriting a script I wrote long ago to reprocess digital video into a format my TV can reliably play. The first version used several tools to accomplish this - ffmpeg and virtualdub among them. VirtualDub allowed me to set the ISFT metadata in the resulting AVI to be whatever I wanted, so I used this field to flag the output file so I can tell at a glance which have been processed and which have not.

I'm trying to eliminate dependencies from the script. It's a pain setting up half a dozen tools to do what I knew could be accomplished with a couple which did not require installation. ffmpeg can do nearly everything I need to do, but I've run into a problem in that I can't seem to set the ISFT (encoding application) metadata via the command line - it's always set to 'Lavfxx.yy.zzz', even when I use the -metadata ISFT="my script" flag on the command line.

Does anyone know of a way to force ffmpeg to use the encoding application string that I supply rather than it's own internal string? If this is not possible, does anyone know of a command line tool, preferably a standalone exe, that can edit this metadata without re-writing the entire file? Needless to say, it's extremely frustrating to get 97% done with alterations to streamline a script and run into such a silly restriction like this.

[poisondeathray]

It's coded like that. You would have to modify and recompile libavformat it's beyond my level of knowledge but I'm sure a few people know how to do it. For example, ffmbc automatically fills in ffmbc 0.7 (or whatever version is being used)

• "ISFT", "encoder" - note that this is automatically filled in by libavformat

http://wiki.multimedia.cx/index.php?title=FFmpeg_Metadata

Certain modified precompiled ffmpeg builds allow you to change ISFT , but are limited and don't have other ffmpeg functions (so roozhou definitely knows how to modify ffmpeg to be able do it)
http://forum.doom9.org/showthread.php?t=152419

Also, ffmpeg requires you to remux/copy the entire file , no in place editing

Is there a reason why you can't use another metadata key field ?



A standalone GUI capable of this is with in place editing is abcAVI Tag Editor - but unfortunately there is no CLI access that I know of

[Ruler2112]

It's coded like that. You would have to modify and recompile libavformat it's beyond my level of knowledge but I'm sure a few people know how to do it. For example, ffmbc automatically fills in ffmbc 0.7 (or whatever version is being used)
...
Is there a reason why you can't use another metadata key field ?
...
A standalone GUI capable of this is with in place editing is abcAVI Tag Editor - but unfortunately there is no CLI access that I know of

I was afraid that a change/recompile would be the only way to do it. Silly of them to have such a restriction IMO.

In hindsight, using a different metadata field would have been the way to go. However, when I made the first version of the script several years ago, I used VirtualDub (driven by the batch file) to mux the audio/video together and set this field. (I believe it was called 'encoded with' in VirtualDub's scripting language IIRC.) I had no idea that other tools would not allow one to set it. I suppose there's nothing really preventing me from switching and using a different field for the new script, but then I'd have all the videos I've already processed tagged one way and all future videos another, which is far from ideal.

Thanks for the tip about abcAVI Tag Editor. I'm going to check it out and see if maybe I can't figure out what it's doing behind the scenes. (Assuming nobody comes up with a better solution.) There doesn't appear to be source code on the homepage, but I wonder if the author would be willing to share? With the logic already in place, it'd just be a matter of designing & building a command line method of driving it, which should be trivial.

[Ruler2112]

For anyone who runs into this in the future, if you add '-flags bitexact' to the ffmpeg command line, you can set the ISFT/encoder metadata. I've been unable to find a comprehensible explanation of what else this does, but it's had no other effects from my limited testing. (Read it's for testing codecs, but that's about it.)

[Selur]

strange, 'bitexact' should not have anything to do with tagging,...

[Ruler2112]

strange, 'bitexact' should not have anything to do with tagging,...

Do you know what it *does* do??? I've not found anything conclusive, other than it's used for testing codecs.

Don't know why they have it designed like this instead of just allowing you to set the field directly. I'm now able to set the field, though I'm uncomfortable implementing it not knowing what else the flag does.

[Selur]

afaik it's ment to force more precision then normally necessary and no, this is no tuning option!
It disables some rounding stuff that would be lost anyways, let me explain a bit:

In example you multiply two numbers 1500 and 9500 and you are only interested in the first two digits of the result (14250000), so it would be possible to simply ignore the last digit or each number. Even if the numbers were 1509 and 9509 the first two digits of the result (14349081) would not change.
So ignoring them does no harm, but can speed up processing, which is why ffmpeg normally would only use the the first 3 digits.
Problem is, if you need to debug code and you need to check stuff it sometimes helps to take the whole number, so make sure you didn't do a mistake somewhere by 'rounding' in a place where you thought that you could, without harm.
-> So, what bitexact does is disable such normally unneeded (and harmless) rounding and force the algorithms to be more precise. (normally enabling this, is simply dumb since it just slows down the whole thing and does not help)

----

Regarding your opservation that you can only change the ISFT field can be changed if bitexact is enabled: I think this is a bug.
-> since bitexact, during normal usage, only slows down the whole thing without any gain, I would recommend to report the problem to the ffmpeg bug tracker, may be it is not a bug, but there is a real reason why ffmpeg behaves the way it does, but atm. I would say the behavior is a bug and should be reported.

Cu Selur

[Ruler2112]

afaik it's ment to force more precision then normally necessary and no, this is no tuning option!
It disables some rounding stuff that would be lost anyways, let me explain a bit:
...
Regarding your opservation that you can only change the ISFT field can be changed if bitexact is enabled: I think this is a bug.
-> since bitexact, during normal usage, only slows down the whole thing without any gain, I would recommend to report the problem to the ffmpeg bug tracker, may be it is not a bug, but there is a real reason why ffmpeg behaves the way it does, but atm. I would say the behavior is a bug and should be reported.

Thank you for the explanation - makes sense and is easy to understand. Wonder why they don't put that in any of the ffmpeg documentation?

Believe it or not, I actually had a bug mostly filled out about this behavior. Originally wanted to be able to simply set the metadata field without needing the bitexact flag. Changed my mind and decided not to report it. If I report it and they decide it IS a bug and fix it without allowing the metadata field to be set, I'm back to cobbling different tools together to achieve the desired output.

I know - this is a great attitude to have. Allow a potential bug to go unreported so that I can exploit a side-effect of it to bypass an otherwise useless restriction in the software. I've seen too many open source project developers sabotage the projects with changes that adversely affect functionality for little to no benefit of anyone to have faith that I'll be able to do what I want if this loophole is closed.

[Selur]

You could still use the current ffmpeg version, regardless if the bug would get fixed for future versions,...

[Cornucopia]

@Ruler2112, you could:
1. Get "Metadata Touch Pro" which can BATCH insert/append/modify/remove the metadata (hopefully your field is included in their list)
2. Convert your previously done files to use a different field
3. Use a new field on all your newly processed files (which will now MATCH what has just been "touched")

Scott

[Ruler2112]

You could still use the current ffmpeg version, regardless if the bug would get fixed for future versions,...

True, but if they eliminate this functionality and I need a feature or fix in a future version (it's happened), I'll be SOL.

@Ruler2112, you could:
1. Get "Metadata Touch Pro" which can BATCH insert/append/modify/remove the metadata (hopefully your field is included in their list)
2. Convert your previously done files to use a different field
3. Use a new field on all your newly processed files (which will now MATCH what has just been "touched")

I'll keep this in mind should I need to. Really don't relish the thought of touching each of several hundred files though, especially just to work around what I consider to be a rather short-sighted limitation in an otherwise excellent software tool. (I think I'd actually rather keep VirtualDub as a dependency of my script than sift through all my previously processed videos, especially since I'm not willing to spend $80 on it either.) This tiny flaw and the fact that they needlessly change the format of various command line parameters every few months are the only things I have a problem with in ffmpeg; it's an awesome tool otherwise.

[Selur]

This tiny flaw and the fact that they needlessly change the format of various command line parameters every few months are the only things I have a problem with in ffmpeg; it's an awesome tool otherwise.

They normally, stay compatible with the old syntax for a year or more,.. (I still got a bunch of 5 year old ffmpeg scripts which still work without problems with the latest builds,....)