[mythtv-users] Varying data formats during digital reception
JP Moitinho de Almeida
moitinho at civil.ist.utl.pt
Tue Nov 6 21:08:22 UTC 2012
On Tuesday 06 November 2012 19:03:27 John Pilkington wrote:
> On 06/11/12 18:49, Mike Perkins wrote:
> > On 06/11/12 17:34, Jose Paulo Moitinho de Almeida wrote:
> >> On Tuesday 06 November 2012, Mark Greenwood wrote:
> >>> On Tuesday 06 Nov 2012 08:09:25 Gary Buhrmaster wrote:
> >>>> On Tue, Nov 6, 2012 at 6:29 AM, Mark Greenwood <fatgerman at gmail.com>
> >>>> wrote: ...
> >>>>
> >>>>> I have 0.26 (on mythbuntu 12.04) and VDPAU. I tried a few things.
> >>>>>
> >>>>> Plays fine in mythtv (as a Movie, not sure if that matters)
> >>>>> Plays fine in mplayer when mplayer is set to use vdpau output
> >>>>> Set mplayer to use xv output and the video stops at the change of
> >>>>> aspect but the audio carries on. The mplayer output gives you the
> >>>>> problem:
> >>>>>
> >>>>> [h264 @ 0x7faa4c59e280]Width/height changing with threads is not
> >>>>> implemented. Update your Libav version to the newest one from Git. If
> >>>>> the problem still occurs, it means that your file has a feature which
> >>>>> has not been implemented. [h264 @ 0x7faa4c59e280]decode_slice_header
> >>>>> error
> >>>>> [h264 @ 0x7faa4c59e280]no frame!
> >>>>
> >>>> Note that this has been reported against FFmpeg/Libav recently, so it
> >>>> is possible that a fix may eventually make it into the codes(*). When
> >>>> it does, and the next FFmpeg merge happens, you should get a fix.
> >>>> Until then, you are probably out of luck if using the software
> >>>> decoder. I suppose you could try running without multiple threads
> >>>> to see if it works.
> >>>
> >>> I did try setting the number of threads (using the smplayer GUI) to 1
> >>> but
> >>> it made no difference. I have always had my doubts as to whether that
> >>> option actually does anything.
> >>>
> >>> Mark
> >>>
> >>>> Gary
> >>>>
> >>>> (*) I expect that some rework of the codes is needed to synchronize
> >>>> the change(s) across the threads working on the stream. If it would
> >>>> have been easy, I would expect it would already be in there.
> >>
> >> Multi threading seems to be the problem for rendering
> >> "ffplay -threads 1 12002_20121104214000.mpg" works, as well as
> >> "mplayer -lavdopts threads=1 12002_20121104214000.mpg" (though with
> >> the sound
> >> advanced..)
> >>
> >> but neither "ffplay -threads 2 12002_20121104214000.mpg" nor
> >> "mplayer -lavdopts threads=2 12002_20121104214000.mpg" manage to pass
> >> the aspect ratio transition.
> >>
> >> I expect that when at home I change my playback profile to be single
> >> threaded
> >> the problems will disappear (under the carpet!). Should be OK as I
> >> only play
> >> SD content.
> >>
> >> If I understand correctly the question initially raised, regarding the
> >> effect
> >> of these changes in Lossless-Cut and (eventually) in some HDHomerun
> >> recordings
> >> is unrelated.
> >
> > Don't make the mistake that many do which is to equate digital with HD.
> > That might be true where you are but it certainly isn't in other parts
> > of the world.
> >
> > These problems will hit digital SD users like myself just as much as
> > they will affect HD users. In the UK, *everything* is now digital.
>
> But I have tended to equate SD with mpeg and HD with h264. Not in
> Portugal (or NZ).
That is correct. All our OTA broadcasts are h264+latm in SD. (There is also a
HD channel which broadcasts, day and night, a black image!)
In any case the "waf factor" has been restored by setting the playback profile
to use one only cpu.
I will keep an eye on updates and will look at the FFmpeg/Libav changes, but a
temporary solution is working.
Thanks to all those who helped.
Regards
ZP
More information about the mythtv-users
mailing list