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>
(cherry picked from commit e3e6a2cff4af9542455d416faec4584d5e823d5d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Simplifies code
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 50d017a28171177b89c367194ec8d02f963e7e9e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes Ticket5287
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit efa98cdc2ff17a2f3b0ceb69e22864fd5bc433db)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit b2ab3398f59ed18a565063584f961ff84484d699)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is safer, as a selected demuxer could still mean that it was auto-detected
by a user application
Reviewed-previously-by: Nicolas George <george@nsup.org>
Reviewed-previously-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 689211d5727231c3fe92762d224dbadebdbf4e30)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit de1de4932419d0fb49c9c23f62e68cdbe90d0ee3)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
RTCP synchronization packet was broken since commit in ffmpeg version > 2.8.3
(commit: e04b039b1528f4c7df5c2b93865651bfea168a19) Since this commit (2e814d0329aded98c811d0502839618f08642685)
"rtpenc: Simplify code by introducing a macro for rescaling NTP timestamps", NTP_TO_RTP_FORMAT
uses av_rescale_rnd() function to add the data to the packet.
This causes an overflow in the av_rescale_rnd() function and it will return INT64_MIN.
Causing the NTP stamp in the RTCP packet to have an invalid value.
Github: Closes#182
Reverting commit '2e814d0329aded98c811d0502839618f08642685' solves the problem.
(cherry picked from commit 1109ed7973c7fd1e7001898adc4976590d862122)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found-by: jamrial
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 554f6e930ce05a4c5449efcaae36bdafe2d9de74)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I discovered that ffserver streaming was broken (it seems like it has been since 20th November) and I opened a ticket for this (https://trac.ffmpeg.org/ticket/5250 <https://trac.ffmpeg.org/ticket/5250>).
I spent yesterday learning git bisect (with the kind help of cehoyos) to painstakingly track down the cause. This was made more difficult due to the presence of a segfault in ffserver during the period where the bug was introduced so I first had to identify when and how that was fixed and then retrospectively apply that fix again for each step of the second git bisect to find the actual bug.
Anyway, the fruits of my labour are the innocent looking patch below to correct a couple of typos and define a valid range for two variables.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit a2f8beef2dfaee573f7c4a607afaa9e83fc2c1e0)
This avoid "libavformat/genh.c:43:14: warning: variable coef_splitted set but not used"
Fewer warnings makes it easier to see new and important warnings
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently it is broken when explicitly using the file protocol, it uses an
insecure temporary file name, and in commit b4431c80 disabling the option by
default was already considered. Also it is not very consistent to have such an
option for one particular muxer.
Signed-off-by: Marton Balint <cus@passwd.hu>
This also deprecates our old duplicated callbacks.
* commit '9f61abc8111c7c43f49ca012e957a108b9cc7610':
lavf: allow custom IO for all files
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The UUID is based on http://www.adobe.com/devnet/xmp.html
The patch is made according to XMP SPECIFICATION PART 3 - STORAGE IN
FILES See Table 8
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Silences: CID1351343
The header is calculated by the code above the changed hunk, it is
thus asserted that the header is always correct.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This can provide a manual workaround for ticket #4230.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
Checked compatiblity with VLC, Windows Media Player 12 and Windows Media ASF
Viewer 9 series.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
Note to maintainers: update tools
Note to maintainers: set a default whitelist for your protocol
If that makes no sense then consider to set "none" and thus require the user to specify a white-list
for sub-protocols to be opened
Note, testing and checking for missing changes is needed
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit 8ed82d8174a666f80ab8834e3617cbe91ae740a9.
SMPTE S377-1-2009c defines in F.4.1 that the Video Line Map should
always be an array with two 32 bit integers as elements. This is
repeated in G.2.12 with actual examples for progressive content,
where the second value would always be 0.
Additionally, the IRT MXF analyser also lists this as the only
error in the MXF output from ffmpeg: https://mxf-analyser-cloud.irt.de
Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
