Guide to write a mplayer codec(转)

最近在研究mplayer,读到这篇文章真是喜出望外。感谢本文的原作者和转载的兄弟。感谢MPlayer-dev-eng的开发人员。

http://blog.csdn.net/freasy/archive/2006/12/06/1432095.aspx

 

Introduction
------------
I've developed a number of open source decoders for the MPlayer project, for both audio and video data. As such, I feel I'm qualified to document a few notes about developing new codecs for the codebase. As always, the best way to learn how to incorporate a new codec is to study a bunch of existing code. This document is supplementary material to the code, meant to give some tips, pointers, and a general roadmap.  A note about terminology: "Codec" stands for coder/decoder (or compressor/decompressor, if you prefer). The term refers to a module that can both encode and decode data. However, this document focuses primarily on incorporating decoders. Still, the terms "decoder" and "codec" are often used interchangeably.

 

Necessary Materials
-------------------
So you've decided that you want to implement a new decoder for MPlayer. There are a few things you will need:

- Knowledge of the codec to be implemented: You will need to know the data format of the chunks that MPlayer will pass to you. You will need to know how to take apart the data structures inside. You will need to know the algorithmic operations that need to be performed on the data in order to reconstruct the original media.

- Sample media: Preferably, lots of it. You will need media encoded in your data format and stored in a media file format that MPlayer knows how to parse (these include AVI, ASF, MOV, RM, VIVO, among others). If the encoded data is stored in a media file format that MPlayer doesn't understand, then you will either need to somehow convert the format to a media file format that the program does nderstand, or write your own MPlayer file demuxer that can handle the data. Writing a file demuxer is beyond the scope of this document. 

 Try to obtain media that stresses all possible modes of a decoder. If an audio codec is known to work with both mono and stereo data, search for sample media of both types. If a video codec is known to
work at 7 different bit depths, then, as painful as it may be, do what you can to obtain sample media encoded for each of the 7 bit depths.

- Latest CVS snapshot: It's always useful to develop code for the very latest development version of MPlayer. Be sure to update your local CVS copy often.

- General programming knowledge, working Linux development environment: I would hope that these items would go without saying, but you never know.

 

Typical Development Cycle
-------------------------
1) Set up basic infrastructure
First things first, there's a big song and dance to go through in order to let the MPlayer program know that you have a new codec to incorporate. First, modify your local copy of codecs.conf. It may be system-shared or in your home directory. Add a new entry for your codec. If it's an open source codec, it would be a good idea to place the new entry with the rest of the open source codecs. When you're confident that you have the entry right, be sure to add it to etc/codecs.conf in your workspace. See the
file codecs.conf.txt for a detailed description of the format of this file. Create a new audiocodec or videocodec block with the proper info, FOURCCs/format numbers, output formats, and a unique driver name. Remember the driver name.

Next, create a new source file which contains the main decoding function that MPlayer will call to decode data. Eventually, you may have multiple files which comprise your decoder, but let's start simple here.
For audio codecs, see ad_sample.c skeleton. For video, choose one of the existing vd_*.c files which you think is close to your codec in behaviour.

Next, modify the Makefile so that it will compile your new source file. Also, add your codec to the array in ad.c (for audio) or vd.c (for video).

Next, compile the project and see if you have everything correct so far.

Next, you want to make sure that the encoded data is making it to your decoding function in the first place. This may sound like a trivial exercise, but there are a lot of things that can go wrong (and I've
watched most of them go wrong in my experience). At the beginning of your skeleton decoder function, enter the following code:
  int i;
  for (i = 0; i < 16; i++)
    printf ("%02X ", input[i]);
  printf ("/n");
When you compile and run MPlayer, your decoder function will print the first 16 bytes of each data chunk that it receives. Open the sample media in a hex editor and reconcile what you see on the screen with what you find in the file. If the decoder is printing the first 16 bytes of each block, that's a good sign that you're ready to move on to step2. Otherwise, you need to figure out why the data isn't getting to your decoder. Is your decoder even being invoked? If not, why not?

 

