July 2011 - ffmpeg-devel - lists.ffmpeg.org

[PATCH 1/2] Parse MXF partitions
by Tomas Härdin 02 Sep '11

02 Sep '11

Forked from the thread "[PATCH] MXF index table based seeking" to avoid cluttering the original thread up. Baptiste Coudurier skrev 2011-05-17 05:31: >> typedef struct { >> + MXFPartition **partitions; >> + unsigned partitions_count; > > Any reason you don't use MXFPartition *partitions ? > It avoids malloc for each partition. No reason at all. Reworked. >> [...] >> >> + >> + /* consider both footers to be closed (there is only Footer and CompleteFooter) */ >> + partition->closed = partition->type == Footer || !(uid[14]& 1); > > Do we really need to workaround here ? Not really a workaround, just a statement of fact. There's no such thing as OpenFooter, hence we might as well set closed correctly. >> [...] >> >> + >> + /* only grab OP from the header */ >> + if (partition->type != Header) >> + return 0; > > Why only header ? :) Why not? :) I don't feel strongly about it though. I removed the check and reworked the part below it since I discovered it was lying - it claims the demuxer supports OPAtom. This is something we can hopefully rectify soon though. The attached patch also parses the remaining operational patterns out, so we can detect OP1a up to OP3c and OPAtom. >> [...] >> >> @@ -843,6 +931,16 @@ static int mxf_parse_structural_metadata(MXFContext *mxf) >> >> static const MXFMetadataReadTableEntry mxf_metadata_read_table[] = { >> { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x05,0x01,0x00 }, mxf_read_primer_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x01,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x02,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x03,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x02,0x04,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x03,0x01,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x03,0x02,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x03,0x03,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x03,0x04,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x04,0x02,0x00 }, mxf_read_partition_pack }, >> + { { 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x04,0x04,0x00 }, mxf_read_partition_pack }, > > Do we need to parse non complete partitions ? > Does it happen in the wild ? :/ Open headers and such aren't unheard of. It doesn't hurt parsing them I think. Preferrably we'd start by parsing any metadata we come across (even open partitions), but override the metadata parsed when we come across a complete header. I think that discussion belongs to [PATCH 2/2] though. > Anyway, patch ok, nice work :) > > I'll review the other patch later. Updated patch attached /Tomas

3 4

Improve timecode support
by Clément Bœsch 30 Aug '11

30 Aug '11

Hi, This patchset is meant to add the -timecode option in FFmpeg. Baptiste Coudurier is the original author of this feature[1] and so of most of the code you will find in those patches. Thought, since it is somewhat heavily modified (and might introduce various issues I am responsible for...) I didn't keep the author credit, but added a note on the bottom of each commits where Baptiste was the original author. Baptiste, if you want to get credits on any of those commits, I'd change them immediately. Note that those features might be done in a better way in FFmbc[2], but this patchset is mainly based on the original code made for SmartJog a few years ago. Here are extra details about the patches: [PATCH 1/8] options: handle options with the same name in codecs and -timecode option is added in the mpeg12enc (lavc) and in some formats, so this allows the option to be parsed in both [PATCH 2/8] timecode: introduce timecode and honor it in MPEG-1/2. This creates a new file for timecode dedicated helpers, and use it in the mpeg12enc. [PATCH 3/8] timecode: move dropframe code and doxycomment it. Some refactoring in the helper file… [PATCH 4/8] mxf: move framenum to timecode convert to timecode Same. [PATCH 5/8] mxf: add cli option in mxfenc to replace GOP timecode Basically support -timecode in MXF muxer. [PATCH 6/8] mxf: honor timecode drop flag in mxf muxer if set. The timecode drop flag was ignored until this commit. [PATCH 7/8] dv: honor timecode in DV muxer. Support -timecode cli option in DV muxer. This required a fate update. [PATCH 8/8] mov: read tmcd tag and set timecode drop flag An old "tmcd" patch from Baptiste, unchanged. [1]: The original code is somewhat old, and was internally developed at SmartJog. [2]: http://code.google.com/p/ffmbc/

