Opened 11 years ago

Closed 10 years ago

#2170 closed defect (invalid)

problem using av_packet_merge_side_data

Reported by: trynitron Owned by:
Priority: normal Component: avformat
Version: 1.1.1 Keywords: regression
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Hi,

I'm currently using ffmpeg API with x264. In my stuff I use av_packet_merge_side_data and av_packet_split_side_data functions. With the latest version of ffmpeg, this isn't working. I mean, the extradata isn't put inside packets.

I try with an old version of ffmpeg API (with the same code) and its working perfect.

Trynitron

Attachments (1)

toCheck.txt (887 bytes ) - added by trynitron 11 years ago.
The way i'm doing the extradata add.

Download all attachments as: .zip

Change History (14)

comment:1 by Carl Eugen Hoyos, 11 years ago

Component: FFmpegundetermined
Keywords: regression added
Priority: normalimportant

Please either provide source code that allows to reproduce your problem or use git bisect to find the change that introduced the bug.

comment:2 by trynitron, 11 years ago

I did a bisect analysis. My current working version is the revision 44968 -> d771b1d137b39a67850beb2204f700697b6c4867.
Building with this one is ok :

Bisecting: 2160 revisions left to test after this (roughly 11 steps)
[a3f30f2e995c3d72664e28a43bec41c4b13ef909] Merge commit '5ae72f54532960cb9eae82a1c9e8d505106c022b'

With the next one :

Bisecting: 1080 revisions left to test after this (roughly 10 steps)
[c8e5efb4961eb779356fcf4195d36e692a25cf2c] mpc8_probe: make buffer related pointers and function arguments const

merging/spiting stuff isn't working anymore. In fact, when using the return error value, all seems ok, but in fact its not...

comment:3 by Carl Eugen Hoyos, 11 years ago

Thank you for testing this, I know this isn't always easy but I will try to help you!

Do I understand correctly / could you confirm that 7456164 fails but d771b1d works fine?
If that is correct, please test 334a0d1. If it works ok, please test 637606d, if it fails, please test 8f37a1e.

by trynitron, 11 years ago

Attachment: toCheck.txt added

The way i'm doing the extradata add.

comment:4 by trynitron, 11 years ago

I just upload a file. You will be able to reproduce the problem. this should not work with the latest version of FFmpeg. By the way, when its working with an old version of FFmpeg, I have sometimes some issues when decoding extradata... (a lot of warnings). Is their some limitations in extradata stuff ? like specific character set, or maximal size ?

Thanks in advance
Trynitron

comment:5 by Carl Eugen Hoyos, 11 years ago

Are you sure the attached file compiles?
Ideally, could you add the gcc command that allows to compile?

comment:6 by Michael Niedermayer, 11 years ago

What you try to store in the file / mux does not seem valid to me. Can you elaborate what kind of container this is and what you are trying to do ?

comment:7 by trynitron, 11 years ago

I will take the time to explain you in detail, with some working code, probably next week. Thanks to take care.

comment:8 by Carl Eugen Hoyos, 11 years ago

Resolution: needs_more_info
Status: newclosed

Please reopen this ticket if you can either:

  • run git bisect as suggested by me in comment:3 (I will then help you with the remaining steps)

or

  • provide the missing information as requested by Michael in comment:6

comment:9 by trynitron, 11 years ago

Component: undeterminedavformat
Resolution: needs_more_info
Status: closedreopened

Hi, I spent some time to solve the problem, and I found it. So The AVpacket merging splitting process using side data is working properly. The problem is in wirting AVpackets to the stream using functions av_write_frame or av_interleaved_write_frame. In latests ffmpeg versions (I pull yesterday) these functions uses an other function split_write_packet.

now the line 525 in mux.c is ret = split_write_packet(s, pkt);
previously working (with side data) line was ret = s->oformat->write_packet(s.pkt);

This function just remove side data from the buffer to be written in the stream, flush the data in the stream, then put again side data in the buffer. So the question is : what did you want to do ?

  • write all the buffer (compressed video data + side data) using *write_frame functions or
  • write the buffer (compressed video data) and use an other function to write the side data

I hope this is sufficient for you to make a decision.

Trynitron

comment:10 by Carl Eugen Hoyos, 11 years ago

Could you explain what you are trying to do / what kind of container you are trying to write to, see comment:6?

comment:11 by trynitron, 11 years ago

I don't use any kind of containers for now, just h264 packets, written with AVpacket stuff. What I want to do is just to put some arbitrary data with a compress video picture, so in the same AVpacket.

Is it clear for you ?

in reply to:  11 comment:12 by Michael Niedermayer, 11 years ago

Priority: importantnormal

Replying to trynitron:

I don't use any kind of containers for now, just h264 packets, written with AVpacket stuff. What I want to do is just to put some arbitrary data with a compress video picture, so in the same AVpacket.

Is it clear for you ?

no
if you use no container than you will never call av_write_frame or av_interleaved_write_frame and nothing
would make any change to your side data that you added. If you do call either of these functions then you do use a container and i would guess this container does not support storing the side data that you added.

comment:13 by Michael Niedermayer, 10 years ago

Resolution: invalid
Status: reopenedclosed

Lacks reproduceable testcase, and noone seems to have been able to make sense of this report in the last 5 month

Note: See TracTickets for help on using tickets.