2) Develop the decoder
Go for it. Remember to make it work, first, then make it work fast. Some specific tips:

What output formats should you support in your decoder? Whatever makes sense. YUV output is always preferable over RGB output. Generally, if a codec uses a YUV data as its source data, you will be able to decode a frame of YUV data. If a codec takes RGB data as its input, as many older video codecs do, then there's no point in supporting YUV output; just output as many RGB formats as possible.

The most preferred output format for video data is YV12. This is because MPlayer supports a multitude of hardware devices that can display, scale, and filter this type of data directly. MPlayer also has a bunch of optimized conversion functions that can convert YV12 data to any other type of output data.

If you do take the RGB output route, you should be aware that MPlayer actually orders packed RGB data as BGR. If you're decoding into a BGR24 buffer, the output will look like:
  B G R B G R B G R B ...
If you're decoding into a BGR32 buffer, there will need to be an additional (unused) byte after each BGR triplet:
  B G R - B G R - B G ...

Make liberal use of sanity checks. Start by including the file mp_msg.h at the start of your decoder. Then you can use the mp_msg() function as you would a normal printf() statement. Whenever your decoder notices a strange bit of data or an odd condition, print a message such as:
  mp_msg(MSGT_DECVIDEO, MSGL_WARN, "Odd data encountered: %d/n", data);
Obviously, you should make the message a little more descriptive, for your benefit. MSGL_WARN is a good message level for this type of information. Look in mp_msg.h for all of the error levels. You can
even make MPlayer bail out completely by using MSGL_FATAL, but that should never be necessary at the data decoder level.

What conditions should trigger a warning? Anything, and I mean *anything* out of the ordinary. Many chunks of compressed video data contain headers with data such as width, height, and chunk size. Reconcile these fields with the parameters passed into the decoding function (if you set it up to take those parameters). Such data should match up. If it doesn't, issue a warning and make an executive decision in the code about which data to believe (personally, I always lend more weight to the data that was passed into the decoder function, the data that comes from the container file's header). If there's supposed to be a magic number embedded in, or computed from, the chunk's header, issue a warning if it isn't correct.

Whenever you're about the index into a memory array with an index that could theoretically be out of range, then test that the index is in range, no matter how tedious it seems. Accessing outside of your memory range is, after all, the number 1 cause of segmentation faults. Never trust that all the data passed to you will be correct. If an array index suddenly winds up out of range, it's probably best to issue a warning about it and bail out of the decoder (but not the whole application).

Writing all of these warning statements may seem insipid, but consider that if you don't do it when you start writing your decoder, you'll probably end up doing it later on when your decoder isn't working properly and you need to figure out why (believe me, I know).

 

3) Debug and test the decoder
If you're extremely lucky, the decoder will work the first time. If you're very lucky, it will work after you've reviewed your code a few times and corrected a few obvious programming mistakes. Realistically, you will write the decoder, review it many times and fix many obvious and subtle
programming errors, and still have to go through an elaborate debug process in order to get the decoder to a minimally functional state. Big hint: Ask for all warnings. You know, the -Wall option in
gcc? It's very useful to develop your codec while running in debug mode. In order to compile MPlayer with debug support (which includes -Wall for all gcc operations), use the --enable-debug option when configuring the project. Pay attention to all warnings and make it a goal to get rid of every single one. I'll never forget when the compiler warned me that there was no point in clamping a signed 16-bit variable within a signed 16-bit range (the calculation to be clamped was supposed to be
stored in a signed 32-bit variable and then stored in the signed 16-bit
variable). I sat stunned for a moment, feeling like I had just dodged a
bullet as I knew that would have taken me hours to debug that kind of
mistake.

4) Contribute decoder to codebase
Create a patch with the "diff -u" format and email it to the MPlayer
development team for approval. You will likely need to diff the following
files:
- Makefile
- etc/codecs.conf
- ad.c or vd.c
Of course, you will need to include your newly-created file(s):
vd_<name>.c -OR- ad_<name>.c. If you contribute enough decoders, the
development team may even grant you write privileges to the CVS repository.

