v2.0.2 Only 21 presets "enabled" (Mandriva 2010.1)

[GoogleCodeExporter]

What steps will reproduce the problem?
1.install ffmpeg (version 0.6-0.22960.5plf2010.1) and all dependencies for 
supported audio and video formats.
2.install sinthgunt (version 2.0.2-1mdv2010.1)
3.launch sinthgunt and inspect presets list menu.

What is the expected output? 
All presets in presets.xml which use codecs provided by the installed ffmpeg 
should be enabled (by inspection this should be nearly all supplied presets).

What do you see instead?
All DVD, Image and VCD presets and some audio presets are enabled.
The Debugging presets are correctly displayed.

What version of the product are you using? On what operating system?
Sinthgunt 2.0.2-1mdv2010.1 on Mandriva 2010.1

Please provide any additional information below.
The Sinthgunt logfile lists correctly the supported formats discovered from 
ffmpeg (ffmpeg_getcodecs codecs_raw).
The logfile shows that these formats are correctly identified as being 
supported for encoding/decoding (ffmpeg_getcodecs self.codecs).
The names used in the presets.xml file for the <codecs> entries is a mixed 
bunch of abbreviated library names (eg. libmp3lame), ffmpeg codec names (ffmpeg 
-codecs, eg msmpeg4), ffmpeg format names (ffmpeg -formats, eg image2) and 
common dos style .xxx file suffix names (eg. wav). 

Only ffmpeg format names (ffmpeg -formats) are used in the check for available 
presets (load_conf_file(self)) so it would seem logical to limit the <codecs> 
entries in the presets.xml file to names actually present in the output from 
ffmpeg -formats. 

I have tried altering some presets.xml <codecs> entries so that they are the 
same as ffmpeg format names and this has resulted in the affected presets being 
recognised and enabled in the Sinthgunt Presets menu. Sadly I do not know 
enough about which codecs are valid for which formats to be confident about 
making ALL of the necessary changes to presets.xml.

A better alternative might be to alter the code in ffmpeg_getcodecs(self) to 
parse the output of ffmpeg -codecs instead of -formats for the codecs[] array 
as many many more matches to presets.xml would result and fewer "misses" would 
be left to investigate. 

I think I read somewhere in the ffmpeg documentation, or elsewhere, that some 
formats are capable of supporting more than one codec (avi ?). There appears to 
be also the possibility of confusing codec names with some implementation 
library names. This seems to have happened with ffmpeg's format and codec names 
for a popular compressed audio standard and the library which implements it 
(mp3, mp3 and libmp3lame). The name used in presets.xml is libmp3lame (the 
library name) and this could never match with the format or the codec name 
returned by either ffmpeg -formats or -codecs. 

There appears to be a similar problem with libx264 in several <codecs> entries, 
but I don't know if this corresponds with ANY ffmpeg -formats or ffmpeg -codecs 
entries. As far as I can tell, it might also be necessary for 
ffmpeg_getcodecs(self) to look for text like --enable-libx264 to know that 
libx264 is present. 

If H264 is the codec provided by libx264 (and I think it might be) then perhaps 
I can change all libx264 references in presets.xml to read h264. Fortunately 
the raw h264 format is also supported by ffmpeg so at least the right name will 
be matched in the existing code, even though it is referring to a stream format 
name rather than a codec name.

All in all, I think it might be less confusing to switch to using ffmpeg 
-codecs in matching up with presets.xml <codecs> entries.

Original issue reported on code.google.com by richardj...@utvinternet.com on 17 Jul 2010 at 12:50

[GoogleCodeExporter]

A mystery has been solved. I had been wondering how the "validation" of presets 
in Sinthgunt could ever have worked properly for anyone ... until yesterday 
when I discovered that there has been a change to the way ffmpeg reports 
capabilities.

I don't know when the change first appeared but I do know that a release 
version of ffmpeg (v0.5.0) is provided for Mandriva 2010.0 whereas the version 
for Mandriva 2010.1 has a Subversion release number (SVN-r22960). This dates 
from 15 June this year. The 2010.0 version was built sometime near the end of 
2009.

When I discovered that Sinthgunt on 2010.0 validates many many more presets 
than reported above, I looked more closely at the output from ffmpeg -formats 
and ffmpeg -codecs on that platform; at any rate, I tried to examine the ffmpeg 
-codecs output, but there isn't any. The option does not exist! Then I found 
the codecs listed at the end of the -formats output and that led me to another 
conclusion; the ffmpeg_getcodecs() code must be able to parse both the table 
style used for formats and the slightly different style used for codecs.

To prove the point I altered the function code to use the -codecs option and it 
works, sort of. It isn't a complete answer as there are still some presets 
missing from the OK list which probably shouldn't be greyed out, but maybe they 
were being validated by entries in the -formats list. If that proves to be the 
case then I can probably get by with hacking presets.xml to suit the use of the 
-codecs output for recent versions of ffmpeg.

Original comment by richardj...@utvinternet.com on 20 Jul 2010 at 7:00

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This is a duplicate of Issue 3.
sinthgunt needs to look at both "ffmpeg -formats" and "ffmpeg -codecs" to get a 
full list of capabilities.  Look at Issue 3 for the patch

Original comment by timkb...@tampabay.rr.com on 12 Sep 2010 at 3:32

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

On Sunday 12 September 2010 16:34:31 sinthgunt@googlecode.com wrote:
> Comment #2 on issue 10 by timkb...@tampabay.rr.com: v2.0.2 Only 21
> presets "enabled" (Mandriva 2010.1)
> http://code.google.com/p/sinthgunt/issues/detail?id=10
>
> This is a duplicate of Issue 3.
> sinthgunt needs to look at both "ffmpeg -formats" and "ffmpeg
-codecs" to
> get a full list of capabilities.  Look at Issue 3 for the patch

Thanks for the clarification. I had studied that thread closely as I thought 
it might be similar to my problem, but in the end I decided that my issues 
were different.

I have applied your patch to v2.0.2 from the Mandriva 2010.1 distribution and 
I can confirm that it produces the same results as revision 183 (2010-09-12) 
from svn. 

This is a very big improvement over my last attempts to use v2.0.2 from 
several months ago. Thank you. There are still some inexplicable anomalies 
which I will investigate in detail soon. For example - OGG is greyed out!

My best guess at the moment is that this may be due to the incompatible 
layouts used by ffmpeg for the output tables for the -codecs and -formats 
tables. I suspect that sinthgunt may not be parsing the -codecs table any 
differently from the -formats table but my knowledge of Python is still very 
limited and it will take me some time to work through it all and find out how 
we manage not to detect the OGG encode/decode ability (same problem with Xvid 
too).

Let us hope that the ffmpeg people don't decide to change the capabilities 
reporting functions again:-)

Richard

Original comment by richardj...@utvinternet.com on 15 Sep 2010 at 12:25

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I spent quite a bit of time this evening with a freshly generated 
.sinthgunt.log file to see if I could determine why, for example, the OGG 
preset is still disabled. 
This is with the latest(?) subversion fetch; revision 183 2010-09-12 18:35:46Z 
kare1234.

It brought back memories of what I had discovered when I first reported this 
issue and I have again re-discovered the cause of the problem. The difference 
now is that I am encouraged by your patch, referred to in the issue 3 thread, 
to believe that I have actually understood what the code is doing!

Your patch has done, albeit more elegantly, what I had done in my hack of the 
code referred to in my comment 1 above. As it doesn't directly address the 
issue I raised here it is still only a partial solution.

To take just one example as an illustration, the OGG case:

The output from ffmpeg -formats shows that the OGG container format is 
supported for both multiplexing and demultiplexing (ffmpeg represents this with 
the flags "D" and "E" which probably stand for Decode and Encode, but the mux 
and demux terms are used presumably because they are more accurate when applied 
to AV container/file formats) and this is recorded in ffmpeg_getcodecs 
self.codecs[] as ['ogg', True, True]. 

The output from ffmpeg -codecs shows that the audio codec for the OGG container 
is also supported and this is recorded in the ffmpeg_getcodecs self.codecs[] 
array as;
['vorbis', False, True]. 

At first I thought the 'False' entry was due to my ffmpeg being compiled with 
the flags '--enable-libvorbis --disable-encoder=vorbis'. Then I noticed that I 
have another entry in self.codecs[] like this;
['libvorbis', True, False]

So between these two I clearly have support for both encoding and decoding with 
the vorbis codec.

Next I looked again at the presets.xml file and the code in 
load_conf_file(self) to see why neither of these entries in self.codecs[] is 
being found. The answer seems to be that the preset-enabling code for the menu 
entries is trying to match to the codec's actual name, 'vorbis'. This matches 
the ['vorbis', False, True] entry and thus the code concludes that encoding is 
not possible and the preset is greyed out in the menu.

The problem with the OGG entry, therefore, is that ffmpeg reports vorbis 
encoding and decoding ability in a very strange way indeed. Why on earth should 
it be split into one report for libvorbis (encoding) and one for vorbis 
(decoding)?

My solution is to change my presets.xml file so it is looking for a codec 
called 'libvorbis' which will correctly match to the encoder entry in 
self.codecs[]. I'll have to leave that for tomorrow as it is now well past my 
bedtime.

Original comment by richardj...@utvinternet.com on 15 Sep 2010 at 1:49

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thank you, Richard. The way ffmpeg names the different codecs sure makes life a 
bit harder for us!

Original comment by kare1234 on 29 Sep 2010 at 9:57

• Added labels: ****
• Removed labels: ****