If I read it right, you basically need to modify the width and height of the incoming caps (which will then recorded by the muxer).  Such caps modifying seems to be more a generic pipeline functionality rather than something that might go in a (or for that matter each individual) muxer.  For example, gentrans has a capssetter element that can do just that.

Thanks Sony!

I will test with capssetter ASAP, if that does what I need maybe its better to just move that to -bad (and eventually good) and not need this hacks mode to the muxer at all.

Note that capssetter has now arrived in -bad, so what about this?

I guess it should be closed :) Closing as Fixed

I'm re-opening this to discuss what the best solution in this particular case might be and if work is still needed on mp4mux.

I think adding some kind of "enable-psp-hack" or "target-device" property (I'm sure someone can find a better name) on the muxer would be a better solution, because:

 a) it's discoverable in gst-inspect-0.10, which
    lowers the barriers of entry/making-stuff-work
    for newcomers

 b) can be used in connection with GstPreset

 c) means that it would still be possible to use
    the width/height of the input caps for
    accepting/rejecting input video streams (in
    future one might not want to accept resolutions
    that are too high for that device to handle,
    for example)

 d) it's closer to the Right Thing To Do, because
    it doesn't violate the usual requirement that
    buffer/stream data is correctly described
    by the caps set on them

I agree with Tim for all the reasons he stated plus it's also more scalable, what if some new hack needs to be done that cannot be done with some element before it (like make sure the order of atoms is this and that).

Should it be a GFlag format-hacks=psp-resolution|xxx-quicks|... then (assuming that we won't run out of flags :)) ?

It's not limited to 320x240. You can do 368x208 with it.

The limit seems to be 76800 pixels in all (not 64k as mentioned on the mencoder page):
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-handheld-psp.html

I don't think that adding this hack is necessary per se, especially when we still can't create a container with the ftypMSNV required.

Yeah, well there is the capssetter element in bad now which lets us do this (and set the ftyp) so if we are to do this we can just use that. Closing this bug.

Although capssetter can influence width/height (whether or not that is the way to go), I do not see how it could do so for the ftyp ?

> Yeah, well there is the capssetter element in bad now which lets us do this
> (and set the ftyp) so if we are to do this we can just use that. Closing this
> bug.

Has anything changed since this was re-opened the last time? See comments 6 and 7.

FYI, I opened bug 595288 about the necessary hacks to have video muxing working for the PSP.

I'm trying to write a patch using the 'target-device' property and I just noticed that the caps that should be handled by mp4mux when the target is psp is really smaller than the default ones. Just wanted to point it out here so we don't forget about it.

IEC 100/1384 ( http://www.canieti.com.mx/assets/files/1011/IEC_100_1384_DC.pdf ) defines a mp4 variant that probably is what PSP uses.

Created attachment 145799 [details] [review]
Initial patch

Initial patch using target-device alternative and doing only the obligatory as from the spec.

Probably patch will only apply after patches from https://bugzilla.gnome.org/show_bug.cgi?id=584361

How can we test this? Anyone with a PSP around?

It would be faster for me to test if you generated a test file that I can dump onto the PSP...

Created attachment 145889 [details]
mp4 for PSP with videotestsrc signal

(In reply to comment #18)
> Created an attachment (id=145889) [details]
> mp4 for PSP with videotestsrc signal

Shows up as "Unsupported data".

The video bitrate isn't set in the information screen.

Created attachment 146072 [details]
Another try with the obligatory fields

Ok, fixed a bug in the PROF atom and added bitrates to them. If this still doesn't work I'll add all the fields, even the optional ones.

*** Bug 595288 has been marked as a duplicate of this bug. ***

anyone with a PSP feels like testing?

I will try to do so this week.

The video bitrate still isn't detected, the resolution shows up as 320x240, and the video codec as AVC.

I borrowed a PSP from a friend to do some testings on this and here are my current findings.

If you use a lower enough resolution (340 x 240 as Christian suggested) you don't need any hacks, mp4mux as is works fine.

I also tried simply lying about the dimensions on the tkhd and stsd entry atoms won't make it work, the psp reports something like 'unsupported data'.

I'll try adding the extra atoms from #595288 and testing later today.

Has someone got this working by just lying in the video dimensions? I can't.

I guess it is saner to add a 'target-device' property and restrict the get_caps to what is really supported. Or should this be handled at a 'profile' level?

Does someone have a video with a higher resolution that works on the PSP?

(In reply to comment #26)
> Has someone got this working by just lying in the video dimensions? I can't.

I never could either.

http://www.ffmpeg.org/faq.html#SEC22
"higher resolution for newer PSP firmwares, width<=480, height<=272"
Depends on the firmware version

Based on Vladimirs comment I will close this bug as obsolete.

> Based on Vladimirs comment I will close this bug as obsolete.

Please explain? As I understand it you still need to fake a smaller resolution in the container somehow, no?

Well it is a hack to begin with and it seems to be a version dependent hack at best, and nobody managed to get this working. So I am not sure keeping this bug open is worth it, as it is not even a bug, it is a feature request to allow for the creation of broken files to support a few PSP systems.