From avio.h:
offset_t *url_fseek*(ByteIOContext *s, offset_t offset, int whence); What does the url_fseek() function do exactly? And whence has SEEK_XYZ values - what do they mean? Any pointers on where this info is located in the code? ----------------- Sisir Koppaka
From the BFI wiki page :
bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values) I'm in a dilemma over what PIX_FMT to use. There appear to be many different sizes of RGB's in libavutil/avutil.h but no 6 bit sized format. There's even a PIX_FMT_PAL8 that is 8 bit with PIX_FMT_RGB32 palette - I'm confused about this! Can we choose a different format for the palette and for the display or do both have to be same? ----------------- Sisir Koppaka
In the typedef struct definition of AVCodec in libavcodec/avcodec.h: 1) what does int capabilities; stand for and what is it supposed to contain? 2) Is it compulsory to assign some value to the PixelFormat variable or can we leave it since we have already assigned a PIX_FMT_XYZ in the demuxer? 3) What is the void (*flush)(AVCodecContext *)? ----------------- Sisir Koppaka
On Fri, Mar 21, 2008 at 01:02:29PM +0530, Sisir Koppaka wrote:
In the typedef struct definition of AVCodec in libavcodec/avcodec.h: 1) what does int capabilities; stand for
Codec capabilities
and what is it supposed to contain?
CODEC_CAP_*
2) Is it compulsory to assign some value to the PixelFormat variable or can we leave it since we have already assigned a PIX_FMT_XYZ in the demuxer?
It is compulsory.
3) What is the void (*flush)(AVCodecContext *)?
It tells the codec to flush its buffer if it does contain any, this is used for seeking. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates
Thanks a lot! One more question : The BFI file format description at the wiki ( http://wiki.multimedia.cx/index.php?title=BFI) begins the file with byte 0 whereas the Bethsoft VID description here ( http://andux.svatopluk.com/docs/dfvid.html) begins with byte 1. Hence, I am in a bit of confusion as to how we should refer to the bytes from FFmpeg. If I want to seek to the video width in a BFI file for example, should I use url_fseek(ByteIOContextPointer,n,SEEK_SET) where n should be 43,44 or 45? I think SEEK_SET stands for absolute offset whereas SEEK_CUR stands for relative offset, but I'm not sure about them. Please correct me if I'm wrong. ----------------- Sisir Koppaka
On Fri, Mar 21, 2008 at 05:41:56PM +0530, Sisir Koppaka wrote:
Thanks a lot! One more question : The BFI file format description at the wiki ( http://wiki.multimedia.cx/index.php?title=BFI) begins the file with byte 0 whereas the Bethsoft VID description here ( http://andux.svatopluk.com/docs/dfvid.html) begins with byte 1. Hence, I am in a bit of confusion as to how we should refer to the bytes from FFmpeg. If I want to seek to the video width in a BFI file for example, should I use url_fseek(ByteIOContextPointer,n,SEEK_SET) where n should be 43,44 or 45?
The first byte of a file, stream, ... has position 0 in libav*.
I think SEEK_SET stands for absolute offset whereas SEEK_CUR stands for relative offset, but I'm not sure about them. Please correct me if I'm wrong.
To quote ISO/IEC 9899:1999 For a binary stream, the new position, measured in characters from the beginning of the file, is obtained by adding offset to the position specied by whence. The specified position is the beginning of the file if whence is SEEK_SET, the current value of the file position indicator if SEEK_CUR, or end-of-file if SEEK_END. A binary stream need not meaningfully support fseek calls with a whence value of SEEK_END. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf
Sisir Koppaka wrote:
From the BFI wiki page :
bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values)
I'm in a dilemma over what PIX_FMT to use. There appear to be many different sizes of RGB's in libavutil/avutil.h but no 6 bit sized format. There's even a PIX_FMT_PAL8 that is 8 bit with PIX_FMT_RGB32 palette - I'm confused about this!
Can we choose a different format for the palette and for the display or do both have to be same?
You will want to use PIX_FMT_PAL8. The 6-bit values will need to be shifted the left by 2 bits. This is quite common in paletted video decoders. 'grep' for PIX_FMT_PAL8 among the other libavcodec/ files to see examples of how it is used. -- -Mike Melanson
Thanks!
In the BFI wiki page (http://wiki.multimedia.cx/index.php?title=BFI): bytes 52-55 ( +34) first used palette entry index bytes 56-59 ( +38) number of used palette entries bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values) To set the palette, I'm currently running av_get_packet after setting the pointer to 60 and setting the stream_index to 0 which is what my video uses. I) have some confusion with bytes 52-55 and 56-59 - what do they do and how should I handle them? 2)Am I right in setting the pointer to 60 before calling av_get_packet or should I set it to 52 or 56? ----------------- Sisir Koppaka
Sisir Koppaka wrote:
In the BFI wiki page (http://wiki.multimedia.cx/index.php?title=BFI):
bytes 52-55 ( +34) first used palette entry index bytes 56-59 ( +38) number of used palette entries bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values)
To set the palette, I'm currently running av_get_packet after setting the pointer to 60 and setting the stream_index to 0 which is what my video uses.
I) have some confusion with bytes 52-55 and 56-59 - what do they do and how should I handle them?
Weird. I just reviewed the spec and examined 2287.bfi. It doesn't make much sense to specify beginning and ending palette indices when you are transporting the whole 256-color palette anyway. Maybe they are just advisory.
2)Am I right in setting the pointer to 60 before calling av_get_packet or should I set it to 52 or 56?
Offset 60. You want the 256 RGB triplets. -- -Mike Melanson
Thanks! ----------------- Sisir Koppaka
What does the get_buffer(x,y,code) do and what is it's return value? (x and y are pointers) ----------------- Sisir Koppaka
The BFI wiki page says(http://wiki.multimedia.cx/index.php?title=BFI) : bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values) and also, The video always encoded as palettized, 8-bit data. How are these two the same? Yes, 8 bit data corresponds to 256 RGB triplets but what is the '6-bit VGA palette values'? I'm finding some trouble here handling the decoding, can anyone please help me with this? ----------------- Sisir Koppaka
Sisir Koppaka wrote:
The BFI wiki page says(http://wiki.multimedia.cx/index.php?title=BFI) :
bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values)
and also, The video always encoded as palettized, 8-bit data.
How are these two the same? Yes, 8 bit data corresponds to 256 RGB triplets but what is the '6-bit VGA palette values'? I'm finding some trouble here handling the decoding, can anyone please help me with this?
A decoded picture is width x height pixels. Each pixel is 8 bits, or 1 byte. That's where the "8-bit data" part comes from. There is a 256-color palette. Each pixel (which is an 8-bit value, 0-255) points to one of those 256 colors. Each color is comprised of a red, green, and blue value. Each R, G, and B value has a 6-bit range (0-63). That's where the "6-bit VGA palette values" part comes from. More background on that here: http://wiki.multimedia.cx/index.php?title=VGA Before you pass the RGB components to FFmpeg, you will need to scale them to be 8-bit components. -- -Mike Melanson
On Sat, Mar 22, 2008 at 2:03 AM, Mike Melanson <mike@multimedia.cx> wrote:
The BFI wiki page says(http://wiki.multimedia.cx/index.php?title=BFI) :
bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values)
and also, The video always encoded as palettized, 8-bit data.
How are these two the same? Yes, 8 bit data corresponds to 256 RGB
Sisir Koppaka wrote: triplets
but what is the '6-bit VGA palette values'? I'm finding some trouble here handling the decoding, can anyone please help me with this?
A decoded picture is width x height pixels. Each pixel is 8 bits, or 1 byte. That's where the "8-bit data" part comes from.
There is a 256-color palette. Each pixel (which is an 8-bit value, 0-255) points to one of those 256 colors. Each color is comprised of a red, green, and blue value. Each R, G, and B value has a 6-bit range (0-63). That's where the "6-bit VGA palette values" part comes from. More background on that here:
But the size of the BFI palette is 256*3 right? Did you mean to say that there is a 256-color palette for R, G and B individually? In that case, wouldn't R,G and B have a depth of 256 instead of 64? Also, I'm setting the palette once in the demuxer? How often do we have to set the palette? like for every frame in the decoder? ----------------- Sisir Koppaka
Sisir Koppaka wrote:
But the size of the BFI palette is 256*3 right? Did you mean to say that there is a 256-color palette for R, G and B individually? In that case, wouldn't R,G and B have a depth of 256 instead of 64? Also, I'm setting the palette once in the demuxer? How often do we have to set the palette? like for every frame in the decoder?
In C, the palette generally looks like this: unsigned char palette[256][3]; So that makes 256*3 = 768 bytes. When you a (commonly) 320x200 video frame of PIX_FMT_PAL8 data, that is 64000 pixels = 64000 bytes. To find the color that a particular pixel represents, use the byte to index into palette[]. That will give you the R, G, and B values for that pixel. Each of those R, G, and B values will max out at 64. Multiply by 4, naively, to scale up to a full 8-bit range. As for the palette communication, I have to admit that I can't remember off the top of my head how that's supposed to work right now. If Kostya is monitoring the conversation, hopefully, he will jump in. How is the BFI demuxer coming? Are you dispatching video and audio? Can you hear the audio yet? -- -Mike Melanson
On Sat, Mar 22, 2008 at 9:38 AM, Mike Melanson <mike@multimedia.cx> wrote:
But the size of the BFI palette is 256*3 right? Did you mean to say that there is a 256-color palette for R, G and B individually? In that case, wouldn't R,G and B have a depth of 256 instead of 64? Also, I'm setting
palette once in the demuxer? How often do we have to set the palette?
Sisir Koppaka wrote: the like
for every frame in the decoder?
In C, the palette generally looks like this:
unsigned char palette[256][3];
So that makes 256*3 = 768 bytes.
When you a (commonly) 320x200 video frame of PIX_FMT_PAL8 data, that is 64000 pixels = 64000 bytes. To find the color that a particular pixel represents, use the byte to index into palette[]. That will give you the R, G, and B values for that pixel. Each of those R, G, and B values will max out at 64. Multiply by 4, naively, to scale up to a full 8-bit range.
As for the palette communication, I have to admit that I can't remember off the top of my head how that's supposed to work right now. If Kostya is monitoring the conversation, hopefully, he will jump in.
How is the BFI demuxer coming? Are you dispatching video and audio? Can you hear the audio yet?
Am working on the demuxer and parts of the decoder...got stuck up in the video maze and forgot to compile...now that I do, I get quite some errors....one of them's a missing ; :) quite some debugging to do :) ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Am working on the demuxer and parts of the decoder...got stuck up in the video maze and forgot to compile...now that I do, I get quite some errors....one of them's a missing ; :) quite some debugging to do :)
Yes, think small and modular. Write a piece, compile it, debug it, verify it, then write another piece. You won't get through an actual GSoC project by trying to write the entire thing before you even compile it once. Remember that for the first iteration of the demuxer, you can just skip the video. The files have uncompressed PCM audio, so demux that, send it down the PCM audio path, and seek() past the video chunks. You should be able to hear audio in short order. -- -Mike Melanson
Doing that now :) For some reason, my typedef struct BFIContext is not being recognized when I declare one inside a function like BFIContext *bfi = s->priv_data; All my errors say that 'BFIContext' has no member named 'membername'. I think I'm making some fundamental mistake here :( ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Doing that now :) For some reason, my typedef struct BFIContext is not being recognized when I declare one inside a function like BFIContext *bfi = s->priv_data; All my errors say that 'BFIContext' has no member named 'membername'. I think I'm making some fundamental mistake here :(
Are you dereferencing items as: bfi.membername or bfi->membername ? One is right. One is wrong. -- -Mike Melanson
On Sat, Mar 22, 2008 at 10:25 AM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
Doing that now :) For some reason, my typedef struct BFIContext is not being recognized when I declare one inside a function like BFIContext *bfi = s->priv_data; All my errors say that 'BFIContext' has no member named 'membername'. I think I'm making some fundamental mistake here :(
Are you dereferencing items as:
bfi.membername
or
bfi->membername ?
One is right. One is wrong.
I'm using bfi->membername -- ----------------- Sisir Koppaka
Sisir Koppaka wrote:
I'm using bfi->membername
Good. That's the right one. :) What does the structure def look like? And what does the problematic statement look like? -- -Mike Melanson
On Sat, Mar 22, 2008 at 10:28 AM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
I'm using bfi->membername
Good. That's the right one. :)
What does the structure def look like? And what does the problematic statement look like?
This is the set of errors for one function. A similar list appears for the other functions as well. bfi.c: In function 'bfi_read_video': bfi.c:83: error: 'BFIContext' has no member named 'chunk_header' bfi.c:83: error: 'BFIContext' has no member named 'video_offset' bfi.c:86: error: 'BFIContext' has no member named 'stream_index' bfi.c:87: error: 'BFIContext' has no member named 'nframes' bfi.c:88: error: 'BFIContext' has no member named 'fps' bfi.c:89: error: 'BFIContext' has no member named 'chunk_header' bfi.c:89: error: 'BFIContext' has no member named 'video_offset' bfi.c:90: error: 'BFIContext' has no member named 'chunk_header' The typdef goes this way : typedef struct BFIContext { int nframes; int nframesOrig; int palette_set=0; int *chunk_header; int audio_offset; int video_offset; int audiovideo=0; int buffer_size; int fps; } BFIContext; The problematic statements look like this: url_fseek(pb,bfi->chunk_header + bfi->video_offset, SEEK_SET); bfi->audiovideo = 1; /* Video to be read next. */ ----------------- Sisir Koppaka
Sisir Koppaka wrote: [...] The problem isn't immediately obvious to me (and I seem to be the only one on duty on this list this late). Attach the whole file if you haven't solved it already so we can get the full context.
bfi->audiovideo = 1; /* Video to be read next. */
But I can tell you that this is among the worst kind of variable names. Something along the lines of "boolean onOrOff = 1"... huh? What does 1 mean? -- -Mike Melanson
On Sat, Mar 22, 2008 at 11:26 AM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote: [...] The problem isn't immediately obvious to me (and I seem to be the only one on duty on this list this late). Attach the whole file if you haven't solved it already so we can get the full context.
On removing the assignment operations in the declaration of the typedef struct, all the errors were gone...now i'm doing those assignments in the read_header()
bfi->audiovideo = 1; /* Video to be read next. */
But I can tell you that this is among the worst kind of variable names. Something along the lines of "boolean onOrOff = 1"... huh? What does 1 mean?
:) It's a toggle switch, 0 indicates that audio has to be read and 1 indicates that video has to be read. Will change the variable names to more appropriate ones soon. Right now, I'm getting a wierd error with the decoder part. In my demuxer, the read_video() is mostly dummy as of now and the /libavcodec/bfi.c is mostly dummy as well. But I've registered the decoder and put the initialization of bfi_decoder as follows: AVCodec bfi_decoder = { .name = "bfi", .type = CODEC_TYPE_VIDEO, .id = CODEC_ID_BFI, .priv_data_size = sizeof(BFIContext), .init = bfi_decode_init, .close = bfi_decode_close, .decode = bfi_decode_frame, }; The error I'm getting is that : In function `avcodec_register_all': /libavcodec/allcodecs.c:69: undefined reference to `bfi_decoder' Does this happen if the decoder is incomplete? ----------------- Sisir Koppaka
wierd->weird, typo! ----------------- Sisir Koppaka
Sisir Koppaka wrote:
On removing the assignment operations in the declaration of the typedef struct, all the errors were gone...now i'm doing those assignments in the read_header()
I didn't catch that before. I wouldn't have even thought that would compile, now that you point it out.
The error I'm getting is that : In function `avcodec_register_all': /libavcodec/allcodecs.c:69: undefined reference to `bfi_decoder'
Are you building your BFI video decoder? -- -Mike Melanson
Sisir Koppaka wrote:
The error I'm getting is that : In function `avcodec_register_all': /libavcodec/allcodecs.c:69: undefined reference to `bfi_decoder'
Are you building your BFI video decoder?
Yes, I am. (It is part of the qualification task, right?)
Let's try a different wording: Are you instructing the build system to use the C compiler to actually compile your BFI video decoder source code file into an object file via libavcodec/Makefile? -- -Mike Melanson
On Sat, Mar 22, 2008 at 1:30 PM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
The error I'm getting is that : In function `avcodec_register_all': /libavcodec/allcodecs.c:69: undefined reference to `bfi_decoder'
Are you building your BFI video decoder?
Yes, I am. (It is part of the qualification task, right?)
Let's try a different wording: Are you instructing the build system to use the C compiler to actually compile your BFI video decoder source code file into an object file via libavcodec/Makefile?
:) No, I don't think so. What am I supposed to put in there? ----------------- Sisir Koppaka
Sisir Koppaka wrote:
On Sat, Mar 22, 2008 at 1:30 PM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
The error I'm getting is that : In function `avcodec_register_all': /libavcodec/allcodecs.c:69: undefined reference to `bfi_decoder'
Are you building your BFI video decoder?
Yes, I am. (It is part of the qualification task, right?) Let's try a different wording: Are you instructing the build system to use the C compiler to actually compile your BFI video decoder source code file into an object file via libavcodec/Makefile?
:) No, I don't think so. What am I supposed to put in there?
Study it. Find the patterns. Use the art of copy & pasting like you have been doing with the rest of the project. Be advised that after modifying the makefile, you may need to do 'make distclean' and then re-run the configure script. -- -Mike Melanson
:) OK. ----------------- Sisir Koppaka
Everything compiles OK now, but I have a nice Segmentation fault(core dumped) to debug now....(occurs on running ffmpeg -i 2287.bfi) At least the thing compiled. :) I've used gdb with small sized programs before, but how to use it with ffmpeg? Any tips? ----------------- Sisir Koppaka
Also, compiling and installing ffmpeg doesn't seem to install ffplay...how do we do that? ----------------- Sisir Koppaka
At last! sisir@sisir-laptop:~/Desktop/bfi$ ffmpeg -i 2287.bfi FFmpeg version SVN-r2, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: libavutil version: 49.6.0 libavcodec version: 51.52.0 libavformat version: 52.11.0 libavdevice version: 52.0.0 built on Mar 22 2008 02:11:13, gcc: 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Somewhat works Now? frames :57 Somewhat works Palette is now set. Reading audio now... Reading video now... [Inserted comment - 'Reading video now...' appeared many times(56, I think) here] Reading video now...Input #0, bfi, from '2287.bfi': Duration: 00:03:42.2, start: 0.100000, bitrate: 31 kb/s Stream #0.0: Video: bfi, pal8, 320x140, 100.00 tb(r) Stream #0.1: Audio: pcm_u8, 3906 Hz, mono, 31 kb/s Must supply at least one output file Reading audio now/video now etc. are debugging messages. The segmentation fault was apparently because of unnecessary pointer assignment. At least all the info's displaying well enough :) and now, how do I play the file(to test the audio stream) when ffplay is not installing when I compile ffmpeg. -- ----------------- Sisir Koppaka
Sisir Koppaka wrote: [...]
Stream #0.1: Audio: pcm_u8, 3906 Hz, mono, 31 kb/s
Err, 3906 Hz is not a sane playback frequency. Read this article for sane PCM properties: http://wiki.multimedia.cx/index.php?title=PCM I examined 2287.bfi and the correct sample rate is in there. You must have read the wrong offset.
Must supply at least one output file
Reading audio now/video now etc. are debugging messages. The segmentation fault was apparently because of unnecessary pointer assignment. At least all the info's displaying well enough :) and now, how do I play the file(to test the audio stream) when ffplay is not installing when I compile ffmpeg.
Congratulations on your progress. BTW, if you want to feed anything to gdb, use 'ffmpeg_g'. That has debugging symbols. 'ffmpeg' is the stipped, "release" version of the same binary. Check your main build directory. There is an ffmpeg binary there. Is there an ffplay binary there as well? If so, then use it as './ffplay <file.bfi>' and report a bug that it doesn't get installed. However, I suspect ffplay is not there. That means it's not being built. That probably means you don't have SDL installed. Figure it out from there. Another way to test if you are demuxing the sound correctly: ffmpeg -i <file.bfi> <file.wav> Then play the WAV file with another media player. -- -Mike Melanson
On Sat, Mar 22, 2008 at 9:16 PM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote: [...]
Stream #0.1: Audio: pcm_u8, 3906 Hz, mono, 31 kb/s
Err, 3906 Hz is not a sane playback frequency. Read this article for sane PCM properties:
http://wiki.multimedia.cx/index.php?title=PCM
I examined 2287.bfi and the correct sample rate is in there. You must have read the wrong offset.
Checking up this now...Do you use vim for examining the file? I can only recognize a few things like headers...if you could elaborate a bit on examining the files better, it'd help me a lot with the reading of the chunks because the wiki specs are a bit vague on the content of the headers etc...which is making me declare extra toggle variables and all instead of just searching for the header to detect a new chunk.
Must supply at least one output file
Reading audio now/video now etc. are debugging messages. The segmentation fault was apparently because of unnecessary pointer assignment. At least all the info's displaying well enough :) and now, how do I play the file(to test the audio stream) when ffplay is not installing when I compile ffmpeg.
Congratulations on your progress. BTW, if you want to feed anything to gdb, use 'ffmpeg_g'. That has debugging symbols. 'ffmpeg' is the stipped, "release" version of the same binary.
Thanks a lot! If it weren't for you and the wonderful people in the FFmpeg community who have so graciously spent so much time clarifying my every single doubt, I couldn't have come this far. It's been a helluva ride(except that sig fault part, but yeah that's what makes the ride worth it, I guess :) ) so far, and I hope it stays that way till the end!
Check your main build directory. There is an ffmpeg binary there. Is there an ffplay binary there as well? If so, then use it as './ffplay <file.bfi>' and report a bug that it doesn't get installed.
No, there isn't a ffplay binary, though I can see the ffmpeg, ffmpeg_g, ffserver and ffserver_g binaries. In fact, ffplay doesn't seem to have compiled, there isn't an object file for it.
However, I suspect ffplay is not there. That means it's not being built. That probably means you don't have SDL installed. Figure it out from there.
Doing this...
Another way to test if you are demuxing the sound correctly:
ffmpeg -i <file.bfi> <file.wav>
Then play the WAV file with another media player.
Will test after debugging the PCM frequency offset issue. ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Checking up this now...Do you use vim for examining the file? I can only recognize a few things like headers...if you could elaborate a bit on examining the files better, it'd help me a lot with the reading of the
Learn how to use a hex editor. I always use the simple ncurses-based 'hexedit' program from a terminal: http://www.chez.com/prigaux/hexedit.html Check your package management system. If you are using KDE, you might like KHexEdit.
Thanks a lot! If it weren't for you and the wonderful people in the FFmpeg community who have so graciously spent so much time clarifying my every single doubt, I couldn't have come this far. It's been a helluva ride(except that sig fault part, but yeah that's what makes the ride worth it, I guess :) ) so far, and I hope it stays that way till the end!
If it's a repeatable segfault, 'gdb ffmpeg_g' should lead you straight to the problem. Also investigate the valgrind memory checking utility. -- -Mike Melanson
Thanks! ----------------- Sisir Koppaka
On Sat, Mar 22, 2008 at 9:16 PM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote: [...]
Stream #0.1: Audio: pcm_u8, 3906 Hz, mono, 31 kb/s
Err, 3906 Hz is not a sane playback frequency. Read this article for sane PCM properties:
http://wiki.multimedia.cx/index.php?title=PCM
I examined 2287.bfi and the correct sample rate is in there. You must have read the wrong offset.
I changed one of the get_byte() I used to a url_fseek(pb,bfi->chunk_header+bfi->audio_offset,SEEK_SET); Now the output is: Input #0, bfi, from '/home/sisir/Desktop/bfi/2287.bfi': Duration: 00:02:38.8, start: 0.100000, bitrate: 43 kb/s Stream #0.0: Video: bfi, pal8, 320x140, 100.00 tb(r) Stream #0.1: Audio: pcm_u8, 5464 Hz, mono, 43 kb/s Still, it's not one of those listed sane frequencies in the wiki. I put the SDL libs in the build directory and changed ffplay.c's sdl header includes to their respective paths. Yet, it didn't compile. This was a pretty stupid thing to do :), I think because the configure script seems to search and decide for the SDL headers and it doesn't find them even now :) Can you tell me where exactly to put the SDL headers? I don't know if gcc has a PATH variable... -- ----------------- Sisir Koppaka
Sisir Koppaka wrote:
I changed one of the get_byte() I used to a url_fseek(pb,bfi->chunk_header+bfi->audio_offset,SEEK_SET); Now the output is: Input #0, bfi, from '/home/sisir/Desktop/bfi/2287.bfi': Duration: 00:02:38.8, start: 0.100000, bitrate: 43 kb/s Stream #0.0: Video: bfi, pal8, 320x140, 100.00 tb(r) Stream #0.1: Audio: pcm_u8, 5464 Hz, mono, 43 kb/s
Still, it's not one of those listed sane frequencies in the wiki.
Are you actually reading the sample rate from the file? I can't find that number in hex encoded anywhere in little endian format. However, when I open up the 2287.bfi in a hex editor and travel to the offset that the BFI spec indicates is the location of the sample rate, I get a sane value.
I put the SDL libs in the build directory and changed ffplay.c's sdl header includes to their respective paths. Yet, it didn't compile. This was a pretty stupid thing to do :), I think because the configure script seems to search and decide for the SDL headers and it doesn't find them even now :)
"Install SDL". After doing this, FFmpeg's build system should just find it. Are you experienced at all with installing software on Linux? -- -Mike Melanson
I put the SDL libs in the build directory and changed ffplay.c's sdl header includes to their respective paths. Yet, it didn't compile. This was a pretty stupid thing to do :), I think because the configure script seems to search and decide for the SDL headers and it doesn't find them even now :)
"Install SDL". After doing this, FFmpeg's build system should just find it. Are you experienced at all with installing software on Linux?
I already install libsdl1.2debian from the Ubuntu repos. Maybe it's the libsdl1.2-dev package that's needed. Trying that now. ----------------- Sisir Koppaka
install->installed ----------------- Sisir Koppaka
Sisir Koppaka wrote:
I already install libsdl1.2debian from the Ubuntu repos. Maybe it's the libsdl1.2-dev package that's needed. Trying that now.
Yes, this makes sense. Be sure to re-run configure in FFmpeg after installing SDL. And look for a line indicating that SDL was found. -- -Mike Melanson
On Sat, Mar 22, 2008 at 11:28:35AM -0700, Mike Melanson wrote:
Sisir Koppaka wrote:
I put the SDL libs in the build directory and changed ffplay.c's sdl header includes to their respective paths. Yet, it didn't compile. This was a pretty stupid thing to do :), I think because the configure script seems to search and decide for the SDL headers and it doesn't find them even now :)
"Install SDL". After doing this, FFmpeg's build system should just find it. Are you experienced at all with installing software on Linux?
Maybe we should state this as a clear requirement on the SoC page. "You should have basic experience installing and compiling software on Linux. As a minimum, you should be able to compile FFmpeg successfully with all the extra options." Diego
I have finished coding the BFI subsystem by now, problem is that it's not playing anything on runtime(It just hangs). I'm not sure where exactly it's hanging, I'm going to investigate that later today. I assume this is because of my confusion with some of the functions etc., but the structure and most code is there. Once I become clear w.r.t. the unclear parts, I'll send over the patch. 1) Right now, the BFI specs in the wiki are not clear about the header of the chunks. Though by using hexedit, it appears that the header is always IVAS, I haven't taken any risk about this and instead coded a version of the decompression algo within the demuxer to count the no. of pixels and once the reqd. no. of pixels is reached, it locates the next chunk and proceeds again. 2) Also, in the decoder, when we send the uncompressed bytes to the output, do we have to take care about it's actual position in the frame where the byte will go, or will ffmpeg decide automatically that after the last pixel of the first line is completed, then go to the first pixel of the second line and so on? 3) I'm setting my palette in the demuxer, but some of the other codecs I've seen are setting theirs in the decoder. The specs of some of these codecs that I've checked out say that the palette may be put anywhere and there may even be a palette for every frame. The BFI specs seem to imply that there's only one palette for the whole file, so I'm setting that in the demuxer instead of doing that in the decoder. Please clarify if this is the right way to proceed. 4) I'm in complete confusion about the bufferstream_get_buffer(and related), the memcpy(and related like memset), the reget_buffer(and related functions) mainly in their usage and the form of the parameters that must be passed( like dst or &dst where dst is already a pointer) Also, Mike said previously in this list : Before you pass the RGB components to FFmpeg, you will need to scale them to be 8-bit components. But where and why do we do that? In the decoder, as of now, I'm just passing the decompressed bytes one by one(assuming each one stands for a pixel), I'm not sure how to interpret and implement Mike's statement in this context... ----------------- Sisir Koppaka
Sisir Koppaka wrote:
I have finished coding the BFI subsystem by now, problem is that it's not playing anything on runtime(It just hangs). I'm not sure where exactly it's hanging, I'm going to investigate that later today. I assume this is because of my confusion with some of the functions etc., but the structure and most code is there. Once I become clear w.r.t. the unclear parts, I'll send over the patch.
1) Right now, the BFI specs in the wiki are not clear about the header of the chunks. Though by using hexedit, it appears that the header is always IVAS, I haven't taken any risk about this and instead coded a version of the decompression algo within the demuxer to count the no. of pixels and once the reqd. no. of pixels is reached, it locates the next chunk and proceeds again.
Good idea. Indeed, it always seems to be IVAS.
2) Also, in the decoder, when we send the uncompressed bytes to the output, do we have to take care about it's actual position in the frame where the byte will go, or will ffmpeg decide automatically that after the last pixel of the first line is completed, then go to the first pixel of the second line and so on?
I think you're talking about frame width vs. stride here. Width != stride. Width is the width of a decoded video frame. Stride is the width of the video buffer that you are outputting to. This is the linesize[] array in the AVFrame.
3) I'm setting my palette in the demuxer, but some of the other codecs I've seen are setting theirs in the decoder. The specs of some of these codecs that I've checked out say that the palette may be put anywhere and there may even be a palette for every frame. The BFI specs seem to imply that there's only one palette for the whole file, so I'm setting that in the demuxer instead of doing that in the decoder. Please clarify if this is the right way to proceed.
Transport the palette from the demuxer -> decoder and then set the palette for the video frame in the decoder.
4) I'm in complete confusion about the bufferstream_get_buffer(and related), the memcpy(and related like memset), the reget_buffer(and related functions) mainly in their usage and the form of the parameters that must be passed( like dst or &dst where dst is already a pointer)
Not sure about this question. All I can recommend is following the model laid out in other decoders. I would recommend libavcodec/smacker.c since (I think) it is probably doing things as expected.
Also, Mike said previously in this list : Before you pass the RGB components to FFmpeg, you will need to scale them to be 8-bit components.
But where and why do we do that? In the decoder, as of now, I'm just passing the decompressed bytes one by one(assuming each one stands for a pixel), I'm not sure how to interpret and implement Mike's statement in this context...
I need to do a blog post on this matter, with big pictures. When you are done decompressing a video frame, you will have an array of bytes. This will double as an array of 8-bit palette indices. Each index references into the 256-entry palette table. Each palette table entry has 3 elements: 6-bit R, 6-bit G, and 6-bit B. If you pass those 6-bit components along, the final image will be too dark. That's why those 6-bit components needs to be scaled to 8-bit components. -- -Mike Melanson
Hi, Good to be back after the exams. I have a couple of doubts: 1) What is the AV_RB24 function? It's used for the palette handling in some decoders. 2) The bytes that we get back from the frame chunks...those are 8 bits...how does the computer know that this type of byte corresponds to this entry in the palette? ----------------- Sisir Koppaka
Also why are data and linesize declared are size 4 arrays in avcodec.h? ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Also why are data and linesize declared are size 4 arrays in avcodec.h?
Because some video codecs operate in more than one plane. In fact, many operate in 3. You will only need 1, however. -- -Mike Melanson
Sisir Koppaka wrote:
Hi, Good to be back after the exams. I have a couple of doubts: 1) What is the AV_RB24 function? It's used for the palette handling in some decoders.
A: audio V: video _: separator R: read B: big-endian 24: 24-bit AV_RB24 reads the next 3 bytes in the bytestream and interprets them as a 24-bit integer.
2) The bytes that we get back from the frame chunks...those are 8 bits...how does the computer know that this type of byte corresponds to this entry in the palette?
Because you told it so. -- -Mike Melanson
On Tue, Mar 25, 2008 at 10:49 PM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
Hi, Good to be back after the exams. I have a couple of doubts: 1) What is the AV_RB24 function? It's used for the palette handling in some decoders.
A: audio V: video _: separator R: read B: big-endian 24: 24-bit
AV_RB24 reads the next 3 bytes in the bytestream and interprets them as a 24-bit integer.
Is it safe for me to assume that the BFI format's bytes in the palette are big endian? I've been using little endian for all the other bytes. ----------------- Sisir Koppaka
Does calling av_new_packet or av_get_packet automatically send over the packet to the decoder? ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Does calling av_new_packet or av_get_packet automatically send over the packet to the decoder?
I don't know off the top of my head. It really shouldn't matter from the perspective of the decoder. -- -Mike Melanson
One more doubt :) Is it necessary to set the palette once per frame in the decoder or doing it once for all the frames will suffice? ----------------- Sisir Koppaka
Hello, On Tue, Mar 25, 2008 at 11:35:44PM +0530, Sisir Koppaka wrote:
One more doubt :) Is it necessary to set the palette once per frame in the decoder or doing it once for all the frames will suffice?
Palette behaves just like any other part of the frame (it is just another plane, no special handling really): If you set FF_BUFFER_HINTS_PRESERVE it will be the same as for the last frame, if not it is uninitialized initially and you have to set it again. And no, IMO you should not set FF_BUFFER_HINTS_PRESERVE just because of the palette. Greetings, Reimar Döffinger
I have to send over the palette from the demuxer to the decoder. But problem is unlike most other codecs I've reviewed, BFI doesn't provide a header for it's palette, which is causing some problem in letting the decoder know whether the incoming buffer contains a palette or a frame. I thought of inserting a 32 bit identifier before the palette values like MKTAG('P','A','L','E') in the palette buffer so that the decoder can understand it's type. I'm however, not very sure of the endianness and the correct way of reading this identifier in the decoder(Should it be bytestream_get_be24 or bytestream_get_le24?). Or is there a better way like a struct that is common to both the demuxer and decoder to place a toggle variable? ----------------- Sisir Koppaka
I've been trying to debug why the audio wasn't working...and wrote a simple demuxer only for the audio with a lot of info messages. The output on a sample file is as follows: FFplay version UNKNOWN, Copyright (c) 2003-2008 Fabrice Bellard, et al. configuration: libavutil version: 49.6.0 libavcodec version: 51.52.0 libavformat version: 52.11.0 libavdevice version: 52.0.0 built on Mar 25 2008 11:24:56, gcc: 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Finished reading the headers....starting to read the chunks... Found a chunk... Chunk number 43 confirmed with IVAS identifier... Audio offset is 1162 Video offset is 24 Reading audio of this chunk... Sending -1138 bytes to the decoder... Found a chunk... Chunk number 42 confirmed with IVAS identifier... Audio offset is 1162 Video offset is 24 Reading audio of this chunk... Sending -1138 bytes to the decoder... Found a chunk... Chunk number 41 confirmed with IVAS identifier... Audio offset is 1160 Video offset is 24 Reading audio of this chunk... Sending -1136 bytes to the decoder... Found a chunk... Chunk number 40 confirmed with IVAS identifier... Audio offset is 1160 Video offset is 24 Reading audio of this chunk... Sending -1136 bytes to the decoder... Found a chunk... Chunk number 39 confirmed with IVAS identifier... Audio offset is 5164 Video offset is 24 Reading audio of this chunk... Sending -5140 bytes to the decoder... Found a chunk... Chunk number 38 confirmed with IVAS identifier... Audio offset is 16496 Video offset is 24 Reading audio of this chunk... Sending -16472 bytes to the decoder... Found a chunk... Chunk number 37 confirmed with IVAS identifier... Audio offset is 22135 Video offset is 24 Reading audio of this chunk... Sending -22111 bytes to the decoder... Found a chunk... Chunk number 36 confirmed with IVAS identifier... Audio offset is 16741 Video offset is 24 Reading audio of this chunk... Sending -16717 bytes to the decoder... Found a chunk... Chunk number 35 confirmed with IVAS identifier... Audio offset is 10110 Video offset is 24 Reading audio of this chunk... Sending -10086 bytes to the decoder... Found a chunk... Chunk number 34 confirmed with IVAS identifier... Audio offset is 10746 Video offset is 24 Reading audio of this chunk... Sending -10722 bytes to the decoder... Found a chunk... Chunk number 33 confirmed with IVAS identifier... Audio offset is 9754 Video offset is 24 Reading audio of this chunk... Sending -9730 bytes to the decoder... Found a chunk... Chunk number 32 confirmed with IVAS identifier... Audio offset is 10071 Video offset is 24 Reading audio of this chunk... Sending -10047 bytes to the decoder... Found a chunk... Chunk number 31 confirmed with IVAS identifier... Audio offset is 10210 Video offset is 24 Reading audio of this chunk... Sending -10186 bytes to the decoder... Found a chunk... Chunk number 30 confirmed with IVAS identifier... Audio offset is 11220 Video offset is 24 Reading audio of this chunk... Sending -11196 bytes to the decoder... Found a chunk... Chunk number 29 confirmed with IVAS identifier... Audio offset is 10807 Video offset is 24 Reading audio of this chunk... Sending -10783 bytes to the decoder... Found a chunk... Chunk number 28 confirmed with IVAS identifier... Audio offset is 11351 Video offset is 24 Reading audio of this chunk... Sending -11327 bytes to the decoder... Found a chunk... Chunk number 27 confirmed with IVAS identifier... Audio offset is 9825 Video offset is 24 Reading audio of this chunk... Sending -9801 bytes to the decoder... Found a chunk... Chunk number 26 confirmed with IVAS identifier... Audio offset is 9957 Video offset is 24 Reading audio of this chunk... Sending -9933 bytes to the decoder... Found a chunk... Chunk number 25 confirmed with IVAS identifier... Audio offset is 9232 Video offset is 24 Reading audio of this chunk... Sending -9208 bytes to the decoder... Found a chunk... Chunk number 24 confirmed with IVAS identifier... Audio offset is 9201 Video offset is 24 Reading audio of this chunk... Sending -9177 bytes to the decoder... Found a chunk... Chunk number 23 confirmed with IVAS identifier... Audio offset is 9282 Video offset is 24 Reading audio of this chunk... Sending -9258 bytes to the decoder... Found a chunk... Chunk number 22 confirmed with IVAS identifier... Audio offset is 9749 Video offset is 24 Reading audio of this chunk... Sending -9725 bytes to the decoder... Found a chunk... Chunk number 21 confirmed with IVAS identifier... Audio offset is 8694 Video offset is 24 Reading audio of this chunk... Sending -8670 bytes to the decoder... Found a chunk... Chunk number 20 confirmed with IVAS identifier... Audio offset is 8971 Video offset is 24 Reading audio of this chunk... Sending -8947 bytes to the decoder... Found a chunk... Chunk number 19 confirmed with IVAS identifier... Audio offset is 9162 Video offset is 24 Reading audio of this chunk... Sending -9138 bytes to the decoder... Found a chunk... Chunk number 18 confirmed with IVAS identifier... Audio offset is 9301 Video offset is 24 Reading audio of this chunk... Sending -9277 bytes to the decoder... Found a chunk... Chunk number 17 confirmed with IVAS identifier... Audio offset is 10123 Video offset is 24 Reading audio of this chunk... Sending -10099 bytes to the decoder... Found a chunk... Chunk number 16 confirmed with IVAS identifier... Audio offset is 10566 Video offset is 24 Reading audio of this chunk... Sending -10542 bytes to the decoder... Found a chunk... Chunk number 15 confirmed with IVAS identifier... Audio offset is 8904 Video offset is 24 Reading audio of this chunk... Sending -8880 bytes to the decoder... Found a chunk... Chunk number 14 confirmed with IVAS identifier... Audio offset is 8688 Video offset is 24 Reading audio of this chunk... Sending -8664 bytes to the decoder... Found a chunk... Chunk number 13 confirmed with IVAS identifier... Audio offset is 8856 Video offset is 24 Reading audio of this chunk... Sending -8832 bytes to the decoder... Found a chunk... Chunk number 12 confirmed with IVAS identifier... Audio offset is 9082 Video offset is 24 Reading audio of this chunk... Sending -9058 bytes to the decoder... Found a chunk... Chunk number 11 confirmed with IVAS identifier... Audio offset is 10015 Video offset is 24 Reading audio of this chunk... Sending -9991 bytes to the decoder... Found a chunk... Chunk number 10 confirmed with IVAS identifier... Audio offset is 10264 Video offset is 24 Reading audio of this chunk... Sending -10240 bytes to the decoder... Found a chunk... Chunk number 9 confirmed with IVAS identifier... Audio offset is 9169 Video offset is 24 Reading audio of this chunk... Sending -9145 bytes to the decoder... Found a chunk... Chunk number 8 confirmed with IVAS identifier... Audio offset is 9638 Video offset is 24 Reading audio of this chunk... Sending -9614 bytes to the decoder... Found a chunk... Chunk number 7 confirmed with IVAS identifier... Audio offset is 6277 Video offset is 24 Reading audio of this chunk... Sending -6253 bytes to the decoder... Found a chunk... Chunk number 6 confirmed with IVAS identifier... Audio offset is 6139 Video offset is 24 Reading audio of this chunk... Sending -6115 bytes to the decoder... Found a chunk... Chunk number 5 confirmed with IVAS identifier... Audio offset is 5747 Video offset is 24 Reading audio of this chunk... Sending -5723 bytes to the decoder... Found a chunk... Chunk number 4 confirmed with IVAS identifier... Audio offset is 5988 Video offset is 24 Reading audio of this chunk... Sending -5964 bytes to the decoder... Found a chunk... Chunk number 3 confirmed with IVAS identifier... Audio offset is 5794 Video offset is 24 Reading audio of this chunk... Sending -5770 bytes to the decoder... Found a chunk... Chunk number 2 confirmed with IVAS identifier... Audio offset is 5778 Video offset is 24 Reading audio of this chunk... Sending -5754 bytes to the decoder... Found a chunk... Chunk number 1 confirme be d with IVAS identifier... Audio offset is 8654 Video offset is 24 Reading audio of this chunk... Sending -8630 bytes to the decoder... All frames are now done! Surprisingly, the audio and video offsets displayed seem to be unusual according to the specs in the wiki. The audio offsets and the video offsets seem to be opposite to what is mentioned in the wiki. Can anyone please confirm if the specs in the wiki are 100% right? ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Sending -1138 bytes to the decoder... [...] Sending -1138 bytes to the decoder... [...] Sending -1136 bytes to the decoder... [...] Sending -1136 bytes to the decoder... [...] Sending -5140 bytes to the decoder...
Something about this seems off... I can't put my finger on it exactly. -- -Mike Melanson
The negative values are because bfi-> remaining_size = bfi->video_offset - bfi->audio_offset as mentioned in the BFI specs and now that the video offset is always occuring at 24 and before the audio offset, the remaining_size variable is turning negative. This -ve value is being passed to the PCM decoder and hence, the decoder is not outputting any sound. Assuming, that there are no logical errors in the above code, I think this is the situation. Are you sure about the accuracy of the BFI specs? ----------------- Sisir Koppaka
Finally!!!! The audio demuxer is working and outputs sound perfectly....for example, now I know that the the man in 5081.bfi says 'Don't make me come looking for you!' :) I really want to thank Mike who's been helping out a lot and was responsible for clearing up a lot of confusion over the BFI specs. BTW, I found one more spec that was probably missed out and is not present in the wiki - while the first four bytes of the chunk header contain IVAS, the next four bytes contain the chunk size...which makes it very easy in the code to find the next chunk....I couldn't have even thought of looking for these four bytes in the hex editor had Mike not told me that the header is 8 bytes long and not 4 bytes long as I had assumed... Now, I've got another test to give! What am I doing at my computer??? :) ----------------- Sisir Koppaka
Is it advisable to break the audio data of a chunk into smaller packets while doing av_get_packet or is it ok to send the whole audio data as one packet? I've seen some demuxers which are sending a minimum of (remaining_size, 2048) whichever is smaller, in one packet and some which seem to be sending the whole thing at once... Same question for the video data as well. ----------------- Sisir Koppaka
On Fri, Mar 28, 2008 at 05:53:10PM +0530, Sisir Koppaka wrote:
Is it advisable to break the audio data of a chunk into smaller packets while doing av_get_packet or is it ok to send the whole audio data as one packet? I've seen some demuxers which are sending a minimum of (remaining_size, 2048) whichever is smaller, in one packet and some which seem to be sending the whole thing at once... Same question for the video data as well.
Its ok to send the whole in case of BFI. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin
Thanks! ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Finally!!!! The audio demuxer is working and outputs sound perfectly....for example, now I know that the the man in 5081.bfi says 'Don't make me come looking for you!' :) I really want to thank Mike who's been helping out a lot and was responsible for clearing up a lot of confusion over the BFI specs. BTW, I found one more spec that was probably missed out and is not present in the wiki - while the first four bytes of the chunk header contain IVAS, the next four bytes contain the chunk size...which makes it very easy in the code to find the next chunk....I couldn't have even thought of looking for these four bytes in the hex editor had Mike not told me that the header is 8 bytes long and not 4 bytes long as I had assumed...
Glad to hear that you are making progress. BTW, you have a MultimediaWiki account-- please update the BFI spec as you find mistakes, omissions, or areas that can be clarified. Thanks... -- -Mike Melanson
Hi, I'm passing the palette using extradata to the decoder. 1)Do I have to do this for every frame? BFI has the same palette for all the frames. Will extradata be refreshed to 0 after every frame by ffmpeg? 2)I'm assuming that in the decoder, I have to put the palette into data[1](based on the code that I read) and the frame's actual contents into data[0]. Is this right? 3) Do I have to set the palette in the decoder for every frame? Or will doing it the first time suffice? ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Hi, I'm passing the palette using extradata to the decoder. 1)Do I have to do this for every frame? BFI has the same palette for all the frames. Will extradata be refreshed to 0 after every frame by ffmpeg?
I'm going to say 'no' on this one. Actually, once your decoder has the palette from the demuxer, the decoder can do what it wants with the data. Neither he demuxer nor the engine have a say in the matter.
2)I'm assuming that in the decoder, I have to put the palette into data[1](based on the code that I read) and the frame's actual contents into data[0]. Is this right?
Sounds good.
3) Do I have to set the palette in the decoder for every frame? Or will doing it the first time suffice?
I can't remember exactly. You will probably see both methods if you look at enough decoders. Try setting the palette on each frame. It probably won't hurt. -- -Mike Melanson
On Sat, Mar 29, 2008 at 11:18:49AM +0530, Sisir Koppaka wrote:
Hi, I'm passing the palette using extradata to the decoder. 1)Do I have to do this for every frame? BFI has the same palette for all the frames. Will extradata be refreshed to 0 after every frame by ffmpeg?
No, extradata must remain unchanged over all the time. But please note (in case you are not aware) that extradata may not be endian specific (since that would break remuxing), so it might still make sense to make a copy in your decoder so you have the native-endian form ready (in case you set the palette every frame).
2)I'm assuming that in the decoder, I have to put the palette into data[1](based on the code that I read) and the frame's actual contents into data[0]. Is this right?
Yes.
3) Do I have to set the palette in the decoder for every frame? Or will doing it the first time suffice?
If you set FF_BUFFER_HINTS_PRESERVE | FF_BUFFER_HINTS_REUSABLE and always use the same AVFrame: no. But you should only do this if there is a reason for it besides the palette, e.g. because previous frames are reused or whatever. Greetings, Reimar Döffinger
Thanks! On Sat, Mar 29, 2008 at 2:39 PM, Reimar Döffinger < Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hi, I'm passing the palette using extradata to the decoder. 1)Do I have to do this for every frame? BFI has the same palette for all
On Sat, Mar 29, 2008 at 11:18:49AM +0530, Sisir Koppaka wrote: the
frames. Will extradata be refreshed to 0 after every frame by ffmpeg?
No, extradata must remain unchanged over all the time. But please note (in case you are not aware) that extradata may not be endian specific (since that would break remuxing), so it might still make sense to make a copy in your decoder so you have the native-endian form ready (in case you set the palette every frame).
But since we're putting the bytes into extradata and we're reading from it again...can't we control the endianness here? I mean, since we're storing them there, wouldn't the way we suppose they should be decoded be the right way? I couldn't get the part about breaking remuxing...can you please expand on it a bit more? ----------------- Sisir Koppaka
On Sat, Mar 29, 2008 at 03:23:49PM +0530, Sisir Koppaka wrote:
Thanks! On Sat, Mar 29, 2008 at 2:39 PM, Reimar Döffinger < Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
Hi, I'm passing the palette using extradata to the decoder. 1)Do I have to do this for every frame? BFI has the same palette for all
On Sat, Mar 29, 2008 at 11:18:49AM +0530, Sisir Koppaka wrote: the
frames. Will extradata be refreshed to 0 after every frame by ffmpeg?
No, extradata must remain unchanged over all the time. But please note (in case you are not aware) that extradata may not be endian specific (since that would break remuxing), so it might still make sense to make a copy in your decoder so you have the native-endian form ready (in case you set the palette every frame).
But since we're putting the bytes into extradata and we're reading from it again...can't we control the endianness here?
no
I mean, since we're storing them there, wouldn't the way we suppose they should be decoded be the right way? I couldn't get the part about breaking remuxing...can you please expand on it a bit more?
BFI-demux -> AVI-mux -> CD-R -later-and-different-computer-> AVI-demux -> BFI-decode [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates
Each component of the BFI palette is 6 bits long...so I'm assuming the palette entries to be of the form [bbbbbbgg ggggrr rrrr][bb bbbbgg ggggrr rrrr]bb bbbb and so on....is this correct? It's going to be a helluva job demuxing this palette :) Why couldn't they just make it 8 bits! :) ----------------- Sisir Koppaka
On Sun, Mar 30, 2008 at 12:16 AM, Sisir Koppaka <sisir.koppaka@gmail.com> wrote:
Each component of the BFI palette is 6 bits long...so I'm assuming the palette entries to be of the form [bbbbbbgg ggggrr rrrr][bb bbbbgg ggggrr rrrr]bb bbbb and so on....is this correct? It's going to be a helluva job demuxing this palette :) Why couldn't they just make it 8 bits! :)
bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values) They've allotted 256*3 bytes, so most probably they're storing it this way - 00bbbbbb 00gggggg 00rrrrrr and so on... Would this interpretation of the endianness be correct? Some of the codecs seem to be having the palette ordered differently from the rest of the file. Correction above: I meant to write [bbbbbbgg ggggrrrr rr][bbbbbb ggggggrr rrrr]bbbb bb....not what was written above...misplaced the bits. ----------------- Sisir Koppaka
Sisir Koppaka wrote:
On Sun, Mar 30, 2008 at 12:16 AM, Sisir Koppaka <sisir.koppaka@gmail.com> wrote:
Each component of the BFI palette is 6 bits long...so I'm assuming the palette entries to be of the form [bbbbbbgg ggggrr rrrr][bb bbbbgg ggggrr rrrr]bb bbbb and so on....is this correct? It's going to be a helluva job demuxing this palette :) Why couldn't they just make it 8 bits! :)
bytes 60-827 ( +3C) 256 RGB triplets (6-bit VGA palette values)
They've allotted 256*3 bytes, so most probably they're storing it this way - 00bbbbbb 00gggggg 00rrrrrr and so on... Would this interpretation of the endianness be correct? Some of the codecs seem to be having the palette ordered differently from the rest of the file.
Correction above: I meant to write [bbbbbbgg ggggrrrr rr][bbbbbb ggggggrr rrrr]bbbb bb....not what was written above...misplaced the bits.
byte 0 byte 1 byte 2 byte 3 ... 00rrrrrr 00gggggg 00bbbbbb 00rrrrrr ... -- -Mike Melanson
byte 0 byte 1 byte 2 byte 3 ... 00rrrrrr 00gggggg 00bbbbbb 00rrrrrr ...
Oh...I thought the r, g, b for each pixel were arranged little endianly....k...Thanks! ----------------- Sisir Koppaka
Sisir Koppaka wrote:
byte 0 byte 1 byte 2 byte 3 ... 00rrrrrr 00gggggg 00bbbbbb 00rrrrrr ...
Oh...I thought the r, g, b for each pixel were arranged little endianly....k...Thanks!
The difference is that these palettes are treated as arrays of independent bytes, not multi-byte numbers for which endianness must be considered. -- -Mike Melanson
Thanks! ----------------- Sisir Koppaka
From the BFI video decompression algo:
2 : skip chain if length is zero, read two more bytes of the length if length still zero, finish the decompression leave (length) bytes of the output unchanged from the last frame To leave length bytes of output unchanged i just have to *not* write anything to those bytes, right? Or do I have write code to remember the previous frame and all? ----------------- Sisir Koppaka
3 : fill chain if length is zero, read two more bytes of the length color = next two bytes of the input fill (length) words of the output with (color) What does color mean here? We already have a palette and all....and why is color two bytes long? ----------------- Sisir Koppaka
On Sun, Mar 30, 2008 at 06:49:46PM +0530, Sisir Koppaka wrote:
3 : fill chain if length is zero, read two more bytes of the length color = next two bytes of the input fill (length) words of the output with (color)
What does color mean here? We already have a palette and all....and why is color two bytes long?
It's just a convenient variable name for a pair of pixels. writing a = get_byte(); b = get_byte(); for(i = 0; i < length; i++){ output_pixel(a); output_pixel(b); } may be clearer for coder but not for the documentation.
Thanks! ----------------- Sisir Koppaka
On Sun, Mar 30, 2008 at 06:38:34PM +0530, Sisir Koppaka wrote:
From the BFI video decompression algo:
2 : skip chain if length is zero, read two more bytes of the length if length still zero, finish the decompression leave (length) bytes of the output unchanged from the last frame
To leave length bytes of output unchanged i just have to *not* write anything to those bytes, right? Or do I have write code to remember the previous frame and all?
It depends on your decoder. If you reuse the same memory for next frame decoding, then do nothing. If your previous frame and next frame are in different buffers then you have to copy pixels from the same position from previous frame.
Hi Sisir Koppaka wrote:
From the BFI video decompression algo:
(...) If I understand the context, you finished your demuxer and are now working in the decoder. But it is a good idea to send the demuxer for review so you can get it reviewed at the same time you work in the decoder. Also, I think it is more pratical this way both for you and for the reviewers (less code to review at a time). But before you send it, follow this small checklist: 1- Did you made _all_ the changes suggested in the thread "GSoc: BFI Demuxer/Decoder" in the devel ML? 2- Are you following all the coding rules? See http://ffmpeg.mplayerhq.hu/general.html#SEC23 3- Did you follow the patch submission checklist? See http://ffmpeg.mplayerhq.hu/general.html#SEC26 4- Did you review your own patch? That means looking for code that could be simpler or faster or more correct or more readable. 5- Are you really sure your patch don't have trailing whitespaces or tabs? (Tip: grep ' $' bfi.patch) Good luck, -Vitor
If I understand the context, you finished your demuxer and are now
working in the decoder. But it is a good idea to send the demuxer for review so you can get it reviewed at the same time you work in the decoder. Also, I think it is more pratical this way both for you and for the reviewers (less code to review at a time).
But before you send it, follow this small checklist:
1- Did you made _all_ the changes suggested in the thread "GSoc: BFI Demuxer/Decoder" in the devel ML?
2- Are you following all the coding rules? See http://ffmpeg.mplayerhq.hu/general.html#SEC23
3- Did you follow the patch submission checklist? See http://ffmpeg.mplayerhq.hu/general.html#SEC26
4- Did you review your own patch? That means looking for code that could be simpler or faster or more correct or more readable.
5- Are you really sure your patch don't have trailing whitespaces or tabs? (Tip: grep ' $' bfi.patch)
Thanks, Vitor! I'll check up on the items in that list before sending a patch. ----------------- Sisir Koppaka
3) Do I have to set the palette in the decoder for every frame? Or will doing it the first time suffice?
If you set FF_BUFFER_HINTS_PRESERVE | FF_BUFFER_HINTS_REUSABLE and always use the same AVFrame: no. But you should only do this if there is a reason for it besides the palette, e.g. because previous frames are reused or whatever.
Video has started playing :) though I can't make out anything and there are lots of black, empty lines - I think it's not remembering the previous frame(The decompressing algo's 'Skip Chain' situation requires us to leave 'length' bytes unchanged from previous frame.) I've set the two FF_BUFFER_HINTS mentioned above, but how do we use the same AVFrame? Currently I'm using an AVFrame declared within BFIContext, my context structure. ----------------- Sisir Koppaka
On Mon, Mar 31, 2008 at 01:32:52PM +0530, Sisir Koppaka wrote:
I've set the two FF_BUFFER_HINTS mentioned above, but how do we use the same AVFrame? Currently I'm using an AVFrame declared within BFIContext, my context structure.
Do whatever the nuv.c decoder does, I think that is the easiest example.
Thanks! ----------------- Sisir Koppaka
On Mon, Mar 31, 2008 at 2:40 PM, Reimar Döffinger < Reimar.Doeffinger@stud.uni-karlsruhe.de> wrote:
On Mon, Mar 31, 2008 at 01:32:52PM +0530, Sisir Koppaka wrote:
I've set the two FF_BUFFER_HINTS mentioned above, but how do we use the same AVFrame? Currently I'm using an AVFrame declared within BFIContext, my context structure.
Do whatever the nuv.c decoder does, I think that is the easiest example.
I'm trying to fix this. Meanwhile with the addition of video demuxing, the audio has stopped for some reason. It's sending the packets all right to the audio decoder, looking from the debug av_logs - any suggestions about where one might go wrong handling multiple streams in a demuxer? Another question: Is it necessary to set pkt->pts in timebase units for both audio and video or like when & how should we set pkt->pts? ----------------- Sisir Koppaka
On Mon, Mar 31, 2008 at 04:11:31PM +0530, Sisir Koppaka wrote: [...]
Another question: Is it necessary to set pkt->pts in timebase units for both audio and video or like when & how should we set pkt->pts?
Pts is in timebase units. You should set it for all packets for which you know or can calculate it easily. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf
I wanted to confirm some things about the decoder: 1. When sending the decoded data to the output buffer, should we just send the indices or should we locate the RGB triplets corresponding to a index and then send them to the output buffer? (Does ffmpeg have any functions to automatically do this/ is the output we send into the output buffer the final one that goes to the display hardware?) 2. From the av_logs, I see that the decode_init is being called right before any of the chunks are actually identified...but the decode_close function doesn't seem to be called anywhere(it's av_log is not being displayed) and I am having to do a manual pkill everytime I play a BFI file. Is there special return value that decode_frame should return to indicate that decode_close should be called? Or any thing else that is necessary for the decode_close function to be called? ----------------- Sisir Koppaka
On Fri, Apr 11, 2008 at 09:03:47PM +0530, Sisir Koppaka wrote:
I wanted to confirm some things about the decoder: 1. When sending the decoded data to the output buffer, should we just send the indices or should we locate the RGB triplets corresponding to a index
just the indices
and then send them to the output buffer? (Does ffmpeg have any functions to automatically do this/ is the output we send into the output buffer the final one that goes to the display hardware?) 2. From the av_logs, I see that the decode_init is being called right before any of the chunks are actually identified...but the decode_close function doesn't seem to be called anywhere(it's av_log is not being displayed) and I am having to do a manual pkill everytime I play a BFI file.
Is there special return value that decode_frame should return to indicate that decode_close should be called?
no
Or any thing else that is necessary for the decode_close function to be called?
It should be called automatically. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
Thanks! ----------------- Sisir Koppaka
Hi, When we put the palette into data[1], should we put them as four byte aligned or just memcpy the 256*3 bytes as-is from extradata? ----------------- Sisir Koppaka
On Wed, Apr 16, 2008 at 11:18:36AM +0530, Sisir Koppaka wrote:
Hi, When we put the palette into data[1], should we put them as four byte aligned or just memcpy the 256*3 bytes as-is from extradata?
Its described in avutil.h : * When the pixel format is palettized RGB (PIX_FMT_PAL8), the palettized * image data is stored in AVFrame.data[0]. The palette is transported in * AVFrame.data[1] and, is 1024 bytes long (256 4-byte entries) and is * formatted the same as in PIX_FMT_RGB32 described above (i.e., it is * also endian-specific). Note also that the individual RGB palette * components stored in AVFrame.data[1] should be in the range 0..255. * This is important as many custom PAL8 video codecs that were designed * to run on the IBM VGA graphics adapter use 6-bit palette components. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
Thank you... ----------------- Sisir Koppaka
On Tue, Mar 25, 2008 at 11:00:43PM +0530, Sisir Koppaka wrote:
Does calling av_new_packet or av_get_packet automatically send over the packet to the decoder?
Those functions are only one way to initialize an AVPacket. If your demuxers read function returns 0, the packet to which your got the pointer as argument to the read function will be queued (and somewhen passed on to the decoder). Greetings, Reimar Döffinger
Thanks. ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Is it safe for me to assume that the BFI format's bytes in the palette are big endian? I've been using little endian for all the other bytes.
You will note a little variation in the way different files deal with the palette. I'll be honest-- I lost the thread on FFmpeg's internal palette handling some time ago. That's an area that sorely needs to be revisited. There are demuxer/decoder systems that do things in a preferred (though still sub-optimal manner) and others that have yet to be revised. I am trying to steer you to some good examples, and I think smacker.c probably has a model you should follow. -- -Mike Melanson
Checking up....Thanks.
I have a question regarding the PCM frequency. The PCM wiki page says : frequency = 1000000 / (256 - frequency_divisor) A common divisor is 211 which yields an integer frequency of 22222 Hz, a common rate in the days of the Sound Blaster. Note that while very low frequencies (all the way down to 3921 Hz) were supported, frequencies above 45454 Hz were not.Does this mean Does this mean that I have to hardcode the frequency_divisor as 211? Right now, I'm doing this: sample_rate = 1000000/(256 - get_byte(pb)) where the get_byte() fetches the first byte of the PCM bytestream in the file. I saw that this was done in one of the codecs, so I took it to mean that the first byte contained the frequency_divisor. Maybe that inference is wrong? --------------------- Sisir Koppaka
The dev package did the trick. I got some sound out and then it stopped. Modem-sort of sound. More debugging to do. ----------------- Sisir Koppaka
Sisir Koppaka wrote:
I have a question regarding the PCM frequency. The PCM wiki page says :
frequency = 1000000 / (256 - frequency_divisor)
A common divisor is 211 which yields an integer frequency of 22222 Hz, a common rate in the days of the Sound Blaster. Note that while very low frequencies (all the way down to 3921 Hz) were supported, frequencies above 45454 Hz were not.Does this mean
Does this mean that I have to hardcode the frequency_divisor as 211? Right now, I'm doing this: sample_rate = 1000000/(256 - get_byte(pb))
where the get_byte() fetches the first byte of the PCM bytestream in the file. I saw that this was done in one of the codecs, so I took it to mean that the first byte contained the frequency_divisor. Maybe that inference is wrong?
Oh wow, this is wrong in, like, 9 different ways. :) The colloquial phrase here is, "too smart by half". Maybe I gave you too much information to work with. The PCM page mentions that weird formula, yes. But it only applies to specs that store Sound Blaster frequency divisors (see VOC and C93 as examples). The BFI spec does not say that it stores a Sound Blaster frequency divisor. Here's what the BFI spec says: bytes 828-831 (+33C) audio sample rate Open 2287.bfi in a hex editor. Travel to offset 0x33C. What 4 bytes live there? -- -Mike Melanson
Oh wow, this is wrong in, like, 9 different ways. :) The colloquial phrase here is, "too smart by half". Maybe I gave you too much information to work with.
The PCM page mentions that weird formula, yes. But it only applies to specs that store Sound Blaster frequency divisors (see VOC and C93 as examples). The BFI spec does not say that it stores a Sound Blaster frequency divisor. Here's what the BFI spec says:
bytes 828-831 (+33C) audio sample rate
Open 2287.bfi in a hex editor. Travel to offset 0x33C. What 4 bytes live there?
The four bytes I see in order are : 11 2b 00 00 So accounting for the little endianness, the sample rate appears to be 2b11 = 11025 hz. So, I guess the formula and the freq. divisor stuff was unnecessary :) I got misled by referring some other demuxer's code which must have needed the freq_div. Now, I get it! We have a perfectly sane frequency :) The modemish sound persists though, and it's showing the following(This must be archived for posterity :) ) : Duration: 00:00:00.0, start: 0.090000, bitrate: -2147483 kb/s Stream #0.0: Video: bfi, pal8, 320x140, 100.00 tb(r) Stream #0.1: Audio: pcm_u8, 1396790857 Hz, mono, -1710575 kb/s Guess it's reading the wrong byte....looking into that... -- ----------------- Sisir Koppaka
Have commented out most of the video part and focussing on getting the audio working perfectly. But I ran into this weird error while compiling : : make -C libpostproc all : make -C libswscale all : make -C libavfilter all cp -p ffplay_g ffplay cp: cannot create regular file `ffplay': Text file busy make: *** [ffplay] Error 1 ffplay or any related file are not open in vim right now...what does it mean? ----------------- Sisir Koppaka
On Sun, Mar 23, 2008 at 1:07 AM, Sisir Koppaka <sisir.koppaka@gmail.com> wrote:
Have commented out most of the video part and focussing on getting the audio working perfectly. But I ran into this weird error while compiling : : make -C libpostproc all : make -C libswscale all : make -C libavfilter all cp -p ffplay_g ffplay cp: cannot create regular file `ffplay': Text file busy make: *** [ffplay] Error 1
ffplay or any related file are not open in vim right now...what does it mean?
Looks like several ffplay processes are running in the background. Kill, kill, kill... -- ----------------- Sisir Koppaka
Wow...discovered a command typo in the man pages...ubuntu doesn't seem to have bug reporting for man pages in launchpad....where do we submit bugs for man pages? kill -L should be kill -l in the man page of kill ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Wow...discovered a command typo in the man pages...ubuntu doesn't seem to have bug reporting for man pages in launchpad....where do we submit bugs for man pages?
kill -L should be kill -l in the man page of kill
All I can say is, "wrong list". -- -Mike Melanson
Sorry about that. ----------------- Sisir Koppaka
I have an exam on Monday, so I will have to take some time off to prepare for that..I'll try to get the audio working before that and figure out the pseudocode of the video decoder. Will update this thread with my progress. ----------------- Sisir Koppaka
Sisir Koppaka wrote:
What does the get_buffer(x,y,code) do and what is it's return value? (x and y are pointers)
According to my reading of the code, get_buffer() only has 2 parameters. What version of code are you working from? -- -Mike Melanson
On Sat, Mar 22, 2008 at 1:59 AM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
What does the get_buffer(x,y,code) do and what is it's return value? (x and y are pointers)
According to my reading of the code, get_buffer() only has 2 parameters. What version of code are you working from?
http://svn.mplayerhq.hu/ffmpeg/trunk/libavformat/bethsoftvid.c?annotate=1107... line 123. ----------------- Sisir Koppaka
Sisir Koppaka wrote:
On Sat, Mar 22, 2008 at 1:59 AM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
What does the get_buffer(x,y,code) do and what is it's return value? (x and y are pointers) According to my reading of the code, get_buffer() only has 2 parameters. What version of code are you working from?
http://svn.mplayerhq.hu/ffmpeg/trunk/libavformat/bethsoftvid.c?annotate=1107...
line 123.
Oh, that's the libavformat one. Declaration is in libavformat/avio.h: int get_buffer(ByteIOContext *s, unsigned char *buf, int size); It could probably use a doc not or 2. Given a bytestream (ByteIOContext), fetch size bytes into buf (better make sure buf is at least size bytes long) and returns the number of bytes actually consumed from the bytestream. -- -Mike Melanson
Thanks! ----------------- Sisir Koppaka
On Fri, Mar 21, 2008 at 12:16:07PM +0530, Sisir Koppaka wrote:
From avio.h:
offset_t *url_fseek*(ByteIOContext *s, offset_t offset, int whence);
What does the url_fseek() function do exactly? And whence has SEEK_XYZ values - what do they mean? Any pointers on where this info is located in the code?
see fseek() [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
participants (7)
-
Diego Biurrun -
Kostya -
Michael Niedermayer -
Mike Melanson -
Reimar Döffinger -
Sisir Koppaka -
Vitor Sessak