Now that the seek only happens with the right mouse button, it makes
sense to toggle full screen when double-clicking with the left mouse
button, like other video players do.
Signed-off-by: Vittorio Gambaletta <ffmpeg-dev@vittgam.net>
Signed-off-by: Marton Balint <cus@passwd.hu>
Seeking by clicking on the video window can be annoying, because
the user might click on it accidentally while eg. trying to get
focus on it, and ffplay seeks instead.
This commit changes that behaviour to seek only when the right
mouse button is used to click and drag on the window.
Signed-off-by: Vittorio Gambaletta <ffmpeg-dev@vittgam.net>
Signed-off-by: Marton Balint <cus@passwd.hu>
It serves absolutely no purpose other than to confuse potentional
Android developers about how to use hardware acceleration properly
on the the platform. The stagefright "API" is not public, and the
MediaCodec API is the proper way to do this.
Furthermore, stagefright support in avcodec needs a series of
magic incantations and version-specific stuff, such that
using it actually provides downsides compared just using the actual
Android frameworks properly, in that it is a lot more work and confusion
to get it even running. It also leads to a lot of misinformation, like
these sorts of comments (in [1]) that are absolutely incorrect.
[1] http://stackoverflow.com/a/29362353/3115956
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
support reading encrypted mp4 using aes-ctr, conforming to ISO/IEC
23001-7.
a new parameter was added:
- decryption_key - 128 bit decryption key (hex)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This solves the problem discussed in https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by which a muxer can add a bitstream filter to a
stream automatically, rather than prompting the user to do so.
support writing encrypted mp4 using aes-ctr, conforming to ISO/IEC
23001-7.
3 new parameters were added:
- encryption_scheme - allowed values are none (default) and cenc-aes-ctr
- encryption_key - 128 bit encryption key (hex)
- encryption_kid - 128 bit encryption key identifier (hex)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Having a configure option with the same name as a MIPS ISA is confusing,
so better to remove it. This option was being used to add some
optimizations to a specific core (i6400). We will add the optimizations
just when the i6400 core has been detected, in a later patch.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Having a configure option with the same name as a MIPS ISA is confusing,
so better to remove it. This option was being used to add some
optimizations to a specific core (p5600). We will add the optimizations
just when the p5600 core has been detected, in a later patch.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '4a0918cae6394e503b17c71f8f171b4a795eb849':
sgienc: Support encoding high bit depth images with RLE
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'fb472e1a11a4e0caed2c3c91da01ea8e35d9e3f8':
avconv: add support for Intel QSV-accelerated transcoding
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This finalizes merging of the work in the patches in ticket #2686.
Improvements to twoloop and RC logic are extensive.
The non-exhaustive list of twoloop improvments includes:
- Tweaks to distortion limits on the RD optimization phase of twoloop
- Deeper search in twoloop
- PNS information marking to let twoloop decide when to use it
(turned out having the decision made separately wasn't working)
- Tonal band detection and priorization
- Better band energy conservation rules
- Strict hole avoidance
For rate control:
- Use psymodel's bit allocation to allow proper use of the bit
reservoir. Don't work against the bit reservoir by moving lambda
in the opposite direction when psymodel decides to allocate more/less
bits to a frame.
- Retry the encode if the effective rate lies outside a reasonable
margin of psymodel's allocation or the selected ABR.
- Log average lambda at the end. Useful info for everyone, but especially
for tuning of the various encoder constants that relate to lambda
feedback.
Psy:
- Do not apply lowpass with a FIR filter, instead just let the coder
zero bands above the cutoff. The FIR filter induces group delay,
and while zeroing bands causes ripple, it's lost in the quantization
noise.
- Experimental VBR bit allocation code
- Tweak automatic lowpass filter threshold to maximize audio bandwidth
at all bitrates while still providing acceptable, stable quality.
I/S:
- Phase decision fixes. Unrelated to #2686, but the bugs only surfaced
when the merge was finalized. Measure I/S band energy accounting for
phase, and prevent I/S and M/S from being applied both.
PNS:
- Avoid marking short bands with PNS when they're part of a window
group in which there's a large variation of energy from one window
to the next. PNS can't preserve those and the effect is extremely
noticeable.
M/S:
- Implement BMLD protection similar to the specified in
ISO-IEC/13818:7-2003, Appendix C Section 6.1. Since M/S decision
doesn't conform to section 6.1, a different method had to be
implemented, but should provide equivalent protection.
- Move the decision logic closer to the method specified in
ISO-IEC/13818:7-2003, Appendix C Section 6.1. Specifically,
make sure M/S needs less bits than dual stereo.
- Don't apply M/S in bands that are using I/S
Now, this of course needed adjustments in the compare targets and
fuzz factors of the AAC encoder's fate tests, but if wondering why
the targets go up (more distortion), consider the previous coder
was using too many bits on LF content (far more than required by
psy), and thus those signals will now be more distorted, not less.
The extra distortion isn't audible though, I carried extensive
ABX testing to make sure.
A very similar patch was also extensively tested by Kamendo2 in
the context of #2686.
