Video Haltiness Multiple Times/Second

[Stephen Warren]

Originally Posted by Quantumstate

- The stream discontinuities are not being addressed. Are you saying that your mplayer is using the latest ffmpeg? And that any Myth in existence will not be able to cope well with stream discontinuities?

Yes, my MPlayer (and hence ffmpeg/libavcodec) are SVN versions from within the last week or two.

Originally Posted by Quantumstate

- I thought that ffmpeg isn't even in the mix with Myth and Mplayer. I thought that only a subcomponent of ffmpeg (libavcodec) was what is integrated. And that libavcodec compiled into mythtv-fixes and Mplayer is much newer than the stock ffmpeg one.

I use ffmpeg and libavcodec interchangably; it's quite possibly MythTV only uses the libavcodec sub-directory of ffmpeg. And no, MythTVs versions are quite old as I explained.

Originally Posted by Quantumstate

- The Dish transport stream (with its slight differences) is not even being considered by anyone. (referenced sample) This is a concern for three reasons:
a. It is more likely to have stream discontinuities than a DVD program stream; and
b. I would like to clean the TS to a PS with a tool like avidemux, but avidemux can't understand the indexing in a Dish TS. The developer is indifferent, as is apparently jyavenard (VDPAU patch) since he doesn't seem to grasp the problem.
c. Sure not many ppl get the pure TS from sat providers, but I am on the cutting-edge. This has such technical merit that it has to take off and so apps should be able to accommodate.

I don't doubt there are extra nuances to handling Dish streams. However, I'm sorry to say this is outside the realm of VDPAU; VDPAU deals with the PES stream after it's been extracted from the container. VDPAU should handle compliant H.264 streams. Either the dish PES stream is H.264 compliant or it isn't.

[Quantumstate]

Originally Posted by Stephen Warren

I use ffmpeg and libavcodec interchangably; it's quite possibly MythTV only uses the libavcodec sub-directory of ffmpeg. And no, MythTVs versions are quite old as I explained.

OK, I'm wondering now (and I don't expect you to know this as it's out of your realm) whether the SVN mythtv-fixes I compile, reaches out to the system for libavcodec (ffmpeg) includes, like Mplayer apparently does?

I would guess not, as I've 'apt-get build-deps mythtv' and it did not install the libavcodec-dev includes. This implies that Myth does come with its own (old) libavcodec. Maybe they don't do this because sundry libavcodecs can bung up the Myth compile, so they use a known working one? But what a sacrifice to not use a lib that's improving so much over time.

I wonder whether I could graft in a newer libavcodec? There is in fact a libavcodec dir under mythtv/libs, a libavformat, and a libavutil; I'll bet they have to be at the same rev.
If it were this easy though, I'll bet jyavenard would have tried it. Tempted...
jyavenard would say I don't know what I'm talking about, but this is the method of scientific investigation, and it looks to me like few others have thought of this. I doubt he's inclined to help at all since he's been so pissed lately...

Originally Posted by Stephen Warren

I don't doubt there are extra nuances to handling Dish streams. However, I'm sorry to say this is outside the realm of VDPAU; VDPAU deals with the PES stream after it's been extracted from the container. VDPAU should handle compliant H.264 streams. Either the dish PES stream is H.264 compliant or it isn't.

Interesting. So apparently Myth (or VDPAU) discards the extra housekeeping packets and other extra falderal in a sat transport stream, and deals only with the video and audio packets.

Mplayer VDPAU plays fine whereas Myth-fixes-VDPAU can't cope with stream discontinuities. Apparently the problem isn't that it's a sat transport stream... but that the VDPAU patch to Myth is more intolerant than the VDPAU patch to Mplayer is, for some reason. The inference I get from you is maybe it's the old libraries.

[Stephen Warren]

Originally Posted by Quantumstate

OK, I'm wondering now... whether the SVN mythtv-fixes I compile, reaches out to the system for libavcodec (ffmpeg) includes, like Mplayer apparently does?

MythTV will only look at its internal copy of ffmpeg libs. Apparently, some modifications are required to ffmpeg to get it to work with MythTV; that's why using arbitrary system versions isn't possible, and upgrading the internal copy is slightly non-trivial.

