If adding the deinterlacer filter fails, try conversion filters
until we try something the deinterlacer wants, and then try again.
This fixes the problem where the input from the decklink module
(at least with --no-decklink-tenbits) is UYVY, while the deinterlacer only
wants planar formats.
Another possibility would be going straight for the format the
encoder wants, but often, this would be a 4:2:0 format, and 4:2:0
is pretty bad to deinterlace in, since the vertical chroma resolution
is gone already (the chroma interlacing in 4:2:0 is rather odd).
When the mux is capable of marking blocks as containing keyframes
(currently only the avformat mux), start new clients only on such
frames. This makes sure they do not get anything they might not
decode at the beginning of the stream.
Some browsers, such as Firefox, are very picky about WebM streams needing to
start with a keyframe. To be able to handle this correctly when streaming,
the avformat mux needs to mark keyframe-containing blocks (or clusters, in
Matroska terminology) as such even after they have been muxed. The next patch
in the series will make httpd actually care about this flag.
Unfortunately, as avformat does not actually propagate this status, we need
to use some heuristics to figure out which blocks contain keyframes. The natural
thing to do would be to say that when we write a keyframe, the block that comes
back has to be a keyframe block, but the WebM/Matroska muxer thwarts this by
having its own internal buffering of clusters, flushing the _previous_ cluster
when we send it a keyframe. In this case, we need to look at the _next_ cluster
after the one that comes back when we mux a keyframe.
I couldn't find a way to reliably autodetect this behavior (think for instance
about the audio packet caching that the WebM mux does), short of simply making
a list of such muxes and checking for them.
The previous value, 32 kB, causes formats like WebM to overflow
and split the blocks, which has negative consequences for streaming.
We're unlikely to have a memory crunch in this area, so increase it
to something generous.
avformat mux: Propagate seekable status into avformat.
Some muxes, in particular mkv/webm, behave very differently depending on
whether we say that the stream is seekable or not (by providing the IOSeek
function). It does not help that the seek function itself returns an error.
Thus, add a new access_out control called ACCESS_OUT_CAN_SEEK, set to true
for the file output only, and propagate the status of that into avformat
at initialization time.
Xiph: support TRACKNUMBER=xx/xx in vorbis comments
Yeah, yeah, such a clever idea, thx...
Let' not use TRACKTOTAL or TOTALTRACKS or TOTALTRACK or TRACKSTOTAL,
because you know, there is not enough options...
Oh, and let's not make ANY of the above official in the spec, because
then, people could follow the spec...
https://www.xiph.org/vorbis/doc/v-comment.html
Martin Storsjö [Mon, 29 Jul 2013 18:58:24 +0000 (21:58 +0300)]
androidsurface: Support cropping
Since b71c85b3d88b8d, the output from the avcodec video decoder
requires the vout to handle the cropping. This uses an updated
version of the jni_SetAndroidSurfaceSize function to be able to
pass the visible size separately from the full size.
Gleb Pinigin [Fri, 2 Aug 2013 12:41:55 +0000 (19:41 +0700)]
vout_ios2: take into account scale of attached screen
As said in Apple documentation drawRect should not be implemented for view based on opengl es layer.
Instead contentScaleFactor should be changed manually if needed. Underlying opengl es layer will adjust its scale accordingly.
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>
Martin Storsjö [Mon, 29 Jul 2013 07:55:42 +0000 (10:55 +0300)]
androidsurface: Only use ANativeWindow if the private symbols aren't found
Even if ANativeWindow is a public API, the release call seems to
crash on a Nexus One (running 2.3) and on a Galaxy Tab (running 3.2).
The exact reason is not known or understood yet, but it might be
due to accessing and dealing with the Surface from both Java (via the
SurfaceHolder class) and via the ANativeWindow API.
Therefore, only use the ANativeWindow if the old methods aren't
found (that is, on 4.3).
The ANativeWindow output works fine on firmwares as early as 4.0
though.
Martin Storsjö [Tue, 23 Jul 2013 13:58:36 +0000 (16:58 +0300)]
audiounit_ios: Fill the remainder of the buffer with zeros
If we didn't have enough data to fill the buffer, fill the rest
of it with zeros. This is better than playing back whatever happened
to be there from before.
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>
Stopping the aout from within the callback like this could
lead to deadlocks, where AudioOutputUnitStop in the callback thread
and AudioOutputUnitStart in the audio decoder thread blocked each
other (noticed at startup of playback on a 3GS with iOS 6.0).
Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>