Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#237 closed defect (fixed)

ffv1 v2

Reported by: dave rice Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Using ffv1 version 2 to encode yuv422p10le and then decoding back to yuv422p10le results in the loss the right 25% of the image. See samples attached.

v210 to ffv1 v2

ffmpeg -y -vsync 0 -i unc_10_bit.mov -vcodec ffv1 -coder 1 -an unc_10_bit_ffv1.mov
ffmpeg version git-N-30179-g8d95317, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 24 2011 13:40:22 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
  configuration: 
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  6. 0 / 53.  6. 0
  libavformat  53.  2. 0 / 53.  2. 0
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2. 10. 0 /  2. 10. 0
  libswscale    0. 14. 0 /  0. 14. 0
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x101012400] Could not find codec parameters (Data: tmcd / 0x64636D74)

Seems stream 0 codec frame rate differs from container frame rate: 2997.00 (2997/1) -> 29.97 (2997/100)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'unc_10_bit.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2009-12-14 22:30:48
  Duration: 00:10:32.86, start: -88.288288, bitrate: 47 kb/s
    Stream #0.0(eng): Video: v210, yuv422p10le, 720x486, 223724 kb/s, PAR 10:11 DAR 400:297, 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc
    Metadata:
      creation_time   : 2009-12-14 22:30:48
    Stream #0.1(eng): Audio: pcm_s16be, 48000 Hz, 2 channels, s16, 1536 kb/s
    Metadata:
      creation_time   : 2009-12-14 22:30:48
    Stream #0.2(eng): Data: tmcd / 0x64636D74
    Metadata:
      creation_time   : 2009-12-14 22:30:48
[buffer @ 0x100d02000] w:720 h:486 pixfmt:yuv422p10le tb:1/1000000 sar:10/11 sws_param:
[mov @ 0x10102c400] Warning, using MS style video codec tag, the file may be unplayable!
Output #0, mov, to 'unc_10_bit_ffv1.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2009-12-14 22:30:48
    encoder         : Lavf53.2.0
    Stream #0.0(eng): Video: ffv1, yuv422p10le, 720x486 [PAR 10:11 DAR 400:297], q=2-31, 200 kb/s, 2997 tbn, 29.97 tbc
    Metadata:
      creation_time   : 2009-12-14 22:30:48
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=    4 fps=  0 q=0.0 Lsize=    1042kB time=88.42 bitrate=  96.6kbits/s    
video:1041kB audio:0kB global headers:0kB muxing overhead 0.074731%

ffv1 back into v210

ffmpeg -y -i unc_10_bit_ffv1.mov -vcodec v210 unc_10_bit_ffv1_back_to_v210.mov
ffmpeg version git-N-30179-g8d95317, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 24 2011 13:40:22 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
  configuration: 
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  6. 0 / 53.  6. 0
  libavformat  53.  2. 0 / 53.  2. 0
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2. 10. 0 /  2. 10. 0
  libswscale    0. 14. 0 /  0. 14. 0

Seems stream 0 codec frame rate differs from container frame rate: 2997.00 (2997/1) -> 29.97 (2997/100)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'unc_10_bit_ffv1.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    creation_time   : 1970-01-01 00:00:00
    encoder         : Lavf53.2.0
  Duration: 00:00:00.13, start: 0.000000, bitrate: 63973 kb/s
    Stream #0.0(eng): Video: ffv1, yuv422p10le, 720x486, 63914 kb/s, PAR 10:11 DAR 400:297, 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc
    Metadata:
      creation_time   : 1970-01-01 00:00:00
[buffer @ 0x100d012e0] w:720 h:486 pixfmt:yuv422p10le tb:1/1000000 sar:10/11 sws_param:
Output #0, mov, to 'unc_10_bit_ffv1_back_to_v210.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 512
    compatible_brands: qt  
    creation_time   : 1970-01-01 00:00:00
    encoder         : Lavf53.2.0
    Stream #0.0(eng): Video: v210, yuv422p10le, 720x486 [PAR 10:11 DAR 400:297], q=2-31, 200 kb/s, 2997 tbn, 29.97 tbc
    Metadata:
      creation_time   : 1970-01-01 00:00:00
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=    4 fps=  0 q=0.0 Lsize=    3646kB time=0.13 bitrate=223770.0kbits/s    
video:3645kB audio:0kB global headers:0kB muxing overhead 0.020174%

Attachments (3)

unc_10_bit.mov.zip​ (1.9 MB ) - added by dave rice 14 years ago.
original v210
unc_10_bit_ffv1.mov​ (1.0 MB ) - added by dave rice 14 years ago.
to ffv1 version 2
unc_10_bit_ffv1_back_to_v210.mov.zip​ (1.5 MB ) - added by dave rice 14 years ago.
and back to v210

Change History (12)

by dave rice, 14 years ago