3 26

Using avfilter to watermark a video stream
by Roger Pau Monné 29 Aug '11

29 Aug '11

Hello, I'm trying to watermark the key frames of a video stream using a DCT transformation, I've developed a watermark and recovermark filters, to add and recover the mark (which I've attached to this email). However I'm not able to recover the mark correctly, and I think it is because a problem in the marking. I mark the videos using the following command: ffmpeg -i original.mpg -vf "[in] watermark=80:1.2|1.3|1.4:111 [out]" -vcodec mpeg2video -sameq -acodec copy marked.mpg Then I recover the mark using this command: ffmpeg -i original.mpg -vf "movie=marked.mpg, setpts=PTS-STARTPTS [wm];[in] setpts=PTS-STARTPTS, [wm] recovermark=3:1.2|1.3|1.4 [out]" -vcodec rawvideo -an -f null /dev/null However frames compared from vsrc_movie are not key_frames, and I don't know how to sincronize them. My guess is that I'm doing something wrong in the insertion of the mark, because if I execute: ffmpeg -i original.mpg -vf "movie=original.mpg, setpts=PTS-STARTPTS [wm];[in] setpts=PTS-STARTPTS, [wm] recovermark=3:1.2|1.3|1.4 [out]" -vcodec rawvideo -an -f null /dev/null or ffmpeg -threads 2 -i marked.mpg -vf "movie=marked.mpg, setpts=PTS-STARTPTS [wm];[in] setpts=PTS-STARTPTS, [wm] recovermark=3:1.2|1.3|1.4 [out]" -vcodec rawvideo -an -f null /dev/null It works perfectly (or course no difference is found). Anyway if someone could give a hint about what I might be doing wrong I would really appreciate it. Thanks, Roger.

2 1

-profile option broken(?)
by Erik Slagter 27 Aug '11

27 Aug '11

Hi, Since the last pull I did (about three weeks ago) the option "-profile high" (and possibly others?) seem to been have broken. I've done some bisecting but I can't really find the offending patch. Before I put any more effort in this, can please anyone try this option? Maybe I've screwed up something, although I've tested with a clean tree. $ ffmpeg -y -probesize 500000000 -threads 16 -i 00033.avi -vsync 0 -async 0 -profile high -preset veryslow -vcodec libx264 -x264opts level=40:aud=1:keyint=100:ref=4:nr=1000:bframes=8:threads=16:vbv-bufsize=31250:vbv-maxrate=25000:nal-hrd=vbr:crf=24 -strict experimental -acodec aac -ac 2 -ar 48000 -ab 192k -f mpegts 00033_tmp.ts [ .. ] Input #0, avi, from '00033.avi': Metadata: encoder : Lavf53.4.0 Duration: 00:00:34.08, start: 0.000000, bitrate: 66871 kb/s Stream #0.0: Video: mjpeg, yuvj420p, 1920x1080 [PAR 1:1 DAR 16:9], 25 tbr, 25 tbn, 25 tbc Stream #0.1: Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s [buffer @ 0xa213a0] w:1920 h:1080 pixfmt:yuvj420p tb:1/1000000 sar:1/1 sws_param: [libx264 @ 0xa20ee0] using SAR=1/1 [libx264 @ 0xa20ee0] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 [libx264 @ 0xa20ee0] profile High, level 4.0 [NULL @ 0xa39700] [Eval @ 0x7fff4b992270] Undefined constant or missing '(' in 'high' [NULL @ 0xa39700] Unable to parse option value "high" [NULL @ 0xa39700] Error setting option profile to value high. Output #0, mpegts, to '00033_tmp.ts': Stream #0.0: Video: libx264, yuvj420p, 1920x1080 [PAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream #0.1: Audio: aac, 48000 Hz, 2 channels, s16, 64 kb/s Stream mapping: Stream #0.0 -> #0.0 Stream #0.1 -> #0.1 Error while opening encoder for output stream #0.1 - maybe incorrect parameters such as bit_rate, rate, width or height Thanks.

6 8

Decode basic data from an AAC stream before muxing into MOV family containers.
by Leo Izen 27 Aug '11

27 Aug '11

When using -acodec copy -f mov* (mov* meaning mov, mp4, ipod, 3gp, 3g2, or mj2), libavformat will copy the AAC stream as is into the container without looking at data such as frame duration. This leads to a mismatch in container data and the AAC data, and any smart decoder/demuxer will take the AAC values and not the container values. Unfortunately, iTunes isn't smart enough and won't be able to play the file, even though QuickTime will. I suggest that libavformat should decode the first small part of the AAC bitstream (just the metadata, not the audio) and use that in the container data, but unfortunately I don't have enough knowledge of how movenc.c works to do this.

2 1

[PATCH] Rename find_program_from_stream to av_find_program_from_stream and make it public
by cus＠passwd.hu 27 Aug '11

27 Aug '11

Hi, The find_program_from_stream is a useful funcion that should not be static. For example, if you want to implement program switching in ffplay, it might come very handy... Regards, Marton

5 4

YUV video to RGB image export color conversion issue
by Peter B. 19 Aug '11

19 Aug '11

Hi, I've found a bug in color conversion from YUV422p to RGB and posted details about it to ffmpeg-devel on March 1st. Baptiste Coudurier wrote a patch, attached it and I've verified that it works. :) Now I've seen that this fix has not been applied to trunk, so I thought I might repost this on ffmpeg-devel. The video as well as the exported images with and without the error can be seen at: http://download.das-werkstatt.com/pb/mthk/examples/color_problem/problem.ht… I've added it to ffmpeg bugtracking in Trac as issue #143: http://ffmpeg.org/trac/ffmpeg/ticket/143 I'm also attaching the Baptiste's patch. Thanks, Pb // ------------ My message from 01.March.2011 ------------------------- Hello, I'm currently developing a test-video (for automatically finding field/frame drops in A/D converters), and I've run into a color-conversion issue with ffmpeg: When extracting images from the video (yuv422p), the color values in the interlaced areas of the video are deviate from their original beyond recognition. I've uploaded the source video [1] and the resulting images on my webserver, so you can more easily see what I mean: http://download.das-werkstatt.com/pb/mthk/examples/color_problem/problem.ht… I've tried to extract the images with 3 different tools: 1) ffmpeg 2) mplayer 3) virtualdub VirtualDub exports the images as I'd expect it, whereas mplayer and ffmpeg don't. :( Here's the ffmpeg call I've used: "ffmpeg -vframes 4 -i 'testvideo_color_rectangles-YUV422P.avi' -pix_fmt rgb24 -f image2 '%03d.bmp'" (It's also strange, that the resulting bitmap isn't RGB24, but BGR24) What am I doing wrong? Thank you very much for any hint/help. Yours, Pb == References: [1] http://download.das-werkstatt.com/pb/mthk/examples/color_problem/testvideo_… _______________________________________________ ffmpeg-user mailing list ffmpeg-user(a)mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

