Opened 5 years ago

Closed 4 years ago

#731 closed defect (needs_more_info)

h264 video frames inside m2ts container get altered after commit 13b7781ec8d475513c1ee40a6e481763b728a71e

Reported by: Andrea3000 Owned by:
Priority: important Component: undetermined
Version: git-master Keywords: h264 m2ts
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

After commit 13b7781ec8d475513c1ee40a6e481763b728a71e, h264 video frames inside m2ts container are altered.
Take a look at those 2 pictures:
Pre commit: Image pre-commit
After commit: Image after-commit

As you can see, after that commit, height of the frame is bigger (by 8 pixles) than the correct one (in this case 1088 against 1080), therefore a black border appears in the bottom part of the window/frame.
This happens with every h264 stream inside m2ts container and never happens with mkv container.
MPEG-2 and VC-1 streams don't have this issue both in m2ts and mkv container.

This bug also causes a crash when deinterlacing and converting image with avpicture_deinterlace and sws_scale. (See https://ffmpeg.org/trac/ffmpeg/ticket/713)

Change History (11)

comment:1 follow-up: Changed 5 years ago by cehoyos

Please provide a sample that allows to reproduce the problem (images are nearly always unneeded).
If the sample is larger than 2.5MB, please see http://ffmpeg.org/bugreports.html or upload to http://www.datafilehost.com/ (and provide the download link).

For all problem reports on this tracker, please provide a (failing) command line and complete, uncut console output.

comment:2 in reply to: ↑ 1 Changed 5 years ago by Andrea3000

Replying to cehoyos:

Please provide a sample that allows to reproduce the problem (images are nearly always unneeded).
If the sample is larger than 2.5MB, please see http://ffmpeg.org/bugreports.html or upload to http://www.datafilehost.com/ (and provide the download link).

For all problem reports on this tracker, please provide a (failing) command line and complete, uncut console output.

It happens with every h264 movie file inside m2ts container, anyway I have uploaded a short sample here: http://www.datafilehost.com/download-902f38c6.html

I'm not able to provide the failing command line because I use FFmepg library as API inside my OSX app.

The strange thing is that it seems to be a parsing issue rather then a decoding issue. I have tried using FFmpeg first only as a parser (decoding frames with the GPU) and later even as a decoder and this black border appears in both of the case. Prior to that commit, both software (FFmpeg) and hardware decoding wasn't giving any black border.

comment:3 Changed 5 years ago by Andrea3000

I have made a further discovery.
Incorrect frame height is given by AVCodecContext->coded_height which reports a value of 1088.
If I override this value (in my app) and set it to 1080, the black border is gone but the app still crash when calling avpicture_deinterlace and sws_scale.

Version 0, edited 5 years ago by Andrea3000 (next)

comment:4 follow-up: Changed 5 years ago by michael

The width and height of the outputed picture is stored in width/height.
H.264 allows croping an image and the uncropped dimensions are in coded_width/coded_height.
This behavior exists since 29a29226. The quoted commit 13b7781ec8d4 is a merge commit and thus has multiple
ancestors, thus iam not sure if you meant to say both its ancestors work and it is the first not working or if you tested something else

comment:5 in reply to: ↑ 4 Changed 5 years ago by Andrea3000

Replying to michael:

The width and height of the outputed picture is stored in width/height.
H.264 allows croping an image and the uncropped dimensions are in coded_width/coded_height.
This behavior exists since 29a29226. The quoted commit 13b7781ec8d4 is a merge commit and thus has multiple
ancestors, thus iam not sure if you meant to say both its ancestors work and it is the first not working or if you tested something else

I've tested f2bd8a0786 ancestor and codec_height was reported correctly. To be precise, I've checked out git repository till b8f02f5b4e which is the last commit prior to 13b7781ec8d4 and that last commit has f2bd8a0786 as ancestor.
Have I to try the second ancestor?

comment:6 follow-up: Changed 5 years ago by michael

The 2 ancestors of 13b7781ec8d4 are ada8d48 and f2bd8a0
git bisect should find the commit introducing the problem but please first verify that you use width/height and not coded_width/coded_height

comment:7 in reply to: ↑ 6 Changed 5 years ago by Andrea3000

Replying to michael:

The 2 ancestors of 13b7781ec8d4 are ada8d48 and f2bd8a0
git bisect should find the commit introducing the problem but please first verify that you use width/height and not coded_width/coded_height

I'm using both width/height and coded_width/coded_height to keep track of both of them.
When I call sws_scale, for example, I pass coded_height as srcSliceH and it has been always worked good. Is it wrong?

The problem is only on coded_width/coded_height, width/height are still correct.

comment:8 Changed 5 years ago by Andrea3000

Can someone answer my last question so that I can further investigate which exact commit introduced the problem?

comment:9 Changed 5 years ago by reimar

I am no longer 100% sure about what the meaning of each is exactly, but you should not (and should not have a reason to) use the coded_* variants. I can't see how your code could even work with "lowres" if you are using coded_*.

comment:10 Changed 5 years ago by cehoyos

Could you confirm if your issue is fixed if you use width and height instead of coded_width and coded_height?

comment:11 Changed 4 years ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed

Please reopen if there still is any problem that you can reproduce.

Note: See TracTickets for help on using tickets.