August 2010 - ffmpeg-devel - lists.ffmpeg.org

[RFC] unix socket protocol and our proto situation
by lu_zero＠gentoo.org 01 Jan '11

01 Jan '11

Our network protocol layer is pretty much ineffective and can lose quite easily packets. Usually the system buffer would hide the issue with tcp based protocols and udp based might hide well the problem till we call url_read often enough. Losing data over loopback is something we do experience already when we test rtp. Here yesterday stab at the unix sockets, it shows pretty well how much our current proto layer rely on system buffers instead doing its proper buffering itself. Way to use it: ./ffplay -f mpegts unix:///tmp/ff.socket & sleep 2 && ./ffmpeg_g -re -i something -vcodec copy -acodec copy -f mpegts unix://tmp/ff.socket Expect to lose lots of frames. I'm pondering which would be a good solution: - do nothing and expect downstream apps cope with it somehow. - implement a generic fill thread within proto and change the interface so it could use a proper polling system. - something else glaring simpler that I hadn't thought. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero

7 38

[PATCH] fix gray/pal range in libswscale
by baptiste.coudurier＠gmail.com 25 Dec '10

25 Dec '10

Hi gray/16/pal use full range so set jpeg range and disable unscaled gray -> yuv func since it won't convert the range. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org

2 1

[PATCH] Added integer 32 bits support to wavpack
by fenrir＠videolan.org 25 Dec '10

25 Dec '10

The attached patch completes the support for files with INT32INFO chunk with non zero sent_bits. -- fenrir

6 23

[PATCH] H264 MC8 SSSE3 minor speedups
by rsbultje＠gmail.com 24 Dec '10

24 Dec '10

Hi, since everything else failed, and this is one of the highest functions in my profiling tests, I went for simple changes instead, so I can at least tell myself I helped speed it up, in whatever minor way. ;-). H264 MC8 SSSE3 uses a combination of movq+movlhps, which could also be done as a movdqa, which is a few cycles faster. before (mc8, mx==0^my==0 in h264.c around chroma_op() call): 604 dezicycles in w=8, 65535 runs, 1 skips 603 dezicycles in w=8, 131067 runs, 5 skips 606 dezicycles in w=8, 262137 runs, 7 skips 606 dezicycles in w=8, 524275 runs, 13 skips 605 dezicycles in w=8, 1048552 runs, 24 skips after changing constant to aligned and removing movlhps: 574 dezicycles in w=8, 65529 runs, 7 skips 572 dezicycles in w=8, 131062 runs, 10 skips 570 dezicycles in w=8, 262133 runs, 11 skips 570 dezicycles in w=8, 524271 runs, 17 skips 578 dezicycles in w=8, 1048539 runs, 37 skips Then further down, there's a case where it copies a variable which it doesn't actually double-write to, so the copy appears not necessary. Removing it again saves a few cycles. before (mc8, !(mx&7)&&(my&7) in same position in h264.c): 733 dezicycles in w=8, 16383 runs, 1 skips 731 dezicycles in w=8, 32767 runs, 1 skips 729 dezicycles in w=8, 65534 runs, 2 skips 718 dezicycles in w=8, 131068 runs, 4 skips 720 dezicycles in w=8, 262136 runs, 8 skips after removing extraneous movdqa: 687 dezicycles in w=8, 16383 runs, 1 skips 683 dezicycles in w=8, 32766 runs, 2 skips 681 dezicycles in w=8, 65534 runs, 2 skips 679 dezicycles in w=8, 131070 runs, 2 skips 672 dezicycles in w=8, 262138 runs, 6 skips Measured on OSX 10.6.4, i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664), Intel Core i7. Ronald

3 5

[PATCH] Windows Television (.wtv) demuxer
by pross＠xvid.org 20 Dec '10

20 Dec '10

Yet another streaming to disk format. Samples here: samples.mplayerhq.hu/wtv -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

3 12

