PDA

View Full Version : second_chroma_qp_index_offset not supported by libavcodec

schweinsz
19th August 2008, 08:03
second_chroma_qp_index_offset not supported by libavcodec?
I can not find it in libavcodec. Is it important for a H.264 software high profile decoder? I want to write a H.264 software high profile decoder.
clsid
19th August 2008, 13:39
Why do you care if libavcodec supports that or not?

May I remind you that if you base your decoder on libavcodec, you must make your decoder open-source as well!

I think you can find your answer in the H.264 specification...
Dark Shikari
19th August 2008, 15:33
May I remind you that if you base your decoder on libavcodec, you must make your decoder open-source as well!No you don't, the LGPL allows linking from proprietary apps.
schweinsz
20th August 2008, 07:23
I am writing a H.264 high profile decoder in scrath. I want to know if the feature is important. If there is no bitstreams that have different QP for the Cr and Cb, decoder will run faster. I never based my decoder on libavcodec.
Comatose
20th August 2008, 08:26
Well, libavcodec doesn't have it and it's often used to decode those streams, so probably not... but hey, who knows.
clsid
20th August 2008, 13:29
No you don't, the LGPL allows linking from proprietary apps.
I was of course assuming that he would be modifying the source :)
schweinsz
21st August 2008, 07:46
I was of course assuming that he would be modifying the source :)

IMHO, there are many redundant operation in every part of the h264 decoder in libavcodec, if you base your decoder on it, it will run slow. But my decoder will run faster than coreavc probabily.

I only compare the libavcodec and the H.264 standard text to learn the standard because I am not familar with every fact of the H.264 standard. Perphas I public all my code in future.
clsid
21st August 2008, 13:38
Why don't you help to improve libavcodec? That is a lot less work than writing your own decoder.
Ranguvar
22nd August 2008, 02:09
Agreed. libavcodec has a lot of limitations, and you help would be greatly appreciated.
Mr VacBob
23rd August 2008, 00:51
IMHO, there are many redundant operation in every part of the h264 decoder in libavcodec, if you base your decoder on it, it will run slow. But my decoder will run faster than coreavc probabily.

Such as? Ignoring SMP (which is not tightly integrated with a decoder), they're not really different from each other. I'd expect that practically all the difference can be explained by less SIMD in libavcodec, which is not a "redundant operation". People who think they can write a much more savagely optimized version of something have usually forgotten the important details.

(and another case of being overly general - what important limitations does it have?)
Ranguvar
24th August 2008, 22:02
Limitations?

SMP, CUDA, and PAFF, to begin with.
clsid
24th August 2008, 22:27
Soon it will have frame based multi-threading.
All other popular decoders don't have CUDA support either and I don't see a reason why they should either.
PAFF support may be incomplete/buggy, but if you care about that you should report if at the FFmpeg Roundup bugtracker with sample files.
Mr VacBob
24th August 2008, 22:33
The PAFF warning didn't mean much - it actually did support PAFF+spatial direct already, but there were a large number of other bugs that affected interlaced streams in general. A lot of them are fixed now, you can see which ones aren't by checking conformance streams.

Some of those fixes involved turning off filter_mb_fast(), if someone wants to rewrite that to work it would be nice as the working one is slower.