[2/3] RFC: fate: Add -vsync 0 to output all frames of fate-vc1-ism

Message ID 1327694430-19598-2-git-send-email-martin@martin.st
State Deferred
Headers show

Commit Message

Martin Storsjö Jan. 27, 2012, 8 p.m.
Due to the lack/presence of extradata, the lavf timestamp
magic doesn't take the video stream into account when setting
start_time, making the first video frame come before start_time,
making it be skipped, unless we add -vsync 0.
---
 tests/fate/microsoft.mak |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Comments

Ronald Bultje Jan. 31, 2012, 6:41 a.m. | #1
Hi,

On Fri, Jan 27, 2012 at 12:00 PM, Martin Storsjö <martin@martin.st> wrote:
> Due to the lack/presence of extradata, the lavf timestamp
> magic doesn't take the video stream into account when setting
> start_time, making the first video frame come before start_time,
> making it be skipped, unless we add -vsync 0.
> ---
>  tests/fate/microsoft.mak |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Shouldn't the ref be updated then?

Ronald
Martin Storsjö Jan. 31, 2012, 8:24 a.m. | #2
On Mon, 30 Jan 2012, Ronald S. Bultje wrote:

> Hi,
>
> On Fri, Jan 27, 2012 at 12:00 PM, Martin Storsjö <martin@martin.st> wrote:
>> Due to the lack/presence of extradata, the lavf timestamp
>> magic doesn't take the video stream into account when setting
>> start_time, making the first video frame come before start_time,
>> making it be skipped, unless we add -vsync 0.
>> ---
>>  tests/fate/microsoft.mak |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> Shouldn't the ref be updated then?

That is one option too, but I don't particularly like it, since it would 
be the output with the first frame skipped.

// Martin
Martin Storsjö Jan. 31, 2012, 10:30 a.m. | #3
On Tue, 31 Jan 2012, Martin Storsjö wrote:

> On Mon, 30 Jan 2012, Ronald S. Bultje wrote:
>
>> Hi,
>> 
>> On Fri, Jan 27, 2012 at 12:00 PM, Martin Storsjö <martin@martin.st> wrote:
>>> Due to the lack/presence of extradata, the lavf timestamp
>>> magic doesn't take the video stream into account when setting
>>> start_time, making the first video frame come before start_time,
>>> making it be skipped, unless we add -vsync 0.
>>> ---
>>>  tests/fate/microsoft.mak |    2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>> 
>> Shouldn't the ref be updated then?
>
> That is one option too, but I don't particularly like it, since it would be 
> the output with the first frame skipped.

FWIW, this workaround shouldn't be needed at all, I stumbled upon the 
correct solution when debugging something else - I'll post it when I'm 
finished analyzing the rest of this..

// Martin

Patch

diff --git a/tests/fate/microsoft.mak b/tests/fate/microsoft.mak
index 5bc27b8..10fc961 100644
--- a/tests/fate/microsoft.mak
+++ b/tests/fate/microsoft.mak
@@ -33,7 +33,7 @@  FATE_VC1 += fate-vc1_sa20021
 fate-vc1_sa20021: CMD = framecrc -i $(SAMPLES)/vc1/SA20021.vc1
 
 FATE_VC1 += fate-vc1-ism
-fate-vc1-ism: CMD = framecrc -i $(SAMPLES)/isom/vc1-wmapro.ism -an
+fate-vc1-ism: CMD = framecrc -vsync 0 -i $(SAMPLES)/isom/vc1-wmapro.ism -an
 
 FATE_TESTS += $(FATE_VC1)
 fate-vc1: $(FATE_VC1)