I'm looking for a method to convert a JPEG image to an MPEG-2 I-frame that can be displayed through VDR's cDevice::StillPicture() function. The conversion should be done by a (sequence of) shell command(s).
Can anybody advise how this can be done?
Klaus
On 01 Nov 2007 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I'm looking for a method to convert a JPEG image to an MPEG-2 I-frame that can be displayed through VDR's cDevice::StillPicture() function. The conversion should be done by a (sequence of) shell command(s).
May be something like this:
#!/bin/bash # # requires: ...topnm, pnmscale, pnmcomp, ppmntsc, ppmtoy4m, mpeg2enc #
# video format. pal or ntsc FORMAT=pal
# target image width/height (taking into account visible screen area) if [ "$FORMAT" = "ntsc" ]; then TW=600 TH=420 else TW=632 TH=512 fi
TMP=/tmp/image_convert.$$.pnm IMG=$1 MPG=$2
DIR=`dirname "$MPG"` if [ ! -d "$DIR" ]; then mkdir -p "$DIR" fi # # get the file type and set the according converter to PNM # FILE_TYPE=`file -i -L -b "$IMG" 2>/dev/null | cut -f2 -d/` case "$FILE_TYPE" in jpg | jpeg) TO_PNM=jpegtopnm ;; tiff) TO_PNM=tifftopnm ;; bmp | x-bmp) TO_PNM=bmptoppm ;; png | x-png) TO_PNM=pngtopnm ;; Netpbm | pnm | x-portable-pixmap) TO_PNM=cat ;; gif) TO_PNM=giftopnm ;; *) echo "filetype '$FILE_TYPE' is not supported" exit 1 ;; esac # # 'chroma subsampling mode' mjpegtools >= 1.8.0 # SUBSAMPLINGMODE="" if ppmtoy4m -h | egrep -q "'420mpeg2'"; then SUBSAMPLINGMODE="-S 420mpeg2" fi # # extract the image size & compute scale value # LANG=C # get the decimal point right $TO_PNM "$IMG" >$TMP 2>/dev/null S=`pnmfile $TMP | awk '{ printf "%d %d ",$4,$6 }'` S=`echo $S $TW $TH | awk '{ sw=$3/$1; sh=$4/$2; s=(sw<sh)?sw:sh; printf "%.4f\n",(s>1)?1.0:s; }'` # # now run the conversion # if [ "$FORMAT" = "ntsc" ]; then pnmscale $S $TMP | \ pnmpad -black -width 704 -height 480 | \ ppmntsc | \ ppmtoy4m -v 0 -n 1 -r -F 30000:1001 $SUBSAMPLINGMODE | \ mpeg2enc -f 7 -T 90 -F 4 -nn -a 2 -v 0 -o "$MPG" else pnmscale $S $TMP | \ pnmpad -black -width 704 -height 576 | \ ppmntsc --pal | \ ppmtoy4m -v 0 -n 1 -r -F 25:1 $SUBSAMPLINGMODE | \ mpeg2enc -f 7 -T 90 -F 3 -np -a 2 -v 0 -o "$MPG" fi # # cleanup # rm $TMP
On 11/01/07 13:21, Stefan Huelswitt wrote:
On 01 Nov 2007 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I'm looking for a method to convert a JPEG image to an MPEG-2 I-frame that can be displayed through VDR's cDevice::StillPicture() function. The conversion should be done by a (sequence of) shell command(s).
May be something like this:
#!/bin/bash # # requires: ...topnm, pnmscale, pnmcomp, ppmntsc, ppmtoy4m, mpeg2enc #
# video format. pal or ntsc FORMAT=pal ...
Thanks, that's exactly what I was looking for.
Klaus
On 11/01/07 13:21, Stefan Huelswitt wrote:
On 01 Nov 2007 Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I'm looking for a method to convert a JPEG image to an MPEG-2 I-frame that can be displayed through VDR's cDevice::StillPicture() function. The conversion should be done by a (sequence of) shell command(s).
May be something like this:
#!/bin/bash # # requires: ...topnm, pnmscale, pnmcomp, ppmntsc, ppmtoy4m, mpeg2enc # ...
When I display a picture generated with this script through a call to DeviceStillPicture(), the display looks very nice for a short while, and after that slanted lines get jagged. It appears as if the two interlaced half-pictures are first sent in turn, and finally only one of them is displayed continuously.
Calling DeviceStillPicture() repeatedly in a loop results in the display jumping between "nice" and "jagged".
So I thought about sending the picture file to the device through cPlayer::PlayPes() in a continuous loop. For that purpose I have added a call to 'mplex' to the script, as can be seen in the attachment.
When I display such a still file on a FF DVB card by calling cPlayer::PlayPes() in a continuous loop, the image on the tv screen looks like it is displaying both interlaced half-pictures in turn, but it is "jumpy" (as if the time between displaying the two half pictures is too long).
Does anybody have an idea how this could be improved, so that I get a smooth display, with slanted lines not jagged (just as if a still picture was shown in a normal movie)?
Klaus
#!/bin/bash # # requires: ...topnm, pnmscale, pnmcomp, ppmntsc, ppmtoy4m, mpeg2enc #
# video format. pal or ntsc FORMAT=pal
# target image width/height (taking into account visible screen area) if [ "$FORMAT" = "ntsc" ]; then TW=600 TH=420 else TW=632 TH=512 fi
TMP1=/tmp/image_convert.$$.pnm TMP2=/tmp/image_convert.$$.m2v IMG=$1 MPG=$2
DIR=`dirname "$MPG"` if [ ! -d "$DIR" ]; then mkdir -p "$DIR" fi # # get the file type and set the according converter to PNM # FILE_TYPE=`file -i -L -b "$IMG" 2>/dev/null | cut -f2 -d/` case "$FILE_TYPE" in jpg | jpeg) TO_PNM=jpegtopnm ;; tiff) TO_PNM=tifftopnm ;; bmp | x-bmp) TO_PNM=bmptoppm ;; png | x-png) TO_PNM=pngtopnm ;; Netpbm | pnm | x-portable-pixmap) TO_PNM=cat ;; gif) TO_PNM=giftopnm ;; *) echo "filetype '$FILE_TYPE' is not supported" exit 1 ;; esac # # 'chroma subsampling mode' mjpegtools >= 1.8.0 # SUBSAMPLINGMODE="" if ppmtoy4m -h | egrep -q "'420mpeg2'"; then SUBSAMPLINGMODE="-S 420mpeg2" fi # # extract the image size & compute scale value # LANG=C # get the decimal point right $TO_PNM "$IMG" >$TMP1 2>/dev/null S=`pnmfile $TMP1 | awk '{ printf "%d %d ",$4,$6 }'` S=`echo $S $TW $TH | awk '{ sw=$3/$1; sh=$4/$2; s=(sw<sh)?sw:sh; printf "%.4f\n",(s>1)?1.0:s; }'` # # now run the conversion # if [ "$FORMAT" = "ntsc" ]; then pnmscale $S $TMP1 | \ pnmpad -black -width 704 -height 480 | \ ppmntsc | \ ppmtoy4m -v 0 -n 1 -r -F 30000:1001 $SUBSAMPLINGMODE | \ mpeg2enc -f 7 -T 90 -F 4 -nn -a 2 -v 0 -o "$TMP2" else pnmscale $S $TMP1 | \ pnmpad -black -width 704 -height 576 | \ ppmntsc --pal | \ ppmtoy4m -v 0 -n 1 -r -F 25:1 $SUBSAMPLINGMODE | \ mpeg2enc -f 7 -T 90 -F 3 -np -a 2 -v 0 -o "$TMP2" fi mplex -f 7 -o "$MPG" "$TMP2" # # cleanup # rm $TMP1 $TMP2
Hi,
Klaus Schmidinger schrieb:
When I display a picture generated with this script through a call to DeviceStillPicture(), the display looks very nice for a short while, and after that slanted lines get jagged. It appears as if the two interlaced half-pictures are first sent in turn, and finally only one of them is displayed continuously.
Calling DeviceStillPicture() repeatedly in a loop results in the display jumping between "nice" and "jagged".
So I thought about sending the picture file to the device through cPlayer::PlayPes() in a continuous loop. For that purpose I have added a call to 'mplex' to the script, as can be seen in the attachment.
When I display such a still file on a FF DVB card by calling cPlayer::PlayPes() in a continuous loop, the image on the tv screen looks like it is displaying both interlaced half-pictures in turn, but it is "jumpy" (as if the time between displaying the two half pictures is too long).
Does anybody have an idea how this could be improved, so that I get a smooth display, with slanted lines not jagged (just as if a still picture was shown in a normal movie)?
How does the attached PES file look like? In vdr-xine, I send it just once and it looks OK in xine.
When it looks ok, I'll have to search for the commands which created it ;-)
I think, I had specified an option to create progressive frames.
Bye.
On 11/11/07 15:20, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
When I display a picture generated with this script through a call to DeviceStillPicture(), the display looks very nice for a short while, and after that slanted lines get jagged. It appears as if the two interlaced half-pictures are first sent in turn, and finally only one of them is displayed continuously.
Calling DeviceStillPicture() repeatedly in a loop results in the display jumping between "nice" and "jagged".
So I thought about sending the picture file to the device through cPlayer::PlayPes() in a continuous loop. For that purpose I have added a call to 'mplex' to the script, as can be seen in the attachment.
When I display such a still file on a FF DVB card by calling cPlayer::PlayPes() in a continuous loop, the image on the tv screen looks like it is displaying both interlaced half-pictures in turn, but it is "jumpy" (as if the time between displaying the two half pictures is too long).
Does anybody have an idea how this could be improved, so that I get a smooth display, with slanted lines not jagged (just as if a still picture was shown in a normal movie)?
How does the attached PES file look like? In vdr-xine, I send it just once and it looks OK in xine.
When it looks ok, I'll have to search for the commands which created it ;-)
I think, I had specified an option to create progressive frames.
After running your file through
mplex -f 7 -o test.mpg noSignal.mpg
and displaying test.mpg trough cPlayer::PlayPes() I get a pefectly smooth display.
Would be great if you could find the commands that created this one.
Klaus
On 11/11/07 15:30, Klaus Schmidinger wrote:
On 11/11/07 15:20, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
When I display a picture generated with this script through a call to DeviceStillPicture(), the display looks very nice for a short while, and after that slanted lines get jagged. It appears as if the two interlaced half-pictures are first sent in turn, and finally only one of them is displayed continuously.
Calling DeviceStillPicture() repeatedly in a loop results in the display jumping between "nice" and "jagged".
So I thought about sending the picture file to the device through cPlayer::PlayPes() in a continuous loop. For that purpose I have added a call to 'mplex' to the script, as can be seen in the attachment.
When I display such a still file on a FF DVB card by calling cPlayer::PlayPes() in a continuous loop, the image on the tv screen looks like it is displaying both interlaced half-pictures in turn, but it is "jumpy" (as if the time between displaying the two half pictures is too long).
Does anybody have an idea how this could be improved, so that I get a smooth display, with slanted lines not jagged (just as if a still picture was shown in a normal movie)?
How does the attached PES file look like? In vdr-xine, I send it just once and it looks OK in xine.
When it looks ok, I'll have to search for the commands which created it ;-)
I think, I had specified an option to create progressive frames.
After running your file through
mplex -f 7 -o test.mpg noSignal.mpg
and displaying test.mpg trough cPlayer::PlayPes() I get a pefectly smooth display.
Would be great if you could find the commands that created this one.
One more thing: the 'file' command reports
MPEG sequence, v2, MP@ML interlaced Y'CbCr 4:2:0 video, 4CIF PAL, 4:3, 25 fps
on a file created with the posted script (before the mplex call), while for your noSignal.mpg it reports
MPEG sequence, v2, MP@ML interlaced Y'CbCr 4:2:0 video, CCIR/ITU PAL 625, 4:3, 25 fps
Maybe this indicates where the problem might be?
Klaus
Hi,
Klaus Schmidinger schrieb:
How does the attached PES file look like? In vdr-xine, I send it just once and it looks OK in xine.
When it looks ok, I'll have to search for the commands which created it ;-)
I think, I had specified an option to create progressive frames.
After running your file through
mplex -f 7 -o test.mpg noSignal.mpg
You're right. That's why it nolonger has the extension .pes ;-)
and displaying test.mpg trough cPlayer::PlayPes() I get a pefectly smooth display.
Would be great if you could find the commands that created this one.
See attachment. This is what file says about my input file:
noSignal.png: PNG image data, 720 x 576, 8-bit/color RGB, non-interlaced
One more thing: the 'file' command reports
MPEG sequence, v2, MP@ML interlaced Y'CbCr 4:2:0 video, 4CIF PAL, 4:3, 25 fps
on a file created with the posted script (before the mplex call), while for your noSignal.mpg it reports
MPEG sequence, v2, MP@ML interlaced Y'CbCr 4:2:0 video, CCIR/ITU PAL 625, 4:3, 25 fps
Maybe this indicates where the problem might be?
Don't think so.
Bye.
On 11/11/07 15:45, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
How does the attached PES file look like? In vdr-xine, I send it just once and it looks OK in xine.
When it looks ok, I'll have to search for the commands which created it ;-)
I think, I had specified an option to create progressive frames.
After running your file through
mplex -f 7 -o test.mpg noSignal.mpg
You're right. That's why it nolonger has the extension .pes ;-)
and displaying test.mpg trough cPlayer::PlayPes() I get a pefectly smooth display.
Would be great if you could find the commands that created this one.
See attachment. This is what file says about my input file:
noSignal.png: PNG image data, 720 x 576, 8-bit/color RGB, non-interlaced
One more thing: the 'file' command reports
MPEG sequence, v2, MP@ML interlaced Y'CbCr 4:2:0 video, 4CIF PAL, 4:3, 25 fps
on a file created with the posted script (before the mplex call), while for your noSignal.mpg it reports
MPEG sequence, v2, MP@ML interlaced Y'CbCr 4:2:0 video, CCIR/ITU PAL 625, 4:3, 25 fps
Maybe this indicates where the problem might be?
Don't think so.
Looks like it is the file size. I have now changed the line
mpeg2enc -f 7 -T 90 -F 3 -np -a 2 -v 0 -o "$TMP2"
to
mpeg2enc -f 7 -T 40 -F 3 -np -a 2 -v 0 -o "$TMP2"
so that the resulting file is about the same size as yours, and now my images also are smooth. However, this most likely means that the picture resolution is now reduced.
Maybe sending a large I-frame continuously causes trouble in the FF DVB cards.
Is there a way to generate a sequence of one (large) I-frame, followed by some number of P-frames, which indicate that there is no change in the image data? Like creating an MPEG sequence from a set of still images, where all stills are the same.
Klaus
Hi,
Klaus Schmidinger schrieb:
Looks like it is the file size. I have now changed the line
mpeg2enc -f 7 -T 90 -F 3 -np -a 2 -v 0 -o "$TMP2"
to
mpeg2enc -f 7 -T 40 -F 3 -np -a 2 -v 0 -o "$TMP2"
so that the resulting file is about the same size as yours, and now my images also are smooth. However, this most likely means that the picture resolution is now reduced.
Maybe sending a large I-frame continuously causes trouble in the FF DVB cards.
Is there a way to generate a sequence of one (large) I-frame, followed by some number of P-frames, which indicate that there is no change in the image data? Like creating an MPEG sequence from a set of still images, where all stills are the same.
Hhm, if you set -n 3 for ppmtoy4m, mpeg2enc should detect, that there are no changes.
Bye.
On 11/11/07 16:05, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
Looks like it is the file size. I have now changed the line
mpeg2enc -f 7 -T 90 -F 3 -np -a 2 -v 0 -o "$TMP2"
to
mpeg2enc -f 7 -T 40 -F 3 -np -a 2 -v 0 -o "$TMP2"
so that the resulting file is about the same size as yours, and now my images also are smooth. However, this most likely means that the picture resolution is now reduced.
Maybe sending a large I-frame continuously causes trouble in the FF DVB cards.
Is there a way to generate a sequence of one (large) I-frame, followed by some number of P-frames, which indicate that there is no change in the image data? Like creating an MPEG sequence from a set of still images, where all stills are the same.
Hhm, if you set -n 3 for ppmtoy4m, mpeg2enc should detect, that there are no changes.
The command sequence I use now looks like this:
pnmscale $S $TMP1 | \ pnmpad -black -width 704 -height 576 | \ ppmntsc --pal | \ ppmtoy4m -F 25:1 -A 4:3 -I p -r -S 420mpeg2 -v 2 -n 3 | \ mpeg2enc -f 7 -a 2 -q 1 -n p -I 0 -T 120 -R 2 -g 10 -G 12 -o "$TMP2" mplex -f 7 -o "$MPG" "$TMP2"
and results in a file with three I-frames:
INFO: [mplex] VIDEO_STATISTICS: e1 INFO: [mplex] Video Stream length: 316949 bytes INFO: [mplex] Sequence headers: 3 INFO: [mplex] Sequence ends : 2 INFO: [mplex] No. Pictures : 3 INFO: [mplex] No. Groups : 3 INFO: [mplex] No. I Frames : 3 avg. size105649 bytes INFO: [mplex] No. P Frames : 0 avg. size 0 bytes INFO: [mplex] No. B Frames : 0 avg. size 0 bytes
So it's a step forward, but we need to make this one I- and two (or more) P-frames.
Klaus
Hi,
Klaus Schmidinger schrieb:
Hhm, if you set -n 3 for ppmtoy4m, mpeg2enc should detect, that there are no changes.
The command sequence I use now looks like this:
pnmscale $S $TMP1 | \ pnmpad -black -width 704 -height 576 | \ ppmntsc --pal | \ ppmtoy4m -F 25:1 -A 4:3 -I p -r -S 420mpeg2 -v 2 -n 3 | \ mpeg2enc -f 7 -a 2 -q 1 -n p -I 0 -T 120 -R 2 -g 10 -G 12 -o "$TMP2" mplex -f 7 -o "$MPG" "$TMP2"
and results in a file with three I-frames:
INFO: [mplex] VIDEO_STATISTICS: e1 INFO: [mplex] Video Stream length: 316949 bytes INFO: [mplex] Sequence headers: 3 INFO: [mplex] Sequence ends : 2 INFO: [mplex] No. Pictures : 3 INFO: [mplex] No. Groups : 3 INFO: [mplex] No. I Frames : 3 avg. size105649 bytes INFO: [mplex] No. P Frames : 0 avg. size 0 bytes INFO: [mplex] No. B Frames : 0 avg. size 0 bytes
So it's a step forward, but we need to make this one I- and two (or more) P-frames.
Try these options:
mpeg2enc -f 8 -a 2 -q 1 -n p -I 0 -T 120 -R 0 -g 10 -G 12 -o noSignal.mpg
But I still think that there is no need to repeat anything. Sending a progressive I-frame as still image should be sufficient, no matter what size the file has. Don't know whether the DVB-API has some limitations regarding image size of still frames.
Bye.
On 11/11/07 16:54, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
Hhm, if you set -n 3 for ppmtoy4m, mpeg2enc should detect, that there are no changes.
The command sequence I use now looks like this:
pnmscale $S $TMP1 | \ pnmpad -black -width 704 -height 576 | \ ppmntsc --pal | \ ppmtoy4m -F 25:1 -A 4:3 -I p -r -S 420mpeg2 -v 2 -n 3 | \ mpeg2enc -f 7 -a 2 -q 1 -n p -I 0 -T 120 -R 2 -g 10 -G 12 -o "$TMP2" mplex -f 7 -o "$MPG" "$TMP2"
and results in a file with three I-frames:
INFO: [mplex] VIDEO_STATISTICS: e1 INFO: [mplex] Video Stream length: 316949 bytes INFO: [mplex] Sequence headers: 3 INFO: [mplex] Sequence ends : 2 INFO: [mplex] No. Pictures : 3 INFO: [mplex] No. Groups : 3 INFO: [mplex] No. I Frames : 3 avg. size105649 bytes INFO: [mplex] No. P Frames : 0 avg. size 0 bytes INFO: [mplex] No. B Frames : 0 avg. size 0 bytes
So it's a step forward, but we need to make this one I- and two (or more) P-frames.
Try these options:
mpeg2enc -f 8 -a 2 -q 1 -n p -I 0 -T 120 -R 0 -g 10 -G 12 -o noSignal.mpg
Doing this (with both -f8 and -f7) didn't show anything when sent via DeviceStillPicture(). I then ran it through mplex and sent it via PlayPes(), and then I got a picture, but again it was jagged.
But I still think that there is no need to repeat anything. Sending a progressive I-frame as still image should be sufficient, no matter what size the file has. Don't know whether the DVB-API has some limitations regarding image size of still frames.
From all I saw today, it only works if the file is not much larger than 40KB,
and if I send it continuously. If I send it only once (even if it has only 40KB) it is jagged.
Klaus
Hi,
Klaus Schmidinger schrieb:
But I still think that there is no need to repeat anything. Sending a progressive I-frame as still image should be sufficient, no matter what size the file has. Don't know whether the DVB-API has some limitations regarding image size of still frames.
From all I saw today, it only works if the file is not much larger than 40KB, and if I send it continuously. If I send it only once (even if it has only 40KB) it is jagged.
Do you get the same jagged images when editing cutting marks? Most likely such an I frame isn't larger than 40 KB.
Bye.
On 11/11/07 17:29, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
But I still think that there is no need to repeat anything. Sending a progressive I-frame as still image should be sufficient, no matter what size the file has. Don't know whether the DVB-API has some limitations regarding image size of still frames.
From all I saw today, it only works if the file is not much larger than 40KB, and if I send it continuously. If I send it only once (even if it has only 40KB) it is jagged.
Do you get the same jagged images when editing cutting marks? Most likely such an I frame isn't larger than 40 KB.
Yes, they are smooth for a brief moment, and then get jagged.
Klaus
Hi,
Klaus Schmidinger schrieb:
Do you get the same jagged images when editing cutting marks? Most likely such an I frame isn't larger than 40 KB.
Yes, they are smooth for a brief moment, and then get jagged.
I recall this behavior when I had a FF card for testing. Maybe it's a feature to stop flickering one pixel high horizontal lines in still images by doubling one field of the frame. Maybe there exists a switch to turn this feature off.
You've tried to repeat an I frame forever. Try to remove the sequence end code (00 00 01 B7) from the end of the file before mplexing and the MPEG program end code (00 00 01 B9) from the file after mplexing. Maybe remove everything up to the first video PES packet from the final file.
Bye.
On 21:03:29 Nov 11, Reinhard Nissl wrote:
I recall this behavior when I had a FF card for testing. Maybe it's a feature to stop flickering one pixel high horizontal lines in still images by doubling one field of the frame. Maybe there exists a switch to turn this feature off.
You've tried to repeat an I frame forever. Try to remove the sequence end code (00 00 01 B7) from the end of the file before mplexing and the MPEG program end code (00 00 01 B9) from the file after mplexing. Maybe remove everything up to the first video PES packet from the final file.
I have no idea what you guys are talking about but have you looked at mencoder and mplayer's filters?
Or transcode?
There are quite a few filters and smoothing algorithms that you might like to make use of to remove the jagged effect or other artifacts.
The bmovl filter might be helpful here.
Or is it some bug in MPEG or DVB implementation?
I dunno...
Best, Girish
Hi,
Girish Venkatachalam schrieb:
I recall this behavior when I had a FF card for testing. Maybe it's a feature to stop flickering one pixel high horizontal lines in still images by doubling one field of the frame. Maybe there exists a switch to turn this feature off.
You've tried to repeat an I frame forever. Try to remove the sequence end code (00 00 01 B7) from the end of the file before mplexing and the MPEG program end code (00 00 01 B9) from the file after mplexing. Maybe remove everything up to the first video PES packet from the final file.
I have no idea what you guys are talking about but have you looked at mencoder and mplayer's filters?
Or transcode?
Or maybe vdr-image plugin. Supports both StillFrame and PlayPes mode.
There are quite a few filters and smoothing algorithms that you might like to make use of to remove the jagged effect or other artifacts.
The bmovl filter might be helpful here.
Or is it some bug in MPEG or DVB implementation?
It seems to be a software/hardware issue. It seems that the FF card displays only a single field of the frame twice (to avoid flickering one pixel horizontal lines on TV) short time after not further data arrives (typical for still frames). And displaying just a single field removes halve of the information to display.
Bye.
Hi,
Reinhard Nissl schrieb:
Yes, they are smooth for a brief moment, and then get jagged.
I recall this behavior when I had a FF card for testing. Maybe it's a feature to stop flickering one pixel high horizontal lines in still images by doubling one field of the frame. Maybe there exists a switch to turn this feature off.
To prove the above mentioned behavior, please try this synthetic file:
http://home.vrweb.de/~rnissl/radio/field_test.mpg
Actually, it should display like here: http://home.vrweb.de/~rnissl/radio/field_test.png
But if the above is true, you'll get some heavy flicker on TV and then it will split the screen into a top and bottom half where one half will be white and the other one black. This will happen when the FF card decides to display just a single field of the frame.
You've tried to repeat an I frame forever. Try to remove the sequence end code (00 00 01 B7) from the end of the file before mplexing and the MPEG program end code (00 00 01 B9) from the file after mplexing. Maybe remove everything up to the first video PES packet from the final file.
Bye.
Would the jagged edges appear because the source was meant for 50Hz Interlaced, while the hardware is set for 60Hz interlaced? I had a similar problem on my nvidia tv-out device, and had to revert back to older drivers.
nvidia-drivers 1.0.7185, is the last driver that still support setting the tv-out device to 50Hz, instead of the default: PAL 60Hz. Any driver that nvidia released later on, doesn't seem to support tv-out @50Hz, no xorg.confsettings will work. My card is an old Geforce4 440MX, so the new cards requires later drivers :(
I hope this maybe helps somebody.
Theunis
On 13/11/2007, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Reinhard Nissl schrieb:
Yes, they are smooth for a brief moment, and then get jagged.
I recall this behavior when I had a FF card for testing. Maybe it's a feature to stop flickering one pixel high horizontal lines in still images by doubling one field of the frame. Maybe there exists a switch to turn this feature off.
To prove the above mentioned behavior, please try this synthetic file:
http://home.vrweb.de/~rnissl/radio/field_test.mpg
Actually, it should display like here: http://home.vrweb.de/~rnissl/radio/field_test.png
But if the above is true, you'll get some heavy flicker on TV and then it will split the screen into a top and bottom half where one half will be white and the other one black. This will happen when the FF card decides to display just a single field of the frame.
You've tried to repeat an I frame forever. Try to remove the sequence end code (00 00 01 B7) from the end of the file before mplexing and the MPEG program end code (00 00 01 B9) from the file after mplexing. Maybe remove everything up to the first video PES packet from the final file.
Bye.
Dipl.-Inform. (FH) Reinhard Nissl mailto:rnissl@gmx.de
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 11/13/07 00:28, Reinhard Nissl wrote:
Hi,
Reinhard Nissl schrieb:
Yes, they are smooth for a brief moment, and then get jagged.
I recall this behavior when I had a FF card for testing. Maybe it's a feature to stop flickering one pixel high horizontal lines in still images by doubling one field of the frame. Maybe there exists a switch to turn this feature off.
To prove the above mentioned behavior, please try this synthetic file:
http://home.vrweb.de/~rnissl/radio/field_test.mpg
Actually, it should display like here: http://home.vrweb.de/~rnissl/radio/field_test.png
But if the above is true, you'll get some heavy flicker on TV and then it will split the screen into a top and bottom half where one half will be white and the other one black. This will happen when the FF card decides to display just a single field of the frame.
When I display field_test.mpg via DeviceStillPicture() on my FF DVB card I see a picture that has a top and a bottom half that rapidly flicker black and white (top black, bottom white and vice versa).
After like half a second the picture gets static, and the top half is solid black, while the bottom half is solid white.
I never see anything like the field_test.png you posted (with alternating black and white lines).
Klaus
Hi,
Klaus Schmidinger schrieb:
When I display field_test.mpg via DeviceStillPicture() on my FF DVB card I see a picture that has a top and a bottom half that rapidly flicker black and white (top black, bottom white and vice versa).
I've just verified this behavior on my EPIA VDR in the living room (which is connected to a 50 Hz TV set) by taking a photo.
The photo shows that the white lines are quite thick -- there is no gap between them. And the black area is totally black, i. e. the white area from the previous field has vanished already.
After like half a second the picture gets static, and the top half is solid black, while the bottom half is solid white.
I had a look into the FF card's driver implementation. The driver simply repeats the still image data for some time. And from your report I guess, that the FF card automatically displays two fields for each frame it receives. When the driver stops sending frames, the FF card displays the last field forever.
I also had a look into the hardware specification. It seems to me that the chip can be switched to a mode where it toggles between the fields automatically. But my coarse understanding of the driver tells me, that the driver doesn't make use of it.
I never see anything like the field_test.png you posted (with alternating black and white lines).
So although xine displays the image on a screen of resolution 720x576 in both cases, it looks like the TV is showing 50 fields of resolution 720x288 while the PC monitor (on my desktop) shows 85 frames of resolution 720x576. Although the TV should weave the two fields, this won't result in a frame of resolution 720x576, as the lines are too thick and the previous field vanished already, so this seems to be the reason why horizontal lines of thickness 1 flicker.
Looks like the only way out of this is to scale the image to 720x288, double the lines and encode it as 720x576.
Bye.
On 12/27/07 14:53, Reinhard Nissl wrote:
... I also had a look into the hardware specification. It seems to me that the chip can be switched to a mode where it toggles between the fields automatically. But my coarse understanding of the driver tells me, that the driver doesn't make use of it.
Can you point me to where you found this info?
Klaus
Hi,
Klaus Schmidinger schrieb:
I also had a look into the hardware specification. It seems to me that the chip can be switched to a mode where it toggles between the fields automatically. But my coarse understanding of the driver tells me, that the driver doesn't make use of it.
Can you point me to where you found this info?
http://www.linuxdvb.tv/documentation/AV711x_3_1.pdf#page=35
See video decoder command "Freeze2".
Bye.
On 12/27/07 14:53, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
When I display field_test.mpg via DeviceStillPicture() on my FF DVB card I see a picture that has a top and a bottom half that rapidly flicker black and white (top black, bottom white and vice versa).
I've just verified this behavior on my EPIA VDR in the living room (which is connected to a 50 Hz TV set) by taking a photo.
The photo shows that the white lines are quite thick -- there is no gap between them. And the black area is totally black, i. e. the white area from the previous field has vanished already.
After like half a second the picture gets static, and the top half is solid black, while the bottom half is solid white.
I had a look into the FF card's driver implementation. The driver simply repeats the still image data for some time. And from your report I guess, that the FF card automatically displays two fields for each frame it receives. When the driver stops sending frames, the FF card displays the last field forever.
I also had a look into the hardware specification. It seems to me that the chip can be switched to a mode where it toggles between the fields automatically. But my coarse understanding of the driver tells me, that the driver doesn't make use of it.
I never see anything like the field_test.png you posted (with alternating black and white lines).
I followed your lead on the FREEZE command and found that when I change the driver's av7110_av.c like this:
--- av7110_av.c 2007-12-30 12:59:44.204192651 +0100 +++ av7110_av.c 2007-12-30 14:03:53.048848398 +0100 @@ -1125,6 +1125,7 @@ dvb_ringbuffer_flush_spinlock_wakeup(&av7110->avout); ret = play_iframe(av7110, pic->iFrame, pic->size, file->f_flags & O_NONBLOCK); + ret = vidcom(av7110, AV_VIDEO_CMD_FREEZE, 1); break; }
I get a smooth still picture (might need some thought on what to actually use as the 'ret' value). And also your test image field_test.mpg displays as shown in your field_test.png (after some short flicker, which apparently comes from the phase where the frame is sent several times to fill up the card's buffer).
Klaus
Hi,
Klaus Schmidinger schrieb:
I also had a look into the hardware specification. It seems to me that the chip can be switched to a mode where it toggles between the fields automatically. But my coarse understanding of the driver tells me, that the driver doesn't make use of it.
I followed your lead on the FREEZE command and found that when I change the driver's av7110_av.c like this:
--- av7110_av.c 2007-12-30 12:59:44.204192651 +0100 +++ av7110_av.c 2007-12-30 14:03:53.048848398 +0100 @@ -1125,6 +1125,7 @@ dvb_ringbuffer_flush_spinlock_wakeup(&av7110->avout); ret = play_iframe(av7110, pic->iFrame, pic->size, file->f_flags & O_NONBLOCK);
ret = vidcom(av7110, AV_VIDEO_CMD_FREEZE, 1); break; }I get a smooth still picture (might need some thought on what to actually use as the 'ret' value). And also your test image field_test.mpg displays as shown in your field_test.png (after some short flicker, which apparently comes from the phase where the frame is sent several times to fill up the card's buffer).
I think sending the frame several times to the card should be omitted then.
Do you think there is the need to distinguish between progressive still images and interlaced ones?
It might be reasonable to show a frame picture for progressive images and only the last field picture for interlaced images.
Bye.
On 12/30/07 14:51, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
I also had a look into the hardware specification. It seems to me that the chip can be switched to a mode where it toggles between the fields automatically. But my coarse understanding of the driver tells me, that the driver doesn't make use of it.
I followed your lead on the FREEZE command and found that when I change the driver's av7110_av.c like this:
--- av7110_av.c 2007-12-30 12:59:44.204192651 +0100 +++ av7110_av.c 2007-12-30 14:03:53.048848398 +0100 @@ -1125,6 +1125,7 @@ dvb_ringbuffer_flush_spinlock_wakeup(&av7110->avout); ret = play_iframe(av7110, pic->iFrame, pic->size, file->f_flags & O_NONBLOCK);
ret = vidcom(av7110, AV_VIDEO_CMD_FREEZE, 1); break; }I get a smooth still picture (might need some thought on what to actually use as the 'ret' value). And also your test image field_test.mpg displays as shown in your field_test.png (after some short flicker, which apparently comes from the phase where the frame is sent several times to fill up the card's buffer).
I think sending the frame several times to the card should be omitted then.
Tried that, but that doesn't work. Apparently the buffer(s) need to be filled up before anything is displayed. Maybe they could be filled with something else than repeating the actual frame data, thus avoiding the short flicker?
Do you think there is the need to distinguish between progressive still images and interlaced ones?
It might be reasonable to show a frame picture for progressive images and only the last field picture for interlaced images.
I'm generating my images as "progressive" (at least that's what I think). The command I'm using is
mpeg2enc -f 3 -b 12500 -a 2 -q 1 -n p -I 0
which gives the best results so far. If I use '-I 1' to have it "interlaced", the result looks just the same on the tv screen.
Klaus
Hi,
Klaus Schmidinger schrieb:
I think sending the frame several times to the card should be omitted then.
Tried that, but that doesn't work. Apparently the buffer(s) need to be filled up before anything is displayed. Maybe they could be filled with something else than repeating the actual frame data, thus avoiding the short flicker?
Hmm, does it work to switch the mode before sending the data?
Do you think there is the need to distinguish between progressive still images and interlaced ones?
It might be reasonable to show a frame picture for progressive images and only the last field picture for interlaced images.
I'm generating my images as "progressive" (at least that's what I think). The command I'm using is
mpeg2enc -f 3 -b 12500 -a 2 -q 1 -n p -I 0
which gives the best results so far. If I use '-I 1' to have it "interlaced", the result looks just the same on the tv screen.
Sure, but that's not what I've meant. The same function is being used to show the image for a cutting mark. Such an image would be interlaced. On my EPIA, vdr-xine would display it as progressive, just as the FF card would do with the changed driver. Don't know whether this matters.
Bye.
On 12/30/07 19:56, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
I think sending the frame several times to the card should be omitted then.
Tried that, but that doesn't work. Apparently the buffer(s) need to be filled up before anything is displayed. Maybe they could be filled with something else than repeating the actual frame data, thus avoiding the short flicker?
Hmm, does it work to switch the mode before sending the data?
Do you think there is the need to distinguish between progressive still images and interlaced ones?
It might be reasonable to show a frame picture for progressive images and only the last field picture for interlaced images.
I'm generating my images as "progressive" (at least that's what I think). The command I'm using is
mpeg2enc -f 3 -b 12500 -a 2 -q 1 -n p -I 0
which gives the best results so far. If I use '-I 1' to have it "interlaced", the result looks just the same on the tv screen.
Sure, but that's not what I've meant. The same function is being used to show the image for a cutting mark. Such an image would be interlaced. On my EPIA, vdr-xine would display it as progressive, just as the FF card would do with the changed driver. Don't know whether this matters.
When I jump to an editing mark with the modified driver, the display is just as smooth as when displaying a still image generated from a jpeg file. So the driver modification also improves this area.
Klaus
On 12/30/07 19:56, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
I think sending the frame several times to the card should be omitted then.
Tried that, but that doesn't work. Apparently the buffer(s) need to be filled up before anything is displayed. Maybe they could be filled with something else than repeating the actual frame data, thus avoiding the short flicker?
Hmm, does it work to switch the mode before sending the data?
If I call vidcom(av7110, AV_VIDEO_CMD_FREEZE, 1) before play_iframe(), I get a black screen for the first picture. Only after switching to the next picture do I see something on the screen. So apparently it must be called afterwards.
Klaus
2007/12/31, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:
If I call vidcom(av7110, AV_VIDEO_CMD_FREEZE, 1) before play_iframe(), I get a black screen for the first picture. Only after switching to the next picture do I see something on the screen. So apparently it must be called afterwards.
Great work! Has this patch already found its way into the dvb drivers?
-
Girish Venkatachalam -
Joachim Wilke -
Klaus Schmidinger -
Reinhard Nissl -
s.huelswitt＠gmx.de -
Theunis Potgieter -
Wolfgang Rohdewald