| Age | Commit message (Collapse) | Author |
|---|
|
And do flush via a separate AVFrame.
Maybe this fixes some rare race.
BTW. libavcodec 56 left an ambigous impression to me.
It does now respect flush requests even in multithread mode. Good.
On the flipside, that "too many DR1 frames in MPEG-TS" issue returned.
The very same stream needed between 7 and 17 frames, depending on the
start time of playback :-/
Also, the future of MPEG4 style postprocessing seems uncertain again.
|
|
|
|
Some MPEG-TS streams dont align ADTS to TS-PES,
pad ADTS frames to (nearly) fixed bitrate, and/or
wrongly flag all this as LATM.
Now the probing is more safe against ambigous input.
Somebody please test whether this still breaks real LATM.
|
|
|
|
HD color matrix (ITU-R 709/SMTE 240) serves to provide a bit more depth
at least for greens where it strikes the most. Having more than 8 bits
for real makes this trick obsolete, so deep color defaults to good old
SD mode. Bad thing: now we need real support in video out to benefit.
Has anyone got an idea how to integrate that into xine video out API
(capability flags are nearly used up)?
I found some UHD tests on Astra 19.2°E 11.406GHz V 22Msym/s 2/3 8PSK
and 10.995GHz 22Msym/s 9/10 8PSK showing this.
|
|
Fixes truncating timestamps
|
|
Some MPEG-TS streams dont align ADTS to TS-PES,
pad ADTS frames to (nearly) fixed bitrate, and/or
wrongly flag all this as LATM.
Somebody please test whether this breaks real LATM.
|
|
After putting this little diff to my old Kaffeine:
- - - kaffeine-1.2.2/src/dvb/dvbsi.cpp 2011-04-17 21:17:19.000000000 +0200
+ + + kaffeine-1.2.2/src/dvb/dvbsi.cpp 2014-08-24 15:41:08.000000000 +0200
@@ -1206,6 +1206,7 @@ DvbPmtParser::DvbPmtParser(const DvbPmtS
case 0x02: // MPEG2 video
case 0x10: // MPEG4 video
case 0x1b: // H264 video
+ case 0x24: // H265 video
if (videoPid < 0) {
videoPid = entry.pid();
} else {
I stumbled upon "UHD TV" on Astra 19.2E, 11.406Ghz V, 22000, 2/3, 8-PSK, 0.35,
Video PID 255.
DSP version? Anyway, my box is far too slow for 3840x2160p50 H.265 10bit :-/
|
|
|
|
|
|
|
|
Rename var to avoid possible macro name collision.
|
|
|
|
Make sure thread count is sane.
|
|
Avoid rv30/rv40 heap corruption after reading
bitstream from invalid location.
BTW. Should ff better be more robust there as well?
|
|
Avoid H.265 image size pumping on x86, for example.
This really is a workaround for an ff bug.
They should issue emms when done with a frame instead.
|
|
|
|
This one seems to prevent "too many DR1 frames" freezes on heavy seeking.
|
|
|
|
|
|
|
|
This happens when multithreading, for example.
|
|
Re-enable DR1 for suitably sized video when vo does not crop.
So, this one is tested with 4k vp9 video on both
AMD Athlon x2 and AMD FX x6. Seems these boxes throw
ordinary segfaults not bus errors on misaligned data.
Anyway, vp9 soft decoding is terribly slow still.
BTW. H.265 and probably vp9 allow variable size macroblocks
up to 64 squared luma pixels. For some reason, ffmpeg still
wants only 16 pixel edges ??
|
|
Try not to add a lot of extra padding.
|
|
|
|
|
|
|
|
OK, I have seen it :-)
|
|
|
|
|
|
|
|
|
|
There are deprecated fields still in use here.
|
|
|
|
BTW. Happy 2014 to you!
Didnt think xine will survive this far :-)
And yes, I finally got an ffmpeg patch through. That kind of rounds the circle :-)
|
|
HG #12298 + #12335 obsolete the decoder side #define's.
Tweaking libavcodec.h after building that lib may be risky or
future useless anyway.
|
|
Less audio fifo load (remember those bufs held for resending after user audio switch).
Used by qt so far.
|
|
|
|
Dont output 1920x1080 as MB padded 1920x1088, for example.
And make code more readable.
BTW. VAAPI handles padding internally,
and only needs to know the pure visible size?
|
|
|
|
|
|
AVFrame.qscale_table had been deprecated at the same time.
|
|
|
|
Lavc v54,55 seems to ignore request_sample_fmt anyway,
but that need not stay that way forever.
|
|
|
|
|
|
|
|
|
|
|
|
|
