[Ffmpeg-devel-irc] ffmpeg-devel.log.20120808

[burek]

[00:04] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rbb2f13c19f 10ffmpeg/ (10 files in 3 dirs): 
[00:04] <CIA-41> ffmpeg: rename missed CodecID to AVCodecID
[00:04] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:37] <saste> ubitux: leave me another day for commenting on edgedetect, i need to sleep now...
[00:49] <ubitux> saste: sure no problem :)
[01:03] <CIA-41> ffmpeg: 03Paul B Mahol 07master * r8654d6c892 10ffmpeg/libavcodec/libtwolame.c: 
[01:03] <CIA-41> ffmpeg: libtwolame: fix stupid bug
[01:03] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[01:17] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rc794acc44e 10ffmpeg/libavutil/x86/x86inc.asm: 
[01:17] <CIA-41> ffmpeg: x86inc.asm: remove redundant ifdef __YASM_VER__
[01:17] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:17] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * re40f7f1e01 10ffmpeg/libavcodec/cavs.c: 
[01:17] <CIA-41> ffmpeg: cavs: fix memleak
[01:17] <CIA-41> ffmpeg: Fixes Ticket1335
[01:17] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:57] <Compn> hmm
[02:57] <Compn> who do i bug about filters
[02:58] <Compn> ubitux?
[03:29] <durandal_1707> Compn: what is problem?
[03:54] <Compn> durandal_1707 : well not problem, i havent verified. but is philisophical question :)
[03:55] <Compn> durandal_1707 : in mencoder, the order of filters matters speed wise, so if you have a 1920:1080 source and you -vf rotate=1,scale=640:-2 , you will only get 10fps encoding speed, but if you -vf scale=640:-2,rotate=1 (scale, then rotate) you get 22fps
[03:55] <Compn> not sure if this is because the rotate filter sucks or because thats just how it is... but i wonder if a warning message or some kind of docs could be written about it :)
[03:56] <Compn> if the same problem exists in ffmpeg anyways
[04:12] <juanmabc> mmm, sws_scale eats 15% cpu, how come?
[04:13] <juanmabc> (mplayers can plays at 10%, my player at low res 30%)
[04:22] <juanmabc> well, using SWS_FAST_BILINEAR i can get higher res at the same 30%, before it was 50%
[04:25] <Compn> probably sws selected sure
[04:25] <Compn> mplayer -sws 1-9 (check manual)
[04:33] <juanmabc> sws selected sure?
[04:35] <Compn> i mean, different scaling algorithms will have different speeds :)
[04:36] <juanmabc> i guess BILINEAR would be a minimal good default?
[04:36] <juanmabc> also aren't the CAPS_SSE2 ... autodetected?
[04:37] <juanmabc> SWS_CPU_CAPS i mean, i do to apply them? SSE2 gives me no benefit
[04:43] <Compn> Replace all CODEC_ID_* with AV_CODEC_ID_*
[04:43] <Compn> what the duece
[04:44] <juanmabc> quoting docs: "CPU caps are autodetected now, those flags are only provided for API compatibility. "
[04:44] <Compn> juanmabc : i have no idea
[04:44] Action: Compn afk
[05:17] <juanmabc> couild i have some performance by tiling the buffers ?
[05:18] <juanmabc> since sws_scale has some slices
[05:18] <juanmabc> concept
[05:21] <juanmabc> i think mplayer does the scale by tiles
[05:48] <michaelni> juanmabc, doing it by slices should be faster, yes
[05:49] <michaelni> also if you arent sure if some optimizations are turned on a simple av_log/printf() in a optimized routine will beyind doubt clarify if its used
[05:54] <juanmabc> ok, michaelni, you always here, :D
[05:54] <juanmabc> i'm at the point on the problem being the size scaling
[05:55] <juanmabc> prescaling with console ffmpeg command gets 14%, without 21%
[05:55] <juanmabc> 14 is pretty good, here
[05:56] <juanmabc> i'm gonna try slicing
[06:29] <juanmabc> i can figure the srcslicey, taking i go 1 row at a slice
[06:29] <juanmabc> i would guess it being i * width * bpp
[06:30] <juanmabc> which by the way bpp has no interface from pixmft as SampleFormat haves (get_bytes_per_sample)
[07:21] <ubitux> Compn: i don't know how you would detect such case and print a warning
[07:21] <ubitux> it sounds just like common sense to me
[07:31] <ohsix> print the cost for the filters, but there's n o way if the order will matter without trying them or expressing it somehow so the order can be chosen automatically, like a rule of thumb
[07:32] <ohsix> or a coefficient for the filter expense based on the frame/slike/row/whatever size, so you can take the info you have, check the coefficient and compare them with that
[07:32] <ubitux> you want profiling within ffmpeg then :)
[07:33] <ubitux> why not... :)
[07:33] <ohsix> that would be cool, and general, but a coefficient probably works
[07:34] <ohsix> since this is computer science and stuff
[07:34] <ubitux> depends on too much things i think
[07:35] <pengvado> Compn: yes, the rotate filter sucks
[07:35] <ohsix> it would only help you decide if a filter was cheaper before or after something that changed the frame size, or if you had 2 filters that could reasonably do the same task, but one is cheaper for the circumstance
[07:36] <pengvado> ohsix: otoh, tweaking the order of filters to optimize for speed, is often pessimizing for quality
[07:37] <ohsix> yea, you could measure that too, and always favor speed or quality or something in between when you decide on it
[07:38] <ohsix> would make it self adjusting, you could have all the scaling filters but the quality coefficient can be different, instead of changing between filters while you're testing or whatever, you just change the quality and the filters "rank" changes
[07:39] <ohsix> this is all hypothetical, but you could have many filters that do the same thing and have them selected automatically if this was all in place
[07:39] <ohsix> eg. instead of one super scaler that has special cases for certain scale factors and stuff, you factor it out into a separate scaler and let the coefficient pick it over the more general but slower scaler
[08:23] <CIA-41> ffmpeg: 03jamal 07master * r82e5c5d45b 10ffmpeg/libavcodec/old_codec_ids.h: lavc/old_codec_ids: Fix make checkheaders.
[09:12] <CIA-41> ffmpeg: 03Clément BSsch 07master * r6b3484dcbc 10ffmpeg/libavformat/mxfenc.c: lavf/mxfenc: better error handling with invalid frame rate.
[09:12] <CIA-41> ffmpeg: 03Clément BSsch 07master * raad737c669 10ffmpeg/libavformat/mxfenc.c: lavf/mxfenc: simplify frame rate checks.
[09:12] <CIA-41> ffmpeg: 03Clément BSsch 07master * r4b365b0868 10ffmpeg/libavutil/ (timecode.c timecode.h version.h): lavu/timecode: add av_timecode_check_frame_rate().
[09:12] <CIA-41> ffmpeg: 03Clément BSsch 07master * raca0f78114 10ffmpeg/libavformat/movenc.c: 
[09:12] <CIA-41> ffmpeg: lavf/movenc: add frame rate heuristic for timecode frame rate.
[09:12] <CIA-41> ffmpeg: Fixes ticket 1576.
[10:05] <nenjordi> gm
[10:42] <ubitux> hey :)
[10:42] <saste> ubitux: go on
[10:42] <ubitux> yup
[10:43] <ubitux> so it's not a surprise, but most people expect lavfi to be able to do ivtc stuff
[10:43] <ubitux> otherwise it will likely never be really used
[10:43] <ubitux> (along with motion compensation stuff)
[10:44] <saste> ubitux: it's not like I am a video engineer, so I'm not that used to all that stuff (I never need it)
[10:44] <ubitux> it seems the most commonly used is the tivtc package
[10:44] <saste> but i see we have some related filters in mp
[10:44] <saste> first question: do they work?
[10:44] <ubitux> i personnaly never used them
[10:45] <saste> do we have something which can try that stuff and report
[10:45] <saste> mencoder was pretty used in that niche, so i suppose it already had filters for fixing the common problems in that area
[10:45] <ubitux> the recently added one in vlc might be decent, but the most commonly used are the filters in the tivtc package
[10:45] <saste> uhm... is that wrappable?
[10:45] <ubitux> not at all
[10:45] <ubitux> VS stuff, asm, avisynth etc
[10:46] <saste> nyuhu: ^^
[10:46] <JEEB> http://web.missouri.edu/~kes25c/ <- tivtc's real home
[10:46] <JEEB> (tritical's site)
[10:46] <JEEB> also, a big warning
[10:46] <JEEB> it's a big lump of ugly code
[10:46] <JEEB> with way too many features to count
[10:46] <ubitux> :)
[10:46] <JEEB> that said, have fun
[10:46] <saste> JEEB: we're used to that
[10:47] <saste> we're professional code exorcist
[10:48] <ubitux> from what i heard yesterday, the classic workflow is something like that: MPEG-2/analog source (DVD..) ’ (fieldmatching || dinterlace) ’ decimate ’ pp random stuff: antialias/denoise/sharpen/crop/resize
[10:48] <saste> ubitux: the socis task is supposed to cover exactly this area
[10:48] <ubitux> (deinterlace being used depending on wether field matching works or no, i guess if badly interlaced material etc)
[10:49] <ohsix> tivtc is the one that can read the field file from dmpgdec right?
[10:49] <JEEB> ubitux, yup -- got it right. might want to add trimming/cutting off parts after loading the source tho (be it commercials or just the final/first parts of a movie on a DVD/BD that you don't want to encode)
[10:49] <ohsix> FWIW, i couldn't use ffmpeg for what i was doing, but i also had to use dmpgdec so it was kind of moot
[10:50] <ohsix> but i have used tivtc
[10:50] <ubitux> there was also mention of various stuff like imagemagick wrapper, inverse resizing (debilinear?), and better denoise filters (such as dfttest which seems broadly used)
[10:50] <ubitux> JEEB: trim/cut off can be achieve with vf select already
[10:50] <ubitux> saste: ah and the last important thing
[10:51] <ubitux> constructing graph with libavfilter really scare people
[10:51] <ubitux> and doesn't look flexible enough to them at all
[10:51] <ubitux> especially given the kind of automated workflow i was mentioning above
[10:52] <ubitux> (ah and almost forgot, gamma curve op were mentioned but i think we have some tools already for that)
[10:53] <saste> ubitux: yeah as for the complexity problem i don't know
[10:53] <saste> a GUI could be an idea...
[10:53] <ubitux> yeah, some gui to generate filtergraph
[10:53] <saste> but that's a lot of work not in our expertise area
[10:53] <saste> not to mention the portability issues (which trollkit to use??)
[10:54] <ubitux> i think the priority should be to make a basic workflow possible, even with some relative pain
[10:54] <saste> that looks like an external project
[10:54] <saste> yes indeed
[10:54] <saste> as for flexibility, anything specific?
[10:54] <ubitux> so DVD probing, ivtc, and eventually random filter to increase quality
[10:54] <ubitux> saste: apply specific processing to a range of frames
[10:55] <ohsix> hrm i had to use virtualdub too, guess there was really nothing i could have done except maybe just the encoding
[10:55] <saste> we should be able to support streams filtering choreography through reconfiguration (stuff like smile) 
[10:56] <ubitux> note that eval is not intuitive, and escaping also is a pain
[10:56] <saste> ubitux: frame specific processing also it should be possible with metadata injection
[10:56] <ubitux> communication within filter would be nice
[10:56] <saste> i discovered that thomas kuhnel did something in that area (metadata in filters)
[10:56] <saste> it is in his repo, but never posted
[10:57] <saste> communication within filter: cmd API (what i call event processing)
[10:57] <saste> event auto-injection would be possible by making each filter access the filtergraph
[10:57] <saste> that is we could store a pointer to the filtergraph in each filter
[10:58] <crtmpserver> hello to all
[10:58] <ohsix> i really liked the avisynth workflow too :p
[10:58] <ubitux> anyway, our current "improving quality" filters such as unsharp or hqdn3d seems to be far from being enough in comparison to dfttest and stuff like that
[10:58] <saste> then each filter can become aware of the global filtergraph, and send specific reconfiguration event to specific filters
[10:58] <ubitux> i think i'm done with my "report"; if JEEB or anyone wants to fill the gaps...
[10:59] <ubitux> saste: communicating through metadata means only strings exchange, right?
[10:59] <crtmpserver> I think I found a bug in the libavformat/rtmpproto.c
[10:59] <saste> ubitux: yes
[11:00] <crtmpserver> (sorry guys for highjacking this)
[11:00] <saste> crtmpserver: fork the channel ;-)
[11:00] <ohsix> ffmpeg can do a sort of preset file thing right
[11:01] <crtmpserver> saste: what do you mean by fork?
[11:01] <saste> crtmpserver: a silly joke
[11:01] <ohsix> stylistically speaking that shouldn't be much different from what avisynth does, it stores settings and filter configurations and you just treat it as an input file
[11:01] <ubitux> crtmpserver: go ahead, we can have interleaved talks somehow
[11:01] <crtmpserver> saste: yeah, so apparently the coffee is not enough on this side
[11:02] <crtmpserver> gen_check_bw is using a non-standard rtmp invoke: _checkbw
[11:03] <crtmpserver> correct approach is to use checkBandwidth
[11:03] <crtmpserver> according to Adobedocs:
[11:04] <crtmpserver> "The client should initiate bandwidth detection after successfully connecting to the server. To start bandwidth detection, call NetConnection.call(), passing it the special command checkBandwidth. No server-side code is needed"
[11:04] <crtmpserver> so, where did the "_checkbw" came from?
[11:05] <crtmpserver> also, there is another problem: _checkbw can not be ignored because is sent with a transactionId != 0, forcing the server to answer something
[11:06] <crtmpserver> if transactionId==0, than the call is a procedure (not having to return anything) rather than a function (must return something)
[11:09] <crtmpserver> so, there are a number of ways to fix it:
[11:11] <crtmpserver> 1. use checkBandwidth instead of _checkbw WITH transactionId==0. Everyone is happy
[11:11] <crtmpserver> 2. keep the current impl but put transactionId==0 so the server will not give back _error if it doesn't know anything about that weird function call
[11:11] <crtmpserver> 3. keep the current impl but don't choke on the _error message when it arrives. That is normal. The server doesn't know anything about that weird _checkbw
[11:15] <ubitux> i was wondering; isn't this kind of a pain when this kind of stuff is interlaced? http://img4.imageshack.us/img4/4897/kinonotabi01h264vorbisn.png
[11:16] <ubitux> (the source has those horizontal lines)
[11:21] <JEEB> that looks like failed IVTC/source that needs some vinverse
[11:21] <ubitux> actually it seems the show has those lines
[11:22] <ubitux> anyway; anyone has any reference material to test ivtc and various decimate stuff?
[11:26] <Compn> crtmpserver : you should talk to kshishkov or #libav-devel , since thats where rtmp stuff is being developed
[11:29] <saste> crtmpserver: yes or lu_zero, or wbs
[11:29] <crtmpserver> tx guys
[11:29] <crtmpserver> going there
[11:29] <saste> libav is having a related gsoc and we'd prefer not to interfere
[11:29] <Compn> i think the rtmp stuff is / was libav gsoc project
[11:29] <Compn> good luck crtmpserver :)
[11:29] <saste> note that wbs is here so maybe he can advise
[11:30] <Compn> crtmpserver : get them to do rtmpe10 support too ...
[11:30] <crtmpserver> FYI, I just tested all those fixes and they all work
[11:30] <saste> hi martin :)
[11:30] <crtmpserver> I prefer the first one, whch is the most standard
[11:30] <Compn> librtmp ?
[11:30] <wbs> crtmpserver: our gsoc student is working on alternative 3 at least
[11:34] <wbs> crtmpserver: but I'll make a note about this being nonstandard as well, doing alt. 3 doesn't stop us from doing the other oens as well
[12:38] <saste> ubitux: is there any reason for which edgedetect doesn't support parameters at the moment?
[12:56] <saste> ubitux: i think we need to implement some convolution utilities
[14:00] <ubitux> saste: yes there is one
[14:00] <ubitux> i'll reply to you in a minute
[15:41] <ubitux> saste: so how do you add parametrization and later different modes without breaking the format?
[15:41] <durandal_1707> saste: smptebars filter displays bogus warning about specified color.....
[15:42] <ubitux> (durandal_1707: btw, i added twolame to the fate+shared box the other day)
[15:42] <ubitux> (seems no issue were raised)
[16:16] <saste> ubitux: edgedetect=low=0.2:high=0.5
[16:17] <saste> the option doesn't apply if the algorithm selected doesn't support them
[16:17] <ubitux> ok
[16:17] <ubitux> right; will do this tonight and resubmit
[16:17] <saste> we have plenty examples, you can eventually warn the user if a param is not used by the given algo
[16:17] <saste> durandal11707: how?
[16:18] <durandal11707> did you tried it?
[16:18] <CIA-41> ffmpeg: 03Paul B Mahol 07master * rc7bbd82170 10ffmpeg/doc/general.texi: 
[16:18] <CIA-41> ffmpeg: doc/general: move ZeroCodec to right section
[16:18] <CIA-41> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[16:19] <saste> ah i see damn
[16:19] <ubitux> saste: btw i'm not discarding pixels on the borders, they're copied
[16:20] <ubitux> so no blur for borders
[16:20] <ubitux> in practice i don't see any problem in that case
[16:21] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rbed63a5e98 10ffmpeg/configure: 
[16:21] <CIA-41> ffmpeg: configure: fix sctp check.
[16:21] <CIA-41> ffmpeg: This fixes build failures on debian/kfreebsd
[16:21] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[16:25] <durandal11707> anyone going to write videodiff filter (like ImageMagick compare or even better)?
[16:26] <durandal11707> hmm is assertion in elbg really correct?
[16:27] <ubitux> mateo` ^
[16:29] <mateo`> durandal11707: i'm interested in writing this filter
[16:29] <Daemon404> vf_imagemagick
[16:29] Action: Daemon404 runs
[16:29] <ubitux> Daemon404: can be complementary :)
[16:30] <ubitux> Daemon404: also it's likely a vf_imagemagick will have a single input at first
[16:30] <Daemon404> indeed
[16:30] <Daemon404> the one thing i always use imagemagick for is generating fft visualizations
[16:30] <Daemon404> its handy
[16:31] <durandal11707> mateo`: than write it, i give you 3 months, after that if it is not done and I'm still here I will write it
[16:31] <ubitux> is imagemagick providing a library?
[16:31] <Daemon404> yes
[16:31] <mateo`> durandal11707: ok :)
[16:32] <Daemon404> ubitux, are you the man to ask about ffmpeg.c behavior?
[16:33] <ubitux> you can try
[16:33] <ubitux> but better ask the channel
[16:33] <Daemon404> incomplete frame
[16:33] <Daemon404> Error while decoding stream #0:1: Invalid data found when processing input
[16:33] <Daemon404> ^ lot of videos with the last frame of the mo3 data incomplete
[16:33] <Daemon404> and ffmpef returns error
[16:34] <Daemon404> wondering if there was a way to handle it wthout special casing
[16:34] <Daemon404> its ending up with transcodes marked as failed
[16:35] <ubitux> without digging, no idea
[16:35] <durandal11707> Daemon404: what container(s)?
[16:35] <Daemon404> avi
[16:35] <Daemon404> of course
[16:36] <ubitux> magickwand doesn't look like a complicated api
[16:37] <ubitux> but it looks like it will require a lot of bindings within the filter
[16:38] <ubitux> oh, there is MagickCommandGenesis() :)))
[16:52] <CIA-41> ffmpeg: 03Stefano Sabatini 07master * rdbf25b70ea 10ffmpeg/libavfilter/vsrc_testsrc.c: 
[16:52] <CIA-41> ffmpeg: lavfi/testsrc: set default value for option "color" to NULL and rework color setting logic
[16:52] <CIA-41> ffmpeg: Fix bogus warnings of the kind:
[16:52] <CIA-41> ffmpeg: option 'color' is ignored with source 'testsrc'
[16:52] <CIA-41> ffmpeg: when the color value is not explicitely set and the filter is different
[16:52] <CIA-41> ffmpeg: from "color".
[17:05] <saste> ubitux: btw any news on showrfdt?
[17:05] <ubitux> will look tonight, after making low & high in edgedetect :)
[17:05] <saste> ok
[17:05] <ubitux> i still need to debug the flickering issue
[17:06] <saste> i'm thinking about emulating ffplay display mode in showwaves, so that we can substitute it with lavfi without users even noticing it
[17:08] <ubitux> note that ffplay handles resizes 
[17:08] <saste> ah that will be more painful
[17:09] <saste> well i procrastinating this stuff since too much time, time to send an rfc about reconfiguration
[17:09] <saste> ...later
[17:11] <ubitux> :D
[18:02] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * ree475e272e 10ffmpeg/libavformat/matroskadec.c: 
[18:02] <CIA-41> ffmpeg: matroskadec: fix lace vs block duration.
[18:02] <CIA-41> ffmpeg: Fixes Ticket1270
[18:02] <CIA-41> ffmpeg: Thanks-to: Moritz Bunkus
[18:02] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:50] <durandal11707> vorbis is dead?
[19:26] <finga> i want to program a tool for mixing videos is there something done with ffmpeg? and am i at the right place for this kind of question?
[20:01] <michaelni> finga, look at ffmpegs libavfilter
[20:03] <finga> michaelni: thx i will look in the git repo, but is there also more documentated than just git like a wiki or something else?
[20:09] <michaelni> i dont think theres a uptodate doc, best is probably to look at some filters that do similar things and read the doxy in the headers
[20:11] <finga> ok thx i will try to find something, if not i'll try it here again but more specific ;)
[21:17] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rb615dbb319 10ffmpeg/libavformat/utils.c: 
[21:17] <CIA-41> ffmpeg: lavf: block special characters in dump metadata
[21:17] <CIA-41> ffmpeg: This is limited to the chars that arent filtered by av_log() already
[21:17] <CIA-41> ffmpeg: we might filter more aggressively if theres some case where this becomes
[21:17] <CIA-41> ffmpeg: needed.
[21:17] <CIA-41> ffmpeg: Fixes Ticket1181
[21:17] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:17] <ubitux> michaelni: in the next merge, i don't think it is a good idea to merge 7ca14c731ed1fca7072c335095c2d96a6cb80fc0
[22:18] <ubitux> at least i don't really agree with that, and i'm not sure saste would as well
[22:19] <ubitux> or well, it could be reworded
[22:19] <ubitux> (it should be discouraged just with ffmpeg, and not "especially" with it)
[22:19] <ubitux> (just my opinion)
[22:28] <iive> ubitux: what is this about. hashes are so... human hostile.
[22:28] <ubitux> sorry
[22:29] <ubitux> it's about saying movie source filter being a hack
[22:29] <ubitux> and that it should not be used
[22:29] <ubitux> that's indeed not required anymore with ffmpeg with -filter_complex, but you *need* it with the other tools
[22:29] <ubitux> also, it can be way more simpler in case of api usage
[22:30] <llogan> it's the most recent qatari commit
[22:31] <iive> i see, thanks you.
[22:31] <iive> guh... thank you.
[22:32] <michaelni> ubitux, ill skip it unless i forget tomorrow (in which case flame me)
[22:32] <ubitux> it's not that important :)
[22:33] <ubitux> iive: also not that we have a more advanced movie source filter, and we also support audio that way
[22:33] <ubitux> note*
[23:02] <CIA-41> ffmpeg: 03Clément BSsch 07master * re6dd2852ca 10ffmpeg/libavfilter/af_atempo.c: lavfi/atempo: remove dead increment.
[23:08] <CIA-41> ffmpeg: 03Clément BSsch 07master * rcb5bb521aa 10ffmpeg/libavformat/movenc.c: 
[23:08] <CIA-41> ffmpeg: lavf/movenc: use two explicit bytes instead of a short.
[23:08] <CIA-41> ffmpeg: This also avoids a pointless cast.
[23:08] <CIA-41> ffmpeg: Idea-by: Reimar Döffinger
[00:00] --- Thu Aug  9 2012