It is already known to some developers, but probably not to everybody that current CVS does not encode properly using mencoder/libavcodec and bframes. Here is how to check the bug. Make 100 jpeg frames to encode: # the following bash line will create 100 jpegs each one with the frame number # included in the image for ((a=1;a<101;a++)) ; do convert -size 100x75 xc:green -pointsize 24 -fill 'rgba(255,255,255,128)' -draw "gravity SouthEast text 12,42 '$a'" $(printf "%05d" $a).jpg ; done # the following command line will make a (dvd) mpeg that has all the frames # correctly encoded. mencoder -of mpeg -mpegopts vaspect=4/3:format=dvd -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:keyint=15:aspect=4/3:vrc_maxrate=7500:vbitrate=7500:vmax_b_frames=0 -o test.mpg mf://*.jpg -fps 25.000 -ofps 25 -vf scale=720:576,harddup -oac copy # the following command line will make a (dvd) mpeg where the frames 2 and 3 are # not encoded. mencoder -of mpeg -mpegopts vaspect=4/3:format=dvd -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:keyint=15:aspect=4/3:vrc_maxrate=7500:vbitrate=7500:vmax_b_frames=1 -o test.mpg mf://*.jpg -fps 25.000 -ofps 25 -vf scale=720:576,harddup -oac copy # Also adding the option -noskip to the last command line will make it to fail # to create the mpeg with many error messages: [mpeg2video @ 0x87c6e48]Error, Invalid timestamp=0, last=0:0.000 [0:0] # The problem exists also with avi. # next command makes an avi with all the frames: mencoder -ovc lavc -lavcopts vcodec=mpeg4 -o test.avi mf://*.jpg -vf scale=800:600 -fps 25.000 -ofps 25 -oac copy # next one has frames 2, 3 and 4 missing: mencoder -ovc lavc -lavcopts vcodec=mpeg4:vmax_b_frames=1 -o test.avi mf://*.jpg -vf scale=800:600 -fps 25.000 -ofps 25 -oac copy # also adding the option -noskip the previous command fails with errors: [mpeg4 @ 0x87c6e48]Error, Invalid timestamp=0, last=0 A-V:0.000 [0:0] And last: the avi created with current CVS with bframes cannot be played with mplayer 1.0pre7 (avi without bframes can be played). These problems have been recently introduced. I have tested CVS of 7th february and it doesn't shows the missing frames problem. Giacomo P.S. You can check the missing frames in two ways: start mplayer and pause it immediatly and then press the Step Forward key (.) or dump the frames with: mplayer -vo png test.avi
Sorry I should have posted to the users list. Giacomo On Wed, Apr 26, 2006 at 12:28:01PM -0400, Giacomo Comes wrote:
It is already known to some developers, but probably not to everybody that current CVS does not encode properly using mencoder/libavcodec and bframes.
Here is how to check the bug.
Make 100 jpeg frames to encode: # the following bash line will create 100 jpegs each one with the frame number # included in the image for ((a=1;a<101;a++)) ; do convert -size 100x75 xc:green -pointsize 24 -fill 'rgba(255,255,255,128)' -draw "gravity SouthEast text 12,42 '$a'" $(printf "%05d" $a).jpg ; done
# the following command line will make a (dvd) mpeg that has all the frames # correctly encoded. mencoder -of mpeg -mpegopts vaspect=4/3:format=dvd -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:keyint=15:aspect=4/3:vrc_maxrate=7500:vbitrate=7500:vmax_b_frames=0 -o test.mpg mf://*.jpg -fps 25.000 -ofps 25 -vf scale=720:576,harddup -oac copy
# the following command line will make a (dvd) mpeg where the frames 2 and 3 are # not encoded. mencoder -of mpeg -mpegopts vaspect=4/3:format=dvd -ovc lavc -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:keyint=15:aspect=4/3:vrc_maxrate=7500:vbitrate=7500:vmax_b_frames=1 -o test.mpg mf://*.jpg -fps 25.000 -ofps 25 -vf scale=720:576,harddup -oac copy
# Also adding the option -noskip to the last command line will make it to fail # to create the mpeg with many error messages: [mpeg2video @ 0x87c6e48]Error, Invalid timestamp=0, last=0:0.000 [0:0]
# The problem exists also with avi. # next command makes an avi with all the frames: mencoder -ovc lavc -lavcopts vcodec=mpeg4 -o test.avi mf://*.jpg -vf scale=800:600 -fps 25.000 -ofps 25 -oac copy
# next one has frames 2, 3 and 4 missing: mencoder -ovc lavc -lavcopts vcodec=mpeg4:vmax_b_frames=1 -o test.avi mf://*.jpg -vf scale=800:600 -fps 25.000 -ofps 25 -oac copy
# also adding the option -noskip the previous command fails with errors: [mpeg4 @ 0x87c6e48]Error, Invalid timestamp=0, last=0 A-V:0.000 [0:0]
And last: the avi created with current CVS with bframes cannot be played with mplayer 1.0pre7 (avi without bframes can be played).
These problems have been recently introduced. I have tested CVS of 7th february and it doesn't shows the missing frames problem.
Giacomo
P.S. You can check the missing frames in two ways: start mplayer and pause it immediatly and then press the Step Forward key (.) or dump the frames with: mplayer -vo png test.avi
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
--
On Wed, Apr 26, 2006 at 12:35:29PM -0400, Giacomo Comes wrote:
Sorry I should have posted to the users list.
I think this bug report is acceptable here because..
These problems have been recently introduced. I have tested CVS of 7th february and it doesn't shows the missing frames problem.
.. you have given a clear date when this regression was introduced. We're trying to get a release out the door and this is probably important enough to hold it up. Could you try to find the exact CVS date where it broke? Diego
Diego Biurrun wrote:
On Wed, Apr 26, 2006 at 12:35:29PM -0400, Giacomo Comes wrote:
Sorry I should have posted to the users list.
I think this bug report is acceptable here because..
These problems have been recently introduced. I have tested CVS of 7th february and it doesn't shows the missing frames problem.
.. you have given a clear date when this regression was introduced. We're trying to get a release out the door and this is probably important enough to hold it up.
Could you try to find the exact CVS date where it broke?
As a start, try right before 2006-03-21. That's when Michael made big PTS modifications. I'm not trying to point my finger at Michael, but he did write "lets see if pts or cola comes out at the end" in the log message. ;-) -Corey
On Wed, Apr 26, 2006 at 08:09:14PM +0200, Diego Biurrun wrote:
On Wed, Apr 26, 2006 at 12:35:29PM -0400, Giacomo Comes wrote:
Sorry I should have posted to the users list.
I think this bug report is acceptable here because..
These problems have been recently introduced. I have tested CVS of 7th february and it doesn't shows the missing frames problem.
.. you have given a clear date when this regression was introduced. We're trying to get a release out the door and this is probably important enough to hold it up.
Could you try to find the exact CVS date where it broke?
cvs -D 2006-03-22 is ok. cvs -D 2006-03-23 has the bug. Giacomo
On Wed, 26 Apr 2006 15:49:38 -0400 Giacomo Comes <comes@naic.edu> wrote:
On Wed, Apr 26, 2006 at 08:09:14PM +0200, Diego Biurrun wrote:
On Wed, Apr 26, 2006 at 12:35:29PM -0400, Giacomo Comes wrote:
Sorry I should have posted to the users list.
I think this bug report is acceptable here because..
These problems have been recently introduced. I have tested CVS of 7th february and it doesn't shows the missing frames problem.
.. you have given a clear date when this regression was introduced. We're trying to get a release out the door and this is probably important enough to hold it up.
Could you try to find the exact CVS date where it broke?
cvs -D 2006-03-22 is ok. cvs -D 2006-03-23 has the bug.
Please try the attached patch. However, I am not sure if it doesn't destroy all the expected functionality of the B-frame & PTS patches. Can somebody with a better insight have a look? Regards, -- Jindrich Makovicka
On Wed, 26 Apr 2006 15:49:38 -0400 Giacomo Comes <comes@naic.edu> wrote:
On Wed, Apr 26, 2006 at 08:09:14PM +0200, Diego Biurrun wrote:
On Wed, Apr 26, 2006 at 12:35:29PM -0400, Giacomo Comes wrote:
Sorry I should have posted to the users list.
I think this bug report is acceptable here because..
These problems have been recently introduced. I have tested CVS of 7th february and it doesn't shows the missing frames problem.
.. you have given a clear date when this regression was introduced. We're trying to get a release out the door and this is probably important enough to hold it up.
Could you try to find the exact CVS date where it broke?
cvs -D 2006-03-22 is ok. cvs -D 2006-03-23 has the bug.
Please try the attached patch. However, I am not sure if it doesn't destroy all the expected functionality of the B-frame & PTS patches. Can somebody with a better insight have a look? Regards, -- Jindrich Makovicka
On Mon, 2006-05-08 at 15:37 +0200, Jindrich Makovicka wrote:
Please try the attached patch. However, I am not sure if it doesn't destroy all the expected functionality of the B-frame & PTS patches. Can somebody with a better insight have a look?
AFAIK those timestamps are not used by anything now and it's better to just disable them by changing the last parameter to MP_NOPTS_VALUE until other code has been changed.
Hi On Mon, May 08, 2006 at 07:26:32PM +0300, Uoti Urpala wrote:
On Mon, 2006-05-08 at 15:37 +0200, Jindrich Makovicka wrote:
Please try the attached patch. However, I am not sure if it doesn't destroy all the expected functionality of the B-frame & PTS patches. Can somebody with a better insight have a look?
AFAIK those timestamps are not used by anything now and it's better to just disable them by changing the last parameter to MP_NOPTS_VALUE until other code has been changed.
for the release iam fine with MP_NOPTS_VALUE, for cvs after the release iam against it, when someone will need the timestamps in their encoder, filter or muxer they almost certainly wont dare or even know what to change and if they where entirely unused then changing the last argument to MP_NOPTS_VALUE couldnt affect this bug ... [...] -- Michael In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
On Mon, May 08, 2006 at 07:35:37PM +0200, Michael Niedermayer wrote:
Hi
On Mon, May 08, 2006 at 07:26:32PM +0300, Uoti Urpala wrote:
On Mon, 2006-05-08 at 15:37 +0200, Jindrich Makovicka wrote:
Please try the attached patch. However, I am not sure if it doesn't destroy all the expected functionality of the B-frame & PTS patches. Can somebody with a better insight have a look?
AFAIK those timestamps are not used by anything now and it's better to just disable them by changing the last parameter to MP_NOPTS_VALUE until other code has been changed.
for the release iam fine with MP_NOPTS_VALUE, for cvs after the release iam against it, when someone will need the timestamps in their encoder, filter or muxer they almost certainly wont dare or even know what to change
and if they where entirely unused then changing the last argument to MP_NOPTS_VALUE couldnt affect this bug ...
By the way, the patch seems to work. Giacomo
On Mon, 2006-05-08 at 19:35 +0200, Michael Niedermayer wrote:
for the release iam fine with MP_NOPTS_VALUE, for cvs after the release iam against it, when someone will need the timestamps in their encoder, filter or muxer they almost certainly wont dare or even know what to change
Yes it will need to be changed after the release; however I think the proper behaviour is to feed timestamps from the source (not muxer) to the front of the filter chain. Doing that will require changing the parameter later anyway.
and if they where entirely unused then changing the last argument to MP_NOPTS_VALUE couldnt affect this bug ...
Yes when encoding with libavcodec it at least checks the timestamp values and breaks, I'm not aware of any useful functionality though.
Hi On Mon, May 08, 2006 at 08:59:09PM +0300, Uoti Urpala wrote:
On Mon, 2006-05-08 at 19:35 +0200, Michael Niedermayer wrote:
for the release iam fine with MP_NOPTS_VALUE, for cvs after the release iam against it, when someone will need the timestamps in their encoder, filter or muxer they almost certainly wont dare or even know what to change
Yes it will need to be changed after the release; however I think the proper behaviour is to feed timestamps from the source (not muxer) to the front of the filter chain.
agree
Doing that will require changing the parameter later anyway.
yes
and if they where entirely unused then changing the last argument to MP_NOPTS_VALUE couldnt affect this bug ...
Yes when encoding with libavcodec it at least checks the timestamp values and breaks,
:)
I'm not aware of any useful functionality though.
for some codecs these get stored in the video stream and furthermore even used for direct mode motion vectors of b frames ... all that requires variable fps video to make a difference of coarse ... [...] -- Michael In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
On Mon, 2006-05-08 at 23:36 +0200, Michael Niedermayer wrote:
I'm not aware of any useful functionality though.
for some codecs these get stored in the video stream and furthermore even used for direct mode motion vectors of b frames ... all that requires variable fps video to make a difference of coarse ...
I think the timestamps fed into the filter chain currently (or with Jindrich's patch) aren't actually correct with B-frames and variables-fps video.
On Mon, 8 May 2006 19:35:37 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
Hi [...]
for the release iam fine with MP_NOPTS_VALUE, for cvs after the release iam against it, when someone will need the timestamps in their encoder, filter or muxer they almost certainly wont dare or even know what to change
[...] Can anybody submit (or commit) a patch for this nopts change? I have no clue about mencoder and this is one of the major things holding back the release. Else please tell me if i should to apply the patch from this thread or the one posted by Nico on Apr 23 ([MPlayer-dev-eng] [BUG] [PATCH] encoding with lavc and b-frames is partially broken). Ciao, Roberto
Hi On Tue, May 09, 2006 at 12:00:30AM +0200, Roberto Togni wrote:
On Mon, 8 May 2006 19:35:37 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
Hi [...]
for the release iam fine with MP_NOPTS_VALUE, for cvs after the release iam against it, when someone will need the timestamps in their encoder, filter or muxer they almost certainly wont dare or even know what to change
[...]
Can anybody submit (or commit) a patch for this nopts change? I have no clue about mencoder and this is one of the major things holding back the release.
Else please tell me if i should to apply the patch from this thread or the one posted by Nico on Apr 23 ([MPlayer-dev-eng] [BUG] [PATCH] encoding with lavc and b-frames is partially broken).
something like: @@ -1316,7 +1316,7 @@ default: // decode_video will callback down to ve_*.c encoders, through the video filters blit_frame=decode_video(sh_video,frame_data.start,frame_data.in_size, - skip_flag>0 && (!sh_video->vfilter || ((vf_instance_t *)sh_video->vfilter)->control(sh_video->vfilter, VFCTRL_SKIP_NEXT_FRAME, 0) != CONTROL_TRUE), mux_v->timer); + skip_flag>0 && (!sh_video->vfilter || ((vf_instance_t *)sh_video->vfilter)->control(sh_video->vfilter, VFCTRL_SKIP_NEXT_FRAME, 0) != CONTROL_TRUE), MP_NOPTS_VALUE); if (sh_video->vf_inited < 0) mencoder_exit(1, NULL); might work, warning this is not a real patch, just hand edited ... [...] -- Michael In the past you could go to a library and read, borrow or copy any book Today you'd get arrested for mere telling someone where the library is
On Tue, 9 May 2006 11:06:30 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
Hi
On Tue, May 09, 2006 at 12:00:30AM +0200, Roberto Togni wrote:
On Mon, 8 May 2006 19:35:37 +0200 Michael Niedermayer <michaelni@gmx.at> wrote:
Hi [...]
for the release iam fine with MP_NOPTS_VALUE, for cvs after the release iam against it, when someone will need the timestamps in their encoder, filter or muxer they almost certainly wont dare or even know what to change
[...]
Can anybody submit (or commit) a patch for this nopts change? I have no clue about mencoder and this is one of the major things holding back the release.
Else please tell me if i should to apply the patch from this thread or the one posted by Nico on Apr 23 ([MPlayer-dev-eng] [BUG] [PATCH] encoding with lavc and b-frames is partially broken).
something like: @@ -1316,7 +1316,7 @@ default: // decode_video will callback down to ve_*.c encoders, through the video filters blit_frame=decode_video(sh_video,frame_data.start,frame_data.in_size, - skip_flag>0 && (!sh_video->vfilter || ((vf_instance_t *)sh_video->vfilter)->control(sh_video->vfilter, VFCTRL_SKIP_NEXT_FRAME, 0) != CONTROL_TRUE), mux_v->timer); + skip_flag>0 && (!sh_video->vfilter || ((vf_instance_t *)sh_video->vfilter)->control(sh_video->vfilter, VFCTRL_SKIP_NEXT_FRAME, 0) != CONTROL_TRUE), MP_NOPTS_VALUE);
if (sh_video->vf_inited < 0) mencoder_exit(1, NULL);
might work, warning this is not a real patch, just hand edited ...
Thanks, applied. I'll revert it after pre8. Ciao, Roberto
participants (8)
-
Corey Hickey -
Diego Biurrun -
Giacomo Comes -
Jindrich Makovicka -
Jindrich Makovicka -
Michael Niedermayer -
Roberto Togni -
Uoti Urpala