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

[PATCH] rtpdec: make the NTP time values unsigned.
by flameeyes＠gmail.com 09 May '14

09 May '14

As per RFC3550, section 4, the NTP time is provided as 64-bit unsigned integer, so follow the same logic here. --- libavformat/rtpdec.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/rtpdec.h b/libavformat/rtpdec.h index 86af2b9..87fd419 100644 --- a/libavformat/rtpdec.h +++ b/libavformat/rtpdec.h @@ -148,8 +148,8 @@ struct RTPDemuxContext { RTPStatistics statistics; ///< Statistics for this stream (used by RTCP receiver reports) /* rtcp sender statistics receive */ - int64_t last_rtcp_ntp_time; // TODO: move into statistics - int64_t first_rtcp_ntp_time; // TODO: move into statistics + uint64_t last_rtcp_ntp_time; // TODO: move into statistics + uint64_t first_rtcp_ntp_time; // TODO: move into statistics uint32_t last_rtcp_timestamp; // TODO: move into statistics /* rtcp sender statistics */ -- 1.7.1.1

4 3

Yamaha SMAF 'CNTI' chunk is wrong.
by yoshihisa.uchida＠gmail.com 07 Jan '13

07 Jan '13

Hi, ffmpeg developers, For Yamaha SMAF, Contents Info chunk ('CNTI') includes only following members: - Contents Class - Contents Type - Contents Code Type - Copy Status - Copy Counts (see http://smaf-yamaha.com/what/s52.html) But, in the current ffmpeg, 'CNTI' includes metadata ("VN:libavcodec,"). According to SMAF Specifications Optional Data Chunk (http://smaf-yamaha.com/what/s52.html) I corrected that metadata include Optional Data Chunk ('OPDA'). Regards, uchan

5 5

[PATCH] OpenEXR decoder
by jimmy＠ghost.dk 06 Apr '12

06 Apr '12

Hi, Here is my stab at a OpenEXR decoder. It only supports 16-bit and 32-bit float. 8-bit integer is in theory supported aswell by the format, but I have yet to find software which supports writing it, but it should be quite straigthforward to implement aswell, but didn't want to touch it since I had nothing to test with. The 32-bit float path is very slow (about 60x slower than the 16-bit path) and not optimized in way yet. -- Best Regards Jimmy Christensen Developer Ghost A/S

9 77

dvd/vob "decoder" part 1: the system itself
by erik＠arawix.com 03 Feb '12

03 Feb '12

Hello; Included are the files, and patches needed for the dvd decoder. I threw away my original system on trying to insert packets into the main stream (as the "attachment/data" type stream). The reason for that is that the dvd data stream, that contains commands for the client can change/insert packets "in the past". Example; a user seeks back. The DVD ifo system will insert packets containing "change the subtitle color" so it works ok for the displayed cell/chapter. LibAV doesn't expect new packets inserted "backwards" in the stream, and the buffer system gets all messed up because packet sizes are off. Changing to a new system means my "hack" on decoding the packet header isn't needed any more, and except for stream flagging the mpegps demuxer should be unchanged. My attachment decoder is not needed anymore (for those who looked at it, only dvd_protocol.c/h are still needed). The new system uses a callback, that the user registers. This is, after much experimenting, the best way I could come up with. The callback though is registered per protocol, and thus changes are needed in "gasp" URLContext. Reason for keeping it per context? Well, a user can be reading from several dvd devices at the same time if he/she uses the avlibs. Or some end devices (like the ps3) send several request to open a file at the same time. If one callback is registered for the whole library, this messes up the system. Whats send in the callback? Basically AVDVDParseContext packets. They contain a type (the enum effdvd_Type ) that tells the end-user app what should be done, and a pts timestamp in dvd time (90000/tick). The packets should be handled at that time. There are some packets which are obvious (like: new subtitle palette) and some that are not. The most important one is effdvd_Reset_IFO. effdvd_Reset_IFO asks the end-user app: clear your streams, flag all streams you are using as invalid (more later on that), and be prepared to re-init all your codec decoders. Why does one need to do that? Because a vob file 1 might contain audio data in ac3 with 2 channels, while a vob 2 might have it in 6 channels. Or the resolution of the video stream might change (from dvd pal to dvd ntsc widescreen for example). First; DVD's may contain up to 64 streams. One of the patches changes the MAX_STREAMS constant to match that. Second; Stream re-init. I implemented this by adding a flag to AVStream (at the end, discard_flags). Set this to one in end-user app, and this will tell the demuxer that this stream has been discarded by user (user closed all codecs, etc). It works by telling the demuxer that once it dedects a certain packet type, and normally does a av_new_stream; don't re-add the stream to the end of the new list (pushing more and more streams on the list). Example; suppose the discard_flag is set to 1 for the video stream (and we only have one). When a new packet is received by the demuxer, its loop will not find a valid video stream anymore. It thus will create a new one, but will fill the slot for the "old" video stream with the new video stream. Don't know if this text makes sense, bit a quick look at the code should be helpful. Why not do this in the protocol reader? Basically 1) because the protocol doesn't and shouldn't know about the streams and 2) because the end-user needs to close and free his/her decoders. Once that's done, the demuxer doesn't even know. Next; chapter seeking. I added a new flag for that: #define AVSEEK_FLAG_DIRECT 8 ///< seek directly, skipping any stamps and translation #define AVSEEK_FLAG_CHAPTER 16 ///< seek to chapter, if supported Using that will basically use av_seek_frame() to override a search like it does for AVSEEK_FLAG_BYTE. The arguments timestamp will thus position chapters, instead of timestamps. Summary; whats the total change; 1) The whole setup adds a protocol handler called ffdvd. User inits his open file with av_open_input_file ("dvdread:e:/") or av_open_input_file("dvdread:/cdrom1/") 2) User registers a callback by using url_fset_protocol_callback(), a new function in avio.c. I tried to make it generic. 3) User polls streams as before for audio/video 4) User can get callback events from the protocol, with timestamps. 5) Events get examined for the timestamps on the protocol packet, and handled upon. 6) When needed, these events are executed, and for some functions a notify is send back (example, when user selects a button dvd_protocol_select_button() is called). 7) That's it. How well does this all work? I build a example app separate from ffmpeg, on which rather big changes are going to be needed. Note that these changes have almost nothing to do with the dvd protocol handler. They are mostly implementing the "we should look at this/this is wrong/etc" comments (example; discarding new streams). I have ffplay ok, but will need to work with someone on ffmpeg. Source is. Offcourse available. I am attaching the main files here, and the most important patches. Since I am not sure on how the continue on this, please tell me how this needs to be handled (ege do patches first, what order,. Etc. ) If the system is accepted, at least one patch needs a major version bump. I should probably split up some patches too. Note 2; I need to talk to the people for libdvdread, since I fixed a few problems in their code (and added one function to read attributes that its not available now dvdnav_get_video_attributes()). To have this working, we would offcourse also need to depend on libdvdread (if the user enabled it by ./configure, changes for makesfiles and that needed). Note 3: we will probably need some commandline extensions to specify seeking to a chapter, etc. for ffmpeg I have worked on and of on this for the better part of 2 months figuring out the best and least intrusive way. If this all gets rejected, I am fine with that. If it doesn't, also. Just let me know. Erik

6 10

[patch] libpostproc: mmx code uses stack below %esp
by yumkam＠mail.ru 23 Sep '11

23 Sep '11

Hello! While trying to catch unrelated bug (that finally was not bug, but misconfiguration [-lavdopts fast was too fragile for broken mpeg-2 stream]), I've run mplayer under valgrind, and got bunch of warnings: ==32414== ==32414== Invalid write of size 8 ==32414== at 0x874CF44: postProcess_MMX2 (in /path/to/mplayer) ==32414== Address 0xbeffa9d0 is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes I, of course, don't use gcc-2.96 ;-) I've looked into libpostproc/postprocess_template.c, and, indeed, it uses memory below %esp: === cut === static inline void RENAME(doVertDefFilter)(uint8_t src[], int stride, PPContext *c) { [...] __asm__ volatile( "pxor %%mm7, %%mm7 \n\t" "lea -40(%%"REG_SP"), %%"REG_c" \n\t" // make space for 4 8-byte vars "and "ALIGN_MASK", %%"REG_c" \n\t" // align ... } [...] static inline void RENAME(dering)(uint8_t src[], int stride, PPContext *c) [...same...] static av_always_inline void RENAME(do_a_deblock)(uint8_t *src, int step, int stride, PPContext *c){ [...same...] === cut === Not sure if this *must* be fixed, but it feels unsafe, so... Patch attached; doVertDefFilter and do_a_deblock changes should not affect speed, not sure about dering one.

3 9

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

[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