An obscure Japanese lossless video codec, originally intended
for use with a remote desktop application.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
We can't do this in general since we could be reading a file with B-frames while
lacking an index.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
In non-blocking mode, lowest-level read protocols are
supposed block only for a short amount of time to let
retry_transfer_wrapper() check for interrupts.
Also, checking the interrupt_callback in the receiving thread is
wrong, as interrupt_callback is not guaranteed to be thread-safe
and the job is already done by retry_transfer_wrapper(). The error
code was also incorrect.
Bug reported by Andrey Utkin.
This avoids problems
where avio_tell() returns 0. I've updated all the checks against
cluster_pos
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Allow up to 4 retries for normal requests, where both the
proxy and the target server might need to authenticate.
Signed-off-by: Martin Storsjö <martin@martin.st>
These commands are sent asynchronously, not waiting for the reply.
This reply is parsed later by ff_rtsp_tcp_read_packet or
udp_read_packet. If the reply indicates that we used stale
authentication and need to use a new nonce, resend a new keepalive
command immediately.
This is the only request sent asynchronously, so currently there's
no other command that needs to be resent in the same way.
Signed-off-by: Martin Storsjö <martin@martin.st>
According to video_file_format_spec_v10_1.pdf flv stores AAC RAW
thanks to Baptiste Coudurier for pointing that out
thanks to Aℓex Converse for explaining:
This can't be at the start of a non-ADTS payload. 111 is the
EndOfFrame syntax element.
Together these proof that the check was correctly rejecting ADTS which
is not supposed to be in flv. Many players are able to play such ADTS
in flv though but its better if we conform to the spec as this should
ensure that not many but all players can play files generated by ffmpeg.
This reverts commit 3c9a86df0e.
mpjpeg video streamings would break and stop on Firefox after 1 - 30
seconds.
In order to fix this, two changes were made:
1. Replaced all occurrences of '\n' character in mjpeg metadata
with occurences of "\r\n".
2. Added "Content-length: <packet-size>" metadata entry for each
sent frame.
The change has been tested on Google Chrome 17.0.963.78 and Firefox 10.0.2
on lubuntu 11.10 and the streaming seems to work fine now.
With this we can always know if a timestamp is based on added durations
from an unknown origin or if it is based on a correct timestamp (and possibly
added durations)
This should fix some bugs where this distinction was mixed up.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes sending back RTCP RR packets if receiving RTP over
multicast.
If the multicast stream is sent on demand (set up and signalled
via RTSP), the sender might depend on getting RTCP RR packets
knowing that there are listeners, otherwise the stream can be
closed after a certain timeout.
This fixes receiving RTSP streams over multicast on unix, from
certain Axis cameras.
Signed-off-by: Martin Storsjö <martin@martin.st>
When this code was added in 36b532815c, the new code was added
between the existing comment and the existing line of code, making
the old comment seem to refer to the new code. This makes it read
correctly.
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes trac #1045.
Thanks to Peter Ross for his help with this patch.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The ogg decoder wasn't padding the input buffer with the appropriate
FF_INPUT_BUFFER_PADDING_SIZE bytes. Which led to uninitialized reads in
various pieces of parsing code when they thought they had more data than
they actually did.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>