Attachment: unc_10_bit.mov.zip​ added

original v210

by dave rice, 14 years ago

Attachment: unc_10_bit_ffv1.mov​ added

to ffv1 version 2

by dave rice, 14 years ago

Attachment: unc_10_bit_ffv1_back_to_v210.mov.zip​ added

and back to v210

comment:1 by Carl Eugen Hoyos, 14 years ago

Status: new → open

I cannot reproduce this:
I encoded unc_10_bit.mov with above command line on 32 and 64 bit Linux and PPC OSX, and in all cases, the result plays fine (while your file unc_10_bit_ffv1.mov is broken).

comment:2 by Carl Eugen Hoyos, 14 years ago

md5sum of the resulting mov file (with -an!) is bb5a77c0e436a464290b005c19612410

comment:3 by dave rice, 14 years ago

cehoyos: Did you test with ffv1 version 2? Changing line 935 of ffv1.c to " s->version=2;". ffv1 version <2 works fine for me, but version 2 (multithreading support) doesn't.

comment:4 by Michael Niedermayer, 14 years ago

Reproduced by developer: set
Resolution: → fixed
Status: open → closed
Version: unspecified → git-master

Will be fixed with my next git push

comment:5 by dave rice, 14 years ago

testing from the new version
new output: ​http://www.avpreserve.com/v210_ffv2X2.mov

ffmpeg -i v210.mov -vcodec ffv1 -coder 1 -threads 0 -an v210_ffv1X.mov
ffmpeg version git-N-30166-g1bc81bf, Copyright (c) 2000-2011 the FFmpeg developers
  built on May 23 2011 22:42:17 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
  configuration: --enable-gpl --enable-libfreetype --enable-frei0r --enable-libx264 --enable-shared
  libavutil    51.  2. 1 / 51.  2. 1
  libavcodec   53.  6. 0 / 53.  6. 0
  libavformat  53.  2. 0 / 53.  2. 0
  libavdevice  53.  0. 0 / 53.  0. 0
  libavfilter   2. 10. 0 /  2. 10. 0
  libswscale    0. 14. 0 /  0. 14. 0
  libpostproc  51.  2. 0 / 51.  2. 0

Seems stream 0 codec frame rate differs from container frame rate: 2997.00 (2997/1) -> 29.97 (2997/100)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'v210.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2010-06-22 04:33:09
  Duration: 00:00:10.21, start: 0.000000, bitrate: 223727 kb/s
    Stream #0.0(eng): Video: v210, yuv422p10le, 720x486, 223724 kb/s, PAR 10:11 DAR 400:297, 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc
    Metadata:
      creation_time   : 2010-06-22 04:33:09
[buffer @ 0x100f01140] w:720 h:486 pixfmt:yuv422p10le tb:1/1000000 sar:10/11 sws_param:
[mov @ 0x101000600] Warning, using MS style video codec tag, the file may be unplayable!
Output #0, mov, to 'v210_ffv1X.mov':
  Metadata:
    major_brand     : qt  
    minor_version   : 537199360
    compatible_brands: qt  
    creation_time   : 2010-06-22 04:33:09
    encoder         : Lavf53.2.0
    Stream #0.0(eng): Video: ffv1, yuv422p10le, 720x486 [PAR 10:11 DAR 400:297], q=2-31, 200 kb/s, 2997 tbn, 29.97 tbc
    Metadata:
      creation_time   : 2010-06-22 04:33:09
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=  306 fps= 17 q=0.0 Lsize=   73454kB time=10.21 bitrate=58934.4kbits/s    
video:73450kB audio:0kB global headers:0kB muxing overhead 0.004394%

comment:6 by Carl Eugen Hoyos, 14 years ago

Resolution: fixed
Status: closed → reopened

If you want your problems fixed, please consider explaining them (as you did originally).

comment:7 by dave rice, 14 years ago

cehoyos: To explain it, the resulting ffv1(version 2) encoded file displays improperly at the right most quarter of the image (as before). The update from yesterday now adds visual issues to the right half of the left half of the image (2nd verical quarter). In this quarter the images are jumpy and misplaced, see: ​http://www.avpreserve.com/v210_ffv2X2.mov.

comment:8 by Carl Eugen Hoyos, 14 years ago

Resolution: → fixed
Status: reopened → closed

I believe this really was fixed, but you have to update both your encoding and your decoding application.
(There is some indication that the version 2 format was not frozen yet.)

Please test again.

comment:9 by Michael Niedermayer, 14 years ago

btw, to elaborate on the original bug, the issue was that the slices encoded & decoded by multiple threads where using positions calculated based on 8bit while they really worked with 16bit thus the right side was never encoded, while the middle was encoded (and decoded) twice
I also was not able to reproduce an issue with ​http://www.avpreserve.com/v210_ffv2X2.mov.

Note: See TracTickets for help on using tickets.