gmane.comp.video.ffmpeg.devel

[PATCH] use macho32 object format in 32-bits arch

Guillaume Poirier — 2008-12-01T17:24:06

Hello folks, The attached patch should fix crashes that some users of libavcodec experienced (MPlayer users if you want me to do some finger-pointing). The problem comes from the fact that the code considers that "-f macho" is the 32-bits flavor, and that "-f macho64" should be used to get the 64-bits flavor. "yasm -f macho" leads to the generation of a 32-bits Mach-O object on a 32-bits machine, and a 64-bit Mach-O object on a 64-bits machine. Attached patch should fix this (I must admit I didn't test it yet), but it's not meant to be applied since it leads to code duplication as I'm not comfortable with yasm. Guillaume _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel< at >mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

buf in avformat/utils.c?

Vadim Lebedev — 2008-12-01T11:21:25

Hello I wonder if the function "set_codec_from_probe_data(AVStream *st, AVProbeData *pd, int score)" should not be modifed to handle ALL known input formats? Btw maybe the AVInputFormat structure should be modified to include prefered_codec_id and codec_type fields? Any opinions? Thanks Vadim

seeking bug in theora codec libavcodec/vp3.c ?

Chris Stones — 2008-11-30T22:06:21

Hello, As you may be aware, ffmpeg is unable to correctly seek Theora video. Attempting to seek (even to frame 0) shows only the moving parts of the first few seconds, with static areas of the scene showing the contents of the frame prior to seeking. After a short while (presumably when a keyframe is hit) the video picture becomes perfect again. Am I correct in thinking these artefacts are occurring because the player has seeked to an intermediate frame, instead of a keyframe ??? The Theora codec is stil using the the old pre 1.0 theora_* api, is nobody activly maintining libabcodev/vp3.c ? I intend to correct this problem, any pointers on where to start ? I notice that the "flush" field of AVCodec is set to NULL, is this likely to be the cause of the seeking artifacts ? Where is seeking implemented, it does not seem to be codec specific.. i assume it is container specific ? Forgive the stupid questions, I'm new to video video encoding / decoding. Thanks. Christopher Stones (chris.stones< at >gmail.com)

[PATCH]NVIDIA VDPAU patch for h264

Carl Eugen Hoyos — 2008-11-30T21:03:39

Hi! Attached is the h.264 part of the VDPAU patch. Tested on GeForce9400. ENABLE* is bad for mplayer-based options: It is also never used for xvmc. Please comment, Carl Eugen Index: configure =================================================================== --- configure(Revision 15958) +++ configure(Arbeitskopie) < at >< at > -969,6 +969,7 < at >< at > h263_encoder_select="aandct" h263p_encoder_select="aandct" h264_decoder_select="golomb" +h264_vdpau_decoder_deps="vdpau" imc_decoder_select="fft mdct" jpegls_decoder_select="golomb" jpegls_encoder_select="golomb" Index: libavcodec/utils.c =================================================================== --- libavcodec/utils.c(Revision 15958) +++ libavcodec/utils.c(Arbeitskopie) < at >< at > -644,6 +644,7 < at >< at > {"context", "context model", OFFSET(context_model), FF_OPT_TYPE_INT, DEFAULT, INT_MIN, INT_MAX, V|E}, {"slice_flags", NULL, OFFSET(slice_flags), FF_OPT_TYPE_INT, DEFAULT, INT_MIN, INT_MAX}, {"xvmc_acceleration", NULL, OFFSET(xvmc_acceleration), FF

[PATCH] RV40 Decoder - 3/3 - RV30/40 enabling patch

Kostya — 2008-11-30T12:29:10

After we find the way to perform rv40_luma_mc33, RV40 decoder can be enabled. RV30 is not as good but we can enable it too or leave disabled until I perfect it. Index: Changelog =================================================================== --- Changelog(revision 15958) +++ Changelog(working copy) < at >< at > -140,6 +140,7 < at >< at > - liba52 wrapper removed - Speex decoding via libspeex - Electronic Arts TGQ decoder +- RV30 and RV40 decoder version 0.4.9-pre1: Index: libavcodec/Makefile =================================================================== --- libavcodec/Makefile(revision 15951) +++ libavcodec/Makefile(working copy) < at >< at > -177,6 +177,8 < at >< at > OBJS-$(CONFIG_RV10_ENCODER) += rv10.o mpegvideo_enc.o motion_est.o ratecontrol.o h263.o mpeg12data.o mpegvideo.o error_resilience.o OBJS-$(CONFIG_RV20_DECODER) += rv10.o h263.o mpeg12data.o mpegvideo.o error_resilience.o OBJS-$(CONFIG_RV20_ENCODER) += rv10.o mpegvideo_enc.o motion_est.o ratecontrol.o h263.o mpeg12data.o mpegvi

How to access to the MPlayer samples archive

Stefano Sabatini — 2008-11-30T12:03:23

Hi all, I need to download some VP6 sample since I lost the mines. Could someone tell me (eventually in private) the necessary steps to access the MPlayer samples archive ? Thanks, regards.

[Patch] Topfield 58XXPVR and 68XXPVR file support

James Marsh — 2008-11-30T03:24:29

Topfield make a variety of personal video recorders that allow for the transfer of recorded programmes via an onboard USB port. The ".rec" files they produce are MPEG2 transport streams with a 3760 byte header containing archive information for the PVR. The attached patch checks for the presence of "TFrc" in the first four bytes of a file and identifies it as an mpeg transport stream if present. It subsequently skips this header when the services are probed. With the patch in place these files are then fully supported by ffmpeg. Cheers, James _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel< at >mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

[PATCH] Improve documentation and error reportingfor the -passoption

Stefano Sabatini — 2008-11-30T00:44:25

Hi, as in subject. Regards.

[PATCH] libavfilter-soc: remove diffs/README

Stefano Sabatini — 2008-11-29T20:20:57

Hi, the file in question is not updated and likely useless, since now the diff is not anymore splitted. Decrease the wonder of the occasional user which by chance reads the file. Regards.

[PATCH] QCELP decoder

Kenan Gillet — 2008-11-29T18:39:58

Hi all, sorry for the delay. I was waiting to resolve the parsing/decoding of the bitrate/packet type issue. Reynaldo and I agreed on IRC to live the parsing/decoding as it is for now. So here is round 13 of the qcelp decoder. - QCELPContext was split so that it can be moved into qcelpdec.c and only keep the unpacked data structure (QCELPFrame) in qcelpdata.h - add doxy comments on QCELPFrame field - simplify decode_gain_and_index for RATE_OCTAVE and IFQ - rename qcelp_bits_per_rate into qcelp_unpacking_bitmaps_lengths - use double in qcelp_lsp.c have a great day Kenan Index: libavcodec/qcelp.h =================================================================== --- libavcodec/qcelp.h(revision 0) +++ libavcodec/qcelp.h(revision 0) < at >< at > -0,0 +1,48 < at >< at > +/* + * QCELP decoder + * Copyright (c) 2007 Reynaldo H. Verdejo Pinochet + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as publish

[PATCH] Fix MLP decoder CRC 2D initialization

Laurent Aimar — 2008-11-29T09:41:24

Hi, This patch initializes the CRC 2D table for the MLP decoder. Without it, the decoder is usable only if the MLP parser is initialized.

[PATCH] Fix compilation on OS/2

Dave Yeo — 2008-11-29T03:41:25

Hi, compilation on OS/2 currently dies here, gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I. -I"/usr/src/FFmpeg" -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -std=c99 -fomit-frame-pointer -march=athlon-tbird -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -O3 -fno-math-errno -fno-signed-zeros -c -o libavformat/udp.o libavformat/udp.c libavformat/udp.c: In function 'udp_read': libavformat/udp.c:459: error: storage size of 'tv' isn't known libavformat/udp.c:459: warning: unused variable 'tv' make: *** [libavformat/udp.o] Error 1 Which is fixed by attached patch Dave _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel< at >mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

[PATCH] H.264 predictive lossless: again

Jason Garrett-Glaser — 2008-11-29T00:04:44

I'm getting rather annoyed at having to tell people to install payware (CoreAVC) or recompile their ffmpeg with an unsupported patch in order to play back output from x264. So, here's the patch again, with a few changes to make it a bit more palatable. In particular, transform_bypass is now counted as a "complex" block in order to eliminate the speed impact of the changes on ordinary decoding of non-lossless material. Patch attached. Another test vector can be found here http://mirror05.x264.nl/Dark/force.php?file=./saextra_predictive_lossless.h264 Dark Shikari _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel< at >mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

[PATCH] use check_lib2 for bzip2 check in configure

Ramiro Polla — 2008-11-28T23:36:50

Hello, bzip2 exports symbols as WINAPI in win32, so it must be checked with check_lib2 instead of check_lib in our configure. Patch attached (and then another commit to align the line above it). Ramiro Polla _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel< at >mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

[RFC] H.264/SQV3 separation: h264data.h

Diego Biurrun — 2008-11-28T16:48:50

Next up on the list is moving the tables in h264data.h to a .c file that can be compiled and shared by the H.264 and SVQ3 decoder. This requires adding an ff_ prefix to the names of the tables, removing the static keyword and then moving h264data.h to h264data.c while replacing the contents of h264data.h with appropriate extern declarations. I have done this in my local tree, but the patch is 174kB big (and terribly boring), so I'm not sending it here. OK to proceed (in several steps)? Will this need to be benchmarked at some point? Diego

patch for correctly tagging mp3 audio track in mpeg4container

Sergei Vavinov — 2008-11-28T15:30:35

Hi, Flash player can play MPEG4 videos with H.264 video track and either MP3 or AAC audio track. For that AAC audio track must be tagged as "mp4a", and MP3 audio track must be tagged as ".mp3" (see [1], [2]). However, ffmpeg always seems to tag MP3s within MPEG4 as "mp4a". The attached patch for libavformat/movenc.c makes ffmpeg tag MP3 audio track in MPEG4 as ".mp3", not "mp4a". [1] http://www.kaourantin.net/2007/08/what-just-happened-to-video-on-web_20.html [2] http://osflash.org/flv

Is it a bug or not done yet?

Vlasov Andrey — 2008-11-27T14:47:44

Ffmpeg behaviour depends on arguments order. I can suggest processing arguments in definite order, taking into account dependencies between them. In some time I'll supply a patch. Here are some examples: When I place -ss after -i, it works much longer. This: ffmpeg -i file.avi -ss 01:10:00 -f mjpeg -vformats 1 result.jpg takes significant time (with any video i tried), when ffmpeg -ss 01:10:00 -i file.avi -f mjpeg -vformats 1 result.jpg works instantly. Variable start_time in the case when -ss follows -i is used in void opt_input_file with value 0, though, should be used with the value provided after -ss. When we change the order of -i and -f, we face the following difficulties: This: ./ffmpeg -i video.avi -f mjpeg -ss 00:00:01 -vframes 1 result.jpg works fine, while $ ./ffmpeg -f mjpeg -i video.avi -ss 00:00:01 -vframes 1 result.jpg FFmpeg version SVN-r15943, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: libavutil 49.12. 0 / 49.12. 0 libavcodec 52. 3. 0 / 52. 3. 0

[PATCH] raw audio read block size align

Maksym Veremeyenko — 2008-11-27T13:05:21

Hi! Originally similar patch was introduced in: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-October/055484.html http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-November/055683.html and recently mentioned on looking for solution on recovering truncated PCM packet. Newer version of patch attached. It fix "6 channel raw audio input" issue, but cause regression test fail for some files. Some notes about *a-g726.wav* regression test DID NOT pass: We perform test transcode by next command: ffmpeg -ab 128k -ac 2 -f s16le -i /usr/local/src/ffmpeg-r15943/tests/asynth1.sw -ab 32k -ac 1 -ar 8000 -acodec g726 -y g726.wav Without patch resulting file has size *24279* bytes. After applying patch it size become *24082* bytes. If we just (without applying patch) modify libavformat/raw.c: [...] -#define RAW_PACKET_SIZE 1024 +#define RAW_PACKET_SIZE 4096 [...] g726.wav will have *24082* bytes length If we just (without applying patch) modify libavformat/raw.c: [...] -#define RAW_PACKET_SIZE 102

[PATCH] RV40 Decoder - 2/3 - MC functions

Kostya — 2008-11-27T07:25:08

$subj I've decided not to taint H.264 chroma MC with the idiocy from RV40, so here are all functions in a single file. /* * RV40 decoder motion compensation functions * Copyright (c) 2008 Konstantin Shishkov * * This file is part of FFmpeg. * * FFmpeg is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * FFmpeg is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with FFmpeg; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ /** * < at >file rv40dsp.c * RV40 decoder motion co

[PATCH] RV40 Decoder - 1/3 - Loop Filter

Kostya — 2008-11-27T07:23:21

$subj Fixed several bugs in chroma loop filtering introduced during refactoring, now it's bitexact again. Index: libavcodec/rv40.c =================================================================== --- libavcodec/rv40.c(revision 15920) +++ libavcodec/rv40.c(working copy) < at >< at > -389,7 +389,251 < at >< at > alpha, beta, beta2, chroma, edge); } +enum RV40BlockPos{ + POS_CUR, + POS_TOP, + POS_LEFT, + POS_BOTTOM, +}; + +#define MASK_CUR 0x0001 +#define MASK_RIGHT 0x0008 +#define MASK_BOTTOM 0x0010 +#define MASK_TOP 0x1000 +#define MASK_Y_TOP_ROW 0x000F +#define MASK_Y_LAST_ROW 0xF000 +#define MASK_Y_LEFT_COL 0x1111 +#define MASK_Y_RIGHT_COL 0x8888 +#define MASK_C_TOP_ROW 0x0003 +#define MASK_C_LAST_ROW 0x000C +#define MASK_C_LEFT_COL 0x0005 +#define MASK_C_RIGHT_COL 0x000A + +static const int neighbour_offs_x[4] = { 0, 0, -1, 0 }; +static const int neighbour_offs_y[4] = { 0, -1, 0, 1 }; + /** + * RV40 loop filtering function +

[PATCH] mingw memalign hack fix

David DeHaven — 2008-11-26T23:28:19

SSE2 code was segfaulting on my MinGW builds, turns out blocks being av_realloc'd were losing their alignment. This patch fixes that. I don't know if other platforms need the memalign hack so I can only test Windows builds. None of the others I build for do (Mac OS X/ Darwin and Linux). It uses the same alignment code as av_malloc (cut-n- paste) so I can't imagine it would break anything. -DrD- Index: libavutil/mem.c =================================================================== --- libavutil/mem.c(revision 15942) +++ libavutil/mem.c(working copy) < at >< at > -102,10 +102,16 < at >< at > return NULL; #ifdef CONFIG_MEMALIGN_HACK - //FIXME this isn't aligned correctly, though it probably isn't needed if(!ptr) return av_malloc(size); diff= ((char*)ptr)[-1]; - return (char*)realloc((char*)ptr - diff, size + diff) + diff; + + // diff is only valid on exit IF the pointer remains the same, so we realign the "new" pointer + ptr = realloc((char*)ptr - diff, size + diff); + if