| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
Originally committed as revision 18002 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 18001 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 18000 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17999 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17998 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17996 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
discussion in the ML thread "[PATCH] rmdec.c: merge old/new packet reading
code".
Over time, this code broke somewhat, e.g. seq was never actually written
into (and was thus always 1, therefore the seq condition was always true),
whereas it was supposed to be set to the sequence number of the video slice
in case the video frame is divided over multiple RM packets (slices). The
problem of this is that packets other than those containing the beginning
of a video frame would be indexed as well.
Secondly, flags&2 is supposed to be true for video keyframes and for these
audio packets containing the start of a block. For some codecs (e.g. AAC),
that is every single packet, whereas for others (e.g. cook), that is the
packet containing the first of a series of scrambled packets that are to be
descrambled together. Indexing any of the following would lead to incomplete
and thus useless frames. Problem here is that flags would be reset to 2 to
indicate that the first packet is ready to be returned, and in addition if
no data was left to be returned (which is always true for the first packet),
then we wouldn't actually write the index entry anyway.
All in all, the idea was good and it probably worked at some point, but that
is long ago. This patch should at the very least make it likely for this code
to be executed again at the right times, i.e. the way it was originally
intended to be used.
Originally committed as revision 17993 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17981 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17980 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17979 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17976 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17975 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17972 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17971 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17969 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17968 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17967 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17966 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17965 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
| |
seeking before data_offset and is more consistent with how the generic index
seeking code handles it.
Originally committed as revision 17964 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17959 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17956 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17953 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17952 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17946 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
| |
pre-parsing the file in read_header.
This avoids some code duplication and seeking, and also avoids an IO error
for small video-only files (as created during e.g. the FATE encoder test).
Originally committed as revision 17945 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17940 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17939 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17938 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17937 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17936 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17935 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17933 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17932 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17929 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17928 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
| |
and if the size is broken (20 bytes, header-only), calculate the expected
size and skip the index entries anyway. See "[PATCH] rmdec.c: correctly
skip indexes" thread.
Originally committed as revision 17924 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
|
|
|
| |
has two possible outcomes: either len and rm->remaining_len are the same, in
which case we care about the outcome and it is zero, or rm->remaining_len is
currently not in use and we don't care about the outcome. In that case, len
is positive and rm->remaining_len is zero, which leads to a negative result.
This is confusing and could eventually lead to a sign-flip if we skip a lot
of packets (unlikely, but still). Therefore, just always set it to zero.
Originally committed as revision 17919 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17918 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
move MOVContext from mov.c to isom.h" thread on ML.
Originally committed as revision 17915 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
consistent with av_fifo_generic_write.
Originally committed as revision 17914 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
|
|
|
| |
has two possible outcomes: either len and rm->remaining_len are the same, in
which case we care about the outcome and it is zero, or rm->remaining_len is
currently not in use and we don't care about the outcome. In that case, len
is positive and rm->remaining_len is zero, which leads to a negative result.
This is confusing and could eventually lead to a sign-flip if we skip a lot
of packets (unlikely, but still). Therefore, just always set it to zero.
Originally committed as revision 17910 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
| |
ff_rm_parse_packet(). See "[PATCH] Make RM demuxer behave better with -an
option" thread, which sort-of turned into an aggregate of unrelated rmdec.c
cleanups.
Originally committed as revision 17909 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
|
|
|
| |
rm->audio_pkt_cnt in case multiple packets should be read before the next
syncpoint in the file, so that ffplay -an on a file containing AAC audio
works. See "[PATCH] Make RM demuxer behave better with -an option" thread
on mailinglist.
Originally committed as revision 17908 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
For proper seeking, they should be set correctly though.
Originally committed as revision 17907 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
|
|
| |
not 0 in av_seek_frame_generic.
Originally committed as revision 17905 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17904 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17898 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17896 to svn://svn.ffmpeg.org/ffmpeg/trunk
|
|
|
|
| |
Originally committed as revision 17895 to svn://svn.ffmpeg.org/ffmpeg/trunk
|