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.
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
script execution time: 55"
|
|
libavcodec 54. 86.100 wmv2 and mpeg4 decoders ignore this flag
(probably inside some dsp routine), provoking segfault.
Turning off direct rendering is a quick but nasty workaround.
If vo plugin can crop, we may drop that emulation without
performance penalty, and sometimes even speed up a little.
|
|
Prevent vo loop from calculating undefined aspect ratio
from _padded_ image size, leading to black bars and
unnecessary scaling.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://github.com/huceke/xine-lib-vaapi
|
|
get_buffer()
(merged from https://github.com/huceke/xine-lib-vaapi)
|
|
(merged from https://github.com/huceke/xine-lib-vaapi)
|
|
(merged from https://github.com/huceke/xine-lib-vaapi)
|
|
|
|
|
|
Fixes laming/freezing after manually stopping VP6 or WMV video.
That issue does not hit when we let the stream play to its end.
|
|
|
|
|
|
|
|
|