[Ffmpeg-devel] Re: [PATCH] Tiertex .SEQ files support

[Gregory Montoir]

Hi,

Updated patch.

Michael Niedermayer wrote:
 > Hi
 >
 > [...]
 >
 >>+static int seq_read_header(AVFormatContext *s, AVFormatParameters *ap)
 >>+{
 >>+    int i, rc;
 >>+    SeqDemuxContext *seq = (SeqDemuxContext *)s->priv_data;
 >>+    ByteIOContext *pb = &s->pb;
 >>+    AVStream *st;
 >>+
 >>+    if (get_buffer(pb, seq->current_frame_data, SEQ_FRAME_SIZE) != 
SEQ_FRAME_SIZE)
 >>+        return AVERROR_IO;
 >
 > why do you read the data into a buffer instead of using get_le*() 
everywhere?
 > if theres no reason then please change it to use get_le*()

Mostly because I thought it would be more efficient to do it like this.
Instead of fseek'ing/ftell'ing ByteIOContext, I just read the whole 6kb
buffer and do the various memcpy calls from the different video data
offsets.

All your other remarks should have been taken into account.


Also, while doing the modifications to my code to use the bitstream
stuff, I encountered a problem ; the get_sbits() function wasn't
returning proper results. Looks like the SHOW_BITS macro wasn't ready
for LE data, I attached a second patch to fix that.


I also have a question regarding the way palette update is handled.
Looking at idcin.c/idcinvideo.c, AVPaletteControl is used. If I
understand things correctly, the AVCodecContext structure contains
this field, the demuxer updates it when it detects a palette change
and next time the video decoder processes a frame, it can handle
it properly. But what happens if the (demuxer)_read_packet() and
(video)_decode_frame calls are not exactly sequential ? For example,
in the following situation :

demuxer_read_packet() is called
  -> a palette change is detected on frame (n+0), AVPaletteControl
     is updated

demuxer_read_packet() is called (probably to buffer data)
  -> no palette change in frame (n+1)

demuxer_read_packet() is called a third time (probably to buffer even
more data)
  -> a palette change is detected on frame (n+2), AVPaletteControl
     is updated

video_decode_frame() is called
  -> it processes frame (n+0), but, with the palette of frame (n+2) (as
     the demuxer has just updated AVPaletteControl in the previous call).

I am just wondering because that's the behaviour I'm observing under
ffplay. Is there a way to do, properly, some kind of synchronization ?


I'll update the other patch (.CIN files support) as I find some more
time.

Regards,
Gregory
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ffmpeg-tiertexseq-20060919.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060920/1c9dc9b0/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ffmpeg-bitstream-20060919.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060920/1c9dc9b0/attachment.txt>