3 9

License violation
by Howard Chu 17 Aug '11

17 Aug '11

http://www.tubedigger.com/index.html Their package includes an ffmpeg.exe violino:~/.wine/drive_c/Program Files/TubeDigger> wine ffmpeg.exe FFmpeg version SVN-r26400, Copyright (c) 2000-2011 the FFmpeg developers built on Jan 18 2011 04:07:05 with gcc 4.4.2 configuration: --enable-gpl --enable-version3 --enable-libgsm --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libmp3lame --enable-libopenjpeg --enable-libschroedinger --enable-libopencore_amrwb --enable-libopencore_amrnb --enable-libvpx --disable-decoder=libvpx --arch=x86 --enable-runtime-cpudetect --enable-libxvid --enable-libx264 --enable-librtmp --extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --target-os=mingw32 --enable-avisynth --enable-w32threads --cross-prefix=i686-mingw32- --cc='ccache i686-mingw32-gcc' --enable-memalign-hack libavutil 50.36. 0 / 50.36. 0 libavcore 0.16. 1 / 0.16. 1 libavcodec 52.108. 0 / 52.108. 0 libavformat 52.93. 0 / 52.93. 0 libavdevice 52. 2. 3 / 52. 2. 3 libavfilter 1.74. 0 / 1.74. 0 libswscale 0.12. 0 / 0.12. 0 Hyper fast Audio and Video encoder usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}... Use -h to get full help or, even better, run 'man ffmpeg' But no GPL information of any kind. violino:~/.wine/drive_c/Program Files/TubeDigger> ls -l total 33123 -rwxr-xr-x 1 hyc hyc 12433408 2011-01-18 15:07 ffmpeg.exe -rw-r--r-- 1 hyc hyc 2691072 2006-06-12 19:33 Halcyon.msstyles drwxr-xr-x 2 hyc hyc 248 2011-07-31 13:36 images -rw-r--r-- 1 hyc hyc 2752280 2011-03-20 07:23 MediaInfo.dll -rw-r--r-- 1 hyc hyc 2498704 2006-03-06 19:16 Metro.msstyles -rw-r--r-- 1 hyc hyc 3600528 2004-05-24 01:33 ProLCD.msstyles -rw-r--r-- 1 hyc hyc 1540096 2009-04-16 06:33 Rasta.msstyles -rw-r--r-- 1 hyc hyc 9350 2011-06-12 05:44 style.css -rw-r--r-- 1 hyc hyc 1873 2011-06-12 04:46 style.ie6.css -rw-r--r-- 1 hyc hyc 1172 2011-06-12 04:45 style.ie7.css -rw-r--r-- 1 hyc hyc 3285136 2003-12-24 21:09 System.msstyles -rwxr-xr-x 1 hyc hyc 3848704 2011-07-29 03:30 TubeDigger.exe -rw-r--r-- 1 hyc hyc 2196 2011-07-21 03:31 tubedigger.html -rw-r--r-- 1 hyc hyc 6316 2011-07-29 04:21 tutorial.html -rw-r--r-- 1 hyc hyc 9051 2011-07-31 13:36 unins000.dat -rwxr-xr-x 1 hyc hyc 1174997 2011-07-31 13:36 unins000.exe Kinda steams me that leeches like this charge $25/pop for their stupid GUIs, when all the hard work was done by free software developers. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