fix a bug for mmsh because the packet len is too large
by spyfeng＠gmail.com 18 Dec '10

18 Dec '10

hi the patch fix a bug because the link below is failed (reported by Tamas Selmeci) mmsh:// a1635.v24937.c2493.g.vm.akamaistream.net/7/1635/2493/v0001/premrad.download… according to the spec, the largest packet length is 65535. so we change the receive buffer size. zhentan -- Best wishes~

2 7

[PATCH] FLAC parser
by mchinen＠gmail.com 08 Dec '10

08 Dec '10

Hi, On Fri, Aug 13, 2010 at 6:38 PM, Justin Ruggles <justin.ruggles at gmail.com> wrote: > Hi, > > I'm writing this from my work computer, so I don't have a way to reply > directly to the list. ?I'm sending it only to you instead so it > doesn't break the thread. ?Sorry about not being able to quote > properly either... ?Feel free to include the full text in your reply > to the list so others can see it. > > Also, I'm going out-of-town this weekend so I won't be able to reply > again until Monday. > > +static void update_sequences(FLACParseContext *fpc, int start_index, > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? int start_distance, FLACHeaderMarker *end) > +{ > + ? ?int distance ? ? ? ? ?= start_distance - 1; > + ? ?FLACHeaderMarker *mid = fpc->headers; > + > + ? ?while (start_index-- > 0) > + ? ? ? ?mid = mid->next; > + > + ? ?update_sequences_header(fpc, mid, end, distance); > +} > > distance variable not needed. removed. > > + ? ? ? ? ? ?/* The header may have already been found in the last search. This > + ? ? ? ? ? ? ? happens when header size is less than > MAX_FRAME_HEADER_SIZE. ? */ > + ? ? ? ? ? ?if (end_offset >= i) { > + ? ? ? ? ? ? ? ?av_log(fpc->avctx, AV_LOG_DEBUG, > + ? ? ? ? ? ? ? ? ? ? ? "found header a second time, skipping\n"); > + ? ? ? ? ? ? ? ?continue; > + ? ? ? ? ? ?} > > shouldn't this be: > if (end_offset == i) I've convinced myself that this case will not happen so I removed it. Looking at this also lead to finding some bugs that I've fixed and tested: -A case where the parser would do the wrong thing if seeked to a position near the end of the file with less than the minimum number of headers -A missing case where a header lies in the last 16 bytes of the file. -The chains were being set wrong. > > + ? ?} else if (fpc->best_header) { > + ? ? ? ?/* No end frame no need to delete the buffer; probably eof */ > + ? ? ? ?FLACHeaderMarker *curr = fpc->headers, *temp; > + ? ? ? ?while (curr != fpc->best_header) { > + ? ? ? ? ? ?temp = curr->next; > + ? ? ? ? ? ?av_free(curr); > + ? ? ? ? ? ?curr = temp; > + ? ? ? ?} > + ? ? ? ?fpc->headers ? ? = fpc->best_header->next; > + ? ? ? ?av_free(fpc->best_header); > + ? ? ? ?fpc->best_header = NULL; > + ? ?} > > av_freep(&fpc->best_header); > then you don't need to set it to NULL. Done. > > + ? ?if (!fpc->best_header) { > + ? ? ? ?FLACHeaderMarker *curr = fpc->headers; > + ? ? ? ?int best_score = FLAC_HEADER_NOT_SCORED_YET; > + > + ? ? ? ?while (curr) { > + ? ? ? ? ? ?if (curr->max_score > best_score) { > + ? ? ? ? ? ? ? ?fpc->best_header = curr; > + ? ? ? ? ? ? ? ?best_score ? ? ? = curr->max_score; > + ? ? ? ? ? ?} > + ? ? ? ? ? ?curr = curr->next; > + ? ? ? ?} > + ? ?} > > it appears to me that fpc->best_header is always NULL at the point of > this check. am i missing something? score_headers used to set it to non-NULL, but this was code duplication, so I refactored some things and got rid of the if statement. > > + ? ?if (fpc->best_header) { > + ? ? ? ?if (fpc->best_header->offset > 0) { > + ? ? ? ? ? ?/* Output a junk frame. */ > + ? ? ? ? ? ?av_log(avctx, AV_LOG_DEBUG, "Junk frame till offset %i\n", > + ? ? ? ? ? ? ? ? ? fpc->best_header->offset); > + > + ? ? ? ? ? ?/* Set frame_size to 0. It is unknown or invalid in a > junk frame. */ > + ? ? ? ? ? ?avctx->frame_size ? ? ?= 0; > + ? ? ? ? ? ?*poutbuf ? ? ? ? ? ? ? = fpc->buffer; > + ? ? ? ? ? ?*poutbuf_size ? ? ? ? ?= fpc->best_header->offset; > + ? ? ? ?} > + ? ? ? ?fpc->best_header_valid = 1; > + ? ? ? ?if(!buf_size) > + ? ? ? ? ? ?return get_best_header(fpc, avctx, poutbuf, poutbuf_size); > + ? ?} > > too much space before the 3 '='. > missing space after 'if' done. > > +handle_error: > + ? ?*poutbuf ? ? ? ? ?= NULL; > + ? ?*poutbuf_size ? ? = 0; > + ? ?return buf_size; > > too much space before the '='. done. > > Thank you for being so patient and persistent in getting this patch approved. Thank you for the review! Michael

