Firstly 32 MB is not that much with HD video and the different
values depending on whether CONFIG_TV_BSDBT848 is set or not
makes debugging harder.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@28190 b3059339-0415-0410-9bf9-f77b7e298cf2
cameras do produce such huge packets.
Requested by Alexandre Poltorak
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27810 b3059339-0415-0410-9bf9-f77b7e298cf2
it is used. Fixes the following warning:
./libmpdemux/asfguid.h:94: warning: 'find_backwards_asf_guid' defined but not used
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27723 b3059339-0415-0410-9bf9-f77b7e298cf2
Undo Aurelien's previous commit which made the lavf demuxer the
default. SSA/ASS subtitles do not work properly with the lavf demuxer
at the moment. That's much more important than any issues with the
internal demuxer. The internal demuxer must remain the default at least
until the subtitle issues are resolved.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27556 b3059339-0415-0410-9bf9-f77b7e298cf2
Change the default demuxer back to the internal one at least until the
current lavf breakage with SSA/ASS subtitles is sorted out. There have
also been quite a few other regressions so maybe the lavf demuxer
should be tested a bit more before trying to make it the default again.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27551 b3059339-0415-0410-9bf9-f77b7e298cf2
The following commits are reverted partially or completely:
"a valid ASS line contains 9 ',' before actual text"
"demux_mkv: output correctly formated ASS packets"
"libass: add a new ass_process_data() to process demuxed subtitle packets"
These commits converted the internal representation of SSA/ASS
subtitle packets from the format used by Matroska to a custom format
where each packet has contents exactly matching one line in complete
SSA script files. AFAIK no files natively use such a format for muxed
subtitles. The stated reason for this change was to use a format that
could in principle be muxed into a maximal number of containers. SSA
subtitles do not have an implicit duration so both start time and
duration or end time need to be specified explicitly; the new format
moved timing information inside the codec packet data so it could be
muxed without modification into containers that can represent only
start time at the container level. However such a change is wrong from
the viewpoint of program architecture. Timing information belongs to
the demuxer level, but these commits moved not only the duration but
also the authoritative value of the start time to inside the codec
data. Additionally the new format lost the value of the Matroska
ReadOrder field which is used by MPlayer.
This commit changes the internal packet format back to that used by
Matroska and makes the internal Matroska demuxer output that format
again. Libavformat still outputs the "new" format; it could be
converted back to the Matroska format in demux_lavf.c, but I'm not
adding that code at least yet. The current lavf code has similar
problems as the reverted code in MPlayer, and it also currently fails
to provide any way to access the value of the ReadOrder field. I hope
that the lavf side will be improved; if it isn't conversion can be
added later. For now I'll make MPlayer default to the internal Matroska
demuxer instead of the lavf one in a separate commit.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27550 b3059339-0415-0410-9bf9-f77b7e298cf2
Some symbols were dropped or renamed, requiring corresponding changes
in MPlayer.
- Use AVCodecContext->bits_per_coded_sample instead of ->bits_per_sample.
- Use AVCodecContext->trellis instead of ->flags&CODEC_FLAG_TRELLIS_QUANT.
- Don't set AVCodecContext->rtp_mode (already marked unused before).
- Use ff_eval2() instead of ff_eval().
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27548 b3059339-0415-0410-9bf9-f77b7e298cf2
I can't spot any regression anymore. If you find one, please tell me.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27484 b3059339-0415-0410-9bf9-f77b7e298cf2
When trying to seek past the end of file, the ByteIOContext expect
that the stream is left in the same state as it was before the
tentative seek. stream_seek() does not meet this expectation.
It changes current position when seeking past the end of file.
Thus, it is necessary to reset the stream to its previous state
after a seek failure.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@27459 b3059339-0415-0410-9bf9-f77b7e298cf2
nicodvb
reimar
diego
ods15
aurel
attila
cehoyos
gpoirier
uau
compn