6 12

[PATCH 1/2] Only add frame_delay to video_clock after the picture was actually queued
by Marton Balint 15 Aug '11

15 Aug '11

Video_refresh expects video_clock to contain the pts of the next frame which is not yet in the queue. --- ffplay.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ffplay.c b/ffplay.c index 8e0ee4d..8286709 100644 --- a/ffplay.c +++ b/ffplay.c @@ -1317,7 +1317,6 @@ static int queue_picture(VideoState *is, AVFrame *src_frame, double pts1, int64_ /* for MPEG2, the frame can be repeated, so we update the clock accordingly */ frame_delay += src_frame->repeat_pict * (frame_delay * 0.5); - is->video_clock += frame_delay; #if defined(DEBUG_SYNC) && 0 printf("frame_type=%c clock=%0.3f pts=%0.3f\n", @@ -1423,6 +1422,7 @@ static int queue_picture(VideoState *is, AVFrame *src_frame, double pts1, int64_ is->pictq_size++; SDL_UnlockMutex(is->pictq_mutex); } + is->video_clock += frame_delay; return 0; } -- 1.7.3.4

2 9

Re: [FFmpeg-devel] [libav-devel] [PATCH] fifo: add av_fifo_peek2()
by Stefano Sabatini 14 Aug '11

14 Aug '11

On date Monday 2011-07-04 16:42:04 +0200, Diego Biurrun encoded: > On Mon, Jul 04, 2011 at 04:13:31PM +0200, Stefano Sabatini wrote: > > > > Updated with changes: > > > > * extended documentation, clarify the meaning of offs and of the returned > > pointer > > * fix a bug (tested this time) > > * keep unchanged the av_fifo_peek() code for avoiding performance > > regressions > > > > >From 0e9763f0dc6f0ca5de4de3f055a37c566c755cb4 Mon Sep 17 00:00:00 2001 > > From: Stefano Sabatini <stefano.sabatini-lala(a)poste.it> > > Date: Wed, 29 Jun 2011 17:30:23 +0200 > > Subject: [PATCH] fifo: add av_fifo_peek2() > > > > The new function provides a more generic interface than the one of by > > av_fifo_peek() for peeking at a FIFO buffer data. > > s/than the one by// Fixed (at least I hope). > > --- a/libavutil/fifo.h > > +++ b/libavutil/fifo.h > > @@ -113,4 +113,25 @@ static inline uint8_t av_fifo_peek(AVFifoBuffer *f, int offs) > > + > > +/** > > + * Return a pointer to the data offset by offs stored in a FIFO > > + * buffer. The FIFO buffer is not modified. > > Return a pointer to the data stored in a FIFO buffer at a certain offset. > The FIFO buffer is not modified. Changed. > > + * The FIFO buffer is treated like a circular buffer, so the returned > > + * value always points to the allocated buffer area. > > + * > > + * @param pointer to the the FIFO buffer to peek at, must be non-NULL > > f > > This should have generated a new doxygen warning. Fixed. > > + * @param offs an offset in bytes > > + */ > > +static inline uint8_t *av_fifo_peek2(const AVFifoBuffer *f, int offs) > > +{ > > + uint8_t *ptr = f->rptr + offs; > > + if (ptr >= f->end) > > + ptr = f->buffer + (ptr - f->end) % (f->end - f->buffer); > > + else if (ptr < f->buffer) > > + ptr = f->buffer + (f->end - ptr) % (f->end - f->buffer); > > + return ptr; > > alternative: > > uint8_t *ptr = f->rptr + offs; > if (ptr >= f->end) > ptr = ptr - f->end; uhm this requires a cast (ptr - ptr => int) > else if (ptr < f->buffer) > ptr = f->end - ptr; > return f->buffer + ptr % (f->end - f->buffer); I kept the old version here for avoiding ugly casts and avoid obfuscating temporaries. > > > --- a/libavutil/Makefile > > +++ b/libavutil/Makefile > > @@ -77,7 +77,7 @@ OBJS-$(ARCH_ARM) += arm/cpu.o > > > > -TESTPROGS = adler32 aes base64 cpu crc des eval lls md5 pca sha tree > > +TESTPROGS = adler32 aes base64 cpu crc des eval fifo lls md5 pca sha tree > > TESTPROGS-$(HAVE_LZO1X_999_COMPRESS) += lzo > > Nowadays making FATE tests out of these is all the rage. Uh.. fate test added. > > --- a/libavutil/fifo.c > > +++ b/libavutil/fifo.c > > @@ -127,3 +127,35 @@ void av_fifo_drain(AVFifoBuffer *f, int size) > > + > > +#ifdef TEST > > + > > +#undef printf > > + > > +int main(void) > > +{ > > + /* create a fifo buffer */ > > FIFO > > > + /* peek at fifo */ > > FIFO > > > + for (i = -50; i < 50; i++) { > > + int *v = (int *)av_fifo_peek2(fifo, i*sizeof(int *)); > > + printf("%d: %d\n", i, *v); > > This can be done without an ugly cast. Uhm, this fixes a warning here. -- Sir, it's very possible this asteroid is not stable. -- C3P0

2 6