6 67

[PATCH] hqdn3d libavfilter port
by baptiste.coudurier＠gmail.com 04 Dec '10

04 Dec '10

Hi, $subject. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org

3 20

[PATCH 0/8] improve text subtitles muxing/demuxing
by aurel＠gnuage.org 04 Dec '10

04 Dec '10

The following series improve text subtitles muxing/demuxing support. It first share and improve the get_line() function from assdec so that if can be re-used by the SRT demuxer. It then implements a SubRip (SRT) muxer and demuxer. It also add seeking support in the ASS demuxer. Finally, it implements support for subtitles in AVI demuxer. It does so by calling av_open_input_stream(), av_read_packet() and avformat_seek_file() on the buffer containing the whole text subtitle. I have tested this successfully with SRT and ASS embedded in AVI, including correct seeking without outputing more packets than needed. --- Aurelien Jacobs (8): rename get_line to ff_get_line move ff_get_line to aviobuf.c improve get_line to return line length document ff_get_line() use return value of ff_get_line() add SRT muxer and demuxer add seeking support in ASS demuxer avidec: demux ASS and SRT tracks Changelog | 1 doc/general.texi | 1 libavcodec/avcodec.h | 1 libavformat/Makefile | 2 + libavformat/allformats.c | 1 libavformat/assdec.c | 60 ++++++++++++++++------- libavformat/avformat.h | 2 - libavformat/avidec.c | 119 +++++++++++++++++++++++++++++++++++++++++++++- libavformat/aviobuf.c | 15 ++++++ libavformat/internal.h | 13 +++++ libavformat/raw.c | 12 +++++ libavformat/srtdec.c | 102 +++++++++++++++++++++++++++++++++++++++ 12 files changed, 307 insertions(+), 22 deletions(-) create mode 100644 libavformat/srtdec.c -- Aurel

5 42

[PATCH+RFC] AVFrame for audio
by pross＠xvid.org 24 Nov '10

24 Nov '10

Hi, To prototype use of audio in AVFrame, I have modified the PCM encoder/decoder and addded new public lavc functions. Existing SAMPLE_FMTs are mapping onto (AVFrame*)->data[0]. The obvious next step is to support planar audio, and splitting FF_COMMON_FRAME into common, audio- and video-specific parts. avctx->reget_audio_buffer() is implemened using a simple realloc. It probably makes sense to reuse the video InternalBuffer stuff, but i'm not sure. Cheers, -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

8 52