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.