5) Wait for bug reports to start rolling in
You may think you're finished when you release the codec and if you're
extremely lucky, you will be right. However, it's more likely that people
will start throwing all kinds of oddball media at your decoder that it
never counted on. Cheer up; take comfort in knowing that people are
testing your code and attempting to use it as a real world
application. Download the problem media that people upload to the MPlayer
FTP site and get back to work, implementing fixed code that addresses the
issues. Contribute more patches and encourage people to hammer on your
decoder even more. This is how you make your decoder rock-solid.

 

1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。 1、资源项目源码均已通过严格测试验证,保证能够正常运行; 2、项目问题、技术讨论,可以给博主私信或留言,博主看到后会第一时间与您进行沟通; 3、本项目比较适合计算机领域相关的毕业设计课题、课程作业等使用,尤其对于人工智能、计算机科学与技术等相关专业,更为适合; 4、下载使用后,可先查看README.md或论文文件(如有),本项目仅用作交流学习参考,请切勿用于商业用途。 5、资源来自互联网采集,如有侵权,私聊博主删除。 6、可私信博主看论文后选择购买源代码。
应用背景为变电站电力巡检,基于YOLO v4算法模型对常见电力巡检目标进行检测,并充分利用Ascend310提供的DVPP等硬件支持能力来完成流媒体的传输、处理等任务,并对系统性能做出一定的优化。.zip深度学习是机器学习的一个子领域,它基于人工神经网络的研究,特别是利用多层次的神经网络来进行学习和模式识别。深度学习模型能够学习数据的高层次特征,这些特征对于图像和语音识别、自然语言处理、医学图像分析等应用至关重要。以下是深度学习的一些关键概念和组成部分: 1. **神经网络(Neural Networks)**:深度学习的基础是人工神经网络,它是由多个层组成的网络结构,包括输入层、隐藏层和输出层。每个层由多个神经元组成,神经元之间通过权重连接。 2. **前馈神经网络(Feedforward Neural Networks)**:这是最常见的神经网络类型,信息从输入层流向隐藏层,最终到达输出层。 3. **卷积神经网络(Convolutional Neural Networks, CNNs)**:这种网络特别适合处理具有网格结构的数据,如图像。它们使用卷积层来提取图像的特征。 4. **循环神经网络(Recurrent Neural Networks, RNNs)**:这种网络能够处理序列数据,如时间序列或自然语言,因为它们具有记忆功能,能够捕捉数据中的时间依赖性。 5. **长短期记忆网络(Long Short-Term Memory, LSTM)**:LSTM 是一种特殊的 RNN,它能够学习长期依赖关系,非常适合复杂的序列预测任务。 6. **生成对抗网络(Generative Adversarial Networks, GANs)**:由两个网络组成,一个生成器和一个判别器,它们相互竞争,生成器生成数据,判别器评估数据的真实性。 7. **深度学习框架**:如 TensorFlow、Keras、PyTorch 等,这些框架提供了构建、训练和部署深度学习模型的工具和库。 8. **激活函数(Activation Functions)**:如 ReLU、Sigmoid、Tanh 等,它们在神经网络中用于添加非线性,使得网络能够学习复杂的函数。 9. **损失函数(Loss Functions)**:用于评估模型的预测与真实值之间的差异,常见的损失函数包括均方误差(MSE)、交叉熵(Cross-Entropy)等。 10. **优化算法(Optimization Algorithms)**:如梯度下降(Gradient Descent)、随机梯度下降(SGD)、Adam 等,用于更新网络权重,以最小化损失函数。 11. **正则化(Regularization)**:技术如 Dropout、L1/L2 正则化等,用于防止模型过拟合。 12. **迁移学习(Transfer Learning)**:利用在一个任务上训练好的模型来提高另一个相关任务的性能。 深度学习在许多领域都取得了显著的成就,但它也面临着一些挑战,如对大量数据的依赖、模型的解释性差、计算资源消耗大等。研究人员正在不断探索新的方法来解决这些问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值