[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