Hi there, I'm facing a low quality encoding and I don't know why... So... I have the original frames on BGR24... I want to compress them to send via RTP... I do the following: void video_encode(unsigned char* frame_rgb, int frame_rgb_size, unsigned char* enc_frame, int buf_size, int &enc_frame_size) { int hr; /* Feed uncompressed_frame with the raw RGB data */ AVPicture uncompressed_frame; uncompressed_frame.data[0] = frame_rgb; uncompressed_frame.data[1] = uncompressed_frame.data[2] = 0x00; uncompressed_frame.linesize[0] = 176*3; uncompressed_frame.linesize[1] = uncompressed_frame.linesize[2] = 0; /* Convert from RGB24 to YUV420P */ hr = img_convert((AVPicture*)yuv420_frame, PIX_FMT_YUV420P, &uncompressed_frame, PIX_FMT_BGR24, 176, 144); /* Encode the YUV420P frame to H.263 */ hr = avcodec_encode_video(enc_context, enc_frame, buf_size, yuv420_frame); if (hr>0) { enc_frame_size = hr; } else { enc_frame_size = -1; } } Any ideas on how can I improve the compression quality? Thanks
Cool_Zer0 wrote:
Hi there,
I'm facing a low quality
Define 'low quality' (or is my guess below right?)
encoding and I don't know why... So...
I have the original frames on BGR24... I want to compress them to send via RTP... I do the following:
void video_encode(unsigned char* frame_rgb, int frame_rgb_size, unsigned char* enc_frame, int buf_size, int &enc_frame_size) { int hr; /* Feed uncompressed_frame with the raw RGB data */ AVPicture uncompressed_frame; uncompressed_frame.data[0] = frame_rgb; uncompressed_frame.data[1] = uncompressed_frame.data[2] = 0x00; uncompressed_frame.linesize[0] = 176*3; uncompressed_frame.linesize[1] = uncompressed_frame.linesize[2] = 0;
/* Convert from RGB24 to YUV420P */ hr = img_convert((AVPicture*)yuv420_frame, PIX_FMT_YUV420P, &uncompressed_frame, PIX_FMT_BGR24, 176, 144);
/* Encode the YUV420P frame to H.263 */ hr = avcodec_encode_video(enc_context, enc_frame, buf_size, yuv420_frame); if (hr>0) { enc_frame_size = hr; } else { enc_frame_size = -1; }
}
Quality depends on what you put in enc_context. If you keep the defaults, that will be 200kbits, which by my seat-of-the-pants-o-meter should be roughly equivalent to a 400kbits MPEG1, ie a little worse than long-play VCR. I have always found it useful to tune codec parameters in a file-to-file encoding using the ffmpeg command line. Cheers, -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Hi there,
I'm facing a low quality
Define 'low quality' (or is my guess below right?)
encoding and I don't know why... So...
I have the original frames on BGR24... I want to compress them to send via RTP... I do the following:
void video_encode(unsigned char* frame_rgb, int frame_rgb_size, unsigned char* enc_frame, int buf_size, int &enc_frame_size) { int hr; /* Feed uncompressed_frame with the raw RGB data */ AVPicture uncompressed_frame; uncompressed_frame.data[0] = frame_rgb; uncompressed_frame.data[1] = uncompressed_frame.data[2] = 0x00; uncompressed_frame.linesize[0] = 176*3; uncompressed_frame.linesize[1] = uncompressed_frame.linesize[2] = 0;
/* Convert from RGB24 to YUV420P */ hr = img_convert((AVPicture*)yuv420_frame, PIX_FMT_YUV420P, &uncompressed_frame, PIX_FMT_BGR24, 176, 144);
/* Encode the YUV420P frame to H.263 */ hr = avcodec_encode_video(enc_context, enc_frame, buf_size, yuv420_frame); if (hr>0) { enc_frame_size = hr; } else { enc_frame_size = -1; }
}
Quality depends on what you put in enc_context. If you keep the defaults, that will be 200kbits, which by my seat-of-the-pants-o-meter should be roughly equivalent to a 400kbits MPEG1, ie a little worse than long-play VCR.
I have always found it useful to tune codec parameters in a file-to-file encoding using the ffmpeg command line.
Hi. I'll take that suggestion :) Tell me something... I have my frames on a BMP format... Can I create a video with the bitmap sequence using ffmpeg? So that I can adjust the quality? Thanks
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Hi there,
I'm facing a low quality [snip]
Quality depends on what you put in enc_context. If you keep the defaults, that will be 200kbits, which by my seat-of-the-pants-o-meter should be roughly equivalent to a 400kbits MPEG1, ie a little worse than long-play VCR.
Please tell if you have indeed this.
I have always found it useful to tune codec parameters in a file-to-file encoding using the ffmpeg command line.
Hi. I'll take that suggestion :)
Tell me something... I have my frames on a BMP format... Can I create a video with the bitmap sequence using ffmpeg? So that I can adjust the quality?
Yes. But this is a different topic, so for the convenience of future readers of the archives, I suggest you start another thread. -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Hi there,
I'm facing a low quality [snip]
Quality depends on what you put in enc_context. If you keep the defaults, that will be 200kbits, which by my seat-of-the-pants-o-meter should be roughly equivalent to a 400kbits MPEG1, ie a little worse than long-play VCR.
Please tell if you have indeed this.
void video_encode_init() { yuv420_frame = avcodec_alloc_frame(); if(yuv420_frame==NULL) { printf("avcodec_alloc_frame() error!\n"); exit(1); } numBytes=avpicture_get_size(PIX_FMT_YUV420P, 176, 144); buffer=new uint8_t[numBytes]; avpicture_fill((AVPicture *)yuv420_frame, buffer, PIX_FMT_YUV420P, 176, 144); enc_codec = avcodec_find_encoder(CODEC_ID_H263); if (!enc_codec) { fprintf(stderr, "encoder not found\n"); exit(1); } enc_context = avcodec_alloc_context(); enc_context->width = 176; enc_context->height = 144; enc_context->pix_fmt = PIX_FMT_YUV420P; enc_context->time_base.num = 1; enc_context->time_base.den = 90000; if (avcodec_open(enc_context, enc_codec) < 0) { fprintf(stderr, "could not open codec\n"); exit(1); } } This is my function that initializes the enc_context... I don't specify the bitrate any where...
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Hi there,
I'm facing a low quality [snip]
Quality depends on what you put in enc_context. If you keep the defaults, that will be 200kbits, which by my seat-of-the-pants-o-meter should be roughly equivalent to a 400kbits MPEG1, ie a little worse than long-play VCR.
Please tell if you have indeed this.
What I asked for was whether my guess at what you call low-quality, is right.
void video_encode_init() {
yuv420_frame = avcodec_alloc_frame();
if(yuv420_frame==NULL) { printf("avcodec_alloc_frame() error!\n"); exit(1); }
numBytes=avpicture_get_size(PIX_FMT_YUV420P, 176, 144); buffer=new uint8_t[numBytes]; avpicture_fill((AVPicture *)yuv420_frame, buffer, PIX_FMT_YUV420P, 176, 144);
enc_codec = avcodec_find_encoder(CODEC_ID_H263); if (!enc_codec) { fprintf(stderr, "encoder not found\n"); exit(1); }
enc_context = avcodec_alloc_context(); enc_context->width = 176; enc_context->height = 144; enc_context->pix_fmt = PIX_FMT_YUV420P; enc_context->time_base.num = 1; enc_context->time_base.den = 90000;
if (avcodec_open(enc_context, enc_codec) < 0) { fprintf(stderr, "could not open codec\n"); exit(1); }
}
This is my function that initializes the enc_context... I don't specify the bitrate any where...
avcodec_alloc_context sets it to AV_CODEC_DEFAULT_BITRATE 200*1000. -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Hi there,
I'm facing a low quality [snip]
Quality depends on what you put in enc_context. If you keep the defaults, that will be 200kbits, which by my seat-of-the-pants-o-meter should be roughly equivalent to a 400kbits MPEG1, ie a little worse than long-play VCR.
Please tell if you have indeed this.
What I asked for was whether my guess at what you call low-quality, is right.
Oh.. Sorry.. Well... It's not a low-quality... I can see the image but it's a lot pixelized... I'll give you too samples... This is the original frame on 176x144: http://www.ncenteio.net/original.bmp This is what the other side is receiving. http://www.ncenteio.net/compressed.bmp The image is with other dimensions but that's because the other side client is resizing it... But it's clear that the image (quality) isn't enough... So.. What do you think? In your profissional opinion :) [SNIPPET]
avcodec_alloc_context sets it to AV_CODEC_DEFAULT_BITRATE 200*1000.
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote: > Hi there, > > I'm facing a low quality [snip]
Quality depends on what you put in enc_context. If you keep the defaults, that will be 200kbits, which by my seat-of-the-pants-o-meter should be roughly equivalent to a 400kbits MPEG1, ie a little worse than long-play VCR.
Please tell if you have indeed this.
What I asked for was whether my guess at what you call low-quality, is right.
Oh.. Sorry.. Well... It's not a low-quality... I can see the image but it's a lot pixelized...
I'll give you too samples... This is the original frame on 176x144: http://www.ncenteio.net/original.bmp This is what the other side is receiving. http://www.ncenteio.net/compressed.bmp The image is with other dimensions but that's because the other side client is resizing it... But it's clear that the image (quality) isn't enough...
So.. What do you think? In your profissional opinion :)
Well, its not the same frame, but it seems about right for 200kbits H263.
[SNIPPET]
avcodec_alloc_context sets it to AV_CODEC_DEFAULT_BITRATE 200*1000.
My usual strategy is to rehearse using ffmpeg, then dump the whole codeccontext, then set the parameters in my own code. Cheers, -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Hi! I'm just wondering, now that the PS3 has been released in Europe too, if anybody has started optimising ffmpeg for the Cell? Is gcc's current Cell support any good? I've heard their is a non-free IBM Cell compiler which is much better. Would ffmpeg libs compiled with IBMs compiler still be freely distributable? dan
Dan MacDonald wrote:
Hi!
I'm just wondering, now that the PS3 has been released in Europe too, if anybody has started optimising ffmpeg for the Cell?
Is gcc's current Cell support any good? I've heard their is a non-free IBM Cell compiler which is much better. Would ffmpeg libs compiled with IBMs compiler still be freely distributable?
Please dont hijack threads. At best it reduces your chances to receive a reply. At worst it might get you killfiled. -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote: > Cool_Zer0 wrote: >> Hi there, >> >> I'm facing a low quality [snip] > > Quality depends on what you put in enc_context. If you keep the > defaults, that will be 200kbits, which by my > seat-of-the-pants-o-meter should be roughly equivalent to a > 400kbits MPEG1, ie a little worse than long-play VCR.
Please tell if you have indeed this.
What I asked for was whether my guess at what you call low-quality, is right.
Oh.. Sorry.. Well... It's not a low-quality... I can see the image but it's a lot pixelized...
I'll give you too samples... This is the original frame on 176x144: http://www.ncenteio.net/original.bmp This is what the other side is receiving. http://www.ncenteio.net/compressed.bmp The image is with other dimensions but that's because the other side client is resizing it... But it's clear that the image (quality) isn't enough...
So.. What do you think? In your profissional opinion :)
Well, its not the same frame, but it seems about right for 200kbits H263.
[SNIPPET]
avcodec_alloc_context sets it to AV_CODEC_DEFAULT_BITRATE 200*1000.
My usual strategy is to rehearse using ffmpeg, then dump the whole codeccontext, then set the parameters in my own code.
Oh my god :( The worst happens... When I compress the .bmp's with ffmpeg it looks pretty good... Almost the same... Input #0, image2, from 'bitmap/bmp%d.bmp': Duration: 00:00:14.6, start: 0.000000, bitrate: N/A Stream #0.0: Video: bmp, bgr24, 176x144, 25.00 fps(r) File 'teste.h263' already exists. Overwrite ? [y/N] y Output #0, h263, to 'teste.h263': Stream #0.0: Video: h263, yuv420p, 176x144, q=2-31, 200 kb/s, 25.00 fps(c) So.. I guess that it's something between the compression with ffmpeg and the decompression used by Microsoft RTC H.263 codec... Right? Now I really don't know what to do :(
Cool_Zer0 wrote:
Oh my god :( The worst happens...
When I compress the .bmp's with ffmpeg it looks pretty good... Almost the same... Input #0, image2, from 'bitmap/bmp%d.bmp': Duration: 00:00:14.6, start: 0.000000, bitrate: N/A Stream #0.0: Video: bmp, bgr24, 176x144, 25.00 fps(r) File 'teste.h263' already exists. Overwrite ? [y/N] y Output #0, h263, to 'teste.h263': Stream #0.0: Video: h263, yuv420p, 176x144, q=2-31, 200 kb/s, 25.00 fps(c)
You should always post the command line and the *complete* output messages (unless some line is repeated ad nauseam).
So.. I guess that it's something between the compression with ffmpeg and the decompression used by Microsoft RTC H.263 codec... Right?
You've managed to confuse me completely with vague stuff like "*it* looks pretty good". *IN WHAT PLAYER*? If I understand correctly, when you encode using ffmpeg, the result is OK when decompressed by Microsoft RTC H.263 codec. Try decoding the h263 file using ffmpeg to some high-quality format (like -target dvd) too. If that is Ok too, then clearly the problem is in your code. There must be some value in the codeccontext that is OK when encoding from ffmpeg, but not when called from your code. (I've always found that ffmpeg.c is way too big; that indicates there are vast amounts of things that need to be done by yourself instead of being done by the libraries) -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Oh my god :( The worst happens...
When I compress the .bmp's with ffmpeg it looks pretty good... Almost the same... Input #0, image2, from 'bitmap/bmp%d.bmp': Duration: 00:00:14.6, start: 0.000000, bitrate: N/A Stream #0.0: Video: bmp, bgr24, 176x144, 25.00 fps(r) File 'teste.h263' already exists. Overwrite ? [y/N] y Output #0, h263, to 'teste.h263': Stream #0.0: Video: h263, yuv420p, 176x144, q=2-31, 200 kb/s, 25.00 fps(c)
You should always post the command line and the *complete* output messages (unless some line is repeated ad nauseam).
Here it is: $ ffmpeg -f image2 -i bitmap/bmp%d.bmp teste.h263 FFmpeg version SVN-r8538, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --enable-shared --disable-static --enable-memalign-hack --disable-debug libavutil version: 49.4.0 libavcodec version: 51.40.2 libavformat version: 51.11.0 built on Mar 28 2007 13:59:47, gcc: 3.4.5 (mingw special) Input #0, image2, from 'bitmap/bmp%d.bmp': Duration: 00:00:14.6, start: 0.000000, bitrate: N/A Stream #0.0: Video: bmp, bgr24, 176x144, 25.00 fps(r) File 'teste.h263' already exists. Overwrite ? [y/N] y Output #0, h263, to 'teste.h263': Stream #0.0: Video: h263, yuv420p, 176x144, q=2-31, 200 kb/s, 25.00 fps(c) Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding Compiler did not align stack variables. Libavcodec has been miscompiled and may be very slow or crash. This is not a bug in libavcodec, but in the compiler. Do not report crashes to FFmpeg developers. frame= 365 fps= 0 q=2.6 Lsize= 444kB time=14.6 bitrate= 248.9kbits/s video:444kB audio:0kB global headers:0kB muxing overhead 0.000000% I don't post earlier because I don't think it's relevant...
So.. I guess that it's something between the compression with ffmpeg and the decompression used by Microsoft RTC H.263 codec... Right?
You've managed to confuse me completely with vague stuff like "*it* looks pretty good". *IN WHAT PLAYER*?
Sorry. You are confused because I don't explain the context of my application when I need to decompress. Here is the situation: I have a VoIP client that is using Microsoft RTC to send me H.263 video frames in real-time. My application is receiving that frames and the decompress them. I can successfuly decompress the frames received by the VoIP application. Now I want to do the reverse... I want to send frames from my application to the other VoIP application that is using Microsoft RTC. In my application I compress the .bmp images and send them in real-time to the VoIP application. The problem is on the quality of the images received on the VoIP application...
There must be some value in the codeccontext that is OK when encoding from ffmpeg, but not when called from your code.
Do you think that there is a way to dump the codec context that is being used by ffmpeg?
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Oh my god :( The worst happens...
When I compress the .bmp's with ffmpeg it looks pretty good... Almost the same... Input #0, image2, from 'bitmap/bmp%d.bmp': Duration: 00:00:14.6, start: 0.000000, bitrate: N/A Stream #0.0: Video: bmp, bgr24, 176x144, 25.00 fps(r) File 'teste.h263' already exists. Overwrite ? [y/N] y Output #0, h263, to 'teste.h263': Stream #0.0: Video: h263, yuv420p, 176x144, q=2-31, 200 kb/s, 25.00 fps(c)
You should always post the command line and the *complete* output messages (unless some line is repeated ad nauseam).
Here it is: $ ffmpeg -f image2 -i bitmap/bmp%d.bmp teste.h263 FFmpeg version SVN-r8538, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --enable-shared --disable-static --enable-memalign-hack --disable-debug libavutil version: 49.4.0 libavcodec version: 51.40.2 libavformat version: 51.11.0 built on Mar 28 2007 13:59:47, gcc: 3.4.5 (mingw special) Input #0, image2, from 'bitmap/bmp%d.bmp': Duration: 00:00:14.6, start: 0.000000, bitrate: N/A Stream #0.0: Video: bmp, bgr24, 176x144, 25.00 fps(r) File 'teste.h263' already exists. Overwrite ? [y/N] y Output #0, h263, to 'teste.h263': Stream #0.0: Video: h263, yuv420p, 176x144, q=2-31, 200 kb/s, 25.00 fps(c) Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding Compiler did not align stack variables. Libavcodec has been miscompiled and may be very slow or crash. This is not a bug in libavcodec, but in the compiler. Do not report crashes to FFmpeg developers. frame= 365 fps= 0 q=2.6 Lsize= 444kB time=14.6 bitrate= 248.9kbits/s video:444kB audio:0kB global headers:0kB muxing overhead 0.000000%
I don't post earlier because I don't think it's relevant...
You never know...
So.. I guess that it's something between the compression with ffmpeg and the decompression used by Microsoft RTC H.263 codec... Right?
You've managed to confuse me completely with vague stuff like "*it* looks pretty good". *IN WHAT PLAYER*?
Sorry. You are confused because I don't explain the context of my application when I need to decompress.
Here is the situation: I have a VoIP client that is using Microsoft RTC to send me H.263 video frames in real-time. My application is receiving that frames and the decompress them. I can successfuly decompress the frames received by the VoIP application.
Now I want to do the reverse... I want to send frames from my application to the other VoIP application that is using Microsoft RTC.
In my application I compress the .bmp images and send them in real-time to the VoIP application.
The problem is on the quality of the images received on the VoIP application...
And you have snipped a suggestion about using ffmpeg to decode the h263 encoded by ffmpeg, and of course not answered it. Try it.
There must be some value in the codeccontext that is OK when encoding from ffmpeg, but not when called from your code.
Do you think that there is a way to dump the codec context that is being used by ffmpeg?
gdb ffmpeg_g break at avcodec_encode_video print the context Not extremely readable, of course. -- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Michel Bardiaux wrote:
Cool_Zer0 wrote:
Oh my god :( The worst happens...
When I compress the .bmp's with ffmpeg it looks pretty good... Almost the same... Input #0, image2, from 'bitmap/bmp%d.bmp': Duration: 00:00:14.6, start: 0.000000, bitrate: N/A Stream #0.0: Video: bmp, bgr24, 176x144, 25.00 fps(r) File 'teste.h263' already exists. Overwrite ? [y/N] y Output #0, h263, to 'teste.h263': Stream #0.0: Video: h263, yuv420p, 176x144, q=2-31, 200 kb/s, 25.00 fps(c)
You should always post the command line and the *complete* output messages (unless some line is repeated ad nauseam).
Here it is: $ ffmpeg -f image2 -i bitmap/bmp%d.bmp teste.h263 FFmpeg version SVN-r8538, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --enable-shared --disable-static --enable-memalign-hack --disable-debug libavutil version: 49.4.0 libavcodec version: 51.40.2 libavformat version: 51.11.0 built on Mar 28 2007 13:59:47, gcc: 3.4.5 (mingw special) Input #0, image2, from 'bitmap/bmp%d.bmp': Duration: 00:00:14.6, start: 0.000000, bitrate: N/A Stream #0.0: Video: bmp, bgr24, 176x144, 25.00 fps(r) File 'teste.h263' already exists. Overwrite ? [y/N] y Output #0, h263, to 'teste.h263': Stream #0.0: Video: h263, yuv420p, 176x144, q=2-31, 200 kb/s, 25.00 fps(c) Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding Compiler did not align stack variables. Libavcodec has been miscompiled and may be very slow or crash. This is not a bug in libavcodec, but in the compiler. Do not report crashes to FFmpeg developers. frame= 365 fps= 0 q=2.6 Lsize= 444kB time=14.6 bitrate= 248.9kbits/s video:444kB audio:0kB global headers:0kB muxing overhead 0.000000%
I don't post earlier because I don't think it's relevant...
You never know...
So.. I guess that it's something between the compression with ffmpeg and the decompression used by Microsoft RTC H.263 codec... Right?
You've managed to confuse me completely with vague stuff like "*it* looks pretty good". *IN WHAT PLAYER*?
Sorry. You are confused because I don't explain the context of my application when I need to decompress.
Here is the situation: I have a VoIP client that is using Microsoft RTC to send me H.263 video frames in real-time. My application is receiving that frames and the decompress them. I can successfuly decompress the frames received by the VoIP application.
Now I want to do the reverse... I want to send frames from my application to the other VoIP application that is using Microsoft RTC.
In my application I compress the .bmp images and send them in real-time to the VoIP application.
The problem is on the quality of the images received on the VoIP application...
And you have snipped a suggestion about using ffmpeg to decode the h263 encoded by ffmpeg, and of course not answered it. Try it.
$ ffmpeg -i teste.h263 -f image2 comp/bmp%d.bmp FFmpeg version SVN-r8538, Copyright (c) 2000-2007 Fabrice Bellard, et al. configuration: --enable-shared --disable-static --enable-memalign-hack --disable-debug libavutil version: 49.4.0 libavcodec version: 51.40.2 libavformat version: 51.11.0 built on Mar 28 2007 13:59:47, gcc: 3.4.5 (mingw special) Seems stream 0 codec frame rate differs from container frame rate: 29.97 (30000/1001) -> 25.00 (25/1) Input #0, h263, from 'teste.h263': Duration: N/A, bitrate: N/A Stream #0.0: Video: h263, yuv420p, 176x144, 25.00 fps(r) Output #0, image2, to 'comp/bmp%d.bmp': Stream #0.0: Video: bmp, bgr24, 176x144, q=2-31, 200 kb/s, 25.00 fps(c) Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding frame= 365 fps= 84 q=0.0 Lsize= 0kB time=14.6 bitrate= 0.0kbits/s video:27120kB audio:0kB global headers:0kB muxing overhead -100.000000% The resulting .bmp's are ok... I guess that it's a problem on my code... I'll try the gdb trick :)
There must be some value in the codeccontext that is OK when encoding from ffmpeg, but not when called from your code.
Do you think that there is a way to dump the codec context that is being used by ffmpeg?
gdb ffmpeg_g break at avcodec_encode_video print the context
Not extremely readable, of course.
Cool_Zer0 wrote:
The resulting .bmp's are ok... I guess that it's a problem on my code...
Now we know the encoding by ffmpeg produces an h632 of good quality when decoded by ffmpeg. But there could indeed be some subtle incompatibility between the ffmpeg h263 and the MS h263 decoder. Can you read the h263 file using WMP? Or Media Player Classic?
I'll try the gdb trick :)
-- Michel Bardiaux R&D Director T +32 [0] 2 790 29 41 F +32 [0] 2 790 29 02 E mailto:mbardiaux at mediaxim.be Mediaxim NV/SA Vorstlaan 191 Boulevard du Souverain Brussel 1160 Bruxelles http://www.mediaxim.com/
Michel Bardiaux wrote:
Cool_Zer0 wrote:
The resulting .bmp's are ok... I guess that it's a problem on my code...
Now we know the encoding by ffmpeg produces an h632 of good quality when decoded by ffmpeg. But there could indeed be some subtle incompatibility between the ffmpeg h263 and the MS h263 decoder. Can you read the h263 file using WMP? Or Media Player Classic?
I'll try the gdb trick :)
I found the problem... With the gdb I saw that the time_base is 1/25... I was using 1/90000... Now is fine... Thanks for the support.
participants (3)
-
allcoms＠googlemail.com -
c00jz3r0＠gmail.com -
mbardiaux＠mediaxim.be