I would like to provide a patch to ffmpeg that would help it support writing 608-style captions to DirecTV HD mp4 streams. The a53 sei header used by ff_alloc_a53_sei does not match the header required by DirecTV. I've written a function (ff_alloc_directv_sei) that will write the correct header, but I need to incorporate it with the rest of the library, and cause it to be used when requested.
(Note that I haven't investigated reading streams with this header. I don't know how often one might want to do this, but it might not be difficult to support, if desired... my interest at the moment is more on encoding compatible streams than decoding). Examining the code further, I see that libx264.c, qsvenc_h264.c, and videotoolboxenc.c all have a reference to a53_cc, treating this integer as a bool, and reacting to a an 'a53cc' option to set it. I wonder if I might try: 1. Retaining a53cc as the option one would set with its current meaning. 2. Creating directvcc as a new option one may set. 3. Changing the a53_cc variable name to to eia_cc. 4. Treating eia_cc as an int instead of a bool. 5. Call neither ff_alloc_a53_sei nor ff_alloc_directv_sei when eia_cc is set to 0. 6. Call ff_alloc_a53_sei appropriately when eia_cc is set to 1. 7. Call ff_alloc_directv_sei appropriately when eia_cc is set to 2. I do not want to move forward with a change like this and risk having this submission rejected... I'd rather work with the team to find what works best. To save time on discussion, though, I'll explain my reasoning for these points: 1. I think it's wise to retain backwards compatibility with those who depend upon the current setting. 2. The header difference is unique to DirecTV, so the name should stand out. 3. 'EIA-608' and 'EIA-708' captioning appears to be the standard of closed captioning both of these headers wrap. If we kept 'a53_cc', it might confuse someone reading the code later. And, obviously, it makes not sense to call it 'directv_cc'. I've tried to recommend a name that both approaches have in common. Perhaps you have a better idea for a variable name. 4. It can't really be a bool at this point, as we need to support a choice of neither, a52, or directv. Three choices can't be jammed into a bool, heh. 5. C treats 0 as false, so this helps dovetail into existing code rather cleanly. 6. I opted for '1' because a53 was supported first, and is frankly the dominant standard. Perhaps you may choose something else. 7. I opted for '2' because directv will be your second standard supported by this. Perhaps you'd prefer a different value. I would normally not want to request of an open source team a fast response to something like this, but I sense some urgency to resolving this issue for the folks who have asked me to look into it. I will feel compelled to move forward with something by sometime next week... I just would prefer it fit in with your recommendations to avoid wasting effort. Also, I do not entirely know if the function I have written is spot-on with the header... I am lacking documentation that would clarify one of the variables that I'm setting. However, I am working with a team that will be able to validate that I'm writing the correct values here, so while I may not necessarily have the right code right now, I will as soon as possible. Alternatively, if someone on this list happens to already know this value, I'm all ears... it's the 'user_data_code_length' value from the DirecTV standard, unique to their header. I do not know if this should be set to side_data-size, or some calculated thing. Many thanks in advance for your attention. - Trey _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
