dv => mp4: deinterlace or not, and how?
Locked
12
12
dv => mp4: deinterlace or not, and how?
 
|
I have an interlaced dv file. I'm transcoding it with x264 to mp4.
1. ffmpeg -i file.dv -an -vcodec libx264 -b <x> out.mp4 If I just leave it like that, is out.mp4 interlaced or progressive? 2. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -deinterlace out.mp4 Here I assume out.mp4 is progressive. The ffmpeg documentation says: "The alternative is to deinterlace the input stream with `-deinterlace', but deinterlacing introduces losses." Is this still true? Given this note about losses, am I right we should never deinterlace? Almost never? When is deinterlacing required/better? 3. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -flags +ilme+ildct out.mp4 Here I assume out.mp4 is interlaced. How is this different from 1. above? Is it different? The FAQ mentions +alt as a flag. When should this be added? Does it hurt to use it all the time? sean _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
Hi,
On 05/05/2011 01:19 PM, sean darcy wrote: > I have an interlaced dv file. I'm transcoding it with x264 to mp4. > > 1. ffmpeg -i file.dv -an -vcodec libx264 -b <x> out.mp4 > > If I just leave it like that, is out.mp4 interlaced or progressive? progressive. By default encoding is progressive. > 2. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -deinterlace out.mp4 > > Here I assume out.mp4 is progressive. The ffmpeg documentation says: > > "The alternative is to deinterlace the input stream with `-deinterlace', > but deinterlacing introduces losses." Correct, it is progressive. Use -vf yadif instead of -deinterlace Deinterlacing may be a bit destructive, especially if the input is _not_ interlaced. > [...] > > Given this note about losses, am I right we should never deinterlace? > Almost never? When is deinterlacing required/better? You have options: if the receiving end playback interlaced (CRT tv): encode interlaced else if the receiver is going to deinterlace if the file is marked as interlaced and you trust this deinterlacer, then you may encode interlaced (deinterlacing will take cpu time) otherwise you should deinterlace yourself using a good deinterlacer. I suggest always deinterlace using -vf yadif if the source content is interlaced > 3. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -flags +ilme+ildct out.mp4 > > Here I assume out.mp4 is interlaced. How is this different from 1. > above? Is it different? Correct. > The FAQ mentions +alt as a flag. When should this be added? Does it hurt > to use it all the time? +alt only applies to mpeg4 and mpeg2. It's supposed to improve compression for interlaced content. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by sean darcy
On 05/05/11 22:19, sean darcy wrote:
> I have an interlaced dv file. I'm transcoding it with x264 to mp4. > > 1. ffmpeg -i file.dv -an -vcodec libx264 -b <x> out.mp4 > > If I just leave it like that, is out.mp4 interlaced or progressive? > > 2. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -deinterlace out.mp4 > > Here I assume out.mp4 is progressive. The ffmpeg documentation says: > > "The alternative is to deinterlace the input stream with `-deinterlace', > but deinterlacing introduces losses." > > Is this still true? > > Given this note about losses, am I right we should never deinterlace? > Almost never? When is deinterlacing required/better? deinterlacing, Most except 720p, which is rare, television broadcast is interlaced. If the final display is a computer-screen or an iPhone/AndroidPhone or something like that, these devices don't deinterlace by themselves so the source has to be deinterlaced, or has the deinterlace flag set at the moment of display. Most people don't know that their computer mplayer/vlc/WindowsMediaPlayer has an deinterlace option and will see a very bad interlaced picture. > > 3. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -flags +ilme+ildct out.mp4 > > Here I assume out.mp4 is interlaced. How is this different from 1. > above? Is it different? > > The FAQ mentions +alt as a flag. When should this be added? Does it hurt > to use it all the time? > > sean > > _______________________________________________ > ffmpeg-user mailing list > [hidden email] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
|
|
----- Original Message ----- From: "belcampo" <[hidden email]> > If the final display is a TV, which is capable to deinterlacing Oi, big misunderstanding.... a good catholic (injoke) TV is NOT capable of de-interlacing. It is capable of displaying interlaced images one field after another, thus making pretty moving pictures. (don't get me started about 100 Hz sets...) Bouke _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by Baptiste Coudurier-2
On 05/05/2011 21:36, Baptiste Coudurier wrote:
> Hi, > > On 05/05/2011 01:19 PM, sean darcy wrote: >> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >> >> 1. ffmpeg -i file.dv -an -vcodec libx264 -b <x> out.mp4 >> >> If I just leave it like that, is out.mp4 interlaced or progressive? > > progressive. By default encoding is progressive. I'd like to clarify that answer. I agree 100% that the mp4 will be encoded progressive. The problem is that it could be badly encoding interlaced material. What I mean is, it will be using progressive frame encoding techniques to encode a frame that might be carrying interlaced material, which would therefore display with comb edges on movement etc. [...] >> 3. ffmpeg -i file.dv -an -vcodec libx264 -b <x> -flags +ilme+ildct out.mp4 >> >> Here I assume out.mp4 is interlaced. How is this different from 1. >> above? Is it different? > > Correct. It is different from 1 because it encodes the two fields as temporally different half-frames (if you don't mind my over-simplification). In your option 1, the encoder can reduce bit-rate by throwing-away/hiding stuff on every line of the picture, in one go. Because interlacing works by every other line being from a different temporal snapshot, that throwing-away/hiding could move pixels from one temporal snapshot to another. Than can look really horrible. In your opting 3 the encoder knows that the image is made up of the two temporal snapshots and will not do that, but can use its knowledge that the second snapshot may contain the same image as the first snapshot, only with some/all parts moved, to reduce the bit-rate - by encoding the second field as deltas from the first field. -- Mark _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by Bouke-3
On 05/05/2011 22:18, Bouke wrote:
> > ----- Original Message ----- > From: "belcampo" <[hidden email]> > >> If the final display is a TV, which is capable to deinterlacing > > Oi, big misunderstanding.... > a good catholic (injoke) TV is NOT capable of de-interlacing. Although, there are many non-cathode-ray-tube displays that do de-interlace (by line doubling fields), the £3500 JVC TFT monitor next to me and the £350 Sony telly at home being just two examples... > It is capable of displaying interlaced images one field after another, thus > making pretty moving pictures. but, yes that is definitely a better, if somewhat wordy, description that sits better with my pedantic way of thinking. > (don't get me started about 100 Hz sets...) vile, horrid, turn it off NOW. Do manufacturers not understand the time domain? -- Mark _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
|
|
----- Original Message -----
From: "Mark Himsley" <[hidden email]> > Although, there are many non-cathode-ray LOL, You just took a good joke to the next level! Bouke _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by Baptiste Coudurier-2
On 05/05/2011 04:36 PM, Baptiste Coudurier wrote:
> Hi, > > On 05/05/2011 01:19 PM, sean darcy wrote: >> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >> >> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x> out.mp4 >> >> If I just leave it like that, is out.mp4 interlaced or progressive? > > progressive. By default encoding is progressive. > >> 2. ffmpeg -i file.dv -an -vcodec libx264 -b<x> -deinterlace out.mp4 >> >> Here I assume out.mp4 is progressive. The ffmpeg documentation says: >> >> "The alternative is to deinterlace the input stream with `-deinterlace', >> but deinterlacing introduces losses." > > Correct, it is progressive. Use -vf yadif instead of -deinterlace > Deinterlacing may be a bit destructive, especially if the input is _not_ > interlaced. > >> [...] >> >> Given this note about losses, am I right we should never deinterlace? >> Almost never? When is deinterlacing required/better? > > You have options: > if the receiving end playback interlaced (CRT tv): > encode interlaced > else if the receiver is going to deinterlace if the file is marked as > interlaced and you trust this deinterlacer, then you may encode > interlaced (deinterlacing will take cpu time) > otherwise you should deinterlace yourself using a good deinterlacer. Right. I knew that! Just passed right out of my mind, though. > > I suggest always deinterlace using -vf yadif if the source content is > interlaced > Well I found http://guru.multimedia.cx/deinterlacing-filters/ so I thought I'd try: -vf "yadif=3:0,mp=mcdeint=2:0:10" (dv is bottom-field first, right?) That generates a lot of perplexing output: [snow @ 0x230df40] pass:4mv changed:1384 [snow @ 0x230df40] pass:0 changed:1083 [snow @ 0x230df40] pass:1 changed:407 [snow @ 0x230df40] pass:2 changed:147 [snow @ 0x230df40] pass:3 changed:50 [snow @ 0x230df40] pass:4 changed:17 [snow @ 0x230df40] pass:5 changed:11 [snow @ 0x230df40] pass:6 changed:2 [snow @ 0x230df40] pass:7 changed:1 [snow @ 0x230df40] pass:8 changed:1 [snow @ 0x230df40] pass:9 changed:1 [snow @ 0x230df40] pass:10 changed:1 [snow @ 0x230df40] pass:11 changed:2 [snow @ 0x230df40] pass:12 changed:2 [snow @ 0x230df40] pass:13 changed:2 [snow @ 0x230df40] pass:14 changed:0 [snow @ 0x230df40] pass:4mv changed:1864 I realize the filter comparison is from five years ago, and yadif may have changed significantly since then. Does mcdeint still add anything to yadif? sean _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by Mark Himsley
On 05/05/2011 06:32 PM, Mark Himsley wrote:
> On 05/05/2011 21:36, Baptiste Coudurier wrote: >> Hi, >> >> On 05/05/2011 01:19 PM, sean darcy wrote: >>> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >>> >>> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x> out.mp4 >>> >>> If I just leave it like that, is out.mp4 interlaced or progressive? >> >> progressive. By default encoding is progressive. > > I'd like to clarify that answer. > > I agree 100% that the mp4 will be encoded progressive. The problem is > that it could be badly encoding interlaced material. What I mean is, it > will be using progressive frame encoding techniques to encode a frame > that might be carrying interlaced material, which would therefore > display with comb edges on movement etc. > > [...] >>> 3. ffmpeg -i file.dv -an -vcodec libx264 -b<x> -flags +ilme+ildct out.mp4 >>> >>> Here I assume out.mp4 is interlaced. How is this different from 1. >>> above? Is it different? >> >> Correct. > > It is different from 1 because it encodes the two fields as temporally > different half-frames (if you don't mind my over-simplification). > > In your option 1, the encoder can reduce bit-rate by > throwing-away/hiding stuff on every line of the picture, in one go. > Because interlacing works by every other line being from a different > temporal snapshot, that throwing-away/hiding could move pixels from one > temporal snapshot to another. Than can look really horrible. > > In your opting 3 the encoder knows that the image is made up of the two > temporal snapshots and will not do that, but can use its knowledge that > the second snapshot may contain the same image as the first snapshot, > only with some/all parts moved, to reduce the bit-rate - by encoding the > second field as deltas from the first field. > know what to do if I'm keeping the stream interlaced. _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by sean darcy
On 05/05/2011 04:34 PM, sean darcy wrote:
> On 05/05/2011 04:36 PM, Baptiste Coudurier wrote: >> Hi, >> >> On 05/05/2011 01:19 PM, sean darcy wrote: >>> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >>> >>> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x> out.mp4 >>> >>> If I just leave it like that, is out.mp4 interlaced or progressive? >> >> progressive. By default encoding is progressive. >> >>> 2. ffmpeg -i file.dv -an -vcodec libx264 -b<x> -deinterlace out.mp4 >>> >>> Here I assume out.mp4 is progressive. The ffmpeg documentation says: >>> >>> "The alternative is to deinterlace the input stream with `-deinterlace', >>> but deinterlacing introduces losses." >> >> Correct, it is progressive. Use -vf yadif instead of -deinterlace >> Deinterlacing may be a bit destructive, especially if the input is _not_ >> interlaced. >> >>> [...] >>> >>> Given this note about losses, am I right we should never deinterlace? >>> Almost never? When is deinterlacing required/better? >> >> You have options: >> if the receiving end playback interlaced (CRT tv): >> encode interlaced >> else if the receiver is going to deinterlace if the file is marked as >> interlaced and you trust this deinterlacer, then you may encode >> interlaced (deinterlacing will take cpu time) >> otherwise you should deinterlace yourself using a good deinterlacer. > > Right. I knew that! Just passed right out of my mind, though. >> >> I suggest always deinterlace using -vf yadif if the source content is >> interlaced >> > > Well I found http://guru.multimedia.cx/deinterlacing-filters/ > > so I thought I'd try: > > -vf "yadif=3:0,mp=mcdeint=2:0:10" > > (dv is bottom-field first, right?) > > That generates a lot of perplexing output: > > [snow @ 0x230df40] pass:4mv changed:1384 > [snow @ 0x230df40] pass:0 changed:1083 > [snow @ 0x230df40] pass:1 changed:407 > [snow @ 0x230df40] pass:2 changed:147 > [snow @ 0x230df40] pass:3 changed:50 > [snow @ 0x230df40] pass:4 changed:17 > [snow @ 0x230df40] pass:5 changed:11 > [snow @ 0x230df40] pass:6 changed:2 > [snow @ 0x230df40] pass:7 changed:1 > [snow @ 0x230df40] pass:8 changed:1 > [snow @ 0x230df40] pass:9 changed:1 > [snow @ 0x230df40] pass:10 changed:1 > [snow @ 0x230df40] pass:11 changed:2 > [snow @ 0x230df40] pass:12 changed:2 > [snow @ 0x230df40] pass:13 changed:2 > [snow @ 0x230df40] pass:14 changed:0 > [snow @ 0x230df40] pass:4mv changed:1864 This is some debug messages, ignore them. > I realize the filter comparison is from five years ago, and yadif may > have changed significantly since then. Does mcdeint still add anything > to yadif? I think nothing has changed much since then :) -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
On 05/05/2011 07:42 PM, Baptiste Coudurier wrote:
> On 05/05/2011 04:34 PM, sean darcy wrote: >> On 05/05/2011 04:36 PM, Baptiste Coudurier wrote: >>> Hi, >>> >>> On 05/05/2011 01:19 PM, sean darcy wrote: >>>> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >>>> >>>> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x> out.mp4 >>>> >>>> If I just leave it like that, is out.mp4 interlaced or progressive? >>> >>> progressive. By default encoding is progressive. >>> >>>> 2. ffmpeg -i file.dv -an -vcodec libx264 -b<x> -deinterlace out.mp4 >>>> >>>> Here I assume out.mp4 is progressive. The ffmpeg documentation says: >>>> >>>> "The alternative is to deinterlace the input stream with `-deinterlace', >>>> but deinterlacing introduces losses." >>> >>> Correct, it is progressive. Use -vf yadif instead of -deinterlace >>> Deinterlacing may be a bit destructive, especially if the input is _not_ >>> interlaced. >>> >>>> [...] >>>> >>>> Given this note about losses, am I right we should never deinterlace? >>>> Almost never? When is deinterlacing required/better? >>> >>> You have options: >>> if the receiving end playback interlaced (CRT tv): >>> encode interlaced >>> else if the receiver is going to deinterlace if the file is marked as >>> interlaced and you trust this deinterlacer, then you may encode >>> interlaced (deinterlacing will take cpu time) >>> otherwise you should deinterlace yourself using a good deinterlacer. >> >> Right. I knew that! Just passed right out of my mind, though. >>> >>> I suggest always deinterlace using -vf yadif if the source content is >>> interlaced >>> >> >> Well I found http://guru.multimedia.cx/deinterlacing-filters/ >> >> so I thought I'd try: >> >> -vf "yadif=3:0,mp=mcdeint=2:0:10" >> >> (dv is bottom-field first, right?) >> >> That generates a lot of perplexing output: >> >> [snow @ 0x230df40] pass:4mv changed:1384 >> [snow @ 0x230df40] pass:0 changed:1083 >> [snow @ 0x230df40] pass:1 changed:407 >> [snow @ 0x230df40] pass:2 changed:147 >> [snow @ 0x230df40] pass:3 changed:50 >> [snow @ 0x230df40] pass:4 changed:17 >> [snow @ 0x230df40] pass:5 changed:11 >> [snow @ 0x230df40] pass:6 changed:2 >> [snow @ 0x230df40] pass:7 changed:1 >> [snow @ 0x230df40] pass:8 changed:1 >> [snow @ 0x230df40] pass:9 changed:1 >> [snow @ 0x230df40] pass:10 changed:1 >> [snow @ 0x230df40] pass:11 changed:2 >> [snow @ 0x230df40] pass:12 changed:2 >> [snow @ 0x230df40] pass:13 changed:2 >> [snow @ 0x230df40] pass:14 changed:0 >> [snow @ 0x230df40] pass:4mv changed:1864 > > This is some debug messages, ignore them. > >> I realize the filter comparison is from five years ago, and yadif may >> have changed significantly since then. Does mcdeint still add anything >> to yadif? > > I think nothing has changed much since then :) > Now I've tried yadif=1:0. As I understand it, this is "bob" deinterlacing - field doubling (each field becomes a frame) - with spatial and temporal weaving. But the output is strange: [yadif @ 0xfbd9c0] mode:1 parity:0 ......... frame=38981 fps= 15 q=-1.0 Lsize= 624133kB time=1300.60 bitrate=3931.2kbits/s dup=0 drop=38979 There's a "drop" for each input frame. I'd understand this for yadif=0, where (as I understand it) 2 fields are combined into 1 frame. But yadif=0 shows _no_ drops. sean _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
On 05/06/2011 12:04 PM, sean darcy wrote:
> On 05/05/2011 07:42 PM, Baptiste Coudurier wrote: >> On 05/05/2011 04:34 PM, sean darcy wrote: >>> On 05/05/2011 04:36 PM, Baptiste Coudurier wrote: >>>> Hi, >>>> >>>> On 05/05/2011 01:19 PM, sean darcy wrote: >>>>> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >>>>> >>>>> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x> out.mp4 >>>>> >>>>> If I just leave it like that, is out.mp4 interlaced or progressive? >>>> >>>> progressive. By default encoding is progressive. >>>> >>>>> 2. ffmpeg -i file.dv -an -vcodec libx264 -b<x> -deinterlace out.mp4 >>>>> >>>>> Here I assume out.mp4 is progressive. The ffmpeg documentation says: >>>>> >>>>> "The alternative is to deinterlace the input stream with >>>>> `-deinterlace', >>>>> but deinterlacing introduces losses." >>>> >>>> Correct, it is progressive. Use -vf yadif instead of -deinterlace >>>> Deinterlacing may be a bit destructive, especially if the input is >>>> _not_ >>>> interlaced. >>>> >>>>> [...] >>>>> >>>>> Given this note about losses, am I right we should never deinterlace? >>>>> Almost never? When is deinterlacing required/better? >>>> >>>> You have options: >>>> if the receiving end playback interlaced (CRT tv): >>>> encode interlaced >>>> else if the receiver is going to deinterlace if the file is marked as >>>> interlaced and you trust this deinterlacer, then you may encode >>>> interlaced (deinterlacing will take cpu time) >>>> otherwise you should deinterlace yourself using a good deinterlacer. >>> >>> Right. I knew that! Just passed right out of my mind, though. >>>> >>>> I suggest always deinterlace using -vf yadif if the source content is >>>> interlaced >>>> >>> >>> Well I found http://guru.multimedia.cx/deinterlacing-filters/ >>> >>> so I thought I'd try: >>> >>> -vf "yadif=3:0,mp=mcdeint=2:0:10" >>> >>> (dv is bottom-field first, right?) >>> >>> That generates a lot of perplexing output: >>> >>> [snow @ 0x230df40] pass:4mv changed:1384 >>> [snow @ 0x230df40] pass:0 changed:1083 >>> [snow @ 0x230df40] pass:1 changed:407 >>> [snow @ 0x230df40] pass:2 changed:147 >>> [snow @ 0x230df40] pass:3 changed:50 >>> [snow @ 0x230df40] pass:4 changed:17 >>> [snow @ 0x230df40] pass:5 changed:11 >>> [snow @ 0x230df40] pass:6 changed:2 >>> [snow @ 0x230df40] pass:7 changed:1 >>> [snow @ 0x230df40] pass:8 changed:1 >>> [snow @ 0x230df40] pass:9 changed:1 >>> [snow @ 0x230df40] pass:10 changed:1 >>> [snow @ 0x230df40] pass:11 changed:2 >>> [snow @ 0x230df40] pass:12 changed:2 >>> [snow @ 0x230df40] pass:13 changed:2 >>> [snow @ 0x230df40] pass:14 changed:0 >>> [snow @ 0x230df40] pass:4mv changed:1864 >> >> This is some debug messages, ignore them. >> >>> I realize the filter comparison is from five years ago, and yadif may >>> have changed significantly since then. Does mcdeint still add anything >>> to yadif? >> >> I think nothing has changed much since then :) >> > > Now I've tried yadif=1:0. As I understand it, this is "bob" > deinterlacing - field doubling (each field becomes a frame) - with > spatial and temporal weaving. > > But the output is strange: > > [yadif @ 0xfbd9c0] mode:1 parity:0 > ......... > frame=38981 fps= 15 q=-1.0 Lsize= 624133kB time=1300.60 > bitrate=3931.2kbits/s dup=0 drop=38979 > > There's a "drop" for each input frame. I'd understand this for yadif=0, > where (as I understand it) 2 fields are combined into 1 frame. But > yadif=0 shows _no_ drops. > > sean Ran it with yadif=0: [yadif @ 0x1d359c0] mode:0 parity:0 ........ frame=38980 fps= 16 q=-1.0 Lsize= 622885kB time=1300.57 bitrate=3923.4kbits/s s video:622275kB audio:0kB global headers:0kB muxing overhead 0.097974% frame I:166 Avg QP:16.67 size: 50398 No drops. And the resulting file size is approximately the same. But shouldn't the yadif=0 file be ~1/2 the size of the yadif=1 file? That is, 2 fields are becoming 1 frame, so 1/2 the number of frames. Or is x264 just compressing the related "bob" frames so effectively? Or am I misunderstanding this entirely? But I still don't get why yadif=1 drops a frame for each input frame. sean _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
On 05/06/2011 10:02 AM, sean darcy wrote:
> On 05/06/2011 12:04 PM, sean darcy wrote: >> On 05/05/2011 07:42 PM, Baptiste Coudurier wrote: >>> On 05/05/2011 04:34 PM, sean darcy wrote: >>>> On 05/05/2011 04:36 PM, Baptiste Coudurier wrote: >>>>> Hi, >>>>> >>>>> On 05/05/2011 01:19 PM, sean darcy wrote: >>>>>> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >>>>>> >>>>>> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x> out.mp4 >>>>>> >>>>>> If I just leave it like that, is out.mp4 interlaced or progressive? >>>>> >>>>> progressive. By default encoding is progressive. >>>>> >>>>>> 2. ffmpeg -i file.dv -an -vcodec libx264 -b<x> -deinterlace out.mp4 >>>>>> >>>>>> Here I assume out.mp4 is progressive. The ffmpeg documentation says: >>>>>> >>>>>> "The alternative is to deinterlace the input stream with >>>>>> `-deinterlace', >>>>>> but deinterlacing introduces losses." >>>>> >>>>> Correct, it is progressive. Use -vf yadif instead of -deinterlace >>>>> Deinterlacing may be a bit destructive, especially if the input is >>>>> _not_ >>>>> interlaced. >>>>> >>>>>> [...] >>>>>> >>>>>> Given this note about losses, am I right we should never deinterlace? >>>>>> Almost never? When is deinterlacing required/better? >>>>> >>>>> You have options: >>>>> if the receiving end playback interlaced (CRT tv): >>>>> encode interlaced >>>>> else if the receiver is going to deinterlace if the file is marked as >>>>> interlaced and you trust this deinterlacer, then you may encode >>>>> interlaced (deinterlacing will take cpu time) >>>>> otherwise you should deinterlace yourself using a good deinterlacer. >>>> >>>> Right. I knew that! Just passed right out of my mind, though. >>>>> >>>>> I suggest always deinterlace using -vf yadif if the source content is >>>>> interlaced >>>>> >>>> >>>> Well I found http://guru.multimedia.cx/deinterlacing-filters/ >>>> >>>> so I thought I'd try: >>>> >>>> -vf "yadif=3:0,mp=mcdeint=2:0:10" >>>> >>>> (dv is bottom-field first, right?) >>>> >>>> That generates a lot of perplexing output: >>>> >>>> [snow @ 0x230df40] pass:4mv changed:1384 >>>> [snow @ 0x230df40] pass:0 changed:1083 >>>> [snow @ 0x230df40] pass:1 changed:407 >>>> [snow @ 0x230df40] pass:2 changed:147 >>>> [snow @ 0x230df40] pass:3 changed:50 >>>> [snow @ 0x230df40] pass:4 changed:17 >>>> [snow @ 0x230df40] pass:5 changed:11 >>>> [snow @ 0x230df40] pass:6 changed:2 >>>> [snow @ 0x230df40] pass:7 changed:1 >>>> [snow @ 0x230df40] pass:8 changed:1 >>>> [snow @ 0x230df40] pass:9 changed:1 >>>> [snow @ 0x230df40] pass:10 changed:1 >>>> [snow @ 0x230df40] pass:11 changed:2 >>>> [snow @ 0x230df40] pass:12 changed:2 >>>> [snow @ 0x230df40] pass:13 changed:2 >>>> [snow @ 0x230df40] pass:14 changed:0 >>>> [snow @ 0x230df40] pass:4mv changed:1864 >>> >>> This is some debug messages, ignore them. >>> >>>> I realize the filter comparison is from five years ago, and yadif may >>>> have changed significantly since then. Does mcdeint still add anything >>>> to yadif? >>> >>> I think nothing has changed much since then :) >>> >> >> Now I've tried yadif=1:0. As I understand it, this is "bob" >> deinterlacing - field doubling (each field becomes a frame) - with >> spatial and temporal weaving. >> >> But the output is strange: >> >> [yadif @ 0xfbd9c0] mode:1 parity:0 >> ......... >> frame=38981 fps= 15 q=-1.0 Lsize= 624133kB time=1300.60 >> bitrate=3931.2kbits/s dup=0 drop=38979 >> >> There's a "drop" for each input frame. I'd understand this for yadif=0, >> where (as I understand it) 2 fields are combined into 1 frame. But >> yadif=0 shows _no_ drops. >> >> sean > > Ran it with yadif=0: > > [yadif @ 0x1d359c0] mode:0 parity:0 > ........ > frame=38980 fps= 16 q=-1.0 Lsize= 622885kB time=1300.57 > bitrate=3923.4kbits/s s > video:622275kB audio:0kB global headers:0kB muxing overhead 0.097974% > frame I:166 Avg QP:16.67 size: 50398 > > No drops. And the resulting file size is approximately the same. But > shouldn't the yadif=0 file be ~1/2 the size of the yadif=1 file? That > is, 2 fields are becoming 1 frame, so 1/2 the number of frames. Or is > x264 just compressing the related "bob" frames so effectively? Or am I > misunderstanding this entirely? > > But I still don't get why yadif=1 drops a frame for each input frame. No, when using mode 1, please read the documentation: * 1: send 1 frame for each field You are outputting 2 frames for one field. If you want no drop you need to double the frame rate. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by sean darcy
On 2011.05.05 06:34 PM, sean darcy wrote:
> Does mcdeint still add anything > to yadif? Yes, but unless you have a really powerful CPU, it's not worth the extra time that it adds. It's very slow. In any case, using Yadif to deinterlace is almost always a very good idea. Interlaced displays are reaching their last days, and encoders do a much better job with progressive input. _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by Baptiste Coudurier-2
On 05/06/2011 01:27 PM, Baptiste Coudurier wrote:
> On 05/06/2011 10:02 AM, sean darcy wrote: >> On 05/06/2011 12:04 PM, sean darcy wrote: >>> On 05/05/2011 07:42 PM, Baptiste Coudurier wrote: >>>> On 05/05/2011 04:34 PM, sean darcy wrote: >>>>> On 05/05/2011 04:36 PM, Baptiste Coudurier wrote: >>>>>> Hi, >>>>>> >>>>>> On 05/05/2011 01:19 PM, sean darcy wrote: >>>>>>> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >>>>>>> >>>>>>> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x> out.mp4 >>>>>>> >>>>>>> If I just leave it like that, is out.mp4 interlaced or progressive? >>>>>> >>>>>> progressive. By default encoding is progressive. >>>>>> >>>>>>> 2. ffmpeg -i file.dv -an -vcodec libx264 -b<x> -deinterlace out.mp4 >>>>>>> >>>>>>> Here I assume out.mp4 is progressive. The ffmpeg documentation says: >>>>>>> >>>>>>> "The alternative is to deinterlace the input stream with >>>>>>> `-deinterlace', >>>>>>> but deinterlacing introduces losses." >>>>>> >>>>>> Correct, it is progressive. Use -vf yadif instead of -deinterlace >>>>>> Deinterlacing may be a bit destructive, especially if the input is >>>>>> _not_ >>>>>> interlaced. >>>>>> >>>>>>> [...] >>>>>>> >>>>>>> Given this note about losses, am I right we should never deinterlace? >>>>>>> Almost never? When is deinterlacing required/better? >>>>>> >>>>>> You have options: >>>>>> if the receiving end playback interlaced (CRT tv): >>>>>> encode interlaced >>>>>> else if the receiver is going to deinterlace if the file is marked as >>>>>> interlaced and you trust this deinterlacer, then you may encode >>>>>> interlaced (deinterlacing will take cpu time) >>>>>> otherwise you should deinterlace yourself using a good deinterlacer. >>>>> >>>>> Right. I knew that! Just passed right out of my mind, though. >>>>>> >>>>>> I suggest always deinterlace using -vf yadif if the source content is >>>>>> interlaced >>>>>> >>>>> >>>>> Well I found http://guru.multimedia.cx/deinterlacing-filters/ >>>>> >>>>> so I thought I'd try: >>>>> >>>>> -vf "yadif=3:0,mp=mcdeint=2:0:10" >>>>> >>>>> (dv is bottom-field first, right?) >>>>> >>>>> That generates a lot of perplexing output: >>>>> >>>>> [snow @ 0x230df40] pass:4mv changed:1384 >>>>> [snow @ 0x230df40] pass:0 changed:1083 >>>>> [snow @ 0x230df40] pass:1 changed:407 >>>>> [snow @ 0x230df40] pass:2 changed:147 >>>>> [snow @ 0x230df40] pass:3 changed:50 >>>>> [snow @ 0x230df40] pass:4 changed:17 >>>>> [snow @ 0x230df40] pass:5 changed:11 >>>>> [snow @ 0x230df40] pass:6 changed:2 >>>>> [snow @ 0x230df40] pass:7 changed:1 >>>>> [snow @ 0x230df40] pass:8 changed:1 >>>>> [snow @ 0x230df40] pass:9 changed:1 >>>>> [snow @ 0x230df40] pass:10 changed:1 >>>>> [snow @ 0x230df40] pass:11 changed:2 >>>>> [snow @ 0x230df40] pass:12 changed:2 >>>>> [snow @ 0x230df40] pass:13 changed:2 >>>>> [snow @ 0x230df40] pass:14 changed:0 >>>>> [snow @ 0x230df40] pass:4mv changed:1864 >>>> >>>> This is some debug messages, ignore them. >>>> >>>>> I realize the filter comparison is from five years ago, and yadif may >>>>> have changed significantly since then. Does mcdeint still add anything >>>>> to yadif? >>>> >>>> I think nothing has changed much since then :) >>>> >>> >>> Now I've tried yadif=1:0. As I understand it, this is "bob" >>> deinterlacing - field doubling (each field becomes a frame) - with >>> spatial and temporal weaving. >>> >>> But the output is strange: >>> >>> [yadif @ 0xfbd9c0] mode:1 parity:0 >>> ......... >>> frame=38981 fps= 15 q=-1.0 Lsize= 624133kB time=1300.60 >>> bitrate=3931.2kbits/s dup=0 drop=38979 >>> >>> There's a "drop" for each input frame. I'd understand this for yadif=0, >>> where (as I understand it) 2 fields are combined into 1 frame. But >>> yadif=0 shows _no_ drops. >>> >>> sean >> >> Ran it with yadif=0: >> >> [yadif @ 0x1d359c0] mode:0 parity:0 >> ........ >> frame=38980 fps= 16 q=-1.0 Lsize= 622885kB time=1300.57 >> bitrate=3923.4kbits/s s >> video:622275kB audio:0kB global headers:0kB muxing overhead 0.097974% >> frame I:166 Avg QP:16.67 size: 50398 >> >> No drops. And the resulting file size is approximately the same. But >> shouldn't the yadif=0 file be ~1/2 the size of the yadif=1 file? That >> is, 2 fields are becoming 1 frame, so 1/2 the number of frames. Or is >> x264 just compressing the related "bob" frames so effectively? Or am I >> misunderstanding this entirely? >> >> But I still don't get why yadif=1 drops a frame for each input frame. > > No, when using mode 1, please read the documentation: > * 1: send 1 frame for each field > > You are outputting 2 frames for one field. If you want no drop you need > to double the frame rate. > Lost. let me go back to basics. I've got an interlaced input with 38980 "frames". But each of these frames is of 2 fields - each half the size of a progressive frame. And ~60 (59.94) fields are shown each second. For yadif=0, 2 fields are combined into 1 frame. So with my input, I should get the same number of "frames". The framerate would be to ~30 (29.97) frames per second. For yadif=1, each field is reconstructed into a frame. "send 1 frame for each field" . So I have twice the number of "frames", and each frame is a full size progressive frame. And the framerate should now be ~60?? So if I use yadif=1 with a standard 29.97 frame rate, half the frames are discarded. Which means there's no benefit to yadif=1! You'd need to set -r 59.94, and there'd be few if any players for your clip! Am I getting closer? Why would anyone ever use yadif=1 "bob" deinterlacing? sean _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
On 05/06/2011 11:35 AM, sean darcy wrote:
> On 05/06/2011 01:27 PM, Baptiste Coudurier wrote: >> On 05/06/2011 10:02 AM, sean darcy wrote: >>> On 05/06/2011 12:04 PM, sean darcy wrote: >>>> On 05/05/2011 07:42 PM, Baptiste Coudurier wrote: >>>>> On 05/05/2011 04:34 PM, sean darcy wrote: >>>>>> On 05/05/2011 04:36 PM, Baptiste Coudurier wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 05/05/2011 01:19 PM, sean darcy wrote: >>>>>>>> I have an interlaced dv file. I'm transcoding it with x264 to mp4. >>>>>>>> >>>>>>>> 1. ffmpeg -i file.dv -an -vcodec libx264 -b<x> out.mp4 >>>>>>>> >>>>>>>> If I just leave it like that, is out.mp4 interlaced or progressive? >>>>>>> >>>>>>> progressive. By default encoding is progressive. >>>>>>> >>>>>>>> 2. ffmpeg -i file.dv -an -vcodec libx264 -b<x> -deinterlace >>>>>>>> out.mp4 >>>>>>>> >>>>>>>> Here I assume out.mp4 is progressive. The ffmpeg documentation >>>>>>>> says: >>>>>>>> >>>>>>>> "The alternative is to deinterlace the input stream with >>>>>>>> `-deinterlace', >>>>>>>> but deinterlacing introduces losses." >>>>>>> >>>>>>> Correct, it is progressive. Use -vf yadif instead of -deinterlace >>>>>>> Deinterlacing may be a bit destructive, especially if the input is >>>>>>> _not_ >>>>>>> interlaced. >>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>> Given this note about losses, am I right we should never >>>>>>>> deinterlace? >>>>>>>> Almost never? When is deinterlacing required/better? >>>>>>> >>>>>>> You have options: >>>>>>> if the receiving end playback interlaced (CRT tv): >>>>>>> encode interlaced >>>>>>> else if the receiver is going to deinterlace if the file is >>>>>>> marked as >>>>>>> interlaced and you trust this deinterlacer, then you may encode >>>>>>> interlaced (deinterlacing will take cpu time) >>>>>>> otherwise you should deinterlace yourself using a good deinterlacer. >>>>>> >>>>>> Right. I knew that! Just passed right out of my mind, though. >>>>>>> >>>>>>> I suggest always deinterlace using -vf yadif if the source >>>>>>> content is >>>>>>> interlaced >>>>>>> >>>>>> >>>>>> Well I found http://guru.multimedia.cx/deinterlacing-filters/ >>>>>> >>>>>> so I thought I'd try: >>>>>> >>>>>> -vf "yadif=3:0,mp=mcdeint=2:0:10" >>>>>> >>>>>> (dv is bottom-field first, right?) >>>>>> >>>>>> That generates a lot of perplexing output: >>>>>> >>>>>> [snow @ 0x230df40] pass:4mv changed:1384 >>>>>> [snow @ 0x230df40] pass:0 changed:1083 >>>>>> [snow @ 0x230df40] pass:1 changed:407 >>>>>> [snow @ 0x230df40] pass:2 changed:147 >>>>>> [snow @ 0x230df40] pass:3 changed:50 >>>>>> [snow @ 0x230df40] pass:4 changed:17 >>>>>> [snow @ 0x230df40] pass:5 changed:11 >>>>>> [snow @ 0x230df40] pass:6 changed:2 >>>>>> [snow @ 0x230df40] pass:7 changed:1 >>>>>> [snow @ 0x230df40] pass:8 changed:1 >>>>>> [snow @ 0x230df40] pass:9 changed:1 >>>>>> [snow @ 0x230df40] pass:10 changed:1 >>>>>> [snow @ 0x230df40] pass:11 changed:2 >>>>>> [snow @ 0x230df40] pass:12 changed:2 >>>>>> [snow @ 0x230df40] pass:13 changed:2 >>>>>> [snow @ 0x230df40] pass:14 changed:0 >>>>>> [snow @ 0x230df40] pass:4mv changed:1864 >>>>> >>>>> This is some debug messages, ignore them. >>>>> >>>>>> I realize the filter comparison is from five years ago, and yadif may >>>>>> have changed significantly since then. Does mcdeint still add >>>>>> anything >>>>>> to yadif? >>>>> >>>>> I think nothing has changed much since then :) >>>>> >>>> >>>> Now I've tried yadif=1:0. As I understand it, this is "bob" >>>> deinterlacing - field doubling (each field becomes a frame) - with >>>> spatial and temporal weaving. >>>> >>>> But the output is strange: >>>> >>>> [yadif @ 0xfbd9c0] mode:1 parity:0 >>>> ......... >>>> frame=38981 fps= 15 q=-1.0 Lsize= 624133kB time=1300.60 >>>> bitrate=3931.2kbits/s dup=0 drop=38979 >>>> >>>> There's a "drop" for each input frame. I'd understand this for yadif=0, >>>> where (as I understand it) 2 fields are combined into 1 frame. But >>>> yadif=0 shows _no_ drops. >>>> >>>> sean >>> >>> Ran it with yadif=0: >>> >>> [yadif @ 0x1d359c0] mode:0 parity:0 >>> ........ >>> frame=38980 fps= 16 q=-1.0 Lsize= 622885kB time=1300.57 >>> bitrate=3923.4kbits/s s >>> video:622275kB audio:0kB global headers:0kB muxing overhead 0.097974% >>> frame I:166 Avg QP:16.67 size: 50398 >>> >>> No drops. And the resulting file size is approximately the same. But >>> shouldn't the yadif=0 file be ~1/2 the size of the yadif=1 file? That >>> is, 2 fields are becoming 1 frame, so 1/2 the number of frames. Or is >>> x264 just compressing the related "bob" frames so effectively? Or am I >>> misunderstanding this entirely? >>> >>> But I still don't get why yadif=1 drops a frame for each input frame. >> >> No, when using mode 1, please read the documentation: >> * 1: send 1 frame for each field >> >> You are outputting 2 frames for one field. If you want no drop you need >> to double the frame rate. >> > > Lost. let me go back to basics. I've got an interlaced input with 38980 > "frames". But each of these frames is of 2 fields - each half the size > of a progressive frame. And ~60 (59.94) fields are shown each second. > > For yadif=0, 2 fields are combined into 1 frame. So with my input, I > should get the same number of "frames". The framerate would be to ~30 > (29.97) frames per second. > > For yadif=1, each field is reconstructed into a frame. "send 1 frame for > each field" . So I have twice the number of "frames", and each frame is > a full size progressive frame. And the framerate should now be ~60?? > > So if I use yadif=1 with a standard 29.97 frame rate, half the frames > are discarded. Which means there's no benefit to yadif=1! > > You'd need to set -r 59.94, and there'd be few if any players for your > clip! > > Am I getting closer? > > Why would anyone ever use yadif=1 "bob" deinterlacing? You can do 1080i25 to 720p50 for example, but I'm sure there are other usage since the feature is there. -- Baptiste COUDURIER Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA FFmpeg maintainer http://www.ffmpeg.org _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by sean darcy
* sean darcy on Friday, May 06, 2011 at 14:35:03 -0400
> Why would anyone ever use yadif=1 "bob" deinterlacing? To show a converted PAL source via a projector at 50 fps. The results from yadif=3,mcdeint=2:1:10 are brilliant, really. You just need a few days to transcode ;-) c -- \black\trash movie _SAME TIME SAME PLACE_ New York, in the summer of 2001 --->> http://www.blacktrash.org/underdogma/stsp.php _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
|
|
In reply to this post by Andrew Berg
----- Original Message -----
From: "Andrew Berg" <[hidden email]> To: "FFmpeg user questions and RTFMs" <[hidden email]> Sent: Friday, May 06, 2011 8:07 PM Subject: Re: [FFmpeg-user] dv => mp4: deinterlace or not, and how? > On 2011.05.05 06:34 PM, sean darcy wrote: >> Does mcdeint still add anything >> to yadif? > Yes, but unless you have a really powerful CPU, it's not worth the extra > time that it adds. It's very slow. > > In any case, using Yadif to deinterlace is almost always a very good > idea. Interlaced displays are reaching their last days, Excuse me? Where did you get this information about interlacing going away? Do you have anything to backup that what you are saying is actually meaningfull? Sorry if i sound harsh (Trying to be so now), but IMHO, this is just plain bullshit. But i love to be prooven wrong. Bouke > and encoders do > a much better job with progressive input. > _______________________________________________ > ffmpeg-user mailing list > [hidden email] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by Andrew Berg
On 06/05/2011 19:07, Andrew Berg wrote:
> Interlaced displays are reaching their last days Not true. -- Mark _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
Re: dv => mp4: deinterlace or not, and how?
|
|
In reply to this post by Bouke-3
On 2011.05.06 04:30 PM, Bouke wrote:
> Excuse me? Where did you get this information about interlacing going away? > Do you have anything to backup that what you are saying is actually > meaningfull? > > Sorry if i sound harsh (Trying to be so now), but IMHO, this is just plain > bullshit. The only bullshit is you calling me out on something I didn't say. I never said interlacing is going away. In fact, I see it being around for a long time (most broadcasters want to present sports and other fast-motion content at 50 or 59.94Hz instead of 25 or 29.97Hz and still have a "full HD" picture, and no one seems to be willing to broadcast 1080p50/60). HDTVs (and software media players sending video to an LCD monitor) can deinterlace, so broadcasting interlaced material isn't a huge issue. Pure interlaced displays are going away in the near future, to be replaced by LCD monitors and HDTVs. I'm not saying everyone will have an HDTV in the next year, but they are being replaced. As always, there are going to be special situations where encoding interlaced is appropriate for a non-broadcaster, but in general, progressive is the way to go. _______________________________________________ ffmpeg-user mailing list [hidden email] http://ffmpeg.org/mailman/listinfo/ffmpeg-user |
«
Return to FFmpeg-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |