r14339 - trunk/libavcodec/h264.c
Author: michael Date: Wed Jul 23 04:12:54 2008 New Revision: 14339 Log: Support gaps in the frame num. Fixes at least: MR3_TANDBERG_B.264 MR4_TANDBERG_C.264 MR5_TANDBERG_C.264 Modified: trunk/libavcodec/h264.c Modified: trunk/libavcodec/h264.c ============================================================================== --- trunk/libavcodec/h264.c (original) +++ trunk/libavcodec/h264.c Wed Jul 23 04:12:54 2008 @@ -3539,6 +3539,12 @@ static int execute_ref_pic_marking(H264C pic= remove_long(h, j); if(pic) unreference_pic(h, pic, 0); } + s->current_picture_ptr->poc= + s->current_picture_ptr->field_poc[0]= + s->current_picture_ptr->field_poc[1]= + h->poc_lsb= + h->poc_msb= + h->frame_num= s->current_picture_ptr->frame_num= 0; break; default: assert(0); @@ -3599,7 +3605,7 @@ static int execute_ref_pic_marking(H264C "number of reference frames exceeds max (probably " "corrupt input), discarding one\n"); - if (h->long_ref_count) { + if (h->long_ref_count && !h->short_ref_count) { for (i = 0; i < 16; ++i) if (h->long_ref[i]) break; @@ -4018,6 +4024,16 @@ static int decode_slice_header(H264Conte } if(h0->current_slice == 0){ + while(h->frame_num != h->prev_frame_num && + h->frame_num != (h->prev_frame_num+1)%(1<<h->sps.log2_max_frame_num)){ + av_log(NULL, AV_LOG_DEBUG, "Frame num gap %d %d\n", h->frame_num, h->prev_frame_num); + frame_start(h); + h->prev_frame_num++; + h->prev_frame_num %= 1<<h->sps.log2_max_frame_num; + s->current_picture_ptr->frame_num= h->prev_frame_num; + execute_ref_pic_marking(h, NULL, 0); + } + /* See if we have a decoded first field looking for a pair... */ if (s0->first_field) { assert(s0->current_picture_ptr); @@ -7738,7 +7754,7 @@ static int decode_frame(AVCodecContext * //FIXME factorize this with the output code below out = h->delayed_pic[0]; out_idx = 0; - for(i=1; h->delayed_pic[i] && !h->delayed_pic[i]->key_frame; i++) + for(i=1; h->delayed_pic[i] && !h->delayed_pic[i]->key_frame && h->delayed_pic[i]->poc; i++) if(h->delayed_pic[i]->poc < out->poc){ out = h->delayed_pic[i]; out_idx = i; @@ -7821,13 +7837,13 @@ static int decode_frame(AVCodecContext * s->current_picture_ptr->qscale_type= FF_QSCALE_TYPE_H264; s->current_picture_ptr->pict_type= s->pict_type; - h->prev_frame_num_offset= h->frame_num_offset; - h->prev_frame_num= h->frame_num; if(!s->dropable) { + execute_ref_pic_marking(h, h->mmco, h->mmco_index); h->prev_poc_msb= h->poc_msb; h->prev_poc_lsb= h->poc_lsb; - execute_ref_pic_marking(h, h->mmco, h->mmco_index); } + h->prev_frame_num_offset= h->frame_num_offset; + h->prev_frame_num= h->frame_num; /* * FIXME: Error handling code does not seem to support interlaced @@ -7887,7 +7903,7 @@ static int decode_frame(AVCodecContext * out = h->delayed_pic[0]; out_idx = 0; - for(i=1; h->delayed_pic[i] && !h->delayed_pic[i]->key_frame; i++) + for(i=1; h->delayed_pic[i] && !h->delayed_pic[i]->key_frame && h->delayed_pic[i]->poc; i++) if(h->delayed_pic[i]->poc < out->poc){ out = h->delayed_pic[i]; out_idx = i;
On Wed, 2008-07-23 at 04:12 +0200, michael wrote:
Author: michael Date: Wed Jul 23 04:12:54 2008 New Revision: 14339
Log: Support gaps in the frame num. Fixes at least: MR3_TANDBERG_B.264 MR4_TANDBERG_C.264 MR5_TANDBERG_C.264
After this commit I'm getting lots of "number of reference frames exceeds max (probably corrupt input), discarding one" messages. Happens with every file I tried. Not affected by the latest "typo fix" commit.
On Wed, 23 Jul 2008, Uoti Urpala wrote:
On Wed, 2008-07-23 at 04:12 +0200, michael wrote:
Author: michael Date: Wed Jul 23 04:12:54 2008 New Revision: 14339
Log: Support gaps in the frame num. Fixes at least: MR3_TANDBERG_B.264 MR4_TANDBERG_C.264 MR5_TANDBERG_C.264
After this commit I'm getting lots of "number of reference frames exceeds max (probably corrupt input), discarding one" messages. Happens with every file I tried. Not affected by the latest "typo fix" commit.
I get that too on some files, because they start out with frame nums != 0 and max frame num being very large. The new gaps in frame num code is missing the delete part of the sliding window operation for reference picture marking; it calls execute_ref_pic_marking directly (sliding window implementation is in decode_ref_pic_marking) so no ref frames get unreferenced until the hard limit (code w/ error message you cite) is hit. I have at least one sample that crashes, too, with this new code (with NDEBUG it trips: assert(best_i != INT_MIN); on or about line 2892. This is because all synthesized frames have poc == 0. I have not had time to see where the error is, though; in the poc computation for the missing frames or the use of poc in the ref list building. -Jeff
On Wed, Jul 23, 2008 at 04:30:18PM -0400, Jeff Downs wrote:
On Wed, 23 Jul 2008, Uoti Urpala wrote:
On Wed, 2008-07-23 at 04:12 +0200, michael wrote:
Author: michael Date: Wed Jul 23 04:12:54 2008 New Revision: 14339
Log: Support gaps in the frame num. Fixes at least: MR3_TANDBERG_B.264 MR4_TANDBERG_C.264 MR5_TANDBERG_C.264
After this commit I'm getting lots of "number of reference frames exceeds max (probably corrupt input), discarding one" messages. Happens with every file I tried. Not affected by the latest "typo fix" commit.
I get that too on some files, because they start out with frame nums != 0 and max frame num being very large.
The new gaps in frame num code is missing the delete part of the sliding window operation for reference picture marking; it calls execute_ref_pic_marking directly (sliding window implementation is in decode_ref_pic_marking) so no ref frames get unreferenced until the hard limit (code w/ error message you cite) is hit.
The limit is the same, sps->ref_frame_count, besides the reference bitstreams with it decode correctly thus i would assume it is doing the sliding window operation correctly, and that rather the code is duplicated in decode_ref_pic_marking(). If true, this duplicated code should maybe be removed.
I have at least one sample that crashes, too, with this new code (with NDEBUG it trips:
assert(best_i != INT_MIN);
on or about line 2892. This is because all synthesized frames have poc == 0. I have not had time to see where the error is, though; in the poc computation for the missing frames or the use of poc in the ref list building.
I do not think the code can assume poc values to be or not to be of specific values. So independant of the poc values being correct the crashing code might be buggy. Please upload the sample, and help fixing it is welcome as well of course. Besides this i have fixed some misdetected frame num gaps, that of course doesnt mean that the assert() above shouldnt be looked into even if its not occuring anymore. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I hate to see young programmers poisoned by the kind of thinking Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
On Thu, 24 Jul 2008, Michael Niedermayer wrote:
On Wed, Jul 23, 2008 at 04:30:18PM -0400, Jeff Downs wrote:
On Wed, 23 Jul 2008, Uoti Urpala wrote:
On Wed, 2008-07-23 at 04:12 +0200, michael wrote:
Author: michael Date: Wed Jul 23 04:12:54 2008 New Revision: 14339
Log: Support gaps in the frame num. Fixes at least: MR3_TANDBERG_B.264 MR4_TANDBERG_C.264 MR5_TANDBERG_C.264
After this commit I'm getting lots of "number of reference frames exceeds max (probably corrupt input), discarding one" messages. Happens with every file I tried. Not affected by the latest "typo fix" commit.
I get that too on some files, because they start out with frame nums != 0 and max frame num being very large.
The new gaps in frame num code is missing the delete part of the sliding window operation for reference picture marking; it calls execute_ref_pic_marking directly (sliding window implementation is in decode_ref_pic_marking) so no ref frames get unreferenced until the hard limit (code w/ error message you cite) is hit.
The limit is the same, sps->ref_frame_count, besides the reference bitstreams with it decode correctly thus i would assume it is doing the sliding window operation correctly, and that rather the code is duplicated in decode_ref_pic_marking(). If true, this duplicated code should maybe be removed.
Indeed. Take a look at attached. Removes MMCO synthesis for sliding window and lets it be handled at the end of mmco execution. The error message for too many reference frames is lost, though; there's no way to tell if it is sliding window or bad MMCO that put us over the limit without some additional book-keeping. If you think the error is valuable enough, I can add a var to the context to track that. -Jeff
On Sat, Jul 26, 2008 at 05:22:54PM -0400, Jeff Downs wrote:
On Thu, 24 Jul 2008, Michael Niedermayer wrote:
On Wed, Jul 23, 2008 at 04:30:18PM -0400, Jeff Downs wrote:
On Wed, 23 Jul 2008, Uoti Urpala wrote:
On Wed, 2008-07-23 at 04:12 +0200, michael wrote:
Author: michael Date: Wed Jul 23 04:12:54 2008 New Revision: 14339
Log: Support gaps in the frame num. Fixes at least: MR3_TANDBERG_B.264 MR4_TANDBERG_C.264 MR5_TANDBERG_C.264
After this commit I'm getting lots of "number of reference frames exceeds max (probably corrupt input), discarding one" messages. Happens with every file I tried. Not affected by the latest "typo fix" commit.
I get that too on some files, because they start out with frame nums != 0 and max frame num being very large.
The new gaps in frame num code is missing the delete part of the sliding window operation for reference picture marking; it calls execute_ref_pic_marking directly (sliding window implementation is in decode_ref_pic_marking) so no ref frames get unreferenced until the hard limit (code w/ error message you cite) is hit.
The limit is the same, sps->ref_frame_count, besides the reference bitstreams with it decode correctly thus i would assume it is doing the sliding window operation correctly, and that rather the code is duplicated in decode_ref_pic_marking(). If true, this duplicated code should maybe be removed.
Indeed. Take a look at attached. Removes MMCO synthesis for sliding window and lets it be handled at the end of mmco execution. The error message for too many reference frames is lost, though; there's no way to tell if it is sliding window or bad MMCO that put us over the limit without some additional book-keeping.
If you think the error is valuable enough, I can add a var to the context to track that.
I think it is valuable. What about a MMCO_SLIDING_WINDOW that is placed in the array, that would be rather clean and easy to check for i think (unless i miss something) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway
On Sun, 27 Jul 2008, Michael Niedermayer wrote: [...]
I think it is valuable. What about a MMCO_SLIDING_WINDOW that is placed in the array, that would be rather clean and easy to check for i think (unless i miss something)
I did something similar - rather than discarding MMCO_END, I insert it. The check for sliding window then becomes simply !mmco_count. -Jeff
On Fri, 15 Aug 2008, Jeff Downs wrote:
On Sun, 27 Jul 2008, Michael Niedermayer wrote:
[...]
I think it is valuable. What about a MMCO_SLIDING_WINDOW that is placed in the array, that would be rather clean and easy to check for i think (unless i miss something)
I did something similar - rather than discarding MMCO_END, I insert it. The check for sliding window then becomes simply !mmco_count.
ping Think this probably got lost in SoC rush. -Jeff
participants (4)
-
heydowns＠borg.com -
michaelni＠gmx.at -
subversion＠mplayerhq.hu -
uoti.urpala＠pp1.inet.fi