| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This slightly increases file size due to needless downscaling on the device due
to aspect correction, but keeps quality as is and prevents encoding errors
caused by odd height/width.
|
|
|
|
|
| |
Lower-fps content is left alone (NOT aligned to this fps); higher fps
content is decimated to this frame rate.
|
|
|
|
|
| |
libx264 rejects the other pixel formats when doing baseline H.264,
although libavcodec accepts them, leading to an encoding abort.
|
|
|
|
|
| |
vorbis is the builtin bad vorbis encoder; whenever possible, one should
rather use the "libvorbis" codec name.
|
|
|
|
|
|
|
| |
In some cases (when using tune=animation as an additional option), the
N900 profile caused use of 6 reference frames, where Level 3.0 only
allows 5 reference frames. This prevented playback on the Nokia N900.
This has been fixed by always specifying refs=5.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This yields generally smaller files, by avoiding upscaling at all times.
This method may or may not be useful for iOS, needs testing there.
Note: this uses three instances of vf_scale:
1. Scale to target dimensions, ONLY if both are <= original video
dimensions.
2. Failing that, scale to width*<calculated height by display aspect>,
ONLY if <calculated height by display aspect> <= original video
height.
3. Failing that, scale to <calculated width by display aspect>*height.
When the test before failed, we KNOW that <calculated width by
display aspect> <= original video width.
So basically, only one of the three scalers should ever be active, as
the last two scalers only can ever have an effect if the aspect ratio
mismatches the video.
As for danger of roundoff errors:
If scaler 1 succeeded, we have won. Scalers 2 and 3 will never do
anything, because display resolution == video resolution. Here it is
crucial that no rounding of video size to display size takes place; in
other words, the target display size already MUST be even, which it is
because we pass 2 to the rounding parameter of the dsize filter.
Scaler 2 and 3 are obviously mutually exclusive, as they depend on
opposite aspect ratio conditions.
We later should put this functionality directly into vf_scale...
|
|
|
|
|
| |
Nokia N900 is simply H.264 Baseline, level must be forced to 3.0, at
max. display resolution. There is no pan-scan like on iOS.
|
|
|
|
|
| |
The iPhone profiles recursively included themselves. Wonder why it even
worked somewhat...
|
|
|
|
| |
The names are left as is, but they are hierarchic internally now.
|
|
|
|
| |
Fixes issue #10.
|
|
|
|
|
| |
Now the scaling for iPhones properly optimizes for the zoomed-in
(pan-scan) view.
|
|
|
|
|
| |
Now the enc-to-iphone profiles no longer specify the aac bitrate
explicitly (128k), but take over the default from enc-a-aac (96k).
|
|
|
|
|
| |
Previously it used 128kbps libfaac by default, but now that we have
libfdk_aac, we can default to 96kbps at better quality than before.
|
|
|
|
| |
global_quality would need an extra multiplication by QP2LAMBDA otherwise
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the name of this project to mpv. Most user-visible mentions
of "MPlayer" and "mplayer" are changed to "mpv". The binary name and the
default config file location are changed as well.
The new default config file location is: ~/.mpv/
Remove etc/mplayer.desktop. Apparently this was for the MPlayer GUI,
which has been removed from mplayer2 ages ago.
We don't have a logo, and the MS Windows resource files sort-of require
one, so leave etc/mplayer.ico/.xpm as-is.
Remove the debian and rpm packaging scripts. These contained outdated
dependencies and likely were more harmful than useful. (Patches which
add working and well-tested packaging are welcome.)
|
|
|
|
|
| |
ffmpeg also does libvo_aacenc (libfaac level) and libfdk_aac (supposedly
great).
|
|
|
|
|
|
| |
This allows to define which stream is to be used as first output stream.
This is useful because dvdauthor refuses VOB files where the audio
stream is the first stream.
|
|
|
|
|
|
| |
This is ok, because the iPhone can handle any resolution. So there is no
need to waste space on upscaling the iPhone can do at playback time as
well.
|
|
|