Recherche avancée
Autres articles (41)
-
Participer à sa traduction
10 avril 2011Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
Actuellement MediaSPIP n’est disponible qu’en français et (...) -
Les autorisations surchargées par les plugins
27 avril 2010, parMediaspip core
autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs -
Supporting all media types
13 avril 2011, parUnlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)
Sur d’autres sites (6794)
-
Developing A Shader-Based Video Codec
22 juin 2013, par Multimedia Mike — Outlandish BrainstormsEarly last month, this thing called ORBX.js was in the news. It ostensibly has something to do with streaming video and codec technology, which naturally catches my interest. The hype was kicked off by Mozilla honcho Brendan Eich when he posted an article asserting that HD video decoding could be entirely performed in JavaScript. We’ve seen this kind of thing before using Broadway– an H.264 decoder implemented entirely in JS. But that exposes some very obvious limitations (notably CPU usage).
But this new video codec promises 1080p HD playback directly in JavaScript which is a lofty claim. How could it possibly do this ? I got the impression that performance was achieved using WebGL, an extension which allows JavaScript access to accelerated 3D graphics hardware. Browsing through the conversations surrounding the ORBX.js announcement, I found this confirmation from Eich himself :
You’re right that WebGL does heavy lifting.
As of this writing, ORBX.js remains some kind of private tech demo. If there were a public demo available, it would necessarily be easy to reverse engineer the downloadable JavaScript decoder.
But the announcement was enough to make me wonder how it could be possible to create a video codec which effectively leverages 3D hardware.
Prior Art
In theorizing about this, it continually occurs to me that I can’t possibly be the first person to attempt to do this (or the ORBX.js people, for that matter). In googling on the matter, I found various forums and Q&A posts where people asked if it were possible to, e.g., accelerate JPEG decoding and presentation using 3D hardware, with no answers. I also found a blog post which describes a plan to use 3D hardware to accelerate VP8 video decoding. It was a project done under the banner of Google’s Summer of Code in 2011, though I’m not sure which open source group mentored the effort. The project did not end up producing the shader-based VP8 codec originally chartered but mentions that “The ‘client side’ of the VP8 VDPAU implementation is working and is currently being reviewed by the libvdpau maintainers.” I’m not sure what that means. Perhaps it includes modifications to the public API that supports VP8, but is waiting for the underlying hardware to actually implement VP8 decoding blocks in hardware.What’s So Hard About This ?
Video decoding is a computationally intensive task. GPUs are known to be really awesome at chewing through computationally intensive tasks. So why aren’t GPUs a natural fit for decoding video codecs ?Generally, it boils down to parallelism, or lack of opportunities thereof. GPUs are really good at doing the exact same operations over lots of data at once. The problem is that decoding compressed video usually requires multiple phases that cannot be parallelized, and the individual phases often cannot be parallelized. In strictly mathematical terms, a compressed data stream will need to be decoded by applying a function f(x) over each data element, x0 .. xn. However, the function relies on having applied the function to the previous data element, i.e. :
f(xn) = f(f(xn-1))
What happens when you try to parallelize such an algorithm ? Temporal rifts in the space/time continuum, if you’re in a Star Trek episode. If you’re in the real world, you’ll get incorrect, unusuable data as the parallel computation is seeded with a bunch of invalid data at multiple points (which is illustrated in some of the pictures in the aforementioned blog post about accelerated VP8).
Example : JPEG
Let’s take a very general look at the various stages involved in decoding the ubiquitous JPEG format :
What are the opportunities to parallelize these various phases ?
- Huffman decoding (run length decoding and zig-zag reordering is assumed to be rolled into this phase) : not many opportunities for parallelizing the various Huffman formats out there, including this one. Decoding most Huffman streams is necessarily a sequential operation. I once hypothesized that it would be possible to engineer a codec to achieve some parallelism during the entropy decoding phase, and later found that On2′s VP8 codec employs the scheme. However, such a scheme is unlikely to break down to such a fine level that WebGL would require.
- Reverse DC prediction : JPEG — and many other codecs — doesn’t store full DC coefficients. It stores differences in successive DC coefficients. Reversing this process can’t be parallelized. See the discussion in the previous section.
- Dequantize coefficients : This could be very parallelized. It should be noted that software decoders often don’t dequantize all coefficients. Many coefficients are 0 and it’s a waste of a multiplication operation to dequantize. Thus, this phase is sometimes rolled into the Huffman decoding phase.
- Invert discrete cosine transform : This seems like it could be highly parallelizable. I will be exploring this further in this post.
- Convert YUV -> RGB for final display : This is a well-established use case for 3D acceleration.
Crash Course in 3D Shaders and Humility
So I wanted to see if I could accelerate some parts of JPEG decoding using something called shaders. I made an effort to understand 3D programming and its associated math throughout the 1990s but 3D technology left me behind a very long time ago while I got mixed up in this multimedia stuff. So I plowed through a few books concerning WebGL (thanks to my new Safari Books Online subscription). After I learned enough about WebGL/JS to be dangerous and just enough about shader programming to be absolutely lethal, I set out to try my hand at optimizing IDCT using shaders.Here’s my extremely high level (and probably hopelessly naive) view of the modern GPU shader programming model :
The WebGL program written in JavaScript drives the show. It sends a set of vertices into the WebGL system and each vertex is processed through a vertex shader. Then, each pixel that falls within a set of vertices is sent through a fragment shader to compute the final pixel attributes (R, G, B, and alpha value). Another consideration is textures : This is data that the program uploads to GPU memory which can be accessed programmatically by the shaders).
These shaders (vertex and fragment) are key to the GPU’s programmability. How are they programmed ? Using a special C-like shading language. Thought I : “C-like language ? I know C ! I should be able to master this in short order !” So I charged forward with my assumptions and proceeded to get smacked down repeatedly by the overall programming paradigm. I came to recognize this as a variation of the scientific method : Develop a hypothesis– in my case, a mental model of how the system works ; develop an experiment (short program) to prove or disprove the model ; realize something fundamental that I was overlooking ; formulate new hypothesis and repeat.
First Approach : Vertex Workhorse
My first pitch goes like this :- Upload DCT coefficients to GPU memory in the form of textures
- Program a vertex mesh that encapsulates 16×16 macroblocks
- Distribute the IDCT effort among multiple vertex shaders
- Pass transformed Y, U, and V blocks to fragment shader which will convert the samples to RGB
So the idea is that decoding of 16×16 macroblocks is parallelized. A macroblock embodies 6 blocks :
It would be nice to process one of these 6 blocks in each vertex. But that means drawing a square with 6 vertices. How do you do that ? I eventually realized that drawing a square with 6 vertices is the recommended method for drawing a square on 3D hardware. Using 2 triangles, each with 3 vertices (0, 1, 2 ; 3, 4, 5) :
A vertex shader knows which (x, y) coordinates it has been assigned, so it could figure out which sections of coefficients it needs to access within the textures. But how would a vertex shader know which of the 6 blocks it should process ? Solution : Misappropriate the vertex’s z coordinate. It’s not used for anything else in this case.
So I set all of that up. Then I hit a new roadblock : How to get the reconstructed Y, U, and V samples transported to the fragment shader ? I have found that communicating between shaders is quite difficult. Texture memory ? WebGL doesn’t allow shaders to write back to texture memory ; shaders can only read it. The standard way to communicate data from a vertex shader to a fragment shader is to declare variables as “varying”. Up until this point, I knew about varying variables but there was something I didn’t quite understand about them and it nagged at me : If 3 different executions of a vertex shader set 3 different values to a varying variable, what value is passed to the fragment shader ?
It turns out that the varying variable varies, which means that the GPU passes interpolated values to each fragment shader invocation. This completely destroys this idea.
Second Idea : Vertex Workhorse, Take 2
The revised pitch is to work around the interpolation issue by just having each vertex shader invocation performs all 6 block transforms. That seems like a lot of redundant. However, I figured out that I can draw a square with only 4 vertices by arranging them in an ‘N’ pattern and asking WebGL to draw a TRIANGLE_STRIP instead of TRIANGLES. Now it’s only doing the 4x the extra work, and not 6x. GPUs are supposed to be great at this type of work, so it shouldn’t matter, right ?I wired up an experiment and then ran into a new problem : While I was able to transform a block (or at least pretend to), and load up a varying array (that wouldn’t vary since all vertex shaders wrote the same values) to transmit to the fragment shader, the fragment shader can’t access specific values within the varying block. To clarify, a WebGL shader can use a constant value — or a value that can be evaluated as a constant at compile time — to index into arrays ; a WebGL shader can not compute an index into an array. Per my reading, this is a WebGL security consideration and the limitation may not be present in other OpenGL(-ES) implementations.
Not Giving Up Yet : Choking The Fragment Shader
You might want to be sitting down for this pitch :- Vertex shader only interpolates texture coordinates to transmit to fragment shader
- Fragment shader performs IDCT for a single Y sample, U sample, and V sample
- Fragment shader converts YUV -> RGB
Seems straightforward enough. However, that step concerning IDCT for Y, U, and V entails a gargantuan number of operations. When computing the IDCT for an entire block of samples, it’s possible to leverage a lot of redundancy in the math which equates to far fewer overall operations. If you absolutely have to compute each sample individually, for an 8×8 block, that requires 64 multiplication/accumulation (MAC) operations per sample. For 3 color planes, and including a few extra multiplications involved in the RGB conversion, that tallies up to about 200 MACs per pixel. Then there’s the fact that this approach means a 4x redundant operations on the color planes.
It’s crazy, but I just want to see if it can be done. My approach is to pre-compute a pile of IDCT constants in the JavaScript and transmit them to the fragment shader via uniform variables. For a first order optimization, the IDCT constants are formatted as 4-element vectors. This allows computing 16 dot products rather than 64 individual multiplication/addition operations. Ideally, GPU hardware executes the dot products faster (and there is also the possibility of lining these calculations up as matrices).
I can report that I actually got a sample correctly transformed using this approach. Just one sample, through. Then I ran into some new problems :
Problem #1 : Computing sample #1 vs. sample #0 requires a different table of 64 IDCT constants. Okay, so create a long table of 64 * 64 IDCT constants. However, this suffers from the same problem as seen in the previous approach : I can’t dynamically compute the index into this array. What’s the alternative ? Maintain 64 separate named arrays and implement 64 branches, when branching of any kind is ill-advised in shader programming to begin with ? I started to go down this path until I ran into…
Problem #2 : Shaders can only be so large. 64 * 64 floats (4 bytes each) requires 16 kbytes of data and this well exceeds the amount of shader storage that I can assume is allowed. That brings this path of exploration to a screeching halt.
Further Brainstorming
I suppose I could forgo pre-computing the constants and directly compute the IDCT for each sample which would entail lots more multiplications as well as 128 cosine calculations per sample (384 considering all 3 color planes). I’m a little stuck with the transform idea right now. Maybe there are some other transforms I could try.Another idea would be vector quantization. What little ORBX.js literature is available indicates that there is a method to allow real-time streaming but that it requires GPU assistance to yield enough horsepower to make it feasible. When I think of such severe asymmetry between compression and decompression, my mind drifts towards VQ algorithms. As I come to understand the benefits and limitations of GPU acceleration, I think I can envision a way that something similar to SVQ1, with its copious, hierarchical vector tables stored as textures, could be implemented using shaders.
So far, this all pertains to intra-coded video frames. What about opportunities for inter-coded frames ? The only approach that I can envision here is to use WebGL’s readPixels() function to fetch the rasterized frame out of the GPU, and then upload it again as a new texture which a new frame processing pipeline could reference. Whether this idea is plausible would require some profiling.
Using interframes in such a manner seems to imply that the entire codec would need to operate in RGB space and not YUV.
Conclusions
The people behind ORBX.js have apparently figured out a way to create a shader-based video codec. I have yet to even begin to reason out a plausible approach. However, I’m glad I did this exercise since I have finally broken through my ignorance regarding modern GPU shader programming. It’s nice to have a topic like multimedia that allows me a jumping-off point to explore other areas. -
error : undefined reference to 'av_free_packet(AVPacket*)' when use NDK to compile ffmpeg
23 juin 2015, par wolfzI compiled my cpps to use ffmpeg liberary with ANDROID NDK by my android MK as follow :
LOCAL_PATH := $(call my-dir)
DEFINES += -DTARGET_POSIX \
-DTARGET_LINUX \
-D_LINUX \
-DTARGET_ANDROID \
-D__STDC_CONSTANT_MACROS
include $(CLEAR_VARS)
LOCAL_MODULE := libavcodec
LOCAL_SRC_FILES := lib/lib/libavcodec.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libavfilter
LOCAL_SRC_FILES := lib/lib/libavfilter.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libavformat
LOCAL_SRC_FILES := lib/lib/libavformat.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libavutil
LOCAL_SRC_FILES := lib/lib/libavutil.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libpostproc
LOCAL_SRC_FILES := lib/lib/libpostproc.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libswresample
LOCAL_SRC_FILES := lib/lib/libswresample.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := libswscale
LOCAL_SRC_FILES := lib/lib/libswscale.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE:= player
base := $(LOCAL_PATH)
LOCAL_SRC_FILES += cores/PlayDemux.cpp \
cores/PlayDemuxFFmpeg.cpp \
cores/PlayFactoryDemuxer.cpp
LOCAL_C_INCLUDES += $(LOCAL_PATH) \
$(LOCAL_PATH)/lib \
$(LOCAL_PATH)/lib/include \
$(LOCAL_PATH)/cores/player \
LOCAL_CPPFLAGS += -Wall -fexceptions $(DEFINES)
include $(BUILD_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE:= testmain
LOCAL_SRC_FILES := \
testmain.cpp \
LOCAL_C_INCLUDES += $(LOCAL_PATH) \
$(LOCAL_PATH)/lib
LOCAL_CPPFLAGS += -Wall -fexceptions $(DEFINES)
LOCAL_SHARED_LIBRARIES := libavcodec \
libavformat \
libavfilter \
libavutil \
libpostproc \
libswscale \
libswresample
LOCAL_STATIC_LIBRARIES := player
include $(BUILD_EXECUTABLE)but when i do "ndk-build v=1", After compiling, I got :
Install : libavcodec.so => libs/armeabi-v7a/libavcodec.so
install -p /cygdrive/d/player/obj/local/armeabi-v7a/libavcodec.so /cygdrive/d/player/libs/armeabi-v7a/libavcodec.so
/cygdrive/d/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-strip --strip-unneeded D:/player/libs/armeabi-v7a/libavcodec.so
Install : libavfilter.so => libs/armeabi-v7a/libavfilter.so
install -p /cygdrive/d/player/obj/local/armeabi-v7a/libavfilter.so /cygdrive/d/player/libs/armeabi-v7a/libavfilter.so
/cygdrive/d/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-strip --strip-unneeded D:/player/libs/armeabi-v7a/libavfilter.so
Install : libavformat.so => libs/armeabi-v7a/libavformat.so
install -p /cygdrive/d/player/obj/local/armeabi-v7a/libavformat.so /cygdrive/d/player/libs/armeabi-v7a/libavformat.so
/cygdrive/d/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-strip --strip-unneeded D:/player/libs/armeabi-v7a/libavformat.so
Install : libavutil.so => libs/armeabi-v7a/libavutil.so
install -p /cygdrive/d/player/obj/local/armeabi-v7a/libavutil.so /cygdrive/d/player/libs/armeabi-v7a/libavutil.so
/cygdrive/d/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-strip --strip-unneeded D:/player/libs/armeabi-v7a/libavutil.so
Install : libpostproc.so => libs/armeabi-v7a/libpostproc.so
install -p /cygdrive/d/player/obj/local/armeabi-v7a/libpostproc.so /cygdrive/d/player/libs/armeabi-v7a/libpostproc.so
/cygdrive/d/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-strip --strip-unneeded D:/player/libs/armeabi-v7a/libpostproc.so
Install : libswresample.so => libs/armeabi-v7a/libswresample.so
install -p /cygdrive/d/player/obj/local/armeabi-v7a/libswresample.so /cygdrive/d/player/libs/armeabi-v7a/libswresample.so
/cygdrive/d/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-strip --strip-unneeded D:/player/libs/armeabi-v7a/libswresample.so
Install : libswscale.so => libs/armeabi-v7a/libswscale.so
install -p /cygdrive/d/player/obj/local/armeabi-v7a/libswscale.so /cygdrive/d/player/libs/armeabi-v7a/libswscale.so
/cygdrive/d/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-strip --strip-unneeded D:/player/libs/armeabi-v7a/libswscale.so
Executable : testmain
/cygdrive/d/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/arm-linux-androideabi-g++ -Wl,--gc-sections -Wl,-z,nocopyreloc --sysroot=D:/android/android-ndk-r8e/platforms/android-14/arch-arm D:/player/obj/local/armeabi-v7a/objs/testmain/testmain.o D:/player/obj/local/armeabi-v7a/libplayer.a D:/android/android-ndk-r8e/sources/cxx-stl/stlport/libs/armeabi-v7a/libstlport_static.a -lgcc D:/player/obj/local/armeabi-v7a/libavcodec.so D:/player/obj/local/armeabi-v7a/libavformat.so D:/player/obj/local/armeabi-v7a/libavfilter.so D:/player/obj/local/armeabi-v7a/libavutil.so D:/player/obj/local/armeabi-v7a/libpostproc.so D:/player/obj/local/armeabi-v7a/libswscale.so D:/player/obj/local/armeabi-v7a/libswresample.so -no-canonical-prefixes -march=armv7-a -Wl,--fix-cortex-a8 -Wl,--no-undefined -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -lc -lm -o D:/player/obj/local/armeabi-v7a/testmain
D:/android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/windows/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../arm-linux-androideabi/bin/ld.exe: D:/player/obj/local/armeabi-v7a/libplayer.a(PlayDemuxFFmpeg.o): in function PlayDemuxFFmpeg::Flush():D:/player/jni/lib/DllAvCodec.h:144: error: undefined reference to 'av_free_packet(AVPacket*)'I´m using windows 7 + cygwin + NDKR8,but the lib "libavcodec.so ,libavfilter.so,libavformat.so,libavutil.so,libpostproc.so,libswresample.so,libswscale.so " of ffmpeg was compiled with standalone mothed of NDK using "ubuntu + NDK8".
and i include the extern "c" code in the head file.so, how to correct the error ?
my DLLavcodec.h is :
#pragma once
#include "DllAvUtil.h"
extern "C" {
#include <libavcodec></libavcodec>avcodec.h>
}
class DllAvCodec : public DllAvCodecInterface
{
public:
static CCriticalSection m_critSection;
virtual ~DllAvCodec() {}
virtual void avcodec_register_all()
{
::avcodec_register_all();
}
virtual void avcodec_flush_buffers(AVCodecContext *avctx) { ::avcodec_flush_buffers(avctx); }
virtual int avcodec_open2(AVCodecContext *avctx, AVCodec *codec, AVDictionary **options)
{
return ::avcodec_open2(avctx, codec, options);
}
virtual int avcodec_open2_dont_call(AVCodecContext *avctx, AVCodec *codec, AVDictionary **options) { *(volatile int *)0x0 = 0; return 0; }
virtual int avcodec_close_dont_call(AVCodecContext *avctx) { *(volatile int *)0x0 = 0; return 0; }
virtual AVCodec *avcodec_find_decoder(enum CodecID id) { return ::avcodec_find_decoder(id); }
virtual AVCodec *avcodec_find_encoder(enum CodecID id) { return ::avcodec_find_encoder(id); }
virtual int avcodec_close(AVCodecContext *avctx)
{
return ::avcodec_close(avctx);
}
virtual AVFrame *avcodec_alloc_frame() { return ::avcodec_alloc_frame(); }
virtual int avpicture_fill(AVPicture *picture, uint8_t *ptr, PixelFormat pix_fmt, int width, int height) { return ::avpicture_fill(picture, ptr, pix_fmt, width, height); }
virtual int avcodec_decode_video2(AVCodecContext *avctx, AVFrame *picture, int *got_picture_ptr, AVPacket *avpkt) { return ::avcodec_decode_video2(avctx, picture, got_picture_ptr, avpkt); }
virtual int avcodec_decode_audio4(AVCodecContext *avctx, AVFrame *frame, int *got_frame_ptr, AVPacket *avpkt) { return ::avcodec_decode_audio4(avctx, frame, got_frame_ptr, avpkt); }
virtual int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub, int *got_sub_ptr, AVPacket *avpkt) { return ::avcodec_decode_subtitle2(avctx, sub, got_sub_ptr, avpkt); }
virtual int avcodec_encode_audio(AVCodecContext *avctx, uint8_t *buf, int buf_size, const short *samples) { return ::avcodec_encode_audio(avctx, buf, buf_size, samples); }
virtual int avcodec_encode_audio2(AVCodecContext *avctx, AVPacket *avpkt, const AVFrame *frame, int *got_packet_ptr) { return ::avcodec_encode_audio2(avctx, avpkt, frame, got_packet_ptr); }
virtual int avpicture_get_size(PixelFormat pix_fmt, int width, int height) { return ::avpicture_get_size(pix_fmt, width, height); }
virtual AVCodecContext *avcodec_alloc_context3(AVCodec *codec) { return ::avcodec_alloc_context3(codec); }
virtual void avcodec_string(char *buf, int buf_size, AVCodecContext *enc, int encode) { ::avcodec_string(buf, buf_size, enc, encode); }
virtual void avcodec_get_context_defaults3(AVCodecContext *s, AVCodec *codec) { ::avcodec_get_context_defaults3(s, codec); }
virtual AVCodecParserContext *av_parser_init(int codec_id) { return ::av_parser_init(codec_id); }
virtual int av_parser_parse2(AVCodecParserContext *s,AVCodecContext *avctx, uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size,
int64_t pts, int64_t dts, int64_t pos)
{
return ::av_parser_parse2(s, avctx, poutbuf, poutbuf_size, buf, buf_size, pts, dts, pos);
}
virtual void av_parser_close(AVCodecParserContext *s) { ::av_parser_close(s); }
virtual AVBitStreamFilterContext *av_bitstream_filter_init(const char *name) { return ::av_bitstream_filter_init(name); }
virtual int av_bitstream_filter_filter(AVBitStreamFilterContext *bsfc,
AVCodecContext *avctx, const char *args,
uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size, int keyframe) { return ::av_bitstream_filter_filter(bsfc, avctx, args, poutbuf, poutbuf_size, buf, buf_size, keyframe); }
virtual void av_bitstream_filter_close(AVBitStreamFilterContext *bsfc) { ::av_bitstream_filter_close(bsfc); }
virtual void avpicture_free(AVPicture *picture) { ::avpicture_free(picture); }
virtual void av_free_packet(AVPacket *pkt) { ::av_free_packet(pkt); }
virtual int avpicture_alloc(AVPicture *picture, PixelFormat pix_fmt, int width, int height) { return ::avpicture_alloc(picture, pix_fmt, width, height); }
virtual int avcodec_default_get_buffer(AVCodecContext *s, AVFrame *pic) { return ::avcodec_default_get_buffer(s, pic); }
virtual void avcodec_default_release_buffer(AVCodecContext *s, AVFrame *pic) { ::avcodec_default_release_buffer(s, pic); }
virtual enum PixelFormat avcodec_default_get_format(struct AVCodecContext *s, const enum PixelFormat *fmt) { return ::avcodec_default_get_format(s, fmt); }
virtual AVCodec *av_codec_next(AVCodec *c) { return ::av_codec_next(c); }
virtual int av_dup_packet(AVPacket *pkt) { return ::av_dup_packet(pkt); }
virtual void av_init_packet(AVPacket *pkt) { return ::av_init_packet(pkt); }
virtual int avcodec_fill_audio_frame(AVFrame *frame, int nb_channels, enum AVSampleFormat sample_fmt, const uint8_t *buf, int buf_size, int align) { return ::avcodec_fill_audio_frame(frame, nb_channels, sample_fmt, buf, buf_size, align); }
virtual void avcodec_free_frame(AVFrame **frame) { return ::avcodec_free_frame(frame); };
}; -
Converting Real Media with ffmpeg
7 août 2013, par Eric ArensonI have a number of old crusty Real Media files I need to convert and was hoping to write a script to batch process them. I'm able to do a Real Media -> AVI conversion with FFMpegX, but when I try to replicate the conversion with ffmpeg, it always errors out with something like :
[avi @ 0x10084fa00] Too large number of skipped frames 117425 > 60000It may have something to do with the funky format of these Real Media files :
Duration: 01:28:23.42, start: 0.000000, bitrate: 448 kb/s
Stream #0:0: Data: none, 32 kb/s
Stream #0:1: Data: none, 192 kb/s
Stream #0:2: Audio: sipr (sipr / 0x72706973), 8000 Hz, mono, flt, 6 kb/s
Stream #0:3: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 13 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:4: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 8 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:5: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 5 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:6: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 27 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:7: Audio: cook (cook / 0x6B6F6F63), 22050 Hz, mono, fltp, 32 kb/s
Stream #0:8: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 192 kb/s, 30 fps, 30 tbr, 1k tbn, 1k tbc
Stream #0:9: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 136 kb/s, 30 fps, 30 tbr, 1k tbn, 1k tbc
Stream #0:10: Audio: sipr (sipr / 0x72706973), 8000 Hz, mono, flt, 6 kb/s
Stream #0:11: Audio: sipr (sipr / 0x72706973), 8000 Hz, mono, flt, 6 kb/s
Stream #0:12: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 13 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:13: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 13 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:14: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 13 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:15: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 5 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbcDoes anyone have any tips on either how to find out what FFMpegX is doing to make the conversion work, or a better way to go about using ffmpeg to do this ?
EDIT
Including the ffmpeg command (thank you to @Mondain for teaching me about the stream mapping !) and output :
Command :
ffmpeg -i cc121307pm.rm -map 0:8 -map 0:7 -c:v libx264 -c:a libfaac -b:a 32k test.aviOutput :
ffmpeg version 1.2.1 Copyright (c) 2000-2013 the FFmpeg developers
built on Aug 7 2013 12:29:30 with gcc 4.2.1 (GCC) (Apple Inc. build 5664)
configuration: --prefix=/usr/local/Cellar/ffmpeg/1.2.1 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --enable-vda --cc=/usr/bin/gcc-4.2 --host-cflags='-Os -w -pipe -march=core2 -msse4.1 -mmacosx-version-min=10.6' --host-ldflags=-L/usr/local/lib --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid
libavutil 52. 18.100 / 52. 18.100
libavcodec 54. 92.100 / 54. 92.100
libavformat 54. 63.104 / 54. 63.104
libavdevice 54. 3.103 / 54. 3.103
libavfilter 3. 42.103 / 3. 42.103
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 2.100 / 52. 2.100
[rm @ 0x10180f200] Unsupported stream type 00000265
[rm @ 0x10180f200] Unsupported stream type 00000652
[rm @ 0x10180f200] max_analyze_duration 5000000 reached at 5004000 microseconds
Input #0, rm, from 'input.rm':
Metadata:
File ID : 41deac0f-94fb-3595-325c-c717943bc532
Content Rating : (PICS-1.1 "http://www.classify.org/safesurf" labels comment "RealProducer Plus 8.5.0.200 Windows" ratings (SS~~000 1))
Modification Date: 12/13/2007 16:26:16
Generated By : RealProducer Plus 8.5.0.200 Windows
Keywords :
Abstract :
Target Audiences: 28K Modem (20 Kbps);56K Modem (34 Kbps);256K DSL/Cable Modem (225 Kbps);
Video Quality : Normal Motion Video
Audio Format : Voice Only
Creation Date : 12/13/2007 14:57:49
ASMRuleBook : #($Bandwidth < 15000),Stream2Bandwidth = 6500, Stream3Bandwidth = 5499;#($Bandwidth >= 15000) && ($Bandwidth < 20000),Stream2Ba
title :
author :
copyright : ?2007
comment :
Duration: 01:28:23.42, start: 0.000000, bitrate: 448 kb/s
Stream #0:0: Data: none, 32 kb/s
Stream #0:1: Data: none, 192 kb/s
Stream #0:2: Audio: sipr (sipr / 0x72706973), 8000 Hz, mono, flt, 6 kb/s
Stream #0:3: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 13 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:4: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 8 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:5: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 5 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:6: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 27 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:7: Audio: cook (cook / 0x6B6F6F63), 22050 Hz, mono, fltp, 32 kb/s
Stream #0:8: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 192 kb/s, 30 fps, 30 tbr, 1k tbn, 1k tbc
Stream #0:9: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 136 kb/s, 30 fps, 30 tbr, 1k tbn, 1k tbc
Stream #0:10: Audio: sipr (sipr / 0x72706973), 8000 Hz, mono, flt, 6 kb/s
Stream #0:11: Audio: sipr (sipr / 0x72706973), 8000 Hz, mono, flt, 6 kb/s
Stream #0:12: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 13 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:13: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 13 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:14: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 13 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
Stream #0:15: Video: rv20 (RV20 / 0x30325652), yuv420p, 320x240, 5 kb/s, 15 fps, 15 tbr, 1k tbn, 1k tbc
[libx264 @ 0x101889c00] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
[libx264 @ 0x101889c00] profile High, level 1.3
Output #0, avi, to 'test.avi':
Metadata:
File ID : 41deac0f-94fb-3595-325c-c717943bc532
Content Rating : (PICS-1.1 "http://www.classify.org/safesurf" labels comment "RealProducer Plus 8.5.0.200 Windows" ratings (SS~~000 1))
Modification Date: 12/13/2007 16:26:16
Generated By : RealProducer Plus 8.5.0.200 Windows
Keywords :
Abstract :
Target Audiences: 28K Modem (20 Kbps);56K Modem (34 Kbps);256K DSL/Cable Modem (225 Kbps);
Video Quality : Normal Motion Video
Audio Format : Voice Only
Creation Date : 12/13/2007 14:57:49
ASMRuleBook : #($Bandwidth < 15000),Stream2Bandwidth = 6500, Stream3Bandwidth = 5499;#($Bandwidth >= 15000) && ($Bandwidth < 20000),Stream2Ba
INAM :
author :
ICOP : ?2007
ICMT :
ISFT : Lavf54.63.104
Stream #0:0: Video: h264 (H264 / 0x34363248), yuv420p, 320x240, q=-1--1, 30 tbn, 30 tbc
Stream #0:1: Audio: aac ([255][0][0][0] / 0x00FF), 22050 Hz, mono, s16, 32 kb/s
Stream mapping:
Stream #0:8 -> #0:0 (rv20 -> libx264)
Stream #0:7 -> #0:1 (cook -> libfaac)
Press [q] to stop, [?] for help
[rm @ 0x10180f200] DATA tag in middle of chunk, file may be broken.
Truncating packet of size 775215378 to 283607526
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 686581284 to 279055389
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 845942319 to 279042877
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 519635011 to 279040757
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 302013449 to 260425302
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 671112232 to 260422550
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 670137329 to 260371048
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 674387680 to 260336787
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 698852899 to 260336757
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 881600768 to 260281240
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 623325768 to 241694111
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 273397034 to 241679920
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 245534365 to 241615319
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 264614026 to 220525004
[rm @ 0x10180f200] Impossibly sized packet
[rm @ 0x10180f200] DATA tag in middle of chunk, file may be broken.
Truncating packet of size 637535515 to 219973842
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 432193588 to 219973831
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 286760544 to 219962162
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 1070610764 to 219737624
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 259875548 to 219371853
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 362059391 to 219371844
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 885179606 to 219371833
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 587434829 to 206214002
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 816942211 to 165623435
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 471624979 to 113266905
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 674059889 to 113266894
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 459361272 to 113253548
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 637535515 to 91792709
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 432193588 to 91792698
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 286760544 to 91781029
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 157876310 to 91505934
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 469953408 to 91505925
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 260215377 to 91486921
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 877425642 to 91335612
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 259887697 to 91322050
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 885071836 to 91245341
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 264614182 to 90930431
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 811350015 to 90930422
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 128974975 to 90713958
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 801151589 to 89195724
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 654645420 to 85989435
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 184860915 to 85989426
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 1072093904 to 85980304
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 907644163 to 85521587
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 187973624 to 52762203
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 315276941 to 52762157
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 947559309 to 23894660
[rm @ 0x10180f200] Impossibly sized packet
Truncating packet of size 183681448 to 2582872
[rm @ 0x10180f200] Impossibly sized packet
input.rm: Input/output error
frame= 0 fps=0.0 q=0.0 Lsize= 10kB time=00:00:00.00 bitrate=N/A
video:0kB audio:0kB subtitle:0 global headers:0kB muxing overhead inf%
Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)
Syndiquer tout le site
