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

[PATCH] default multicast to socket reuse
by david＠fries.net 18 Sep '11

18 Sep '11

We have a number of streams that are being multicast on the local network and have a .sdp file useed to configure ffplay and the ffmpeg library to listen in to those stream. In this case there isn't any way to tell ffmpeg to set the SO_REUSEADDR flag so that multiple programs on the same computer can receive the same multicast stream. With the sdp configuration file ffmpeg will build the uri internally so there isn't any way to specify the reuse=1 option in the uri. This defaults udp.c to enable socket reuse if it is multicast and reuse=0 is not specified. -- David Fries <david at fries.net> http://fries.net/~david/ (PGP encryption key available)

3 3

h264.c: interlaced_frame decission based on sei_ct_type seems to be incorrect
by rnissl＠gmx.de 18 Sep '11

18 Sep '11

Hi, according to the specs, sei_ct_type values 0 and 2 are likely to indicate a progressive frame while 1 indicates an interlaced frame. So it looks to me like a typo, that the wrong bit is tested to derive interlaced_frame. Please see attached patch for a possible fix. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl at gmx.de

2 1

[PATCH] Fix mpegtsenc's choking on first H264 start code
by alexandre.ferrieux＠orange-ftgroup.com 18 Sep '11

18 Sep '11

Hi, It turns out that when muxing an H264 bitstream, mpegts_write_packet has a very crude check on AnnexB start codes. Specifically, it wants a 4-byte 00000001, disallowing the 3-byte 000001 which is also valid and occurs on the first NALU. As a consequence, ffmpeg is currently unable to mux H264 into TS: ffmpeg -f h264 -i a.264 -vcodec copy -f mpegts -y a.ts => [mpegts @ 0xa11cb80]h264 bitstream malformated, no startcode found, use -vbsf h264_mp4toannexb The attached patch restores correct behavior, by also allowing the 3-byte start code, making the above command line work. HTH, -Alex

4 4

[RFC] Issue with "standard" FPS/timebase detection
by darkshikari＠gmail.com 16 Sep '11

16 Sep '11

Test case: http://stfcc.org/misc/fraps.fps.test.zip In the "101fps" file, tb_unreliable gets triggered because of the framerate being >= 101. The if(duration_count[i] && tb_unreliable(st->codec) code in libavformat then proceeds to run, resulting in a framerate of 1/12, which obviously doesn't make any sense whatsoever and is rather broken. I understand the basic idea behind what the duration error code is doing, but I don't understand why it's giving such a weird result. The primary reason seems to be the multiply in double error= duration_error[i][j] * get_std_framerate(j); , which results in a bias towards very small framerate values. But even if I remove that, it still comes up with an extremely weird fps (695/12). Something is off in the error calculation, but I don't fully understand it enough to judge what it is. As this is Michael's code, I figure he can probably offer the best insight on what's going on here. Dark Shikari

2 1

[PATCH] Add support for MPEG-2 MP@HL-14 in mxf container
by danielk＠cuymedia.net 16 Sep '11

16 Sep '11

Support Main Profile at High 1440 Level in MXF container, using essence coding label from SMPTE RDD 9, table 6. -- Daniel

2 1

[PATCH] Binary text decoder
by pross＠xvid.org 16 Sep '11

16 Sep '11

Decoder and demuxer for various binary text formats. Samples here: /MPlayer/incoming/bintext -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)

3 2

[PATCH] change PAT/PMT/SDT playout to be dependant on PTS and not a number of packets.
by JULIAN GARDNER 14 Sep '11

14 Sep '11

Change the way in which the PAT, PMT and SDT are inserted into the Mpeg TS, now dependant on time. Set to repeat at PAT 250ms PMT 375ms SDT 1250ms Maybe add a way of the user setting these values to give faster or slower playout rates, as this does add to the TS overhead. Also cleaned up the udp.c, removed some variables and an av_log joolz

3 17

[PATCH] fixup mpegts_get_pcr to be more reliable
by elupus＠ecce.se 14 Sep '11

14 Sep '11

Hi, Here are a few patches i created while trying to figure out why a file "locked" up in mpegts_get_pcr on seek. I don't seem to learn that patches to the mpegts demuxer have a tendency to get lost in the void. Anyway... 0001: The code for backwords pcr searching could never be reached, so remove it. 0002: Respect the maximum stream position that the function is allowed to process. 0003: Make sure the return value of url_seek is respected 0004: Reindent after the above 0005: Make mpegts_get_pcr resync to stream if the position it is asked to look for a timestamp isn't on a mpegts syncword. ---- The real issue I found out later is that this particlar stream doesn't contain any packets with pid = pcr_pid, so it reads the whole file to attempt to find a starting timestamp for av_gen_search. Are the pid's for the pcr supposed to be listed in PMT? I haven't checked this yet, but i suspect the given pid isn't available in there either. Maybe it should be reset to -1 if the pid isn't found? Regards Joakim

2 1

ffmpeg -s breaks aspect ration (regression)
by Jean Delvare 14 Sep '11

14 Sep '11

Last time I updated ffmpeg, I hit a problem where option -s breaks the aspect ratio. I bisected the repository and found that this regression was introduced by: commit 7a11c82fb760619d0e17ca234381b50d6c675cc0 Author: Michael Niedermayer <michaelni(a)gmx.at> Date: Mon Jan 31 20:48:35 2011 +0100 vsrc_buffer: add sample_aspect_ratio fields to arguments. This fixes aspect handling in ffmpeg. This is based on a patch by Baptiste. Signed-off-by: Anton Khirnov <anton(a)khirnov.net> My input video looks like: Stream #0.0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x576 [PAR 64:45 DAR 16:9], 9500 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc I am passing -s 640x360 to ffmpeg to get square pixels, before the bug I would get: Stream #0.0(und): Video: mpeg4, yuv420p, 640x360 [PAR 1:1 DAR 16:9], 640 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc and the video would look OK. Since the commit above, I get: Stream #0.0(und): Video: mpeg4, yuv420p, 640x360 [PAR 1:1 DAR 16:9], 743 kb/s, PAR 91:64 DAR 91:36, 25 fps, 25 tbr, 25 tbn, 25 tbc and the aspect ratio is wrong when video is played with totem or mplayer (although surprisingly correct with ffplay.) I _can_ fix the problem by passing an additional -aspect 16:9, but I didn't have to do that before and it seems wrong that the aspect ratio is not preserved by default. Can this bug be fixed, please? I'll be happy to perform any amount of testing or provide a small sample input file. As a side note, I would be very grateful if someone could explain to me how a given video stream can have two different PAR, why anyone would want to do this, and what a video player is supposed to do in that case (apparently totem/gstreamer and ffplay do not agree.) Thanks, -- Jean Delvare

2 6

[PATCH] Check extradata size on resolution change.
by Reimar Döffinger 04 Sep '11

04 Sep '11

Ignore resolution change if resolution not defined in extradata. Signed-off-by: Reimar Döffinger <Reimar.Doeffinger(a)gmx.de> --- libavcodec/rv30.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/libavcodec/rv30.c b/libavcodec/rv30.c index cd11079..a9ea6e0 100644 --- a/libavcodec/rv30.c +++ b/libavcodec/rv30.c @@ -51,6 +51,11 @@ static int rv30_parse_slice_header(RV34DecContext *r, GetBitContext *gb, SliceIn skip_bits1(gb); si->pts = get_bits(gb, 13); rpr = get_bits(gb, r->rpr); + if (r->s.avctx->extradata_size < 8 + rpr*2) { + av_log(r->s.avctx, AV_LOG_WARNING, + "Extradata does not contain selected resolution\n"); + rpr = 0; + } if(rpr){ w = r->s.avctx->extradata[6 + rpr*2] << 2; h = r->s.avctx->extradata[7 + rpr*2] << 2; -- 1.7.4.1

2 2