[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