February 2011 - ffmpeg-devel - lists.ffmpeg.org

WunderRadio changes
by diego＠biurrun.de 20 Sep '11

20 Sep '11

WunderRadio uses FFmpeg and even provides source: http://www.wunderradio.com/code.html I just had a 5 minute look, so I don't know any details, but there are some changes in there that we might wish to pick up: RTSP stuff and some ARM libswscale improvements. Diego

8 12

[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] 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

[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

[PATCH] Screen frame grabbing for Win32 platform (bump)
by christophe.gisquet＠gmail.com 21 Jul '11

21 Jul '11

Hello, now for an even older thread bump: https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-February/022360.html I've just adapted it to the new system and just left in the cursor capture in. It should be noted the frame grabbing itself is very slow and nothing much can be done about it, except going a _completely_ different way. Best regards, Christophe

11 27