Ticket #966 (closed defect: fixed)
frwu: change fields order mode
| Reported by: | ami_stuff | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avcodec |
| Version: | git-master | Keywords: | frwu |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | yes | |
| Analyzed by developer: | no |
Description
the first horizontal line from top is moved to bottom of the video frame when file is encoded with "change filelds order" option enabled
C:\>ffmpeg -i frwu_change_field_order.avi out.avi
ffmpeg version N-37208-g01fcbdf Copyright (c) 2000-2012 the FFmpeg developers
built on Jan 27 2012 18:34:52 with gcc 4.6.2
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-ru
ntime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libope
ncore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --en
able-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger -
-enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwben
c --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-
libxvid --enable-zlib
libavutil 51. 34.101 / 51. 34.101
libavcodec 53. 60.100 / 53. 60.100
libavformat 53. 31.100 / 53. 31.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 60.100 / 2. 60.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 6.100 / 0. 6.100
libpostproc 52. 0.100 / 52. 0.100
Input #0, avi, from 'frwu_change_field_order.avi':
Duration: 00:00:01.37, start: 0.000000, bitrate: 9493 kb/s
Stream #0:0: Video: frwu (FRWU / 0x55575246), uyvy422, 192x128, 24 tbr, 24 t
bn, 24 tbc
Incompatible pixel format 'uyvy422' for codec 'mpeg4', auto-selecting format 'yu
v420p'
[buffer @ 02151B20] w:192 h:128 pixfmt:uyvy422 tb:1/1000000 sar:0/1 sws_param:
[buffersink @ 02151DA0] auto-inserting filter 'auto-inserted scale 0' between th
e filter 'src' and the filter 'out'
[scale @ 02151320] w:192 h:128 fmt:uyvy422 -> w:192 h:128 fmt:yuv420p flags:0x4
Output #0, avi, to 'out.avi':
Metadata:
ISFT : Lavf53.31.100
Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 192x128, q=2-31, 200
kb/s, 24 tbn, 24 tbc
Stream mapping:
Stream #0:0 -> #0:0 (frwu -> mpeg4)
Press [q] to stop, [?] for help
frame= 33 fps= 0 q=2.6 Lsize= 64kB time=00:00:01.37 bitrate= 378.5kbits/
s
video:57kB audio:0kB global headers:0kB muxing overhead 11.094793%
Attachments
Change History
comment:1 Changed 17 months ago by cehoyos
- Keywords frwu added
- Status changed from new to open
- Version changed from unspecified to git-master
- Reproduced by developer set
- Summary changed from frwu: change filels order mode to frwu: change fields order mode
comment:2 Changed 17 months ago by richardpl
Does file still plays correctly with native decoder if you remux it with ffmpeg into another container?
comment:3 Changed 17 months ago by ami_stuff
If you mean
ffmpeg -i frwu.avi -vcodec copy frwu.mov
ffmpeg -i frwu.mov -vcodec copy frwu2.avi
then yes, frwu2.avi plays fine with binary codec.
comment:5 Changed 8 months ago by richardpl
Could you create two samples one without this option and one with it but make sure that data is all zeroes in both cases - everything is black - that is only way to found where is such option hidden in bitstream.
comment:6 Changed 8 months ago by ami_stuff
The output files are identical, so it looks like there is no way to identify fields order without user interaction.
comment:7 follow-up: ↓ 8 Changed 8 months ago by richardpl
- Status changed from open to closed
- Resolution set to wontfix
Than how reference decoder could handle it, if it handles it at all?
Closing as there is no way to fix it, it just looks like broken software.
comment:8 in reply to: ↑ 7 Changed 8 months ago by ami_stuff
Replying to richardpl:
Than how reference decoder could handle it, if it handles it at all?
There is an option in the codec to select which field order should be used for decoding and encoding (I thought it is only for encoding, but looks like this is to select decoding field order as well). Similar option are available for mpeg2 and dv codecs from this company.
comment:9 follow-up: ↓ 10 Changed 7 months ago by cehoyos
Does attached patch improve the situation?
(Can you test real interlaced content?)
comment:10 in reply to: ↑ 9 Changed 7 months ago by ami_stuff
Replying to cehoyos:
Does attached patch improve the situation?
(Can you test real interlaced content?)
How do I activate this priv option?
This doesn't work for me:
$ ffmpeg -i frwu_change_field_order.avi -change_field_order out.avi
ffmpeg version 1.0.git-da8242e Copyright (c) 2000-2012 the FFmpeg developers
built on Nov 20 2012 13:54:35 with gcc 4.6.1 (GCC)
configuration: --disable-sse --disable-ffprobe --enable-gpl
libavutil 52. 8.100 / 52. 8.100
libavcodec 54. 73.100 / 54. 73.100
libavformat 54. 37.100 / 54. 37.100
libavdevice 54. 3.100 / 54. 3.100
libavfilter 3. 23.101 / 3. 23.101
libswscale 2. 1.102 / 2. 1.102
libswresample 0. 17.100 / 0. 17.100
libpostproc 52. 2.100 / 52. 2.100
Input #0, avi, from 'frwu_change_field_order.avi':
Duration: 00:00:01.38, start: 0.000000, bitrate: 9493 kb/s
Stream #0:0: Video: frwu (FRWU / 0x55575246), uyvy422, 192x128, 24 tbr, 24 t
bn, 24 tbc
At least one output file must be specified
comment:11 follow-up: ↓ 12 Changed 7 months ago by cehoyos
$ ffmpeg -change_field_order 1 -i frwu_change_field_order.avi out.avi
comment:12 in reply to: ↑ 11 Changed 7 months ago by ami_stuff
Replying to cehoyos:
$ ffmpeg -change_field_order 1 -i frwu_change_field_order.avi out.avi
Ok, this finally works. Could you point me to interlaced avi raw file which I could reencode with VirtualDub? into frwu?
comment:13 Changed 7 months ago by cehoyos
http://samples.ffmpeg.org/MPEG-VOB/interlaced contains some samples, V.VOB is the typical sample that actually needs change of field order (at least with some decoders) to allow de-interlacing.
comment:14 Changed 7 months ago by ami_stuff
I reencoded vob to rawvideo:
ffmpeg -i v.vob -vcodec rawvideo -pix_fmt yuv420p out.avi
and loaded the output into VD + reencoded part of it to frwu:
comment:15 follow-up: ↓ 16 Changed 7 months ago by cehoyos
The question is:
Does the FFmpeg frwu decoder behave differently than the binary decoder without my patch (I believe so, you already provided a sample)? And does it behave identically with my patch assuming you set change_field_order identically for both decoders?
comment:16 in reply to: ↑ 15 Changed 7 months ago by ami_stuff
Replying to cehoyos:
The question is:
Does the FFmpeg frwu decoder behave differently than the binary decoder without my patch (I believe so, you already provided a sample)?
yes
And does it behave identically with my patch assuming you set change_field_order identically for both decoders?
yes
comment:17 follow-up: ↓ 18 Changed 7 months ago by ami_stuff
131 static const AVClass frwu_class = {
132 "srwu Decoder",
please fix typo in the final patch s/srwu/frwu
comment:18 in reply to: ↑ 17 Changed 7 months ago by cehoyos
Replying to ami_stuff:
131 static const AVClass frwu_class = {
132 "srwu Decoder",
please fix typo in the final patch s/srwu/frwu
Done, thank you for spotting!



