Tag a stable release

[rcombs]

It might be kinda arbitrary, but Homebrew requires this:
https://github.com/Homebrew/homebrew/pull/39660/files#r30091612

[foo86]

I plan to release a ‘stable’ version soon. Just need to fix a few things beforehand.

[rcombs]

Anything in particular blocking a release? I'd like to get this into brew.

[magicgoose]

+1

[ghost]

Not alone. Some distros like to have a stable (tm) tarball at least.

[alucryd]

I don't really want to be that guy but, has there been any progress towards a stable release? I'd like to push dcadec to the Arch Linux repositories so that our ffmpeg can be built against it, but I can't really use a git HEAD for that.

[magicgoose]

I don't really want to be that guy

sometimes that guy is necessary, though

[filler56789]

{{ so that our ffmpeg can be built against it }}

Has the ffmpeg team already corrected this design flaw?

https://trac.ffmpeg.org/ticket/4619

[TimothyGu]

@filler56789 there is no design flaw in FFmpeg. The FFmpeg internal decoder is of course preferred over the external decoder. Try ffmpeg -c:a libdcadec -i blah.mka out.mp4 or building FFmpeg without the internal DCA decoder as heleppkes pointed out in that ticket.

[magicgoose]

I don't know what are you calling internal decoder, but ffmpeg by default decodes only lossy part of a DTS-HD MA stream (and what's worse, there is no warning about that)

[jamrial]

I don't know what are you calling internal decoder, but ffmpeg by default decodes only lossy part of a DTS-HD MA stream (and what's worse, there is no warning about that)

The internal decoder shipped by ffmpeg, called "dca".

If you want to use libdcadec, which is an external dep, you need to make it explicit either by forcing it with a command like the one TimothyGu mentioned, or by recompiling ffmpeg with "dca" disabled and libdcadec enabled.
Then you'll get lossless DTS-MA decoding.

[filler56789]

@ TimothyGu: have YOU tried what you suggest?
And yes, the lack of appropriate documentation in ffmpeg sucks.
Some members of their team suck even more.

[filler56789]

{{ The FFmpeg internal decoder is of course preferred over the external decoder.}}

If the external decoder is superior to the old one, then
there is no point in keeping the old one.

[alucryd]

@filler56789 Au contraire, keeping the internal implementation that's been around for much much longer and has been thoroughly tested, even if it has less features, is not a design flaw. It is a smart and sane decision, especially since dcadec hasn't seen any stable release yet and hasn't been battle-tested by the masses.
Now I'm not saying dcadec is bad, it's working beautifully in almost all cases (why almost? see issue #36), but while at least one (known) issue remains, defaulting to the internal implementation is the way to go.

[filler56789]

I see, there is no point in discussing with the narrow-minds from the hive mind.

P.S.: The ticket below shows how much the FFmpeg project "DOES NOT HAVE" design flaws:

https://trac.ffmpeg.org/ticket/3803

[TimothyGu]

@filler56789:

have YOU tried what you suggest?

Does it not work? If it doesn't, file a bug report.

And yes, the lack of appropriate documentation in ffmpeg sucks.

Which I and others have been trying to improve.

If something sucks, TELL US it sucks. FILE A TICKET saying where it sucks. Don't go around saying "FFmpeg's documentation sucks" without even informing us about the problem. It shows extremely inferior citizenship from your end.

Some members of their team suck even more.

I see, there is no point in discussing with the narrow-minds from the hive mind.

I'll try to ignore these two comments.

[MarcusJohnson91]

@TimothyGu I tried my hand on the FFmpeg DCA decoder as well. DCADec is far superior.

[jamrial]

@filler56789

If the external decoder is superior to the old one, then
there is no point in keeping the old one.

The only reason the old internal decoder is still shipped is because nobody bothered to port libdcadec into an internal ffmpeg component and replace it.
Patches to do so are very welcome, so how about instead of complaining and trolling on this ticket you try to do that?

In the meantime, or if you can't port the decoder yourself, you can always use -c:a libdcadec to force its usage or just compile ffmpeg with the internal decoder disabled. Essentially what everyone else does and have been telling you to try.

[filler56789]

The actual trolls in this topic are the FFmpeg zealots.
They are very good at pretending that they didn't realize I have already opened appropriate tickets @ the FFmpeg bug-tracker.
Their project is terribly mismanaged. If the devs don't want to fix something, they should say it to the users. Instead of pretending that they "don't have the time to", or that the bugs reported "are irrelevant", or that the bug "is too complex to be fixed anytime soon". Also, instead of saying «fix the bugs yourself, and/or compile the binary yourself, and STFU».

[filler56789]

{{The only reason the old internal decoder is still shipped is because nobody bothered to port libdcadec into an internal ffmpeg component and replace it.}}

I see, that's the same reason why ffmpeg has never transformed libx264 into an "internal decoder"...
Your logic is faulty, or non-existent.
I only suggested the removal of the internal dca decoder, because that should be simpler than fixing the (let's say) "probing routines" in FFmpeg and FFplay.
Sorry, kiddos, I am not a programmer, but I am very good at detecting rationalizations (aka lame excuses).

[Nevcairiel]

dcadec is an external component, and you cannot assume that its always present - which means removing the internal decoder would remove features from a build without external components, which is not acceptable.

So unless it does in fact replace the internal decoder and becomes an internal component itself, removing the internal decoder will not happen, since you cannot assume that its present in every single build.

It would be relatively easy to make dcadec the default DTS decoder in ffmpeg when its enabled, but noone seems to care enough to actually send a patch, instead people like to troll each other about it, apparently.

[filler56789]

Thanks for the understandable answer, Nev.
The FFmpeggers really should try to learn something from yourself, from Moritz Bunkus and from the VFR_Maniac, for example.

[ghost]

There was the suggestion to drop the internal decoder, and replace it with the imported source code of libdcadec. (So effectively ffmpeg would fork this code and maintain it in place of the builtin one.) This sounds relatively attractive now that the author of libdcadec is MIA. But I don't know if there's still anyone who would want to do the work, or if the rest of ffmpeg would even agree to this idea.

The FFmpeggers really should try to learn something from yourself,

But he is a FFmpegger.

[Fneufneu]

Thanks for the tag, it makes porter life easier

[alucryd]

Thx a lot, just pushed it to the Arch Linux repos.