Hi, I've altered the code in line with your recommendations. However, I'm still not entirely clear about the following:
and if i understand the demuxing code in drc.c correctly, then it does only split the stream into packets, this should be done in a AVParser instead for raw "containers", and the remaining (de)muxing code might fit better in libavformat/raw.c instead of a separate file, but a separate file is fine too if preferred
So, if I understand this correctly, the parsing code in drc.c is shifted to parser.c (or a suitable place to use a Dirac parser). This then receives data from the 'raw' file read in raw.c. Is this correct? I thought av_read_frame() should read an entire frame of data, so I'm not clear how this is now possible. Are you saying that I should use the boolean in avcodec_decode_video() because the frame boundaries will now be split across packets? Please can you elaborate. Thanks in advance Andrew
Hi
On Thursday 07 July 2005 14:38, Anuradha Suraparaju wrote:
**Dirac patch for ffmpeg **Tested with ffmpeg cvs (as of July 7, 2007 10:00am) and FFMpeg-20050707 **Author(s): Andrew Kennedy (dirac_dev at users.sourceforge.net) (main) Anuradha Suraparaju (asuraparaju at users.sourceforge.net) (minor mods)
Dirac is an open-source video codec currently under development. Both the encoder and decoder have been integrated with ffmpeg. This patch is only a basic integration such that only the salient paremeters are currently passed from ffmpeg to Dirac. As Dirac develops, especially with the integration of a formalised bit-stream syntax, then more complex screnarios can be dealt with. Encoded Dirac files, with the right patch, can be played back using MPlayer. [...]
+dirac_encoder_presets_t GetDiracPreset(AVCodecContext *avccontext)
shouldnt that and a few other functions be static to avoid namespace pollution, or are they used outside dirac.c?
+ default: + av_log (avccontext, AV_LOG_ERROR, "this codec supports only YUV420P\n"); + return format420; + + } + + return format420;
the last return is unreachable, IMHO it should be removed
it seems GetFrameBufferSize() could be replaced by avpicture_get_size()
+static unsigned char* dirac_videobuffer = 0; +static int dirac_videobuf_len =0; +static unsigned char dirac_videobuf_code[5]; +static int dirac_videobuf_code_len = 0;
non constant static/globals arent acceptable, it should be possible to use several demuxers or decoders at once
+ } + + dirac_videobuffer[dirac_videobuf_len++] = byte;
i dont care what indention style is used as long as its not the randomized one
+ av_free(dirac_videobuffer); + dirac_videobuffer=0;
this could be replaced by av_freep()
and if i understand the demuxing code in drc.c correctly, then it does only split the stream into packets, this should be done in a AVParser instead for raw "containers", and the remaining (de)muxing code might fit better in libavformat/raw.c instead of a separate file, but a separate file is fine too if preferred
-- Michael
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Hi On Monday 25 July 2005 17:48, Andrew Kennedy wrote:
Hi,
I've altered the code in line with your recommendations. However, I'm still
not entirely clear about the following:
and if i understand the demuxing code in drc.c correctly, then it does only split the stream into packets, this should be done in a AVParser instead for raw "containers", and the remaining (de)muxing code might fit better in libavformat/raw.c instead of a separate file, but a separate file is fine too if preferred
So, if I understand this correctly, the parsing code in drc.c is shifted to parser.c (or a suitable place to use a Dirac parser). This then receives data from the 'raw' file read in raw.c. Is this correct?
yes, but let me explain why it should be done that way if there is just one container format and one codec then it doesnt matter much where the spliting into packets is done but if there are several container formats like lets say a raw "container" which just stores everything from the encoder without any headers, a container like mpeg-ps which has headers but no knowledge of the frame/packet boundaries either and a container like avi or quicktime which has knowledge of frame/packet boundaries now if you wish to copy the video stream without decoding&reencoding it from either the raw or mpeg-ps formats into mov/avi/... then you need to split it into 1-frame packets but if that code is not demuxer independent then it would need to be duplicated for every demuxer which doesnt know about frame boundaries (raw, mpeg-ps, mpeg-ts, ...)
I thought av_read_frame() should read an entire frame of data, so I'm not clear how this is now possible. Are you saying that I should use the boolean in avcodec_decode_video() because the frame boundaries will now be split across packets? Please can you elaborate.
av_read_frame() uses the AVParser if one is available to change the input stream of random chunks into 1-frame packets (see av_read_frame() in utils.c) [...] -- Michael
**Amended Dirac patch for ffmpeg **Tested with ffmpeg cvs (as of August 25, 2005 10:00am) **Author(s): Andrew Kennedy (dirac_dev at users.sourceforge.net) (main) Anuradha Suraparaju (asuraparaju at users.sourceforge.net) (minor mods) Dirac is an open-source video codec currently under development. Both the encoder and decoder have been integrated with ffmpeg. This patch is only a basic integration such that only the salient paremeters are currently passed from ffmpeg to Dirac. As Dirac develops, especially with the integration of a formalised bit-stream syntax, then more complex screnarios can be dealt with. Encoded Dirac files, with the right patch, can be played back using MPlayer. Please feel free to modify/add-to the code. These are the instructions for enabling Dirac support in ffmpeg source code. 1. Download Dirac from sourceforge and build and install Dirac cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/dirac login cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/dirac co -P compress cd compress ./bootstrap ./configure make make install The last step installs the Dirac share encoder and decoder libraries in /usr/local/lib (which is the default install point). 2. Download ffmpeg from cvs cvs -z9 -d:pserver:anonymous at mplayerhq.hu:/cvsroot/ffmpeg co ffmpeg 3. Apply the patch cd ffmpeg patch -p1 < ffmpeg-dirac-patch.txt 4. Build and Install ./configure --enable-dirac make make install The option '--enable-dirac' must be used during configuration in order to pick-up the Dirac code during building. Sample Usage: (encoding) ffmpeg -s 720x576 -i input_file.yuv -vcodec dirac -qscale 15 dirac_output.drc The output from the encoder is exactly as it is written to the .drc encoded file. Dirac bit-rate is controlled by a quality-factor (currently a basic intepretation from qscale. A qscale of 1 maps to dirac quality factor 10 and 30 maps to quality factor 1). Dirac bitstreams can be wrapped in avi by using the -f avi option. (decoding) ffmpeg -i input.drc output.yuv Regards Andrew At 21:28 25/07/2005, you wrote:
Hi
On Monday 25 July 2005 17:48, Andrew Kennedy wrote:
Hi,
I've altered the code in line with your recommendations. However, I'm still
not entirely clear about the following:
and if i understand the demuxing code in drc.c correctly, then it does only split the stream into packets, this should be done in a AVParser instead for raw "containers", and the remaining (de)muxing code might fit better in libavformat/raw.c instead of a separate file, but a separate file is fine too if preferred
So, if I understand this correctly, the parsing code in drc.c is shifted to parser.c (or a suitable place to use a Dirac parser). This then receives data from the 'raw' file read in raw.c. Is this correct?
yes, but let me explain why it should be done that way if there is just one container format and one codec then it doesnt matter much where the spliting into packets is done but if there are several container formats like lets say a raw "container" which just stores everything from the encoder without any headers, a container like mpeg-ps which has headers but no knowledge of the frame/packet boundaries either and a container like avi or quicktime which has knowledge of frame/packet boundaries now if you wish to copy the video stream without decoding&reencoding it from either the raw or mpeg-ps formats into mov/avi/... then you need to split it into 1-frame packets but if that code is not demuxer independent then it would need to be duplicated for every demuxer which doesnt know about frame boundaries (raw, mpeg-ps, mpeg-ts, ...)
I thought av_read_frame() should read an entire frame of data, so I'm not clear how this is now possible. Are you saying that I should use the boolean in avcodec_decode_video() because the frame boundaries will now be split across packets? Please can you elaborate.
av_read_frame() uses the AVParser if one is available to change the input stream of random chunks into 1-frame packets (see av_read_frame() in utils.c)
[...] -- Michael
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
On Thu, Aug 25, 2005 at 05:00:31PM +0100, Andrew Kennedy wrote:
**Amended Dirac patch for ffmpeg **Tested with ffmpeg cvs (as of August 25, 2005 10:00am) **Author(s): Andrew Kennedy (dirac_dev at users.sourceforge.net) (main) Anuradha Suraparaju (asuraparaju at users.sourceforge.net) (minor mods)
Dirac is an open-source video codec currently under development. Both the encoder and decoder have been integrated with ffmpeg. This patch is only a basic integration such that only the salient paremeters are currently passed from ffmpeg to Dirac. As Dirac develops, especially with the integration of a formalised bit-stream syntax, then more complex screnarios can be dealt with. Encoded Dirac files, with the right patch, can be played back using MPlayer.
If bitstream is not finalized and may change, strict=-2 should be required to encode.. Rich
Hi On Thu, Aug 25, 2005 at 05:25:41PM -0400, Rich Felker wrote:
On Thu, Aug 25, 2005 at 05:00:31PM +0100, Andrew Kennedy wrote:
**Amended Dirac patch for ffmpeg **Tested with ffmpeg cvs (as of August 25, 2005 10:00am) **Author(s): Andrew Kennedy (dirac_dev at users.sourceforge.net) (main) Anuradha Suraparaju (asuraparaju at users.sourceforge.net) (minor mods)
Dirac is an open-source video codec currently under development. Both the encoder and decoder have been integrated with ffmpeg. This patch is only a basic integration such that only the salient paremeters are currently passed from ffmpeg to Dirac. As Dirac develops, especially with the integration of a formalised bit-stream syntax, then more complex screnarios can be dealt with. Encoded Dirac files, with the right patch, can be played back using MPlayer.
If bitstream is not finalized and may change, strict=-2 should be required to encode..
yes, adding something like: (from snow.c) if(avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL){ av_log(avctx, AV_LOG_ERROR, "this codec is under development, files encoded with it may not be decodable with future versions!!!\n" "use vstrict=-2 / -strict -2 to use it anyway\n"); return -1; } should fix it [...] -- Michael
Hi, I've amended the patch in line with your recommendations. As part of the changes, encoding should now only work with the -2 strict option. Thanks Andrew At 23:15 25/08/2005, you wrote:
Hi
On Thu, Aug 25, 2005 at 05:25:41PM -0400, Rich Felker wrote:
On Thu, Aug 25, 2005 at 05:00:31PM +0100, Andrew Kennedy wrote:
**Amended Dirac patch for ffmpeg **Tested with ffmpeg cvs (as of August 25, 2005 10:00am) **Author(s): Andrew Kennedy (dirac_dev at users.sourceforge.net) (main) Anuradha Suraparaju (asuraparaju at users.sourceforge.net) (minor mods)
Dirac is an open-source video codec currently under development. Both the encoder and decoder have been integrated with ffmpeg. This patch is only a basic integration such that only the salient paremeters are currently passed from ffmpeg to Dirac. As Dirac develops, especially with the integration of a formalised bit-stream syntax, then more complex screnarios can be dealt with. Encoded Dirac files, with the right patch, can be played back using MPlayer.
If bitstream is not finalized and may change, strict=-2 should be required to encode..
yes, adding something like: (from snow.c) if(avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL){ av_log(avctx, AV_LOG_ERROR, "this codec is under development, files encoded with it may not be decodable with future versions!!!\n" "use vstrict=-2 / -strict -2 to use it anyway\n"); return -1; }
should fix it
[...] -- Michael
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Hi On Tue, Aug 30, 2005 at 04:25:54PM +0100, Andrew Kennedy wrote:
Hi,
I've amended the patch in line with your recommendations. As part of the changes, encoding should now only work with the -2 strict option.
thanks, but it seems i keep finding issues every time i want to apply it so i have to annoy you again with a list of recommandet changes [...]
+ if(avccontext->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL){ + av_log(avccontext, AV_LOG_ERROR, "this codec is under development, files encoded with it may not be decodable with future versions!!!\n" + "use vstrict=-2 / -strict -2 to use it anyway\n"); + return -1; + } + + /* get dirac preset*/ + dirac_encoder_presets_t preset = GetDiracPreset(avccontext);
mixing statements and declarations, breaks with gcc <=2.95 [...]
+ avccontext->frame_size = avpicture_get_size(avccontext->pix_fmt, avccontext->width, avccontext->height);
this is wrong, frame_size is only used for audio codecs, for video its not used, and if we ever decide to use it for video too it would be the number of temporal samples like it is in case of audio which for all current video codecs would be 1 [...]
+static int dirac_encode_frame(AVCodecContext *avccontext, + unsigned char *frame, + int buf_size, void *data) [...] + avccontext->coded_frame->pts= 0;
this obviously is wrong, 2 frames cant have the same pts, why do you set it at all? [...]
+static int dirac_parse_open(AVCodecParserContext *s) +{ + FfmpegDiracParseContext *pc = s->priv_data; + pc->p_dirac_videobuffer = (unsigned char *)av_malloc(0x100000);
is the code which writes into this ensuring that it doesnt write over the end? [...] -- Michael
Hi At 11:37 02/09/2005, you wrote:
Hi
On Tue, Aug 30, 2005 at 04:25:54PM +0100, Andrew Kennedy wrote:
Hi,
I've amended the patch in line with your recommendations. As part of the changes, encoding should now only work with the -2 strict option.
thanks, but it seems i keep finding issues every time i want to apply it so i have to annoy you again with a list of recommandet changes
[...]
+static int dirac_encode_frame(AVCodecContext *avccontext, + unsigned char *frame, + int buf_size, void *data) [...] + avccontext->coded_frame->pts= 0;
this obviously is wrong, 2 frames cant have the same pts, why do you set it at all?
This seems to have been set to avoid problems when encoding to container formats such as avi. When removed, non-monotone errors are thrown up before writing the frame. So this line of code is really more of a short-term fix. As to a cleaner implementation, I'm not sure which approach to take. Any suggestions? Thanks Andrew
Hi On Fri, Sep 16, 2005 at 04:50:12PM +0100, Andrew Kennedy wrote:
Hi
At 11:37 02/09/2005, you wrote:
Hi
On Tue, Aug 30, 2005 at 04:25:54PM +0100, Andrew Kennedy wrote:
Hi,
I've amended the patch in line with your recommendations. As part of the changes, encoding should now only work with the -2 strict option.
thanks, but it seems i keep finding issues every time i want to apply it so i have to annoy you again with a list of recommandet changes
[...]
+static int dirac_encode_frame(AVCodecContext *avccontext, + unsigned char *frame, + int buf_size, void *data) [...] + avccontext->coded_frame->pts= 0;
this obviously is wrong, 2 frames cant have the same pts, why do you set it at all?
This seems to have been set to avoid problems when encoding to container formats such as avi. When removed, non-monotone errors are thrown up before writing the frame. So this line of code is really more of a short-term fix. As to a cleaner implementation, I'm not sure which approach to take. Any suggestions?
please elaborate on what you did to get non-monotone errors? (with latest cvs of course) [...] -- Michael
Hi At 22:19 16/09/2005, you wrote:
Hi
On Fri, Sep 16, 2005 at 04:50:12PM +0100, Andrew Kennedy wrote:
Hi
At 11:37 02/09/2005, you wrote:
Hi
On Tue, Aug 30, 2005 at 04:25:54PM +0100, Andrew Kennedy wrote:
Hi,
I've amended the patch in line with your recommendations. As part of the changes, encoding should now only work with the -2 strict option.
thanks, but it seems i keep finding issues every time i want to apply it so i have to annoy you again with a list of recommandet changes
[...]
+static int dirac_encode_frame(AVCodecContext *avccontext, + unsigned char *frame, + int buf_size, void *data) [...] + avccontext->coded_frame->pts= 0;
this obviously is wrong, 2 frames cant have the same pts, why do you set it at all?
This seems to have been set to avoid problems when encoding to container formats such as avi. When removed, non-monotone errors are thrown up
before
writing the frame. So this line of code is really more of a short-term fix. As to a cleaner implementation, I'm not sure which approach to take. Any suggestions?
please elaborate on what you did to get non-monotone errors? (with latest cvs of course)
For example, removing: avccontext->coded_frame->pts= 0 ...and encoding using: ffmpeg_g -s 720x576 -i snowboard.yuv [14 frames] -vcodec dirac -f avi -r 25/1 -strict -2 output.avi ....produces (from utils.c) error, non monotone timestamps 12 >= 120.5 bitrate=2430.9kbits/s error, non monotone timestamps 12 >= 12 error, non monotone timestamps 12 >= 12 ..code snippet: if(st->cur_dts && st->cur_dts != AV_NOPTS_VALUE && st->cur_dts >= pkt->dts){ av_log(NULL, AV_LOG_ERROR, "error, non monotone timestamps %Ld >= %Ld\n", st->cur_dts, pkt->dts); return -1; However, adding in: avccontext->coded_frame->pts=AV_NOPTS_VALUE; ..to dirac_encode_frame() does not produce an error. Is this valid? Regards Andrew
Hi On Tue, Sep 20, 2005 at 04:55:24PM +0100, Andrew Kennedy wrote:
Hi
At 22:19 16/09/2005, you wrote:
Hi
On Fri, Sep 16, 2005 at 04:50:12PM +0100, Andrew Kennedy wrote:
Hi
At 11:37 02/09/2005, you wrote:
Hi
On Tue, Aug 30, 2005 at 04:25:54PM +0100, Andrew Kennedy wrote:
Hi,
I've amended the patch in line with your recommendations. As part of
the
changes, encoding should now only work with the -2 strict option.
thanks, but it seems i keep finding issues every time i want to apply it so i have to annoy you again with a list of recommandet changes
[...]
+static int dirac_encode_frame(AVCodecContext *avccontext, + unsigned char *frame, + int buf_size, void *data) [...] + avccontext->coded_frame->pts= 0;
this obviously is wrong, 2 frames cant have the same pts, why do you set it at all?
This seems to have been set to avoid problems when encoding to container formats such as avi. When removed, non-monotone errors are thrown up before writing the frame. So this line of code is really more of a short-term fix. As to a cleaner implementation, I'm not sure which approach to take. Any suggestions?
please elaborate on what you did to get non-monotone errors? (with latest cvs of course)
For example, removing: avccontext->coded_frame->pts= 0 ...and encoding using:
ffmpeg_g -s 720x576 -i snowboard.yuv [14 frames] -vcodec dirac -f avi -r 25/1 -strict -2 output.avi
....produces (from utils.c) error, non monotone timestamps 12 >= 120.5 bitrate=2430.9kbits/s error, non monotone timestamps 12 >= 12 error, non monotone timestamps 12 >= 12
are you using latest ffmpeg cvs?
..code snippet: if(st->cur_dts && st->cur_dts != AV_NOPTS_VALUE && st->cur_dts >= pkt->dts){ av_log(NULL, AV_LOG_ERROR, "error, non monotone timestamps %Ld >= %Ld\n", st->cur_dts, pkt->dts); return -1;
However, adding in: avccontext->coded_frame->pts=AV_NOPTS_VALUE; ..to dirac_encode_frame() does not produce an error. Is this valid?
no, but better then setting it to 0 btw, i would help debug this but trying to compile ffmpeg+dirac here leads to /home/michael/bin/colorgcc -O3 -g -Wall -Wno-switch -DHAVE_AV_CONFIG_H -I.. -I'/home/michael/ffmpeg-write2/ffmpeg'/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -I/usr/local/include/dirac -c -o dirac.o dirac.c In file included from dirac.c:31: /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:167: error: syntax error before 'bool' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:167: warning: no semicolon at end of struct or union /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:186: error: syntax error before '}' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:186: warning: type defaults to 'int' in declaration of 'dirac_encparams_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:186: warning: data definition has no type or storage class /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:194: error: syntax error before 'dirac_encparams_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:194: warning: no semicolon at end of struct or union /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:200: error: syntax error before '}' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:200: warning: type defaults to 'int' in declaration of 'dirac_encoder_context_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:200: warning: data definition has no type or storage class /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:288: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:413: error: syntax error before 'dirac_encoder_context_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:413: warning: no semicolon at end of struct or union /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:464: error: syntax error before '}' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:464: warning: type defaults to 'int' in declaration of 'dirac_encoder_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:464: warning: data definition has no type or storage class /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: warning: type defaults to 'int' in declaration of 'dirac_encoder_context_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: warning: type defaults to 'int' in declaration of 'dirac_encoder_init' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: warning: data definition has no type or storage class /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:483: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:494: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:503: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:509: error: syntax error before '*' token colorgcc --version gcc (GCC) 4.0.1 (Debian 4.0.1-1) [...] -- Michael
Hi At 21:00 20/09/2005, you wrote:
Hi
On Tue, Sep 20, 2005 at 04:55:24PM +0100, Andrew Kennedy wrote:
Hi
At 22:19 16/09/2005, you wrote:
Hi
On Fri, Sep 16, 2005 at 04:50:12PM +0100, Andrew Kennedy wrote:
Hi
At 11:37 02/09/2005, you wrote:
Hi
On Tue, Aug 30, 2005 at 04:25:54PM +0100, Andrew Kennedy wrote:
Hi,
I've amended the patch in line with your recommendations. As part of
the
changes, encoding should now only work with the -2 strict option.
thanks, but it seems i keep finding issues every time i want to apply it so i have to annoy you again with a list of recommandet changes
[...]
+static int dirac_encode_frame(AVCodecContext *avccontext, + unsigned char *frame, + int buf_size, void *data) [...] + avccontext->coded_frame->pts= 0;
this obviously is wrong, 2 frames cant have the same pts, why do you set it at all?
This seems to have been set to avoid problems when encoding to container formats such as avi. When removed, non-monotone errors are thrown up before writing the frame. So this line of code is really more of a short-term fix. As to a cleaner implementation, I'm not sure which approach to take. Any suggestions?
please elaborate on what you did to get non-monotone errors? (with latest cvs of course)
For example, removing: avccontext->coded_frame->pts= 0 ...and encoding using:
ffmpeg_g -s 720x576 -i snowboard.yuv [14 frames] -vcodec dirac -f avi -r 25/1 -strict -2 output.avi
....produces (from utils.c) error, non monotone timestamps 12 >= 120.5 bitrate=2430.9kbits/s error, non monotone timestamps 12 >= 12 error, non monotone timestamps 12 >= 12
are you using latest ffmpeg cvs?
Yes, this is the output from the latest CVS.
..code snippet: if(st->cur_dts && st->cur_dts != AV_NOPTS_VALUE && st->cur_dts >=
pkt->dts){
av_log(NULL, AV_LOG_ERROR, "error, non monotone timestamps %Ld >= %Ld\n", st->cur_dts, pkt->dts); return -1;
However, adding in: avccontext->coded_frame->pts=AV_NOPTS_VALUE; ..to dirac_encode_frame() does not produce an error. Is this valid?
no, but better then setting it to 0
btw, i would help debug this but trying to compile ffmpeg+dirac here leads to
Thanks. Some help on this issue would be appreciated.
/home/michael/bin/colorgcc -O3 -g -Wall -Wno-switch -DHAVE_AV_CONFIG_H -I.. -I'/home/michael/ffmpeg-write2/ffmpeg'/libavutil -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -I/usr/local/include/dirac -c -o dirac.o dirac.c In file included from dirac.c:31: /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:167: error: syntax error before 'bool' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:167: warning: no semicolon at end of struct or union /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:186: error: syntax error before '}' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:186: warning: type defaults to 'int' in declaration of 'dirac_encparams_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:186: warning: data definition has no type or storage class /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:194: error: syntax error before 'dirac_encparams_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:194: warning: no semicolon at end of struct or union /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:200: error: syntax error before '}' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:200: warning: type defaults to 'int' in declaration of 'dirac_encoder_context_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:200: warning: data definition has no type or storage class /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:288: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:413: error: syntax error before 'dirac_encoder_context_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:413: warning: no semicolon at end of struct or union /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:464: error: syntax error before '}' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:464: warning: type defaults to 'int' in declaration of 'dirac_encoder_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:464: warning: data definition has no type or storage class /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: warning: type defaults to 'int' in declaration of 'dirac_encoder_context_t' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: warning: type defaults to 'int' in declaration of 'dirac_encoder_init' /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:472: warning: data definition has no type or storage class /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:483: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:494: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:503: error: syntax error before '*' token /usr/local/include/dirac/libdirac_encoder/dirac_encoder.h:509: error: syntax error before '*' token
colorgcc --version gcc (GCC) 4.0.1 (Debian 4.0.1-1)
It appears that a boolean type had creeped into the lastest Dirac CVS by accident. Hence the reason that the ffmpeg compiler was complaining. This has now been corrected. A fresh check-out should fix the problem. Regards Andrew
Hi On Thu, Aug 25, 2005 at 05:00:31PM +0100, Andrew Kennedy wrote:
**Amended Dirac patch for ffmpeg **Tested with ffmpeg cvs (as of August 25, 2005 10:00am) **Author(s): Andrew Kennedy (dirac_dev at users.sourceforge.net) (main) Anuradha Suraparaju (asuraparaju at users.sourceforge.net) (minor mods)
[...]
+/* dirac codec */ +#ifdef CONFIG_DIRAC + register_avcodec(&dirac_decoder); +#ifdef CONFIG_ENCODERS + register_avcodec(&dirac_encoder); +#endif +#endif
register_avcodec(*_decoder); should be under CONFIG_*_DECODER and register_avcodec(*_encoder); should be under CONFIG_*_ENCODER if they are not under these then --enable/disable-codec will not work and ideally they should not be under any other #ifdef
+ /* input frame buffer */ + unsigned char *p_in_frame_buf; + + /** output frame buf */ + unsigned char* p_out_frame_buf;
mixing doxygen compatible comments with non doxy [...]
+ /** tell ffmpeg about sequence details*/ + avccontext->height=p_dirac_params->p_decoder->seq_params.height;
AFIAK doxygen comments are not supposed to be put in the middle of functions or does current doxygen do something with these?
+ dirac_buffer (p_dirac_params->p_decoder, buf, buf+buf_size); + while (1) + { + /** parse data and process result */ + DecoderState state = dirac_parse (p_dirac_params->p_decoder); + switch (state) + { + case STATE_BUFFER: + return buf_size; [...] + default: + break; + } + }
there is a lot of inconsistant indention in the files, often changing by +-1, but these arent a problem as i will run the file through indent before applying if you are too busy to fix them [...] -- Michael
participants (3)
-
andrew.kennedy＠rd.bbc.co.uk -
dalias＠aerifal.cx -
michaelni＠gmx.at