[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