Hi, I have downloaded the sample files from http://samples.mplayerhq.hu/game-formats/yop. The base reference file CIMOVI01.avi which I need to compare my decoded output of CIMOVI01.YOP is not playing with ffplay. It showing a blank screen. Any suggestions will be greatly appreciated. With regards to this YOP project, any pointers/guidelines will be very helpful. Thanks, Indrani --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Indrani Kundu Saha wrote:
Hi,
I have downloaded the sample files from http://samples.mplayerhq.hu/game-formats/yop.
The base reference file CIMOVI01.avi which I need to compare my decoded output of CIMOVI01.YOP is not playing with ffplay. It showing a blank screen.
Hmm, same here. How about that. Well, proceed with the task anyway. :) You often will only have the specs and no raw reference when writing a new decoder.
With regards to this YOP project, any pointers/guidelines will be very helpful.
1) Get FFmpeg source code from SVN and download available YOP samples. 2) Write demuxer for YOP format. Verify with './ffmpeg -i <file.yop>'. This should tell you that the file was recognized as YOP. 3) Adapt FFmpeg's existing IMA ADPCM decoder to be able to handle the audio data inside YOP. After this is done, you should be able to hear coherent audio when you play a YOP file. 4) Finally, implement the video decoding algorithm. That's the coarse overview of the task. If you need finer detail on those steps, let us know. -- -Mike Melanson
On Tue, Mar 18, 2008 at 04:12:51PM -0700, Indrani Kundu Saha wrote:
Hi,
I have downloaded the sample files from http://samples.mplayerhq.hu/game-formats/yop.
The base reference file CIMOVI01.avi which I need to compare my decoded output of CIMOVI01.YOP is not playing with ffplay. It showing a blank screen.
Any suggestions will be greatly appreciated.
svn up the problem is fixed [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
Hi, This particular version of the BFI demuxer has only the bfi_probe function. When I compile it and run ffmpeg -i <path/to/bfi/file.bfi> I get the following output - FFmpeg version SVN-r1, 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 20 2008 12:46:04, gcc: 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Input #0, bfi, from './bfi/2287.bfi': Duration: N/A, bitrate: N/A Must supply at least one output file There's no other function and hence I suppose no other info is displayed except for 'Input #0, bfi'. Can I take this as a confirmation that the bfi_probe was called and it confirmed the type of the file or does 'Input #0, bfi' come from some other part of ffmpeg? ----------------- Sisir Koppaka
Hi Sisir Koppaka wrote:
Hi, This particular version of the BFI demuxer has only the bfi_probe function. When I compile it and run ffmpeg -i <path/to/bfi/file.bfi> I get the following output - FFmpeg version SVN-r1, 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 20 2008 12:46:04, gcc: 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Input #0, bfi, from './bfi/2287.bfi': Duration: N/A, bitrate: N/A Must supply at least one output file
There's no other function and hence I suppose no other info is displayed except for 'Input #0, bfi'. Can I take this as a confirmation that the bfi_probe was called and it confirmed the type of the file or does 'Input #0, bfi' come from some other part of ffmpeg?
You surely got the demuxer properly registered. But if you specified a file extension in the demuxer, ffmpeg can fall back to it to detect the file type. A simple test would be to rename it to something different and giving the same command. -Vitor PS: For those quick question, you'll have faster answers if you ask in #FFmpeg-devel IRC channel at freenode.org
Sisir Koppaka wrote:
Hi, This particular version of the BFI demuxer has only the bfi_probe function. When I compile it and run ffmpeg -i <path/to/bfi/file.bfi> I get the following output - FFmpeg version SVN-r1, 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 20 2008 12:46:04, gcc: 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) Input #0, bfi, from './bfi/2287.bfi': Duration: N/A, bitrate: N/A Must supply at least one output file
There's no other function and hence I suppose no other info is displayed except for 'Input #0, bfi'. Can I take this as a confirmation that the bfi_probe was called and it confirmed the type of the file or does 'Input #0, bfi' come from some other part of ffmpeg?
A few things: * You are replying to an email thread on the topic of YOP, yet you are talking about BFI. It would be more appropriate to start a new thread. Note that this does not mean replying to a message and changing the subject line. Create a new message with a new subject and send it to the list. It's less confusing. * There is no demuxer in FFmpeg to handle BFI files. The first part of your qualification task is to write a BFI demuxer. There is no bfi_probe() function in the code. That's your job. Run 'ffmpeg -i' on a supported file (like mpg, avi, mov) and you will see what kind of data FFmpeg will output. -- -Mike Melanson
Hi, Running ffmpeg -i <filename.notbfi> gives : Input #0, bfi, from '2287.mov': Duration: N/A, bitrate: N/A so, I guess the probe function is working and it's not using the extension to detect it. I'm in so desperate need of IRC but my institute won't allow it - we have only partial HTTP access to the internet and we don't even have FTP :(, leaving aside all other protocols. Tunnelling is only a paid option and hence not viable at this point in time. I've tried to use IRC in other ways but couldn't do so - I'd be glad if someone could suggest a http-based IRC alternative for guys like us behind ruthless proxies. @Mike: Sorry about replying in this thread, I'm learning these etiquettes and hopefully will not do such things in the future. I read your instructions at the top of this thread and replied in haste(I guess! :( ) Sisir Koppaka
Sisir Koppaka wrote:
Hi, Running ffmpeg -i <filename.notbfi> gives : Input #0, bfi, from '2287.mov': Duration: N/A, bitrate: N/A
so, I guess the probe function is working and it's not using the extension to detect it.
This strikes me as strange. What does your probe function look like? When I run './ffmpeg -i' on a supported file it looks something like: $ ./ffmpeg -i /mnt/fate-suite/8bps/full9iron-partial.mov FFmpeg version SVN-r12406, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --cc=ccache /usr/local/gcc-4.3.0/bin/gcc libavutil version: 49.6.0 libavcodec version: 51.51.0 libavformat version: 52.9.0 libavdevice version: 52.0.0 built on Mar 12 2008 18:57:07, gcc: 4.3.0 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/mnt/fate-suite/8bps/full9iron-partial.mov': Duration: 00:00:13.5, start: 0.000000, bitrate: 620 kb/s Stream #0.0(eng): Video: 8bps, pal8, 360x240, 12.50 tb(r) Stream #0.1(eng): Audio: pcm_u8, 22050 Hz, mono, 176 kb/s Must supply at least one output file Notice how the duration, bitrate, and streams are all specified and valid. About communication: work with what you have. We're here on these lists all day. -- -Mike Melanson
On Fri, Mar 21, 2008 at 1:17 AM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
Hi, Running ffmpeg -i <filename.notbfi> gives : Input #0, bfi, from '2287.mov': Duration: N/A, bitrate: N/A
so, I guess the probe function is working and it's not using the extension to detect it.
This strikes me as strange. What does your probe function look like? When I run './ffmpeg -i' on a supported file it looks something like:
I renamed the 2287.bfi file to 2287.mov just to check that my skeleton demuxer was able to recognize it as BFI by examining it's header irrespective of the extension(As Vitor suggested to check). The probe function just checks for the characters BF&I in the header of the file.
$ ./ffmpeg -i /mnt/fate-suite/8bps/full9iron-partial.mov FFmpeg version SVN-r12406, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --cc=ccache /usr/local/gcc-4.3.0/bin/gcc libavutil version: 49.6.0 libavcodec version: 51.51.0 libavformat version: 52.9.0 libavdevice version: 52.0.0 built on Mar 12 2008 18:57:07, gcc: 4.3.0 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/mnt/fate-suite/8bps/full9iron-partial.mov': Duration: 00:00:13.5, start: 0.000000, bitrate: 620 kb/s Stream #0.0(eng): Video: 8bps, pal8, 360x240, 12.50 tb(r) Stream #0.1(eng): Audio: pcm_u8, 22050 Hz, mono, 176 kb/s Must supply at least one output file
Notice how the duration, bitrate, and streams are all specified and valid.
About communication: work with what you have. We're here on these lists all day.
-- -Mike Melanson _______________________________________________ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
-- ----------------- Sisir Koppaka
On Fri, Mar 21, 2008 at 01:24:33AM +0530, Sisir Koppaka wrote:
On Fri, Mar 21, 2008 at 1:17 AM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
Running ffmpeg -i <filename.notbfi> gives : Input #0, bfi, from '2287.mov': Duration: N/A, bitrate: N/A
so, I guess the probe function is working and it's not using the extension to detect it.
This strikes me as strange. What does your probe function look like? When I run './ffmpeg -i' on a supported file it looks something like:
I renamed the 2287.bfi file to 2287.mov just to check that my skeleton demuxer was able to recognize it as BFI by examining it's header irrespective of the extension(As Vitor suggested to check). The probe function just checks for the characters BF&I in the header of the file.
You're making progress with your quoting, good. Next step..
$ ./ffmpeg -i /mnt/fate-suite/8bps/full9iron-partial.mov FFmpeg version SVN-r12406, Copyright (c) 2000-2008 Fabrice Bellard, et al. configuration: --cc=ccache /usr/local/gcc-4.3.0/bin/gcc libavutil version: 49.6.0 libavcodec version: 51.51.0 libavformat version: 52.9.0 libavdevice version: 52.0.0 built on Mar 12 2008 18:57:07, gcc: 4.3.0 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/mnt/fate-suite/8bps/full9iron-partial.mov': Duration: 00:00:13.5, start: 0.000000, bitrate: 620 kb/s Stream #0.0(eng): Video: 8bps, pal8, 360x240, 12.50 tb(r) Stream #0.1(eng): Audio: pcm_u8, 22050 Hz, mono, 176 kb/s Must supply at least one output file
Notice how the duration, bitrate, and streams are all specified and valid.
About communication: work with what you have. We're here on these lists all day.
-- -Mike Melanson _______________________________________________ FFmpeg-soc mailing list FFmpeg-soc@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
.. delete the useless block of text you are not replying to. Diego
I have a theory that at midnight, the earth's magnetic field interferes with the neurons' functioning causing a tremendous lack of common sense. I apologise on behalf of the earth's magnetic field, the neurons, and myself. :) Now, I've to start working on the rest of the demuxer...be back in a few hours... ----------------- Sisir Koppaka
Hi Sisir Koppaka wrote:
I have a theory that at midnight, the earth's magnetic field interferes with the neurons' functioning causing a tremendous lack of common sense. I
Well, don't let it interfere in your netiquette/posting style ;-) . See http://article.gmane.org/gmane.comp.video.ffmpeg.soc/2105 to see how your posts looks like to everyone else (and compare with messages posted by other people). -Vitor
In libavformat/avformat.h I came across this: struct AVCodecTag; struct AVFormatContext; I'm interested in finding out more about AVFormatContext? Is it typedef'fed somewhere else? ----------------- Sisir Koppaka
OK, I've found it, please ignore above question. On Fri, Mar 21, 2008 at 2:40 AM, Sisir Koppaka <sisir.koppaka@gmail.com> wrote:
In libavformat/avformat.h I came across this: struct AVCodecTag; struct AVFormatContext;
I'm interested in finding out more about AVFormatContext? Is it typedef'fed somewhere else?
----------------- Sisir Koppaka
-- ----------------- Sisir Koppaka
Hi, What does the get_le16(ByteIOContext *xyz) function do? ----------------- Sisir Koppaka
Hi, On Donnerstag, 20. März 2008, Sisir Koppaka wrote:
Hi, What does the get_le16(ByteIOContext *xyz) function do?
It reads a 16 bit little endian value from the stream. Regards Sascha
Thanks! ----------------- Sisir Koppaka
Sisir Koppaka wrote:
Hi, What does the get_le16(ByteIOContext *xyz) function do?
It reads a little endian 16-bit number from a bytestream. -- -Mike Melanson
In av_new_stream(s, ID) can we give same id to both video and audio streams or should it be different? Do codecs with same ID play simultaneously ? ----------------- Sisir Koppaka
On Fri, Mar 21, 2008 at 12:02:08PM +0530, Sisir Koppaka wrote:
In av_new_stream(s, ID) can we give same id to both video and audio streams or should it be different?
Its suposed to be different but will work as well if equal i guess ...
Do codecs with same ID play simultaneously ?
What is played is the decission of the application. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
Thank you very very much. ------------ Sisir Koppaka
Sisir Koppaka wrote:
I renamed the 2287.bfi file to 2287.mov just to check that my skeleton demuxer was able to recognize it as BFI by examining it's header irrespective of the extension(As Vitor suggested to check). The probe function just checks for the characters BF&I in the header of the file.
Okay, that invalidates my earlier theory. I thought you were running FFmpeg against a valid .mov file and your BFI demuxer was claiming it. So, looking back over your original email, to answer your question (now that I understand it): yes, it looks like your bfi_probe() function is being called. A simpler way to verify where the code execution is going would be to print something. Be mindful that you have to use av_log() instead of printf() in FFmpeg. E.g.: av_log(NULL, AV_LOG_INFO, "Hey! This is the bfi_probe() function!\n"); -- -Mike Melanson
On Fri, Mar 21, 2008 at 1:33 AM, Mike Melanson <mike@multimedia.cx> wrote:
Sisir Koppaka wrote:
I renamed the 2287.bfi file to 2287.mov just to check that my skeleton demuxer was able to recognize it as BFI by examining it's header irrespective of the extension(As Vitor suggested to check). The probe function just checks for the characters BF&I in the header of the file.
Okay, that invalidates my earlier theory. I thought you were running FFmpeg against a valid .mov file and your BFI demuxer was claiming it.
So, looking back over your original email, to answer your question (now that I understand it): yes, it looks like your bfi_probe() function is being called.
A simpler way to verify where the code execution is going would be to print something. Be mindful that you have to use av_log() instead of printf() in FFmpeg. E.g.:
av_log(NULL, AV_LOG_INFO, "Hey! This is the bfi_probe() function!\n");
Will be very useful :) Can we use format specifiers in av_log (like in printf()) to print values of variables? -- ----------------- Sisir Koppaka
Sisir Koppaka wrote:
av_log(NULL, AV_LOG_INFO, "Hey! This is the bfi_probe() function!\n");
Will be very useful :) Can we use format specifiers in av_log (like in printf()) to print values of variables?
Absolutely. Treat it just like a printf() but with 2 extra parameters in front. -- -Mike Melanson
On Fri, Mar 21, 2008 at 01:08:46AM +0530, Sisir Koppaka wrote:
@Mike: Sorry about replying in this thread, I'm learning these etiquettes and hopefully will not do such things in the future. I read your instructions at the top of this thread and replied in haste(I guess! :( )
Note that you seem to have replaced your top-posting habits with no quoting at all. This is hardly better. When you write something like "@Mike:" in an email, you are doing something wrong. Diego
I'm sorry about that. I'm literally flushing with embarrassment here - I've been on a roll with my errors. Sorry! Really! ----------------- Sisir Koppaka
On Fri, Mar 21, 2008 at 01:22:14AM +0530, Sisir Koppaka wrote:
I'm sorry about that. I'm literally flushing with embarrassment here - I've been on a roll with my errors. Sorry! Really!
And now you're doing it again. What's the point of your apology then? Diego
Hi Mike Melanson wrote:
Sisir Koppaka wrote:
Hi, This particular version of the BFI demuxer has only the bfi_probe function. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* There is no demuxer in FFmpeg to handle BFI files. The first part of your qualification task is to write a BFI demuxer. There is no bfi_probe() function in the code. That's your job.
I think by "This particular version of the BFI demuxer" he means a skeleton demuxer he just finished writing. -Vitor
Vitor Sessak wrote: > Hi > > Mike Melanson wrote: >> Sisir Koppaka wrote: >>> Hi, >>> This particular version of the BFI demuxer has only the bfi_probe function. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> * There is no demuxer in FFmpeg to handle BFI files. The first part of >> your qualification task is to write a BFI demuxer. There is no >> bfi_probe() function in the code. That's your job. > > I think by "This particular version of the BFI demuxer" he means a > skeleton demuxer he just finished writing. I'm starting to think so too. And my working theory regarding his problem is that he wrote a bfi_probe() function that is being called early and is, for whatever reason, returning AV_PROBE_MAX unconditionally, thus claiming any file. Learning curve. -- -Mike Melanson
On Fri, Mar 21, 2008 at 1:28 AM, Mike Melanson <mike@multimedia.cx> wrote:
> Vitor Sessak wrote:
> > Hi
> >
> > Mike Melanson wrote:
> >> Sisir Koppaka wrote:
> >>> Hi,
> >>> This particular version of the BFI demuxer has only the bfi_probe
> function.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> * There is no demuxer in FFmpeg to handle BFI files. The first part of
> >> your qualification task is to write a BFI demuxer. There is no
> >> bfi_probe() function in the code. That's your job.
> >
> > I think by "This particular version of the BFI demuxer" he means a
> > skeleton demuxer he just finished writing.
>
> I'm starting to think so too. And my working theory regarding his
> problem is that he wrote a bfi_probe() function that is being called
> early and is, for whatever reason, returning AV_PROBE_MAX
> unconditionally, thus claiming any file.
>
> Learning curve.
No, there is an if and there is an else { return 0; }.
--
-----------------
Sisir Koppaka
participants (7)
-
Diego Biurrun -
Indrani Kundu Saha -
Michael Niedermayer -
Mike Melanson -
Sascha Sommer -
Sisir Koppaka -
Vitor Sessak