March 2010 - ffmpeg-devel - lists.ffmpeg.org

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

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

[PATCH] lavfi test pattern generator
by stefano.sabatini-lala＠poste.it 26 Jun '11

26 Jun '11

Hi all, useful for testing, it is based on the test pattern generator by Nicolas George: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-October/036838.html basically I just stripped the audio signal generator and adapted few things to the lavfi framework, so most credit goes to Nicolas. And it would plenty cool to find some way to get ffmpeg/ffplay take as input such a generator, but I still can't see how to do that. What I can do now is to take as input /dev/null, then overlay the test_pattern over it, but this is rather ugly. Regards. -- FFmpeg = Freak and Fierce Mysterious Proud Erratic Gadget

7 24

[FWD] [PATCH] immediate decoding of dvd stills
by nicola_sabbi＠fastwebnet.it 24 Jun '11

24 Jun '11

Some time ago someone posted this small patch to permit decoding dvd still images without setting LOW_DELAY; unfortunately it seems the patch was forgotten Is it ok to commit? If not, what's the right way to proceed?

5 17

[PATCH] encoder for adobe's flash ScreenVideo2 codec
by joshuawarner32＠gmail.com 07 May '11

07 May '11

Hi all, I've developed an encoder for Adobe's Flash ScreenVideo2 format, which is stored in flv files. My encoder currently only supports a large subset of the format. The only player that supports this codec (so far) is Adobe Flash Player itself, but ScreenVideo2 makes dramatic improvement in file size over ScreenVideo (currently in ffmpeg as flashsv) - and should be very useful for uploading screencasts, etc. Most options (block size, etc) now just fall back on defaults because I couldn't find a general algorithm that produced consistantly better results than these. All the code is in place to be able to change these parameters dynamically, so future improvements there should be easy. The patch is attached. The codec is listed as flashsv2 in ffmpeg. Joshua Warner

13 41