[Quantumstate]

Yeah, in compiling my (lib improved) mythtv-fixes.20445 it hauls ass through libavformat, libavutil, and libavcodec, but when it gets to libmythsoundtouch:

 ccache g++ -c -pipe -g -march=k8 -fomit-frame-pointer -O3 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wno-non-virtual-dtor -D__STDC_CONSTANT_MACROS -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fPIC -DPIC -w -D_REENTRANT  -DMMX -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_TABLET_SUPPORT -I/usr/share/qt3/mkspecs/default -I. -I../../../../../include -I../../../../../../include -I../../libs/libavcodec -I../.. -I../../../../../../include/qt3 -o cpu_detect_x86_gcc.o cpu_detect_x86_gcc.cpp
ccache g++ -c -pipe -g -march=k8 -fomit-frame-pointer -O3 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -Wno-non-virtual-dtor -D__STDC_CONSTANT_MACROS -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -fPIC -DPIC -w -D_REENTRANT  -DMMX -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -DQT_SHARED -DQT_TABLET_SUPPORT -I/usr/share/qt3/mkspecs/default -I. -I../../../../../include -I../../../../../../include -I../../libs/libavcodec -I../.. -I../../../../../../include/qt3 -o mmx_gcc.o mmx_gcc.cpp
mmx_gcc.cpp: In member function ‘virtual long int soundtouch::TDStretchMMX::calcCrossCorrStereo(const short int*, const short int*) const’:
mmx_gcc.cpp:89: error: ‘mmx_t’ was not declared in this scope
mmx_gcc.cpp:89: error: ‘pv1’ was not declared in this scope
mmx_gcc.cpp:89: error: expected primary-expression before ‘)’ token
mmx_gcc.cpp:89: error: expected `;' before ‘pV1’
mmx_gcc.cpp:94: error: ‘mm1’ was not declared in this scope
mmx_gcc.cpp:94: error: ‘movq_a2r’ was not declared in this scope
mmx_gcc.cpp:95: error: ‘mm2’ was not declared in this scope
mmx_gcc.cpp:97: error: ‘mm5’ was not declared in this scope
mmx_gcc.cpp:97: error: ‘movd_v2r’ was not declared in this scope
mmx_gcc.cpp:103: error: ‘pv2’ was not declared in this scope
mmx_gcc.cpp:103: error: ‘pmaddwd_a2r’ was not declared in this scope
mmx_gcc.cpp:104: error: ‘mm3’ was not declared in this scope
mmx_gcc.cpp:106: error: ‘mm4’ was not declared in this scope
mmx_gcc.cpp:122: error: ‘pv2’ was not declared in this scope
mmx_gcc.cpp:122: error: ‘pmaddwd_a2r’ was not declared in this scope
... etc

I wonder if I can disable soundtouch? Nah, it's probably integral to sound speed control.

I tried disabling mmx just to get through, but same error. Probably just needs some sort of #include statement. But I'd never figure it out; I'm a real estate developer, not a coder.

Here is my procedure:
- svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
- Delete mythtv/libs subdirectories: libavcodec, libavformat and libavutil
- Copy ffmpeg subdirectories: libavcodec, libavformat and libavutil into mythtv/libs
- Copy ffmpeg files: common.mak, config.mak, and subdir.mak into mythtv/libs
- ln -s mythtv/libs/libavcodec/x86 mythtv/libs/libavcodec/i386
- ./configure --enable-proc-opt --enable-vdpau --enable-xvmc-opengl --enable-opengl-video --enable-opengl-vsync --disable-xvmcw --disable-directfb --disable-joystick-menu --disable-ivtv --disable-firewire --disable-dbox2 --disable-hdhomerun --disable-audio-oss
- make -j 4

[Quantumstate]

OK, it seems clear that there are numerous fiddly changes that need to be made in order to flange in the new libraries... if in fact old libraries are the cause. Other possibilities are the VDPAU patch for Mythtv-fixes and the VDPAU driver itself.

Looks like ppl are out of luck WRT satellite HD streams.