[mythtv-users] BBC HD Dimensions Change - WAS [UK] BBC HD and BBC ONE HD - recording length incorrect

Wed Feb 23 23:41:27 UTC 2011

On 26/12/2010, Taylor Ralph <taylor.ralph at gmail.com> wrote:
> On Sun, Dec 26, 2010 at 9:46 AM, Paul Gardiner <lists at glidos.net> wrote:
>> On 24/12/2010 08:55, belcampo wrote:
>>>
>>> Taylor Ralph wrote:
>>>>
>>>> On Wed, Dec 22, 2010 at 6:13 AM, David Knight
>>>> <dlknight at sdf.lonestar.org> wrote:
>>>>>
>>>>> On Mon, November 29, 2010 8:19 pm, Taylor Ralph wrote:
>>>>>>
>>>>>> On Mon, Nov 29, 2010 at 3:11 PM, David Knight
>>>>>> <dlknight at sdf.lonestar.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Sun, November 28, 2010 12:43 pm, Richard Morton wrote:
>>>>>>>>
>>>>>>>> I have seen this on one recording as well (last weekend I think). i
>>>>>>>> was waiting for it to reoccur before reporting it - but I havent
>>>>>>>> watched any BBC HD since that occurance.
>>>>>>>> R
>>>>>>>>
>>>>>>>>
>>>>>>> Thanks for confirming Richard, I will check to see if there is an
>>>>>>> open
>>>>>>> ticket on the weekend as this was also mentioned in another recent
>>>>>>> thread.
>>>>>>> Just need to get the playback log output and a sample then :)
>>>>>>>
>>>>>>> Suppose I should try mplayer to see if it is an issue with some
>>>>>>> library
>>>>>>> e.g. ffmpeg.
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>> What does ffmpeg -i report for the recording? A change was committed
>>>>>> to trunk recently that hopefully fixes this issue.
>>>>>>
>>>>>> Regards.
>>>>>> --
>>>>>> Taylor
>>>>>>
>>>>>>
>>>>> FFmpeg version SVN-r25557-snapshot, Copyright (c) 2000-2010 the FFmpeg
>>>>> developers
>>>>> built on Oct 24 2010 07:32:30 with gcc 4.4.4 20100630 (Red Hat
>>>>> 4.4.4-10)
>>>>> configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64
>>>>> --mandir=/usr/share/man --enable-shared --enable-gpl --enable-version3
>>>>> --enable-nonfree --enable-postproc --enable-avfilter --enable-pthreads
>>>>> --enable-x11grab --enable-vdpau --disable-avisynth --enable-libdc1394
>>>>> --enable-libdirac --enable-libfaac --enable-libgsm --enable-libmp3lame
>>>>> --enable-libnut --enable-libopencore-amrnb --enable-libopencore-amrwb
>>>>> --enable-libopenjpeg --enable-libschroedinger --enable-libspeex
>>>>> --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid
>>>>> --extra-cflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>>>>> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC'
>>>>> --disable-stripping
>>>>> libavutil 50.32. 3 / 50.32. 3
>>>>> libavcore 0. 9. 1 / 0. 9. 1
>>>>> libavcodec 52.93. 0 / 52.93. 0
>>>>> libavformat 52.84. 0 / 52.84. 0
>>>>> libavdevice 52. 2. 2 / 52. 2. 2
>>>>> libavfilter 1.53. 0 / 1.53. 0
>>>>> libswscale 0.12. 0 / 0.12. 0
>>>>> libpostproc 51. 2. 0 / 51. 2. 0
>>>>> [h264 @ 0x1e1c490] non-existing SPS 0 referenced in buffering period
>>>>> [h264 @ 0x1e1c490] non-existing PPS referenced
>>>>> [h264 @ 0x1e1c490] non-existing SPS 0 referenced in buffering period
>>>>> [h264 @ 0x1e1c490] non-existing PPS 0 referenced
>>>>> [h264 @ 0x1e1c490] decode_slice_header error
>>>>> [h264 @ 0x1e1c490] non-existing PPS 0 referenced
>>>>> [h264 @ 0x1e1c490] decode_slice_header error
>>>>> [h264 @ 0x1e1c490] non-existing PPS 0 referenced
>>>>> [h264 @ 0x1e1c490] decode_slice_header error
>>>>> [h264 @ 0x1e1c490] non-existing PPS 0 referenced
>>>>> [h264 @ 0x1e1c490] decode_slice_header error
>>>>> [h264 @ 0x1e1c490] non-existing PPS 0 referenced
>>>>> [h264 @ 0x1e1c490] decode_slice_header error
>>>>> [h264 @ 0x1e1c490] non-existing PPS 0 referenced
>>>>> [h264 @ 0x1e1c490] decode_slice_header error
>>>>> [h264 @ 0x1e1c490] no frame!
>>>>>
>>>>> Above errors repeated for couple of pages.
>>>>>
>>>>> [mpegts @ 0x1e166e0] max_analyze_duration reached
>>>>> [NULL @ 0x1e3a630] start time is not set in
>>>>> av_estimate_timings_from_pts
>>>>> Input #0, mpegts, from '/video/default/8941_20101127194500.mpg':
>>>>> Duration: 00:46:26.00, start: 5649.660133, bitrate: 7424 kb/s
>>>>> Program 1
>>>>> Stream #0.0[0x1518]: Video: h264, yuv420p, 1440x1080 [PAR 4:3 DAR
>>>>> 16:9], 27.53 fps, 25 tbr, 90k tbn, 50 tbc
>>>>> Stream #0.1[0x151a](NAR): Audio: mp2, 48000 Hz, 2 channels, s16, 256
>>>>> kb/s
>>>>> Stream #0.2[0x151b](eng): Subtitle: [6][0][0][0] / 0x0006
>>>>> Stream #0.3[0x151c](eng): Subtitle: dvbsub
>>>>> Stream #0.4[0x1519](eng): Audio: ac3, 48000 Hz, stereo, s16, 192 kb/s
>>>>> At least one output file must be specified
>>>>>
>>>>> Dave K.
>>>>>
>>> Things go wrong here:
>>> The duration seems to be correct but this 27.53 fps is wrong, The file
>>> is assumed as VFR instead of CFR. The amount of frames will be
>>> calculated wrong, so seeking will fail. The problem is AFAIK in the
>>> muxing of ffmpeg, see my mentioned ffmpeg-issues in this thread.
>>
>> Does this mean it isn't a MythTv issue at all? Is it because ffmpeg
>> is used in generating the position map?
>>
>> Paul.
>
> My initial guess is that something might be wrong with MythTV's h264
> parser, but until someone opens a ticket and uploads a sample
> somewhere for a dev to look at we'll never know. If you copy the
> recording under a different name and play it with the Internal player
> under MythVideo without issue then ffmpeg is working fine. I'm not
> wasting anymore time responding to this thread given that no one has
> taken the time to create a ticket and/or upload a sample. Maybe one of
> the UK devs will take this on.
>
> Regards.
> --
> Taylor
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>

I just thought I'd flag up that BBC HD are tinkering with the stream again.....

In

mythconverg.recordedmarkup.type

there are two flags on the recording, specifically 30 and 31 which
historically have captured the dimensions of the recording....in the
past for a BBC HD recording they stored 1440 and 1088 respectively.

In September last year the values changed to 256 and 1600 which didn't
directly relate to the dimensions any longer.

Over the last few days BBC HD has changed the values to 224 and 48 respectively.

While this doesn't seem to affect myth directly (running .23 fixes) I
bring it to everyones attention in case anyone is using it as a check
flag for any other scripts you may be running.

Someone told me where those two fields get populated from but I can't
remember now or find it in my notes....if anyone is running .24 fixes
could they possibly check some BBC HD recordings from the last few
days to see if they are getting the same data.

Thanks