• R/O
  • HTTP
  • SSH
  • HTTPS

Commit

Tags
No Tags

Frequently used words (click to add to your profile)

javac++androidlinuxc#windowsobjective-ccocoa誰得qtpythonphprubygameguibathyscaphec計画中(planning stage)翻訳omegatframeworktwitterdomtestvb.netdirectxゲームエンジンbtronarduinopreviewer

githubのコードからのfolk


Commit MetaInfo

Revisiond624933d6d66444a469a6d64f89bb0bd993215eb (tree)
Time2011-03-01 07:00:26
Authorjstebbins <jstebbins@b64f...>
Commiterjstebbins

Log Message

Fix PFR issue where there are different number of frames in 1st and 2nd pass.

Waiting for a fill threshhold in the fifos causes some non-determinism
in finding the first PTS value. Sometimes the fill level of one fifo
would not be reached until after another fifo is completely full, causing
an early exit in the loop that looks for the first PTS. When the initial PTS
is different between passes, the duration of the first frame is different.
This affects the PFR algorithm and can cause it to drop a different number
of frames.

The fill level was initially intended as a way to prevent thrashing between
threads to improve performance. But my testing indicates no degradation
when removing it.

git-svn-id: svn://localhost/HandBrake/trunk@3819 b64f7644-9d1e-0410-96f1-a4d463321fa5

Change Summary

Incremental Difference

--- a/libhb/fifo.c
+++ b/libhb/fifo.c
@@ -453,7 +453,7 @@ void hb_fifo_push_wait( hb_fifo_t * f, hb_buffer_t * b )
453453 f->size += 1;
454454 f->last = f->last->next;
455455 }
456- if( f->wait_empty && f->size >= f->thresh )
456+ if( f->wait_empty && f->size >= 1 )
457457 {
458458 f->wait_empty = 0;
459459 hb_cond_signal( f->cond_empty );
@@ -485,7 +485,7 @@ void hb_fifo_push( hb_fifo_t * f, hb_buffer_t * b )
485485 f->size += 1;
486486 f->last = f->last->next;
487487 }
488- if( f->wait_empty && f->size >= f->thresh )
488+ if( f->wait_empty && f->size >= 1 )
489489 {
490490 f->wait_empty = 0;
491491 hb_cond_signal( f->cond_empty );