Previously, the bug was that if -1 < start_time < 0, the reported
"start" time would lose the negative-sign.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '7e01d48cfd168c3dfc663f03a3b6a98e0ecba328':
mov: Check the entries value when parsing dref boxes
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Broke a lot of stuff and didn't fix anything.
This reverts commit 3c461eecd4, reversing
changes made to 884dd175f0.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '3e8fd93b6ab219221e17fa2b6243cc72cf2d69dc':
lavf: add a missing bump and APIchanges for the codecpar switch
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
* commit 'fa55addd23c2f168163175aee17adb125c2c0710':
img2: Drop av_ prefix for a static function
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It will be used by text subtitle demuxers to construct format instructions
straight into extradata. They all currently a similar function that accepts
an AVCodecContext instead.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
WAV is not a NOHEADER format, and thus should not be changing
stream codec IDs and probing in read_packet.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Original mail and my own followup on ffmpeg-user earlier today:
I have a device sending out a MJPEG/RTP stream on a low quality setting.
Decoding and displaying the video with libavformat results in a washed
out, low contrast, greyish image. Playing the same stream with VLC results
in proper color representation.
Screenshots for comparison:
http://zevv.nl/div/libav/shot-ffplay.jpghttp://zevv.nl/div/libav/shot-vlc.jpg
A pcap capture of a few seconds of video and SDP file for playing the
stream are available at
http://zevv.nl/div/libav/mjpeg.pcaphttp://zevv.nl/div/libav/mjpeg.sdp
I believe the problem might be in the calculation of the quantization
tables in the function create_default_qtables(), the attached patch
solves the issue for me.
The problem is that the argument 'q' is of the type uint8_t. According to the
JPEG standard, if 1 <= q <= 50, the scale factor 'S' should be 5000 / Q.
Because the create_default_qtables() reuses the variable 'q' to store the
result of this calculation, for small values of q < 19, q wil subsequently
overflow and give wrong results in the calculated quantization tables. The
patch below uses a new variable 'S' (same name as in RFC2435) with the proper
range to store the result of the division.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Adding early support for a subset of the proposed colour elements
according to the latest version of spec:
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=hIKLhMdgTMTEwUTeA4ct38h0tmE
Like matroskadec, I've left out elements for pix_fmt related things
as there still seems to be some discussion around these.
The new elements are exposed under strict experimental mode.
Signed-off-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
