[FFmpeg-devel] [PATCH] RoQ muxer
Vitor
vitor1001
Wed May 9 10:47:30 CEST 2007
Michael Niedermayer wrote:
>> Actually, I don't have Quake 3, so I can't verify if it really is so
>> sensible to the frame interleaving...
>>
> that is a problem
>
"fixed", downloads in http://ioquake3.org/ and
ftp://ftp.idsoftware.com/idstuff/quake3/linux/linuxq3ademo-1.11-6.x86.gz.sh
>> The original's author comment says
>> so, and the format description in Tim Ferguson page specifies that
>> order.
>>
> the idroq.txt file shows in an example that audio packets and video
> packets are interleaved together one after one but your code does not produce
> this it rather omits audio packets if it received 2 consecutive video packets
> after dts ordering, this is very odd
> also its just a example diagram in idroq.txt ive not found any mentioning
> of this interleaving requirement in the actual text
>
I've done some experiments with it. In the idlogo.RoQ (that's part of
the Q3 demo), the frames are ordered like the following:
AVAVAVAVAVAVAV ... AVAVAVAVAVAVAVVVVVVV ... VVVV
The file jk02.roq in the samples ftp show the same ordering. The file
demoEnd.RoQ is video only.
>> If this order is really necessary, I don't think that just dts
>> interleaving (even subtracting a constant of the dts audio packets) will
>> be enough to assure a proper packet ordering.
>>
>
> what is proper packet ordering for roq?
>
> blind 1 audio + 1 video is almost certainly wrong, just think of the case that
> the duration of the audio and video packets missmatch
> and if they match then how does your code differ from dts ordering + constant?
>
I've tried both the patch I submitted and the dts ordering to encode a
file. The resulting ordering are the following:
DTS:
VAAVAVVAAVAVAVAVAVVAAVAVAVAVAVVAAVAVAVAVAVVAAVAVAVAVAVVAAVAVVAAVAVVAAVAVAVVAAVV
AAVAVAVAVAVVAAVAVAVAVAVVAAVAVAVAVAVVAAVAVVAAVAVVAAVAVVAVAAVVAAVAVAVAVVAVAAVAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
...
My patch:
AVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVA
VAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAVAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
...
The input file had more audio than video, so the extra A's in the end
are supposed to be there. Interestingly, I've tried both in Quake III
and both play ok. Maybe back in 1999, in a case like AVVAA, the time it
took to decode two video frames was too long to allow the next audio
frame to arrive on time. It may also that the problem only exists in the
windows port, or there is no problem at all with a different ordering...
What do you think?
PS: In the other hand, I think there is a minor thing wrong in my patch,
so if you decide to stick with the custom interleaving, I'll send
another patch...
More information about the ffmpeg-devel
mailing list