[FFmpeg-devel] Typo in h264_parser.c ?

Mark Thompson sw at jkqxz.net
Fri Apr 27 02:47:34 EEST 2018


On 27/04/18 00:33, John Pilkington wrote:
> Hi: I haven't previously posted here.
> 
> I've been on the mythtv lists since 2005 and wrote a cutting script that I use daily on mpeg2video SD recordings from DVB-T; it cuts with Project-X, at keyframes.  I have been trying to write a similar script using ffmpeg to cut h264-encoded HD recordings from DVB-T2 transmissions in the UK. Internal cuts have not been good.
> 
> I'm using mythffmpeg version 3.4.1, as incorporated in current mythtv-master, in Fedora 26.  Results have been similar with ffmpeg 3.3.7 for x86_64 f26 from rpmfusion.
> 
> I use a first pass to 'ignore_unknown' streams, and a second to do the cutting. During the second pass I have almost always had error reports of 'illegal reordering of pic_nums_idc' or 'reference count overflow.'
> 
> I reported that and the following details yesterday on the mythtv-devel list, and a re-post here has been suggested.
> 
> The error reports apparently come from libavcodec/h264_parser.c, lines 186 and 194.  The numbers in the 'if/else if' combination at lines 182/184 look very strange to me:
> 
>     unsigned int reordering_of_pic_nums_idc = get_ue_golomb_31(gb);
> 
>             if (reordering_of_pic_nums_idc < 3)
>                 get_ue_golomb_long(gb)
>             else if (reordering_of_pic_nums_idc > 3) {....
> 
> ..and libavcodec/golomb.h has this at line 82:
> 
> /**
> * read unsigned exp golomb code, constraint to a max of 31.
> * the return value is undefined if the stored value exceeds 31.
> */
> static inline int get_ue_golomb_31(GetBitContext *gb)
> {....
> 
> ***I think that the '3' in the 'else if' line in the parser should probably be 31. ***

No.

This is parsing a reference picture list modification block - see H.264 <https://www.itu.int/rec/T-REC-H.264-201704-I/en>, section 7.3.3.1.

Valid meaningful values are 0-2, and 3 ends the list.  Any other value is invalid.

> I have patched my copy accordingly.  I have seen no bad effects, most of the error messages have gone, and the internal cuts are much neater.
> 
> It would be great if someone would look to see if this and/or other patches are appropriate.  IIUC mythtv won't patch the ffmpeg code that it uses.
> 
> I have more test results available if required.

Can you share a short sample showing your problem?

- Mark


More information about the ffmpeg-devel mailing list