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

Andre mythtv-list at dinkum.org.uk
Thu Feb 24 01:17:30 UTC 2011 

On 23 Feb 2011, at 23:41, Another Sillyname wrote:

> 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.

Looks like it went back to meaningful numbers on the 21st

|  18940 | 2011-02-20 18:22:00 |     1 |   14 |  160000 |
|  18940 | 2011-02-20 18:22:00 |     1 |   30 |     256 |
|  18940 | 2011-02-20 18:22:00 |     1 |   31 |    1600 |
|  18940 | 2011-02-20 19:57:00 |     0 |   14 |  160000 |
|  18940 | 2011-02-20 19:57:00 |     0 |   30 |     256 |
|  18940 | 2011-02-20 19:57:00 |     0 |   31 |    1600 |
|  18940 | 2011-02-21 22:27:00 |     1 |   14 | 1323529 |
|  18940 | 2011-02-21 22:27:00 |     1 |   30 |    1440 |
|  18940 | 2011-02-21 22:27:00 |     1 |   31 |    1088 |
|  18940 | 2011-02-21 22:27:00 |     1 |   32 |   25000 |

And BBC One HD

|  18941 | 2011-02-19 00:58:00 |     1 |   31 |    1600 |
|  18941 | 2011-02-20 14:53:00 |     1 |   14 |  160000 |
|  18941 | 2011-02-20 14:53:00 |     1 |   30 |     256 |
|  18941 | 2011-02-20 14:53:00 |     1 |   31 |    1600 |
|  18941 | 2011-02-20 15:25:00 |     1 |   14 |  160000 |
|  18941 | 2011-02-20 15:25:00 |     1 |   30 |     256 |
|  18941 | 2011-02-20 15:25:00 |     1 |   31 |    1600 |
|  18941 | 2011-02-20 23:23:00 |     1 |   14 |  160000 |
|  18941 | 2011-02-20 23:23:00 |     1 |   30 |     256 |
|  18941 | 2011-02-20 23:23:00 |     1 |   31 |    1600 |
|  18941 | 2011-02-22 16:53:00 |     1 |   14 | 1323529 |
|  18941 | 2011-02-22 16:53:00 |     1 |   30 |    1440 |
|  18941 | 2011-02-22 16:53:00 |     1 |   31 |    1088 |
|  18941 | 2011-02-22 16:53:00 |     1 |   32 |   25000 |
+--------+---------------------+-------+------+---------+

This is running 0.24-fixes

> 
> 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.

Yes, except I haven't seen the 224 & 48 in any of my recordings.

I wonder if this related to the PS3 refusing to play any recent BBC [One] HD recordings, maybe it's working again.

Andre

More information about the mythtv-users mailing list